生存報告

主に情報セキュリティ関連のエントリをたまに書いて、存命であることを報告するページ。

Burp Suiteとnghttpxを使ってHTTP2のWebアプリに接続してみよう

2015年2月にHTTP2がRFC化された。これから普及が進むことが期待される。既にいくつかのクライアントやサーバはHTTP2に対応しており、対応アプリケーションは、以下のGitHubでまとめられている。*1


github.com


HTTP2では、バイナリプロトコル、サーバープッシュ、多重化など新要素がある。これに伴うセキュリティ面ではOWASP等で議論が重ねられているところだけど、ここでは置くとして、さしあたり僕が気になるのは、従来型のWebアプリケーションのテストはどうなるんだろうという点。

テストのためにはフォワードプロキシが欲しい。が、あいにくBurp SuiteやFiddlerなどはまだ対応していない模様。上のGitHubを見てもフォワードプロキシはあまりなく、すぐ利用できるものもなさそう。
HTTP2はバイナリプロトコルなので、HTTPリクエストをそのままガシガシ編集することもできない。

いざ「HTTP2でアプリケーション作ったのでテストよろしくね」的な無茶振りがきた場合、途方に暮れるおそれがある。*2 *3

そこで今回は実験的に、Burp Suiteとnghttpxを組み合わせてHTTP2のWebアプリケーションにアクセスしてみたい。

nghttpxについて

HTTP2のリバースプロキシである。なんか使い方によってはフォワードプロキシのようにも使えるみたい。以下リンクを参照。

qiita.com

今回は、フォワード/リバース両方使う。

検証環境

検証環境のイメージ

以下のイメージ。

f:id:tosebro:20150422063700p:plain

ざっくり流れを説明すると、

・ブラウザからBurp Suiteを通して接続する。ここはHTTP1。

・クライアント側のフォワードプロキシ(nghttpx)でHTTP1→HTTP2にアップグレード

・サーバ側のリバースプロキシ(nghttpx)でHTTP2→HTTP1にダウングレードしてApacheに転送*4

アプリケーション

検証用に、入力値(名前)を受け取ってようこそというメッセージを出すだけのシンプルな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アプリケーションに接続できることを確認した。

アクセスの様子

f:id:tosebro:20150420232333p:plain
ブラウザから、サーバのURL「http://192.168.120.128:8443/hello.php」にアクセスしたところ。


f:id:tosebro:20150420232338p:plain
フォームをSubmitしたときのHTTPリクエスト


f:id:tosebro:20150420232343p:plain
POSTパラメータ「name」の値を改変


f:id:tosebro:20150420232345p:plain
HTTPレスポンス。改変後の値で処理されている。


f:id:tosebro:20150420232349p:plain
結果表示。

ログでの確認

フォワードプロキシのログを見ると、リクエストが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

課題

アクセス自体はできたものの、いま分かっている課題を挙げる。

  • フォワードプロキシ側で、サーバアドレスが決め打ちになってしまっている。複数ドメインにわたる場合などが問題。
  • サーバアドレスを実在のドメインに変えると動作しない場合があった。*6
  • TLS関連のテストができない。(別でnmapとかsslscanでやる?)
  • アップグレード/ダウングレードがあってロスする情報があるかもしれない。

まとめ

HTTP1→HTTP2にアップグレードできるフォワードプロキシ(nghttpx)を使って、Burp SuiteでHTTP2サイトにアクセスしてみた。Burp Suiteはテストに使えそうだけど、実用を考えるとまだクリアする課題がある。やはりBurp SuiteなどのテストツールがHTTP2に対応するのを期待したい。

*1:メジャーなところではTwitterがHTTP2に対応している。

*2:特に、NOと言うことが許されない体育会系の組織にいる現場の人(僕のような)には酷な話だ。

*3:Twitterはどうやってるんだろう。ソースコードレビュー?

*4:環境構築を簡単にするためApache利用

*5:脆弱性あったらごめんなさい。

*6:手元で見た限りではnghttp2.orgは接続可能、twitter.comは不可だった

IPv6に対する検証コマンドのメモ

IPv6のサーバに対して検証をする機会があって、コマンドとかIPv4とは勝手が違う部分があって苦労している。

 

