1 概況
JPCERT/CCでは、インターネット上に複数の観測用センサーを分散配置し、不特定多数に向けて発信されるパケットを継続的に収集し、宛先ポート番号や送信元地域ごとに分類して、これを脆弱性情報、マルウエアや攻撃ツールの情報などと対比して分析することで、攻撃活動や準備活動の捕捉に努めています。なお、本レポートでは、本四半期に観測された日本宛のパケットを中心に分析した結果について述べます。
宛先ポート番号別パケット観測数のトップ5を [表1]に示します。
順位 | 宛先ポート番号 | 前四半期の順位 |
---|---|---|
1 | 23/TCP (telnet) | 1 |
2 | 445/TCP (microsoft-ds) | 4 |
3 | 8888/TCP | 13 |
4 | 0/ICMP | 2 |
5 | 22/TCP (ssh) | 3 |
なお、サービス名はIANAの情報をもとに記載していますが、必ずしも各サービス
プロトコルに則ったパケットが受信されているとは限りません。
図1は、期間中のトップ5の宛先ポート番号ごとのパケット観測数の推移を示しています。
クリックすると拡大されます
送信元地域のトップ5を [表2]に示します。
順位 | 送信元地域 | 前四半期の順位 |
---|---|---|
1 | 中国 | 1 |
2 | 米国 | 2 |
3 | 台湾 | 4 |
4 | 日本 | 3 |
5 | ロシア | 6 |
図2に期間中のトップ5のパケット送信元地域からのパケット観測数の推移を示します。
クリックすると拡大されます
Telnetサーバを搭載したネットワーク機器を対象とする探索活動については、過去の定点観測レポートでも紹介しましたが、本四半期も5月7日頃から23/TCP宛のパケット数が再び増加しました。また、インターネット定点観測レポート(2015年 1~3月) (*2) で言及した445/TCP宛のパケットが3月中旬から5月中旬にかけて増加した結果、2位に位置しています。
そのほか、4月中旬から8888/TCP宛のパケットが増加しています。この増加の原因は、オープンプロキシサーバの探索活動の影響と思われ、2.1で詳しく取りあげます。
2 注目された現象
2.1 オープンプロキシサーバの探索と推測されるパケットの増加本四半期は、4月上旬から5月中旬にかけて8888/TCP、37564/TCPなど複数のポート番号へのパケットが増加しました(図3)。 (*3) 8888/TCP宛のパケットは、通期で第1位の23/TCP宛のパケットよりも多く観される日(or週)が約6週間に渡って続いたほど増えたため、13位から3位にランクインしました。
クリックすると拡大されます
これらのポート番号宛の多量のパケットの発信目的を考察した時に最初に思い起こされるのが、オープンプロキシサーバのリストとして、IPアドレスとポート番号を掲載している海外の複数のWebサイトの存在です。これまでのTSUBAMEの過去の観測では、何度となく通常サービスに使用されていないポート番号に対するパケットが急増するという事象がありました。今回、宛先ポート番号が8888/TCPや37564/TCPのパケットと同じ送信元IPアドレスをもつパケットを探してみると、従来から知られているオープンプロキシサーバのポート番号宛のパケットが見つかるケースがあります。対応するオープンプロキシサーバのリストを調べると、8888/TCPなどのポート番号の情報が新たにリストに追加されていて、このことからオープンプロキシサーバの探索を目的としたパケットであったことが高い確度で推測されます。これらのポート番号を標準的に用いるメジャーなプロキシサーバ―ソフトは知られておらず、何らかのパッケージ・ソフトウェア製品が内部的に稼働させているプロキシ―サーバが、不適切なネットワーク・アクセス制御のために、インターネットに露出していることが疑われます。いずれにせよ、こうしたポート番号に気づいたオープンプロキシサーバのリストの管理者が、探索ポートとして追加したことが、この種のパケットの観測数が一時的に増えた原因であろうと推測しています。
2.2 53413/UDP宛のパケットの増加2015年6月10日頃から2週間ほど53413/UDP宛のパケットが増加しました (図4) 。
クリックすると拡大されます
このポート番号は、日本で広く利用されている製品ではほとんど使用されていません。2014年8月27日に公開されたトレンドマイクロ社のブログ記事によると、Netis/Netcore社製のルータ製品には脆弱性があり、このポート番号に細工したパケットを送ることで、ルータが用意している任意のコマンドを遠隔の第三者がルータ上で実行できるとされています (*4)。この問題は、9月5日までに製品ベンダがフォームウエアを更新し、解消されました。該当ポート番号にアクセスはできなくなったことをトレンドマイクロ社でも確認しています (*5) 。
6月中旬に増加したパケットは、この脆弱性を悪用してBotに当該製品を感染させるものだったことがJPCERT/CCの調査で分かりました。その手口は、次のとおりです。
1. | 攻撃者は、当該ルータの53413/UDPに対し認証用パケット送信することで、認証を完了させる |
2. | 細工した53413/UDPパケットを当該ルータに送り込んで、ルータ上に用意されたコマンドを用いて、インターネット上の外部サイトサーバからスクリプトファイルをダウンロードさせ、実行権限を書き換えてから実行させることで当該ルータをBot化させる |
この手口に対応した一連の攻撃パケットの増加が観測された期間が、脆弱性情報や修正パッチが公表された2014年9月以降も数回ありました。パッチの適用が進まない中で、新たにBot化する機器が今後も増え続け、DDoS攻撃がさらに深刻化する恐れがあります。 (*6)
3 参考文献
(1) | Service Name and Transport Protocol Port Number Registry |
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml |
|
(2) | JPCERT/CC インターネット定点観測レポート(2015年 1~3月) |
https://www.jpcert.or.jp/tsubame/report/report201501-03.html | |
(3) | 警察庁@Police |
インターネット観測結果等 (平成27年5月期) | |
https://www.npa.go.jp/cyberpolice/detect/pdf/20150624.pdf | |
(4) | トレンドマイクロセキュリティブログ |
UDPポートを開放した状態にするNetis製ルータに存在する不具合を確認 | |
http://blog.trendmicro.co.jp/archives/9725 | |
(5) | トレンドマイクロセキュリティブログ |
Netis製ルータに存在する不具合を修正する更新プログラムを検証 | |
http://blog.trendmicro.co.jp/archives/10050 | |
(6) | Shadow Server |
Vulnerable Netis Router Scanning Project | |
https://netisscan.shadowserver.org/ |
インターネット定点観測レポートPDF版はこちら
最新情報についてはJPCERT/CCのWebサイトをご参照ください。
JPCERTコーディネーションセンター(JPCERT/CC)
https://www.jpcert.or.jp/tsubame/report/index.html