バグ賞金稼ぎに報酬を与えた後の予想外な結末

自分では良いことをしているつもりでも、悪い結果になって返ってくることがあります。筆者は TYPO3 (ヨーロッパで人気のオープンソースの Web コンテンツ管理システム) のセキュリティチームで働くソフトウェア開発者 Oliver 氏から連絡を受けました。

Oliver 氏は、他の多くのオープンソース開発者と同じく、プロジェクトにパートタイムで参加しています。TYPO3 には彼の他に 5 人のメンバーがいます。週におよそ 5 つのセキュリティレポートを受け取るのが通常で、TYPO3 が複雑な PHP アプリケーションであることを考えればこれは妥当な数字です。

2020 年の 7 月、TYPO3 は、筆者が以前の記事で解説したものと同様の報告を大量に受信していることに気がつきました。この時点で週あたりの数は 10 から 15 件に増えていました。2021 年の 2 月には、爆発的に提出数が増えましたが、それについては後ほど見ていきます。

Oliver 氏の同僚は今年 2 月に起きた報告数急増の前兆として、Jira インスタンスをホストする Apache Tomcat サーバーからバージョンを判別できる文字列が引き出せる、というバグレポートに対応しています。これは脆弱性とは呼べない事象ですが、最新バージョンでないことや、既知のエクスプロイトの影響を受けやすいバージョンであることを攻撃者に教えないためにも、正確なバージョン名は公開しない方が、プラクティスとしては優れています。

TYPO3 は親切心から、脆弱性について教えてくれた情報提供者にブランドロゴの入ったギフトを送ろうと考えました。しかしチームはまだ、この人物が Twitter で 13,000 人以上のフォロワーを集め、バグ報奨金の稼ぎ方を教えるメンターであることを知りませんでした。

ギフトを受け取った情報提供者はすぐさまこれについてツイートしています。「@typo3 から素晴らしいギフトをもらいました。実に素早い対応です」同日、彼は次のようにもツイートしています。「報奨金稼ぎをどのように学んだか。結論としては、2 か月頑張っただけです。最初の月は、毎日 20 件のバグを報告すること。バグの重大性は問いません。見つけたものはすべて報告。次の月は、毎日 5 件のバグを、質の高いレポートとともに報告します」

このツイートに「いいね!」を押したユーザーの何人かがすぐさま、他の Web サーバーやインターネットに接続しているアセットでもサーバーのバージョン文字列を見られると主張するバグレポートを提出しました。面白いことに、TYPO3 のソースコードが Web サイトからダウンロード可能である、と指摘する脆弱性レポートを提出した人さえいました。オープンソースのプロジェクトですから、ソースコードがダウンロード可能なのは当然です。TYPO3 に感謝を表明する問題のツイートの後、TYPO3 のセキュリティチームに届く報告の数は週に 5 件から、1 日 10～15 件以上に増加しました。

厳密に証明できることではありませんが、この報告者たちが使用したと思われるもう 1 つの手口は、同じ問題について異なる ID から複数回報告し、何度も報酬を得ようとするものです。

最初の例は、保守されていない古いインフラストラクチャに対して攻撃的なペネトレーションテストのスクリプトを実行し、DoS 攻撃をしたというものです。その結果、ホスト上の Nginx Web サーバーがバージョンが分かる文字列を含むエラーメッセージを報告しました。この人物は、バグ報奨金稼ぎとしては珍しく、デスクトップ PC ではなく Android 端末上でのスクリーンショットを添付したレポートを提出しました。

This reporter’s email address appeared to be named after a popular Bangladeshi film. この報告者のメールアドレスは、バングラデシュで人気の映画のタイトル (『দেয়র কথা』) に由来しているようです。タイムゾーンと IP アドレスで、バングラデシュからの発信であることも確認されています。

その約 60 分後にも、同一バージョンの Android で撮られたスクリーンショットが添付されてほぼ同じ内容の報告がありました。提供者の名前は「Royel」で、タイムゾーンは BDT (バングラデシュ時間)、1 つ前の報告と同じ奇妙なフレーズ「Version is disclosing 😊」も含まれていました。

TYPO3 チームは、バージョン情報が表示される原因となっていたいくつかの問題を解決することで対応し、エラーの原因となったアプリケーションをどのようにクラッシュさせたのかを知るため、また「重大な問題」という主張の詳細を確かめるべく、報告者に詳細な情報を要求しました。すると返ってきたのは、「バグへの報酬を要求する」という返信でした。

Oliver 氏は、チームが主にプラットフォームへのリスクについて提示された事実に基づいてどのように脅威の深刻度を評価しているか説明し、もう一度詳細を尋ねました。しかし怒った情報提供者は、ここで脅迫に転じました。これはもはや、迷惑行為ではなく犯罪です。

「もし提供したバグへの報酬を払わないのであれば、会社の情報を Facebook、Instagram、Telegram、LinkedIn、Twitter、Youtube に暴露します。

これを投稿して、誰もこのプログラムを報告できないようにします。いいのですね?

報酬をもらえれば嬉しいし、もし報酬がないようであれば、会社の情報をリークします」

これはまるで脅迫の見本のような文章です。しかしこれが通用しないことがわかると、今度は懇願をしはじめました。

悲しいことに、Oliver 氏の体験から導き出される唯一の結論は、「正直者はばかを見る」ということです。最初は、ガイドラインに従わず思いつきのように報告をした賞金稼ぎに対する親切心から始まったのですが、雪だるま式に、ほとんど価値のないバグ報告が、5 倍から 10 倍に増えるという結果を招いてしまいました。

このような行為を積極的に奨励しているグループがあり、手に負えない状況になっているようです。筆者としては、公式に認可されたプログラムを通じて提出されたセキュリティレポートにのみ報酬を出すことをお勧めします。

Bugcrowd や HackerOne のようなサービスではガイドライン策定の支援を行っており、レポートを選別し、有益な情報の比率を高めるためのサービスも有料で提供しています。バグ報奨金の設定をして、製品やサービスの安全性、セキュリティを向上させようとする意欲のある人々にきちんと賞与を与えたい場合には、最適な選択肢です。