研究者、a16zのWebサイトの欠陥により一部の企業データが露出していたことを発見
(kibty.town)- あるセキュリティ研究者が、a16z関連のサブドメイン
portfolio.a16z.comで、Herokuインスタンスのprocess.env全体 がJavaScriptに動的に含まれている状態を発見した - 露出していた値には、
DATABASE_URL、AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、SALESFORCE_CLIENT_SECRET、OKTA_CLIENT_SECRET、MAILGUN_API_KEYなど、複数の サービス認証情報 が含まれていた - 研究者は、
lunchcatでJSファイル内のシークレットを探す通常のチェック中にAWSキーへの参照を見つけ、ブラウザの開発者ツールの Sourcesタブ だけで確認できたと述べた - 影響範囲にはPIIを含むデータベース、AWS、Salesforce、Mailgunが含まれており、Mailgunではa16zドメインから任意のメール送信や過去のメール閲覧が可能だったと主張した
- a16zは、公の場で連絡を試みたことを理由に バグバウンティを支払わず、研究者はメインサイトに連絡先がなく、見つけたメールアドレスも不達だったと述べた
サブドメイン調査中に露呈した環境変数
- 研究者はTwitterで企業を見つけた後、素早くペネトレーションテストを行う方法で対象を探しており、
Relevant Peopleタブをよく使うと述べた- 今回の経路は、
crypto関連企業 → cryptoベンチャーキャピタル →a16z crypto→a16zへとつながった
- 今回の経路は、
- a16zの調査過程で一般的な サブドメインスキャン を実施し、lunchcat ツールでドメインチェックとJSファイル内のシークレット検出を行った
portfolio.a16z.comは、a16z傘下の企業向けの ポートフォリオ管理ツール のように見え、チェック中にWebサイトのどこかでAWSキーへの参照が検出された- JSの中には、Herokuインスタンスの
process.env全体と思われる値が動的に入っていた- 含まれていた項目には、
MARKETPLACE_URL、DATABASE_URL、SALESFORCE_CLIENT_ID、SALESFORCE_CLIENT_SECRET、OKTA_CLIENT_SECRET、SESSION_SECRET、MAILGUN_API_KEY、AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、COOKIE_SECRET、HEROKU_POSTGRESQL_CRIMSON_URLなどがあった - 研究者は認証情報をすぐに確認し、偽物ではなく実際の認証情報 のように見えたと述べた
- アクセスはブラウザの開発者ツールで Sourcesタブ を開く程度だったと説明した
- 含まれていた項目には、
露出し得る範囲とバグバウンティをめぐる議論
- 研究者が挙げた侵害され得るサービスは次のとおり
- データベース: PIIを含んでいたと述べた
- AWS: 露出したキーを通じてアクセスできる可能性が言及された
- Salesforce: 直接確認はしておらず、アカウント権限が限定的である可能性があるとも付け加えた
- Mailgun: a16zドメインから任意のメールを送信でき、過去のメールも読めたと述べた
- その他にも存在する可能性に言及した
- a16zは、研究者が非公開で連絡せず公に連絡を試みたことを理由に バグバウンティを支払わなかった
- 研究者は公に連絡した理由として2点を挙げた
- a16zのメインサイトで利用できる連絡先を見つけられなかった
- 見つけられたメールアドレス宛に送ったメールが不達になった
- 関連記事として TechCrunchの記事 が添付されており、研究者がa16zに連絡しようとして投稿したツイートをLorenzoが見て連絡し、記事を書いたと述べている
1件のコメント
Hacker News のコメント
私たちのオープンソースプロジェクト（[https://github.com/heyPuter/puter/](https://github.com/heyPuter/puter/））を公開したとき、Eva はかなり広範にペネトレーションテストをしてくれ、脆弱性報告も非常にプロフェッショナルに対応してくれた。
当時はバグバウンティプログラムもなかったのに報酬を求めることもなく、Eva は優秀で責任感のあるハッカーなので、a16z はもっときちんと遇するべきだ。
似たようなミスをしたことがある。
apostrophecms という Node.js CMS を使っていて、global settings という管理者パネルを認証サーバーの API キー管理に使っていたのだが、数か月後になってようやく、その値が HTML ソースコードに出力されることに気づいた。
JavaScript から使えるようにするための仕様で、ドキュメントにも書かれていたのでそちらを責めるつもりはないが、私たちが雑に見過ごしていた。
さらに腹立たしいのは、大手コンサルティング会社にかなりの金額を払ってペネトレーションテストを受けたのに、彼らも見つけられなかったことだ。結局自分たちで発見し、ログを確認したところ悪用された形跡はなさそうだったが、かなり衝撃的な漏えいだった。
これまで見てきたペネトレーションテストは、チェックボックスを埋める以上のものだったことがない。
あなたの言うとおり、このデータ共有の方式はドキュメントに書かれていたが、それでも驚くことはあり得る。
今後調べる人のために補足すると、現在サポートされている Apostrophe のメジャーバージョンは、もうこのようには動作しない。
ログアウト状態のフロントエンドにデータを注入するには、開発者が意図的に選択する必要があり、こうした驚きを避けるためにそのように変更された。
ただし、特定のウィジェットの設定やコンテンツの一部として API キーを含める必要があるユースケースは今もある。
ちなみに私は Apostrophe のデザイン責任者であり、エンジニアリングの役割も担っている。
この状況は、私たちのマルチテナント構成と apostrophe への理解不足が原因で起きた。
危険な挙動をドキュメント化したからといって免責されるわけではなく、この教訓はもう広く知られているべきだと思う。
新しいサービスを作って ACME でサーバーに LetsEncrypt 証明書を付けると、すぐにログがゴミのようなリクエストで埋まる。
開発者が開けたままにしがちな甘いデフォルトを探すボットがあからさまに見えるし、プロセス環境ファイルをリクエストしてくるのを見たことすらある。
こういう脆弱性がどうして発見も悪用もされなかったのか分からない。a16z が非常に幸運だったのか、あるいはすでに悪用されているが公になっていないだけかもしれない。
善意の研究者か、ホワイトハット精神のある退屈した人が先に連絡したということだ。こうした不注意に法的な枠組みがないのは残念だが、a16z は多額の罰金を科されるべきだと思う。
もしかすると、すでにされていたのかもしれない。
ただ壊すよりも、これを開けたままにしておくほうが価値があったのかもしれない。
ただ、OKTA のような認証情報がいくつかあるのはかなり危険に見える。
「公に連絡してきたためバグバウンティは支払わなかった。そうした理由は、メインサイトに連絡先がなく、見つけた engineering@a16z.com はメールがバウンスしたからだ」という部分は、会社のお金を節約する賢いライフハックのように見える。
エンジニアリングチームに非公開で連絡する手段をなくしておけば、すべてのバグバウンティ報告が公に行われることになり、そうすれば何も支払わなくて済むからだ。
開発も fiverr みたいなところで人を買いたたいて相当節約したのだろうし、ロシアのランサムウェアグループが簡単に持っていけば、会計コストも間接的にかなり節約できそうだ。
公開されたバグバウンティプログラムがないなら、借りは何もない。
そのうえ https://a16z.com/connect の下部に連絡用メールアドレスがあるのに、研究者は都合よく見落としている。
責任ある開示というより、知名度を狙ったように見える。
企業が「ハッキングされた」と言うとき、今では「重要な認証情報を適切に保護できなかったが、私たちが『ハッカー』と呼ぶ無名の主体に責任を押し付けてほしい」という企業向け表現のように聞こえる。
「住居侵入」「窃盗」「不法侵入」といった法的な区分があり、ドアが開いていたかどうかが違法性や処罰に影響することはあり得るが、日常表現としてはやはり盗まれたのだ。
これほど大きく開いた穴に対して、象徴的な金額のバウンティすら払わないのはかなりひどい。
彼らは巨大な生成 AI アーキテクチャのホワイトペーパーを書くのに忙しい。
少し休ませてあげよう。半分できただけのチャットボットたちが動き回る未来のエージェント世界を夢見ているのだから。
世界は壊れたソフトウェアアップデートで燃えているというのに。
金曜日の壊れたソフトウェアアップデートは、その上に添えられた仕上げの一筆だ。
まったく驚かない。
実際に Salesforce インスタンスへアクセスできたのだとしたら、創業者の立場では非常に不安だったはずだ。
通常 Salesforce のような場所にはメールが記録されており、その中にポートフォリオ企業の創業者たちが外部に共有していない資金調達計画や M&A 計画が残り続けている可能性があるからだ。
しかし、そのキーで権限のないシステムにアクセスすることは犯罪だ。
この違いは非常に大きい。
この VC 会社がこれほど大きなセキュリティホールにバグバウンティを支払わなかったという事実は、信頼を抱かせない。
HN の運営がタイトルをあまり恥ずかしくないものに変えたね。
驚きではない。
スコアの変化はないのに、一番上から一番下へ移動している。
応答を提供する方法も本当にいろいろあるね。