非公開のセキュリティリンクは、本当に公開アクセス不可能なのか？
(vin01.github.io)- urlscan.io、Hybrid Analysis、Cloudflare Radar URL Scanner のような URL/マルウェア分析サービス は脅威インテリジェンス共有のためにリンクを保存するが、ユーザーのミスや設定不備のあるスキャナーによって 機微なリンク が公開データとして残る可能性がある
- Dropbox、iCloud、AWS S3、Zoom、OneDrive、Airtable、パスワード再設定リンク、OAuth ログインリンクのように、URL 自体がアクセス権として使われるサービス が特に影響を受けやすい
- すべてのリンクが直ちに露出するわけではないが、税務書類、請求書、写真、業務コミュニケーション、onetimesecret で共有された秘密、スマートホーム・会議録画のような資料が実際に見つかっている
- urlscan Pro は Public だけでなく Unlisted スキャン も有料顧客に表示し、TheHive の Cortex-Analyzers 設定のように意図せず unlisted として送信される経路が存在しうる
- 直近24時間の urlscan.io のスキャン数は Public 398,563件、Unlisted 328,147件、Private 955,432件で、カナリアトークン実験でも送信後1時間以内のアクセスが確認されており、スキャン可視性の管理 が必要である
URL 分析サービスに残る機微なリンク
- urlscan.io、Hybrid Analysis、Cloudflare Radar URL Scanner は URL とマルウェア分析のために多数のリンクを保存している
- 問題は、この保存先に 非公開・機微なリンク も一緒に入ってしまう可能性があること
- ユーザーが公開情報になることを知らずに機微なリンクをスキャンへ送信する
- 設定を誤ったスキャナーや拡張機能が、メールからスキャンした非公開リンクを公開データとして送信する
露出しうるリンクと資料
- 見つかったリンクには、各種サービスの 共有 URL と認証関連 URL が含まれていた
- Dropbox、iCloud、Sync、Egnyte、Ionos Hidrive、AWS S3 などのクラウドストレージのファイル共有
- Western Digital Mycloud のようなクラウド接続 NAS
- Slido、Zoom、OneDrive、Airtable のような企業向けコミュニケーションツール
- パスワード再設定リンクと OAuth ログインリンク
- こうしたサービスでは、セキュリティのためにランダム識別子を含む 単一の非公開リンク でアクセスを許可する場合が多い
- 一部のリンクはパスワードやパスフレーズで追加保護されているため、リンクにアクセスできても直ちにデータが露出するとは限らない
- 実際に見つかった機微なコンテンツは次のとおり
- 税務書類、請求書、写真、業務コミュニケーションなどの非公開ファイル
- onetimesecret で共有された秘密
- スマートホーム機器の録画
- クラウドに保存された会議録画
送信経路と責任の隙間
- urlscan.io で確認された多くの送信には falconsandbox タグが付いており、これをきっかけに Hybrid Analysis まで分析範囲が広がった
- Cloudflare Radar もより広く使われる可能性があり、すでに一部の非公開リンクを公開データとして含んでいる
- Hybrid Analysis の利用規約には、ユーザー送信コンテンツを分析・公開・共有でき、送信物や自動生成レポートに偶然含まれた情報について責任を負わないと明記されている
- urlscan.io の利用規約も、ユーザーコンテンツや行為について責任を負わず、アカウント配下で公開されたコンテンツと活動はユーザーの責任であるとしている
- 既存コンテンツを見直して機微なリンクを表示・削除する 明確なメカニズム はないようで、自動化も簡単ではない可能性がある
- Positive Security の分析 は、urlscan.io を対象にカナリアトークンを使って自動化された送信元を検知し、メール内の悪意あるリンクをスキャンするセキュリティツールが原因である可能性を扱っている
- 同じ挙動はカナリアリンクでも検証された
Unlisted スキャンと urlscan Pro のアクセス
- urlscan Pro は有料ユーザーと企業に対し、Public だけでなく Unlisted スキャン まで含む、より広い範囲のスキャンアクセスを提供している
- urlscan.io における Unlisted は公開ページや検索結果には表示されないが、urlscan Pro プラットフォームの顧客には表示される状態である
- urlscan Pro の顧客は、検証済みのセキュリティ研究者または信頼できる企業に限定されると案内されている
- TheHive の Cortex-Analyzers は、意図しない露出経路を示す一例である
- urlscan.io アナライザーで
public:on設定を明示的に使用している - この設定のため、urlscan アカウントの可視性が Private でもリンクが unlisted として表示される可能性がある
- 関連コードは Cortex-Analyzers の urlscan.py にある
- urlscan.io アナライザーで
- この場合、データが完全に公開されるわけではなくても urlscan Pro ユーザーには見えるため、より機微な情報が露出する可能性は残る
スキャン数とカナリアトークンの結果
- 直近24時間時点の urlscan.io のスキャン数は次のとおり
Public: 398,563件Unlisted: 328,147件Private: 955,432件
- カナリアトークンで確認したアクセス結果は次のとおり
- urlscan.io に
unlistedとして送信したリンクは、送信後1時間以内に 12回アクセス された - Hybrid Analysis にブラウザーではなく
APIで送信したリンクは、送信後1時間以内に 10回アクセス された - 一部の IP アドレスは両サービスに送信された固有リンクへ同時にアクセスしており、送信元 IP 匿名化サービスを利用していた
- urlscan.io に
- 当該 IP アドレス一覧は 別ファイル として公開されている
機微なリンクの削除と利用時の注意点
- urlscan.io と Hybrid Analysis は、リンクを報告して削除できる手順を提供している
- Hybrid Analysis は削除と共有範囲がより複雑である
- Public Sandbox に送信されたすべてのファイルは検索可能で、世界中に提供される
- 「Do not share my sample with the community」チェックボックスを選んでも、スクリーンショットと実際のレポートは引き続き提供される
- 「do not share」は実際の入力サンプルにのみ適用される
- サービスを使う際は、まず スキャン可視性 を確認すべきである
- こうした URL データベースからリンクやファイルにアクセスする場合、フィッシングの試み、実際のマルウェアファイル、悪意あるリンクに遭遇する可能性がある
- アクセスが必要なら サンドボックス環境 で確認すべきである
1件のコメント
Hacker Newsの意見
根本的な問題は、アクセス制御のないリンクが、公開識別子のインデックスがないという理由だけで非公開だと見なされていることにある
先月も、バケット経由でAWSアカウントIDを見つける話がHNでかなり盛り上がり[0]、コメントでの合意は、アカウント識別子が非公開であるという前提にセキュリティを期待するのは誤りだ、という方向だった
ここにも同じ概念が当てはまり、新しいセキュリティ問題というより、別の**検索演算子ベースの探索（dorking）**手法にすぎない
[0]: https://news.ycombinator.com/item?id=39512896
理論上、256桁の16進数リンク、つまり1024ビットは、32文字のユーザー名と32文字のパスワードよりはるかに推測しにくい
https://site.com/[256chars] は2^1024通りなので、総当たりは事実上不可能
一方、https://site,com/[32chars] と32文字のパスワードは2^256通りで、これもほぼ不可能だが、前者よりは可能性がある
https://site,com/[32chars][32chars] のように見るわけだ
ただし、前者のほうが当てにくいとしても、URLはパスワードよりはるかに多く漏えいする
ここでいうメッセージには、メール、DM、ドキュメントに貼り付けたリンクまで広く含まれる
気持ち悪かったので結局別の方法を選んだが、URLの中に「秘密」があることと、URLリクエスト時に送信するトークンの中に秘密があることが、実際どれほど違うのかを考え続けることになった
私の結論は、トークンは顧客ごとに発行でき、アクセスログを監視して怪しい挙動を見つけたら失効できる、という点にある
また、他の人も言っているように、ファイル名一覧を秘密に保つことをどれほど重要視するかという考え方も違う
Amazonがミスし得る規模を考えると、公開バケットのファイル名一覧を偶然露出してしまうことは、ユーザーの99%が気にしないような事柄なので、優先度は低そうに見える
当然、その競争にはこちらの会社が負けた
それ以来、AWSを扱うたびに、バケット名はたいてい - の形式にする、という小さな教訓になった
本当に非公開であるべきなら、プロジェクト名も暗号化し、「親しみやすい」名前でバケットを列挙するスクリプトを提供すればよい
ホスティングサービスには常に奇妙なトレードオフがあり、技術的に完璧な方法である完全ランダムな識別子は、不完全な方法である説明的な名前よりも、運用負荷がはるかに大きくなる可能性が高い
Bitwarden Sendは他人に渡せるリンクを作成し、
#の後ろに長いランダム文字列が付く定期的に使っているので、セキュリティ上の問題があるのか知りたい
少なくともリンクは破棄でき、数日後に自動失効させることもできるが、一般的なパスワードは通常そのようには動作しない
非公開共有リンクを作るなら、URLのハッシュ部分に非公開値を保存すればよい
ハッシュはDNSクエリやHTTPリクエストで送信されない
たとえば links.com?token= にアクセスすると、そのリンクは検索パラメータまで含めて送信され、Cloudflareのような中間者に保存される可能性がある
一方、links.com# にアクセスした場合、ハッシュ部分はブラウザの外へ出ていかない
ハッシュ部分のデータを扱うときは、URL Safe Base64文字列にエンコードすると便利
つまり、JS Object ↔ JSON String ↔ URL Safe Base 64 String という流れ
他はその通りで、ただこのHTTPS暗号化のニュアンスを付け加えたかった
フラグメントに入れるのは役に立つが、完璧ではない
理想論として言っているのではなく、実際にフラグメント内の非公開トークンがこのように漏えいするのを何度も見ている
[https://example.com?token=](<https://example.com?token=<secret>>;) は「example.com」だけでDNSクエリが出るはず
メール内のリンクをたどるボットはJavaScriptを実行するのか？ JavaScriptが誘導したPOSTによって実際の動作を有効化してしまう危険はあるのか？
高速なリダイレクトループの一部ではないリンクは、共有のためにコピー＆ペーストされるほかない
URLはもともとそのためのもので、普遍的であり、何らかのプロトコルで提供されるリソースへアクセスしやすくする
寿命が短くないものへのアクセス制御は、URLの外側で行うべき
エンドツーエンド暗号化ではないチャネルでリンクを共有すると、そのURLに最初にアクセスする主体は受信者ではなくチャネルサービスになる
Bitwardenがユーザー体験のためにファビコンを探すように正当な場合もあれば、Facebook Messengerのクローラーが非公開メッセージで何が共有されているのかをもっと知りたがるように悪意のある場合もある
こうしたスキャナーツールによってユーザー体験が良くなることはないだろう
スキャン結果が公開されると明示すれば、一部のユーザーはサービスを使う前に考え直すだろうし、無料ユーザーであれプロライセンスのユーザーであれ、事業にはマイナスだからだ
無制限に使える「非公開」リンクは、いつも少し疑わしいと思っていた
結局のところ、曖昧さに依存するセキュリティだ
Google ドキュメントのようなものを共有するときは、少なくとも「URL を知っている全員がアクセス可能」と明示するオプションがある
自分が作ったシステムでこういうタイプが必要なときは、たいてい有効期間が数分しかない署名付き URLを使っていた
URL はおおむね実装の詳細で、ユーザーに直接見せることはないが、ブラウザのデバッグ画面では見える可能性がある
インターネット上でこうしたものが URL 内のランダム文字列以外で保護されていないなら、実際には非公開ではない
探せば出てくるインターネット接続の Web カメラと同じ話だ
これはもう分かっていたことではないのか？ なぜ「誰に責任があるのか」セクションでこの点にまったく触れていないのか分からない
すべてに最高レベルのセキュリティが必要なわけではなく、場合によっては広範な共有を防ぐための障壁だけあればよい
たとえば写真ギャラリーで「リンク共有を作成」を押して写真リンクを誰かに送るとき、その人にパスワードを入力してほしいとは思わない
リンクを開けば写真が見えるべきで、その用途なら問題ない
ここにある例の一つがまさにそのケースであり、そのユースケースには合っている
プライバシー上の懸念という点でも、ログイン手順があったとしても、エンドユーザーはその時点でスクリーンショットを再共有できる
セキュリティがユースケースに合っているということだ
ユーザーは今や写真リンクを持っていて再共有もできるが、意図的にはそうしないと信頼している状況だ
ここでの大きな問題はリンク自体というより、セキュリティ分析ツールが、ユーザーがメールで受け取ったすべてのリンクをスキャンし、そのコミュニティの他のユーザーにもアクセス可能にしてしまう点だ
私が誰かに写真を送るときに意図したものより、はるかに大規模な再共有になる
このメールベース認証問題の回避策は、パスワードアカウント作成まで行かずに、一時的なワンタイムコードを使うことだ
そうすれば URL が誤って共有されても大きな問題にはならない
話題から外れるが、リンク先が Cloudflare Radar になっていて、このサービスはどうやら 1.1.1.1 のデータをマイニングしているように見える
1.1.1.1 はユーザーデータをいかなる目的にも使わないと理解していた
もっと詳しい人に説明してほしい。次の二つは何が違うのか？
どちらも同じ総当たり攻撃対策やレート制限がある、またはどちらにもないと仮定すると、なぜ 1 は 2 より安全なのか？
実際には違いがある
所有ベースの秘密と知識ベースの秘密は異なる
URL は持っているものなので、アクセス可能な場所に残しておくと奪われる可能性がある
パスワードは知っているものであり、適切に管理すれば奪われない。ただし、鉛パイプ攻撃は例外だ
もう一つは生体ベースで、網膜や指紋スキャンがこれに当たる
(1) は認証のために別経路の情報が必要で、人々が安全に保管することに慣れている情報だ
一方、(2) の URL は URL として扱われる
URL は頻繁にログに残り、記録され、共有され、あちこちに渡される
たとえば企業のファイアウォールが、あるサービスへのログインに使ったユーザー名とパスワードを記録するなら明らかに悪いが、アクセスした URL を記録するのは問題なさそうに見える可能性が高い
後者は例にすぎず、TLS のエンドツーエンド保証があるため、本来はどちらにもアクセスできてはいけない
さらに domain.com/12-char-password が HTTPS なしでリクエストされると、リダイレクトがあっても最初のリクエストは暗号化されないまま送信され、中間者攻撃が可能になる
一方、ログインページでは、パスワード送信が必ず HTTPS 上でのみ行われるよう保証する方法がより多い
大きな問題の一つは、多くのロギングアプリケーションが URL 全体をどこかに記録する点で、そうすると事実上「パスワード」をログに残すことになる
非公開の airtable.com アプリにアップロードするすべてのメディアと写真は公開リンクだ
URL を知っていれば認証なしでアクセスできる
通常の画像タグでは、API リクエストで fetch() を使うときのように、リクエストにトークン入りの Authorization ヘッダーを設定できない
可能な選択肢は URL にトークンを追加するか、Cookie 認証を使うことだけだ
Cookie 認証は CDN が同じドメインにある場合にしか動作せず、サブドメインでさえ多くの場合問題になり得る
潜在的に問題になり得るという点には同意する
Zoom の会議リンクでは、パスワードをクエリパラメータとして付けることが多い
このリンクは「非公開のセキュアな」リンクなのか？ パスワードが抜けたリンクは「非公開のセキュアな」リンクなのか？
URL が別の場所に現れるころには、その会議はすでに終わって消えているはずだからだ
しかし現実には誰も気にせず、あれこれ入力しなくても済む「クリックして参加」を望む
以前の「会議 ID だけを使う」方式は、あまりにも簡単に推測できた