ページの先頭です


ページ内移動用のリンクです

  1. ホーム
  2. IIJの技術
  3. セキュリティ・技術レポート
  4. Internet Infrastructure Review(IIR)
  5. Vol.23
  6. 1.インフラストラクチャセキュリティ

Internet Infrastructure Review(IIR)Vol.23
2014年5月28日発行
RSS

目次

1.4 フォーカスリサーチ

インターネット上で発生するインシデントは、その種類や規模が時々刻々と変化しています。このため、IIJでは、流行したインシデントについて独自の調査や解析を続けることで対策につなげています。ここでは、これまでに実施した調査のうち、PlugXの背後にいる攻撃者について、DrDoS攻撃とその対策、電気通信事業におけるサイバー攻撃への適正な対処の在り方に関する研究会、の3つのテーマについて紹介します。

1.4.1 PlugXの背後にいる攻撃者

2014年3月、 IIJではBlack Hat Asia 2014(※50)において、PlugX(※51)に関する講演を行いました。この講演は、PlugXの検体からC&Cサーバなどの設定情報を抽出して解析することで、PlugXの検体群から共通項を見つけてグループ化し、それら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検体からの設定情報の抽出

PlugXの各亜種は、それぞれコードの特徴が大きく異なります。そこで、IIJでは各亜種に対応する抽出スクリプトをそれぞれ作成することで、すべての亜種から有用な設定情報(C&Cサーバや、サービス名、レジストリ値といった自動実行に関する情報など)の抽出を可能にしました。Type IとIIに関しては、多くの処理を共通化することができたため、1つのImmunity Debugger(※55)用のスクリプトとして実装しています。Type IIIは、PlugXのコードを特定するための特徴が、難読化などの耐解析機能によって正規化できなかったため、半自動で抽出を行うIDA Python(※56)スクリプトとして実装しました。これらのスクリプトを利用して、150のユニークハッシュ値を持つPlugXの検体から設定情報の抽出を試みました。このうち、27検体については設定情報を持たない、デモバージョン(※57)でした。よって、残りの123検体について分類の対象としています。

PlugXの分類

図-14は、PlugXの分類手法を図示したものです。前述のスクリプトを用いて設定情報を抽出後、各検体の共通項を見つけて分類しています。

図-14 PlugXの分類方法

1. 各PlugXの検体からそれぞれのタイプに応じたスクリプトを用いて設定情報を抽出する。

2. 抽出した設定情報を基に、各検体間で設定情報の値が一致、もしくは整合性があるものを同じグループとして分類する。

表-1 PlugX検体の分類結果

第一段階としてサービス名を基に分類しました。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)など、何らかの既知の標的型攻撃者グループに関わりがあることが判明しました。

図-15 PlugXグループと標的型攻撃者グループとの相関図

新たな対策手法の検討

今回は、PlugXを例にしてこのような調査を行いました。標的型攻撃では、少数の特定組織が狙われるため、攻撃者の意図、組織の規模、攻撃に使うツール、インフラ設備などの全貌が見えにくいという側面があります。各組織が入手できる検体数も限られており、少数の検体から得られた情報を頼りに対策を行うことになりがちです。それに対して、もし多くの検体を集められた場合、今回のように、多くのPlugXグループがAPT1との関連が見つかるなどの新たな事実が判明する可能性があります。もしそのようなことが分かれば、例えば、APT1の攻撃者がRATを経由して組織内に侵入した後に使用する攻撃手法や、攻撃ツールの特徴を基にした検出や対策が行えるなど、攻撃の進行状況に応じた多角的な対策を取ることができる可能性があります。

Black Hat ASIAにおける発表では、講演資料や設定情報抽出スクリプトに加え、各PlugXの検体と既知の標的型攻撃者グループとの相関図も併せて配布(※63)しています。これはSVGと呼ばれる画像フォーマットになっています。SVGは、画像でありながら実際にはXML形式でもあるため、こ れを解析することでC&Cサーバなど、今回開示した情報をすべて取り出すことができます。そのため、このデータを利用して出口対策などが可能になります。

標的型攻撃を受けた各組織が、もっと広く詳細に情報を開示し合うことが標的型攻撃の対策につながります。IIJではこの様な解析や調査活動を継続し、積極的に情報を開示することによって、標的型攻撃の対策に向けた活動を行っていきます。

1.4.2 DrDoS攻撃とその対策

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攻撃の仕組み

