XZバックドア事件 - 初期分析結果

 (securelist.com)
2 ポイント 投稿者 GN⁺ 2024-04-13 | 1件のコメント | WhatsAppで共有

  • Timeline of events:

    • 2024.01.19: XZ website moved to GitHub pages by a new maintainer (jiaT75)
    • 2024.02.15: "build-to-host.m4" is added to .gitignore
    • 2024.02.23: Two "test files" containing malicious script stages are introduced
    • 2024.02.24: XZ 5.6.0 is released
    • 2024.02.26: Commit in CMakeLists.txt sabotaging the Landlock security feature
    • 2024.03.04: Backdoor causes issues with Valgrind
    • 2024.03.09: Two "test files" are updated, CRC functions modified, Valgrind issue "fixed"
    • 2024.03.09: XZ 5.6.1 is released
    • 2024.03.28: Bug discovered, Debian and RedHat notified, Debian rolls back XZ
    • 2024.03.29: Email published on OSS-security mailing list, RedHat confirms backdoored XZ shipped
    • 2024.03.30: Debian shuts down builds and starts rebuild process
    • 2024.04.02: XZ main developer recognizes the backdoor incident

  • 悪意あるバックドアが含まれたXZ配布版のハッシュ値:

    • xz-5.6.0: MD5、SHA1、SHA256ハッシュ値が提供されている
    • xz-5.6.1: MD5、SHA1、SHA256ハッシュ値が提供されている

初期感染分析

  • Stage 1 - 改ざんされたbuild-to-hostスクリプト:

    • リリース用ソースファイル自体は当初無害だったが、攻撃者が制御するURLからダウンロードした場合、悪性コードを実行する build-to-host.m4 ファイルが含まれていた
    • この .m4 ファイルはビルド中に実行され、テストフォルダに追加された最初のファイルを改変して展開する

  • Stage 2 - 注入されたシェルスクリプト:

    • .m4 ファイルによって注入された悪性スクリプトは、Linux上で意図されたビルドプロセス内で実行されているかを確認する
    • good-large_compressed.lzma ファイルを使って次の段階を実行するが、これは通常どおり圧縮されている一方、展開後のデータ内部にはゴミデータが含まれている
    • head/tail コマンドで33,492バイトを抽出し、tr コマンドで基本的な置換を適用して難読化を解除する

  • Stage 3 - バックドア抽出:

    • 最終段階のシェルスクリプトは、想定された環境で実行中かどうかを確認するために複数の検査を行う
    • 同じ good-large_compressed.lzma ファイルの別オフセットに隠されたバックドアのバイナリコード本体を抽出する
    • XZツールでファイルを抽出し、一連の head 呼び出しによってRC4類似アルゴリズムを使ってバイナリデータを復号する
    • 圧縮ファイルをXZで展開し、predefined値を使って先頭バイトを削除した後、liblzma_la-crc64-fast.o として保存する
    • crc_x86_clmul.h の is_arch_extension_supported 関数を修正し、__get_cpuid 呼び出しを _get_cpuid に変更する

バイナリバックドア分析

  • ステルスローディングのシナリオ:

    • XZはCRC計算に lzma_crc32、lzma_crc64 関数を使用しており、ELFシンボルテーブルにはIFUNC型として格納されている
    • 最適化版を使うかどうかを動的に決定するためにIFUNCが使われている
    • バックドアはオブジェクトファイルとして保存され、主な狙いはコンパイル時に main 実行ファイルへリンクされることにある
    • オブジェクトファイルには _get_cpuid シンボルが含まれており、元のソースでアンダースコアを1つ取り除くことで、コードが _get_cpuid を呼ぶと実際にはバックドア版が呼ばれるようになる

  • バックドアコード分析:

    • 初期バックドアコードは2回呼び出され、実際の悪性活動は lzma_crc64 IFUNCが _get_cpuid を呼ぶときに始まる
    • GOTアドレスを見つけて cpuid ポインタの位置を特定し、main の悪性関数ポインタに置き換える
    • 感染システムへのすべての接続を監視できるよう、特定の関数をフックすることが主な目的となっている

  • 核心的な動作:

    • RSA_public_decrypt、EVP_PKEY_set1_RSA、RSA_get0_key などの libcrypto 関数をフック対象としている
    • 現在のプロセスが実行条件に合致するかを検査し、kill switchの存在を確認する
    • Trie構造を使って文字列演算を行う
    • 3つ以上のsymbol resolverルーチンを使ってELF Symbol構造体の位置を見つける
    • rtdl-audit 機能を悪用し、symbol resolvingルーチンをハイジャックすることで関数フッキングを実現する

GN⁺の意見

  • この記事は、オープンソースソフトウェアにマルウェアが注入された非常に巧妙な攻撃事例をよく示している。オープンソースの利点が逆に悪用され得るという教訓を与える。

  • Linuxシステムを狙うサイバー攻撃とバックドアはますます高度化している。特にSSHサーバーを通じた攻撃は深刻なセキュリティ脅威になり得る。

  • 一方で、オープンソース生態系の自浄能力も示している。最終的にバックドアはコミュニティによって発見され、迅速に対応された。透明性が鍵だ。

  • 高度なTrieデータ構造、Symbol Resolver、dl_audit フッキングなどの技法が使われたことは、Linuxマルウェアの技術的進化を示している。Linuxシステムのセキュリティにも特別な注意が必要だ。

  • 企業がオープンソースソフトウェアを導入する際は、ライセンスだけでなくセキュリティ面の検証も必須だ。信頼できる配布元かどうか、コードに対する継続的な監視が行われているかを必ず確認すべきである。

関連記事

1件のコメント

 
GN⁺ 2024-04-13
Hacker News の意見

要約:

  • 攻撃者が検知を回避するためにスクリプトとコードへ多大な労力を注いでいたことを考えると、このプロジェクト全体は、ピボットや同時進行する複数の取り組みに対する代替として機能し得る
  • SSHD に焦点を当てることで、システム全体の他の部分や技術的・社会的側面への影響を見落とす可能性があることを考慮すべき
  • 各動的リンクライブラリが独自の GOT を持ち、動的リンク完了後にそのテーブルを読み取り専用としてマークすることは、有用なハードニング手順になり得る
  • ソースコードは、逆アセンブラを実行してコードの動作を理解し、その後すべてを説明的な名前に置き換える形で生成されたように見える
  • バックドアのバグによって発生した SSH の遅延や低速化が最終的に露見につながったが、これについての分析が行われたのか気になる
  • xz リポジトリが GitHub に再び現れ、メンテナたちは ifunc サポートの削除やテストファイル生成コードのコミットなど、整理作業を進めている
  • 人々が発見できていないバックドアはまだ多くあるのではないかという想像と、この件のように見過ごされているものが存在しないことを願う気持ち