概況JPCERT/CCでは、インターネット上に複数の観測用センサーを分散配置し、不特定多数に向けて発信されるパケットを継続的に収集し、宛先ポート番号や送信元地域ごとに分類して、これを脆弱性情報、マルウエアや攻撃ツールの情報などと対比して分析することで、攻撃活動や準備活動の捕捉に努めています。本レポートでは、本四半期に観測された日本宛のパケットを中心に分析した結果について述べます。宛先ポート番号別パケット観測数のトップ5を[表1]に示します。サービス名はIANAの情報をもとに記載していますが、必ずしも各サービスプロトコルに則ったパケットが受信されているとは限りません。図1は、期間中のトップ5の宛先ポート番号ごとのパケット観測数の推移を示しています。5図2に期間中のトップ5のパケット送信元地域からのパケット観測数の推移を示します。[図2:2016年10~12月の送信元地域別トップ5ごとのパケット観測数の推移]クリックすると拡大されます本四半期は、23/TCPを含めて、主に機器が使用していると思われるポートに対するパケットが増加しTOP3を占めました。それ以外の複数のポートに対するパケットが増加しました。機器を対象としたパケット数の増加」で詳しく述べます。次に、送信元地域別のトップ5では、台湾が前四半期の6番目から3番目になりました。台湾がTOP5に入った理由は、宛先ポート番号別の内訳で一番多く55%近くを占めた23/TCP宛のパケットのおよそ13%が台湾を送信元地域としていたためです。その他の地域については、多少の増減はありましたが、特筆すべき状況の変化は見られませんでした。呼ばれるマルウエアの活動が盛んになっていることを記載しました。本四半期もPort23/TCPとPort2323/TCP宛のパケットが増加した状態が続きました。前述の2つのいずれとも異なる複数のポートに対するパケットが観測され、Miraiのソースコードが公開されたことにより、Miraiの亜種が登場したことが推測されました。図1で示したように、7547/TCP宛のパケットが3番目に多く観測されました。地域別の変化を見るため、図3に上位10地域のグラフを示します。[図3:Port7547TCP宛のパケットのトップ10ごとのパケット観測数の推移]クリックすると拡大されますブラジル・イギリス・トルコなど複数の地域からのパケットが、ほぼ同じタイミングで増加しましたが、その後次第に減っていきました。減少するスピードは地域により差異がありました。パケットの送信は多くの地域でISPへの接続に使用するネットワーク機器の脆弱性(*2,3,4)によるものと報じられました。それらの情報をもとに製品情報を調査したところ、複数の製品が該当しました。ユーザに機器を配布する際は、メーカの型番ではなくISPにて新たに型番を付ける場合が多く、型番から製品を特定することが難しいため、パケットが多く送信された地域のISPでは、修正ファームウエアの提供をISPが呼びかけたり、停止したルータの復旧方法をアナウンスしたりするなどの対応に追われたようです。したことから、JPCERT/CCでは、海外の型番をもとにして、国内で使用されている脆弱な機器を検索することは困難であると考え、マルウエアに感染した機器が踏み台となる事象が発生しているかどうかをみるために、国内の障害情報等について情報を収集しました。当該期間のパケットは1パケットのみであったことに加え、障害や緊急対応を行ったなどのアナウンスや報道も確認されていないため、日本国内への影響は小さかったのではないかと推測されます。続いて、2016年12月24日ごろから観測された、国内のIPアドレスを送信元とするPort5358/TCPに対するパケットの推移を図4に示します。[図4:Port5358/TCP宛のパケット観測数の推移]クリックすると拡大されます12月24日以前のパケットの送信状況を確認したところ、これらの送信元IPアドレスからMiraiの特徴をもつパケットをPort23/TCPやPort2323/TCPに対して送信していました。このことから、パケットの送信元に設置されていた機器は既にMiraiに感染していたと推測できます。不審なパケットを低減させるために、JPCERT/CCではこれまでもパケットの送信元に設置されている機種の推定を行ってきました。今回もJPCERT/CCではMirai、もしくは亜種のマルウエア挙動が変わった可能性があると考え、これらのホスト群を調査しました。その結果、送信元には共通する特徴があることがわかり、機種の特定には到りませんでしたが、機器に関するいくつかのヒントを得ることができました。TSUBAMEでの観測データと推定された機器の情報を関係すると思われる機器ベンダに提供しました。5358/TCPへパケットを送信するIPアドレスの管理者(多くはISP)にパケットログの情報を提供しました。その結果、ISPから情報を受けとったユーザが製品ベンダに連絡をしたとみられ、発生している現象に関する調査が行われ、機器がマルウエアに感染する経緯が特定されました。当該製品は、ある条件を満たした場合にのみマルウエアに感染します。JPCERT/CCでは、継続してマルウエアの挙動に関する情報をベンダに提供し、対策の検討に役立てていただいています。送信元IPアドレスの管理者に対する連絡を強化しています。その後も、既知の脆弱性が存在する監視カメラ製品のポートに対して、Miraiに感染していると思われる機器がパケットを送信するなどの事象(*5,6)が見られました。攻撃者はMiraiおよびその亜種を使って、インターネットからアクセス可能な機器に対して探索活動を行い、脆弱性への対応が行われていない、初期パスワード等をそのまま使用しているといったセキュリティ上問題がある機器に対して攻撃をおこなっていると推測されます。国内のオープンリゾルバ等を使ったDNS水責め攻撃の再開DNSのクエリに対するリプライパケットをTSUBAMEが、国内外の多数のIPアドレスから受信しています。受信したパケットを分析したところ、存在しないランダムなホスト名の名前解決要求パケットに対する応答パケットであることが分かりました。これは、DNS水責め攻撃のために、TSUBAMEのセンサーのIPアドレスを詐称して、オープンリゾルバに送信された名前解決要求パケットに対する応答パケットと考えられます。送信元Port53/UDPからのパケット数の推移を図5に示します。53/UDPからのパケット観測数の推移]クリックすると拡大されますオープンリゾルバ等を用いたDNS水責め攻撃は影響が深刻な攻撃手法の一つと考えられますので、オープンリゾルバをもつ組織の管理者に情報を提供して改善を求める活動を再開しました。一部の管理者からは、ルータのフィルタルールの不備などの調査結果を含む返信をいただきました。引き続き、DNS水責め攻撃を少しでも抑えられるよう、オープンリゾルバを減らすべく努力していく予定です。して実施したものです。広報(pr@jpcert.or.jp)まで確認のご連絡をお願いします。最新情報についてはJPCERT/CCのWebサイトをご参照ください。いいえその他、ご意見・ご感想などございましたら、ご記入ください。こちらはご意見・ご感想用のフォームです。各社製品については、各社へお問い合わせください。※本フォームにいただいたコメントへの返信はできません。javascriptを有効にすると、ご回答いただけます。ありがとうございました。