メモリー破損の脆弱性を超えて ―セキュリティの絶滅とこれからのエクスプロイト

Chintan Shah 著 - 2022 年 1 月 24 日

最新のエクスプロイト技術によって、攻撃の側が攻撃戦略を実行する方法が変わり、防御する側が脆弱性からエクスプロイトまでの経路を分析する手法も変わってきています。過去 10 年間、オペレーティング システム全体とアプリケーションの両方のセキュリティを強化することに重点的に取り組んできた結果、いくつかのエクスプロイト対策の導入が著しく進展しました。その進展によって、場合によってはメモリー破損の脆弱性というクラス全体が徐々に解消されています。たとえば、Use-After-Free (UAF) は、Web ブラウザーのような大規模で複雑なコードベースでごく頻繁に見られるクラスの脆弱性です。エクスプロイトが容易なため、Microsoft はブラウザー エンジン (mshtml.dll) で孤立ヒープと遅延のないオブジェクトを導入し、UAF エクスプロイトの連鎖を排除しました。そのため、攻撃者はその障害に対処し、エクスプロイトを再設計せざるをえない状況に追い込んだのです。以下の図 1 は、UAF 脆弱性を緩和するために導入されたコードの一部を示しています。

保護されているコードと保護されていないコードの違いがおわかりになると思います。これは氷山の一角にすぎませんが、攻撃者は特定のタイミング制約やメモリーしきい値に対処しなくてはならないため、UAF 脆弱性のエクスプロイトはかなり困難になりました。次に示す図 2 は、過去 10 年ほどの間に導入された、Windows OS に対するメモリー エクスプロイトの対策をわかりやすく視覚化したものです。

にもかかわらず、こうしたエクスプロイト対策が、導入後ほどなくしてバイパスされてしまうということが何度も起こっています。主な理由は、依存性のあるコードやサードパーティのコードも含めてあらゆるコードが、コンパイラーで有効になったはずの対策と互換性がない、あるいは対策を実装してコンパイルされていないことでした。つまり、エクスプロイト対策が適用されていないコードがある、あるいは対策自体が完全には実装されていないために複数の抜け穴が存在し、それがエクスプロイトの余地を残していたということです。たとえば上の図を見ると、アドレス空間レイアウトのランダム化 (ASLR) は最初から完全にではなく段階的に実装されていたため、コードの多くが依然としてバイパスに対して脆弱であったことがわかります。

メモリー破損の脆弱性は過去のものになるか

メモリー破損の脆弱性は、今もなお報告の絶えないバグのひとつですが、OS でもクライアント側アプリケーション (スクリプト エンジンなど) でもエクスプロイト対策が導入されているため、メモリー破損の脆弱性を武器として十分なエクスプロイトに変えるのは、最近では困難になっています。メモリー破損の脆弱性を、任意のコードを実行できる本格的なエクスプロイトに変えるには、エンドポイント セキュリティ ソリューションによる保護や検出を受けることなく、いくつもの対策をバイパスしなければなりません。つまり、攻撃者はエクスプロイト対策バイパスの研究に膨大な労力と時間、コストを費やす必要があるということです。また、ターゲット システム上で効果的なエクスプロイトを実行しようとすれば、複数の脆弱性を連鎖させなければならない場合も多いので、開発コストが大幅にふくらみ、エクスプロイトのハードルは高くならざるをえません。

私たちは、将来的に攻撃者が関心を持つ脆弱性クラスの性質を決めるうえで、エクスプロイト対策のこうした進化が特に重要なものになると考えています。そうなると、「メモリー破損の脆弱性は根絶されるのか?」という質問は議論の余地があり、それなりの考察が必要になってきます。

これからのエクスプロイト戦略 - その先にあるものは何か

メモリー処理が適切でないコードがアプリケーションに存在する限り、メモリー破損の脆弱性はアプリケーションに存在し続けます。それでも、このクラスの脆弱性によってエクスプロイトが起こる強さと頻度は、徐々に下がっていくでしょう。過去には、攻撃者がメモリー破損の欠陥を突いて任意のメモリー読み書き (R/W) を達成し、それを基本にしてアプリケーション メモリーにおける特定のフラグやデータを書き換えてコードの実行につなげるというエクスプロイト手法の事例も数多く目撃されています。こうした手法は「データのみの攻撃」と呼ばれ、多くのエクスプロイトで見られる比較的容易な手法でした。最終的には、メモリーで重要なデータ構造の位置をランダム化することで、このような性質の攻撃は減らすことができました。

