体系的に学ぶメールセキュリティ

      

概要

ここでは、メールのセキュリティ脅威とセキュリティ対策について解説する。

メールは、組織や個人において電子データをやり取りする手段として、従来より広く利用されている。
最近では、組織内や特定グループでの電子データのやり取りにグループウェアや SNS を使用することも多くなっているが、外部とのやり取りには依然メールを利用していることが多いと思われる。

メールの普及・利用率の高さと同時に、メールを悪用したサイバー攻撃は従来より問題視されており、標的型メール攻撃に代表されるような規模の大きなサイバー攻撃にも利用されている。

一方、「メールシステムが存在する情報システムネットワーク」と「制御システムネットワーク」が直接接続されているケースは極まれであり、メールを悪用したサイバー攻撃から直接、制御システムに被害が及ぶことはめったにない。

しかし、過去のサイバー攻撃事例より、メールによるサイバー攻撃を契機に制御システムの情報が窃取されたり、内部ネットワークを伝搬することで制御システムネットワークまで侵入されたりし、制御システムに被害が生じたケースもある。

このように、メールは大規模なサイバー攻撃の起点となりやすいため、メールシステムは制御システムと直接接続されていないので制御システムには関係ないと考えるのではなく、組織全体と間接的な制御システムへの攻撃を防ぐということを意識し、メールシステムのセキュリティ対策に取り組んでいただきたい。

本記事では、メールを契機としたサイバー攻撃事例、メールの送付・受信の仕組み、メールにおけるセキュリティ脅威、メールにおけるセキュリティ対策の順番に解説していく。

      

メールを契機とした制御システムへのサイバー攻撃事例

文献[1-7] を参考に、メールを契機として制御システムが攻撃された主な事例について紹介する。
(※攻撃自体の詳細は割愛させていただく。)
      

攻撃事例 概要
2012年と2016年のサウジアラビアの石油会社へのサイバー攻撃
(Shamoon, Shamoon2)[2]
マクロ付きのファイルが添付されたメールを開封したことが、本攻撃の契機となったとされている(推測情報)。
2014年のドイツの製鉄所へのサイバー攻撃 [3] PDF のような文書ファイルが添付されたメールを開封したことが、本攻撃の契機となった。
2015年のウクライナ西部の電力供給会社へのサイバー攻撃
(BlackEnergy3)[4]
マクロ付きの Office ファイルが添付されたメールを開封したことが、本攻撃の契機となった。
2016年のウクライナ首都近郊の電力供給会社へのサイバー攻撃
(CrashOverride / Industroyer)[5]
マクロ付きのファイルが添付されたメールを開封したことが、本攻撃の契機となったとされている(推測情報)。
2016年のサンフランシスコの市交通局へのサイバー攻撃 [6] ランサムウェアそのもの(拡張子偽装など開封させるような工夫をしていたとされる)を添付したメールを開封したことが、本攻撃の契機となったとされている(推測情報)。
2018年のGreyEnergyによるサイバー攻撃 [7] マクロ付きのファイルが添付されたメールを開封したことが、本攻撃の契機となった。

       
制御システム自体への実被害がない事例もあるものの、メールを契機にマルウェア感染し、そこから感染拡大や情報窃取されることで、制御システムまで被害・攻撃が至っていることが分かる。

      

メールの仕組み

メールの送信・受信をする際の大まかな仕組みについて図1を参考に説明する。
図1では、A さんから B さんにメールを送付する際の流れを示している。
      


                図1:メール送信/受信の概要

      

メール送信・受信について下記に示す(図1の番号とはリンクしていないので注意されたい)。
各用語と概要については、下表の通りである。

  1. A さんがメーラ(MUA)にて B さんのメールアドレスを指定したメールを作成してメーラで送信する。
  2. メーラが DNS に送信時に利用するメールサーバAのIPアドレスを取得する。
  3. メーラとメールサーバA の MSA が SMTP を使用して、認証とメールの内容を授受する。
  4. MSA が受け取ったメールの内容を MTA に配送する。
  5. MTA は送信先メールアドレスが外部の場合、送信先メールサーバ(メールサーバB)のIPアドレスを DNS に問い合わせて取得する。
  6. MTA は MDA にメールの内容を配送する。
  7. MDA は MTA が解決したメールサーバB の MTA に対して、SMTP を使用してメールの内容を配送する。
  8. メールサーバ B の MTA は、受け取ったメールの内容をローカル転送用の MDA に渡す。
  9. MDA は MRA にメールの内容を渡す。
  10. MRA は、MUA のリクエストを基に、POP または IMAP にてメールを授受する。

      

