Skip to main content
MSRC

攻撃コードのトレンド（Exploitation Trend）～セキュリティ インテリジェンスレポート第16版から～

Japan Security Team
/ By Japan Security Team / / 25 min read

5 月に公表された「マイクロソフト セキュリティ インテリジェンスレポート第 16 版」の特集記事、「攻撃コードのトレンド（Exploitation Trend）」を紹介します。

マイクロソフト セキュリティ インテリジェンスレポート（以下、SIR）は、半期に一度マイクロソフトが公開しているセキュリティに関する分析レポートで、ソフトウェアの脆弱性、攻撃コード(Exploit)、マルウエア、フィッシング、悪性の Web サイト等に関する分析を中心としたものです。今回公表された第 16 版では、2013 年下半期（2013 年 7 月―12 月）を対象としています。
SIR では、特集記事として話題性の高いテーマを取り上げており、これまでボットネットへの取組み、クラウドのセキュリティ、オンライン広告を使ったサイバー犯罪などを取り上げてきました。今回は、紹介する「攻撃コードのトレンド」も、第 16 版の特集記事として掲載されている内容です。

SIR は主要なレポートだけでも約 140 ページの分厚い資料ですが、興味深い内容も多いので、ぜひオリジナルのレポートをご覧いただければと思います。

セキュリティ インテリジェンスレポート
http://www.microsoft.com/ja-jp/security/resources/sir.aspx

Security Intelligence Report
http://www.microsoft.com/security/sir/default.aspx

攻撃コードのトレンド ～潜在的なリスクから現実の脅威へ～

ゼロデイ攻撃が話題になる機会が増えていますが、ゼロデイ攻撃を含め、攻撃コードやマルウエア対策を進めるためには、現状を出来るだけ正確に理解する必要があります。本特集記事では、脆弱性と脆弱性に対する攻撃の推移に着目し、脆弱性悪用の技術的な傾向と、流通状況等の分析を行っています。

脆弱性の悪用に関する状況

最初に脆弱性に対する攻撃コードが確認された割合の分析です。
Figure.1 は、リモートコード実行可能な脆弱性のうち、実際に攻撃コードが確認された脆弱性の割合を表したグラフです。最も危険で悪用が容易な脆弱性にも関わらず、2013 年はわずかに 10%の脆弱性だけが悪用されるにとどまりました。
現在の攻撃コード開発者は、脆弱性情報や攻撃コードを販売し、これを購入した攻撃者が、マルウエア感染を通じた不法行為通により収益を上げるというエコシステムになっています。このため、攻撃コードの開発に見合った収益が見込めない場合は、その脆弱性は攻撃コード開発の対象とならない傾向にあります。Figure.1 は、この傾向がよく表れています。

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/20/8130.Fig1.png)

攻撃コードが確認されたタイミング

Figure.2 は、リモートコード実行可能な脆弱性に対する、最初の攻撃コードが確認された時期を分析したものです。
2011 年から、このカテゴリのゼロデイ攻撃は減少していますが、あわせて脆弱性の総数が減少しています。このため、相対的にゼロデイ攻撃の割合が増えており、2013 年には公表された脆弱性の大半を占めるようになりました。
この変化は、セキュアコーディングの普及により、新たにリモートコード実行可能な脆弱性を見つけることが難しくなったことが背景になっています。脆弱性の発見が難しくなったことで脆弱性の総数が減少し、その結果として未公開の攻撃コードの価値が高まったと考えられます。攻撃コードの開発者は、収益を最大化するため、脆弱性対策が公表され、セキュリティソフトが検知するようになるまでは、極めて限定的な相手（顧客など）を対象に取引をするようになっており、これがゼロデイ攻撃の割合が増えた要因となっています。
ゼロデイとは対照的に、公開後 30 日を超えてから、最初の攻撃コードが出現するケースは減少しています。これは、一カ月以内に脆弱性の対処が行われるコンピューターの割合が増え、古い脆弱性を悪用した攻撃が成功する可能性が減少しているためだと考えられます。

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/20/fig2.png)

悪用された脆弱性カテゴリ(root cause)の傾向

Figure.3 では、悪用されたマイクロソフト製品のリモートコード実行可能な脆弱性の脆弱性カテゴリ（root cause）に関する分析です。

