パスワードを忘れた? アカウント作成
13524893 story
犯罪

Windows版Google Chromeユーザーを主なターゲットにしたテクニカルサポート詐欺の手法 23

ストーリー by headless
詐欺 部門より
Webブラウザーに偽の警告画面を表示して電話をかけさせるタイプのテクニカルサポート詐欺では、ユーザーの操作を困難にするためのさまざまな手法が用いられるが、Windows版のGoogle Chromeユーザーが主なターゲットとみられる新たな手法による攻撃をMalwarebytesが報告している(Malwarebytes Labsの記事Neowinの記事Ars Technicaの記事SlashGearの記事)。

この手法では、ウイルスに感染したのでISPがPCをブロックしたといった内容の警告とMicrosoftの偽の電話番号を表示するとともに、大量のファイルダウンロードを実行してCPU使用率を100%まで上昇させ、ウインドウやタブを閉じることができないようにする。ダウンロードするファイルは実体があるわけではなく、Blobオブジェクトを生成し、window.navigator.msSaveOrOpenBlobメソッドで保存するというものだ。これを繰り返すことで大量のファイルダウンロードが実行されることになる。

攻撃は実際に行われているものであり、Chrome最新版のバージョン64.0.3282.140も影響を受ける。そのため、報告を受けたChromiumチームが対策を検討しているようだ。Chrome以外のブラウザーはUser Agent文字列別のランディングページが用意され、別のHTML APIによる手法が用いられているとのことだが、MalwarebytesはFirefoxとBraveも影響を受けることを確認し、それぞれ報告したとのこと。

なお、この手法ではベンダー接頭辞「ms」のついたメソッドが使われているが、MalwarebytesがUser Agent文字列をChromeのものに変更したInternet ExplorerやMicrosoft Edgeで試したみたところ、ウインドウを閉じることは可能だったという。JavaScriptコードの関数名(ch_jam、bomb_ch)に「ch」が付けられているところからみても、Chromeユーザーを念頭に置いた手法と考えられるとのことだ。

