アップデート前に脆弱性を突く「ゼロデイ攻撃」にどう対策するか

本記事はキヤノンマーケティングジャパンが提供する「マルウェア情報局」に掲載された「高まるゼロデイ攻撃のリスクにどう対処すべきか」を再編集したものです。

「ゼロデイ攻撃」とは何か

サイバー攻撃の巧妙化・高度化に合わせて、その対策も進化を遂げてきた。攻撃と対策は、いたちごっこのような関係であるが、OSやアプリケーションが日々進化し続けることが前提となっている中、脆弱性の要因を完全に取り除くことは不可能に近い。OSやアプリケーションのベンダーが脆弱性を発見し、その修正のためのアップデートを配布した日を「ワンデイ」とし、ゼロデイ攻撃はそのワンデイより前の「ゼロデイ」に、その脆弱性を突く攻撃のことである。脆弱性を修正するためのアップデートでは時間的に間に合わないため、対応できることにも限りがある。そのため、ゼロデイ攻撃は、数あるサイバー攻撃の中でも「もっとも深刻な脅威である」と言われている。

ゼロデイ攻撃が発生する背景

OSやアプリケーションの脆弱性を攻撃者が最初に発見した場合や、修正アップデートの提供前に、脆弱性が公表された場合、その脆弱性を突いたゼロデイ攻撃を受けてしまうリスクが生じる。特に、これまでOSやアプリケーションのベンダーにも知られてない未知の脆弱性を突くゼロデイ攻撃は、攻撃者にとっては格好の餌食であり、大きな魅力となる。ダークウェブでは、こうしたベンダーに知られていない未知の脆弱性に関する情報が高値で取引されていることも明らかになってきている。さらに、ダークウェブ上ではマルウェアそのものの取引もおこなわれており、自分でマルウェアを作成するスキルがない人も攻撃者になり得るのだ。

暗号資産（仮想通貨）の普及にともない、ダークウェブで取引される情報やマルウェアなどの市場規模は年々大きくなっており、エコシステムを確立してきている。今後、ゼロデイ攻撃の脅威はさらに増加していくことは想像に難くない。

過去に起きたゼロデイ攻撃の事例

これまでにも大規模なゼロデイ攻撃がおこなわれ、被害が出ている。代表的な事例は以下の通りだ。

・2014年4月のハートブリード攻撃
2014年4月に暗号化通信のオープンソフト「OpenSSL」の脆弱性を悪用する「ハートブリード攻撃」によって、国内の大手信販会社が攻撃され、894人のWeb会員の個人情報が流出。ものの､この脆弱性は2012年から存在していたものである。（補足：攻撃された企業が不正アクセスを検知した直前にこの脆弱性に対するバグの修正版が公開されてはいたため､厳密に言えばゼロデイ攻撃ではないとする意見もある｡）

・2014年9月のシェルショック脆弱性事件
Linuxなどで使われているシェル「Bash」の脆弱性を突いたゼロデイ攻撃である。Bashは多くのサーバーの運営管理に使われており、影響は大きく、IPAから緊急告知がおこなわれた。日本国内でも遠隔操作被害などが相次ぎ、警察署が監視し報告書を公開するなど、大きな騒ぎとなった。

・2015年1月のAdobe Flash Playerの脆弱性を突いたゼロデイ攻撃
Adobe Flash Playerには以前から脆弱性があると言われていたが、2015年1月13日、Adobeがそれまでにわかっていた脆弱性を修正したバージョン16.0.0.257をリリース。しかし、そのバージョンにも致命的な脆弱性がふたつ発見され、それら脆弱性を突いたゼロデイ攻撃活動が確認された。

・2017年4月のMS Office/WordPadの脆弱性を突いたゼロデイ攻撃
2017年4月12日、Microsoft社が月例セキュリティ更新プログラムを公開。この更新プログラムで修正されたMS Office/WordPadの脆弱性を突いたRTF形式文書ファイルが添付されたメールが4月10日から12日にかけて80万通以上送信された。ファイルを開封することで内部に含まれているVBScriptが実行される恐れがあり､注意喚起がおこなわれた｡

・2019年6月のFirefoxの脆弱性を突いたゼロデイ攻撃
2019年6月17日、米国の暗号資産取引所Coinbaseがサイバー攻撃に遭遇。この攻撃は、大学関係者になりすました標的型攻撃メールとWebブラウザーFirefoxの脆弱性を突いたゼロデイ攻撃の組み合わせによるもの。Coinbaseの対応が迅速だったこともあり、実害は生じなかったものの、Webブラウザーの脆弱性は大きなセキュリティホールとなり得ることを改めて示した形となった。

