XZバックドア：「認証バイパスではなくRCEであり、ゲート付きで再生不可能」
(bsky.app)- xzバックドアのリバースエンジニアリング予備分析によると、この挙動は単なる認証バイパスではなく、リモートコード実行（RCE）に近い
- フックされた
RSA_public_decryptが、サーバーのホストキーの署名を固定のEd448キーで検証する流れが中核 - 署名検証を通過すると、ペイロードが
system()に渡され、実行される可能性がある - 分析は許可を得て共有された予備結果であり、Bluesky投稿には引用投稿または埋め込みコンテンツが含まれる
- バックドアはゲート付きで再生不可能な形式と要約され、同じ入力を単純に再利用する攻撃とは異なるものとして見る必要がある
xzバックドアの実行フロー
- 許可を得て共有されたリバースエンジニアリングの予備分析は、フックされた
RSA_public_decryptに焦点を当てている- サーバーのホストキーに対する署名を固定の
Ed448キーで検証する - 検証後、ペイロードを
system()に渡す
- サーバーのホストキーに対する署名を固定の
分類と制約
- この挙動は認証バイパスではなく、**リモートコード実行（RCE）**に分類される
- バックドアはgated/unreplayableな特性を持つものと要約されている
- 元のBluesky投稿には、引用投稿または他の埋め込みコンテンツが含まれる
1件のコメント
Hacker News の意見
この件についての追加リバースエンジニアリング結果がある。バックドアが文字列を隠すために使っていた prefix trie から抽出したシンボル再マッピング情報が含まれており、リバースエンジニアリング／分析そのものからも隠れようとしていたように見える
https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9...
デコードされた文字列の完全な一覧はここにある
https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01
OpenSSL の内部に詳しくない立場から見ると、N 値は
rsa_stのnフィールドから取得しているようだhttps://github.com/openssl/openssl/blob/56e63f570bd5a479439b...
この値は
BIGNUMで、可変長型に見えるhttps://github.com/openssl/openssl/blob/56e63f570bd5a479439b...
バックドアはリモート攻撃者から受け取った証明書からこの値を取り出してChaCha20で復号を試み、成功すると
system()に渡す。system()は、現在のプロセスが実行されているユーザー権限でシェルスクリプト 1 行を実行する単純なラッパーに近いもし正しく理解できているなら、これは公開鍵バイパスよりさらに悪い。公開鍵バイパスなら理論上はログインしようとしているユーザーの権限しか得られず、強化された SSH 設定では root ログインが禁止されている可能性が高い
しかしこれは
sshdプロセス自体のコンテキストでのリモートコード実行なので、root で動作しているsshdならペイロードも root として実行されうる。広範にばらまかれたリモートコード実行としては、現実的にほぼ最悪に近いこのバックドアが性能問題のせいで見つかったのでなければ、後になって発見される可能性はどれほどあったのだろうか。性能問題はコード上のミス／修正可能な欠陥だったと理解しているが、それを捉えられるツールがあったのかも重要だ
こうした問いは、この種のバックドアが初めてなのか、それとも初めて表面化しただけなのかを理解することにも関わってくる
小さなミス一つで全てが崩れることがあり、ときには一文だけで連鎖反応が始まり、緻密に組まれた計画が露見する
犯罪捜査は毎日そうやって進む。警察業務にはリソース制約があるが、ソフトウェアは趣味で分析する人、趣味のように分析し続ける専門家、職業として分析する専門家たちに毎日見られている
結局のところ、いつかは発見されていた可能性が高い
XZ 攻撃は非常によく実行されており、ほとんど傑作に近い。国家機関が関与していても驚かない。しかし同時に、とてつもなく運が良かった。今問題として挙がっているもののどれか一つでも見つかっていたら、私だけでなく多くの同僚が長期の追跡に入っていただろう
導ける結論の一つは、xz/liblzma がオープンソースでなかったら、こうした問題を見つけるのは不可能だっただろうという点だ。もちろんオープンソースだったからこそそもそも可能になった面もあるが、これが Windows や MacOS の中にあったと想像してみればよい
ただし使わなければ目的を達成できない。使えば使うほど、後から検出される可能性も高まる。SolarWinds と比較できる
個人的には
system()呼び出しはやや雑で、バイナリ機能スキャナーがその経路を潜在的に見つけられたかもしれないと思うsshdパッチは許容される段階であるリンク時に発生し、この分析が正しいならマスターキーバックドアでもないので、通常のログイン監査の痕跡は残らない。そしてsshdが別プロセスを起動すること自体は当然許容されうる非常に厳密な SELinux ポリシーであれば、
sshdがシェル以外の何かを実行することを検出できたかもしれないが、そのレベルの強化は非常にまれだろう対象の外側から発見するという問題もすでに試されたと言える。複数の人が
valgrindなどでペイロードを調べたが、見つけられなかった。デバッグ環境で見つからないようにする防御もかなり巧妙だ。ペイロードの下にある露出したインフラが ASan のようなツールと互換性がないからだたとえリンクされていても、コードは
main()よりはるか前に実行されるため、デバッガでliblzma周辺を探っても通常は実行場面を観測できないstraceならプロセス生成後のすべてのシステムコールとリンカーの動作を見られる。しかし、ここまでの理解では、ペイロードはその段階で有効化可否を決めるためにシステムコールを使ってはおらず、argvやenvironなどを見ているようだ[0] https://en.wikipedia.org/wiki/PWB/UNIX
[1] https://news.ycombinator.com/item?id=38020792
バイナリペイロードの中にエンコードされた文字列があるように見える
https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01...
この文字列はキルスイッチとして動作する
https://piaille.fr/@zeno/112185928685603910
本当にそうなら、緩和策の一つは次のようになるかもしれない
-aを含める必要がある。そうしないと環境ファイルを消してしまうおそれがある。そして通常は、悪意のあるコードが含まれていないバージョンへアップグレードして再起動するのが正しいバックドアが正確に何をするのか、簡単に説明できる？ まだ分かっている段階なのか？ バックドア自体がペイロードではないように思えるが、悪意ある圧縮ファイルが必要なのか、それとも
sshdプロセスにフックしてリモート攻撃者の悪意あるパケットを待ち受けるのかが気になる元の文は、攻撃者が SSH セッションの認証前段階で悪意あるペイロードを送れるようにも読めるが、なぜエクスプロイトが永遠に出てこないかもしれないと言われているのかも分からない。コードをリバースエンジニアリングできるなら、概念実証も書けるのでは？
結局のところ、攻撃者はこのバックドアのあるマシンをどうやって制御するのか？
ここでの状況も似ている。xz は怪しい動作をする前に、あるデータを復号しようとする。非対称方式なので、秘密の暗号鍵を提示しなくても復号の検証はできる。対応する公開鍵を持っているからだ
秘密鍵を見つけるのは現実的には不可能で、ペイロードの復号に失敗しても目に見えて異なる動作をしないため、エクスプロイトコードは永久に公開されないかもしれない。エクスプロイトコードを作る方法は秘密鍵が何らかの形で見つかることだけで、現実的にはバックドア開発者が漏らす場合しかない
sshdが起動し、libsystemdをロードし、それがハッキングコードの入った XZ ライブラリをロードするXZ ライブラリは RSA 署名を検証する OpenSSL 関数の独自版を注入する
誰かが SSH にログインし、認証用の署名付き SSH 証明書を提示すると、その改変された関数が呼び出される
証明書には通常のログイン処理でユーザー名やロールのようなアサーション情報が入ることがあり、その情報で特定ユーザーのログインに有効な証明書かどうかを判断する。だが改変された関数が特定の攻撃者鍵で署名された証明書を検知すると、証明書の下位フィールドの一部を取り出してシステムコマンドとして実行する。実行コンテキストは
sshd、つまり root ユーザーだ残念ながら攻撃者の署名鍵は分かっておらず、ハッキングコードが検証に使う公開鍵しか分かっていない。要するに、攻撃者は感染したシステム上でroot として任意のコマンド実行ができ、痕跡はせいぜいログイン失敗の試行程度だろう。インターネットに公開されたシステムなら、そうした試行はもともと大量にある
攻撃者の鍵署名が必要だという点が核心だ。その鍵が漏洩するか、RSA アルゴリズムが破られない限り、他の研究者や第三者がこのバックドアを悪用することはできない。RSA が破られるなら、それよりはるかに大きな問題が起きる
現時点では攻撃者だけがエクスプロイトを実行できるため、スキャンも不可能だ。性能低下のような二次的影響を除けば検出は難しく、実際そのように発見された
これほど多くの Linux サーバーで毎日使われる重要なパッケージが、資金不足のせいで元の作者に維持できなくなるというのは理解しがたい。オープンソースでは何かを変える必要がある
一つの解決策は、一定規模以上の企業や事業者にメンテナンス費用の支払いを義務づけるライセンスかもしれない
そのためベンダーには、オープンソースを安全に保つインセンティブが生まれる。メンテナーに資金を出したり、コード監査を依頼したり、正社員を雇って貢献させたりする形だ
現在 xz リポジトリに行くと、GitHub 利用規約違反で無効化されている。無効化自体は当然だが、GitHub にはコードと履歴は残し、バナーを表示しつつ悪用可能な機能だけ止めてほしい
そうすれば研究者や他の人たちがエクスプロイトを学べる。もっと些細な状況でライブラリがマルウェアをホストしていてリポジトリが落とされると、単なる些事として見過ごされかねない
ソースコードに関心があるなら見つけるのは難しくない。このコードと Git リポジトリは世界中の複数の Git リポジトリにつながっており、リリースにも何度もソースが同梱されている
あまり知られていないオープンソースゲームの事実上のメンテナーとして、開発者が出入りするのを見てきた。価値のある貢献は基本的にすべてマージしている
協力者の中には、さまざまなコーディングスタイルでCとC++が入り混じった状態のまま、かなり深く機能を掘り下げる人たちもいる。実装の細部を常にすべて把握できているわけではないが、心のどこかでは、誰かが本当にひどいバックドアを仕込んだらプロジェクトが終わるかもしれないと思っている
幸い、そのゲームはかなり obscure で、攻撃対象領域も非常に小さい。それでも、善意でWindowsバイナリに署名してみようかという誘惑は止まるようになった
この xzバックドア は本当に巨大な悪夢で、元の開発者たちや、これに巻き込まれたすべての人たちに同情する
森の小道を歩いているとき、通りかかった車がそのままはねていくかもしれない。運転手は捕まらない可能性が高く、防ぐ方法もなく、警察もそばにいない。ソフトウェアのバックドアよりはるかに恐ろしいこのシナリオは、実際には、何かをしながら生きていくために受け入れなければならない最小限のリスクだ。実際にそういうことは起こる
しかし結局のところ、大多数の人は他人を積極的に傷つけようとはしない。人間のあらゆる営みは常にその前提の上に成り立ってきたし、今もそうだ
コードレビューをもう少し厳格にし、リンターやCIやパターンマッチングをもっと使い、コード署名をさらに普及させ、人々の身元を検証すればこうしたことを防げる、という幻想こそがむしろ本当の問題だ。世界はあらゆる細部のレベルで管理・統制できるし、そうあるべきだという シリコンバレー流の妄想 の症状でもある。そんな「治療法」は、防ごうとしているどんな病よりもはるかに悪くなりうる
[1]: http://hintjens.com/blog:106
貢献者が楽しくプロジェクトに参加できるコミュニティを作る利点は理解できる。しかし、プロジェクトを明確なビジョンや方向性のないまま拡大させ、結局は他人の貢献を共通の基準に合わせるために、メンテナーへ過大な負担を強いるやり方のように感じられた
実際のコードレビューは将来の不確かな時点へ先送りされ、そのときレビューが徹底されるかどうかも、誰が責任を持って行うのか、問題を修正するのかも不明だ。結局、ユーザーに何が配布されるのかを制御できない混沌への処方箋のように聞こえる
悪意あるコードの配布という問題もある。当該ブログ記事のコメントでもこの問題が取り上げられており、Pieter は xz の事例とまったく同じシナリオを説明している
「Mallory が忍耐強く、欺瞞的で、十分長いあいだ有効な貢献者のように振る舞ってプロジェクトの制御権を手に入れ、その後ゆっくりとバックドアを仕込むとしよう。そうなると、慎重なコードレビューも役に立たない。Mallory はメンテナーになれるだけの十分な信頼を得ればよく、それは可能かどうかではなく、やり方の問題だ」
彼は「最善の防御はコミュニティの規模と多様性だ」と結論づけている
しかし、慎重なコードレビューは実際にこうしたことが起こる可能性を下げられると思う。信頼された貢献者であれ外部の貢献者であれ、すべての貢献を徹底的にレビューすれば、不審な挙動や、「Aをする」と言いながら実際にはBをするコミットをより早く発見できる可能性が高まる
Optimistic Merging がより大規模で多様なコミュニティにつながるのかも議論の余地がある。厳格な貢献ガイドラインを持ちながら活発なコミュニティを維持しているプロジェクトは多い。そして、悪意あるパッチをいつどうやって見つけるのかという問いにも答えていない
xz の問題は小さなコミュニティだったことではなく、コミュニティがなかった ことだ。単一の悪意ある行為者がプロジェクトの制御権を握り、他の誰からの監督もほとんどなかった。貢献ガイドラインはコミュニティ規模の要因ではなく、Optimistic Merging を使っていたかどうかに関係なく、こうしたことは起きていただろう
[2]: http://hintjens.com/blog:106/comments/show#post-2409627
brew install caskや vi/emacs/vscode の拡張機能をインストールしているのを見ると、いつも驚かされるRust は、デフォルトが最も安全なプログラミング言語／コミュニティだと言ってよく、ポインタまわりの危険な細工をほとんどできないレベルのセキュリティ優先設計を持っている。それなのに、最も一般的で推奨されるインストール経路はこうで、私自身も完全な偽善者としてしばしばこうしている
https://www.rust-lang.org/tools/install
これは一例にすぎない。「これを
curlしてshにパイプしろ」という形で自らリモートコード実行への道を開いておきながら、同時に誰かのunsafeブロックについて議論する習慣が、あまりにも多くの人にとって筋肉記憶になってしまっているこうしたことが起きたのは残念だが、驚きではない。こうした悪意ある行為者に対抗するための、より良いツールが、それもオープンソースとして、出てきてほしい
このバックドアが投げかける疑問はいくつもある。同じチーム、あるいは似たようなチームが仕込んだ別のバックドアは他に何があるのか。こうしたチームはどれほど活発に活動しているのか。こうした侵入攻撃に脆弱な依存関係はどれほどあるのか。業界におけるこの種の秘密工作の標的となりうる攻撃面はどれほど広いのか。
apache httpd,postgres,mysql,nginx,openssh,dropbear ssh,haproxy,varnish,caddy,squid,postfixのような主要ネットワークサービスと、そのすべての依存関係、さらにそれら依存関係の全コミッターグラフを作ることが、どこが最も価値が高く、監視が手薄かを把握する第一歩になるかもしれない。これが誰かがこうしたことを試みた最初の事例であるはずはない。失敗して露見した最初の事例にすぎない。Linuxカーネルに対して試みられ、発見されたバックドアは知っているが、これはリモート攻撃であり、まったく性質が異なる。
なぜ、検知されてもバグに見えるような無害そうなものを配布するのではなく、完全機能のバックドアを実装し、配布方法まで隠そうとしたのだろうか。
これは意識的な判断だったはずだ。その理由は、目標が何だったのかについての手がかりを与えるかもしれない。
これは、リモートからエクスプロイトをスキャンするには、こちらが持っていない攻撃者の秘密鍵が必要だという意味のようだ。残る選択肢は、ローカルで検知スクリプトを走らせることだけだ。
この問題が実システムで広範に広がっていると判明しない限り、そうしたやり方は、以前に似たような「専門家」たちが毎年パスワード変更を要求し、実際のセキュリティは下げたまま、書類上のセキュリティだけを良く見せていた件よりも悪く見える。
バックドアの署名検証には約100µsかかるはずなので、フィンガープリントが一致する鍵は、そうでない鍵よりその分だけ処理時間が長くなるはずだ。この時間差は少なくともLAN上では現実的に検知可能であり、スキャナーが対象の近くで動作するなら、インターネット越しでも可能かもしれない。
認証失敗を繰り返した後にクライアントIPをブロックするシステムでは、スキャンはさらに難しくなるだろう。
(https://bench.cr.yp.to/results-sign.html では Ed448 検証は約40万サイクルとなっており、4GHzでは100µsに相当する。)
sshdが何らかのチャレンジを出し、攻撃者がそれに署名しなければならない構造なのだろうか。人気のない意見かもしれないが、作戦全体には感嘆せずにいられない。もちろん非難すべきだが、それでも感嘆してしまう。構想から実行まで、本当に芸術作品のようで、これほど早く見つかったのはとてつもない幸運だった。
次は、攻撃者が人間の待ち時間が発生する作業で異常な遅延スパイクを生まないペイロードを作る可能性が高い。
なぜか、Kim Dotcom が違法盗聴の対象になっていると知った出来事を思い出す。MW3で突然 ping が大きく跳ね上がったからだ。調べてみると、自分のパケットだけが物理的に非常に遠い場所にある GCSB のオフィスを経由してルーティングされていた。GCSB にはニュージーランド永住者を盗聴する権限がない。最終的に彼はニュージーランド首相から個人的な謝罪を受けた。
最も巧妙だった部分は、侵入するプロジェクト選定だったと思う。あとから “Hans” の IFUNC プルリクエストの議論を読むと胸が痛むが、なぜこのプロジェクトが選ばれたのかを本当によく示している。
“Jia” と “Hans” の背後に何人いたのか、そしてコミュニケーションやコード貢献をどう分析し、どう戦略化していたのかを知りたい。メーリングリストで圧力をかける役を演じた第三の人格のような一部の側面は、やや雑に作られていたようにも見える。
だから、洗練された少人数チーム、あるいは単独の個人がやった可能性もまだある。国家主体であれば、この種の作戦のために偽の人格を一日中作って維持する人たちがいるだろうと思う。
誰かが「この3ユーザー、少し無礼なくらい強く押してくるのが変だな。誰なんだ？ アカウントも同時期に作られている。怪しい。なぜわざわざ偽アカウントでこれをここまで強く推す必要があるんだ？ 調べるべきだ」と考えていたらまずかったはずだ。全体の投入労力に比べると、その部分は不注意だったか、計画が悪かったか、予算不足だったことになる。
劇的な仮説を付け加えるなら、攻撃者が自分で炸裂させる情報核爆弾に怖気づいて、わざと失敗させた可能性すらある。
最終結果には嫌悪を覚えつつも、攻撃の複雑さ自体は認めざるをえない。