パスワードを忘れた? アカウント作成
14974529 story
プライバシ

チャット/メッセージングアプリのリンクプレビュー機能に潜む問題 30

ストーリー by nagazou
悪用厳禁 部門より
headless 曰く、

チャット/メッセージングアプリのリンクプレビュー機能の問題点について、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, おもしろおかしい)

    by Anonymous Coward on 2020年10月30日 18時26分 (#3916267)

    サービス側で余計なことをされないようにURLからhを抜いてttps://のようにすれば

    # 昔からあるやつ

    ここに返信
    • by Anonymous Coward

      ttps://www.google.co.jp/
      のような文字列を貼ると、大抵はドメイン名を見て判断して
      ttps:// www.google.co.jp/
      のように正しく?解釈されます。
      プロトコル部をhts://みたいに替えるとか、全部ダメになりました。

      • by Anonymous Coward

        ついでにwebブラウザーの補完機能でも修正される

  • by Anonymous Coward on 2020年10月30日 17時59分 (#3916255)

    LINEの場合、メッセージをエンドツーエンドで暗号化しているが、リンクはサーバーへ送られる。また、送受信者のIPアドレスをリンク先に送信していたという。LINEは報告を受けてIPアドレスの送信をやめたが、サーバーへのリンク送信は許容範囲内だと回答したそうだ。

    エンドツーエンドで暗号化されたメッセージ内からどのようにリンクを取得しているのでしょうか。
    IPアドレスはメッセージが暗号化されていようと取得可能な情報なので納得できる部分もありますが、
    リンクはそういった方法での取得ができそうにないように思えるので不思議に思います。

    ここに返信
    • by hakikuma (47737) on 2020年10月30日 23時14分 (#3916430)

      ストーリーの参照先の記事に書いてあるじゃないの、よく読みなよ。

      >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サーバーにそのリンクを送ってプレビューを作成してもらう

      との事。

      • by Anonymous Coward

        ありがとうございます。
        要するにE2Eで暗号化してるけど、対向のEの先でメッセージの中身を読み取ってるってことですね。

        • by Anonymous Coward

          読み取るばかりかLINEのサーバにそれを送ることでプレビューを実装している
          MITMを防いでもManはEdgeにいる、と

    • by Anonymous Coward on 2020年10月30日 18時10分 (#3916259)

      端末から送信する時点でメッセージ本文からリンク部分だけを抽出して、本文とは別にURLのみをサーバへ送信するようにすれば可能な気はする。
      それはそれで「部外者に知られたくないURLでもLINEが勝手に取得していることになる」とも言えるけど。

      • by Anonymous Coward

        だよねぇ。どういう理由で許容範囲内なのかさっぱりわからん。

      • by Anonymous Coward

        URL送る際にプレビューも送信時に作って送ればちょっとはマシかもね。

  • by Anonymous Coward on 2020年10月30日 17時56分 (#3916252)

    下手に端折ったプレビューだと
    同一性保持権に引っかかる

    # プレビュー機能自体が脆弱性の温床になりがちだしいらんよなぁ

    ここに返信
  • by Anonymous Coward on 2020年10月30日 17時59分 (#3916256)

    受信側生成・サーバ生成それぞれに非公開があるが、サーバ生成の非公開は1つだけなので、どちらかのアプリは受信側生成ですな。

    ここに返信
  • by Anonymous Coward on 2020年10月30日 19時12分 (#3916291)

    end-to-end暗号化をしてないサービスなら、どっちもサービス提供業者に筒抜けじゃないの? なんでLINEだけYesになるんだ?

    ここに返信
    • by Anonymous Coward on 2020年10月31日 7時44分 (#3916516)

      かつてのメールソフト(主にOutlook)のプレビュー問題を知らない世代がアプリ作ってたりするのかねぇ

      • by Anonymous Coward

        親コメの内容とずれてるけど、読んでないのかな?
        それにプラスモデする人はより酷い。

    • by Anonymous Coward

      ここでのYes/Noはリンク先サイトがURLをクリックする前に知ることができるかどうかであって、サービスを提供しているサーバに対してではない。

    • by Anonymous Coward

      Leaking Encrypted Links は、そもそもend-to-end暗号化をしているサービスだけのための項目だから、「end-to-end暗号化をしてないサービスなら」という考えがそもそも間違い。
      情報が漏れないための暗号化のはずが、漏れてるやん、ていう話だから。

      「サービスを提供しているサーバに対してではない」と別コメにあるけど、Leaking Encrypted Links に関しては、サービス提供側に漏れるのも問題。サービス提供側にも漏らさないためのend-to-end暗号化でもあるので。

  • by Anonymous Coward on 2020年10月30日 23時35分 (#3916434)

    2ちゃんは時代を先取りしすぎだった

    ここに返信
    • by Anonymous Coward

      あれもリファラーをリンク先のサーバーにleakしないためという理由がかなり大きかった

typodupeerror

犯人はmoriwaka -- Anonymous Coward

読み込み中...