また、2019年6月にはESETの研究者がWindowsのゼロデイ脆弱性をいち早く発見し、Microsoftセキュリティレスポンスセンターに報告、ゼロデイ攻撃に悪用されることを防いだ。

参考URL:https://eset-info.canon-its.jp/malware_info/trend/detail/190723.html

このように、未知の脆弱性を狙うゼロデイ攻撃は増加し続けている｡製品やサービス提供側においても､提供するものに対する責任と､攻撃が発覚した際の対応について適切かつ迅速な行動が求められるようになってきている。

ゼロデイ攻撃への対策

ゼロデイ攻撃は、まだ修正されていない脆弱性を突いた攻撃であり、根本的な対策は難しいとされる。しかし、以下に挙げるような対策を講じることで、ゼロデイ攻撃を受けた場合でも、被害の低減あるいは被害回避の可能性が高まる。

・ベンダーから提供される対応策をすみやかに適用する
OSやアプリケーションのベンダーから、脆弱性を修正するプログラムが提供される前に、被害の低減、回避するための対策が公開されることがある。常に情報収集を欠かさず、対応策が発表され次第、適用する。

・入口対策をおこない、感染を防ぐ
ファイアウォールを設置して不正な通信をブロック、サンドボックスを設置して未確認の添付ファイルなどを実行したときに異常な動きがないかを分析することで、入口部分で可能な限り感染を予防する。

・多層防御で未知のマルウェアへ対処
IDS/IPS（不正侵入検知・侵入防御システム）によるネットワーク監視や機密情報をサーバーへ隔離、ファイルの暗号化など、防御壁を複数設けることで、ゼロデイ攻撃によって侵入したマルウェアが、機密情報に到達する確率を下げる。また、動作を許可したアプリケーション以外は、起動や実行ができないように制限するホワイトリスト型のセキュリティツールを導入することも有効な対策となる。

・EDRを導入する
従来型のエンドポイント対策では検知できない不審な挙動の検知を行うEDR（Endpoint Detection and Response）を導入する。EDRは「不正な挙動の検知およびマルウェアに感染した後の対応や復旧を迅速に行う」ための製品。ゼロデイ攻撃などのセキュリティ侵害をいち早く検知・可視化することによって、侵害後の対応を迅速化し、被害の最小化につながる。外部への送信データのチェックや不正な通信の遮断が有効になることもある。なお、EDRについては、こちらの記事を参照してほしい。

参考URL：https://eset-info.canon-its.jp/malware_info/term/detail/00109.html

・ホワイトハッカーやコミュニティに協力を依頼する
アプリケーション開発側の対策としては、いかに攻撃者よりも早く未知の脆弱性を見つけるかということが重要だが、自社内だけでは、その人手が足りないことも多い。そのため、アプリケーションベンダーの中には、自社製品の脆弱性を報告してくれた人に懸賞金を出すところも出てきている。セキュリティ向上のために、アプリケーションを解析、ハッキングする善なるハッカーをホワイトハッカーと呼ぶが、ダークウェブで暗躍する悪のハッカー（クラッカー）の脅威から自社製品を守るためには、ホワイトハッカーやユーザーコミュニティなどの協力を得ることもひとつの対抗策となる。

迅速な対応と侵入される前提で対策を講じることが求められる時代に

ここ数年のセキュリティ意識の高まりにより、ゼロデイ攻撃という言葉自体の認知度は高くなっている。しかし、ゼロデイ攻撃は具体的な攻撃手法というよりはむしろ、概念・考え方と捉えるほうが正確だろう。今後も攻撃側と防御側のせめぎあいが続いていく中で、いまやゼロデイ攻撃とされる未知の脆弱性を突くことが主流となりつつあるのが実状だ。攻撃者が成功確率を追う限り、その流れは変わることはない。

だからこそ、防御側に求められるのは迅速な対応と、侵入後にどう回復するかということになる。インシデントレスポンスの考え方は大企業を中心に浸透しつつあるが、サプライチェーン攻撃などの影響で中小企業もサイバー攻撃のターゲットとなりつつある今、より一歩踏み込んだ対策をとる必要があるのではないだろうか。