セキュリティ製品を入れとけば安全な“つもり”ですか？ セキュリティリサーチャーズが指摘する3つの落とし穴：ITmedia Security Week 2023 夏

2023年6月、「ITmedia Security Week 2023 夏」において、インターネットイニシアティブの根岸征史氏、SBテクノロジーの辻伸弘氏、「piyolog」でおなじみのpiyokango氏の3人が「積もる『つもり』の落し穴」と題してパネルディスカッションを行った。

[宮田健，＠IT]

　安全、安心のために導入したはずのセキュリティ製品が、いつの間にか落とし穴になっていた――。セキュリティリサーチャーとして活動する3人が、そのような目をそむけたくなる現実に斬り込む本セッションでは、それぞれが見つけた、現場に存在する見落としがちな“つもり”をピックアップし、自らを見直すきっかけとなるような話題を提供する。今回も盛り上がったディスカッションをレポートする。

左からSBテクノロジー 辻伸弘氏、piyokango氏、インターネットイニシアティブ 根岸征史氏

ツールが動いていた“つもり”

　piyokango氏がピックアップした事例は、豊田市で発生したメールアドレスの流出だ。これは本来Bccで送信すべきメール送信先を、To／Ccに記載してしまったという事故だったが、この裏には“つもり”が存在していた。

• 報道発表資料　個人情報（電子メールアドレス）の流出について （最終報）｜豊田市

　piyokango氏によると、本件の背景には豊田市が導入した、「強制Bccシステム」が存在するという。このシステムは、もし利用者がメールのToやCcにメールアドレスを入力していたとしても、システム側でそれをBccに置き換えるものだ。メールアドレスの流出を未然に防ぐために導入されたと思われるものだが、それが意図せずに止まったことが事故の原因だ。

　強制Bccシステムが動かなかった理由は、「ライセンス」が更新されていなかったこと。これは「運用委託先が失念していた」と報告されている。その結果、約3日間にわたって強制Bcc設定が働かず、24通のメールに含まれたメールアドレス652件が流出することになった。

豊田市における「強制Bccシステム」のライセンス更新ミス

　piyokango氏はこの事件から、2つの重要なポイントを見いだす。

　1つ目は「フェイルセーフの考え方」だ。万が一にもリスクを顕在化させたくない場合は、安全側に振る設計が望まれるが、「システムが止まったとしてもBccに変更しなかったのは安全側に倒せていないのではないか」という指摘だ。

　「例えば、一時的にメール送信を保留するなどの方法があったのではないか。一方で安全側に倒すと、業務が止まることを考慮しなければならない場合もあり、そのバランスをどうすべきかについて十分に考慮する必要があったのではないだろうか」（piyokango氏）

　2つ目は「一辺倒にならない考え方」だ。本来この強制Bccシステムは、万が一To/Ccでメールを送信しようとしたときに､それを防ぐシステムだったはずだ。

　「報告書に細かな説明はなかったが、もしかしたら利用者も『システムがBccにしてくれるから、Toに送信先を書いてもいいよね』と考えてもおかしくない。使われ方が本来の目的から逸脱していないだろうか。こういうことが起きる前にモニタリングできていればよかったのかもしれない」（piyokango氏）

豊田市の事例から学べること

　本件について根岸氏は「特殊な事例」と述べつつ、「組織においては、ありがちかもしれない。過信、思い込みが幾つか重なり、こういうことが起きる可能性はある。世の中のセキュリティインシデントはほとんどこうやって起きているのではないだろうか。外部委託していたとしても、影響を受けるのは自分たち。チェックする責任はあると思う。学びが多いケースだ」と指摘した。

　辻氏も「そもそもToで送ってはいけないことを把握できていたかどうか疑問に思う。システムが止まった時もおそらくテストされていたはずだが、異常系のテストは例えば電源が抜けたレベル止まりで、『ライセンスが切れた』という特殊な状態は想定されていなかったのかもしれない。通知が出ていたとしても運用カバーができているかどうかを確認するとともに、こういった“保険”的なシステムがあるからといって、乱暴な運転はよくない」と述べた。

Emotet対策できていた“つもり”

　続いて辻氏は、「Emotet」を取り上げる。Emotetは一時的にテイクダウンしていたものの、現在も引き続き「攻撃の波が来ては止まって」を繰り返している。辻氏は「振り返りも兼ねて。いまさらと思っても、だからこそ話さねば」と述べつつ、これまでのEmotetにおける配送方法を振り返る。

