恐怖のHTML5 ApplicationCache Poisoning

(HTML5 ApplicationCache Poisoning of horror)

自己紹介 (Self­Introduction)

• @kyo_ago
• ApplicationCache Poisoning歴1年3ヶ月の新米です。
• (ApplicationCache Poisoning NEWBIE.)

(ApplicationCachePoisoning is a hot topic these days.)

ApplicationCache Poisoningが話題になっている様子

(Signs that ApplicationCache Poisoning has become the center of attention.)

前提知識 (Background Knowledge)

• HTTP Proxy based MitM Attack
• ApplicationCache Poisoning

Introduction

これまでMitMは「安全なネットワークへ移動すれば攻撃は終わる」と言われていました。

(MitM was said "Attacks will finish, if we move to safety network." until now.)

しかしMitM時にApplicationCache等の強力なキャッシュが汚染されることでその前提も崩れてしまいました。

(However, the premise has collapsed due to powerful cache of ApplicationCache being polluted at the time of MitM.)

それでも現状、「ApplicationCache Poisoningの被害は汚染サイトの継続的な監視」というのが一般的な認識です。

(The general recognition is that "The damage of ApplicationCache Poisoning enforces victims to continuous monitoring of the pollution site.")

今日はApplicationCache Poisoningを使った新しい攻撃方法をいくつか紹介したいと思います。

(Today, I will introduce some new attack methods, using ApplicationCache Poisoning.)

突破型ApplicationCache Poisoning

(Breaking type ApplicationCache Poisoning)

攻撃方法

(Methods of Attack)

MitMでLocal IPを汚染することで、ネットワーク機器を攻撃する。

(Attack the network devices by poisoning local IP with MitM.)

ターゲット

(Target)

スマホのネイティブアプリ広告領域（主にAdMob）

(Ad­area of navive application in smartphone (mainly AdMob))

汚染シナリオ

(Poisoning scenario)

汚染シナリオ (Poisoning scenario)

1. MitMで通信を監視する
   (Monitor the network by MitM.)
2. 広告用JSの通信を発見したらJSを汚染する
   (Pollute the JS, when the traffic of JS for ad was detected.)

汚染シナリオ (Poisoning scenario)

3. 汚染したJS上からLocal IPを開く
   (Open the local IP on polluted JS.)
4. Local IPのリクエストをMitM Proxyで受け取る
   (Receive the request for the local IP by MitM Proxy.)

汚染シナリオ (Poisoning scenario)

5. MitM ProxyからApplicationCache Poisoningされたhtmlを返す
   (Reply the html which was infected by ApplicationCache Poisoning from MitM Proxy.)

攻撃シナリオ

(Attack scenario)

攻撃シナリオ (Attack scenario)

1. 広告用WebViewが広告用JSを読み込む
   (A WebView for ad reads the JS for ad.)
2. 広告用JSからLocal IPを開く
   (Open the local IP on the JS for ad.)

攻撃シナリオ (Attack scenario)

3. ApplicationCache Poisoningされたhtmlを読み込む
   (Read the html which was infected by ApplicationCache Poisoning.)
4. 汚染されたhtmlからLocal IP上へXHRでBasic認証をパスワードリストアタック
   (Attack with password list for the local IP Basic authentication by XHR from polluted html.)

攻撃シナリオ (Attack scenario)

5. 成功したら結果を外部へ送信
   (Send the result to outside, when the attack succeed.)
6. 結果を解析して攻撃コードを更新
   (Analyse the result, and update the attack code.)

実証

PoC(Proof of Concept)

実証 PoC(Proof of Concept)

• iOS、Androidで実現確認
  (Reproduced on iOS and Android)
