やってみた

Web Cache Deception AttackをIISとARRで検証してみた

cdi-horikoshi

こんにちは。技術部の堀越です。

先日、セキュリティ研究者のOmer Gil氏によってPayPalがWebキャッシュを詐称した攻撃(Web Cache Deception Attack)に脆弱であると指摘されました。
この攻撃は、「Web Cache Deception Attack」と呼ばれており、ユーザの機微な情報が意図せずWebキャッシュサーバに保存され、誰でもキャッシュされた情報にアクセス出来てしまうという脆弱性です。
この攻撃手法は、受動的ではあるが攻撃成功時の影響範囲が広く、Akamaiからも注意喚起がされています。
そこで、今回はOmer Gil氏のブログ内でも公開されているIISとAplication Request Routing(ARR)を使い検証してみました。
本記事では皆さんが検証出来るように構築から順を追って記載しています。

目的

本記事はWeb Cache Deception Attackの攻撃手法を理解することを目的としています。
そのため、WebサーバにはGUIでわかりやすく構築可能であるIISとARRを使用しています。

環境

PC 1(Webサーバ):

  • OS: Windows Server 2008 R2 Enterprise
  • アプリ: IIS7.5+ARR
  • ホスト名: arr.example.com
  • 用途: リバースプロキシとWebキャッシュの提供

PC 2(Webコンテンツ):

  • OS: Ubuntu 16.04.2 LTS
  • アプリ: Apache2,php7
  • ホスト名: php.example.com
  • 用途: PHPコンテンツの提供

※本記事ではWebサーバの構築を主に説明するため、PC2の環境は事前にインストール済みと想定しています。

Webコンテンツの用意

PC 2で以下のような簡単なPHPファイルを作成し公開します。

<?php  
if( isset( $_COOKIE['session'] ) ) { 
  echo 'logged-in: ' .  $_COOKIE['session']; 
} else { 
  echo 'please login'; 
} 
?>

Cookieなしでアクセスすると「please login」と表示されます。

cdi-horikoshi_20170418183951

sessionという名前のCookieを付与してアクセスすると「logged-in:cookieの値」と表示されます。

cdi-horikoshi_20170418184000

Webサーバの用意

IISのインストール

IISのインストールは標準設定のままインストールしているため、既にIISのインストール方法をご存知の方は、「Web PIのインストール」の説明からご覧ください。

cdi-horikoshi_20170413135829
役割の追加をクリック

cdi-horikoshi_20170413140001
次へをクリック

cdi-horikoshi_20170413140119
Webサーバー(IIS)を選択し、次へをクリック

cdi-horikoshi_20170414100440
次へをクリック

cdi-horikoshi_20170414100449
そのまま次へをクリック

cdi-horikoshi_20170414100457
インストールをクリック

cdi-horikoshi_20170414100505
IISのインストールは終了です。

Web PIのインストール

まずは、Web PI(Microsoft Web Platform Installer)をダウンロードします。
ダウンロードが完了したら、Web PIをインストールします。

cdi-horikoshi_20170414100858
使用許諾書の条項に同意し、インストールをクリック

cdi-horikoshi_20170414100910
Web PIのインストールは終了です。

ARRのインストール

スタート->すべてのプログラムから「Microsoft Web Platform Installer」を起動します。

cdi-horikoshi_20170414120513
検索から「ARR」と入力してEnter

cdi-horikoshi_20170414100924
「Application Request Routing 3.0 (英語)」を選択し->追加->インストールをクリック

cdi-horikoshi_20170414100931
同意するをクリック

cdi-horikoshi_20170414120524
ARRのインストールは終了です。

ARRの設定

リバースプロキシの設定

スタート->管理ツールから「インターネット インフォメーション サービス (IIS) マネージャー」を起動します。

cdi-horikoshi_20170414120534
URL 書き換えをダブルクリック

cdi-horikoshi_20170414120548
操作->規則の追加をクリック

