公開アクセスできない個人用セキュリティリンク、本当にそうだろうか？
- 人気のマルウェア/URL分析ツールである urlscan.io、Hybrid Analysis、Cloudflare Radar URL Scanner は、情報収集と共有のために大量のリンクを保存している。
- こうしたサービスが、ユーザーによって誤って送信されたり、設定ミスのあるスキャナーや拡張機能によって公開データとしてスキャンされた個人的かつ機微なリンクを保存していることは、あまり広く知られていない。
どんなリンクのこと？
- クラウドストレージツール（
Dropbox、iCloud、Sync、Egnyte、Ionos Hidrive、AWS S3 など）で共有されたファイル。
- クラウド接続型NASツール（
Western Digital Mycloud など）。
- 企業向けコミュニケーション（
Slido、Zoom、Onedrive、Airtable など）。
- パスワード再設定リンク、Oauthログインリンクなど。
- これらのサービスに共通しているのは、ランダムな識別子を含む単一の個別リンクでサービスにアクセスできるようにしている点である。場合によってはパスワードやパスフレーズで追加保護されており、その場合はリンクにアクセスできてもデータ漏えいにはつながらない。
誰が責任を負うべきか？
- Hybrid Analysis と urlscan.io の利用規約によれば、送信されたコンテンツの責任はユーザーにあり、機微なリンクを確認して削除する仕組みは存在しない。
- これを自動化で実装するのも簡単ではないかもしれない。
- セキュリティ研究者の立場でも、こうしたリンクの出どころを突き止めるのは難しい。
私たちは脅威ハンター！ すべてのリンクは我々のものだ！
- urlscan Pro は、有料ユーザー/企業に対して
Public だけでなく Unlisted スキャンへのアクセスも許可している。
Unlisted は公開ページや検索結果には表示されないが、urlscan Pro プラットフォームの顧客には見える。- TheHive の Cortex-Analyzers は、urlscan.io アナライザーで
public:on 設定を明示的に使用し、リンクが unlisted として表示されるようにしている。
- データは urlscan Pro ユーザーに対して公開はされていないが、アクセスは可能であるため、より多くの機微な情報が漏れるリスクがある。
機微なリンクはどうやって削除できる？
- Urlscan と Hybrid Analysis では、リンクにフラグを付けて削除を依頼できる。
- Hybrid Analysis の場合、公開サンドボックスに提出されたすべてのファイルが検索可能で、世界中に公開される。
結論
- この問題が今後も続くことは確実だが、スキャンをデフォルトで非公開に保つことが最善の解決策かもしれない。ただし、それはセキュリティコミュニティにおける脅威インテリジェンスや分析共有の慣行の目的には合致しない。
- こうしたサービスを利用する際は、スキャンの可視性に注意する必要がある。
免責事項
- URLデータベースからこうしたリンク/ファイルにアクセスすることを選ぶ場合は、実際の悪意あるファイルやリンクに注意すること。
- 一部は単なるフィッシングの試みかもしれず、実際のマルウェアを含んでいる可能性がある。
- サンドボックス環境の利用が推奨される。
役立つリンク
- urlscan.io の SOAR spot: Chatty security tools leaking private data (2022)
- urlscan.io Search API Reference
- Falcon Sandbox Public API
- Cloudflare Radar URL Scanner
GN⁺の見解
- この記事は、セキュリティツールがどのようにして機微な情報を意図せず公開してしまう可能性があるかを示しており、セキュリティ研究者と一般ユーザーの双方に警鐘を鳴らしている。
- こうした問題は、ユーザーのミスやツールの設定不備によって発生しうるものであり、セキュリティコミュニティ内で機微情報を扱う際に、より大きな注意と責任が求められることを示している。
- この記事はまた、個人や企業が自らのデータを保護するためにどのような対策を取るべきかという重要性も強調している。
- 批判的な観点から見ると、このような漏えいは個人のプライバシー侵害や企業の機密保持に深刻な脅威となりうるもので、セキュリティツールやサービスの信頼性に疑問を投げかける可能性がある。
- 類似の機能を提供する他のプロジェクトとしては、VirusTotal や Any.run のようなマルウェア分析プラットフォームがあり、こうしたサービスを使う際には常にデータが公開されるかどうかを慎重に確認する必要がある。
1件のコメント
Hacker Newsの意見
根本的な問題はリンクにアクセス制御がないことであり、公開インデックスがないからといって私的だと見なされている。バケット経由でAWSアカウントIDを見つける話がHacker Newsで話題になったが、コメント欄で導かれた結論は、アカウント識別子の非公開性をセキュリティの一部として当てにするのは誤ったアプローチだというものだった。これは単なる別の「dorking」の手法にすぎない。
個人的に共有可能なリンクを生成するには、URLのハッシュ部分に秘密情報を保存すべきだ。ハッシュはDNSクエリやHTTPリクエストに含まれない。たとえば、
links.com#<secret>形式のリンクはブラウザの外に出ない。ハッシュ部分のデータはURLセーフなBase64文字列でエンコードするのが望ましい。無制限に使える「プライベート」リンクには以前から常に懐疑的だった。これは単なる隠蔽によるセキュリティだ。Googleドキュメントのように「URLを知っている人なら誰でもアクセスできる」という明示的なオプションがある方がよい。筆者が構築したシステムでは、短寿命の署名付きURLを使っており、このURLはユーザーに直接表示されない。
高速なリダイレクトループの一部ではないリンクはコピーされて共有されることになる。URLは普遍的であり、プロトコル上のリソースへのアクセスを容易にする。十分に短くない寿命を持つものへのアクセス制御は、URLの外側で行われるべきだ。E2EEではないチャネルでリンクを共有する場合、URLに最初にアクセスする主体は送信相手ではなく、そのチャネルのサービスかもしれない。このようなスキャナーツールは、スキャンが公開的であることをユーザーに明示してもUXの改善にはならないだろう。
「メールベース認証」の問題に対する解決策は、アカウントやパスワードを作る段階なしに、URLが誤って共有されても問題にならないワンタイムコードを使うことだ。ユーザーが「プライベート」リンクを訪れると、サイトは時間制限付きのワンタイムコードをメールで再送し、ユーザーはメール所有を確認するために一時コードを入力する。
インターネット上で、URLがランダム文字列以上の保護を持たないなら、それは実質的にプライベートではない。インターネットに接続されたウェブカメラを見つけるのと同じ話だ。私たちはすでにこれを知っているべきだ。「誰が責任を負うべきか」のセクションでこれに触れていないのはなぜなのか。
本題から外れるが、Cloudflare Radarが1.1.1.1からデータをマイニングしているというリンクがある。1.1.1.1はユーザーデータをいかなる目的にも使わないと思っていたのだが？
Zoomの会議リンクはしばしばクエリパラメータとしてパスワードを追加する。このリンクは「プライベートで安全な」リンクなのか？ パスワードなしでも「プライベートで安全な」リンクなのか？
次の2つのケースのうち、どちらがより安全なのか説明できるだろうか？
domain.com/loginユーザー名: John パスワード: 5桁のランダムパスワードdomain.com/12文字のランダムURL両方とも同じランダム性／レート制限による保護がある、またはまったくないと仮定した場合、なぜ1番が2番より安全なのか？private airtable.comアプリにアップロードされたすべてのメディア／写真は公開リンクになっており、URLを知っていれば認証なしでアクセスできる。