Burp Suiteとnghttpxを使ってHTTP2のWebアプリに接続してみよう
2015年2月にHTTP2がRFC化された。これから普及が進むことが期待される。既にいくつかのクライアントやサーバはHTTP2に対応しており、対応アプリケーションは、以下のGitHubでまとめられている。*1
HTTP2では、バイナリプロトコル、サーバープッシュ、多重化など新要素がある。これに伴うセキュリティ面ではOWASP等で議論が重ねられているところだけど、ここでは置くとして、さしあたり僕が気になるのは、従来型のWebアプリケーションのテストはどうなるんだろうという点。
テストのためにはフォワードプロキシが欲しい。が、あいにくBurp SuiteやFiddlerなどはまだ対応していない模様。上のGitHubを見てもフォワードプロキシはあまりなく、すぐ利用できるものもなさそう。
HTTP2はバイナリプロトコルなので、HTTPリクエストをそのままガシガシ編集することもできない。
いざ「HTTP2でアプリケーション作ったのでテストよろしくね」的な無茶振りがきた場合、途方に暮れるおそれがある。*2 *3
そこで今回は実験的に、Burp Suiteとnghttpxを組み合わせてHTTP2のWebアプリケーションにアクセスしてみたい。
検証環境
検証環境のイメージ
以下のイメージ。
ざっくり流れを説明すると、
・ブラウザからBurp Suiteを通して接続する。ここはHTTP1。
・クライアント側のフォワードプロキシ(nghttpx)でHTTP1→HTTP2にアップグレード
アプリケーション
検証用に、入力値(名前)を受け取ってようこそというメッセージを出すだけのシンプルなphpスクリプトを用意。*5
hello.php
<?php $name = $_POST["name"]; if($name=="") { $name = "guest"; } ?> <html> <head> <title>greeting</title> </head> <body> <h1>greeting</h1> Hello, <?php echo htmlspecialchars($name, ENT_QUOTES, 'UTF-8'); ?> !<br /> <br /> <?php if($name=="guest") { ?> Input your name.<br> <form action="./hello.php" method="post"> Name: <input type="text" name="name" size="24" value="" /> <input type="submit" /> </form> <?php } ?> <a href="./hello.php">back</a><br /> <br /> </body> </html>
手順
- ブラウザとかBurpとかApacheはテキトーに起動する。
- ブラウザのプロキシ設定をBurpに、Burpのプロキシ設定をフォワードプロキシのnghttpxに設定する。
- フォワードプロキシのnghttpxを以下のコマンドで起動する。
nghttpx -p -k -LINFO -f0.0.0.0,8090 -b192.168.120.128,8443
- リバースプロキシのnghttpxを以下のコマンドで起動する。
nghttpx -LINFO -f0.0.0.0,8443 -b127.0.0.1,80 /root/cert/server.key /root/cert/server.crt
- ブラウザからサーバのURLにアクセスする。
結果
ブラウザから、フォワードプロキシを経由してWebアプリケーションに接続できることを確認した。
アクセスの様子
ブラウザから、サーバのURL「http://192.168.120.128:8443/hello.php」にアクセスしたところ。
フォームをSubmitしたときのHTTPリクエスト
POSTパラメータ「name」の値を改変
HTTPレスポンス。改変後の値で処理されている。
結果表示。
ログでの確認
フォワードプロキシのログを見ると、リクエストがHTTP1→HTTP2にアップグレードされていることがわかる。
(前半がBurpから受け取ったHTTPリクエスト、後半がサーバに送るHTTPリクエスト)
20/Apr/2015:23:06:57 +0900 PID25573 [INFO] shrpx_https_upstream.cc:153 [UPSTREAM:0x7ffc3b84e060] HTTP request headers POST http://192.168.120.128:8443/hello.php HTTP/1.1 Host: 192.168.120.128:8443 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.5.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://192.168.120.128:8443/hello.php Connection: keep-alive Cache-Control: max-age=0 Content-Type: application/x-www-form-urlencoded Content-Length: 35 (中略) 20/Apr/2015:23:06:57 +0900 PID25573 [INFO] shrpx_http2_session.cc:1279 [DHTTP2:0x7ffc3b836780] Negotiated next protocol: h2-14 20/Apr/2015:23:06:57 +0900 PID25573 [INFO] shrpx_http2_downstream_connection.cc:438 [DCONN:0x7ffc3b8216c0] HTTP request headers :scheme: http :path: /hello.php :authority: 192.168.120.128:8443 :method: POST accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-encoding: gzip, deflate accept-language: en-US,en;q=0.5 cache-control: max-age=0 content-length: 35 content-type: application/x-www-form-urlencoded host: 192.168.120.128:8443 referer: http://192.168.120.128:8443/hello.php user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.5.0 via: 1.1 nghttpx
課題
アクセス自体はできたものの、いま分かっている課題を挙げる。
まとめ
HTTP1→HTTP2にアップグレードできるフォワードプロキシ(nghttpx)を使って、Burp SuiteでHTTP2サイトにアクセスしてみた。Burp Suiteはテストに使えそうだけど、実用を考えるとまだクリアする課題がある。やはりBurp SuiteなどのテストツールがHTTP2に対応するのを期待したい。
IPv6に対する検証コマンドのメモ
IPv6のサーバに対して検証をする機会があって、コマンドとかIPv4とは勝手が違う部分があって苦労している。
あまりまとまっているページが見当たらなかったので、調べた内容を把握する範囲でメモしておこう。
基本的には、クライアントはLinux環境を想定している。
コマンドなど
ping
ping6コマンドを使う。
ping6 -c 3 2001::abcd
リンクローカルアドレスはインタフェース番号を末尾に付ける。
ping6 -c 3 fe80::abcd%eth0
telnet
-6オプションを付ける。
telnet -6 2001::abcd 80
Windowsではオプション不要。
ssh
-6オプションを付ける。
ssh -6 2001::abcd
ftp
-6オプションを付ける。
ftp -6 2001::abcd
ssl
接続にはncatを使う。
調べた限りOpenSSLではv6に接続できなかった。
ncat -6 --ssl -v 2001::abcd 443
OpenSSLが使えなかったので、Cipher Suiteの確認はsslscanかnmapを使う。
sslscanの場合:
sslscan --ipv6 [2001::abcd]:443
nmapの場合:
nmap
-6オプションを付ける。
nmap -6 2001::abcd
Nessus
Linux環境からスキャンする。
Windowsだとスキャンできない。(5.2のhelpには「IPv6 is now supported on most Windows installations」とあるが、期待した結果が得られなかった)
OpenVAS
Linux環境からスキャンする。
ひとまず以上。
追加があれば追記する。
Burp suiteのリクエスト/レスポンス文字化け対策(試作)
Burp suiteのリクエスト/レスポンスからコピペするとマルチバイト文字が文字化けしてしまう問題について、Burp Extenderで試作してみた。
ニッチなところに需要があるかもしれないので、まずは、ひっそりと置いておきます。
なお、お約束として、動作を保証するものではありません。
概要
- Burp Extenderで実現(コピーのためのコンテキストメニューを追加)
- Burp proxyで現在表示しているリクエスト/レスポンスを、クリップボードにコピー
- 現時点では、リクエスト/レスポンス全体コピーと、ヘッダのみコピーの機能を搭載
要件
- burp suite 1.5.01以上(新しいBurp Extenderが必要)
- JRE 1.7以上
あとは特にないと思います。
動作確認は、Windows 8.1、JDK 1.8.0_05、Burp suite 1.6(Free版)でやっています。
使い方
Burp proxyのコンテキストメニューにメニューが追加されているので、それを選べばOK。
今後の課題
- 他のBurpツールからのコピー(現在Burp proxy以外の動作は未定義)
- 「選択範囲のみコピー」で、マルチバイト文字の途中まで選択状態でコピーすると化ける(これは仕方ないかも)
- その他
ダウンロード
https://github.com/tosebro/CopyForEvidence
(2014/07/02 更新)
・UTF-8以外で化けるのを修正
(2014/07/03 更新 ver.alpha 25)
・Proxyのhistoryからのコピーに対応。
・選択範囲のコピーに対応。ようやく実用的になってきた。
(2015/03/29 更新)
・GitHubに公開しました。
まとめ
Burp suiteの文字化け対策を試作してみた。
新しいBurp Extenderはかなり強力になっているようなので、他にもいろいろ拡張できそう。折を見て更新していきたい。
そもそもの話
文字化けの原因が分からず。swingからクリップボードへの文字列コピーが怪しいと思ってるが、、、
Burp suite文字化けの原因とか有効な対策があったら教えて下さいm(_ _)m
リバースHeartbleed(Reverse Heartbleed)を検証してみた。
セキュリティ界隈でOpenSSLのHeartbleed(CVE-2014-0160)が話題になっている。
サーバからの情報漏洩がクローズアップされており、対策が進んでいるようだけど、一方でクライアントを攻撃できる「リバースHeartbleed」脆弱性がある。
Android 4.1.1のリバースHeartbleed脆弱性
クライアントから情報が漏れるので、かなり危険なんじゃないかと思うけど、あまり注意喚起もされていないようなので知らない人もいるのでは?と思って、その検証と、対策などをまとめてみた。
該当する端末やアプリを使っている人はぜひ参考にして自衛してほしい。
Heartbleedとは
改めて説明するまでもないと思うけど、OpenSSLの脆弱性である。
OpenSSLはHeartbeat機能に実装不備があり、これを悪用することで最大64KBのメモリ上のデータを不正に取得できる。(しかも何回でも取得できる)
秘密鍵や、ユーザの入力したIDやパスワードなどの漏洩のおそれがある。
リバースHeartbleed(Reverse Heartbleed)とは
通常は、クラッカー(クライアント側)が世の中のサーバを標的として攻撃するが、リバースHeartbleedでは「リバース」の名の通り、サーバがクライアントを攻撃するHeartbleedである。*1
影響を受けるクライアント
冒頭の記事によるとAndroid 4.1.1と一部の4.2.2が影響を受けるとのこと。(厳密にはAndroidに組み込まれたOpenSSLが影響を受ける。4.2.2は詳細不明)
Androidのシェア的には4.1.xは最も多い35.3%みたい(4.1.1は不明)。ただWikipediaによると、日本ではAndroid 4.1.1の製品の種類は少ない。日本では一部の人が使っているだけなので話題になっていないのかな?
他に影響を受けるソフトウェアについてはセキュインコさんのまとめが詳しい。
検証
実際にリバースHeartbleed攻撃ができるか、以下の環境で検証してみた。
- 端末A:Android 4.1.1(リバースHeartbleed影響有り/HTC J butterfly)
- 端末B:Android 4.0.3(影響無し/HTC EVO 3D)
- サーバ:攻撃用サーバ。OSはKali linux、サーバスクリプトはpacemaker.pyを使用。
Heartbleed Detectorで端末のHeartbleed状況を確認する。
左:端末A:Android 4.1.1(HTC J butterfly。リバースHeartbleed影響有り)
右:端末B:Android 4.0.3(HTC EVO 3D。影響無し)
手順と結果
1. 攻撃用サーバの準備
攻撃用サーバからスクリプトを実行する。
サーバのURLは、例えばhttps://192.168.1.1:4433/のようになる。
2. 端末Aで攻撃用サーバにアクセス
端末AのAndroid標準ブラウザから攻撃用サーバにアクセスする。
サーバのコンソール上では以下のように端末のメモリ内の情報が表示された。(バイナリ部分はマスク)
取得したメモリ内容によっては、暗号化鍵や個人の情報が漏洩するおそれがある。
今回は、過去アクセスしたURL、サイトへのログインID、Googleアカウントなどが取得できた。
例:過去アクセスしたURL
また、OSが影響受けても、アプリが影響を受けない場合*2、(そのアプリの通信からは)メモリ内容は漏洩しない。
例:Android 4.1.1(影響有り)でGoogle chrome(影響無し)を使ってアクセスした場合
3. 端末Bで攻撃用サーバにアクセス
端末Bで同様にアクセスする。脆弱性がないので漏洩しない。
以上の結果から、脆弱な端末のユーザを、攻撃用サーバのURLにアクセスさせることができれば、端末のメモリ内容を盗み取ることができると考えられる。
対策
まずは影響を受けるかチェックする。
Androidの場合はHeartbleed DetectorやBluebox Heartbleed Scannerで、OSとアプリをチェックする。
不運にも該当するAndroid端末を使っている人は、以下のどちらかを検討する。
アップデートが提供されていないとか、機種変更がすぐにできない場合は、いったん以下の自衛策を取りつつ、どこかのタイミングで機種を変える。
- 不審なサイト(アングラ色の強いサイトなど)には行かない。
- ブラウザにはGoogle chromeを使う。標準ブラウザを使わない。
- オンラインバンキングなどにはログインしない。
あと、オススメできない方法だけど、思いついたのを一応載せておく。
- rootを取ってカスタムROMでアップデートする→root化に伴うリスクがある
- 以前使っていた携帯に戻す→(通常は)OSが古くなってしまうので別のリスクがあるかも。キャリアを変えていたり3GからLTEに機種変更していると戻せない。
まとめ的な
というわけでAndroid端末を例にリバースHeartbleedの検証結果と対策のまとめでした。
悪い人のサイトにユーザを誘導できれば、情報が抜き取れるというお話です。
ツッコミや考慮漏れなどがあったら教えていただけるとありがたいです。
情報源
URLを載せておきます。(本文と重複あり)
http://googleonlinesecurity.blogspot.jp/2014/04/google-services-updated-to-address.html
http://www.infoq.com/jp/news/2014/04/android_heartbleed
http://d.hatena.ne.jp/Kango/20140414/1397498442
http://blog.meldium.com/home/2014/4/10/testing-for-reverse-heartbleed
https://reverseheartbleed.com/
(追記)
国内のスマホは6機種該当するようですな。お使いの方はぜひアップデートを。
<OpenSSL欠陥>国内のスマホ6機種 OSに問題 (毎日新聞) - Yahoo!ニュース