★注意★ 間違っても本番サーバで試さないでください。人生終わります。
■対象
脆弱性があるのは、2.0.64以下の全ての2.0系と2.2.19以下の全ての2.2系。1.3系にはありません。
■脆弱性の概要
Range ヘッダは本来、取得するコンテンツのバイト数を指定してリクエストを送るために使います。例えば、Range: bytes=500-600 とすれば、GET 対象のコンテンツの 500byte 目から 600byte 目までのデータだけを取得することができます。これによって、FTP のレジューム機能のようなものが HTTP でも実現できるわけです。このレンジ指定は、カンマで区切って複数記載できます。その場合、それぞれの指定幅の複数のコンテンツが返されます。
Accept-Encoding ヘッダは、クライアントが解釈可能なコンテンツのコーディング方式をサーバ側に知らせるためのヘッダです。これを知らされたサーバはそのエンコード方法が利用可能ならエンコードしてデータを返します。例えば Accept-Encoding: gzip がリクエストヘッダにあった場合、mod_deflate や mod_gzip などのモジュールが組み込まれて設定されていれば(デフォルトでは組み込まれません)、コンテンツを動的に gzip 圧縮して返します。mod_rewrite 等で予め圧縮しておいたファイルに誘導することもできますし、モジュールに頼らなくてもCGIなどのプログラムで独自に実装することも勿論できます。帯域を節約したい場合に有効です。
※HTTPヘッダについて詳しくは RFC 2616 を参照してください。
で、Apache Killer はというと、大量のレンジ指定をリクエストすることによって、サーバのリソースを食いつくします。どれだけ大量かというと、こんな感じです。
上記のレンジ指定を含んだリクエストを複数投げつけることで攻撃します。どれぐらいのセッション数で DoS を引き起こせるかはサーバ側のスペック次第ですが、クライアント側にはほとんど負荷にならない量でサーバ側に大ダメージを与えられます。サーバが gzip 圧縮可能な設定になっていると更にダメージUP。そういう意味で mod_deflate などが使われていると効果的なわけですが、必須ではありません。
どのリソースがボトルネックになってくるかは、動的な gzip 圧縮が有効になっているかどうかや、サーバのスペック次第なところがあると思いますが、いずれにせよ DoS は成立してしまいます。
では実際にやってみましょう。
■検証環境
サーバ:Solaris10 + Apache 2.0.64 / CentOS5.4 + Apache 2.2.3
※OSは何でも良いです。Apache も対象バージョンであれば何でも OK。モジュールもデフォルトで構いません。
クライアント:Solaris10
※Perl5以上が使える環境であれば何でもOKです。攻撃対象のサーバとは分けましょう。
■検証
出回っている攻撃ツールには killapache.pl と apachepartial.pl がありますが、killapache.pl のほうはモジュールのインストールが必要だし、use strict; してないし、バグもあるし、使い勝手悪くて編集しないと使い物にならないので、apachepartial.pl を使います。
http://pastebin.com/NCDv9eTh
ダウンロードするなりコピペするなりして、クライアントに設置します。
サーバは Apache が起動していなければ起動します。vmstat 1 で観察しましょう。
いよいよ攻撃です。apachepartial.pl を使って攻撃対象の URL を探します。攻撃が成立するのは、レスポンスとして 206 Partial Content を返してくる URL のみです。DocumentRoot に入っているコンテンツ次第では、単純に / では 206 が返ってこない場合がありますので、その場合は適当に検証用のファイルを置くなりしてアクセスしてみてください。ファイルサイズが小さいとうまくいかないので、1300byte 以上あるファイルを用意して試してください。
引数は、ホスト名、パス、子プロセス数、ループ数、ポート番号です。ホスト名以外は省略可能で、デフォルトでは前から順番に / 、10、5、80 が使われます。
※OKパターンの例
サーバの vmstat 1 の様子です。(Solaris10 + Apache 2.0.64)
サーバの vmstat 1 の様子です。(CentOS5.4 + Apache 2.2.3)
Solaris10 + Apache 2.0.64 の結果も CentOS5.4 + Apache2.2.3 の結果もほぼ同じです。最初の idle がほぼ 100 の間は何もしていない時です。攻撃を開始するとほぼ同時に、メモリが食い尽くされ、ひどいスラッシング状態に陥り、ディスクI/O待ちのプロセス数が頭打ち状態になりました。攻撃を停止してもこの状態は続き、Web の応答は勿論、新たにOSにログインすることもできません。vmstat も 1 秒ごとには流れなくなっています。DoS 成功です。
放っておいても回復しないのでOSごと再起動してしまいましょう。
次回は、アナウンスされている暫定回避策の有効性確認と対策済みバージョンの検証を行いたいと思います。
0 件のコメント:
コメントを投稿