用語 概要
MUA
(Mail User Agent)
エンドユーザが利用するメーラのプログラムを指し、SMTP(Simple Message Transfer Protocol)で
MTA にメール送信したり POP/IMAP を利用して MRA かメールを受信する。
代表的なメーラとしては、Thunderbird、Outlook、Mew などがある。
MSA
(Message Submission Agent)
MUA から送信されるメールを受信し、MTA に配送するプログラムを指す。
SMTP の認証機能等を持つ。MTA にまとめられることも多い。
MTA
(Mail Transfer Agent)
MDA にメールを配送したり、MDA からメールを受け取ったりするプログラムを指す。
外部のメールアドレスに送信する際は、DNS に送信先のメールサーバのアドレスを問い合わせる機能も持つ。
代表なプログラムとして、postfix、sendmail、Exchange 等がある。
MDA
(Mail Delivery Agent)
MTA から配送されるメールを指定する宛先に配送するプログラムを指す。
外部のメールサーバの MTA に送付する際は、SMTP を使用する。MTA にまとめられることも多いが、
procmail や maildrop のようなローカル MDA に特化したプログラムもある。
MRA
(Mail Retriecal Agent)
メールボックスに保存されたメールを MUA に配送するプログラムを指す。
POP(Post Office Protocol)や IMAP(Internet Message Access Protocol)を使用する。
代表的なプログラムとして、Dovecot、Courier-imap、Exchange 等がある。
DNS
(Domain Name System)
ドメインとIPアドレスを紐づけているシステムを指す。
MUA が送信時のメールサーバのアドレスを解決したり、MTA が送信先のメールサーバのアドレスを
解決したりする際に利用される。

      

メールにおけるセキュリティ脅威

メールにおけるセキュリティ脅威について、図2に示す。


                図2:メールにおけるセキュリティ脅威

      
図2の脅威1は、SMTP、POP、IMAP といったメールで利用されるプロトコルは、暗号化機能や改ざん検知機能が備わっていないことを悪用するものである。
このため、攻撃者が何等かの方法でこれらのプロトコルでやり取りしている通信を閲覧できる場合、メールの内容の盗聴やメールの内容を改ざんをされる危険性がある。

脅威2は、送信先のメールアドレスに対して送信元のメールアドレスの詐称、メールにマルウェアを添付、本文にマルウェアに感染するような不正URLを記述、オープンリレーの設定を悪用といった直接送信先メールアドレスの受信者やメールサーバに対して攻撃を行うものである。

      

メールにおけるセキュリティ対策

次の表に、それぞれの脅威とそれに対応するセキュリティ対策をまとめる。
オープンリレーの悪用については、メールサーバ側の設定で対応するものであるため、下表からは除外している。
また、どこにも分類されない対策については、「その他」という分類にしている。
     

対策内容 盗聴 メール改ざん 送信元アドレス偽装 マルウェア/不正URL添付 その他
SMTPS(SMTP over SSL)
IMAPS(IMAP over SSL)
POP3S(POP3 over SSL)
STARTTLS
SMTP-AUTH(SMTP認証) 〇(なりすまし)
OP25B(Outbound Port 25 Blocking) 〇(スパム)
POP Before SMTP 〇(なりすまし)
S/MIME(Secure/Multipurpose Internet Mail Extensions)
PGP(Pretty Good Privacy)
SPF(Sender Policy Framework)
SenderID
DKIM(DomainKeys Identified Mail)
DMARC
(Domain-based Message Authentication, Reporting and Conformance)
アンチウイルス/サンドボックス
添付ファイル暗号化 〇(誤送信/データ漏洩)
データ損失防止(DLP: Data Loss Prevention) 〇(誤送信/データ漏洩)

      
続いて、それぞれの対策の概要を以下の表でまとめる。
      

