- 余暇にバグハンティングを楽しむ15歳の少年が、Fortune 500企業が使うZendeskでメール認証に関するバグを発見
- これを複数企業に報告して5万ドル以上を得た一方、Zendeskはこれを修正しておきながら、報告者には一切報奨金を支払わなかった経緯を紹介
Zendeskの紹介
- Zendeskは世界有数の企業が利用するカスタマーサービスツール
- サポート用メールをZendeskに接続すると、Zendeskが受信メールを管理し、チケットを作成する
- 多くの大企業が独自のチケットシステムを構築する代わりにZendeskへ依存しているのは驚き
最も弱い環
- 「最も弱い環の強さまでしか強くない」という言葉どおり、Zendeskはしばしば単純なチケットツールと見なされ、慎重な設定なしに使われる
@company.com ドメインをシングルサインオン(SSO)に使い、Zendeskと連携するとセキュリティ脆弱性が生じうる- Zendeskがドメインメールを処理するため、SSOシステムがメールアドレスを適切に検証しない場合、Zendeskへアクセスした人物が内部システムを悪用できる可能性がある
メールスプーフィング
- Zendeskの深刻な脆弱性を発見し、攻撃者がZendeskを使う企業のカスタマーサポートチケットを読める状態だった
- Zendeskにはメールスプーフィングに対する有効な保護機構がなかった
- 攻撃者はサポート用メールアドレスとチケットIDを知っていれば、メールスプーフィングによって元の送信者になりすまし、チケットへアクセスできた
- 著者がバグを報告したが、Zendeskは当初関心を示さなかった
- メールスプーフィング(SPF, DKIM, DMARCの問題)はOut of Scopeとの回答
- 報告はHackerOne経由で処理され、Zendeskチームのメンバーへの直接報告も求めたが拒否された
この問題をSlack乗っ取りへ拡大
- メールスプーフィングのバグを個別企業へ報告することもできたが、より大きな影響を与えたいと考えた
- 過去には別の研究者がZendesk経由で数百社のSlackへ侵入した事例があった (TICKETTRICK)
- 著者は自分のバグでこれを再現しようとしたが、いくつか困難があった
- Slackはメールアドレスへランダムトークンを追加して検証する方式へ変更していた
- しかしOAuthを使ってApple IDでログインする場合はトークンが使われず、回避できた
再現手順: Apple → Zendesk → Slack
support@company.com でApple IDを作成し、認証コードをリクエストするとZendeskチケットが作成されるcompany.com のサポートポータルで自分のメールアドレスを使ってチケットを作成し、ID範囲を追跡する- メールスプーフィングのバグで、そのID範囲のすべてのチケットに自分を追加しようとする
daniel@wearehackerone.com アカウントでその会社のサポートポータルにログインし、CCされたチケットを確認する- Apple IDに認証コードを入力する
- Slackの「Appleでログイン」機能から、@company.com メールに接続されたApple IDでログインし、Slackにログインする
著者はこの6手順を数百のZendeskおよびSlackインスタンスに適用した
事件の余波
- 1週間にわたり個別企業へ脆弱性を報告し、一部は即座に対処したが、Zendeskの問題だと主張する企業もあった
- いくつかの企業がZendeskに連絡すると、Zendeskは最終的に報告を非公開のままにしてほしいと要請し、Slack脆弱性の再現手順を求めた
- Slack乗っ取りのPoCを提供した後、Zendeskは問題を確認したが、解決までに2か月かかった
- 多くの企業がメールコラボレーション機能を無効化してインスタンスを保護した
- 著者はこのバグバウンティ報告により、HackerOneやその他プラットフォーム上の各企業から合計5万ドル超の報奨金を受け取った
- 一部企業はZendeskとの契約を解約した
Zendeskの修正と私の0ドルバウンティ
- 2か月後、Zendeskは問題の解決を確認した
- CloudmarkとRspamd EAPスパムフィルタを使っていたが、Rspamdのスコアを活用していなかったため、多くのメールが保留されなかった
- 当初は特定条件でRspamdへ自動切り替えする方式で修正した
- その後、AppleとGoogleの認証メールを自動保留するフィルタを実装した
- 問題を解決したにもかかわらず、Zendeskは最終的にこのバグバウンティ報告への報奨金支払いを行わないと決定した
- 著者が脆弱性を影響を受けた企業と共有したことで、HackerOneの公開ガイドラインに違反したため
結論
- 小さなメールのバグが、世界最大級企業の内部システム侵入につながった
- Zendeskは最終的に脆弱性を修正したが、拒否、遅い対応、無視など、その過程は厳しいものだった
- バグハンティングの現実は、勝つこともあれば負けることもあるということ
GN⁺の意見
- Zendeskの一件は、サードパーティ製ソリューションを無批判に導入する危険性を示している。どれほど有名企業の製品でも、セキュリティレビューは不可欠
- 主要企業の内部システム乗っ取りは甚大な被害を招きうるため、Zendeskの鈍い対応は極めて無責任だった。バウンティ支払い拒否でセキュリティ研究者の意欲を削ぐのも望ましくない
- 企業はSSOドメインを慎重に選び、メール検証プロセスを強化すべき。DMARC、SPF、DKIMなどのメール認証技術を積極活用する必要がある
- HackerOneの公開ガイドラインは研究者の立場から見ると硬直的すぎる。深刻な脆弱性は迅速な共有が必要なため、状況に応じた柔軟な適用が求められる
- バグハンティングは企業と研究者の双方にとってwin-winであるべき。研究者の善意と努力を尊重し、適切に報いる文化が根付くことを期待したい
2件のコメント
こういう問題を見ると、セキュリティ関連のソリューションを持ってくるよりも、セキュリティの専門家を迎え入れて育成するほうが、はるかに良さそうに見えますね（涙）
Hacker Newsの意見
あるユーザーは、2024年6月にZendesk、Apple、Slackへ同じバグを報告しており、彼らがそのバグに報奨金を支払わなかった理由は、おそらく自分が最初ではなかったからだろうと述べている
別のユーザーは、ZendeskがGoogle検索結果を汚染するために「Zendesk Alternative」という偽のバンドを作ったと主張している
あるユーザーは、Zendeskがバグに対する報奨を拒否したことは残念であり、これは大規模な報奨金プログラムに参加したくなくなるやり方だと述べている
また別のユーザーは、非効率なバグバウンティプログラムがソフトウェアサービスに悪影響を与えると述べている
あるユーザーは、Zendeskが13億ドルの売上を上げる会社であるにもかかわらず報奨を支払わないのは短期的な視点だと批判している
別のユーザーは、Zendeskがバグの影響を正しく理解していなかったために無視したのだろうと説明している
あるユーザーは、ZendeskがAppleアカウント確認メールの問題だけを修正し、根本的な問題は解決していないと指摘している
2つの別個の脆弱性が存在すると説明している
Zendeskが問題を無視し、非公開のままにしようとした点を批判している
最後に、あるユーザーはZendeskがバグへの報奨を拒否したことを批判し、報告者がすべての手順を正しく踏んでいたことを強調している