バグ報奨金を要求する恐喝メール: その方法と送り主の目的とは

約 10 年前に、Bugcrowd 社と HackerOne 社がサービスの提供を開始して以来、バグ報奨金という概念がメインストリームとなり、幾千もの人がこのサービスで賞金稼ぎを始めています。しかし、まとまった額を稼ぐためには非常に高いスキルが必要です。また、誰にでも容易に見つかるバグはすでに発見されています。加えて、バグ報奨金プログラムを用意できるほど実力のある組織は、虚偽の申請にはまず騙されません。

プログラムを導入している組織ではそのような報告をフィルタリングしており、それがなぜ支払いの対象にならないのかを説明したプログラム概要やポリシーを提出者に示します。しかしバグ報奨金プログラムを持たない組織では、送られてくる「セキュリティ勧告」に対処する準備ができていないことがあります。報告されたリスクの重大性を判断できず、軽微なバグはもとより、バグ報告にはそもそも報酬を払わない、ということを説明できない場合があります。

これが「ベグバウンティ」の問題です。数週間前に記事を執筆したところ、読者の一部から反響がありました。本来害が無い、あるいは何の意味もない「バグ」の報告に対して報酬を求めるという手口は、おおいに流行っているようです。

無差別攻撃

ベグバウンティの流行は、インターネット上の他の多くの流行と同様に、SNS の影響が大きいように見受けられます。SNS 上では多くの人がバグ賞金稼ぎとして正規のプログラムでお金を稼いだ経験を共有しています。これがきっかけで、同じ方法でお金を稼ぎたいと思う人が一気に増えました。

中には、それなりの数のフォロワーを獲得したため、その名声を利用してトレーニングやペネトレーションテストのサービスを始めた賞金稼ぎもいます。特権を最大限に利用するために、フォロワーに対して、支払いの対象になりそうなものは発見次第何であれ報告することから始めるように、と勧めているケースも多くあります。脆弱性を利用してお金持ちになるためには、質より量が重要だ、というのが彼らの考えです。

サーチボットと暗号化

先週、筆者が今まで見聞きした中でも特に馬鹿馬鹿しい情報提供がありました。この人物は robots.txt ファイルがあることが脆弱性だと考えたようですが、これは検索エンジンにインデックスされたくないものを検索ボットに伝えるためのファイルです。非常に低レベルな言い分です。

他には、フランスの大手メディア企業を狙ったバグ報奨金要求がありました。やり取りの内容を見る限り、報告者が相手の企業について理解していたとは思えませんが、この人物は当該企業の Web サイトが「弱い暗号化」に対して脆弱であることを発見した、という主張から交渉を始めています。

報告には、Qualys SSL Labs のストックレポートのスクリーンショットとリンクが記載されています。暗号化が弱いという点は事実ですが、因果関係を見出すことはできず、これ自体を脆弱性と考えるのは無理があります。

このメッセージの送信元は Gmail で、次の思わせぶりな文言で結ばれています。「ご案内。貴社の Web サイトにはまだ他にもバグがあります。詳細についてはご返信ください」

追って届いたメールでは、次のように述べています。「その他のバグや脆弱性を Web サイト上に発見しています。これをお教えした場合に報奨金がいただけるかどうか、お知らせ願います。」

受信者は、報告者にまず感謝を伝えたのち、個人への支払いには応じられず、支払いが可能なのはバグが報酬に値するもので、かつ企業が相手である場合に限る旨を説明しました。

報告者は次の返信で、直接的に金銭を要求しています。「事情はお察ししますが、我々のチームは非常に多くの労力を費やして貴社の Web サイトのバグを発見しました。その他のバグも発見しています。もし 100～150 ドルの僅かな報酬をいただければ、すべてのレポートをお送りすることができます」

再び、企業宛にしか支払いはできないことを伝えると、バグ報告者は IT 担当者に Web サイトを提示してきました。しかしそれは大部分が Wikipedia から切り貼りしたテキストと、簡単な CMS で作成されたサイトでした。法的に登録された会社でもなさそうです。

IT 担当者は再度、企業からの請求書が必要である旨と、請求書の宛先を送りました。すると数日後、賞金稼ぎからの返信があり、出版物 (?) の 2 日分の購読料を要求されました。

面白いことに、この報告者のアカウントは、被害にあった企業に連絡を取った直後に Google によって停止されています。再び企業に連絡が来たときには、アドレスを少し変えただけの別の Gmail アカウントを使用していました。

この人物は、相手の会社の Web サイトにある脆弱な TLS 暗号化を報告しておきながら、自身の「会社」の Web サイトには一切暗号化を施していないことにもご注目ください。

筆者がこの人物についての調査を終える前に、また別の人物が同じ会社に「貴社サイトの脆弱性について注意を喚起します」とメッセージを送ってきました。このメッセージの行く末はご想像の通りで、対応をしても時間の無駄でしょう。

トロールに餌を与えるな、不正な要求を助長するな、不具合の原因はいつでも DNS。この 3 つこそ、2021 年の IT 業界を生きるための教訓かもしれません。