機能の豊富なアプリケーションを狙うとなると、攻撃者はターゲット システムでコードを実行できる、少しでも簡単な方法を常に探索しています。インターネットに接続されているレガシー システムのなかには、対策の導入が甘いために攻撃者がなんの苦もなく侵入できてしまう経路が、必ず存在します。ただし、この方向をもっと推し進めようと思えば、アプリケーションやネットワーク プロトコルに存在する機能上または設計上の欠陥を悪用するのもひとつの方法です。攻撃者が、ターゲット アプリケーションに固有の設計や機能を悪用する、たとえばメモリーの明示的なオーケストレーションなしにアプリケーションやサービスを攻撃者の制御下にあるマシンに接続させるなどの方法を見いだした場合、リモート コードの実行は比較的容易になります。しかも、エクスプロイトされたプロセスによって実行する任意のコードの機能は攻撃者の思いのままなので、狙われたマシンに大混乱をもたらします。以下の図 3 は、ここ数年のエクスプロイト戦略の進展を単純な形で表したものです。

ここ数年、データのみを対象とする攻撃や、アプリケーションの機能上/設計上の欠陥を悪用する攻撃が何度も目撃されてきました。そうした攻撃には、従来のメモリー破損のエクスプロイトと比べていくつもの利点があり、以下にあげる理由から、今後のエクスプロイト戦略として注目されると考えられます。

• エクスプロイト対策をバイパスできる可能性を秘めているため、攻撃者はその障害に対処するためにだけにエクスプロイトを設計しなくて済む。
• 任意のコードが、エクスプロイトのあったプロセスの特権で実行されるため、特権の昇格を引き起こせる。
• アプリケーションに固有の機能上または設計上の欠陥を利用するエクスプロイトであれば、脆弱性のエクスプロイトに先立って明示的なメモリー操作やスペース制約に対処する必要がない。そのため、メモリーにシェルコードをインジェクトしたり、昔ながらのスタック ピボット技法を使用したりしなくて済む。
• 脆弱性を武器にする開発/維持のコストと時間が少なくなり、脆弱性のエクスプロイトが比較的容易。

これまでの何回かの四半期に見られた深刻な脆弱性を振り返ると、これからの攻撃がどんな形になるのかについて、明確な手がかりを得ることができます。以下の各セクションでは、ごく最近発生して影響の大きかった脆弱性をいくつか取り上げながら、サービスやアプリケーションにおける機能上/設計上の欠陥がどう悪用され、あまり抵抗されることなくコード実行や機密情報漏えいが実行されてきたかを見ていくことにします。

CVE-2021-44228 - Apache Log4j2 ロギング ライブラリの脆弱性によるリモート コードの実行

Apache のロギング ライブラリである Log4j で報告されたこのリモート コード実行 (RCE) の脆弱性は、近年報告されたなかでは特に大きな欠陥のひとつです。攻撃者は、Log4j ロギング ライブラリを使用してテキスト メッセージをログに記録している脆弱なサーバー上で任意のコードを実行できるようになります。前回のブログでは、オープン ソース ソフトウェアが現代のソフトウェア開発の構成ブロックとしていかに重要な役割を果たしているか、そしてそれを使用している製品にはどんな脆弱性でも大きな影響を与えるため、それを監査することがいかに重要かということを、詳細にわたって解説しました。

Log4j の脆弱性は、jndimanager クラスの Lookup メソッドに存在します。When the JNDI URL is included in the request message parameter to be logged by log4j, the apache\logging\log4j\core\lookup\JndiLookup.lookup () method is called with the JNDI URL which in turn calls the net\JndiManager.lookup () method as shown in figure 3 below, leading to the initiation of the remote JNDI lookup to the attacker controlled server. こうすると、攻撃者の制御下にあるサーバーは、レスポンスで悪意のある JNDI 参照を送信して、脆弱なサーバー上で任意のコードを実行できるようになります。

このような RCE が可能になるのは、Java が LDAP、DNS、RMI、CORBA などさまざまな JNDI (Java Naming and Directory Interface) サービス プロバイダーを実装しているためです。また、デフォルトのシステム プロパティ設定によっては、リモート クラスの読み込みも可能でした。