　Emotetは手法を変えつつ攻撃が続いた。その配送方法は主に「パスワード付きzip」「Microsoft Office文書」（マクロ）、そして「コンテナ形式」が使われてきた。現在では多くの企業が「パスワード付きzipが添付されたメールを受け取らない」と発表していたり、Microsoftがマクロをデフォルトでオフとしたりするなど、Emotet対策が進んでいる。Emotet攻撃者から見ると、向かい風が強くなったという、良い知らせでもある。

Emotetのこれまでの配送方法

　しかし、攻撃者も手をこまねいているわけではない。Emotetでは新たな配送方法が日々、開発されている。その一つが「巨大ファイル」の利用だ。

　これは添付するファイルとして、パスワードは付いていないながら、600KB程度のファイルが500MBに展開されるというファイルを用い、マルウェアに感染させる手法だ。マルウェア対策製品によっては､一定サイズを超えるファイルのスキャンをスキップするものや、展開後のフォルダ階層を一定層までしかスキャンしないものが存在する。その弱点を突く形の配送方法だ。

　マルウェア対策製品がどのような仕様になっているのかを把握している組織は少ないだろう。しかし、それが悪用されている。この点に関しては「自組織が利用するセキュリティ対策製品が、新しい配送方法も検知できるかどうかを再点検すべきだ」と辻氏は指摘する。

巨大ファイルで検知を回避する新たな手法が登場している

　Microsoftによってマクロによる配送の対策が進んだ結果、攻撃者は新たに「Microsoft OneNote」アプリを配送の手段として悪用しつつある。このアプリが悪用されるポイントとして辻氏は、ビジネス文書のように見せスクリプトを隠蔽（いんぺい）できること、ダブルクリックしても違和感のない“おとり”動作が可能なこと、Microsoft Officeと共にインストールされており、利用者のPCに存在する可能性が高いこと、現在サポートされているWindowsのバージョンにはデフォルトで入っていて攻撃が成立しやすいことなどを挙げる。

狙われるOneNote（画像は辻氏作成のデモ用）

　これを踏まえ、辻氏は古河電池の事例を紹介する。Emotetに感染したという報告書によると、「アンチウイルスソフトウェアが検知し、Emotet感染に気が付いた」としている。これについて辻氏は「メールの中のzipを開いて感染したと報告書にはあるが、検知漏れしたのだろうか？　そうだったとしても、Microsoftがアップデートしていたマクロのブロックがなぜ動かなかったのだろうか」と疑問を呈する。

　圧縮ファイルを展開するアーカイバによっては、「MoTW」（Mark of the Web）という、外部からダウンロードしたことを示すフラグが立つ。このフラグがある場合、マクロを動かせないのを知っているだろうか。本事例では詳細は書かれていないものの、「こういった新しいEmotet対策が生まれた背景にある教訓が、もしかしたら生かされてなかったのかもしれない」と辻氏は述べる。

　「検知に頼るのもアプローチの一つだが、OSや基本機能、基本的な対策で有効な部分もある。先ほどの強制Bccシステムではないが、最後の最後、クライアントでの検知に頼ってしまうと、感染を防げないのではないか。いまのところEmotetは最終的にマクロを使っている。マクロブロックなど共通する部分に着目してほしい」（辻氏）

古河電池の事例

• マルウェア感染に関する調査結果のご報告

　加えて辻氏は、今回の報告書における対策部分に「EDR（Endpoint Detection and Response）の導入」が挙がっていることに注目し、「銀の弾丸は決してないので、それ以外にもやるべきこと、できることにも目を向けてほしい」と指摘する。

　「“最後のとりで”として、EDRを活用する。EDRが最初で、最後のとりでにならぬように使い方を意識してほしい。セキュリティ製品が思ったような動きをしなかったら？　という机上テストもいいのではないかと思う。製品が生かせているかどうかという視点で振り返ってほしい」（辻氏）

　根岸氏もEDR自体の機能については「優れている」と評価する。その上で、EDRで検知した結果「なぜ最後まで分からなかった？」「なぜ途中で気が付けなかった？」と思うことも多いと話す。

