はい、M10iです。
近頃大手の企業さんがランサムウェア攻撃にあったニュースが世間を騒がせておりますね。
怖い世の中になったものです。
webサイトを攻撃する方法やユーザを騙す方法は日進月歩しておりまして(しなくていいのに)
ここでは最近話題になったBrowser Cache Smugglingについてお話したいと思います。
Browser Cache Smuggling（ブラウザキャッシュ・スマグリング）は、ブラウザの自然な挙動と CDN／プロキシ／バックエンドの処理の“差”を突いて、見かけ上は無害なレスポンスをブラウザや中間キャッシュに仕込み、後続ユーザにそれを配布する攻撃手法です。ダウンロードや明示的な通信が発生しないため発見されにくいのが特徴です。
なぜ注目されているの？
近年、攻撃者は「挙動の差」を活かす方向に巧妙化しています。ブラウザやプロキシの扱い方に微妙なズレがあると、正規のリクエスト経路に攻撃者が“種”を植え付けられます。キャッシュに一度でも悪性データが入ると、その同じキャッシュを参照する多数のユーザに横展開できるため、インパクトが大きくなり得ます。
仕組み
ブラウザや中間キャッシュが「普通にやること（画像取得など）」を利用して、攻撃者が 中間キャッシュまたはブラウザのキャッシュ に悪意あるコンテンツを注入する攻撃手法です。
汚染フェーズと配布／実行フェーズの二段階があると思えば理解しやすいです。M10i的には
なので攻撃者のフェーズとユーザのフェーズに分けて説明します。
フェーズ1：汚染
-
攻撃者が特定のキャッシュキー（URL やヘッダ組合せ）に対して攻撃者制御のレスポンスをキャッシュさせる。
※手段例：直接の細工リクエスト、キャッシュキーの分岐・正規化バグ利用、Proxy/Origin の解釈差の悪用など。今回は具体例コードは無しで、全体イメージを掴んで頂きたい。 - ここで「汚染済みのキャッシュエントリ」が生成される（＝攻撃成功した段階）。
フェーズ2：汚染された後（配布／発火フェーズ）
- 別のユーザが同じキャッシュキー(URL)でリソースを要求すると、CDN/proxy/ブラウザのキャッシュが汚染済みレスポンスを返す。
※画像をキャッシュしたつもりが謎dllをキャッシュしているなど予期せぬ状態に・・・ - ただし「返す」だけで被害が起きるかは別問題 → 以下の“発火条件”を満たす必要がある。
発火（被害が成立）に必要な条件 — 「ダウンロードだけでは発火しない」
1.クライアントがそのデータを自動的に実行・解釈する場合
- 返されたデータがブラウザにスクリプトとして読み込まれ、実行される（例：同名 .js を <script> として読み込ませる等）。
2.別のプロセス／アプリがそのデータを実行してしまう場合
- サードパーティのビューアや統合アプリがファイルを開いてしまい、そこで意図しないコードが走る。
3.ユーザ操作で実行に繋がる場合
- クリップボードに貼られたコマンドをユーザがそのまま実行してしまう、ダウンロード→手動で解凍→実行、など。
4.ローカルのスクリプト（PowerShell 等）がキャッシュ内ファイルを参照して起動される場合
- UIトリックでローカルスクリプトを起動させ、そのスクリプトがキャッシュを読み出して展開・実行する流れ。
どこが厄介？
ネットワーク上に「大きなファイル転送」や「外部からのダウンロード要求」が見えないことが多く、従来の検出手法に引っかかりにくいので、セキュリティソフトで検出できないマルウェアがPC内にダウンロードされてしまうことに！
最後に
ものすごくまとめると、攻撃者がCDNやブラウザのキャッシュに悪いデータをこっそり入れておいて、あとから普通のユーザがそのURLを開くと改ざんされた中身が返ってくるのが Browser Cache Smuggling です。でもポイントは「キャッシュに入るだけじゃ基本的には勝手に動かない」こと。実際にエラいことになるには、そのデータがブラウザや別のアプリで実行・解釈される（あるいはユーザーが誤操作する）ような条件が必要です。だから対策はキャッシュを汚されないようにすることと、返ってきたデータが不用意に実行されないように扱いを厳しくすることの両方が大事ってことですね。
ではではM10iでした☆
参考サイト
Browser Cache Smuggling Attack
Browsers’ cache smuggling
Cache smuggling: When a picture isn’t a thousand words
