[CODE BLUE 2017]HTTP/2 クライアントのパッシブ・フィンガープリンティングオリー・シガール – Ory Segal -[レポート] #codeblue_jp #codeblue_jp_t2

#セキュリティ

#CODE BLUE

臼田佳祐

2017.11.09

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

『世界トップクラスのセキュリティ専門家による日本発の情報セキュリティ国際会議』でありますCODE BLUE 2017に参加していますのでレポートします。

このブログは下記セッションについてのレポートです。

HTTP/2 クライアントのパッシブ・フィンガープリンティング - オリー・シガール - Ory Segal -

レポート

Akamaiがどのようなデータを収集しているか

Akamaiのスケール
- 220,000+エッジ
- 3,315のDC
- 60Tbps
- 3兆ビット
- 等など
HTTP/2の1日の使用統計
- 13,200ホスト
- 632,900ユーザーエージェント
- 等など
- 10%トラフィック

HTTP/2概要

Googleが開発したSPDYがベース
2015年に発表
- RFC7540, 7541
HTTP/1.1のパフォーマンス上の課題を改善
- 並行性
  - 1つのTCPコネクションで1つのリクエストしか送る事ができない
- 圧縮
  - HTTPヘッダのフィールドは冗長的でTCPのCogestion windowを埋めてしまう
- サーバがパッシブ
  - サーバからトラフィックプッシュを開始することはできない
  - 次にクライアントが何を要求するかわかっていても、クライアントの要求を待つ
改善されている内容
- 並行性
  - 1つのTCPコネクション内でデータのインターリーブが可能
- 圧縮
  - 効率的なエンコーディングでヘッダの圧縮
- サーバプッシュ
  - 新しいインタラクションモードとしてクライアントが必要になると判断した場合にサーバからレスポンスをプッシュ
並行性
- ストリームを多数作ることができる
- 独立した走行性のフレームのシーケンスがストリーム
HTTP/2のキー要素
- コネクション
- ストリーム
- フレーム
- メッセージ
フレームの構造
- length
- Type
- Flags
- R
- Stream Identifier
- Frame payload
ヘッダのフレーム例
- ペイロードにはどのストリームに依存しているかも組み込まれている
HTTP/2フレームタイプ
- DATA
- HEADERS
- PRIORITY
- 等など
HTTP/2検査ツール
- 以前より簡単に見れないのでwebサーバのログを利用する
- chrome://net-internalsは良いツール
注意点
- HTTP/2はバイナリである(netcatで試すことが出来ない)
- TLSが使われる
- 殆どのプロキシツール(Burp等)はH2をサポートしていない

クライアント&デバイスのパッシブフィンガープリンティング

資料
ユニークな特徴が観測できる可能性のある情報のパッシブな収集
エンドユーザではなくクライアントのフィンガープリンティング
トランスポート/セッション/アプリケーション層
導き出す情報
- OS
- system uptime
- ソフトウェアクライアントの種類
使えるヘッダ
- headers
- priority
- settings
- windows_update
SETTINGSフレーム
- コネクション開始時に双方から必ず送られなくてはならない
- クライアントごとに利用するIDと値が異なる
WINDOW_UPDATEフレーム
- フローのコントロールに用いられる
- 各フレームのレベルとコネクション全体のレベルで行われる
- RFCはデフォルトのサイズを定義している
- コネクションフローコントロールウインドウはWINDOW_UPDATEフレームを用いることによってのみ変更できる
PRIORITYフレーム
- ストリームの依存関係と優先度の設定に用いられる
- 優先度はストリームに重み付けを行うことが出来る
- 3つのフィールドがある
  - 重み
  - ストリーム依存関係
  - 排他フラグ
疑似ヘッダ
- HTTP/1.xではメッセージを用いてターゲットURL、リクエストのメソッド、そしてステータスコードを表現した
- HTTP/2では:で始まる特別な疑似ヘッダを用いる
- :method: GET等
疑似ヘッダのエントロピー
- クライアントによってぜんぜん違う順番
- ハードコードされている

HTTP/2パッシブフィンガープリンティングの用途

偽装されたクライアントの検知
攻撃ツールとbot等の確認
Webクライアントへのポジティブな制約
- モバイルアプリのアクセスするAPI等
匿名プロキシ & VPN検知
- トラフィック & フィンガープリントの統計解析

HTTP/2の脅威の現状

全くない(少しはあるけど、出すほどのものではない)
殆どのセキュリティツールはH2をサポートしていない
- Burp, Fiddler, SQLmap, AppScan, NetSparker等など
いまならHTTP/2にすれば無料でセキュリティを手にすることができるｗｗｗ
何故か？
- 攻撃者に実質的なインセンティブがない
  - WebサーバがHTTP/1,xと2を両方サポートしている
- 一般的でシンプルなライブラリがHTTP/2をサポートしていない
  - リファクタリングが必要