CVE-2021-44228 は機能エクスプロイトの典型的な例です。ここで悪用されたのは、ルックアップをサポートする「ルックアップ置換」という機能でした。ルックアップとは、ログ メッセージに値を追加する方法です。その値は通常、定義されたマップを使用して、あるいは StrSubstitutor クラスや StrLookup クラスなど実装されているインターフェースを介して実行時に解決される変数名です。

Log4j は、プロパティ構文 "$\{prefix:name}" をサポートしており、prefix は、変数名を特定のコンテキストで評価する必要があることを Log4j に指示します。JNDI コンテキストは、以下のように Log4j に組み込まれています。

Log4J バージョン 2.14.1 およそれ以前のバージョンでは、デフォルトで JNDI ルックアップが有効になっていました (上の図 6 を参照)。そのため、サーバーに記録される HTTP リクエスト ッダーのパラメーター値として渡される JNDI 参照をライブラリが識別してしまい、攻撃者が悪意のある JNDI 参照を HTTP リクエスト パラメーターにインジェクトすることによってリモートで Java コードを実行できる可能性があります。

CVE-2021-34527 - Windows 印刷スプーラー サービスの脆弱性によるリモート コードの実行

spoolsv.exe に存在した特権的なリモート コード実行の脆弱性、いわゆる PrintNightmare も、昨年報告されたもうひとつの重大な脆弱性でした。プロトコルにおける設計上の欠陥を悪用すると、メモリーを操作することなくターゲット マシン上で任意のコードを実行できるということを示す格好の例となっています。

この脆弱性は、SMB を介して RPC を呼び出すことによって、Print System Remote Protocol (MS-RPRN) および Print System Asynchronous Remote (MS-PAR) プロトコル上でエクスプロイトされていました。スプーラー サービスで印刷サーバー コンポーネントの実装に存在していた以前からの設計上の欠陥を悪用するエクスプロイトでした。ターゲット システムにプリンター ドライバーをインストールするために MS-RPRN および MS-PAR インターフェースに対して RPC リクエストを行うときに発生します。RpcAddPrinterDriverEx (MS-RPRN Opnum 89) または RpcAsyncAddPrinterDriver (MS-PAR Opnum 39) への RPC コールを実行するには、DRIVER_CONTAINER 構造体を引数として渡す必要があります。

上図の詳細な構造に示すように、DRIVER_CONTAINER には、pDriverPath と pConfigFile が含まれています。それぞれ、プリンター ドライバーと構成モジュールを含むファイル名のフルパスです。任意のコードが読み込まれないように、pDriverPath も pConfigFile も UNC パスが指定されているかどうかをチェックされます。

このコードの設計上またはロジック上の欠陥は、プリンター データを含むファイルのフルパスである pDataFile に、同じ UNC パス チェックが適用されていないことです。攻撃者は、RpcAddPrinterDriverEx に対して、以下のように複数の呼び出しを実行できます。

1. ターゲット マシンにアクセスできる悪意のある DLL の UNC パスを指定した pDataFile を指定する。これに成功すると、悪意のある DLL がターゲット マシンのローカルにコピーされる。
2. コピーされたファイル名を pConfigFile に割り当てられた同じ API を指定する (このときは悪意のある DLL がローカル パスになる)。これで、印刷スプーラー サービスによって悪意のあるコードが読み込まれる。

CVE-2021-36942 - Windows に存在する LSA なりすましの脆弱性による認証情報の漏えい

SMB を介した RPC は常に、数々のエクスプロイト手法の最前線にありました。この脆弱性のエクスプロイトは、MS-EFSRPC プロトコルを再度悪用することで実行されます。MS-EFSRPC は、Windows でリモート システム上のファイルを管理する際に使用されるプロトコルであり、暗号化ファイル システム (EFS) を使って暗号化されています。

LSARPC インターフェース上で EfsRpcOpenFileRaw などの特定の RPC 呼び出しを実行することで、攻撃者は Windows ホストで別のサーバーを認証させることができます。つまり、ターゲット サーバーが NTLM 認証を介して、攻撃者の制御下にあるサーバーを認証するように誘導できることになります。さらに重要なのは、事前の認証なしに RPC コールを使用して LSARPC を発行できることです。このターゲット サーバーが Active Directory (AD) である場合、攻撃者は NTLM 認証を目的として、そのマシン アカウントを使用して AD を任意のサーバーに接続させることができます。この EFSRPC プロトコルを悪用すると、企業ネットワーク内の複数の脆弱性を連鎖的に悪用して、NTLM 認証情報を攻撃者の制御下にあるサーバーにリレーしてその中を横移動できるようになり、最終的にはドメインの完全な侵害につながる可能性もあります。