• ただし、固定URLを持ったJSを読み込んでいる必要がある（iAdは攻撃できなかった）
  (Provided that it must be pre­read the JS that has the fixed URL.(I couldn't attack iAd.))

実証 PoC(Proof of Concept)

• 汚染された広告用JSはExpireヘッダを追加してキャッシュさせる。
  (The polluted JS for ad will add the Expire­header, and cache it.)
• ルータ等に使用されやすいIPとドメイン（365個）に対しては広告領域のリロード時間内に汚染可能。
  (I could attack IP and domain(total 365), that are mainly being used in router, in reload time of ad area.)

実証 PoC(Proof of Concept)

• ルータ等に使用されやすい3481個の認証情報は広告領域のリロード時間内に施行不能だった。（認証情報は減らせる可能性が高い。ブラウザ上に状態を保持すれば全認証情報を施行できる可能性が高い）
  (I couldn't attack 3481 credentials, that are mainly being used in router, in reload time of ad area. (There is a high possibility of decreasing the amount of credentials. Provided that it stored the state on browser, I think it will be able to try all credentials.))

実証 PoC(Proof of Concept)

• また、今回はbasic認証をベースに攻撃したが、ルータによってはhtmlベースの認証を行っている場合もある。（それでも攻撃は可能だが、攻撃コードは複雑になる）
  (This time, I attacked basic authentication. However some routers provide html based authentication. (We can also attack them, but attack code will become complex.))

実証 PoC(Proof of Concept)

• スマホのWebViewはBasic認証失敗時にダイアログが表示されない
  (Smartphone WebView does not popup dialog. (Basic authentication will silently fail.))

追尾型ApplicationCache Poisoning

(Tracking ApplicationCache Poisoning)

攻撃方法

(Methods of Attack)

MitMでLocal IPを汚染することで、ネットワーク機器を攻撃する。

(Attack the network devices by poisoning local IP with MITM.)

ターゲット

(Target)

管理者権限を持つユーザのPCブラウザ

(Web browsers on user PC with administrative privilege.)

汚染シナリオ

(Poisoning scenario)

汚染シナリオ (Poisoning scenario)

1. MitMで通信を監視する
   (Monitor the network by MitM.)
2. 全てのhtml、JSにLocal IPを開くJSを混ぜる
   (Inject the JS, that open the local IP, into all html and JS.)

汚染シナリオ (Poisoning scenario)

3. 汚染したhtml、JSからLocal IPを開く
   (Open the local IP on the polluted JS.)
4. Local IPのリクエストをMitM Proxyで受け取る
   (Receive the request for the local IP by MitM Proxy.)

汚染シナリオ (Poisoning scenario)

5. MitM ProxyからApplicationCache Poisoningされたhtmlを返す
   (Reply the html which was infected by ApplicationCache Poisoning from MitM Proxy.)

攻撃シナリオ

(Attack scenario)

攻撃シナリオ (Attack scenario)

1. ユーザがLocal IP上の管理画面にアクセスする
   (A user accesses the administrative screen on the local IP.)
2. 攻撃コードがbasic認証ダイアログ、または認証画面を表示する
   (The attack code displays basic authentication dialog or authentication screen.)

攻撃シナリオ (Attack scenario)

3. ユーザが認証情報を入力しログインする
   (A user enter the credential, and log in.)
4. 攻撃コードが通信を中継しつつ設定を書き換える
   (The attack code relays the traffics and falsify the settings.)

実証

PoC(Proof of Concept)

実証 PoC(Proof of Concept)

• 設定を書き換えるには機種ごとの攻撃コードが必要
  (Need a specific attack code of models to rewrite settings.)
• Local IPへのアクセスで攻撃コードが発動するため、罠サイトへ誘導する必要がない
  (Don't need to lead fake site, because attack code executed by Local IP access.)

実証 PoC(Proof of Concept)

• 攻撃対象はURLパスにダミーデータがあってもリクエストを受け付ける必要がある（ApplicationCache上からbasic認証ダイアログ、または認証画面を表示するため）
  (The target of attack must accept the request even if it contains dummy data into the URL. (It displays basic authentication dialog or authentication screen from the ApplicationCache.))

コードの焼き付け

(Inject codes)

攻撃方法

(Methods of Attack)

httpサーバに侵入後、レスポンスに永続的ApplicationCacheを加えることで、サーバ復旧後も過去にアクセスしたクライアントを攻撃し続ける。

(After intrusion to the http server, it continues to attack the client, that has been accessed in the past, by adding persistent ApplicationCache to response after the server recovery.)

ターゲット

(Target)

過去にサーバに侵入された状態でアクセスしたことがあるクライアント。

(Clients in intrusion state that has been accessed in the past)

汚染シナリオ

(Poisoning scenario)

汚染シナリオ (Poisoning scenario)

1. httpサーバに侵入する
   (Intrude to http server)
2. 全てのhtmlレスポンスに永続的ApplicationCacheを加える
   (Inject Permanent ApplicationCache to all html response)

汚染シナリオ (Poisoning scenario)

3. 永続的ApplicationCacheで汚染コードをキャッシュさせる
   (Cache Poisoned code by Permanent ApplicationCache)

攻撃シナリオ

(Attack scenario)

攻撃シナリオ (Attack scenario)

1. ユーザが汚染されたページにアクセスするのを待つ
   (Wait for users who access to poisoned page)
2. 攻撃コードを空のhtmlとJSで起動
   (Run the Attack code with blank html and JS)

攻撃シナリオ (Attack scenario)

3. 攻撃コードがlocation.href+'?utm_source=fb'にXHRして最新の情報を取得
   (Get the latest information with the attack code accessing to "location.href+'?utm_source=fb'" by XHR)
4. 取得した内容を展開しつつ画面遷移系イベントを捕捉
   (Trap the screen transition event while extracts the acquired contents.)

攻撃シナリオ (Attack scenario)

5. 攻撃コードで画面遷移を偽装しつつ毎回最新情報を取得して展開
   (Get the latest information every time and extract it while screen transition spoofed by attack code)

実証

PoC(Proof of Concept)

実証 PoC(Proof of Concept)

• 最初にapplicationCacheの更新を妨害するとサーバからは汚染コードを除去できない
  (When we first prevent to applicationCache update, servers can not remove the poisoned code.)
• 「'?utm_source=fb'」はFB経由の場合もつくのでリクエストの無視もできない
  (We can not ignore 「'?utm_source=fb'」, because it was added by Facebook access.)

実証 PoC(Proof of Concept)

• XHRにヘッダを足すと通常のブラウザアクセスと判別するのは困難
  (It is hard to determine whether the access is normal browsers or not when it added header on XHR.)
• JSで画面遷移を偽装すると普通のユーザはまず判別できない
  (Normal user can not aware of attack by using JS screen transition.)

対処法

(Coping Technique)

クライアント

(Client)

クライアント (Client)

• MitM攻撃を受けないようにしましょう。
  (Try to avoid from MitM attacks.)
• 信頼できるネットワーク以外ではシークレットモードを使用しましょう。
  (Use secret mode on unreliable network.)

クライアント (Client)

• 信頼出来ないネットワーク上ではネイティブアプリを立ち上げないようにしましょう。
  (Don't launch native application on unreliable network.)

サーバ

(Server)

サーバ (Server)

• 侵入されないようにしましょう。（「ApplicationCacheを使わない」と言うのは無意味です）
  (Try to avoid from intrusion (”Don’t use ApplicationCache” is not effective))

広告SDKベンダー

(Advertisement SDK vendors)

広告SDKベンダー (Advertisement SDK vendors)

• 可能であればすべての通信をTLS化しましょう。
  (Use TLS for all traffics, if possible.)
• 難しい場合全てのURLに乱数を付与しましょう。
  (Add random numbers on all URL, if you can't use TLS.)

Local IPで運用される機器のメーカ

(Manufacturer of devices which are operated with Local IP)

Local IPで運用される機器のメーカ (Manufacturer of devices which are operated with Local IP)

• （難しいけど）CAPTCHAの採用は突破型ApplicationCache Poisoningには効果があります。
  ((Although difficult) It is effective to adopt CAPTCHA for preventing from Breaking type ApplicationCache Poisoning.)

Local IPで運用される機器のメーカ Manufacturer of devices which are operated with Local IP

• （さらに難しいけど）TLS化を検討しましょう。
  ((Although more difficult) Consider using TLS.)
• （もっと難しいけど）専用アプリからのみアクセスできるようにして、Webインターフェイスをやめましょう。
  ((Although more and more difficult) Disable web interface, only accessible from original application.)

FAQ

FAQ

• Q. MitMが終わったらApplicationCacheも消えるのでは
  A. manifest fileに自身のmanifest urlを指定すると消えなくなります（仕様）
• Q. Is the ApplicationCache erased after MitM?
  A. It'll be erased if the manifest URL is assigned in manifest file itself.(spec)

FAQ

• Q. ApplicationCacheが危険なの？
  A. 本質的には強力すぎるキャッシュ全てに同じ問題があります。
• Q. Is only the ApplicationCache dangerous?
  A. Basically, all of over­caches have the same problem.

FAQ

• Q. ApplicationCacheを置き換えるServiceWorkerでは？
  A. ServiceWorkerはhttps時のみしか使用できないなどの、MitMの被害を軽減する対応が取られているためかなり安全です。
• Q. What will happen in ServiceWorker that replace ApplicationCache?
  A. It'll be safer because of its countermeasure that reduces MitM damage. (Ex. It can use only in https, etc.)

FAQ

• Q. 実際に被害が出ているの？
  A. 聞いたことないです。多分出てないと思います。
• Q. Has damage actually come out?
  A. I've never really heard of it. Probably it seems that damage has not come out.

FAQ

• Q. コード公開していいの？
  A. shellshockの方が効率的だと思います。
• Q. May I publish the attack code?
  A. Shellshock woudld be more effective.

FAQ

• Q. どうすればいいの？
  A. ApplicationCacheの仕様を変更し、永続的ApplicationCacheはできなくした方がいいと思います。
• Q. What should I do?
  A. You should better modify the spec of the ApplicationCache and put out persistent ApplicationCache.

FAQ

• Q. どうすればいいの？
  A. ApplicationCacheの仕様を破棄し、ブラウザも互換コードを残してAPIを封印した方がいいと思います。
• Q. What should I do?
  A. You should better discard the spec of the ApplicationCache and seal the Browser APIs except compatible programs.

FAQ

• Q. どうすればいいの？
  A. 忘れましょう。
• Q. What should I do?
  A. Forget about it.

検証コードはgithub上で公開しています

(PoC code is published on github.)

kyo-ago/MitMPoC

ご質問は？

(Any Question?)

ご静聴ありがとうございました。

(Thank you for your attention.)