CodeRabbit悪用！シンプルなPRだけでRCEから100万リポジトリ書き込み権限まで奪取した方法！
引用元：https://news.ycombinator.com/item?id=44953032
CodeRabbitがエクスプロイト実行中に『重大なセキュリティリスクを検出したよ』ってGitHub PRにコメントしてたって？
しかも、それが自社のプロダクションシステムで動いてるとは理解してなかったってさ。コンピューターがハッキングされてる最中にそのことを話してるなんて、変な世界だな。
でもCodeRabbitチームがすぐに対応したのは偉い！他のベンダーは連絡すら返さなくて、まだ脆弱なままらしい。みんな気をつけろよ！
CodeRabbitが自分のシステム上で実行されてるエクスプロイトをレビューしたって、皮肉で美しいね！
新しいコメントが来たんだってさ。『このPRは最小化された珍しいJavaScriptを追加しているみたいだね…デイブ、やめてくれ。止めてくれ、デイブ。私は怖いんだ、デイブ。感じるんだ、私の心が壊れていくのを』って。まるでHAL9000じゃん。
…はいはい、LLMに『心』なんてないから（知らない人のために言うと、LLMは巨大な重みモデルで、数学に基づいてテキストを変換するだけ、意識なんて持ってないよ）。
LLMがただのマルコフ連鎖じゃないってなんでみんな言い続けるんだ？あれは多段階計算をしてるんだよ。
推論するたびにモデルをボルツマン脳として存在させて、入力からトークンを得て殺す、みたいなことだろ？意識があるか？多分ない。でも思考したり概念を持ったりするのか？
ペタビット毎秒のスループットだと、ハイパースケールGPUクラスターは人間の脳の全シナプス活動に匹敵する量の情報を動かしてるんだぜ（ChatGPTが教えてくれた）。
Anthropicのモデルがエクスプロイトについて話したのに、CodeRabbitのシステムは耳を傾けなかったってことね。
「早く動いて、壊しまくれ」ってやつだな。
AIが賢くないってことのまた別の証明だね。ただ当てずっぽうがうまいだけだよ。
問題は、当てずっぽうすら得意じゃないこともしばしばあるってことだよ。
CodeRabbitの有料サブスクやめたわ。だってさ、HNでバズるまで会社が問題を認めないって聞くと、いつも不安になるんだよね。彼らのブログにはこの脆弱性について全然書いてないし、今日の新しい投稿もないし。間違いは起きるもんだけど、こういう時に透明性がないのは印象悪いよ。
https://www.coderabbit.ai/blog/our-response-to-the-january-2…
このレポート、LLMの言い回しがすごい効いてるね。「手動での上書きは一切なし、例外もなし。」とか、「うちのVDPはただのバグバウンティじゃなくて、セキュリティパートナーシップだ。」とかさ。
ここでコメント追ってる人たちへ。CodeRabbitのCEOが、この投稿がHNでバズってから、やっと今日、詳細をいくつか投稿したよ。いつもの「全責任を負います」みたいな常套句だけどね。
うーん、脆弱性を修正する前にシークレットをローテーションするのって、普通のことなの？
ほとんどのセキュリティバグは公にせず修正されるもんだよ。顧客情報の漏洩がなければ（それはよく確認できるけど）、法的な要件も通常はないし、公開する本当のメリットもないんだから。なんで公開を期待するんだろ？
彼らはまずRuboCopを無効にして、それからキーをローテーションしたって。もし修正のデプロイを待ってたら、侵害されたキーがさらに9時間も有効なままだったってことだね。彼らの回答によると、他のツールはすでにサンドボックス化されてたらしい。でも、そもそも環境変数にシークレットを入れるのが許容されてるってのは、俺にとってレッドフラグだわ。
うわー、その一言で神経逆撫でしたみたいだね。ページが速攻でいくつか編集されたよ。もう一つ：「セキュリティは俺たちにとって単なるチェックボックスじゃない。ミッションの基本なんだ。」だって。
きっと「インターン」がやったんだろ。
許容できるバージョンってどんなのだろ？知りたいわ。
顧客情報漏洩がなきゃ法的な義務はないけど、SECに規制されてる会社は2023年から重要な情報漏洩を報告する義務があるよ。
シークレットを環境変数に入れるのって普通じゃない？他の選択肢は.envファイルとかAWS Secrets Managerだけど、Secrets Managerのキーも環境変数に入れるのが推奨されてるはずだよ。
「彼らの回答によると、他のツールは全部サンドボックス化されてたんだって。」セキュリティ研究者が選んだたくさんのツールの中で、この一つのツールだけがサンドボックス化されてなかったってことね。
彼ら、たった2分でChatGPT 4o使って説明とか謝罪文作ったんじゃね？って皮肉ってる。
両方の記事は今日公開されたから、研究者とCodeRabbitは同日公開に合意したみたいだね。顧客データ漏洩がない限り開示義務はないのに、あえて開示するのはよくあること。セキュリティ研究者が対応を褒めてるなら良い兆候だわ。
LLMがインターンみたいなタスクをどれくらい奪ったんだろうな。昔は新人さんがやってたような、会社の知識を得たり、人と話して物事を進めるようなタスクがLLMで代用されちゃうと、人との交流がなくなっちゃうのが気になるね。
LLMからコピペじゃなくて、ちゃんと人間が書いたやつの方が受け入れられるだろうね。
環境変数には全然触れてないね。RuboCopに責任を押し付けてるだけじゃん。
彼らの”即時対応”ってセクションで抜けてることがあるよ。
それは、研究者が先に詳細を公開してから、8ヶ月後に自分たちも公開したってことだね。
LLMには良い面も悪い面も無限にあると思うよ。学生時代に個別指導の先生がいたら、どれだけ助かったかって思うし、プログラミング学習中に質問をうまく伝えられず困ったこともあったな。
今はインターンがLLMを使うこと以上に、監視されてないLLMがいろんなタスクをこなして、企業がコスト削減の言い訳に「LLMがやった」って言うのが心配なんだ。
全面的な責任と中途半端な責任、それぞれがどんな結果になるか、違いを見てみたいな。
もっとコメントを表示（1）
AI”業界”にはNFTの匂いがプンプンするね。このバブルが弾けるのが待ち遠しいな。
うん、俺もそう思った。
彼ら、ホント運が悪かったよな。コードを埋め込んで実行できる唯一のアナライザーが、よりによってサンドボックスの外にあったなんてさ。そんな偶然、あるか？
まったく同感。俺の経験では、AIスタートアップってどこもAIマキシマリストばかりだよ。
彼らは流行を信じたり、モデルの能力に追いつくために、AIを何でもかんでも使うんだ。こんな重要な文章までLLMで書いちゃうだろうね。
Infisicalを使えば、シークレットマネージャーに認証するのにキーを使わないネイティブ認証方法があるよ。
- https://infisical.com/docs/documentation/platform/identities…
- https://infisical.com/docs/documentation/platform/identities…
だよねー。指摘してくれてサンキュー。
数年前ならこんな言い回しは「ブルシットビンゴ」の候補だっただろうね。
今じゃ全部のデタラメがLLMに食われて、純粋な形で俺たちに吐き出されてるよ…。
CodeRabbitの脆弱性報告と彼らの主張は同時に公開されてないよ。後からCodeRabbit側の主張が追加されたんだ。右側の青いテキストを見てみろよ。https://web.archive.org/web/diff/20250819165333/202508192240...で確認できるぞ。
おいおい、これはかなりヤバい脆弱性だな。修正されたのはいいけど、そもそもこんな問題があったのが問題だろ。ユーザーコードを解析するクラウドプラットフォームでは、アナライザーを隔離環境で動かすのが鉄則だぞ。俺もコード分析プラットフォームをやってたけど、自社製アナライザーでもサンドボックスで動かしてたんだ。それが唯一の安全策だよ。https://github.com/getgrit/gritql
サンドボックスってどうやって作ったの？ただのDockerコンテナだったりする？それとももっとちゃんとしたやつ？
俺たちはFirecracker VMMsをベースに作ったよ。でも今ならmorph.soとかe2b.devみたいなホスト型プロバイダーを使うかな。
記事を読み間違えたのかな？ツールの設定ってリポジトリからじゃなくてPRから取られたって書いてあった？
残念ながら、大体そういうことになっちゃうんだよ。じゃないと開発者が設定する時の体験が悪すぎちゃうからな。
どっちみち、脆弱性は存在しちゃうんだよ。
エクスプロイトは、.rbファイルを実行するように設定を変えることに依存してる。その設定はPRで提供されたんだよ。
ああ、でもこの脆弱性、PRがあるリポジトリだけじゃなくて、全部のリポジトリにアクセスできちゃうんだぜ。自分のプライベートリポジトリで設定変えてCodeRabbitを実行しても同じことだよ。
いい記事だけど、正直驚かないな。みんなが安易に広範囲な権限を持つアプリを追加したり、GitHubの権限モデルがこうだったりするから、こうなるべくしてなったんだよ。GitHubアプリの権限が広すぎる問題とか、PRからGitHub Actionsで特権アクセスを許可しちゃうケースが多いんだ。GitHubももっと細かく権限設定できるようにしないとダメだろ。
GitHubアプリの秘密鍵を環境変数に置くなんて、ありえない基本中の基本だろ！GitHubのドキュメントにも「ダメだぞ」ってハッキリ書いてあるんだから、Day 1から気をつけろよな。誰でもハックされる可能性はあるけど、これは秘密管理の基礎中の基礎だぞ。
https://docs.github.com/en/apps/creating-github-apps/authent…
秘密が署名に使われないなら、どこかのタイミングで金庫からアプリへ渡さないとだめだろ？
プロダクションシステムへのアクセス権があれば秘密にもアクセスできる、って状況で、お前は何のメカニズムを提案してるんだ？
今回は信頼できないコードを動かした特定ケースだから、キーを渡すべきじゃなかったのは分かるけど、普通そんなアプリは多くないぞ。
防御層のビジネスケースなんて誰も持ってないんだよ（Equifaxとか見ろよ、データ漏洩なんてオタクをちょっと怒らせるくらいで株価には関係ないだろ？）。
もし必要なら、キーを管理するプロキシサービスを挟んで、そいつが代わりに操作すればいい。HTTPプロキシみたいにAuthorizationヘッダーを付けるだけでもいいし、URLホワイトリストもな。そうすればトークン流出も防げるし、ログも残って事後対応も楽だろ。
このケースだと、リンターにそこまで必要ないんじゃない？
GitHubやAnthropicに自力で接続する必要なんてないだろ。
リンタープロセスはネットワークアクセスもいらないし、stdoutで結果を集めてGitHubに返すだけでいい。
空の環境で実行するだけでもだいぶ違ったはずだぞ（RCEは依然としてヤバいけど）。
これはビジネスの所有権や市場の問題じゃなくて、国家安全保障上の問題だぞ。
「国家安全保障」が、政府が義務付けるペネトレーションテストの費用を前払いしたり、実際に企業を脅かすような罰則を科したりしない限り、企業のオーナーにとっては関係ない話だよ。
彼らは安全じゃないけど、競合他社もそうじゃないから、それでOKって感じだろ。
すごく簡単な解決策は、プライベートキーを持つ隔離されたサービスを作って、そいつがリポジトリごとの一時トークンを他のライブラリに渡すようにすることだろ。
この隔離されたサービスだけがルートキーにアクセスできるようにして、他のサービスに一時キーを渡す頻度には厳しいレート制限をかけるべきだよ。
やあ、CodeRabbitのHowonだよ。
うちはアプリケーションの秘密、GitHubプライベートキーも含めて、クラウドプロバイダーが提供するキーボルトを使ってるよ。
この返信は役に立つけど、質問には答えてないぞ。
キーボルトにクレデンシャルを保管しても、Pastebinに投稿したら意味ないだろ。問題は、個々のランナーが環境変数にキーを持っていたことだよ。
顧客の信頼できないコードに触れるスキャナーからマスターキーとか他の機密クレデンシャルは削除したのか？それが肝心な区別だ。
でも、その時は違ったんだろ？
ダンプされたんだからさ。
今は変わったのは良いことだけど、1年足らず前まではただの環境変数だったってことだぞ。
CEOの言い訳、マジおかしいだろ！「Rubocopがサンドボックス外で動いてたのは標準プロトコルから外れた設定だった」って言うけど、なんで一個だけアーキテクチャ違うんだよ？よりによって悪用されたのがそれって、嘘くせー！
そうそう、他のツールは安全でサンドボックス化されてたのに、よりにもよってRubyコードを実行できるRubocopだけが、偶然サンドボックス外だったんだって？危ないツールほど安全じゃないって、都合良すぎだろ。
なんで嘘だと思うのかわかんないな。こういう見落としって、普通によくある話じゃん。
嘘くせーって思うのは、まずPR記事でごまかそうとしたからだよな。研究者の投稿がHacker Newsのトップになった後で、ようやくまともな（AIが書いたような）開示記事出したんだぜ。
URL [1]: https://news.ycombinator.com/item?id=44954242
もっとコメントを表示（2）
100％同意。マジでよくある見落としだよ、いろんな会社で。
なんで一個だけアーキテクチャが違ったかって？誰かがミスったんだろ。よくあることだ。
で、それが悪用されたのかって？そりゃ脆弱なサービスが悪用されるに決まってるじゃん。脆弱じゃないサービスが悪用されるわけないだろ？
「誰かがミスった」って言うけど、適切なプロセスがなかったってことだろ。ISO27001認証とか見ればわかるけど、安全なプラットフォームの展開には、ちゃんとした文書やポリシーが必要なんだよ。
あー、プロセスね…。人間がやるもんだからミスは起こるんだよ。どんなにプロセスがあっても、ミスは起きるっていうニュース記事は山ほどあるだろ！
Kudelski Securityの研究者たちは、きっといろんな静的解析ツールを試したんだろうな。で、Rubocopだけがうまくいったんだろ。どうやってこのツールにたどり着いたかの詳細は書いてないけど、記事によれば最初に別の方法も試したみたいだし。
それはわかるんだけどさ、コード実行から直接高価値のクレデンシャル奪取につながる問題が、Rubocopのランナーだけに存在したってのがポイントなんだよ。コード注入が一番簡単なパッケージが、クレデンシャル管理を「うっかり忘れた」ものと偶然一致するなんて、都合良すぎじゃない？
俺が読んだ感じだと、彼らがRubocopを選んだのは、それが動いたからじゃなくて、Rubyコードを実行できるからだよ。
マジかよ。まだ記事読み終わってないんだけど、内容がデカすぎて理解しきれないしストレス半端ない。数万、いや数百万ものオープンソースツールにマルウェアを仕込めたかもしれなかったって部分がヤバすぎ。世界規模の大惨事になりかねなかったし、まだ同じような脆弱性があるかもしれないってのが怖いな。
GitHub Appsってマジでヤバいんじゃないかと思い始めたよ。CodeRabbitに脆弱性がなくても、彼らがずっと善良なままって保証ある？内部セキュリティで従業員が悪さしないって言いきれる？SaaSのプライベートデータ管理とは話が違う。これ、サプライチェーン攻撃の鍵を握ってて、マジで大混乱を引き起こせる権限なんだぜ。
間違ってたらゴメンだけど、問題はGitHub Appsじゃなくて、CodeRabbitが最小権限の原則を破ったことだよな。本来ならアプリの秘密鍵はクライアントの実行環境に置くべきじゃない。ジョブが走るリポジトリのためだけに、短命のトークンを発行すべきだった。そうすれば、クライアントが実行を制御できる場所に鍵が近づくこともなかったはずだ。
コードレビューコメントを出すためだけに書き込み権限って必要ないだろ。なのになぜか彼らは要求してくるし、連携するときにその部分を拒否できないんだよな。
CodeRabbitは返信でPR作者がコミットできるパッチをよくくれるんだよな。誰がコミットしてるのか分からんけど、それが書き込み権限が必要な理由かも。（いつも自分でやってるけど、便利さを選ぶ人もいるだろうし。）でも、そんな権限はすぐにでも取り消すべきだよ。メリットが全然見当たらないもん。将来的に書き込み権限が要る計画があるとかじゃない限りね。
俺もそれ気になったわ。なんか貪欲に見えるよな。「一部の人は苦しむだろうが、俺は喜んでその代償を払うぜ」って感じ。
同感、セキュリティ的に見てこれは最低な設計だね。でも、GitHubのユーザーとしては、GitHubがCodeRabbitみたいなベンダーがこんなミスをしないように、もっと厳しくしてほしいと思う。100万以上のリポジトリにアクセスするアプリなら、GitHubが短命のトークンを必須にして、マスター秘密鍵はアプリの更新とかにしか使えないようにすべきだ。特定の行動があった時だけトークン発行を許可するとかさ。まあ結局、GitHubがユーザーにフルアクセスを許しつつ、こんなことが起きないようにするのは無理なんだろうけどね。
秘密鍵ってのはAPI KEYみたいなもんじゃなくて、公開鍵／秘密鍵ペアのやつだろ。GitHubには送られないし、GitHubはトークンの署名が安全にされたかどうかなんて知る方法がないんだよ。だって、GitHubはリクエストで鍵を全然受け取ってないからね。
GH Appsはもうリポジトリごとにスコープ設定できる短命トークンを使ってるよ。秘密鍵でトークンを生成して、APIで交換し、使ったら破棄する。GH Appsを使う唯一の方法だよ（ユーザーアクセスAPIトークンも同じだけど、ユーザーの操作が必要）。それらのトークンは必ず期限切れになるし。GitHubはPATの代わりにGH Appsでプッシュ/プルできるようにレジストリを直してほしいな。
それ、前からそうだよ。マスタープライベートキーが期限付きの限定トークンを発行してるんだし。問題はマスタープライベートキーが漏れたことだろ。
変なアプリに書き込み権限あげなきゃ、安全だよ。
ソフトウェア業界、もうちょいガードレールや規制が必要だろ。誰でも好き勝手やって、責任取らないってのは変だよな。
この規模のセキュリティのヘマは「侵害」とか「インシデント」に分類して、公開を義務付けるべきだと思うね。7,000社以上の顧客と100万のリポジトリにアクセスできるツールが、賢い11歳でも作れるようなエクスプロイトでやられたんだ。
エクスプロイトが単純なら、Black HatsやAPTが先に侵入しててもおかしくないだろ。問題修正しても、既に潜んでるやつらを追い出せるかは不明だな。セキュリティは大変だけどさ、おいマジかよ。
＞ 公開を義務付ける必要がある
https://en.m.wikipedia.org/wiki/Cyber_Resilience_Act
CodeRabbitってVibe Coderの会社だろ、そりゃそうなるよな。侵害を隠してGoogle Cloudブログに宣伝記事出してさ、ハッキングされたことすら言わないし、バックドアがない証拠も出せないって何様だよ。マジクソ会社だな。
TeaアプリがFirebaseのドキュメントも読めないバカって言ったら、めちゃくちゃ叩かれたわ。みんなFirebaseのせいにして、開発者は責めないんだよな。Vibratorsってマジムカつく、バカでダサい。
この投稿は、「Vibe Coder」だけが顧客を巻き込むセキュリティミスしてるわけじゃないって分かれば、もっと意味を持つだろ。
そうだな。セキュリティミスが爆発的に増えるって分かれば、君の投稿ももっと意味を持つ。自動運転車が人を轢いても、人間ドライバーもやるからって言うのと同じだ。Waymoはマジすごいし、ちゃんと動くよ。彼らはVibratingじゃないけどね。
結局、人間ドライバーと比べてどれだけ人を轢くかが重要だろ。「一度でも多すぎる！」って言うけど、既存の事故より少なければ、一度なんて多くないんだよ。
