エグゼクティブサマリー
- Orion ソフトウェアのビルドとコード署名のインフラストラクチャが侵害されたことの決定的な詳細を示しています。
- Orion のソースコードが悪意のあるバックドアを含むように直接変更されたことを確認するコンパイル結果を開示しています。
- バックドアされたOrionのソフトウェアパッチが、既存のソフトウェアリリース管理システムを介して配信されたことを確認する、ソフトウェア配信の成果物を開示しています。
- 将来のソフトウェアサプライチェーン攻撃を検出して防止するための新しいアプローチを提案しています。
概要
IT監視・管理ソリューションを製造するSolarWinds社が、巧妙なサプライチェーン攻撃の最新の標的となっています。2020年3月から6月にかけてリリースされた複数のSolarWinds Orionソフトウェアアップデートには、攻撃者が影響を受けたシステムに対して監視や任意のコマンドの実行を可能にするバックドアコードが含まれていることが判明しています。
ReversingLabsのこのサプライチェーン攻撃の解剖調査により、Orionソフトウェアのビルドおよびコード署名インフラストラクチャが侵害されていることを示す決定的な詳細が明らかになりました。影響を受けたライブラリのソースコードは、悪意のあるバックドアコードを含むように直接変更され、既存のソフトウェアパッチリリース管理システムを通じてコンパイル、署名、配信されました。
ソフトウェアのサプライチェーンに対するこの種の攻撃は決して目新しいものではありませんが、今回と異なるのは、可能な限り長く検出されないようにするために攻撃者が使用したステルスのレベルです。攻撃者は、影響を受けたコードベースに溶け込み、ソフトウェア開発者のコーディングスタイルや命名基準を模倣しました。これは、Orion ソフトウェアを使用するあらゆる組織のバックドアにするために追加されたかなりの数の機能によって一貫して実証されました。
ソフトウェア開発者からの隠蔽
事件の外部からストーリーをまとめることは困難です。しかし、残されたパンくずの痕跡から、攻撃者が Orion ソフトウェアのリリースプロセスを侵害するために使用した方法について、ある程度の洞察を得るには十分です。
このような調査は通常、既知のものから始めます。この場合、バックドアードされたソフトウェアライブラリのリストです。OrionプラットフォームソフトウェアパッケージのアップデートSolarWinds-Core-v2019.4.5220-Hotfix5.msp内のSolarWinds.Orion.Core.BusinessLayer.dllというファイルが、悪意のあるバックドアコードを含むことが知られている最初のバージョンです。このライブラリは、FireEyeの技術ブログで徹底的に分析されており、バックドアの動作について非常によく説明されています。
しかし、メタデータの分析から、攻撃者の忍耐力、巧妙さ、Orion ソフトウェアビルドシステムの状態について、さらなる結論を導き出すことができます。
FireEyeブログで概説されているように、悪意のあるバックドアコードを含む最初のバージョンは2019.4.5200.9083でしたが、攻撃者によって改ざんされた以前のバージョンがありました：2019年10月のバージョン2019.4.5200.8890で、このバージョンはわずかに修正されただけでした。悪意のあるバックドアコードは含まれていませんが、将来的にそれをホストする.NETクラスが含まれています。
この最初のコード修正は、明らかにコンセプトの証明に過ぎませんでした。彼らの三段階の行動計画 ビルドシステムを破壊し、独自のコードを注入し、署名されたパッケージが期待通りにクライアント側に表示されることを確認する。これらの目的が達成され、サプライチェーンが侵害される可能性があることが攻撃者自身に証明されると、攻撃者は実際の攻撃ペイロードの計画を開始しました。
クラスの名前である OrionImprovementBusinessLayer は、意図的に選ばれたものです。残りのコードに紛れ込むためだけでなく、ソフトウェア開発者やバイナリを監査する人を騙すためです。このクラスと、それが使用するメソッドの多くは、他のOrionソフトウェアライブラリにも含まれており、それらのライブラリ内のコードとテーマ的に一致していることさえあります。これは、ステルス性を保つ意図だけでなく、攻撃者がコードベースに精通していたことを暗示しています。
例えば、UserID を計算する関数を比較してみてください。Orion Client のコードでは、この関数はレジストリから以前に計算された値を読み込もうとしたり、ユーザの新しい GUID を作成したりします。
これを模倣して、攻撃者はこれらの関数の独自の実装を作成してUserIDも計算し、同じように名前を付けました。彼らの関数は、後に ID 型に同じ GUID 形式を使用していることさえあります。
正確ではありませんが、このコードはオリジナルと同じような機能を果たしています。クラス、メンバー、変数を適切に命名するパターンは、バックドアされたコードの至る所に見られます。
実際に、Orionクライアントライブラリのコードで使用されるCollectSystemDescriptionとUploadSystemDescriptionというメソッドがあります。IOrionImprovementBusinessLayer インターフェースがあったように、攻撃者はバックドアコードを配置したクラスの名前を模倣しました。
しかし、ライブラリに追加されたコードは、魔法のようにそれ自体が実行されるわけではありません。攻撃者は何らかの方法でそれを呼び出す必要があります。そして、それが行われた方法は、ビルドシステム自体が危険にさらされたことを物語っています。
赤くハイライトされたコードは、攻撃者が入れた追加機能です。この小さなコードブロックは、Orion ソフトウェアがバックグラウンドのインベントリチェックを実行している間に、バックドアを実行する新しいスレッドを作成します。このような場所は、この種のコードを追加するのに最適な場所です。つまり、攻撃者が注入した残りのコードと同様に、このコードも溶け込んでしまうのです。
.NET コードを逆コンパイルして新しいものを注入し、その後にコードを再コンパイルする方法もありますが、今回はそうではありませんでした。InventoryManagerクラスはソースコードレベルで修正され、最終的には通常のOrionソフトウェアのビルドシステムでビルドされました。
これは、バックドアされたバイナリのタイムスタンプ、同じパッケージ内の他のライブラリ、およびそれらを配信するパッチファイルを見ることで確認できます。
PE ファイルヘッダと CodeViews のタイムスタンプは完全に一致しています。これは、リビジョン番号が 1 に設定されているということは、 そのファイルが一度だけコンパイルされたか、あるいはクリーンビルドされたかを意味します。ファイルは署名され、タイムスタンプのために交差署名されているので、ヘッダ内のタイムスタンプを確実に検証することができます。クロスサインのタイムスタンプは、ビルド環境の外にあるリモートサーバによって制御され、改ざんされることはありません。
署名はライブラリのコンパイルから1分以内に発生しています。これでは、攻撃者がビルドシステムを監視し、バイナリを置き換え、これに完全に一致するようにメタデータを変更することができる時間がありません。これらのタイムスタンプを完全に一致させる最も簡単な方法は、攻撃者のコードをソースに直接注入し、既存のビルドシステムと署名システムに、Orionソフトウェア開発者によって定義されたコンパイルとリリースのプロセスを実行させることです。
最後に、MSP のパッチファイルには CAB アーカイブが含まれており、ライブラリのローカルの最終更新時刻を保持しています。これは、ビルドシステムがGMT+1タイムゾーンで動作していると仮定して、署名中にファイルが最終更新されたことを確認するものです。
同じ名前空間に属するバックドアされたライブラリの周囲のファイルも同時にコンパイルされています。これらのファイルは互いに依存していないので、ビルドシステムが完全なビルドを実行していない限り、同時にビルドされることはありません。
MSP のパッチファイルは署名されており、その署名時間はパッケージの内容と一致しているので、パッチファイルが残りのビルドと同じマシン上で作成されたことを確認できます。
大きな疑問は、ソースコントロールが侵害されたのか、攻撃者のコードがビルドマシンに置かれただけなのかということです。
残念ながら、それはメタデータでは明らかにできません。ソフトウェアのコンパイル中に保存されるような成果物はありません。しかし、攻撃者はコードがコードベースの中にあるように見えるようにするために、多くのトラブルを経験しました。これは確かに、ソフトウェア開発者による監査からコードを隠すために行われました。
確実なのは、ビルドインフラが侵害されたということです。さらに、デジタル署名システムは、信頼できないコードに署名することを余儀なくされた。現時点では、SolarWindsの証明書が他の悪意のあるコードの署名に使用されたという証拠はありませんが、その可能性は排除されるべきではありません。そして、予防措置として、そのビルドシステムで使用されたすべての証明書と鍵を失効させる必要があります。
セキュリティアナリストに隠れて
このような環境でオリオンのソフトウェアを実行している顧客のタイプを考えてみましょう。このようなソフトウェアのサプライチェーン攻撃を成功させるためには、攻撃者はレーダーを潜り抜け、何百万ドルものセキュリティ投資を回避する必要があります。攻撃者は、高度に専門化された検出ソフトウェアと、脅威を検出するためにそれを実行している人々を騙して、数ヶ月間、このソフトウェアを使用して積極的に異常を探し出す必要があります。このトリックを成功させるためには、攻撃者は隠れたままでいることと目的を達成することの間で適切なバランスを取る必要があります。
大規模なセキュリティ予算には、かなり多くの特典が付いています。内部脅威の調査ができることは、確かにその1つです。そして、脅威ハンターがデータの異常ほど探したがるものはありません。YARAルールは、ただ横たわっている奇妙なものを見つけるための一つの方法に過ぎない。
文字列 "Select * From Win32_SystemDriver "は、おそらくかなりの数の中に見られる。そのため、攻撃者は圧縮とBase64エンコーディングを組み合わせて、このようなノイズの多い文字列をすべて隠すことにしたのです。前述の文字列のBase64変種を探すハンティングルールがかなりの数存在するため、このような2段階のアプローチが必要でした。
これらのステップを逆にすることで、上で見つかったC07NSU0uUdBScCvKz1UIz8wzNooPriwuSc11KcosSy0CAA==は "Select * From Win32_SystemDriver "になります。そして、すべての脅威狩りのルールは、賢くないままです。
このような文字列難読化はコード全体で繰り返されます。これが、ソフトウェア開発者のレビューで目立つことと、セキュリティシステムを騙すことの間のバランスであり、攻撃者にとっては、この賭けが実を結んだことになります。
サプライチェーン攻撃の防止
ソフトウェアのサプライチェーンの安全性確保に重点を置いているセキュリティ企業はほとんどありません。ほとんどのセキュリティ企業にとって、この種の攻撃がもたらすリスクを減らすことについて話すことは、遠い未来の話です。多くの点で、私たちはまだ問題意識の段階にあります。このような事件は、ソフトウェアを出荷する側と消費する側にも同様に影響を与える多面的な問題であることに注意を喚起するのに役立ちます。
ReversingLabs の研究開発チームは、このような大きな問題が広く懸念される前に考えることに誇りを持っています。そのために、私たちはこのような問題に対処するための製品やソリューションのプロトタイプを数多く作ってきました。
ソフトウェアのサプライチェーンの保護は、解決が待たれている大きな問題です。そして社内では、開発者とユーザーの双方を保護するための製品戦略を定義しました。
私たちは、「ゴールド」ソフトウェアのリリースイメージをリリースや消費の前にスキャンできるシステムを想定しています。このシステムは、ソフトウェアの改ざん、デジタル署名、およびビルド品質の問題を探すために意図的に構築されています。このシステムは、継続的なソフトウェア開発とリリースサイクルに組み込まれており、これらの問題を表面化させ、それらを排除するためのガイダンスを提供することを目的としています。
このようなシステムの重要な側面の1つは、コンパイルされたソフトウェアのバージョン間の動作の違いをピンポイントで特定する能力です。静的挙動指標と呼ばれるこの記述は、基本となるコードの動作を、それを実行するマシンに与える可能性のある影響に変換します。
追加された（緑）コードと削除された（赤）コードの違いとしてレイアウトすると、ソフトウェアの動作の変化の影響が明らかになります。バックドアされたSolarWindsバイナリでは、これにより、このサプライチェーン攻撃をより早くキャッチすることが可能になったであろう多くのセキュリティアラームが発生します。
以下のリストでは、最初に改ざんされたバージョンと、悪意のあるバックドアコードを含むバージョンとの間の重要な静的コードの動作の変化を強調しています。
1. 1つ以上の実行中のプロセスに関する情報を読み取る
アプリケーションが突然、環境で実行中の他のプロセスを認識するようになることは、非常に珍しいことです。成熟したコードベースでは、この機能は通常メジャーリリースで追加されます。通常、この種のコードの背後には大きな機能が計画されています。そして、通常、追加するにはそれなりの理由があります: ある種のプロセス間通信や、実行中のプロセスを制御したいという願望です。他のシナリオでは、このような無計画な追加は懸念の原因となります。
2. MD5/SHA1 アルゴリズムの .NET Framework クラスへの参照が含まれています。
珍しいものではありませんが、MD5 や SHA1 のようなハッシュ化アルゴリズムは、特定の問題を解決するために実装されるのが一般的です。それは、ある種のコンテンツの検証、認証、または一意性のチェックのいずれかです。これらのそれぞれは通常、高レベルの要件にマッピングされ、機能変更のリクエストや同様の開発タスクまで追跡することができます。
3. kernel32.dll / advapi32.dllネイティブWindows APIへの参照が含まれています。
.NET ライブラリから突然 Windows ネイティブ API を参照するというのは非常に珍しいことです。システムと相互作用する基礎となるコードは、管理されたアプリケーションであっても必要ですが、より良い方法があります。例えば、提供されている言語ランタイムは、ほとんどの開発者がネイティブ関数に求めるものと同じ効果を、型の不確実性に対処することなく、一般的に達成することができます。サプライチェーン攻撃のコンテキストに関係なく、これ自体が開発者がコードの匂いと呼んでいるものです。
4. WMIを使用してシステム情報を列挙する
Windows Management Instrumentation (WMI) は、アプリケーションがローカルおよびリモートコンピュータシステムの状態に関する情報を取得することを可能にするシステム機能のセットです。IT管理者は、これらの機能を使用してコンピュータシステムをリモートで管理しています。なぜこのような機能が突然追加されるのかを理解することは非常に重要です。アプリケーションの範囲が劇的に変化して、リモート・コンピュータ・システム間の相互作用がその重要なタスクの一部になったということは考えられません。そして、ローカルシステムから何かを取得することが目的であれば、すでにその情報を持つコードがあるかもしれません。
5. ユーザー/アカウントの権限を列挙しています。
ユーザーやアカウントの権限を調べることは、通常、権限を昇格させるための最初のステップです。上昇した権限でコードを実行するのは、制限されたフォルダにファイルをコピーしたり、実行中のプロセスを操作したり、システムの設定を変更したりなど、限定されたアクションを実行するために行われます。これらのアクションはすべて、その背後にしっかりとした理由がなければならないものであり、成熟したコードベースに追加することは、少なくとも疑問の余地があります。開発者は、この種のことを認識し、サインオフしなければなりません。
6. システムのシャットダウンを妨害する
アプリケーションの不必要な特権というテーマに固執して、最後に大きな赤旗を掲げています。コンピュータをシャットダウンしたり再起動したりすることは、予期せずコードに追加されたものではありません。これは、複数のコードコンポーネント間の調整を必要とする機能であり、通常はアプリケーション内の単一の場所で実装されます。それが他の場所に現れることは、間違いなく懸念の原因となります。
ソフトウェアの展開プロセスのどの側にいるかに関わらず、ソフトウェアコードの変更の影響に関するレポートは、非常に貴重な情報です。ソフトウェア開発者にとっては、基礎となるコードの動作についての情報に基づいた意思決定を行うことができます。また、ソフトウェアの消費者にとっては、異常なコードの追加を確実に検出することができます。いずれにしても、このようなシステムの影響は、ソフトウェアのデプロイメントプロセスに大きな変化をもたらします。このようなソフトウェアサプライチェーン攻撃が再発しにくくなる検証バリアとしての役割を果たします。
新しい制御機構の必要性
SUNBURSTは、アクセス、洗練された技術、忍耐力を武器とした次世代の危殆化対策を紹介しています。貴重なビジネスを運営している企業や、顧客にとって重要なソフトウェアを製造している企業にとって、ソフトウェアを検査し、改ざんの兆候がないか、悪意のあるものや不要なものが追加されていないか、アップデートを監視することは、リスク管理プロセスの一部でなければなりません。この種の改ざんは、従来のセキュリティソフトウェアスタックで信頼されているソフトウェアディストリビューションを悪用するもので、既知の悪意のあるインプラントと比較しても特異なものです。ディストリビューションは、たとえ境界制御によっても、容易に検査することはできませんでした。世界的に知られたソフトウェアブランドや、信頼されたビジネスクリティカルなプロセスの背後に隠れていることで、フィッシング・キャンペーンでは夢のようなアクセスが可能になります。
NIST CSFなどのサイバーセキュリティフレームワークの多くは、継続的なリスク管理とデータとソフトウェアの検査の必要性を文書化しています。これには、社内外を問わず、すべてのサードパーティ製およびオープンソースのソフトウェアを継続的に検査し、改ざん、悪意のあるコンテンツ、または組織の許容ポリシーに抵触する望ましくない特性がないかどうかを確認する必要性も含まれています。