2010年2月上旬から始まったボットネットPushDoによるSSL接続攻撃について

2010年2月3日より、多数の発信元から、443/tcp(https)ポートに対して不正な形式のSSL接続が大量に発生するというDDoS活動が観測されはじめました。 観測事象と公開情報とをつき合わせていくと、このDDoS活動は、ボットネットPushdoによるものであるということがわかりました。
インシデント情報活用フレームワーク検討 WGでは、日本IBM Tokyo SOCの協力を得て、ボットネットPushdoによる443(https)ポートへのDDoS活動を調査しました。 本レポートでは、観測事象と公開情報とを用いて、ボットネットPushdoによる443(https)ポートへのDDoS活動について報告します。



経緯

2010年1月29日 PushdoSSLポートへのDDoS活動開始

Shadowserverから、PushdoによるDDoS活動の報告「Pushdo DDoS'ing or Blending In?」が公開され、www.cia.gov、tips.fbi.govなど、攻撃対象が340箇所近くにのぼることがわかりました。

2010年2月2日 snort検知ルールの公開

ISC.sans.orgから、Pushdoによる443(https)ポートへの攻撃を検知するsnortルールが報告されました。 $HOME_NET 443 -> $EXTERNAL_NET はエラー応答(図2-1の②)を、 $EXTERNAL_NET any -> $HOME_NET 443 は形式が不正なSSLネゴシエーションパケット(図2-1の①)を検知します。


図1-1. 攻撃を検知するsnortルール

2010年2月3日 DDoS活動の活発化

PushdoのDDoS活動の活発化に伴い、国内でも、いくつかの事象が観測され始め、IBM Internet Security Systems X-Forceからも報告「PushdoによるSSLを使用したDDoS攻撃」が公開されました。 不正な形式のSSL接続は、SSL_Hello_Msg_DoSとして検知されます。

2010年2月24日 国内での発生状況

jpドメインについても40箇所近くが攻撃対象となっていることがわかりました。

2010年4月28日 DDoS 攻撃を行うマルウエアに関する注意喚起

JPCERT/CCから、ガンブラー (Gumblar) などのホームページ誘導型ウイルスの中に、DDoS 攻撃を行う機能が追加されたとの注意喚起が発行されました。

2010年8月25日 Pushdoの指令サーバ停止

8つのホスティングプロバイダによって、ボットネットPushdoの指令サーバとして特定された30台のうち20台が停止されました。 M86 SECURITY LABS のブログ "Pushdo Botnet Cripped" によれば、指令サーバ停止により、8月25日時点で、Pushdoからのスパムが激減したということです。 しかしながら、 国内に存在するDDoS攻撃対象サイトでの観測結果(観測事象 =1=)では、PushdoからのDDoS攻撃に減少は見られません。 逆に、8月31日には、DDoS攻撃トラフィックの急激な増加を観測しています(図1-2)。

図1-2. スパムとDDoS攻撃対象サイトでのトラフィックの推移

[参考]

Shadowserver:Pushdo DDoS'ing or Blending In?
CNET Japan:「Pushdo」によるボットネット、CIAなど主要サイトに不正なSSL接続を送信か
IBM Internet Security Systems X-Force:PushdoによるSSLを使用したDDoS攻撃
JPCERT/CC Alert 2010-04-28:いわゆる Gumblar ウイルスによってダウンロードされる DDoS 攻撃を行うマルウエアに関する注意喚起
M86 SECURITY LABS:Pushdo Botnet Cripped


不正な形式のSSL接続

不正な形式のSSL接続では、11パケット、約283バイト(イーサネットフレームサイズでは約614バイト)の通信が発生します。 TCPコネクション確立後に、攻撃者⇒サーバ:形式が不正なSSLネゴシエーションパケットを受信し、サーバ⇒攻撃者:エラー応答パケットを送信するという流れになります。


図2-1. 不正な形式のSSL接続


図2-2. 攻撃者⇒サーバ:形式が不正なSSLネゴシエーションパケット(図2-1の①)


図2-3. サーバ⇒攻撃者:エラー応答パケット(図2-1の②)


ボットネット Pushdo

PushDoは、2007年1月頃に存在が確認されたボットネットであり、Pandex、Cutwailとも呼ばれています。 トレンドマイクロによれば、活動中のスパム配信用ボットネットのうち最大規模の1つと報告されています。 また、MessageLabsの2009年報告によれば、スパム配信用ボットネットで、180億メール/日に達し、110万~160万規模と推定されています。

