【メールのセキュリティ】メールの乗っ取り事例(その詳細と対策)
最終更新日: 2019/02/07 4:12pm
こんにちは。
経理の小高です。
先日発行のかわら版「メールの乗っ取りと対処について」では、実際に起こったメール乗っ取り事件について(紙面の都合上)その”さわり”だけご紹介しました。
Office365(メールはExchange Onlineです)をご利用中のお客様で発生した事件ですが、弊社にとっても教訓とすべきことが多く、ブログでもう少し詳細を書こうと思いたちました。
一般的にメールシステムのクラッキングは以下のようなイメージで説明されます。
- 侵入者(首謀者)とそのボットネットが被害者のメールシステムに侵入する
- 侵入されたメールシステムはボットネットの一員(戦闘員)になる。
- ボットネットに組み込まれたことで、被害者だったはずが加害者になってしまう。
図1:一般的なメールシステムのクラッキングのイメージ(弊社作成)
この結果として発生するビジネス上の障害としては、被害者側が「スパム登録されてしまう(スパムメールの送信元としてデータベースに登録される)」ことかと思います。
セキュリティベンダーやSpamhauseといった有力なデータベースへ登録されてしまうと、これを解除するためには、それらのデータベースに対して個々の対応をしなければなりません。一番の問題は、解除を即日に行うことができないことです。
たとえば、自社のメールサーバー(ドメイン)がスパム登録された場合、解除されるまでの間、メールを送っても送り先で廃棄されたり迷惑メールに回されたりしてしまいます。これは、ビジネス用途のメールとしては致命的な痛手です。
そして、スパムの送信元となるリスクだけでなく、メールシステムへ侵入されてしまった場合に一番心配されることは「自社、あるいは取引先の機密情報が漏洩してしまったのではないか」ということです。
自社でメールサーバーを保有している場合、メールシステムへの侵入=社内(一般にはDMZかと思われますが)への侵入となります。この場合には「社内ネットワークを通じて、社内に保有する機密情報が暴露される」とか「取引先に侵入される(踏み台攻撃)」というシナリオもありえるのですが、Office365のような有力ベンダーのクラウドメールシステムを利用している場合、メールサーバーへの侵入が困難であることに加え、踏み台になる恐れはまずありません。クラウド型メールシステムの1つのメリットといっていいかと思います。
今回のケースではスパムの送信件数が少なかった(後述)こともあり、「Exchange Onlineの特定アカウントへ侵入された」という「Office365内で閉じたインシデント(事件)」と判断できましたので、Office365内で閲覧可能なリソースが漏洩されなかったか、が対応の焦点となりました。
被害にあったメールアドレスが侵入されたのは深夜で、侵入から(侵入された)アカウントの停止までに10時間ほどかかりました。
結果的には、Office365のログ(アクティビティ)を追跡して「情報が漏洩をした形跡はない」ことがわかり、お客様もわれわれも一安心しました。
マイクロソフトから(クラウドに対する直接的な)クラッキングがあったという報告は出ていませんでしたので、被害に遭ってしまったメールアカウントが「パスワードの脆弱性」などを要因として侵入されたと推測されます。
以下では、クラッキングのルートや規模について詳しく記載します。
今回の侵入では、上の図1のような(教科書的)パターンではなく以下のような攻撃がなされたことがわかりました。
図2:今回のメールシステムのクラッキングのイメージ(弊社作成)
クラックされたメールアカウントが(ボットネットの一員になるのではなく)「ボットネットを構成するコンピュータから寄ってたかって侵入」されていました。
下の図3は、事件の事後報告のために事件発生の1か月前からの当該アカウントへのログインの試み(回数)を、ログを分析して国別に集計したものです。
1か月間の侵入の試みは21か国、85回に及んでいました。
図3:クラックされたメールアカウントへの侵入の試み(弊社作成)
下の図4は、「侵入後にそのメールアカウントを踏み台にしたIPアドレス(一般にサーバー台数)」を集計したものです。
49か国、150台(IP)によって1つのアカウントが侵入されるというのは衝撃的です。アカウントをクラックしたアドレスは中国のものでしたが、漏洩したパスワードが一瞬にして世界を駆け巡ってしまうことがわかります。
図4:クラック後にメールアカウントへ侵入したIPの分布(弊社作成)
150IP(台)から侵入をうけて送信したスパムメールは220件でした。1IPにつき1通ないし2通が第3者へ送られた計算ですので、(侵入元の数と比較して)少ないと感じます。
この理由として考えられるのは、
- (攻撃者)がメールシステムの「調整スロットル」を回避するプログラムを使っている。
かと思われます。
調整スロットルというのは、スパムメールの送信元になることを防止するために、短時間に大量のメールが送られたことを検出すると自動的に送信制限をかける仕組みです。
一般的なビジネス用途のメールシステム(やサーバー)にはこの仕組みが必須です。なぜなら、スロットルがないと侵入を受けた際に(アドレス帳にある)取引先に数万件といったメールを送信して取引先のメールシステムをダウンさせてしまうリスクがあるからです。
攻撃者の視点にたてば、せっかく見つけた踏み台からメールが送れなくなるのは困りますので、「スロットルがかからない程度にスパムの送信を抑制」していると考えられます。
さて、メールの送信件数が220件と比較的少なかった理由はこのように説明できるとして、侵入元1台あたりのメール送信件数がすくない(1IPあたり1、2台)ことの説明がつきません。
強いてあげれば、攻撃者が身元を隠すためではないかと言えるかもしれません。下は上の図3と同じものです。お客様のメールボックスへ侵入の試みを行った攻撃元を表しています。
これらの攻撃元は1つのボットネットではなく、複数の攻撃者が同時に不正侵入を試みていると考えるのが妥当と思われます。下の図で言いますと、赤(中国)、青(シンガポール)、黄色(ドイツ)は違う攻撃者ということです。
図5:クラックされたメールアカウントへの侵入の試み(弊社作成)
下図6は上の図4と同じものですが、様子がだいぶ違います。図5にある中国(赤)の攻撃者が侵入した後、この攻撃者が世界中に散らばるボットネットを中継してお客様のメールボックスに侵入している様(仮説)を表しています。
図6:クラック後にメールアカウントへ侵入したIPの分布(弊社作成)
踏み台を使ったこのような攻撃はインターネットの世界ではよくみられることです。これについては過去にブログを書きましたので、ご興味のある方はご参照ください
ブログ【ホームページの管理】「ちょっと待って、この犯人、ウクライナのプロキシを経由してるのよ!」ペネロピ・ガルシア クリミナルマインドより
推測の域をでませんが、今回の攻撃はこういったものであったのだろうと思います。
この事件で痛感したのは、「トレーサビリティ」に優れたメールシステムの有効性です。
今回のケースのように、侵入がアカウントの乗っ取りによる場合には、メールシステム(メールサーバー)は正常に動いています。
システムが正常に動いていて、かつ、乗っ取られたアカウントが最高権限を持たなければ、侵入者がその行動の形跡(ログ)を消すことは(かなり)難しいことです。そして、ログを消せないということは「何をやったのか後からわかる」ということになります。
Office365には多様なサービス(Exchange, Sharepoint, Onedrive, Teamなど)があります。アクティビティを見れば、頻繁に利用されているサービス、利用されていないサービスがわかります(利用していないサービスには機密情報はありません)。利用頻度が高いサービスについては、複数のログから事件の概要をつかむことができます。
具体的には(ざっくりですが)、
- 機密情報を添付してどこかにメールで送っていないか(Exchange内での行動)
- OneDriveに対する行動はなかったか(Sharepoint、Onedirve内での行動)
などの情報をログをトレースすることでその概要をつかむことができました。(Exchange onlineの監査ログはデフォルトではオフになっていますが、弊社のお客様ではオンでご利用いただいています)
さて、最後に対応策です。
今回の事件を受けて、「メールのアクセス元(どこからメールシステムにログインしようとしているか)を制限する」などの方策が考えられます。
「システム屋的な」案ですが、これは万全ではありません。なぜなら、侵入が日本国内からやってくる可能性があるからです。実際、弊社が管理させていただいているホームページに対して国内からの攻撃が検出されます。
また、図5に示したように、メールボックスは(電子メールの仕様上)不特定多数の攻撃者から常に狙われていると考えるのが妥当ですから、安易にシステム的な対応をすることでリスクがうやむやになりかねません。
事件後(弊社内での対応はあるとして)、お客様に実施いたいだいたのは「パスワードの厳格化」です。
8文字以上で数字・大文字小文字・記号を併用したランダムなもの、というのが厳格なパスワードの1つの基準です。
なぜ8文字か?というのは、個人的な経験に基づいています。もう何年も前になりますが「Excelにパスワードをかけた人が辞めてしまったのだけどどうにかならないか」という相談を受けて、プログラムでクラックしようとしたことがあります。このとき、6文字までのブルートフォース(総当たり)を実行するのに1日程度かかってしまいました。英数小文字大文字を合わせると62文字ありますから、パスワードの長さを7文字にすると単純に62日、8文字にすると62*62=3,844日(10年以上)かかる勘定です。再検証すべきかと思いますが、クラッキングかかる時間はおおむね同程度だろうと思います。
「推測されやすいパスワードはいけない」ということがよく言われますが、これは上記のように「ランダムなパスワードはかなり手ごわい」ことの裏返しです。攻撃者はランダムなパスワードを(ブルートフォース攻撃で)解くよりも、送り先の情報から推測できる文字列に絞った方が成功の確率が高いことを知っています。
パスワードの定期的な変更、というのも重要な運用ですが、これは「乗っ取られていることに気が付かない場合でも、確実に侵入者を締め出す」運用です。
まずは、推測しずらい長いパスワードに変更して、乗っ取られないための防御をすべきです。
身が引き締まる事件ですので、弊社のサービス向上に役立てていきたいと考えます。
←「【お知らせ】イー・レンジャーかわら版(2019年2月号:メールの乗っ取りと対策)を発行しました。」前の記事へ 次の記事へ「【お知らせ】イー・レンジャーかわら版(2019年3月号:NOTICEをかたる詐欺に注意しましょう)を発行しました。」→