対策内容 概要
SMTPS(SMTP over SSL) 465/TCP ポートを使用し、SSL/TLS での暗号化通信で SMTP 通信を行う仕組みである。
はじめから SSL/TLS 通信で暗号化する。
IMAPS(IMAP over SSL) 993/TCP ポートを使用し、SSL/TLS での暗号化通信で IMAP 通信を行う仕組みである。
はじめから SSL/TLS 通信で暗号化する。
POP3S(POP3 over SSL) 995/TCP ポートを使用し、SSL/TLS での暗号化通信で POP3 通信を行う仕組みである。
はじめから SSL/TLS 通信で暗号化する。
STARTTLS 従来の SMTP(25/TCP or 587/TCP)、IMAP(143/TCP)、POP(110/TCP)のポート番号を変更することなく、
暗号化通信を実施できる仕組みである。はじめは SMTP/IMAP/POP 通信を行い、途中から STARTTLS 命令を発行し、
SSL/TLS 通信で暗号化する。
SMTPS などのように、専用のポートをファイアウォール等で開示する必要がないことがメリットである。
SMTP-AUTH(SMTP認証) メールを送信する前に、送信側メールサーバ(SMTPサーバ)にユーザアカウントとパスワードの認証を行い、
認証が許可された場合にメールを送付できるという仕組みのこと。
OP25B(Outbound Port 25 Blocking) スパムメールや迷惑メールをブロックするために、SMTP サーバの 25/TCP をブロックする設定をすること。
OP25B を行っている場合、25/TCP の代わりに、SMTP-AUTH を有効にした上で、
587/TCP(Submission Port)を利用することが多い。
POP Before SMTP メール送信時に、POPサーバでユーザ認証を行い、認証が許可された場合は認証を行った端末のIPアドレスが
メールサーバに登録され、一定時間メール送信ができるという仕組み。
現在は、IPアドレスの詐称による認証回避が可能とされているため、この手法は廃止の傾向となっている。
S/MIME(Secure/Multipurpose Internet
Mail Extensions)
メール本文の暗号化と送信者の正当性を検証する仕組みである。
メール本文を共通鍵暗号方式で暗号化し、その共通鍵を公開鍵暗号方式を用いて受け渡しする。
通常、公開鍵は認証局に登録する必要がある。
メール本文の改ざんと送信者の正当性を確認できる。通信自体は暗号化されない。
送信者ごとに検証する仕組みであり、DKIM のようなドメイン単位での検証ではない。
PGP(Pretty Good Privacy) メール本文の暗号化と送信者の正当性を検証する仕組みである。
メール本文を共通鍵暗号方式で暗号化し、その共通鍵を公開鍵暗号方式を用いて受け渡しする。
仕組み的には S/MIME と似ているが、第三者が他の証明書の証明を行う「Web-of-trust」という考え方を
採用している。
友達の友達は、友達で信用できるという考え。
公開鍵ごとに異なるフィンガープリントを使用して認証する方法もある。通信自体は暗号化されない。
S/MIME と同様に、送信者ごとに検証する仕組みであり、DKIM のようなドメイン単位での検証ではない。
SPF(Sender Policy Framework) 送信元ドメインが詐称されていないか検証する仕組みである。送信側は DNS に「SPFレコード」という
送信メールサーバのIPアドレス等の情報を追加する。これにより、受信したメールサーバは送信元メールアドレスの
ドメインの SPF レコードを取得し、受信されたメールアドレスのドメインの IP アドレスと比較することで、
詐称されているメールアドレスか判断することができる。ちなみにドメインは、
エンベロープFrom に設定されたドメインを確認する(つまり、エンベロープFromの改ざんを検証する)。
なお、受信側のメールサーバにおいても、SPF 認証の機能をオンにする必要がある。
欠点としては、ヘッダFrom の改ざんは検証できないこと、SPFレコードを登録しているメールサーバを利用した
メールは検証が通ること、SPF レコードに登録されているメールサーバ自体を踏み台にされた場合は検証が通る等、
効果は発揮できないケースもある。
SenderID 送信元ドメインが詐称されていないか検証する仕組みである。Microsoft が考案した Caller ID for Email と
SPF が組み合わさって出来た規格である。SPF と仕組みは同じであるが、基本的にはヘッダFrom に設定された
ドメインと SPF レコードを確認する個所が異なる(つまり、ヘッダFrom の改ざんを検証する)。
SenderID でもエンベロープFrom を確認できる等の記事も見つかったりはするが、
これは SPF と組み合わせて使用したケースと考えてよいだろう。なお、どちらも似た仕組みであるため、
ネット記事では SPF/SenderID と記述されることが多いが、上記のように厳密には異なるので注意されたい。
欠点としては SPF と同様に、エンベロープFrom の改ざんは検証できないこと、
SPFレコードを登録しているメールサーバを利用した攻撃メール(ヘッダFromを改ざんしていない場合に限る)や
SPF レコードに登録されているメールサーバ自体を踏み台にされた場合、
効果は発揮できない。このため、SPF と SenderID の両方の認証機能を有効化しなければ、
送信元ドメインの詐称に対する効果的な対策はできない。
DKIM(DomainKeys Identified Mail) 送信ドメインの詐称とメール本文の改ざんを検証する仕組みである。公開鍵暗号方式を利用しており、
事前に DNS サーバに公開鍵を登録しておき、送信時に送信側メールサーバにて送信側の秘密鍵で
電子署名したメールを送付する。
受信側メールサーバは送信元ドメインの DNS サーバから公開鍵を取得し、その電子署名を検証することで、
送信元詐称やメール本文の改ざんを検知できる。S/MIME や PGP のように送信者ごとの検証ではない。
DMARC
(Domain-based Message Authentication,
Reporting and Conformance)
SPF や DKIM の認証機能の結果に対して、どのような処理を実施するかを定める仕組みである。
これらの認証結果により、そのメールをどのように扱うかは受信者の判断にゆだねられている。
そこで、DMARC という判断基準が策定された。
DMARC の利用は SPF と同様、DNS の TXT レコードに DMARC レコードを設定することで利用できる
(当然受信側メールサーバの設定も必要である)。
DMARC には、「動作を指定しない」、「隔離する」、「拒否する」というポリシーを設定できる。
アンチウイルス/サンドボックス メールの添付ファイルや本文中に記載されている URL をアンチウイルスエンジンやサンドボックス上で
解析することで、悪性なファイルや URL でないか検査する機能である。
添付ファイル暗号化 添付ファイルを暗号化し、第三者から中身を閲覧できないようにする仕組みである。
添付ファイルをパスワード付きの ZIP ファイル(共通鍵暗号方式)に変換する仕組みが多い。
データ損失防止
(DLP: Data Loss Prevention)
DLP は、送信されるメールの本文や添付ファイルを検査し、あらかじめ指定した文字列や
コンテンツが記入されていないか検査し、データ送信を未然に防ぐ機能である。
DLP を有効化することで、誤送信による機密情報の漏えい等を防止することができる。

      
このように、メールのセキュリティ対策は数多く存在しており、対策効果が重複しているケースもある。
自組織において、どのリスクを優先して対策するか明確にした上で、上の表を参考にしながら対策を進めていただければと思う。

     

