ページの先頭です
インターネット上で発生するインシデントは、その種類や規模が時々刻々と変化しています。このため、IIJでは、流行したインシデントについて独自の調査や解析を続けることで対策につなげています。ここでは、これまでに実施した調査のうち、PlugXの背後にいる攻撃者について、DrDoS攻撃とその対策、電気通信事業におけるサイバー攻撃への適正な対処の在り方に関する研究会、の3つのテーマについて紹介します。
2014年3月、 IIJではBlack Hat Asia 2014(※50)において、PlugX(※51)に関する講演を行いました。この講演は、PlugXの検体からC&Cサーバなどの設定情報を抽出して解析することで、PlugXの検体群から共通項を見つけてグループ化し、それらPlugXグループの背後にどのような標的型攻撃のグループが関与しているかを調査したものです。本章では、その結果を共有すると共に、なぜこの調査を行ったのかを併せて解説します。
PlugXは、2012年3月に発見されたRAT(※52)であり、標的型攻撃での利用が度々確認されています。IIJでは、PlugXの亜種が本稿執筆時点で大きくわけて3タイプ存在することを確認しています。ここでは、それらをType I、II、IIIと呼ぶことにします。Type Iは、PlugXが発見されてから今まで一番多く発見されている検体であり、以前、本レポートのVol.21(※51)で解説しています。Type IIは、IIJ-SECT Security Diaryで新型PlugX(※53)として報告したとおり、2013年の第3四半期に発見された亜種です。PlugXの特徴であった"GULP"というシグネチャを含むヘッダを取り除き、Basic認証付きのProxyを通過する機能を持つなど、Type Iよりも大きく進化しています。Type IIIはType Iより前から存在しており、PlugXの前身(※54)として過去の事件に使用されたことが報告されています。C&Cサーバからの命令を処理するコマンドや、通信の特徴はTypeIやIIとほぼ同一でありながら、コードの特徴は大幅に異なり、耐解析機能もより強化されています。また、Type IやIIと同様に、現在でもアップデートされ続けています。
PlugXの各亜種は、それぞれコードの特徴が大きく異なります。そこで、IIJでは各亜種に対応する抽出スクリプトをそれぞれ作成することで、すべての亜種から有用な設定情報(C&Cサーバや、サービス名、レジストリ値といった自動実行に関する情報など)の抽出を可能にしました。Type IとIIに関しては、多くの処理を共通化することができたため、1つのImmunity Debugger(※55)用のスクリプトとして実装しています。Type IIIは、PlugXのコードを特定するための特徴が、難読化などの耐解析機能によって正規化できなかったため、半自動で抽出を行うIDA Python(※56)スクリプトとして実装しました。これらのスクリプトを利用して、150のユニークハッシュ値を持つPlugXの検体から設定情報の抽出を試みました。このうち、27検体については設定情報を持たない、デモバージョン(※57)でした。よって、残りの123検体について分類の対象としています。
図-14は、PlugXの分類手法を図示したものです。前述のスクリプトを用いて設定情報を抽出後、各検体の共通項を見つけて分類しています。
1. 各PlugXの検体からそれぞれのタイプに応じたスクリプトを用いて設定情報を抽出する。
2. 抽出した設定情報を基に、各検体間で設定情報の値が一致、もしくは整合性があるものを同じグループとして分類する。
第一段階としてサービス名を基に分類しました。PlugXは、感染ホストが再起動した場合でも継続的に活動できるよう、感染時にサービスやレジストリのRunキーに登録を行います。これらの値で特徴的なものをグルーピングしました(※58)。第二段階では、C&Cサーバの情報(FQDN、IPアドレス(※59)、ドメイン名、ドメイン所有者のメールアドレス)や、コード内のデバッグ文字列(※60)を基に更なるグルーピングを行いました。
これらの作業を繰り返してできたグループを表-1に示します。全PlugX検体の約3分の2を7グループに分類することができました。なお、今回は、最低4つの検体が属しているものを1グループとしています。
最後に、前項で生成したPlugXグループが、既知の標的型攻撃者グループとの関係があるかを調査しました。具体的には、標的型攻撃の外部レポートに記載されている検体のハッシュ値や、C&Cサーバの情報が一致しているかを調査しました。図-15は、それらの関係性をまとめたものです。今回の調査では7つのPlugXグループのうち、5グループが何らかの既存の事件に関連していることが分かりました。特に、5グループ中4グループが、APT1(※61)と呼ばれる攻撃者グループと関連していることが今回の調査で分かりました。これは、多くのPlugXを使う攻撃者がAPT1に属している、もしくは、少なくとも異なる攻撃者グループ間でインフラを共有していることを示しています。また、今回グループに分類しきれなかったPlugXのうち、8検体についてはAPT1やWinnti(※62)など、何らかの既知の標的型攻撃者グループに関わりがあることが判明しました。
今回は、PlugXを例にしてこのような調査を行いました。標的型攻撃では、少数の特定組織が狙われるため、攻撃者の意図、組織の規模、攻撃に使うツール、インフラ設備などの全貌が見えにくいという側面があります。各組織が入手できる検体数も限られており、少数の検体から得られた情報を頼りに対策を行うことになりがちです。それに対して、もし多くの検体を集められた場合、今回のように、多くのPlugXグループがAPT1との関連が見つかるなどの新たな事実が判明する可能性があります。もしそのようなことが分かれば、例えば、APT1の攻撃者がRATを経由して組織内に侵入した後に使用する攻撃手法や、攻撃ツールの特徴を基にした検出や対策が行えるなど、攻撃の進行状況に応じた多角的な対策を取ることができる可能性があります。
Black Hat ASIAにおける発表では、講演資料や設定情報抽出スクリプトに加え、各PlugXの検体と既知の標的型攻撃者グループとの相関図も併せて配布(※63)しています。これはSVGと呼ばれる画像フォーマットになっています。SVGは、画像でありながら実際にはXML形式でもあるため、こ れを解析することでC&Cサーバなど、今回開示した情報をすべて取り出すことができます。そのため、このデータを利用して出口対策などが可能になります。
標的型攻撃を受けた各組織が、もっと広く詳細に情報を開示し合うことが標的型攻撃の対策につながります。IIJではこの様な解析や調査活動を継続し、積極的に情報を開示することによって、標的型攻撃の対策に向けた活動を行っていきます。
2013年3月に、DNSのオープンリゾルバを悪用したDDoS攻撃が問題となりました(※64)。この攻撃は、外部からの再帰的な問い合わせを許可しているDNSキャッシュサーバを悪用し、攻撃対象のIPアドレスに送信元IPアドレスを偽装した問い合わせを行うことで、その応答を攻撃対象のサーバに対するDDoS攻撃として送りつけるものでした。
10月頃には、NTPによるDDoS攻撃が観測されており(※65)、12月には米国Symantec社がブログで、NTPによるDDoS攻撃に関する報告を行いました(※66)。これらのNTPによるDDoS攻撃では、NTPの管理機能の1つであるmonlistを悪用しており、DNSによる攻撃と同様に送信元IPアドレスを偽装した問い合わせを行うことでDDoS攻撃を行っていました。この問題については2014年1月に入り、DDoS攻撃に悪用される可能性が高いとして、日本でもJPCERTコーディネーションセンターなど複数の組織から注意喚起が行われており*(※67)、実際に、この攻撃によると考えられる被害や、踏み台となった事件が複数確認されています。更に、欧米では2013年12月頃から何者かによるゲーム関連サイトなどに対するNTPによるDDoS攻撃が複数発生しており、最大で80Gbpsにも達したことが、米国のDDoS対策事業者の1つであるStaminus社によってブログで報告されています(※68)。また、クラウド事業者であるCloudFlare社のブログでは、同社の顧客に対して、攻撃規模としては最大で400Gbpsの攻撃があったことを報告しており(※69)、更に、ArborNetworks社からは、同社の複数ISPネットワークにおける観測情報として、NTPによる通信量が最大で800Gbpsにも上ったと報告されています(※70)。
これらの攻撃は、Distributed Reflection Denial of Service attacks(以下、DrDoS攻撃)と呼ばれ、その攻撃の容易さと増幅率による影響の大きさから問題となっています。本稿では、DrDoS攻撃について解説すると共にその対策について検討します。
DrDoS攻撃はその名のとおり、ある通信の応答(反射)を悪用した攻撃です。DNSやNTPなど、UDPのサービスが悪用されることが多いですが、これはUDPがコネクションレスのプロトコルであることに起因しており、攻撃の容易さに繋がっています。攻撃は踏み台となった脆弱な機器のIPアドレスからの攻撃に見えるため、被害者からは本当の攻撃者が分かりません。このため、攻撃元からの通信を遮断するなどの対処を行ったとしても、新たな踏み台を見つけて攻撃が継続できることから、被害者側での対策が攻撃の根本対処にはつながらない場合もあります。
更に、攻撃先を直接攻撃する場合に比べ、DrDoS攻撃では、問い合わせに対する応答のデータ量が多いことを利用して、その攻撃規模を数倍から数十倍に増幅させます。例えば、DNSの場合では理論上の増幅率は70倍まで増幅される可能性があります(※71)。今回問題となった、NTPのmonlist機能を悪用した攻撃の場合、1つの問い合わせに対し、理論上の最大値で返答した場合、約200倍のデータが送られることになります。このように、NTPの場合には増幅率が非常に高いことが分かります(※72)。DrDoS攻撃では、これにより、攻撃先の回線容量を超える通信量を発生させています。
今回、問題となったNTPのmonlistによるDrDoS攻撃の可能性については、NTPの実装に関する開発者のコミュニティで2010年に指摘されており、同年5月には修正が行われていました(※73)。しかしながら、この修正はDevelopment(開発版)のみに反映され、Stable(安定版)は4.2.6p5のまま、本修正は反映されていませんでした。このため、一部のntpdの実装を使っていたルータなどの機器やUNIX系OSでは、この修正が反映されていませんでした(※74)。
図-16に今回問題となったNTPによるDrDoS攻撃について示します。ntpdなど一部のNTPの実装では、管理のために、参照しているクライアントのIPアドレスの一覧を返すmonlistコマンドが実装されています。外部からのこの問い合わせに応答するルータやサーバなどの機器があった場合、送信元を攻撃先のIPアドレスに偽装した問い合わせを送ることで、返答が攻撃先に返ることになります。攻撃者は、このような通信を多数の機器に対して行うことで攻撃を行います。ntpdでは、参照しているクライアントのIPアドレスを、最大で600までリストとして持つことから、今回の攻撃では、攻撃者は外部から詐称したIPアドレスで連続して問い合わせを行うことで、リストを最大値まで増やした後に、実際の攻撃先を詐称して攻撃を行っていたと考えられます。
今回のNTPの問題について、NTPサーバにおいて2つ注意する点があります。1つは、DrDoS攻撃の踏み台として悪用される可能性です。これらの攻撃の踏み台となってしまった場合には、攻撃の被害者であると同時に加害者となってしまうことになります。もう1つは、情報漏えいの可能性です。今回の問題では、管理機能として参照しているクライアントのIPアドレスの一覧を返すmonlistコマンドが使われています。このため、外部からの問い合わせに答えることで、このNTPサーバを利用しているネットワーク上のクライアントのIPアドレスなどの情報が外部に漏れる可能性があります。
図-17に昨年10月初めから今年3月末の期間で、ハニーポットに到着したNTP(123/UDP)の通信について、発信元IPアドレスの国別分類を示します。ここに示したとおり、11月中旬よりドイツを発信元とした通信が行われていたことが確認できます。この後、今年の1月中旬にCERT/CCなどか ら脆弱性情報が公表(※75)された時期から継続的に通信が発生していることが確認できます。国別で見ると、米国が36.8%と最も多く、オランダの25%、ドイツの14.3%と続いており、欧米からの通信が多いことが確認できます。日本からの通信も4位で5.9%ありました。このことから、この問題が公表されてから問題の確認を行ったり、攻撃の試みを行う活動が増加したことが推測できます。また、DrDoS攻撃では、送信元を偽装した問い合わせを問題のあるサーバなどに対して行いますが、この期間に確認された通信では、総数があまり多くないため、外部からの問い合わせを許可しているサーバやルータなどを探索する活動なのか、送信元に対する攻撃なのか判断することはできませんでした。しかしながら、送信元の一部がゲーム関連のサービスを提供していると考えられるIPアドレスであったことなどから、攻撃と探査活動の両方が行われていたと考えられます。
DrDoS攻撃では、IPアドレスを詐称することで比較的容易に攻撃が行えるため、悪用できる脆弱性や新たな攻撃手法が公表されると、すぐに悪用の試みが行われる傾向があります。DrDoS攻撃の発生情報に注意し、自分の管理するシステムが攻撃に悪用される可能性について検討し、対処する努力が必要です。
また、今回の事件では、NTPが問題となりましたが、DrDoS攻撃に利用されるプロトコルはNTPだけではなく、DNSやSNMP、ECHO、Chargenなども悪用される可能性があります。サーバやルータなどの機器をインターネットに接続する場合には、まず、機器の脆弱性情報に注意し、ファームウェアなどについてセキュリティの問題のないバージョンを利用することが必要です。更に、機器において初期状態から動作しているサービスについて、利用者が認識していない状況で、踏み台として悪用されてしまうような場合も見受けられます。このような状況にならないために、機器の導入時には不要なサービスを停止し、適切にアクセス制御を設定します。導入後においても、動作するサービスについてインターネット側から継続的に調査することで、設定ミスを早期に発見することができ、外部から第三者に悪用される可能性を減らすことができます。
また、DrDoS攻撃では、送信元を詐称して攻撃を行うため、適切な通信制御を行うことでその影響を低減することができます。例えば、送信元検証(Source Address Validation)(※76)のような、詐称した通信がネットワークに流 入することを防ぐ技術を利用することで、このような送信元のIPアドレスを詐称した攻撃を防ぐことが可能となります。
更に、ISPのネットワーク網において、これを遮断することについて、総務省の研究会などで検討されています。この議論については、「1.4.3 電気通信事業におけるサイバー攻撃への適正な対処の在り方に関する研究会」も併せて参照してください。
これまで解説したとおり、DrDoS攻撃は、攻撃の容易さに比べるとその攻撃の影響が非常に大きいことから、注意すべき脅威の1つです。一方で、攻撃としては比較的古くから知られていたものの、具体的な脅威があまりなかったことから、これまで十分な対策が行われているとはいえませんでした。今後も、同様の手法を用いた新たな攻撃が出現することが考えられます。これに備えるためにも、日頃から利用している機器の管理を適切に行う必要があります。IIJとしても、業界団体などを通じて、適切な対策に向けた活動を今後も継続して行っていきます。
ここでは2013年11月から2014年3月までの期間に実施された、総務省の研究会「電気通信事業におけるサイバー攻撃への適正な対処の在り方に関する研究会」の検討内容について解説します。この研究会は有識者や通信関連団体により構成されていますが、技術的な内容を検討するためのワーキンググループが組織され、また各関連団体においても検討の場が設けられるなど、短い期間に多くの人が関わる複数の場で、数々の議論がなされました。研究会の議事は要旨のみの公開となっていますが、ここでは公開された「第一次とりまとめ」を元に、検討のポイントについて紹介します。
この研究会では、最近の攻撃に関連する課題として次の5つについて検討を行っています。
これらのような攻撃の多くは通信を媒介として発生します。また通信インフラ自体も攻撃にさらされることから、攻撃への対処の機能を通信の過程で実現することは、ある程度必要になることです。加えて、通信事業を行うISPにおいて攻撃に対処することで、数多く発生する被害を効果的に防ぐことも可能です。一方で、通信の過程において攻撃に対処することは、通信すべてについて情報(通信内容や、誰がいつどこに通信を行ったのかなどの外延情報も含む)を取得し、その情報を利用することで攻撃の有無やその様態を判断し、適切に攻撃の通信を止めることを意味します。これは電気通信事業法にある通信の秘密を犯す行為、つまり違法行為にあたります。
そこで、通信事業において攻撃への対処を行うために、攻撃それぞれについて、その発生の原因や影響と、取りうる対処法に関して、違法性が阻却されるかどうかを確認する必要があります。まず、通信の情報を利用した攻撃への対処は、通信の当事者である利用者が同意したうえで実施することができますが、どのように有効な同意を得るかが大きな論点となります。また、利用者の同意の有無に関わらず、攻撃への対処として行う行為が、通信事業者にとっての正当防衛、緊急避難、正当業務行為などに該当する場合も考えられます。この研究会においても、5つの課題について、これらの検討を行っています。以下にそれぞれの検討の概要を示します(※79)。
総務省施策ACTIVEで実施している、Web感染型マルウェアなどへの感染防止の試みのうち、通信に介在する装置などを用いて、すべての利用者に包括的に実施するURLフィルタリングの可能性について検討されています。利用者の通信に関わる情報を利用した対策については、将来契約者の不利益に繋がる可能性のあることから、従来は個別同意が必要とされていました。この課題の検討では、約款に基づく包括同意において、
などの条件を満たす場合については、有効な同意と見なすことができるとしています。また、併せて契約約款に記載すべき事項や注意喚起画面の例を示しています。
マルウェア対策を行う様々な組織の活動の結果、マルウェアを制御するサーバが差し押さえられる場合が増えてきています。そのサーバに蓄えられた情報を元に、感染に気づいていない利用者を特定し、感染の事実や駆除の方法を伝える注意喚起を実施することが検討されました。この場合においては、C&Cサーバに蓄積された通信に関わる情報のうち、接続元のIPアドレスやタイムスタンプを元に、ISPにおいて顧客情報を検索し、利用者を特定することが通信の秘密(外縁情報)の侵害にあたります。この検討では、C&CサーバにIPアドレスなどの記録が残っている端末は、実際に当該サーバを利用するマルウェアに感染しており、そのマルウェアによる被害を受けるとしたうえで、C&Cサーバに残った記録を用いた対処方法について議論しています。結果として、当該IPアドレスから特定した利用者の情報を、注意喚起以外の用途で利用しない場合には、緊急避難として違法性が阻却されるとしています。
設定の緩いDNSリゾルバを踏み台とし、大きな通信量をともなうDDoS攻撃(DNSAmp攻撃)が、2013年に多く発生しました。DNSAmp攻撃は、攻撃者からDNSリゾルバに向かう通信、DNSリゾルバからISPのDNSサーバに向かう通信、インターネット上のサーバからの増幅された応答といった、複数の通信により構成されます。ここでは、それぞれの通信の状況や、その通信で対処を行うことによる効果について議論を行った上で、攻撃者から踏み台になるDNSリゾルバに向かった、増幅を誘発するための通信をブロックする対処について検討しています。また、通常の状況では利用者が特定できない、動的IPアドレスの範囲に多数のDNSリゾルバが存在するために、包括的にブロックを行う必要がある状況を想定しています。
この検討では、動的IPアドレスの空間に対するDNSのクエリの通信をブロックすることについて、宛先のIPアドレス及びポート番号を確認した結果がDNSAmp攻撃の防止以外の用途で利用しない場合に、正当業務行為として違法性が阻却されるとしています。
迷惑メール送信対策として広く利用されているSMTP認証ですが、最近は利用者によるパスワードの使いまわしなどに起因して、リスト型攻撃などの不正アクセスの対象となり、第三者にメール送信機能を悪用される場合が発生しています。ここでは、この課題への対策として、
の2つについて検討しています。いずれの場合も、サーバに対する通信状況に関する情報を元に判断し、一時的に通信を行わせなくする行為ですが、利用者によるパスワード変更などで不正利用が解消するまでの期間、もしくは攻撃が継続する期間に限って行う場合には、正当業務行為として違法性が阻却されるとしています。
この課題としては、システムの脆弱性を悪用する内容を含む通信を検出し、通信先に届けないことで攻撃を未然に防ぐ対策と、同時多発的なDDoS攻撃や国内のISPの利用者同士が攻撃をしあっている状況などに対する、ISP間の連携による対策について検討が行われました。しかし、前者は通信内容を直接判断する行為であり、また脆弱性を保有するシステムに依存する問題でもあること、後者は検討の前に連携が必要となる場面に関する整理が必要であることから、この一次取りまとめでは今後更に検討を進める必要があるとしています。
以上のように、この研究会では設定した5つの課題に関する検討を実施し、特に、いくつかの対策について、約款に基づく包括同意をもって利用者による有効な同意と解釈することや、従来攻撃の発生後に正当防衛や緊急避難として許容されてきた攻撃への直接的な対策について、正当業務行為として認められる検討結果を得ています。これらの結果は、今後ISPにおける攻撃対策を検討する上で、大きな影響を及ぼす成果であると考えることができます。
インターネット上の攻撃の状況は日々変化しており、今回具体的に検討された範囲においても、例えばNTPサーバを踏み台としたDDoS攻撃の発生については、その発生の事実を認識していることを言及するのみにとどまっています。このことからも研究会自体は今後も継続し、新しい攻撃とその対策について検討を進めるべきだと考えます。
また、今回検討された課題についても、ISPなどの通信事業者において実際に適用する場面では、より詳しく指針を示す必要があります。例えば、C&Cサーバをテイクダウンした場合において、どのような組織からの情報を信用して良いのか検討を要します。また、SMTP認証に関わる通信の異常についても、可能な限り多くの利用者や事業者が納得できる定量的な基準づくりを試みる必要があります。
このため、この研究会の検討結果を通信事業の実務上の状況に適用させるためのガイドラインづくりを、インターネットの安定的運用に関する協議会などの場で進めていきます(※80)。
ページの終わりです