[参考]

トレンドマイクロ:<TrendLabs Report>「Pushdo」の脅威に関する主要なファクターとその防衛手段
MessageLabs:MessageLabs Intelligence: 2009 Annual Security Report


観測日記

観測日記では、国内でも観測された事象の一部を紹介します。

  • 観測事象 =1=
    ウェブサーバは、443(https)ポートを稼動させておらず、 ウェブサーバ手前に設置した負荷分散装置が、SSL接続を受け付ける設定であったサイトでの観測事象です。 トラフィックが、どういう意図をもってのものかは不明であり、どこかのタイミングで、トラフィックが増大する可能性も考えられるため、監視を続けているとのことです(4月21日時点)。

  • 観測事象 =2=
    ウェブサーバが、80(http)と443(https)ポートとを稼動させていたサイトでの観測事象です。


観測事象 =1=

2010年2月4日
数十万個(/日)のIPアドレスから、不正な形式のSSL接続がウェブサーバ宛に届きだし、4月(4月21日時点)になっても継続しています。 このウェブサーバ自身は443(https)ポートを稼動させていませんでした。しかし、ウェブサーバ手前に設置した負荷分散装置が、SSL接続を受け付ける設定であったことから、インターネットからみた場合、ウェブサーバの443(https)ポートが稼動しているようにみえていたことになります。このことから、何らかの意図を持って大量のアクセスを行っているものと思われます。

2010年2月8日
ファイアウォールでSSLの接続を遮断しました。遮断後は、当初よりもアクセス頻度が減少したものの、継続的に20万個(/日)を超えるIPアドレスから接続要求がありました。


2010年3月下旬
当初1,000ppsを超える頻度だったものが、100~200pps程度に減少しています(図3-1の上段)。 また、アクセス数は1日ごとの周期で増減を繰り返していることと、アクセス元のIPアドレスが数十万(/日)IPアドレスに達していることから、ボットネットを利用したアクセスと思われます(図3-1の下段)。


図3-1. ファイアウォールログ:SSLアクセス数の推移(/日)


2010年4月16日
アクセス元のIPアドレスを分析してみたところ、アクセス元のIPアドレスは、インド、エジプト、ベトナム、パキスタンが上位に観測されています。 トラフィックで見ると、サウジアラビア、インドが上位に観測されています。


図3-2. アクセス元のIPアドレス上位(/日)


図3-3. トラフィック上位(/日)

2010年4月22日

図3-4. 急激なアクセス数の変動発生(/日)

2010年4月29日
DDoS 攻撃を行うマルウエアに関する注意喚起(4月28日)前のアクセス数について、"観測事象 =1="と"観測事象 =2="を比較してみたいと思います。 "観測事象 =1="と"観測事象 =2="における、DDoS 攻撃を行うマルウエアに関する注意喚起前後のアクセス数の推移には、 (1) 22日にアクセス数が増加した、(2) 26日頃から少しずつアクセス数の増加したという、似た特徴がありました。


図3-5. DDoS 攻撃を行うマルウエアに関する注意喚起前のアクセス数の推移(/日)


2010年5月7日
連休中のアクセス数について、"観測事象 =1="と"観測事象 =2="を比較してみたいと思います。 日単位でみた場合、"観測事象 =1="と"観測事象 =2="におけるアクセス数の推移(図3-6)は似ています。 時間単位でみた場合、アクセス数の推移全体としては似ていますが、"観測事象 =1="と"観測事象 =2="との間に多少のズレがあるようです(図3-7)。 これは、攻撃元として利用されているノードが異なることによる稼働の時差などが考えられます。


図3-6. 連休中のアクセス数の推移(/日)


図3-7. 連休中のアクセス数の推移(/時)

2010年5月31日
2月15日、4月6日、4月27日の3日間を比較してみたいと思います。 日本国内からの攻撃は、全体の攻撃からみると0.2~0.5%程度です(図3-8)。規模は小さいですが、攻撃全体に占める割合は純増しています。 4月27日に注目すると、アクセス元のIPアドレス上位とトラフィック上位にトルコが観測されました(図3-9)。


図3-8. 攻撃全体に占める日本からの割合の推移


図3-9. アクセス元のIPアドレス上位(/日)、トラフィック上位(/日)


2010年9月10日
ボットネットPushDoからのトラフィックを分析した結果、興味を引くトラフィックがありました。

1) Hostヘッダに他サイトのサーバ名が格納されたHTTPリクエストが攻撃対象のサーバに送付されている。

