もしWebセキュリティのエンジニアがRFC7540の「HTTP/2アプリ」をWeb診断したら

More Related Content

1.もしWebセキュリティのエンジニアがRFC7540の「HTTP/2アプリ」をWeb診断したら略して「もしR」
2.自己紹介Twitter： abend@number3to4Webセキュリティエンジニア
3.宣伝7/26（日） に開催されるJULY TECH FESTAにて、「フリーでできるセキュリティチェック」というタイトルにて、プレゼンをさせていただきます。”無料”のツールを利用して、ラクにセキュリティチェックを行うためのノウハウをご紹介いたします。インフラエンジニア、運用を担当されているエンジニア向けの内容となっています。http://2015.techfesta.jp/
4.HTTP/2ってHTTP（HyperperText Transfer Protocol）の最新バージョンにあたり、HTTP/1.1から16年ぶりのアップデート。HTTP/2についてはRFC7540、関連するHPACKはRFC7541でリリースされました。HTTP/1.1と比較するとHTTP/2は複雑になっています。HTTP/1.1との違いはこんな感じ。① 多重化② バイナリメッセージ③ ヘッダ圧縮（HPACK）④ フロー制御⑤ 優先度⑥ 依存関係⑦ Server Push
5.nghttp2ってHTTP/2に対応したWebサーバ、Webクライアント、Proxy機能を有する。通信内容の確認は、hexdumpオプションを指定することで確認することが可能。https://nghttp2.org/
6.① 多重化HTTP/1.Xでは、1つのTCPコネクションで1つのリクエストおよびレスポンスをやりとりしていた。HTTP/2では、streamという概念により1つのTCPコネクションで複数のリクエストおよびレスポンスをやりとりできるようなった。streamStream_id：偶数Stream_id：奇数Stream_id：0クライアントサーバStreamID0：コネクション制御用奇数：クライアントが開始偶数：サーバが開始コネクション
7.② バイナリメッセージHTTPフレームが新たに定義され、stream上でやりとりをする。フレームタイプによってFrame Payloadのフォーマットが変わる。フレームヘッダは9byte。フレームヘッダHEADERSフレーム
8.② バイナリメッセージリクエスト、レスポンスヘッダがバイナリベースとなっている。Nghttpでアクセスした際のdump結果。赤枠箇所がリクエストのHEADERSフレーム。
9.② バイナリメッセージリクエストのHEADERSフレーム。00 00 26 01 25 00 00 00 0d 00 00 00 0b 0f 82 8487 41 8b 0b e2 5c 2e 3c b8 5b 7d 70 b2 cf 53 032a 2f 2a 90 7a 89 aa 69 d2 9a c4 c0 57 02 e0緑箇所の3byte「00 00 26」がフレームサイズで38byte（0x26）最初の9byte（固定長）は、フレームヘッダ。青箇所の「01」がフレームタイプを表しており、0x01はHEADERSフレーム。黄色箇所の「25」はFlagで詳細はRFC7540へ。茶色箇所の4byte（正確には31bit分）はStream IDで、この場合は13。
10.② バイナリメッセージリクエストのHEADERSフレームペイロード（赤箇所）00 00 26 01 25 00 00 00 0d 00 00 00 0b 0f 82 8487 41 8b 0b e2 5c 2e 3c b8 5b 7d 70 b2 cf 53 032a 2f 2a 90 7a 89 aa 69 d2 9a c4 c0 57 02 e0青箇所は依存先のStream IDを指している。白箇所でPriorityフラグ（0x20）がセットされた場合にのみ、青箇所と緑箇所が出力される。緑箇所はweightで、「0f」の場合、15+1=16となる。
11.③ ヘッダ圧縮（HPACK）HTTP/2はヘッダ圧縮のためにHPACK（RFC7541）を採用しています。ハフマン符号や静的テーブルと動的テーブルを用いて、圧縮しています。Indexの場合、7bitの値がリクエスト・レスポンスヘッダのヘッダ名、値を指している。「:」から始まるヘッダ名はHTTP/2のために作られた疑似ヘッダフィールドです。
12.③ ヘッダ圧縮（HPACK）さっきのHeader Blockの場合00 00 26 01 25 00 00 00 0d 00 00 00 0b 0f 82 8487 41 8b 0b e2 5c 2e 3c b8 5b 7d 70 b2 cf 53 032a 2f 2a 90 7a 89 aa 69 d2 9a c4 c0 57 02 e00x82（1000 0010）でIndexの2を指しており、「:method: GET」を意味します。同様に0x84、0x87は、それぞれIndexが4、7を指しています。Index 4 ・・・ :path: /Index 7 ・・・ :scheme: https
13.③ ヘッダ圧縮（HPACK）bitにより、どういう意味なのか変わってくる。Indexは事前に定義されたヘッダ名の値をセットする。0x41の場合、Indexが1である:authorityを指す。2byte目（緑箇所）は、上位bitがハフマンエンコーディングの有無を指定し、値長を指定している（11byte）。00 00 26 01 25 00 00 00 0d 00 00 00 0b 0f 82 8487 41 8b 0b e2 5c 2e 3c b8 5b 7d 70 b2 cf 53 032a 2f 2a 90 7a 89 aa 69 d2 9a c4 c0 57 02 e0
14.③ ヘッダ圧縮（HPACK）:authority:ヘッダの値は、赤箇所のbyte列（11byte分）になる。このbyte列はハフマンエンコーディングされているため、このままでは可視できるものではないので、ハフマンでコーディングを行う必要がある。00 00 26 01 25 00 00 00 0d 00 00 00 0b 0f 82 8487 41 8b 0b e2 5c 2e 3c b8 5b 7d 70 b2 cf 53 032a 2f 2a 90 7a 89 aa 69 d2 9a c4 c0 57 02 e0
15.③ ヘッダ圧縮（HPACK）まずは、11byteを2進数に変換し、結合する。RFC7541で定義されているテーブルから戻してあげればいい。赤箇所の「00001」は1を意味しており、白は9、青は2を意味する。これを繰り返すと「 192.168.159.133 」となる。緑箇所は余りで1でpaddingされている。0000101111100010010111000010111000111100101110000101101101111101011100001011001011001111
16.④ フロー制御HTTP/2では1つのコネクションで複数のstreamが通信できる。複数のstreamが一斉に大量の通信をはじめたら・・・。俺、通信するっ！！ じゃ、俺も俺も。 じゃ、俺も俺も。誰も「どうぞ、どうぞ」を言わないと、重要な通信が行えなくなってしまう。どうぞ、そうぞ どうぞ、そうぞ えっ！？
17.④ フロー制御ウィンドウサイズによるフロー制御が存在しており、優先度にも応じて通信を行う。ただし、フロー制御の対象となるのは、DATAフレームのみ。コネクションの使用可能なウィンドウサイズ：65535Streamごとの使用可能なウィンドウサイズ：65535使用可能な量を使い切ってしまった場合、受信者側からWINDOW_UPDATEを受け取ることで、使用可能な量を追加することができる。クライアントサーバ
18.④ フロー制御たとえば、237byteのデータをStreamIDが1のウィンドウサイズ127byteの設定で通信した場合・・・2. サーバが237byteのデータのうち、127byteをsendクライアントサーバコネクション ウィンドウサイズ：65535StreaｍID:1 ウィンドウサイズ：1271. クライアントがInitial Window Sizeを127byteへ変更をsendコネクション ウィンドウサイズ：65535StreamID :1 ウィンドウサイズ：127クライアントサーバ
19.④ フロー制御4. サーバが残りの110byteをsendクライアントサーバコネクション ウィンドウサイズ：65408StreaｍID:1 ウィンドウサイズ：1273. クライアントがWINDOW_UPDATE(StreamID:1)127byteをsendコネクション ウィンドウサイズ： 65408StreaｍID:1 ウィンドウサイズ：0クライアントサーバ
20.④ フロー制御Initial Window Sizeは、SETTINGフレームで指定します。00 00 0c 04 00 00 00 00 00 00 03 00 00 00 64 0004 00 00 00 7f赤箇所9byteはフレームヘッダ。黄色箇所以降がSETTINGフレームのペイロード。2byteの識別子と4byteの値の計6byte単位で構成される。黄色箇所0x03は、SETTINGS_MAX_CONCURRENT_STREAMS を意味し、値は緑箇所の0x64(100)。0x04がSETTINGS_INITIAL_WINDOW_SIZEで、0x07(127)。※ SETTINGS_INITIAL_WINDOW_SIZEはオプションで強制的に0x07に指定してます。
21.④ フロー制御WINDOW_UPDATEは、WINDOW_UPDATEフレームで実行されます。00 00 04 08 00 00 00 00 0d 00 00 00 1fWINDOW_UPDATEは、「コネクションに対して」と「Streamに対して」行うことが可能で、フレームヘッダで指定するStream IDが0の場合、「コネクションに対して」、指定するWindow Sizeが追加される。「Streamに対して」行う場合は該当するStream IDを指定する必要がある。両方に対して行う必要がある場合はそれぞれのWINDOW_UPDATEフレームを送信する必要がある。
22.⑤ 優先度各StreamがWindow Sizeの上限まで使い切ることがないように、Streamに対して優先度(Wight)をつけて、その割合に応じて通信を行う。値は1から256の整数で指定することが可能です。Defaultは16です。StreamID:1 Wight:12StreamID:3 Wight:3この場合、StreamID:1は全体の5分の4の割合で通信を行います。非常に参考になりました。HTTP/2 Deep Dive: Priority & Server Push by Moto Ishizawahttps://speakerdeck.com/summerwind/2-deep-dive-priority-and-server-push
23.⑤ 優先度優先度の指定は、PRIORITYフレームを用いて行うことが可能です。00 00 05 02 00 00 00 00 03 00 00 00 00 c8赤箇所はフレームヘッダ。青箇所は依存するStreamIDを指定し、この場合は0を指していている。緑箇所が該当Stream(StreamID:3)の優先度で、0xc8(200)+1=201が優先度となる。
24.⑥ 依存関係各Streamは、他のStreamと依存関係を持ちます。ルートにはStreamID:0がセットされ、依存されるStreamIDのほうが優先してリソースの割り当てを行われます。StreamID:0StreamID:1 StreamID:3StreamID:5 StreamID:7
25.⑦ Server Push通常、クライアントからリクエストを送信し、それに対してレスポンスを返すが、Server Pushはクライアントからのリクエストを受けずにサーバがレスポンスを返す。クライアント サーバリクエストレスポンスServer Pushのレスポンスは、クライアントが送信すると予定されるリクエストとデータを返します。データはクライアントでキャッシュされます。
26.⑦ Server PushServer Pushするために、サーバからクライアントにPUSH_PROMISEフレームで通知しておく必要があります。Promissed Stream IDは、Server PushされStreamIDがセットされる。サーバが起点となるため、この値は偶数となる。また、Header Block Fragmentには予定されるリクエストをセットされます。
27.⑦ Server PushServer Pushするために、サーバからクライアントにPUSH_PROMISEフレームで通知しておく必要があります。00 00 18 05 04 00 00 00 0d 00 00 00 02 82 04 8761 09 f5 41 57 22 11 87 41 87 08 9d 5c 0b 81 70ff赤箇所はフレームヘッダ。緑箇所は、Server PushするStreamIDでID:2を指定。水色箇所は、予定されるリクエストヘッダになっており、HEADERSフレームと同様にデコード可能。
28.Web診断ってWebアプリケーションの脆弱性の有無を検査することをWeb診断としています。Web診断では、基本的にProxyツールを用いて行います。Proxyツールで検査パターンを付加してリクエストし、そのレスポンスの内容によって脆弱性の有無を判断します。リクエストWebサーバクライアント検査パターンを付加する。 Proxyツールレスポンス
29.Web診断ってProxyツールを使う理由は、ブラウザで操作できる内容が限られているためです。都道府県：性別： 男 女東京都 （ブラウザ上で）入力形式が固定化されている場合にProxyツールを用いて、入力値を変更します。
30.Web診断ってProxyツールのひとつにBurp Suiteがあります。Javaで動作し、一部の機能は有償版のみとなりますが、基本的にフリーで使えるツールです。リクエストをInterceptして変更することで、ブラウザでは変更できないパラメータも変更可能となります。
31.結論HTTP/2のアプリに対して、Burp Suiteでアクセスしてみた。Burp Suiteは、HTTP/2に対応していないのでできなかった。
32.じゃあ、どうすんのソースとか見てたら、nghttpxというProxy機能があることに気づいたのでこれを活用することに。クライアント ProxyツールHTTP/1.1 HTTP/2nghttpxHTTP/1.1こうすれば既存の仕組みのまま、HTTP/2アプリにも接続可能。HTTP/2アプリ
33.試してみたNghttp2をProxyとして動作させることで、Burp Suiteでもアクセスできるようになった。nghttpx --client -f0.0.0.0,8080 –b[HTTP2サーバのIP],443 -k -o -LINFO
34.これで脆弱性見つけられるnghttp2には、アプリケーションサーバとしての機能がないため、以下、構成で診断が行えるか確認することに。クライアント ProxyツールHTTP/1.1HTTP/2nghttpxHTTP/1.1WebアプリHTTP/1.1nghttpx
35.当然見つかるHTTP/1.Xと同様に何も変わることなく、XSSを見つけることができた。
36.じゃあ、すべての脆弱性も？HTTPヘッダインジェクションはどうなるのだろうか。脆弱なサイト一般利用者Proxy Server攻撃者キャッシュが汚染されるメールやページ書込みによるリンクXSSと同じ被害
37.なぜ、HTTPヘッダインジェクションなのかHTTP/2だとレスポンスヘッダ（リクエストヘッダもだけど）はバイナリになるため、以下の行為ができないのではないかと考えた。① 任意のヘッダ挿入勝手にSet-Cookieとセットされる可能性がある。② レスポンススプリッティングProxyサーバに不正な内容をキャッシュさせられる可能性がある。
38.なぜ、HTTPヘッダインジェクションなのか検証するにあたり、脆弱なソースを用意した。※オープンリダイレクタも存在します。#!/usr/bin/perluse utf8;use strict;use CGI;my $cgi = new CGI;my $url = $cgi->param('url');print "Status: 302 Movedn";print "Content-Type: text/html; charset=UTF-8n";print "Location: $urln";print "n";print "<hmtl>n";print "<body>n";print "redirect done!!n";print "</body>n";print "</hmtl>n";exit;
39.① 任意のヘッダ挿入HTTP/2の場合、HPACKを用いてヘッダの圧縮を行っているため、脆弱性を悪用してヘッダにインジェクトしようとしても、ただの文字列として処理されてしまうのではないかと推測した。＜レスポンス＞HTTP/1.1 302 FoundDate: Thu, 25 Jun 2015 00:17:28 GMTSet-Cookie: a=aLocation: http://www.yahoo.co.jp以下略＜リクエスト＞GET http://192.168.159.152:8433/redirect.cgi?url=http://www.yahoo.co.jp%0a%0dSet-Cookie:a=a HTTP/1.1以下略脆弱だった。。。
40.① 任意のヘッダ挿入なぜこうなったのか。＜推測です＞今回の構成の場合、バックエンドサーバである脆弱サーバで改行が評価されヘッダに挿入されたレスポンスをそのままHTTP/2へ返すために、HTTP/2にはまったく関係がなく、とめることはできないのではないかと推測しています。
41.② レスポンススプリッティングHTTP/2では、レスポンスヘッダとレスポンスボディはそれぞれ違うフレームとして送信されるため、レスポンスを分割したとしてもキャッシュされないのではないかと推測。＜リクエスト＞GET http://192.168.159.152:8433/redirect.cgi?url=http://www.yahoo.co.jp%0a%0dContent-Length:0%0a%0d%0a%0dHTTP/1.1%20200%20OK%0a%0d%0a%0d<html><body>inject</body></html> HTTP/1.1Host: 192.168.159.152:8433以下略＜赤字箇所のURLデコード結果＞改行Content-Length:0改行改行HTTP/1.1 200 OK<html><body>inject</body></html>
42.② レスポンススプリッティング結果は・・・。HTTP/1.0 302 Moved TemporarilyDate: Thu, 25 Jun 2015 16:57:28 GMTLocation: http://www.yahoo.co.jpContent-Length: 100Content-Type: text/html; charset=UTF-8Connection: keep-aliveHTTP/1.1 200 OK<html><body>inject</body></html><hmtl><body>redirect done!!</body></hmtl>プログラムがそもそも意図した通りになっていなかった。。。
43.② レスポンススプリッティング※20015/6/27に内容を追加してます。意図した通りのレスポンスになっていないため、pythonで強制的にレスポンススプリッティングした結果がHTTP/2(nghttpx)ではどのように評価されるか検証してみた。参考http://qiita.com/otoyo/items/98098e927797272d0a39プログラムは一部抜粋self.wfile.write("HTTP/1.1 302 Foundrn")self.wfile.write("Content-Type: text/html; charset=utf-8rn")self.wfile.write("Location: http://www.yahoo.co.jprn")self.wfile.write("Content-Length:0rn")self.wfile.write("rn")self.wfile.write("HTTP/1.1 200 OKrn")self.wfile.write("rn")self.wfile.write("<html><body>inject</body></html>rn")
44.② レスポンススプリッティングPythonサーバにアクセスすると以下のレスポンスが常に返される。HTTP/1.1 302 FoundContent-Type: text/html; charset=utf-8Location: http://www.yahoo.co.jpContent-Length: 0HTTP/1.1 200 OK<html><body>inject</body></html>※20015/6/27に内容を追加してます。青字箇所がレスポンススプリッティングされることを想定したレスポンス。
45.② レスポンススプリッティングブラウザ → Burp Suite → フォワードプロキシ(nghttpx) →リバースプロキシ(nghttpx) → Pythonサーバという順でアクセスした結果。HTTP/1.1 302 FoundDate: Sat, 27 Jun 2015 08:10:08 GMTLocation: http://www.yahoo.co.jpVary: Accept-EncodingContent-Length: 0Content-Type: text/html; charset=UTF-8Server: nghttpx nghttp2/1.0.4Via: 1.1 nghttpx, 2 nghttpx2つ目のレスポンスがなくなっている。※20015/6/27に内容を追加してます。
46.② レスポンススプリッティングリバースプロキシ(nghttpx)のログは、大きく4つのポイントがあります。1. フォワードプロキシ(nghttpx)からのHTTP/2のGETリクエスト2. PythonサーバへのHTTP/1.1のGETリクエスト3. PythonサーバからのHTTP/1.1のレスポンス4. フォワードプロキシ(nghttpx)へのHTTP/2のレスポンス※20015/6/27に内容を追加してます。
47.② レスポンススプリッティング1.フォワードプロキシ(nghttpx)からのHTTP/2のGETリクエスト:method: GET:scheme: http:authority: リバースプロキシのIP:path: /user-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8accept-language: ja,en-US;q=0.7,en;q=0.3accept-encoding: gzip, deflatex-forwarded-proto: httpvia: 1.1 nghttpx※20015/6/27に内容を追加してます。
48.② レスポンススプリッティング2. PythonサーバへのHTTP/1.1のGETリクエストGET http://リバースプロキシのIP/ HTTP/1.1Host:リバースプロキシのIPUser-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: ja,en-US;q=0.7,en;q=0.3Accept-Encoding: gzip, deflateVia: 1.1 nghttpx, 2 nghttpx※20015/6/27に内容を追加してます。
49.② レスポンススプリッティング3. PythonサーバからのHTTP/1.1のレスポンス:status: 302content-type: text/html; charset=utf-8location: http://www.yahoo.co.jpcontent-length: 0via: 1.1 nghttpx※20015/6/27に内容を追加してます。※疑似ヘッダフィールド「:status」が出力されている。理由は不明。
50.② レスポンススプリッティング4.フォワードプロキシ(nghttpx)へのHTTP/2のレスポンス[2805.766] send HEADERS frame <length=27, flags=0x04, stream_id=5>; END_HEADERS(padlen=0); First response header:status: 302content-type: text/html; charset=utf-8location: http://www.yahoo.co.jpcontent-length: 0via: 1.1 nghttpx[2805.766] send DATA frame <length=0, flags=0x01, stream_id=5>; END_STREAM※20015/6/27に内容を追加してます。レスポンスは、HEADERSフレームとDATAフレームのみで、DATAフレームのサイズも0となっている。
51.② レスポンススプリッティングレスポンススプリッティングした「HTTP/1.1 200 OK」のレスポンス自体は認識されずに、破棄されていると思われる。※20015/6/27に内容を追加してます。Nghttpxを介すことで、レスポンススプリッティングされる可能性は減ると思うが、実装状況にも依存すると思われるため、HTTP/2だからセキュアになるということではないと思う。
52.まとめ
53.大事なことなので2度言います。
54.宣伝7/26（日） に開催されるJULY TECH FESTAにて、「フリーでできるセキュリティチェック」というタイトルにて、プレゼンをさせていただきます。”無料”のツールを利用して、ラクにセキュリティチェックを行うためのノウハウをご紹介いたします。インフラエンジニア、運用を担当されているエンジニア向けの内容となっています。http://2015.techfesta.jp/
55.・HTTP/2は以前のバージョンと比較すると複雑になり、telnetとかで試すことができなくなった。まとめ・HTTP/2を使えば安全というわけではなく、Webアプリケーションはこれまで通りセキュリティ対策はとる必要はある。・hexdumpした結果を何度も見ていると、だんだんフレームが見えてくる。
56.ちなみに前から疑問だったのだが・・・。HTTP/2コネクションの初期設定確立のために、24byteの固定されたコネクションプリフェイスをサーバが送信する。「HTTP/2.0」だと！？正式名称は「HTTP/2」or「HTTP2」じゃないのか。って、前から？？でした。
57.参考資料RFC7540https://http2.github.io/http2-spec/http://summerwind.jp/docs/rfc7540/ （日本語訳）RFC7541http://www.rfc-editor.org/rfc/rfc7541.txthttp://syucream.github.io/hpack-spec-ja/rfc7541-ja.html （日本語訳）HTTP/2 Frequently Asked Questionshttp://http2.info/faq.html#why-is-http2-multiplexedHTTP2 Advent Calendar 2014http://qiita.com/advent-calendar/2014/http2HTTP/2.0のインパクトhttps://www.janog.gr.jp/meeting/janog32/doc/janog32-http2.0-shimizu-01.pdfHTTP/2 入門http://www.slideshare.net/techblogyahoo/http2-35029629HTTP/2 Deep Dive: Priority & Server Pushhttps://speakerdeck.com/summerwind/2-deep-dive-priority-and-server-push