DrDoS攻撃はその名のとおり、ある通信の応答(反射)を悪用した攻撃です。DNSやNTPなど、UDPのサービスが悪用されることが多いですが、これはUDPがコネクションレスのプロトコルであることに起因しており、攻撃の容易さに繋がっています。攻撃は踏み台となった脆弱な機器のIPアドレスからの攻撃に見えるため、被害者からは本当の攻撃者が分かりません。このため、攻撃元からの通信を遮断するなどの対処を行ったとしても、新たな踏み台を見つけて攻撃が継続できることから、被害者側での対策が攻撃の根本対処にはつながらない場合もあります。

更に、攻撃先を直接攻撃する場合に比べ、DrDoS攻撃では、問い合わせに対する応答のデータ量が多いことを利用して、その攻撃規模を数倍から数十倍に増幅させます。例えば、DNSの場合では理論上の増幅率は70倍まで増幅される可能性があります(※71)。今回問題となった、NTPのmonlist機能を悪用した攻撃の場合、1つの問い合わせに対し、理論上の最大値で返答した場合、約200倍のデータが送られることになります。このように、NTPの場合には増幅率が非常に高いことが分かります(※72)。DrDoS攻撃では、これにより、攻撃先の回線容量を超える通信量を発生させています。

NTPによるDrDoS攻撃とその影響

今回、問題となったNTPのmonlistによるDrDoS攻撃の可能性については、NTPの実装に関する開発者のコミュニティで2010年に指摘されており、同年5月には修正が行われていました(※73)。しかしながら、この修正はDevelopment(開発版)のみに反映され、Stable(安定版)は4.2.6p5のまま、本修正は反映されていませんでした。このため、一部のntpdの実装を使っていたルータなどの機器やUNIX系OSでは、この修正が反映されていませんでした(※74)

図-16 DrDoS攻撃の概要(NTPの場合)

図-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アドレスであったことなどから、攻撃と探査活動の両方が行われていたと考えられます。

図-17 ハニーポットに到着したNTP(123/UDP)の通信

DrDoS攻撃への対処

DrDoS攻撃では、IPアドレスを詐称することで比較的容易に攻撃が行えるため、悪用できる脆弱性や新たな攻撃手法が公表されると、すぐに悪用の試みが行われる傾向があります。DrDoS攻撃の発生情報に注意し、自分の管理するシステムが攻撃に悪用される可能性について検討し、対処する努力が必要です。

また、今回の事件では、NTPが問題となりましたが、DrDoS攻撃に利用されるプロトコルはNTPだけではなく、DNSやSNMP、ECHO、Chargenなども悪用される可能性があります。サーバやルータなどの機器をインターネットに接続する場合には、まず、機器の脆弱性情報に注意し、ファームウェアなどについてセキュリティの問題のないバージョンを利用することが必要です。更に、機器において初期状態から動作しているサービスについて、利用者が認識していない状況で、踏み台として悪用されてしまうような場合も見受けられます。このような状況にならないために、機器の導入時には不要なサービスを停止し、適切にアクセス制御を設定します。導入後においても、動作するサービスについてインターネット側から継続的に調査することで、設定ミスを早期に発見することができ、外部から第三者に悪用される可能性を減らすことができます。

また、DrDoS攻撃では、送信元を詐称して攻撃を行うため、適切な通信制御を行うことでその影響を低減することができます。例えば、送信元検証(Source Address Validation)(※76)のような、詐称した通信がネットワークに流 入することを防ぐ技術を利用することで、このような送信元のIPアドレスを詐称した攻撃を防ぐことが可能となります。

更に、ISPのネットワーク網において、これを遮断することについて、総務省の研究会などで検討されています。この議論については、「1.4.3 電気通信事業におけるサイバー攻撃への適正な対処の在り方に関する研究会」も併せて参照してください。

まとめ

これまで解説したとおり、DrDoS攻撃は、攻撃の容易さに比べるとその攻撃の影響が非常に大きいことから、注意すべき脅威の1つです。一方で、攻撃としては比較的古くから知られていたものの、具体的な脅威があまりなかったことから、これまで十分な対策が行われているとはいえませんでした。今後も、同様の手法を用いた新たな攻撃が出現することが考えられます。これに備えるためにも、日頃から利用している機器の管理を適切に行う必要があります。IIJとしても、業界団体などを通じて、適切な対策に向けた活動を今後も継続して行っていきます。