Active Directory Certificate Services (AD CS) 機能がインストールされ、NTLM over HTTP 認証を使用するように設定された IIS Web サーバーを攻撃者が管理している場合、Active Directory を IIS に認証されると、NTLM 認証情報が攻撃者に漏えいし、ドメインのセキュリティが完全に侵害されてしまいます。NTML リレー攻撃は目新しいものではありませんが、このようなプロトコルの悪用を防ぐために、Kerberos のような認証メカニズムで安全性を強化することが推奨されます。

要約すると、プロトコルや機能を悪用して重要な資産を外部の攻撃者のサーバーに接続されてしまうと、CVE-2021-44228 (Log4J の脆弱性) でも見られたように、危険な結果をもたらしかねないということです。

CVE-2021-40444 - Windows MSHTML の脆弱性によるリモート コードの実行

これも、昨年エクスプロイトのあったもうひとつの重大な脆弱性です。単純な機能の悪用をロジックの欠陥と結び付けると、任意のコード実行をいかに簡単に実現できるかということを示す好例でした。まず、ドキュメントを外部の OLE オブジェクトにリンクするために、OLE (Object Linking and Embedding) が使用されました。歴史的に見ても OLE は、Office のエクスプロイトを武器として構築するうえで重要な役割を果たしています。相互運用性に対処するために特別に設計された Microsoft Office ファイル形式のコア機能のひとつなので、今後も同じようなことは起こるでしょう。

Microsoft Office Open XML 仕様により、文書に内部または外部のオブジェクトを埋め込んだり、オブジェクトへのリンクを指定したりでき、特に外部 OLE オブジェクトへのリンクは、リレーションシップを介して指定されます。以下に用意したエクスプロイト文書にもあるように、document.xml.rels ファイルは Type 属性が "oleObject"、Target 属性が OLE オブジェクト リンクに設定され、TargetMode が external に設定されています。そのため、ここで用意した文書は、外部でホストされている悪意のあるオブジェクトにリンクし、それぞれのプロトコル/リソース ハンドラーを呼び出してそのオブジェクトをレンダリングしたうえで、そのハンドラーで論理上/設計上の欠陥をエクスプロイトできる可能性があります。これが、過去にも多くの OOXML エクスプロイトで使用されてきた OOXML テンプレート インジェクションという手法の典型です。OLE のエクスプロイトについては、以前のブログ記事で詳しく紹介しています。

HTML コードの処理は mshtml.dll で行われ、HTTP プロトコルと MSHTML ダウンロードの信頼性検証と処理は urlmon.dll で行われます。urlmon.dll コードにおける設計上の欠陥は、ダウンロードした CAB ファイルの抽出と信頼性の検証に関連するものでした。CAB ファイルは、上の図 11 のように、side.html ページに埋め込まれた Javascript (JS) コードを介してダウンロードされました。CAB ファイルの抽出時にパスのエスケープ チェックが行われなかったため、エクスプロイトは CAB ファイルに含まれるファイルを図 12 のような相対パスで抽出できてしまったのです。その結果、作成された TEMP ディレクトリの外に悪意のあるペイロードがドロップされ、ドロップされたペイロードが最終的に実行されてしまいます。

まとめ

以上に解説した CVE-2021-44228、CVE-2021-34527、CVE-2021-36942、CVE-2021-40444 のように、処理上の固有の欠陥を利用し、機能の悪用を中心とする脆弱性は、ここ数年で増加する傾向にあります。メモリー破損の欠陥は、Rust を除く非メモリー セーフな言語で書かれた安全でないコードが存在する限り、これからも拡散し続けると思われますが、これからのエクスプロイトの傾向は、設計または論理上のエクスプロイトや、プロトコル悪用の方向に進むと考えられます。攻撃者は、最近成熟してきたメモリー エクスプロイト対策の縦深防御すら気にすることなく、ネットワーク内を横移動するというシステム ベルの初期目的を達成できるため、消費者もオープン ソース ソフトウェアの開発者も、こうした欠陥には今まで以上に警戒する必要があります。