おわりに

ここでは、メールを契機としたサイバー攻撃の事例、メールの仕組みの概要、メールのセキュリティ対策について解説した。

メールは、非常にシンプルな仕組みとプロトコルで成り立っているがゆえ、サイバー攻撃に利用されやすく、同時にセキュリティ対策も数多く存在していることが理解していただけたと思う。

また、メールのセキュリティ対策については、一つの対策だけでメールの脅威をすべて対応できるものではなく、複数の対策を組み合わせる必要がある。

今後もメールは現在と変わらず利用されていくシステムであると予想されるので、今一度、自組織のメールのセキュリティ対策について振り返ってみてはいかがだろうか。

     

参考文献

[1] IPA, 制御システムの情報セキュリティ~ 社会インフラや工場に対するサイバー攻撃の脅威と対策~, https://www.ipa.go.jp/files/000073863.pdf
[2] OPSWAT, How Shamoon Malware Infected Saudi Organizations Again, https://www.opswat.com/blog/how-shamoon-malware-infected-saudi-organizations-again
[3] SANS, German Steel Mill Cyber Attack, https://ics.sans.org/media/ICS-CPPE-case-Study-2-German-Steelworks_Facility.pdf
[4] Kaspersky, BlackEnergy APT Attacks in Ukraine, https://www.kaspersky.com/resource-center/threats/blackenergy
[5] virsec, Virsec Hack Analysis: Deep Dive into Industroyer (aka Crash Override), https://virsec.com/virsec-hack-analysis-deep-dive-into-industroyer-aka-crash-override/
[6] THe Register, Passengers ride free on SF Muni subway after ransomware infects network, demands $73k, https://www.theregister.co.uk/2016/11/27/san_francisco_muni_ransomware/
[7] eset, GREYENERGY A successor to BlackEnergy, https://www.welivesecurity.com/wp-content/uploads/2018/10/ESET_GreyEnergy.pdf

      

登録日時2019-12-25 23:11:19
更新日時2019-12-25 23:19:12