　「そこに至るまで何もできなかったのだろうかと思うこともある。最初に触れた基本的な対策がしっかりしていれば、得られる効果も変わる。『侵入されているのが前提だ』といいつつも、エンドポイントだけに依存するのは危険。EDRは『最後の保険がある』ぐらいに思っている方がよいのではないだろうか」（根岸氏）

誤検知だった“つもり”

　根岸氏がピックアップしたのは、ソフトウェアベースの構内電話交換機を提供する3CXで発生した、ソフトウェアサプライチェーン攻撃の事例だ。2023年3月に発生したこのインシデントにも“つもり”が存在する。

　3CXが提供する正規の署名付きインストーラー／アップデータにマルウェアが混入し、利用者が感染してしまった。この原因は、3CXの従業員がトレーディングソフトウェアをインストールした際、そのトレーディングソフトウェア自体がソフトウェアサプライチェーン攻撃を受けており、正規の署名付きインストーラーにマルウェアが既に混入していたことにある。根岸氏もこれについて「私が知る限り世界で初めてのケースではないか」と話すものだ。

　しかし、根岸氏が指摘したいのはその点ではない。今回3CXがマルウェア込みのインストーラーを配布してしまった結果、利用者の環境でアラートが発生する。3CXの公式フォーラムでは、利用者の環境で「EDRがアラートを出している」という報告が幾つか挙がる。しかし、利用者の視点では正規のアップデータを適用しただけであり、多数のユーザーが「これは誤検知だ」と思い込むことになる。3CXのサポートが「EDRの動作はEDRベンダーに問い合わせよ」と回答するにとどまり、3CX自身もこの時点では「誤検知だろう」と考えていた様子がうかがえる。

3CXにおけるソフトウェアサプライチェーン攻撃

　しかし、そのアラートの内容を見ると、分かっている人ならばすぐにぴんとくるような、「シェルコードを検知しました」などの内容が含まれていた。本来ならばアラートが上がったタイミングで調査を開始できたかもしれないが、「誤検知だ」と思い込んでしまった結果、そのアラートの回避方法までフォーラムで議論されていたという。

　「攻撃者からしたら『しめしめ』という状況。ソフトウェアサプライチェーン攻撃の実態もさることながら、このやりとりの方がショックだった」（根岸氏）

含まれていたのは危ないコードだった

　一方で根岸氏は「EDR製品は検知性能も良くなっている」と話す。たとえ攻撃を検知できたとしても、それを判断する“人間”の方に問題があるのではないか。『セキュリティは人間に依存せざるを得ない』という事実を突き付けられたと思った」

　課題は、同じようなことが起きたとき、問題を把握し、正しくトリアージ（対応の優先順位付け）ができるかどうかだ。本件はベンダーも1週間程度気が付けなかった。果たして、自社でこれが起きないといえるだろうか。

　「EDRでもこういうことが起き得ることを、導入前に知っておく必要があるかもしれない。検知した結果を人が見て、人がそれを攻撃ではないと判断し得るのは危ない」（根岸氏）

　そしてこの事象は、別の可能性を指摘している。piyokango氏は「フォーラムでのやりとりに、攻撃者が紛れ込んでいたとしたら」と仮定する。「製品のフォーラムでこういったやりとりをするのは適切だったのだろうか。国家が関与するような攻撃だった場合、あえて偽情報をフォーラムに流し、皆が『誤検知だ』と判断するように誘導する可能性もある」（piyokango氏）

　これを受けて辻氏も次のように話した。「3CXが『EDRベンダーに聞け』と指摘したのは結果的に正しかったかもしれない。セキュリティの専門家ではない人同士だけでなく、一番問題を理解できる正しい部門に聞くべきだった。身を守るためには、疑ってかかるというのが大事なのかもしれない」（辻氏）

これらの“つもり”が自社で起こると仮定して、防げるか？　応用されたら？

　これらの3つの事例は、異なる場所で起きた、異なる事象だ。しかし、「根底には人の思い込みや、こうなっているはずという“過信”がある」と根岸氏。そういったセキュリティ事件は現在も多数発生している。

　辻氏はこれらを踏まえ「これらの話を自分たちに置き換えてみよう。落とし穴はそこら中に存在するのではないかと思う。自分たちの組織で『これら3つの事象が起きた』と想定するだけでなく、『他に応用したらどうなるだろうか』という視点で、見直すきっかけにしてほしい」と話し、パネルディスカッションを締めくくった。