1.4.3 電気通信事業におけるサイバー攻撃への適正な対処の在り方に関する研究会(※77)

ここでは2013年11月から2014年3月までの期間に実施された、総務省の研究会「電気通信事業におけるサイバー攻撃への適正な対処の在り方に関する研究会」の検討内容について解説します。この研究会は有識者や通信関連団体により構成されていますが、技術的な内容を検討するためのワーキンググループが組織され、また各関連団体においても検討の場が設けられるなど、短い期間に多くの人が関わる複数の場で、数々の議論がなされました。研究会の議事は要旨のみの公開となっていますが、ここでは公開された「第一次とりまとめ」を元に、検討のポイントについて紹介します。

5つの課題と検討

この研究会では、最近の攻撃に関連する課題として次の5つについて検討を行っています。

  • マルウェア配布サイトへのアクセス防止(※78)
  • C&Cサーバで入手した情報を元にしたマルウェア感染駆除の拡大
  • 新たなDDoS攻撃であるDNSAmp攻撃の防止
  • SMTP認証の情報を悪用した迷惑メールへの対処
  • 攻撃の未然の防止と被害拡大の防止

これらのような攻撃の多くは通信を媒介として発生します。また通信インフラ自体も攻撃にさらされることから、攻撃への対処の機能を通信の過程で実現することは、ある程度必要になることです。加えて、通信事業を行うISPにおいて攻撃に対処することで、数多く発生する被害を効果的に防ぐことも可能です。一方で、通信の過程において攻撃に対処することは、通信すべてについて情報(通信内容や、誰がいつどこに通信を行ったのかなどの外延情報も含む)を取得し、その情報を利用することで攻撃の有無やその様態を判断し、適切に攻撃の通信を止めることを意味します。これは電気通信事業法にある通信の秘密を犯す行為、つまり違法行為にあたります。

そこで、通信事業において攻撃への対処を行うために、攻撃それぞれについて、その発生の原因や影響と、取りうる対処法に関して、違法性が阻却されるかどうかを確認する必要があります。まず、通信の情報を利用した攻撃への対処は、通信の当事者である利用者が同意したうえで実施することができますが、どのように有効な同意を得るかが大きな論点となります。また、利用者の同意の有無に関わらず、攻撃への対処として行う行為が、通信事業者にとっての正当防衛、緊急避難、正当業務行為などに該当する場合も考えられます。この研究会においても、5つの課題について、これらの検討を行っています。以下にそれぞれの検討の概要を示します(※79)

マルウェア配布サイトへのアクセス防止

総務省施策ACTIVEで実施している、Web感染型マルウェアなどへの感染防止の試みのうち、通信に介在する装置などを用いて、すべての利用者に包括的に実施するURLフィルタリングの可能性について検討されています。利用者の通信に関わる情報を利用した対策については、将来契約者の不利益に繋がる可能性のあることから、従来は個別同意が必要とされていました。この課題の検討では、約款に基づく包括同意において、

  • 利用者が契約約款に同意したあとでも同意内容を変更できる(設定変更できる)こと
  • 同意内容の変更の有無に関わらず、その他通信サービスの提供条件が変わらないこと
  • 必要最小限の通信の秘密の検知で実施すること
  • 注意喚起画面などを表示すると共に、同意内容を変更できることとその方法を説明すること

などの条件を満たす場合については、有効な同意と見なすことができるとしています。また、併せて契約約款に記載すべき事項や注意喚起画面の例を示しています。

C&Cサーバで入手した情報を元にしたマルウェア感染駆除の拡大

マルウェア対策を行う様々な組織の活動の結果、マルウェアを制御するサーバが差し押さえられる場合が増えてきています。そのサーバに蓄えられた情報を元に、感染に気づいていない利用者を特定し、感染の事実や駆除の方法を伝える注意喚起を実施することが検討されました。この場合においては、C&Cサーバに蓄積された通信に関わる情報のうち、接続元のIPアドレスやタイムスタンプを元に、ISPにおいて顧客情報を検索し、利用者を特定することが通信の秘密(外縁情報)の侵害にあたります。この検討では、C&CサーバにIPアドレスなどの記録が残っている端末は、実際に当該サーバを利用するマルウェアに感染しており、そのマルウェアによる被害を受けるとしたうえで、C&Cサーバに残った記録を用いた対処方法について議論しています。結果として、当該IPアドレスから特定した利用者の情報を、注意喚起以外の用途で利用しない場合には、緊急避難として違法性が阻却されるとしています。