まず目につくのが、Stack Overflow に代表されるスタックに関する脆弱性の減少です。2007 年には、54.2%を占めていましたが、2013 年には 5%まで減少しています。これは、コンパイラ(Visual Studio 等)の対策が進展したことより、/GS や SafeSEH 等の緩和策が機能していることや、開発時の静的な分析ツール（コード解析ツール）の精度の向上が貢献していると考えられます。
スタックに関する脆弱性の減少に合わせるように、Useafter-free 脆弱性の悪用が増加しています。Drive-by-Download 等の手法が一般化したことで、クライアントが主要な標的になりました。Userafter-free は、クライアント側で稼働するアプリケーションによく見られる脆弱性である事から、攻撃コード開発の主要なターゲットなってきたものと考えられます。
なお、Stuxnet で悪用された、DLL ロードの脆弱性は、2009 年から 2012 年にかけては悪用が確認されていますが、2013 年では悪用が確認されませんでした。

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/20/fig3.png)

DEP（Data Execution Prevention）と、ASLR(Address Space Layout Randomization)は、脆弱性の悪用方法に大きな影響を与えています。Figure.4 は、マイクロソフト製品に対する攻撃手法を分析したもので、DEP と ASLR を回避する新たな手法を見つける事が、攻撃者の焦点となっていることがうかがえます。DEP を回避するための手法として ROP(Return Oriented Program)が主要な手法となっていますが、ROP を成功させるためには ASLR を回避する必要があります。このため、ROP と ASLR を回避する新たな手段が研究の焦点となっています。ASLR の回避には、ASLR が利用されていないイメージを使うか、アドレス情報が取得可能な脆弱性が利用される場合が大半を占めています。
なお、DEP と ASLR に加えて、最新の Internet Explorer と EMET の利用率の向上は、実効性のある攻撃コードの開発を困難なものにしています。

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/20/fig4.png)

誰が攻撃コードを使うのか

脆弱性が明らかになる経緯は様々です。攻撃コードが犯罪者の手に渡る様子を、2012 年 1 月から 2014 年 2 月に攻撃コードが発見された、16 の脆弱性について分析をしました。
最初に攻撃コードが明らかになった経緯を分析すると、標的型攻撃 9 件、攻撃フレームワーク 3 件、トレーダー（販売業者）2 件、セキュリティ研究者 2 件でした。これらの攻撃のうち 8 件は、後に攻撃フレームワークに取り込まれ、8 件のうち 2 件は犯罪者向けの攻撃キットに取り込まれました。
少ないサンプル数ではありますが、攻撃コードは標的型攻撃で使用され、このうちの一部が数か月後を経て広範囲に影響を与える犯罪者向けの攻撃キットに取り込まれています。このことは、セキュリティ更新プログラムを迅速に適用することが、攻撃コードによる攻撃をリスクを避ける上で有効な対策であることを裏付けています。

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/20/fig5.png)

攻撃コードの開発者は、限定的な取引ばかりでなく、商用の攻撃キットを通じて収益を上げています。誰でもハッカーフォーラムなどで、攻撃キットの購入やレンタルすることで、容易に攻撃者となることが可能です。典型的なキットでは Figure.6 のように、Web ブラウザやアドオンの脆弱性に対する攻撃コードが用意されています。これを攻撃者が自ら用意したサイトや侵入して改竄した Web サーバーに仕掛けます。そして適切な対策を取っていないユーザーが閲覧すると、Drive by Download 攻撃によりマルウエアに感染することになります。
このような商用の攻撃キットの存在は、遅くとも 2006 年には確認されていますが、使いこなすためには専門的な知識が必要でした。2010 年に登場した Blackhole と呼ばれる攻撃キットは、専門的な知識がなくても使いやすいように設計されており、お金を払えばだれでもサイバー犯罪ができるようになりました。
サイバー犯罪で大きな収益を得る例も報告されており、たとえばランサムウエアの一種 Reveton を使った犯罪者グループは、攻撃キットを使って Reveton を感染させ、2012 年には$50,000/日の収益を上げていたと言われています。

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/20/fig6.png)

悪用される製品の推移

初期の攻撃キットは、様々な製品に対する攻撃コードが用意されていましたが、徐々に Adobe Flash/Reader, Microsoft Windows / Internet Explorer, Oracle Java 等の主要な製品に絞り込まれるようになりました。最近では、特に Java Runtime Environment(JRE)に絞り込まれ、攻撃キットに含まれる攻撃コードの約 3/4 が JRE の脆弱性を悪用するものになっています。

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/20/fig7.png)
（Java と Windows に関する線は、筆者が追記したもの）