このような攻撃は主に不正広告経由で行われるため、Malwarebytesでは効果的な緩和策として広告ブロックソフトウェアの使用を挙げている。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2018年02月12日 18時33分 (#3360258)

    Chromeを捨てよう

    • by Anonymous Coward on 2018年02月12日 18時42分 (#3360259)

      冗談抜きにそれが最善だったりする
      最近はまたブラウザごとの独自実装で面倒になってきたしもう一度シェアがフラットになった方がいいかもだし

      Chromeも シェアを取ればかつての IE

      親コメント
      • by Anonymous Coward

        そこでsafariですよ!
        あ、Apple製品にしかなかったですね...

        • by Anonymous Coward

          Windows版Safariはフェードアウトしちゃったからね…。

          # 止めるのは構わないが開発終了告知を出せと

          • by Anonymous Coward

            Windows Phoneの悪口はやめろ

            • by Anonymous Coward

              Windows Phoneはセキュリティアップデート出てるから・・・。

            • by Anonymous Coward

              Safariの場合はセキュリティ穴だらけのまま撤退という情けない対応w

      • by Anonymous Coward

        Edgeは
        IEであったように
        https://answers.microsoft.com/ja-jp/edge/forum/edge_other-edge_win10/w... [microsoft.com]

        日本語ファイルのダウンロードでファイル名が化けたりするので
        去年、化けるという話が来て、幾つか試したところ
        IE、FireFox、Chromeでは化けなかったのにEdgeのみ化け

        Edge以外使ってくださいという対応しましたわ

        • by Printable is bad. (38668) on 2018年02月12日 20時27分 (#3360309)

          Edge以外使ってくださいという対応しましたわ

          Microsoft Edge 41.16299.15.0 で確認しましたが、RFC 2616 [ietf.org] に準拠した方法で filename* を指定(URLエンコード)すれば、日本語ファイル名の文字化けは発生しませんでした。

          誤った指定方法:

          Content-Disposition: attachment; filename="テスト画像.jpg"

          正しい指定方法:

          Content-Disposition: attachment; filename*=UTF-8''%E3%83%86%E3%82%B9%E3%83%88%E7%94%BB%E5%83%8F.jpg

          悪いのは、Edge ではなく Webアプリケーションの製作者です。

          親コメント
          • by Anonymous Coward on 2018年02月12日 22時43分 (#3360370)

            RFC 2616には、filenameに非ASCII文字が含まれている場合の規定は見つけられなかったのですが。ていうかすでにRFC 7230~7235でobsoleteされてるし。いくら誰もリンク先見ないからって参照が適当すぎやしませんか。

            親コメント
            • RFC 2616には、filenameに非ASCII文字が含まれている場合の規定は見つけられなかったのですが。(略)いくら誰もリンク先見ないからって参照が適当すぎやしませんか。

              #3360309 [srad.jp] のコメント内容を再確認したところ、タイトルの「RFC 6266 を無視するサイトが悪い」とアンカーのリンク先は「RFC 6266」で意図した通りでしたが、アンカーテキストのみ「RFC 2616」と誤表記してしまったようでした。正しくはアンカーテキストも「RFC 6266」とすべきでした。お詫び申し上げます。

              ていうかすでにRFC 7230~7235でobsoleteされてるし。

              RFC 6266 - 6.Internationalization Considerations [ietf.org] では、下記の通り、"filename*" パラメータには RFC5987 で定められたエンコーディングを使用することができ ISO-8859-1 以外のキャラクターセットが使用可能とされています。

              6.  Internationalization Considerations

                 The "filename*" parameter (Section 4.3), using the encoding defined
                 in [RFC5987], allows the server to transmit characters outside the
                 ISO-8859-1 character set, and also to optionally specify the language
                 in use.

                 Future parameters might also require internationalization, in which
                 case the same encoding can be used.

              RFC 6266 (June 2011) の目的は、RFC 2616 (June 1999) の Content-Disposition を国際化するためのものであり、仰る通りもととなる RFC 2616 は既に obsolete されています。

              しかし、改訂版 HTTP/1.1 の RFC の一部である RFC 7231 (June 2014) - Appendix B. Changes from RFC 2616 [ietf.org] において、Content-Disposition ヘッダーについての定義は RFC 2616 → RFC 7231 の過程で RFC 7231 からは除去され、今は RFC 6266 で定義されているとあるので、今も RFC 6266 は有効だと思われます。

              下記は、RFC 7231 [ietf.org] からの引用です(太字強調は引用者)。

              The Content-Disposition header field has been removed since it is now defined by [RFC6266].

              親コメント
              • by Anonymous Coward

                RFC 2616はobsoleteでもRFC6266は新HTTP1.1から参照してるのかよ。IETFは依存関係バージョン管理無で新番号乱立しすぎやしないか

            • by Anonymous Coward on 2018年02月12日 23時36分 (#3360393)

              >RFC 2616には、filenameに非ASCII文字が含まれている場合の規定は見つけられなかったのですが。
              RFC2616だろうが、7230だろうが、HTTPヘッダに許可されているのはISO-8859-1のみです。

              >filenameに非ASCII文字が含まれている場合
              許可されていない形式ですので、Webブラウザの実装依存でしょうね。

              親コメント
              • RFC2616だろうが、7230だろうが、HTTPヘッダに許可されているのはISO-8859-1のみです。

                確かにそのままでは UTF-8 などの文字は使用できませんが、RFC 7231 - 8.3.1. Considerations for New Header Fields [ietf.org] には、

                Header fields needing a greater range of characters can use an encoding such as the one defined in [RFC5987].

                とあるので、US-ASCII 以外のキャラクターを使用する必要がある場合には、RFC 5987 で定められた符号化方式が使えるはずです。

                また、RFC 6266 において、「filename」と「filename*」は別のパラメータで、「filename*」のみエンコードした UTF-8 が使用できます。

                親コメント
        • by Anonymous Coward on 2018年02月12日 20時17分 (#3360302)

          RFC 5987でエンコードしろや
          http://tech.innovator.jp.net/entry/s3-content-disposition [jp.net]
          こういうゴミクズを養成しているという点において確かにChromeは現代のIEになってるわ

          親コメント
          • by Anonymous Coward on 2018年02月13日 5時37分 (#3360442)

            普通に考えりゃRFC6266は "Updates: 2616" やからRFC2616と連鎖で無効なはずだが
            RFC7231に now defined by [RFC6266] てあるならまだRFC6266は有効なのか
            ほんと紛らわしいわ

            旧HTTP1.1 = RFC2616
            ↑       ↑補足 (Updates: 2616)
            ↑obsolete   RFC6266 →→→→→→呼び出し→→→→→RFC5987
            ↑       ↑RFC7231 Appendix B          ↑RFC7231 8.3.1で呼び出し
            新HTTP1.1 = RFC7230~7235→→→→→→→→→→→→→→

            ならばPrintable vs ACの対決は結局両者とも大筋の内容は正しいってことで終着か
            ChromeはWinXP時代でゆうIE、RFC重視のEdgeはWinXP時代でゆうWEB標準重視の古き良きFireFoxやな

            親コメント
            • by Anonymous Coward

              普通に考えりゃRFC6266は "Updates: 2616" やからRFC2616と連鎖で無効なはずだが

              違ったんならそれは普通じゃないんだろう

        • by Anonymous Coward

          リンク先、IE11でも化けないのにEdgeは化けるって言ってるように見えるんだが。ていうか一部の例外除いてサポート終了したバージョンの時代の話みたいだけど今でも文字化けするの? 当時のEdgeはガチで未完成品だったからなあ

        • by Anonymous Coward

          結局こいつが馬鹿だったという話か

    • by Anonymous Coward


      Microsoft曰く、Microsoft EdgeではWebKitと動作が異なる場合はバグ

      Webkit ではなく Blink なので追従の必要はない、ということですね。

      # WebGL のように仕様レベルでの脆弱性が発見された場合、きっと一時的に非互換を認めてセキュリティ強化側に振ってくれてると信じてます

    • by Anonymous Coward

      マルチプロファイル対応してくれたらちょっとはEdge使ってもいいんだけど…

  • by Anonymous Coward on 2018年02月12日 18時47分 (#3360262)

    msSaveOrOpenBlobサポートしてるのかよ。Chromeはゼロクリックでファイルがダウンロードされるという特徴があるのにちと安易すぎやしないか

    • by Anonymous Coward

      あれChromeだけの機能なのか。
      だったら偽flashplayerぐらい自動的にフィルタして捨てるのもセットにしてくれよ…

typodupeerror

海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs

読み込み中...