新たなDDoS攻撃であるDNSAmp攻撃の防止

設定の緩いDNSリゾルバを踏み台とし、大きな通信量をともなうDDoS攻撃(DNSAmp攻撃)が、2013年に多く発生しました。DNSAmp攻撃は、攻撃者からDNSリゾルバに向かう通信、DNSリゾルバからISPのDNSサーバに向かう通信、インターネット上のサーバからの増幅された応答といった、複数の通信により構成されます。ここでは、それぞれの通信の状況や、その通信で対処を行うことによる効果について議論を行った上で、攻撃者から踏み台になるDNSリゾルバに向かった、増幅を誘発するための通信をブロックする対処について検討しています。また、通常の状況では利用者が特定できない、動的IPアドレスの範囲に多数のDNSリゾルバが存在するために、包括的にブロックを行う必要がある状況を想定しています。

この検討では、動的IPアドレスの空間に対するDNSのクエリの通信をブロックすることについて、宛先のIPアドレス及びポート番号を確認した結果がDNSAmp攻撃の防止以外の用途で利用しない場合に、正当業務行為として違法性が阻却されるとしています。

SMTP認証の情報を悪用したスパムメールへの対処

迷惑メール送信対策として広く利用されているSMTP認証ですが、最近は利用者によるパスワードの使いまわしなどに起因して、リスト型攻撃などの不正アクセスの対象となり、第三者にメール送信機能を悪用される場合が発生しています。ここでは、この課題への対策として、

  • 接続元が瞬時に外国に移動するなど、SMTP認証のID・パスワードの不正利用の蓋然性が高いものへの対策。一時的に利用停止すると共に、利用者にパスワード変更を依頼する。
  • SMTP認証の接続の過程において、特定のIDに対して多くのパスワードを試すような辞書攻撃により、ID・パスワードを盗み取ろうとする試みの防止。特定のIPアドレスからの通信で発生する大量のSMTP認証失敗の検出と、そのIPアドレスからのSMTP認証を一時的に停止する。

の2つについて検討しています。いずれの場合も、サーバに対する通信状況に関する情報を元に判断し、一時的に通信を行わせなくする行為ですが、利用者によるパスワード変更などで不正利用が解消するまでの期間、もしくは攻撃が継続する期間に限って行う場合には、正当業務行為として違法性が阻却されるとしています。

サイバー攻撃の未然の防止と被害の拡大防止

この課題としては、システムの脆弱性を悪用する内容を含む通信を検出し、通信先に届けないことで攻撃を未然に防ぐ対策と、同時多発的なDDoS攻撃や国内のISPの利用者同士が攻撃をしあっている状況などに対する、ISP間の連携による対策について検討が行われました。しかし、前者は通信内容を直接判断する行為であり、また脆弱性を保有するシステムに依存する問題でもあること、後者は検討の前に連携が必要となる場面に関する整理が必要であることから、この一次取りまとめでは今後更に検討を進める必要があるとしています。

以上のように、この研究会では設定した5つの課題に関する検討を実施し、特に、いくつかの対策について、約款に基づく包括同意をもって利用者による有効な同意と解釈することや、従来攻撃の発生後に正当防衛や緊急避難として許容されてきた攻撃への直接的な対策について、正当業務行為として認められる検討結果を得ています。これらの結果は、今後ISPにおける攻撃対策を検討する上で、大きな影響を及ぼす成果であると考えることができます。

今後の活動

インターネット上の攻撃の状況は日々変化しており、今回具体的に検討された範囲においても、例えばNTPサーバを踏み台としたDDoS攻撃の発生については、その発生の事実を認識していることを言及するのみにとどまっています。このことからも研究会自体は今後も継続し、新しい攻撃とその対策について検討を進めるべきだと考えます。

また、今回検討された課題についても、ISPなどの通信事業者において実際に適用する場面では、より詳しく指針を示す必要があります。例えば、C&Cサーバをテイクダウンした場合において、どのような組織からの情報を信用して良いのか検討を要します。また、SMTP認証に関わる通信の異常についても、可能な限り多くの利用者や事業者が納得できる定量的な基準づくりを試みる必要があります。

