脆弱なホストを狙った不正中継を見抜く：インシデントの見抜きかた（3）（1/3 ページ）
猛威をふるったBlasterワーム。これが大流行したのは2003年でしたが、いまだにこのワームの痕跡はインターネット上に残っています。その理由の1つは、いまだにセキュリティパッチが適用されていないホストが残っていることにもあります。今回は脆弱なホストや設定ミスによって発生する「穴」への攻撃を見抜く方法を解説します（編集部）
※ご注意
他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。
本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。
また、本稿を利用した行為による問題に関しましては、筆者およびアイティメディア株式会社は一切責任を負いかねます。ご了承ください。
不正中継、踏み台といった脆弱なホストの悪用
インターネット上には、無数の脆弱なホストが存在していると考えられる。過去に猛威をふるったSQL slammer、Blaster、Nimdaなどのワーム、およびその亜種と思われるさまざまなトラフィックがいまだ絶えることなく観測されていることからもそれは証明されている。
それらはなぜ存在しているのだろうか。設置されていることさえ忘れ去られているサーバ、ファイアウォールがなくほぼ初期インストール状態のマシン、単なる設定ミス、そしてブロードバンドでつながれセキュリティは考慮されていない個人用PC……脆弱なホストがネットにつながれてしまう理由は多岐にわたるであろう。
今回は、これらインターネット上の脆弱なホストの悪用方法として、特に不正中継を取り上げよう。
被害者が加害者になり得る不正中継の怖さ
攻撃者の狙いは、本来彼らが実現したい不正行為をより確実なものとすることであり、匿名性やCPU／メモリリソースを確保する手段として、脆弱なホストを積極的に悪用する。
本来彼らが実現したい行為とは、迷惑メールを大量にばらまいたり、彼らの個人的な趣味のため、掲示板への書き込みや成人向けサイトへ匿名性を保持したままアクセスすることなどが挙げられる。
悪用されたホストは、ホームページの改ざんや情報取得（情報漏えい）など直接的で分かりやすい事象とは異なるため、正しく運用管理されていなければ被害に遭っていることを見落とすことになる。
不正中継の怖さは、被害者であるはずの管理者が、気付いたときには加害者となり得る点で、例えば迷惑メールの配信を助長したということで、強いクレームとその対応に追われる、といったことはよく耳にする話ではある。
HTTPプロキシを利用した不正中継
プロキシは代替サーバの総称で、HTTPの通信を代替するものはHTTPプロキシなどと呼ばれている。
HTTP通信代替の仕組みは簡単で、クライアントから受け取ったHTTPのリクエストをそのままプロキシがWebサーバに対して行い、HTTPの戻り（レスポンス）をクライアントに渡すだけである。
そのため、HTTPの通信を代替するプロキシを探すには、HTTPリクエストをサーバに送り、応答があるかを確かめればよい。単純な手順で探せることから、攻撃者は常にHTTPプロキシを探すような通信を発生させているのが現状である。
なお、プロキシに送信するHTTPリクエストには特徴があり、“GET http://www.example.com/ HTTP/1.0”というようにGETやPOSTといったメソッドの形式がURIになる。
HTTP CONNECTを利用した不正中継
ここ数年はHTTP CONNECTメソッドを用いて、スパムなどのSMTPメールを送るという不正中継の通信もよく目にするようになった。
「HTTPなのにSMTPの通信？」と思われるかもしれないが、HTTP/1.1（RFC 2616）のCONNECTメソッドを用いることで、SMTPに限らずTCPの通信をトンネリングさせることができる。
【HTTP CONNECTメソッドの書式】
CONNECT 中継先ホスト:中継先ポート HTTPプロトコルバージョン
もともとCONNECTメソッドとは、通常のHTTPプロキシが代理応答のできない通信を透過的に中継（トンネリング）させるために考案されたものだ。その代表的な例がSSLの通信である。
SSLは通信を確立するために暗号鍵交換の手順が必要になる。この手順はプロキシが代替できない部分であり、負荷も高い部分である。そのため、効率的に処理できるよう、SSLの通信をHTTP CONNECTで、単に中継のみ行うよう設計しているプロキシは多い。
しかし先に述べたように、すべてのTCPプロトコルもトンネリングできることから、攻撃者はHTTP CONNECTで有効なプロキシを探し出し、その仕組みを悪用してスパムメールの送信にプロキシを不正中継ホストとして利用している。
例として、CONNECTメソッドを使ってSMTPを中継させる通信を以下に紹介しよう。
SMTPを中継する場合、CONNECTの後の「中継先ホスト」にメール送信先のメールサーバ、「中継先ポート」に25（SMTP）を指定するだけでよい。あとは、HTTPプロキシがこの要求を許可すれば、それ以降は接続元と中継先メールサーバとのSMTPによる通信がやりとりされることになる。
% telnet proxy.example.com 80 Trying 10.0.0.1... Connected to proxy.example.com Escape character is '^]'. CONNECT mail.example.net:25 HTTP/1.1 Host: mail.example.net HTTP/1.0 200 Connection Established Proxy-agent: Apache/2.2.6 (Unix) mod_ssl/2.2.6 OpenSSL/0.9.8e DAV/2 220 mail.example.net ESMTP Postfix HELO mail.example.net 250 mail.example.net MAIL FROM: unknown@example.com 250 2.1.0 Ok RCPT TO: foobar@example.net 250 2.1.5 Ok DATA 354 End data with <CR><LF>.<CR><LF> Subject: test mail From: unknown@example.com To: foobar@example.net test . 250 2.0.0 Ok: queued as 92571107D4 QUIT 221 2.0.0 Bye Connection closed by foreign host.
説明のため行番号を付与した
この例では、まずproxy.example.com（80/tcp）にHTTP接続し、その後にCONNECTメソッドを用いてmail.example.net とSMTP（25/tcp）の通信をやりとりしている。
CONNECTメソッドがHTTPプロキシによって許可されたことは、8行目のHTTPステータスコードの「HTTP/1.0 200 Connection Established」からうかがえる。
許可された後、10行目以降は接続元と中継先メールサーバとのSMTPの通信となり、HTTPプロキシは、単にSMTPの通信をそのまま中継（トンネリング）するだけとなる。最終的にこの通信が成立すると、foobar@example.netあてにメールが届く。
なお、CONNECTメソッド自体は不正なものではないため、攻撃と判断するにはそのほかの要素を参照する必要がある。判断については後述する。
Copyright © ITmedia, Inc. All Rights Reserved.