セキュリティの重要課題:もしもバグを発見したら、どうすべきか

** 本記事は、Serious Security: How to make sure you don’t miss bug reports! の翻訳です。最新の情報は英語記事をご覧ください。**

これまでのセキュリティの重要課題シリーズの記事では、専門的な内容について取り上げることが多いのですが、専門用語を使用せずに分かりやすくお伝えするようにしてきました。

過去には、Web サイトのハッキングとその回避方法、数値解析とその正しい使い方、ポスト量子暗号と使用する理由などのトピックを取り上げました。

バグレポートの報告先

今回のセキュリティの重要課題で取り上げるトピックは、まったく技術的なものではありません。

この記事は、サイバーセキュリティの担当者の仕事をやりやすくするにはどうすれば良いのか、そしてやりやすくなるとどのようなメリットが得られるのかについて説明します。

最近では、多くの企業が脆弱性の発見に報奨金制度を導入したり、外部の会社にバグの検出を依頼したりしています。これは、企業が自社の製品やサービスのセキュリティ上の脆弱性について知りたいと真剣に考えていることを示しています。

しかし、それらの企業も「どこに報告するか?」、「誰に報告するか?」、「どうやって報告するのか?」といったことを明示するところまでには注意が及んでいないようです。

特に第三者のバグハンター会社が関与している場合、バグ発見者が自分で報告先を探さなければならないとしたら、あまり良い結果をもたらさないでしょう。

まず、バグ発見者の中には、発見した問題を伝える際に外部のサービスを介さず、当事者と直接連絡するのを好む者もいます。

他にも、懸賞金に興味がない者、サードパーティのプロバイダに別のアカウントを作成する手間を省きたい者、簡便な個人間の連絡を取りたがる者などもいます。

また、バグハンティングを専業としている研究者であっても、報告先選択をどこから着手すれば良いか知っておく必要があります。連絡先が決まっているのであれば、誰にとってもバグ報告が容易になります。

大企業の機密情報を手に入れてしまったらどうするか?

先日、「どこに報告するか」という問題にまつわる事件がメディアで面白おかしく取り上げられました。イギリスの開発者 Connor Greig 氏がファーストフード大手のマクドナルドからプロモーション用のメールを受け取ったときのことです。

そこでは、認証情報を含む Azure データベースの接続テキストが大量に含まれていました。

一見すると、 Greig 氏のメールを生成するために使用されたデータベースクエリの機密入力データの一部が、彼に送られた出力データの中で誤って繰り返され、それがメールの本文に不用意に記載されてしまったようです。

例えるなら、ある Web メールサービスにログインするために入力したパスワードを、それ以後送信するすべてのメールの本文に貼り付けてしまうようなものです。

Greig 氏は、ソーシャルメディアのクリエイターの収益と分析の改善を目的とした Web ベースの企業を経営しています。そのため、彼は、自分が本来見るべきではないデータを見ていることに気付いただけでなく、この問題を報告して再発を防止することの重要性を認識していました。

結果から言うと、電話番号やメールアドレスなど容易に見つかった連絡先への連絡を試みたようですが、正しい報告先を見つけることはできませんでした。

バグレポートなどのコメントを、「サイバーセキュリティ問題に関する通知を送るのに適した場所」と明記されていないメールアドレスに送ることの問題点は、そのメールが誰かに届いたかどうか、あるいは届いたとしても受信者自身がそのメールをどうすべきかを把握しているかどうか確信が持てないことです。つまり、バグレポートの報告先が簡単には見つからないということは、大企業であれば、企業内でも全く同じ問題が起きている可能性があるということです。問題が解決されないまま、バグレポートがたらいまわしにされているかもしれません。

サイバーセキュリティ版のダンスダンスレボリューション

そこで Greig 氏は、一風変わった方法をとりました。

TikTok でバグレポートを公開したのです。

@creatorsphereco

I don’t want these. Please answer emails McD. #cybersecurity #mcdonalds #disclosure #help #techtok #monopoly

♬ original sound – CreatorSphere.co

https://www.tiktok.com/embed.js

と言ってもバグレポートについての歌を投稿したわけではなく、動画でこう呼びかけました。「興味のある方がいたらご連絡ください。私はマクドナルド社への扉を開く鍵を持っています。そして私にはその鍵は不要です」

ニュースサイト「The Register」によると、 Greig 氏の動画はマクドナルドの関係者の目に留まりましたが、マクドナルド側は当初、バグレポートを「疑わしい」ものとして扱ったため (状況を考えれば当然かもしれませんが)、対応がさらに遅れることになってしまいました。

最終的に Greig 氏は、問題の担当者と連絡を取ることができました。

しかし、もし彼が最初から誰に問題を報告すべきか知っていたとしたら問題解決にはここまでの時間は掛からなかったでしょう。

対策

セキュリティ専門家にどこから報告に着手すれば良いかを知らせるための、シンプルでほぼ標準化された方法があります。

現在、「A File Format to Aid in Security Vulnerability Disclosure ( セキュリティ脆弱性の開示を支援するファイルフォーマット)」と題されたインターネット標準のドラフトが作成されており、提案されたシステムはすでに IANA (Internet Assigned Numbers Authority) によって Well-Known URI と呼ばれるものとして承認されています。)

ファイル名は security.txt と短く簡単に覚えることができます。シンプルなテキストのみのダウンロードで、企業のドメインのトップレベルに置くことができます。たとえばソフォスでは https://sophos.com/security.txt のようになります。

このファイルには数多く情報行を入れることができ、その中で最も重要なのは、ソフォスが使用しているファイルにあるように、1つまたは複数の Contact 項目のグループです。[2021-09-13T16:00Z]

Contact: security-alert@sophos.com 
Contact: https://www.sophos.com/security 
Contact: https://bugcrowd.com/sophos 
Acknowledgement: https://www.sophos.com/en-us/legal/sophos-responsible-disclosure-policy/thanks.aspx
Disclosure: https://www.sophos.com/security

連絡手段として、直接連絡を取りたい人のための社内メールアドレスから、セキュリティレポートを提出して正式な懸賞金請求をすることに興味がある人のためのサードパーティのWeb サイトまで、3つの異なる方法を提供しています。

また、ソフォスが契約しているブログホスティング会社である Automattic 社 (WordPress の所有者: https://automattic.com/.well-known/security.txt) のように、IANA の Well-Known URI のために予約された特別な場所に security.txt ファイルを置くこともできます。

Well-Known URI の概念とその置き場所については、RFC 8615 で定義されています。

Web サイトをお持ちの方は、今すぐに security.txt ファイルを追加してみてはいかがでしょうか。

すぐに簡単にできますし、サイバーセキュリティ上の緊急事態が起きたときに、解決までにかかる時間を数時間から数日間短縮できるかもしれません。