このため、この研究会の検討結果を通信事業の実務上の状況に適用させるためのガイドラインづくりを、インターネットの安定的運用に関する協議会などの場で進めていきます(※80)

  • (※50)Black Hat(https://www.blackhat.com/blank)は米国、ヨーロッパ、アジアの主に3地域で毎年開催されている世界最大規模のITセキュリティのカンファレンス。IIJでは今回アジア地域で行われたBlack Hat Asia 2014にて講演を行った。
  • (※51)PlugXはIIR vol.21(http://www.iij.ad.jp/dev/report/iir/021.htmlblank)で詳しく解析している。
  • (※52)Remote Administration Toolの略で、主にホストを遠隔から操作するためのマルウェアの一種。標的型攻撃ではこの種のマルウェアを起点に攻撃が行われることから、IIJでもこのマルウェアに注目して解析を行っている。専門家によってはRemote Access ToolやRemote Access Trojanの略であると定義する場合もある。
  • (※53)IIJ Security Diary「新型PlugXの出現((https://sect.iij.ad.jp/d/2013/11/197093.htmlblank)」。Type IIやType IIIの亜種についてそれぞれ触れている。
  • (※54)「SK Hack by an Advanced Persistent Threat(https://www.commandfive.com/papers/C5_APT_SKHack.pdfPDF)」によると、2011年の攻撃で、Destory RATと呼ばれるRATが使用されていることが報告されている。これはPlugX Type IIIとほぼ同一であることをIIJでは確認している。
  • (※55)Immunity DebuggerはImmunity社が提供しているWindows用のデバッガ(https://www.immunityinc.com/products-immdbg.shtmlblank。OllyDbgを基に作成されており、Python拡張が特徴の1つ。プラグインやスクリプトをPythonで記述できる。
  • (※56)IDA PythonはHex-Rays社が提供する逆アセンブラ、デバッガであるIDA Pro(https://www.hex-rays.com/products/ida/blankで処理を自動化するためのPython拡張。
  • (※57)PlugXのデモバージョンに関する詳細は次のサイトが詳しい「An Analysis of PlugX(http://lastline.com/labs/plugxblank)」。デモバージョンの場合、設定情報は文字列 "XXXX"でパディングされることが多いため、情報を抽出することはできない。ただし、一部の検体ではデモバージョンのフラグが立っているにも関わらず、設定情報を持ち、パディングがされない検体が存在することも確認している。そのような検体は解析対象に含めている。
  • (※58)サービス名でグルーピングする際「SxS」、「XXX」、「TVT」といった、デフォルト値はグルーピングのキーから除いた。一方、サービス名で同一グループとして分類された検体の多くは、その検体間でC&Cサーバの情報が一致するか、類似性が見られた。このことからも、一定の時期もしくは攻撃者ごとに独自のサービス名をつけている可能性が高いと考えられる。
  • (※59)FQDNを名前解決したものも含む。
  • (※60)PlugXの検体の多くは現在も開発が頻繁に行われている。そのためかデバッグを有効にしてコンパイルされている検体が多く存在する。PlugXで何らかの処理中にエラーが発生した場合、そのエラーの内容と共に、どのバージョンで不具合が発生したかを示すバージョン情報や中国語圏の文字列を含むパス情報を併せてログとして記録するルーチンが存在する。このパス情報の文字列は数多くのパターンが存在するため、この情報も同一攻撃主体を示すものの1つとして利用できると考えられる。次のWebサイトでは、多くのデバッグ文字列例が紹介されている。「CASSIDIAN CyberSecurity Blog PlugX: some uncovered points(http://blog.cassidiancybersecurity.com/post/2014/01/plugx-some-uncovered-points.html?2014/01/plugx-some-uncovered-points.htmlblank)」。
  • (※61)APT1はMandiant社が報告した標的型攻撃を行うグループの1つ(http://intelreport.mandiant.com/blank)。
  • (※62)WinntiはKaspersky Lab社が報告した、ゲーム業界を標的とする標的型攻撃(https://www.securelist.com/en/downloads/vlpdfs/winnti-more-than-just-agame-130410.pdfPDF)。
  • (※63)今回の講演資料、抽出スクリプト及び相関図はBlack Hatのアーカイブサイトから入手できる(https://www.blackhat.com/asia-14/archives.html#Haruyamalblank)。スクリプトは更新版を以下でも配布している(http://takahiroharuyama.github.io/blog/2014/03/27/id-slash-idapython-scripts-extracting-plugx-configs/blank)。
  • (※64)DNSオープンリゾルバ問題については、本レポートのVol.21「2. インターネットオペレーション DNS オープンリゾルバ問題 」も参照のこと、(http://www.iij.ad.jp/dev/report/iir/pdf/iir_vol21.pdfPDF)。
  • (※65)リトアニアの研究教育機関のネットワークであるLITNETのCERTチームの報告で確認できる。LITNET CERT、"NTP DoS reflection attacks"(https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacksblank)。
  • (※66)Symantec Cyber Readiness & Response Blog、"Hackers Spend Christmas Break Launching Large Scale NTP-Reflection Attacks"http://www.symantec.com/connect/blogs/hackers-spend-christmas-break-launching-large-scale-ntp-reflection-attacksblank)。
  • (※67)JVN、「JVNVU#96176042 NTP が DDoS 攻撃の踏み台として使用される問題」(https://jvn.jp/vu/JVNVU96176042/index.htmlblank)。
  • (※68)Staminus Communications、"Mitigating 80 Gbps Attacks – NTP Amplification Attacks on the Rise" (https://blog.staminus.net/mitigating-80-gbps-attacks-ntp-amplification-attacks-on-the-riseblank)。
  • (※69)CloudFlare、"Technical Details Behind a 400Gbps NTP Amplification DDoS Attack" (http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attackblank)。
  • (※70)ArborNetworks、"NTP attacks continue – a quick look at traffic over the past few months"(http://www.arbornetworks.com/asert/2014/03/ntp-attacks-continue-a-quick-look-at-traffic-over-the-past-few-months/blank)。
  • (※71)実際にはキャッシュDNSサーバの設定などにより増幅率が律速されるため、最大で8倍から40倍程度となる。
  • (※72)攻撃に使われるプロトコルの増幅率については、CERT/CCのアドバイザリでも注意喚起が行われている。"Alert (TA14-017A) UDP-based Amplification Attacks"(https://www.us-cert.gov/ncas/alerts/TA14-017Ablank)。
  • (※73)4.2.7p26以前のntpdが本脆弱性の影響を受ける。修正については次のntp.orgのBugレポートなども参照のこと。"Bug 1532 - remove ntpd support for ntpdc'smonlist (use ntpq's mrulist)" (http://bugs.ntp.org/show_bug.cgi?id=1532blank)。
  • (※74)例えば、FreeBSDなどが該当している。The FreeBSD Project、"ntpd distributed reflection Denial of Service vulnerability"(http://www.freebsd.org/security/advisories/FreeBSD-SA-14:02.ntpd.ascblank)。
  • (※75)CERT/CC、"Vulnerability Note VU#348126 NTP can be abused to amplify denial-of-service attack traffic"(http://www.kb.cert.org/vuls/id/348126blank)。
  • (※76)送信元検証については次の弊社解説も参照のこと。「送信元検証『Source Address Validation』」(http://www.iij.ad.jp/dev/tech/activities/sav/blank)。
  • (※77)総務省、「電気通信事業におけるサイバー攻撃への適正な対処の在り方に関する研究会」(http://www.soumu.go.jp/main_sosiki/kenkyu/denki_cyber/index.htmlblank)。
  • (※78)マルウェア配布サイトへのアクセスを未然に防止する等の実証実験を行う官民連携プロジェクト、ACTIVEの普及展開策の一つとして検討された。ACTIVE(AdvancedCyber Threats response InitiatiVE)、「ACTIVE について」(http://www.active.go.jp/active/index.htmlblank)。総務省、「「ACTIVE」の実施及び「ACTIVE推進フォーラム」の開催」(http://www.soumu.go.jp/menu_news/s-news/01ryutsu03_02000059.htmlblank)。
  • (※79)この研究会における事例の検討は、多くの条件を設定したもとでの法解釈の検討であり、正確な検討内容については研究会の一次とりまとめを参照のこと。
  • (※80)インターネットの安定的運用に関する協議会は、通信関連団体である社団法人電気通信事業者協会、社団法人テレコムサービス協会、社団法人日本インターネットプロバイダー協会、社団法人日本ケーブルテレビ連盟、財団法人日本データ通信協会テレコム・アイザック推進会議による協議会で、「電気通信事業者における大量通信等への対処と通信の秘密に関するガイドライン」の策定を行っている。JAIPA、「電気通信事業者における大量通信等への対処と通信の秘密に関するガイドラインの改定について」(http://www.jaipa.or.jp/topics/?p=400blank)。
1.インフラストラクチャセキュリティ

ページの終わりです

ページの先頭へ戻る