あまりまとまっているページが見当たらなかったので、調べた内容を把握する範囲でメモしておこう。

基本的には、クライアントはLinux環境を想定している。

 

コマンドなど

 

ping

ping6コマンドを使う。

 ping6 -c 3 2001::abcd

リンクローカルアドレスはインタフェース番号を末尾に付ける。

ping6 -c 3 fe80::abcd%eth0

 

WindowsではpingコマンドでOK。

 

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 --script ssl-enum-ciphers -p 443 2001::abcd

 

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.1JDK 1.8.0_05、Burp suite 1.6(Free版)でやっています。

 

使い方

Burp proxyのコンテキストメニューにメニューが追加されているので、それを選べばOK。

 

f:id:tosebro:20140703060000p:plain

 

今後の課題

  • 他の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脆弱性

Google Online Security Blog: Google Services Updated to Address OpenSSL CVE-2014-0160 (the Heartbleed bug)

 

クライアントから情報が漏れるので、かなり危険なんじゃないかと思うけど、あまり注意喚起もされていないようなので知らない人もいるのでは?と思って、その検証と、対策などをまとめてみた。

該当する端末やアプリを使っている人はぜひ参考にして自衛してほしい。

 

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攻撃ができるか、以下の環境で検証してみた。

 

Heartbleed Detector端末のHeartbleed状況を確認する。

f:id:tosebro:20140427010150p:plain

左:端末A:Android 4.1.1(HTC J butterfly。リバースHeartbleed影響有り)

右:端末B:Android 4.0.3(HTC EVO 3D。影響無し)

 

手順と結果

1. 攻撃用サーバの準備

攻撃用サーバからスクリプトを実行する。

f:id:tosebro:20140427005353p:plain

サーバのURLは、例えばhttps://192.168.1.1:4433/のようになる。

 

2. 端末Aで攻撃用サーバにアクセス

端末AのAndroid標準ブラウザから攻撃用サーバにアクセスする。

サーバのコンソール上では以下のように端末のメモリ内の情報が表示された。(バイナリ部分はマスク)

 f:id:tosebro:20140427005519p:plain

 

取得したメモリ内容によっては、暗号化鍵や個人の情報が漏洩するおそれがある。

今回は、過去アクセスしたURL、サイトへのログインID、Googleアカウントなどが取得できた。

例:過去アクセスしたURL

f:id:tosebro:20140427010952p:plain

 

また、OSが影響受けても、アプリが影響を受けない場合*2、(そのアプリの通信からは)メモリ内容は漏洩しない。

例:Android 4.1.1(影響有り)でGoogle chrome(影響無し)を使ってアクセスした場合

f:id:tosebro:20140427010149p:plain

 
3. 端末Bで攻撃用サーバにアクセス

端末Bで同様にアクセスする。脆弱性がないので漏洩しない。

f:id:tosebro:20140427010148p:plain

 

以上の結果から、脆弱な端末のユーザを、攻撃用サーバのURLにアクセスさせることができれば、端末のメモリ内容を盗み取ることができると考えられる。

 

対策

まずは影響を受けるかチェックする。

Androidの場合はHeartbleed DetectorBluebox Heartbleed Scannerで、OSとアプリをチェックする。

 

不運にも該当するAndroid端末を使っている人は、以下のどちらかを検討する。

  • OSのアップデートがあれば適用する。
  • 機種変更する。(影響を受けないAndroidか、iPhoneに乗り換える)

 

アップデートが提供されていないとか、機種変更がすぐにできない場合は、いったん以下の自衛策を取りつつ、どこかのタイミングで機種を変える。

  • 不審なサイト(アングラ色の強いサイトなど)には行かない。
  • ブラウザには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/

https://forums.hak5.org/index.php?/topic/32368-exclusive-how-to-exploit-reverse-heartbleed-on-real-websites/

 

(追記)

国内のスマホは6機種該当するようですな。お使いの方はぜひアップデートを。

<OpenSSL欠陥>国内のスマホ6機種 OSに問題 (毎日新聞) - Yahoo!ニュース

 

*1:Heartbeat機能には対称性がある。つまり、サーバからクライアントにHeartbeatを送信することができる

*2:自前で、脆弱性のないSSLのライブラリをもっているとか