Basetenの本番GitHubに25分で管理者権限を取得した方法
We got admin access to Baseten's production GitHub in 25 minutes
セキュリティ企業Strixが、Basetenをベンダーとして検討する前に自社の自律型ハッキングエージェントでスキャンしたところ、公開Harborレジストリから2023年3月ビルドのDockerイメージを取得。そのビルド履歴に残っていたGitHubトークンが、メイン製品リポジトリやGitOpsリポジトリへの管理者権限を今も保持していた。Basetenは翌日までにトークンをローテーションし、問題を修正した。
Dockerイメージにはファイルシステム層だけでなく、ビルド履歴を含む設定情報も含まれている。認証情報ファイルを削除しても、ビルド履歴にトークンのコピーが残っていれば意味がない。そしてこのトークンは3年以上経った今も有効だった。
HNでの議論
142- swyx
> Basetenはこれをうまく処理した。タイムラインは以下の通り：
> 7月13日 午後11:10：私はライブのbasetenbotトークン、公開Harborプロジェクト、リポジトリの権限を報告した。
> 7月14日 朝：BasetenはHarborプロジェクトを非公開にした。私はトークン自体がまだ機能していることを指摘した。
> 7月14日 午後4:34：Baseten SecurityのAntonがこの問題を重大と確認し、Harborプロジェクトを非公開にし、トークンをローテーションしたと述べた。また、私たちがプルしたイメージを安全に削除するよう求めた。
> 7月14日 午後5:05：私たちは削除を確認し、同じスキャンから見つかった2つの低深刻度の所見を送った。
> 7月17日：Basetenは残りの所見をクローズした。
> 9月：私たちはこの所見を公表する予定であることをBasetenに伝え、この記事のドラフトを送った。
彼らはまた、この重大なバグを見つけたお礼としてTシャツとスウェットシャツを送ってくれた。
全体としてよくやった。私の唯一の未解決の疑問は、このことから学べることとして、すべてのバイブコーディングされた内部エージェントが従うべきデフォルトのセキュリティ境界は何かということだ。
- wxw
[ペネトレーションテストエージェント]がbasetenbotのアクティブなGitHubパーソナルアクセストークンを持ち帰った。そのトークンは、Basetenのメインプロダクトリポジトリ、クラスタを駆動するGitOpsリポジトリ、およびHomebrew tapへの管理者およびプッシュアクセスを持ち、さらに顧客ごとの特定のリポジトリを含む他のプライベートリポジトリへの読み書きアクセスも持っていた。
そしてエージェントは、Basetenのイメージリポジトリを見つけた後、Dockerビルド履歴でトークンを見つけた。
最近、この種のエージェント駆動型のセキュリティエクスプロイト（つまり悪意のある行為者によるもの）で、我々が耳にしていないものがどれほどあるのだろうか、心配だ。
- aatd86
これはstrixにとっては素晴らしいマーケティングで、basetenにとってはかなり悪い。
自分のセキュリティ製品を宣伝するためにより良いストーリーを持てる人はいないだろう。
strixについては知らなかったが、今から調べてみるつもりだ。
自分のスタックに追加するかもしれない。
- codemog
これは合法なのか？隣人の家に侵入しようとしても、ロックを破った後に中に入って盗むつもりがなくても、それはできないと知っている。
- nrmitchi
それが有効かどうかは別として、セキュリティツール企業が実際の顧客/ベンダーをマーケティングキャンペーンに利用することには、何か引っかかるものがある。この「ストーリー」は、彼らの「被害者」をあからさまに名指しすることなく語ることができたはずだ。
それが複雑な多段階のエクスプロイトであれば話は別だが、トーンは「Basetenがどれだけ失敗したか見てみろ！」に近い。
Strixはこの時点でも一線を越えている：
> Strixはイメージをプルして中身を見ることにした。
ここでホワイトハットの範囲を超えている。能動的にデータを窃取してそれを見始めたら。窃取したデータから認証情報を使い始め、内部システムを列挙して探り始めたら、もう完全に超えている。
聞いてくれ、わかるよ、彼らの製品は「自己テスト用」であり、掘り下げても安全だと想定している。結局のところ、自己チェックだからね。だからこそ、それを第三者に向けるのは無責任で、違法すれすれなんだ。たとえ「許可」があったとしても、その許可が「できれば我々のリポジトリも検索および/またはダウンロードしていい」にまで及んでいたとは思えない。
全体的なトーンはプロフェッショナルとは言い難い。（太字で）「これは公開ダウンロード可能なイメージに残すには非常識な量のアクセス権だ」といった発言。誰もがこれは認識しているし、意図的な決定だったかのように表現されている。
自分たちが「助ける」ために設計された人々を積極的にけなすチームのセキュリティツールは間違っていると感じる。
編集：「リポジトリをプルする」に関する私の主張を明確にするために、この投稿には目的と機能の説明が含まれている […]
- grey-area
…ログから管理者トークンを見つけることによって。
- brewmarche
ああ、この問題は何度か見たことがある。そのようにDockerビルド引数を使うなら、`--provenance=false`を追加して、そのビルドメタデータをすべて取り除くといい。ビルドシークレットの方が、Dockerfile内でシークレットをスコープできるのでまだマシだ。また、メタデータはイメージを検査するのに役立つこともある。
- stopthe
最近の侵害は、何らかの形でGitHubが関与していることがあまりにも多い。なぜそこにプロプライエタリなものをホストすることがまだ正気の選択だと考えられているのか？あなたのビジネスがオープンソースを中心に構築されているなら、まあ、GitHubにミラーを置けばいい。しかし、CI/CD、GitOps、FDEのものはパブリッククラウドに置く場所ではない。Cレベルの幹部はビットとバイトの区別がつかないかもしれないが、今となってはこれが野外で硝酸アンモニウムを保管するのに似ていることを理解しているはずだ。