攻撃対象のサーバ宛のHTTPリクエストを確認してみたところ、本来、攻撃対象のサーバ名が格納されているはずのHostヘッダに www.facebook.comが格納されていました(図3-10)。


図3-10. Hostヘッダに他サイトのサーバ名が格納されたHTTPリクエストの例

また、HTTPリクエストのHostヘッダに格納されていたサーバ名は、www.fasebook.com以外にも多数ありました(図3-11)。

図3-11. HTTPリクエストのHostヘッダに格納されていた他サイトのサーバ名一覧

2) 攻撃対象のサーバのIPアドレス周辺に対して、まれに不正なSSL接続が行なわれている。

攻撃対象のサーバと同じサブネット上のIPアドレスに対して、まれに不正なSSL接続が発生していました。 新たな攻撃対象を見つけ出すためのスキャン行為の可能性が考えられます。 下線赤文字がDDoS攻撃先となった攻撃対象のサーバのIPアドレスで、 青文字が同じサブネット上のIPアドレスです(図3-12)。

図3-12. 攻撃対象のサーバのIPアドレス周辺に到着する不正なSSL接続の例


観測事象 =2=

2010年2月3日
ウェブサーバの443(https)ポートに対して、世界中のIPアドレスから不正な形式のSSL接続が大量に発生しはじめました。 このとき、443(https)ポートでは、不正な形式のSSL接続に対してネゴシエーションエラーで切断しているため、サーバへの実質侵害はありませんでしたが、正規の接続ができなくなりました。 80(http)ポートへの接続は、特に問題はありませんでした。
ウェブサーバSSLエラーログには、SSL3_GET_CLIENT_HELLO:no ciphers specified、SSL3_GET_CLIENT_HELLO:length mismatchの2種類のエラーログが記録されていました。


図4-1. ウェブサーバSSLエラーログの例

2010年2月4日
ウェブサーバでの443(https)ポート接続に対するタイムアウト時間(SSLSessionCacheTimeout)を短くすると共に、以降、ウェブサーバの443(https)ポート稼動を定期的(1回/日)にリブートすることにしました。


図4-2. ウェブサーバSSLエラーログ:SSLアクセス数の推移(/時)

2010年2月5日
3,000フレームほどのキャプチャデータを調べてみたところ、不正な形式のSSL接続は、9~12パケットで構成されていることがわかりました。 また、これらの不正な形式のSSL接続の通信は、TCPデータサイズでみると282~283バイト、イーサネットフレームサイズでは540バイト~680バイトで構成されていました。 キャプチャデータからトラフィック量を算出すると、約1,300pps、約0.9Mbps(イーサネットフレームサイズ試算)となります。
上り(攻撃者⇒サーバ):620pps, 0.57Mbps
下り(サーバ⇒攻撃者):662pps, 0.35Mbps


図4-3. 443(https)ポートへの通信パケット数とフレームサイズの分布

2010年2月16日
IPアドレスでの狙い撃ちでの攻撃であれば、攻撃対象から外れることを期待し、ウェブサーバのIPアドレスを変更してみましたが、対策としては空振りに終わりました(後日、攻撃対象がドメイン名で指定されているという情報を得ました)。


対策

ウェブサーバでの設定変更

攻撃対象がIPアドレスで指定されている場合
Shadowserverから報告されている「Pushdo DDoS'ing or Blending In?」には、SSL接続攻撃の攻撃対象がIPアドレスで指定されている場合があります。 このような場合には、IPアドレスを変更することでSSL接続攻撃を回避できる可能性があります。

攻撃対象がドメイン名で指定されている場合
ウェブサーバ、HTMLページでのリダイレクト処理によりアクセス先を変更する方法があります。 secure.in.gov(https://secure.in.gov/)では、HTMLページでのりダイレクトによりアクセス先の変更(<meta http-equiv="refresh" content="0;url=http://www.IN.gov/">)を実施しています(4月21日時点)。

ファイアウォールを用いた発信元IPアドレスの制限

Pushdoによる不正な形式のSSL接続の場合、発信元IPアドレスを国内IPアドレスからのみに制限することによる遮断措置は効果があります。

負荷分散装置の活用

発信元IPアドレスを制限できない場合には、負荷分散装置の導入を検討してください。


更新履歴

    2010-05-07
  • ・新規

発行日:2010-05-07T10:46+09:00
更新日:2010-09-17T11:10+09:00