攻撃キットは、Web ページだけが対象ではなく、様々なプログラムやコンポーネントに対する攻撃コードが含まれていますが、実際に検知された攻撃を見ると、JRE への集中傾向をより鮮明にみる事が出来ます（Figure.8)。
2013 年には、攻撃キットに関連して検知された攻撃のうち、84.6-98.5%を占めており、2 番目に検知されている Adobe Reader への攻撃よりもはるかに高い検出率になっています。Internet Explorer を含む 3 番目以降のプロダクトに対する攻撃は、すべてを合計しても平均すると 1.1%に過ぎませんでした。

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/20/fig8.png)

DEP や ASLR などのメモリ破壊への対策が進んだことで、Stack Overflow に代表されるようなメモリに関する攻撃が減少しています。メモリに関する攻撃は、2010 年には明らかに主要な攻撃対象でしたが、悪用が難しくなったことから、攻撃キットの主要な攻撃対象ではなくなっています。

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/20/fig9.png)

ガイダンス

脆弱性に対する攻撃が成功するためには、脆弱性のタイプ、製品のバージョン、攻撃コード作成者の能力、攻撃コードの開発の難易度など、多くの条件が整っている必要があります。逆に攻撃が成立する条件を消していくことで、攻撃の被害にあうリスクを効果的に軽減することができます。
ここでは、企業での利用、個人での利用に関わらず、攻撃によるリスクを減らすための効果的な手法をご紹介します。

常に最新を維持する（セキュリティ更新プログラムを迅速に適用する）

多くの場合、脆弱性に対する攻撃は、セキュリティ更新プログラムが公開された後に行われます。特に、広範囲な被害に結びつく攻撃キットでは、更新プログラム公開後しばらくしてから、該当する脆弱性への攻撃コードが組み込まれる傾向にあります。このため、セキュリティ更新プログラムを早急に適用することは、リスクを低減するための重要な対策と位置づけられます。

最新のバージョンのアプリケーションを利用する

Windows 8.1, Internet Explorer 11, Office 2013 は、悪用されている攻撃手法に対する効果的な対策が導入されています。これらの最新の製品を利用することで、主要な脅威を軽減することが可能です。
加えて、64bit 版の Internet Explorer 11 を利用し、拡張保護モードを利用することで、Internet Explorer に対する広範囲な脅威を軽減することができます。

マイクロソフトの製品に限らず、主要な製品のバージョンを確認するためには、IPA が公開している MyJVN バージョンチェッカーが便利です。

MyJVN バージョンチェッカーを利用するためには、Java のインストールが必要なのが難点ですが、主要なプログラムの最新版が利用されているかを確認でき、アップデートの方法についても解説されます。色々と調べるよりも、このツールで確認をするのが、一番簡単で確実だと思います。
Java の最新版がインストールされていても、古いバージョンが残っている場合があるのですが、このツールを使うことで、この問題も回避することが可能です。

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/20/myJvn.png)

（MyJVN バージョンチェッカー）

EMET(Enhanced Mitigation Experience Toolkit)を利用する

EMET は、すべてのサポートされている Windows 上で稼働し、アプリケーションを保護することが可能です。EMET に搭載された技術は、脆弱性の悪用を防ぐための最新の技術が実装されています。
いわゆるゼロデイ攻撃のケースでも、EMET を使うことで対処できる場合も少なくありません。日常的に利用するのが効果的ですが、ゼロデイ攻撃対策という観点からは、事前に EMET をインストールして最低限の保護をしておき、ゼロデイ攻撃が公表されたときに、該当するプログラムを EMET による保護の対象とする運用も効果が期待できると思います。

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/20/EMET1.png)

むすび

SIR はメインレポートだけでも 140 ページ、加えて Worldwide Threat Assessment, Regional Threat Assessment といった、詳細な分析資料が含まれます。膨大な分量があるので、なかなか通しで読むことは難しいのですが、丹念に読んでいくと、漠然と見ていた傾向の変化に対して、明確な要因が示されていることが少なくありません。
例えば、観測された攻撃コードの推移についても分析では、2013 年の第 4 四半期で大きく傾向が変化しています。SIR16 では、この変化は Blacole 関係者の逮捕により、更新が止まったことを要因としてあげています。
SIR16 では、マイクロソフト社内でのマルウエア対策の状況と、検知されたマルウエアに対する分析という、ちょっと興味深い内容も掲載しています。こちらについても、近日中にこちらの Blog でご紹介する予定です。

Next Post

Related Posts

How satisfied are you with the MSRC Blog?

Rating

Feedback * (required)

Your detailed feedback helps us improve your experience. Please enter between 10 and 2,000 characters.

Thank you for your feedback!

We'll review your input and work on improving the site.