チャット/メッセージングアプリのリンクプレビュー機能に潜む問題 30
悪用厳禁 部門より
チャット/メッセージングアプリのリンクプレビュー機能の問題点について、Talal Haj Bakry氏とTommy Mysk氏が18本のアプリを対象とした調査結果を公表している(Myskの記事、 Ars Technicaの記事、 9to5Macの記事、 Mac Rumorsの記事)。
リンクプレビュー生成方法は、送信側で生成・受信側で生成・サーバー上で生成の3種類。最も安全なのはリンクを生成しないことで、テストした中ではSignal(プレビュー無効時)/Threema/TikTok/WeChatが該当する。
比較的安全なのは送信側での生成だ。送信者がリンク先にアクセスすることは避けられないが、受信者はクリックしない限りリンク先ページにアクセスすることはない。テストした中ではiMessage/Signal(プレビュー有効時)/Viber/WhatsAppが該当する。ただし、Viberではプレビュー生成時のダウンロードサイズに制限がなく、バッテリーやデータを大量に消費するなどの問題が発生する可能性もある。
受信側での生成はクリックしなくてもリンク先へのアクセスが発生するため、攻撃者が悪用する可能性もある。テストした中では2本がこの方法だが、情報は非公表になっている。また、2本とも修正前にはデータサイズの制限がなく、Viberと同様の問題が受信側で発生していたとのこと。
サーバーで生成するのはDiscord/Facebook Messenger/Hangouts/Instagram/LINE/LinkedIn/Slack/Twitter/Zoomと非公表1本。この方法では非公開情報をサーバーが取得する可能性がある。中でもFacebook Messenger(画像と動画のみ)とInstagramは取得するデータサイズに制限がない。また、InstagramとLinkedInではサーバー上で任意のJavaScriptコードを実行可能だったとのこと。保存期間についてはSlackのみ30分程度と回答している。
LINEの場合、メッセージをエンドツーエンドで暗号化しているが、リンクはサーバーへ送られる。また、送受信者のIPアドレスをリンク先に送信していたという。LINEは報告を受けてIPアドレスの送信をやめたが、サーバーへのリンク送信は許容範囲内だと回答したそうだ。
いいこと思いついた (スコア:2, おもしろおかしい)
サービス側で余計なことをされないようにURLからhを抜いてttps://のようにすれば
# 昔からあるやつ
Re: (スコア:0)
ttps://www.google.co.jp/
のような文字列を貼ると、大抵はドメイン名を見て判断して
ttps://www.google.co.jp/のように正しく？解釈されます。
プロトコル部をhts://みたいに替えるとか、全部ダメになりました。
Re: (スコア:0)
ついでにwebブラウザーの補完機能でも修正される
どういうこと？ (スコア:1)
LINEの場合、メッセージをエンドツーエンドで暗号化しているが、リンクはサーバーへ送られる。また、送受信者のIPアドレスをリンク先に送信していたという。LINEは報告を受けてIPアドレスの送信をやめたが、サーバーへのリンク送信は許容範囲内だと回答したそうだ。
エンドツーエンドで暗号化されたメッセージ内からどのようにリンクを取得しているのでしょうか。
IPアドレスはメッセージが暗号化されていようと取得可能な情報なので納得できる部分もありますが、
リンクはそういった方法での取得ができそうにないように思えるので不思議に思います。
Re:どういうこと？ (スコア:3)
ストーリーの参照先の記事に書いてあるじゃないの、よく読みなよ。
>Well, it appears that when the LINE app opens an encrypted message and finds a link, it sends that link to a LINE server to generate the preview.
受信側LINEアプリがメッセージ内にリンクがあるのを見つけたら、LINEサーバーにそのリンクを送ってプレビューを作成してもらう
との事。
Re: (スコア:0)
ありがとうございます。
要するにE2Eで暗号化してるけど、対向のEの先でメッセージの中身を読み取ってるってことですね。
Re: (スコア:0)
読み取るばかりかLINEのサーバにそれを送ることでプレビューを実装している
MITMを防いでもManはEdgeにいる、と
Re:どういうこと？ (スコア:2, 興味深い)
端末から送信する時点でメッセージ本文からリンク部分だけを抽出して、本文とは別にURLのみをサーバへ送信するようにすれば可能な気はする。
それはそれで「部外者に知られたくないURLでもLINEが勝手に取得していることになる」とも言えるけど。
Re: (スコア:0)
だよねぇ。どういう理由で許容範囲内なのかさっぱりわからん。
Re: (スコア:0)
URL送る際にプレビューも送信時に作って送ればちょっとはマシかもね。
リンクプレビュー自体がアウトなケースも (スコア:0, すばらしい洞察)
下手に端折ったプレビューだと
同一性保持権に引っかかる
# プレビュー機能自体が脆弱性の温床になりがちだしいらんよなぁ
TeamsとSkypeはどこだ (スコア:0)
受信側生成・サーバ生成それぞれに非公開があるが、サーバ生成の非公開は1つだけなので、どちらかのアプリは受信側生成ですな。
Re:TeamsとSkypeはどこだ (スコア:1)
Skypeって、プレビュー機能なくない？
少なくとも普段使ってるfor businessにはない。
Teamsはサーバ側で生成してる気がするな。イントラサイトは生成されないし。
Re: (スコア:0)
Microsoft は Skype のメッセージを閲覧している [security.srad.jp]
IP ExposureとLeaking Encrypted LinksがLINEのみYesになってる (スコア:0)
end-to-end暗号化をしてないサービスなら、どっちもサービス提供業者に筒抜けじゃないの？ なんでLINEだけYesになるんだ？
Re:IP ExposureとLeaking Encrypted LinksがLINEのみYesにな (スコア:1)
かつてのメールソフト（主にOutlook）のプレビュー問題を知らない世代がアプリ作ってたりするのかねぇ
Re: (スコア:0)
親コメの内容とずれてるけど、読んでないのかな？
それにプラスモデする人はより酷い。
Re: (スコア:0)
ここでのYes/Noはリンク先サイトがURLをクリックする前に知ることができるかどうかであって、サービスを提供しているサーバに対してではない。
Re: (スコア:0)
Leaking Encrypted Links は、そもそもend-to-end暗号化をしているサービスだけのための項目だから、「end-to-end暗号化をしてないサービスなら」という考えがそもそも間違い。
情報が漏れないための暗号化のはずが、漏れてるやん、ていう話だから。
「サービスを提供しているサーバに対してではない」と別コメにあるけど、Leaking Encrypted Links に関しては、サービス提供側に漏れるのも問題。サービス提供側にも漏らさないためのend-to-end暗号化でもあるので。
ttpで書き込め！ (スコア:0)
2ちゃんは時代を先取りしすぎだった
Re: (スコア:0)
あれもリファラーをリンク先のサーバーにleakしないためという理由がかなり大きかった
Re: (スコア:0)
日本語と英語のサイトでも同じじゃないか
Re:非公開情報ってなんぞ (スコア:1)
非公開のURLとかでしょ。
ワンタイムの認証用URLを送ると、サーバーが勝手にアクセスする可能性が有ると。
http: // を付けるだけでDNS経由で内容が漏洩するとか有るかもね。
Re: (スコア:0)
「URLにアクセスすると登録を完了します」みたいなものも、誰かに送るだけで勝手に踏まれてるとか、気持ち悪いな。
Re:非公開情報ってなんぞ (スコア:1)
クライアント側でプレビューを生成する場合、アクティブな時間と、場合によりセキュリティ侵害と、IPアドレスの取得が可能なのよね。
プレビュー自体が害悪な気がする。
Re: (スコア:0)
アクセスしちゃってる(&それによる通信ログにURLが残ること)自体がリークだから、両立にはなってないと思う
Re: (スコア:0)
受け手側じゃなくて送り手側で画像生成して暗号化して送ればええんちゃうんか。