cdi-horikoshi_20170414120555
受信規則と送信規則->リバース プロキシをクリック->OKをクリック

cdi-horikoshi_20170414120601
OKをクリック

cdi-horikoshi_20170418184048
受信規則にWebコンテンツを配置したサーバ名またはIPアドレスを入力->OKをクリック

キャッシュの設定

Webコンテンツのキャッシュを保存する場所を設定します。

cdi-horikoshi_20170414120617
「Application Request Routing Cache」をダブルクリック

cdi-horikoshi_20170414120624
Drive Management->Add Drive...をクリック

cdi-horikoshi_20170414120634
Drive locationにキャッシュを保存する任意の場所を入力->OKをクリック
ここでは予めCドライブ直下にCacheフォルダを作成してます。

cdi-horikoshi_20170414120639
Cache Management->Cache Control Rulesをクリック

cdi-horikoshi_20170414120647
Add...をクリック

cdi-horikoshi_20170414120654
以下を設定し、OKをクリック

  • Apply rule: Always
  • Cache duration (minutes): 60
  • URL: *.css

この設定は今回の攻撃手法のポイントとなります。cssの拡張子がついているリクエストはキャッシュ制御ヘッダに関係なくキャッシュされます。

攻撃手順

実際に攻撃者と被害者を仮定して、Web Cache Deception Attackを確認してみたいと思います。

最初にApplication Request Routing Cache->Cache Management->Browse Cache Contentをクリックし、いまの状態で何もキャッシュされていないことを確認します。

cdi-horikoshi_20170414120747

(被害者の操作)サンプルサイトへログイン

cdi-horikoshi_20170418184149
用意したサンプルWebへアクセス

cdi-horikoshi_20170418184206
Cookieを付与してアクセス(とあるサイトへログインしたと仮定)

(攻撃者の操作)罠URLの公開

予め罠URLを被害者がアクセスしそうな場所に公開

http://arr.example.com/login.php/style.css

(被害者の操作)攻撃者によって公開された罠URLへアクセス

末尾にstyle.cssを追加したURLにアクセスしてしまうことにより、キャシュポリシーに従いキャッシュサーバがログイン後の情報をキャッシュしてしまいます。

cdi-horikoshi_20170418184234

キャッシュ状態の確認

Application Request Routing Cache->Browse Cache Contentを確認すると、php.example.comへのキャッシュが保存されており、ファルダ内へアクセスすると「style.css.full.gzip」というキャッシュが保存されている。

cdi-horikoshi_20170418184249
cdi-horikoshi_20170418184257
cdi-horikoshi_20170418184304

(攻撃者の操作)Cookieが設定されていないブラウザで罠URLへアクセス

cdi-horikoshi_20170418184317

本来sessionというCookieがないと表示されない「logged-in」という文字が表示されています。
更にcookieの値が被害者によって設定した値になっていることも確認できます。

まとめ

今回検証した内容をまとめると、以下が本脆弱性のポイントとなります。

  1. クライアント側からWebコンテンツ側へ存在しないリソースをリクエストした際に、クライアントのブラウザには404や302などのレスポンスを返さず、意図しないコンテンツ(本記事ではlogin.php)を返却してしまう
  2. クライアント側からキャッシュサーバ経由でリクエストした際に、キャッシュ保存設定が拡張子のみで判断している場合、(1)の存在しないはずのコンテンツがキャッシュサーバにキャッシュされる

そのため、以下のような対策が有効であると考えられます。

キャッシュサーバ側:

  • 拡張子のみでキャッシュさせない
  • キャッシュ制御ヘッダを条件に追加(キャッシュ制御ヘッダを無視しない)

Wbeコンテンツ側:

  • 存在しないリソースがリクエストされた際に404や302などのレスポンスを返す
© 2016 - 2024 DARK MATTER / Built with Hugo / テーマ Stack は Jimmy によって設計されています。