エフセキュアブログ

ファイルシステム を含む記事

Petya:ディスク暗号化ランサムウェア

 4月3日更新。暗号化スキームについてより詳しく追記した。


 Petyaは邪悪なひねりが加えられている新しいランサムウェアだ。ディスク上のファイルを暗号化する代わりに、ディスク全体をロックしてほとんど使い物にならない状態にする。具体的には、ファイルシステムのMFT(master file table)を暗号化する。つまりOSからファイルの位置が特定できなくなることを意味する。Petyaは、ブートキットと同様に自身をディスクのMBR(master boot record)にインストールする。ただし、秘密裏に活動するのではなく、赤い画面上にシステムを復旧する方法についての説明を表示する。

 MFTを狙うと素早く攻撃できる。データファイルを暗号化するより極めて短時間で済むのだ。それでも全体的な結果としては暗号化と同じ、すなわちデータにアクセスできなくなる。

Petya, Press Any Key!

 Petyaは2段階で実行する。第1段階はメインのドロッパーで、以下を実行する。

  • \\.\PhysicalDriveを直接操作してMBRに感染させる
  • 一連の暗号キーを生成する。これには16バイトのランダムなディスク暗号用のキーと楕円暗号(EC、Elliptic Curve)のキーペアが含まれる。この時点で、特別な「復号コード」も用意される
  • あとでMBRに感染したコードで使うため、ディスクの暗号キーと復号コードをディスクに保存する。その他の生成された暗号データはすべて破棄される
  • なんの警告もなしにマシンをシャットダウンし、MBRのコードでブートする

 Petyaは非対称キーによる暗号化と搬送のために、楕円曲線暗号スキームを用いている。192ビットの公開鍵とsecp192k1曲線パラメータは、ドロッパーのバイナリにハードコーディングされて配信される。Petyaはサーバの公開鍵を取得し、ECDH(Elliptic Curve Diffie-Hellman)アルゴリズムを用いて共有の秘密鍵を構築する。この共有秘密鍵を用いて16バイトのディスク暗号キーをAES暗号化する。共有秘密鍵はこのマルウェアとサーバしか使用できない。バイナリをASCIIにエンコーディングするBase58により、このマルウェアの楕円曲線の公開鍵といっしょにディスク暗号キーをパッケージする。ここで得られるパッケージが、後に赤いスクリーン上で提示される「復号コード」である。

Petya physdrive
PetyaドロッパーによるPhysicaldriveの操作

Petya server pubkey
ドロッパー内部にあるPetyaサーバの楕円曲線暗号の公開鍵

Petya ecc params
ドロッパー内部にあるPetyaのsecp192k1の曲線パラメータ

Petya encode pubkey
ASCIIエンコーディングのPetyaドロッパーの楕円曲線暗号の公開鍵

Petya gen salsa20 key
Petyaドロッパーのsalsa20バイト列の生成

 感染後、マシンはMBRのコードでブートする。これは以下のようになる。

  • まずディスクが感染しているかを確認する
  • 感染していなければ偽のCHKDSK画面を表示し、暗号キーに共有秘密キーを用いてMFTを暗号化する
  • ディスクの暗号化にsalsa20を用いる。暗号化後は当該キーを破棄する
  • 赤い「スカルスクリーン」、続いてTorの隠しサービスのURLがある画面と「復号コード」を表示する。「復号コード」とは、サーバでしか開けない暗号化されたメッセージである
Petya debug environment
Petyaが環境を取り戻すところ

petya_disk_encryption
salsa20でディスクを暗号化する際の、偽の「CHKDSK」に関するMBRのコード

Petya salsa20 expand32
MBRに置かれるsalsa20のコード

 楕円曲線アルゴリズムを用いて暗号キーを復号できるのは、もはやサーバしかない。これはマルウェアによってキーが破棄されたためだ。また、たとえ破棄されていなかったとしても、マシンがロックされて使えないままだ。リカバリディスクでMBRを復旧したとしても役には立たないだろう。なぜならMFTがいまだ暗号化されているからだ。理論上は共有秘密鍵を復旧して、リカバリディスクでディスク暗号化キーを復号して戻すことは可能だ。しかしそのためには、元々の楕円曲線暗号のキーペアを入手しなければならないのだが、必要な楕円曲線のデータはすべてドロッパーが破棄してしまっている。これはまるで家に入るための鍵が2つあって、意図的に片方を無くしたようなものだ。

 サーバ側では、復号コードのデコードが逆の順番で行われることが想定される。

  • Base58で符号化されたバイナリデータをデコードする
  • マルウェアの公開鍵と暗号化されたデータを展開する
  • 公開鍵を用いて、共有秘密鍵を構築する
  • この共有秘密鍵を用いると、サーバはAESを使ってディスク暗号化キーを復号できる
  • ここで攻撃者は、ロックされたマシンを解放できる暗号化キーを元に戻すことができる

 一例として、当社のラボのマシン上の復号コードの1つは次のように見える(ハイフンと先頭の2文字は削除。サーバはこれをデコードに使用しない)。

Q5rL1YMqnJPCsCgji4KcDv5XnQrtqttBQ7tfbAq7QStmTXNQ6Voepeaiem8uzaQxYq3LwpvMCXBvMx2Mmqkdt8Fi

 このコードを標準のBase58アルゴリズムを用いてデコードすると、以下のデータが生成される(説明のために、マルウェアが生成する公開鍵を緑で、ディスクを暗号化するキーを赤で示す)。

Petya decryption code opened

 サーバのヘルプ無しでマシンを復旧する唯一の方法は、デバッガを使って感染プロセスの途中でsalsa20のキーを捕捉することだ。これは通常のコンピュータユーザにとっては、あまり魅力的な対抗手段ではない:)

トリビア:

諜報ツールキットRegin

 Reginは一連の洗練された諜報ツールキットの中で最新のもので、世界中の広範な組織を標的に使用されている。既報の通り、活動中のマルウェア群でさらに複雑なものの1つで、他の数多くのツールキットとまったく同様に背後には長い歴史がある。我々は約6年前の2009年の初頭に初めてReginと遭遇した。北ヨーロッパの顧客の環境にあるWindowsサーバ上にそれが隠れているのを見つけた。

 そのサーバはたびたびクラッシュし、悪名高いブルースクリーンになっており、トラブルの兆候を示していた。「pciclass.sys」という、当たり障りのない名前を持つドライバがクラッシュを引き起こしているように見受けられた。より詳細な分析を行うと、当該ドライバは実はルートキットであった。もっと厳密に言うとReginの初期のバリアントの1つだった。

Regin File Header

 上のスクリーンショットで認められるとおり、このドライバは明らかに既に2008年3月7日にはコンパイルされているが、それより早いタイムスタンプのある他のサンプルによって、作戦はさらにこれよりも前であることが示唆されている。

 結局のところ、複数の段階がある脅威における1つのコンポーネントに過ぎないことが分かった。このドライバはレジストリキーかNTFSファイルシステムの拡張アトリビュートを使って、次の段階のマルウェアを読み込める。ドライバに埋め込まれた設定が、このことを示している。

Regin config

 我々は少なくとも以下のレジストリキーが、次の段階のペイロード用に使用されているのを目にした。

  •  \REGISTRY\Machine\System\CurrentControlSet\Control\Class\{9B9A8ADB-8864-4BC4-8AD5-B17DFDBB9F58}:Class
  •  \REGISTRY\Machine\System\CurrentControlSet\Control\Class\{4F20E605-9452-4787-B793-D0204917CA58}:Class
  •  \REGISTRY\Machine\System\CurrentControlSet\Control\RestoreList:VideoBase

 以下のフォルダには名前に「_」が付いたNTFS拡張アトリビュートが格納されており、また次の段階のペイロードも格納されているのが見られた。これは実際には2つの異なるアトリビュートに分割され得る。

  •  %WINDIR%
  •  %WINDIR%\security
  •  %WINDIR%\repair
  •  %WINDIR%\msapps
  •  %WINDIR%\msagent
  •  %WINDIR%\Cursors
  •  %WINDIR%\fonts
  •  %WINDIR%\Temp
  •  %WINDIR%\msagent\chars
  •  %WINDIR%\Help
  •  %WINDIR%\inf
  •  %WINDIR%\Spool\Printers
  •  %WINDIR%\CertSrv

 2013年および2014年の間、我々はより新しいバージョンのReginを分析してきたので、攻撃における複雑さと洗練度合が非常に明確になってきた。我々はReginを、Stuxnetや、Flame、Turla/Snakeのようなものと共に、高度に洗練された諜報作戦という同一のカテゴリに配する。

 いつもながら、このような事案で出所を特定するのは難しい。我々の感じるところでは、このマルウェアは珍しくロシアや中国から来たものではない。

Mayhemに首を突っ込む

 ここ1年で、Linuxサーバを標的にしたマルウェアが大きなニュースとなることが増えてきた。本記事では、LinuxとFreeBSDのサーバを標的とした、高度かつ多目的なあるマルウェアの動作について、調査報告を行う。当社ではこの動作の核となるマルウェアファミリーをGalacticMayhemと命名した。この名前は一部のC&CサーバのURLをもとにしている。Yandexの研究者チームによって報告されたものと同じマルウェアファミリーである。

概要

 サーバへのMayhemの感染は、PHPのドロッパースクリプトから始まる。このスクリプトの役割は、悪意のあるELF共有オブジェクトファイルをドロップし実行することだ。ドロップされたバイナリの名前の多くはlibworker.soだ。しかし我々の調査では、当該バイナリがatom-aggregator.soまたはrss-aggr.soとなっているような該当しないケースもあった。ドロッパースクリプトは常に32ビットと64ビットの両バージョンのマルウェアを含む。この2つは同一の機能と設定を持つ。

 ドロッパースクリプトはまず、実行中の/usr/bin/hostプロセスをすべてkillする。続いてホストが32ビットか64ビットか、またLinuxかFreeBSDかを判定する。スクリプトはさらにホストのアーキテクチャに合ったバイナリを選び、OSを考慮してELFヘッダを調整し、最後にバイナリをディスクに書き込む。ドロッパーはまた、1.shという名前のシェルスクリプトもディスクに書き込む。このシェルスクリプトは、クリーンアップおよびマルウェアを実行する役割を持っている。マルウェアの実行は、いわゆる「LD_PRELOAD」テクニックを使って実現する。ドロップされたバイナリへのパスを環境変数「LD_PRELOAD」に設定するのだ。次に、実行ファイル/usr/bin/hostを実行する。最終的に/usr/bin/hostによって呼び出されるexitファンクションをフックすることで、OSのローダーは悪意のあるバイナリをロードするようになっている。/usr/bin/hostがいったんexitを呼び出すと、実行が悪意のあるバイナリへと移る。

 我々の調査では、これまでのところ47通りの異なるMayhemのサンプルが明らかになった。こうしたサンプル群のうち最初期のものは少なくとも半年は前のもので、最新のものは1週間以内の可能性がある。サンプルの分析から、Mayhemは開発の最中に3段階の主要なイテレーションを経てきたことは明らかだ。イテレーションごとにマルウェアは次第に複雑さと洗練度を増してきた。加えて、より細かいインクリメンタルな更新が観測されている。これはマルウェアファミリーMayhemが活発に開発中であることを示す。以降の記事では、Mayhemの最新かつもっとも機能が豊富なイテレーションに焦点を合わせる。

 マルウェアMayhemは、高度にモジュール化した設計になっている。Mayhemは1つのメインコンポーネントと複数の任意に読み込まれるモジュールから構成される。メインコンポーネントは、モジュールのロードおよびアンロードや実行はもちろん、C&Cサーバとの通信も担っている。また、モジュール自身やモジュールが使用する他のファイルを格納するために、暗号化した隠しファイルシステムを用いている。このファイルシステムはディスク上に保存される。マルウェアの設定データの1つがそのファイル名を指定している。大半のケースではファイルの名前は.sd0となっている。しかしながら、当社が最近観測したところでは、マルウェアの作者はファイル名を.cachesに変更している。おそらく、隠しファイルシステムのファイル名が複数の情報源により公表され、感染したシステムを検索するために利用されるようになったことに対応したのだろう。重ねて言うが、当該マルウェアが活発に開発中なのは明らかだ。注目すべきは、隠しファイルシステムのファイルサイズもマルウェアの設定データで指定されており、我々が観測したすべてのケースでちょうど12MBになっている点だ。

 マルウェアMayhemは、特別に作られたHTTP postリクエストを用いてC&Cサーバと通信する。このリクエストのヘッダは非常に独特で、「Host」「Pragma」「Content-Length」という特定の3つのフィールドしか含まれていない。この中の「Pragma」フィールドの値は常に「1337」である。加えて、HTTPのバージョンは常に1.0を指定している。マルウェアからC&Cサーバへのリクエストの例を以下に挙げる。

Packet capture of malware communicating with C&C

 以上のように、実際のリクエストのボディは、コマンドやメッセージを指定する1行以上の行から構成される。これらの行は常にメッセージの種別を示す単一の文字で始まっており、カンマ区切りのパラメータのリストが続く。メッセージの種別により、ファイルの送受信、ジョブの開始や終了、モジュールのロードや更新、C&Cサーバへのマルウェアの状況の通知といったことを可能にする。

 感染と設定が終わると、マルウェアは設定データ内にハードコーディングされているC&Cサーバに対し、リクエストを送信しようと試みる。このリクエストには、マルウェアが動作しているホストのシステムや環境についての情報が含まれている。マルウェアはC&Cサーバから条件を満たすリプライをひとたび受け取ると、現在のステータスを報告するC&Cサーバに対し、定期的にリクエストを送信するように戻る。もしそのC&Cサーバが現在これといったアクティビティに参加していない場合、スリープして後でpingするような指示をマルウェアに応答する。

 C&Cサーバは、新たなジョブをマルウェアに応答することもある。今回のケースでは、C&Cサーバは最初にマルウェアに対しロードするモジュールを指示する。同様に、ロードするモジュールのためのルールファイルやパスワードリストのような、追加のファイルも任意に指示する。この場合、マルウェアはまずは隠しファイルシステムを検索して、指定されたモジュールを探す。見つかったら、モジュールのCRC-32チェックサムをC&Cサーバに返す。次にC&Cサーバは、見つかったモジュールが最新版かどうか、あるいはマルウェアはC&Cサーバ上の新たなバージョンを要求すべきなのかをマルウェアに通知する。見つかったモジュールが古いバージョンであったり、モジュールが見つからなかった場合、マルウェアはC&Cサーバにモジュールを要求する。モジュールはHTTPレスポンス中にbase64エンコードされたデータとして返される。

 モジュールを取得したら、マルウェアのメインコンポーネントはモジュールを読み込み、エントリーポイントファンクションを呼び出す。このエントリーポイントファンクションはさらに設定を行い、おそらく隠しファイルシステムやC&Cサーバにある追加のファイルを要求する。また、このファンクションは特定の状況下でメインコンポーネントによって呼び出される1~4つのコールバックファンクションを登録する。これこそ、モジュールの主機能が実行される仕組みだ。

 モジュールの読み込みが成功した後、C&Cサーバはメインコンポーネントに対し新たなジョブを開始するように指示することがある。このジョブの結果、メインコンポーネントはオペレーターが指定した数のスレッドを作成する。各スレッドは、それぞれ読み込まれたモジュールの機能を実行する。最後にC&Cサーバはマルウェアに対し、実行するモジュールへの引数になる文字列を送信し始める。こうした引数の文字列の内容はロードしたモジュールによって異なるが、通常は少なくとも悪意のあるアクティビティの標的となるドメインやURLが含まれる。

モジュール群

 当社の研究の最中に、現実の環境で、マルウェアMayhemによって使用される11個の異なるモジュールに遭遇した。これらの大半において、複数の異なるバージョンを観測した。これは明らかに、モジュールもまた活発に開発中であることを示している。

 遭遇したモジュールは以下の通り。


  • bruteforce.so - WordPressとJoomlaのサイトのログイン情報を総当たりで見つけるために使用する
  • bruteforceng.so - 上と同様だが、HTTPSと正規表現をサポートしており、高度な設定ができる
  • cmsurls.so - WordPressのログインページを特定するために使用する
  • crawler.so - WordPressとJoomlaのサイトを見つけるためWebサイトをクロールするのに使用する
  • crawlerng.so - 上記の改良バージョン。HTTPSと正規表現をサポートし、任意の正規表現にマッチするWebページを発見できる
  • crawlerip.so - 上記と同様だが、ドメインの代わりに標的のIPアドレスリストを受け取る
  • ftpbrute.so - FTPサーバのログイン情報を総当たりで見つけるために使用する
  • rfiscan.so - RFIの脆弱性を持つWebサイトの検索に使用する
  • wpenum.so - WordPressのサイトのユーザを列挙するために使用する
  • opendns.so - 公開されている再帰的なDNSリゾルバを検索するために使用する
  • heartbleed.so - Heartbleedという脆弱性(CVE-2014-0160)を露呈しているサーバを特定するために使用する


 このポストでは個々のモジュールについて非常に詳細なところまで掘り下げることはしないが、分かったことのうち興味深いものを一部挙げる。

bruteforce.so

 bruteforce.soモジュールは、現在飛び抜けて活発に使用されているモジュールである(これについては後ほど詳細に述べる)。機能面では非常にシンプルだ。WordPressまたはJoomlaのサイトのログインページを指し示す標的となるURL、ユーザ名を並べたファイル、パスワードを並べたファイルを取得する。続いて、ユーザ名とパスワードの可能な組み合わせをすべて用いてログインを試みる。

bruteforceng.so

 このモジュールはbruteforce.soモジュールの進化したバージョンで、HTTPSと正規表現のサポートが加えられている。入力として、標的のURL、ユーザ名のファイル、パスワードのファイルを取得するのに加えて、ルールファイルも必要とする。ルールファイルは、標的のログインインターフェイスを指定するために使われる。したがって、このモジュールを使用すれば、どのWebベースのインターフェイスのログイン情報でも総当たりで見つけることができる。このモジュールは主にWordPressとJoomlaのサイトのログイン情報を総当たりするために使われているのを我々は観測してきた。しかし、たとえばcPanel Web Host Managerのサイトなど、他の種類のサイトに対しても使われていると信じるに足る理由がある。

 興味深いことには、bruteforce.soおよびbruteforceng.soの両モジュールの新バージョンを最近になって我々は発見した。古いバージョンでは、ユーザ名のファイル内の全ユーザ名をすべての標的に対して試していたが、新しいバージョンでは使用すべき1つのユーザ名をC&Cサーバが指定できるようになっている。C&Cサーバが標的のURLを指定するために使うコマンドの文字列は、「Q,target」(targetはURL)である。しかし新しいバージョンのコマンドは、「Q,target;username」という、より長いコマンド文字列をサポートしている。セミコロンと別のパラメータが追加されたことに注意してほしい。この追加されたパラメータはユーザ名を1つ指定でき、パスワードファイル内にあるすべてのパスワードと結びつけられる。しかしながら、ユーザ名の文字列が「no_matches」だったり、2番目のパラメータが指定されていない場合には、モジュールは独立したユーザ名のファイル内の全パスワードを試すという古い方法へフォールバックする。

crawlerng.so

 crawlerng.soはWebサイトをクロールするのに使われるモジュールだ。引数として、正規表現を含むファイルを取る。次に当該モジュールは、こうした正規表現にマッチするコンテンツを求めて、標的のドメインを検索する。これは主に、WordPressおよびJoomlaのログインページを特定するために使われているようだ。ただ、正規表現で指定するということから、モジュールは本質的に任意の種類のページを特定するように指示できる。例として、当社はPhpMyAdmin、DirectAdmin、Drupalのログインページを特定するために使われるcrawlerng.soモジュールを観測した。一部のケースでは、モジュールは特定のキーワード、たとえば薬局に関連するキーワードにマッチするコンテンツを提供するWebサイトを見つけるために使われていた。我々が観測したケースでは、マルウェアのオペレーターが工夫をこらし、crawlerng.soモジュールでローカルファイルインクルードの脆弱性を探すものさえあった。観測したルールセットでもっとも多かったのは、別のHTTP、HTTPS、FTPサイトへ移動するリンクも検索するようにモジュールに指示するものだ。このやり方で、モジュールが新しい標的を見つけてクロールを続けるようになる。

Screencapture of LFI rule file
ローカルファイルインクルードの脆弱性を探すために使われるルールの一部

opendns.so

 このモジュールは、DNS amp攻撃で使われ得る、公開されている再帰的なDNSリゾルバを検索するために使用される。引数としてIPアドレスレンジと、サイズのしきい値を取る。レンジ内の全IPを1つずつ繰り返し、53番ポートへの接続を試みる。53番ポートへの接続が成功すると、拡張的なDNSの「DNSSEC OK」ビットをセットして、「ripe.net」ドメインのANYレコードを問い合わせる再帰的なDNSリクエストを送信する。標的がオープンかつ再帰的なDNSリゾルバを起動していたら、大きなDNSの応答を返すことになる。リプライのサイズが、事前にセットしたサイズのしきい値と比較して大きかったら、C&CサーバにIPアドレスが報告される。

Packet capture of the DNS request
当該モジュールによって送信されるDNSリクエストのパケットキャプチャ

heartbleed.so

 このモジュールは標的のドメインがHeartbleed脆弱性に対して脆弱かどうかを特定しようとする。これは標的に初めて接続するときに行なわれ、TLSv1.1のClientHelloパケットを送信し、さらにペイロードサイズが64KB(0xFFFFバイト)だが実際のペイロードは3バイトのハートビートリクエストを送る。

TLSv1.1 ClientHello packet
Malicious heartbeat request
ClientHelloパケットのペイロード(上)と悪意あるハートビートリクエスト

 最後に、サーバのリプライのペイロードのサイズが確認される。これが3バイトよりも長いなら、サーバはおそらく脆弱で、そのことがC&Cサーバに報告される。

Code that checks the server reply
サーバの応答を確認するコード

現在の活動

 当社の調査により、マルウェアファミリーMayhemによって使われているC&Cドメインが19個明らかになった。そのうち7つは現在もアクティブである。現在の活動の大半はWordPressおよびJoomlaのログイン情報を総当たりで取得することに関連している。ただ、FTPのログイン情報も総当たりで見つけることや、同様にWordPressとJoomlaのログインページを検索しながらドメインをクロールすることも観測している。我々は別のモジュールがある時点で現実に使われた証拠も持っている。

 総当たりの活動を観測したためだが、これは非常に日和見的に見える。マルウェアのオペレーターはボリュームに焦点を合わせているようだ。共通かつ脆弱な認証情報を使っているサイトが十分に存在することをあてにしている。アクティブなC&Cサーバ群から標的になったURLを1週間分記録したところ、我々は35万超のユニークな標的を特定した。このサーバ群のなかの1台のC&Cサーバが、21万を超えるユニークな標的に関与していた。これはマルウェアの単一のインスタンスに与えられる標的に過ぎず、全体的な数はおそらくずっと大きいものになることに注目すべきだ。

 標的のドメインに関する分析に基づくと、マルウェアのオペレーターは誰かあるいは何かを特別に標的としているとは思えない。むしろ、単純に低い位置にあるWebの果実を探しているだけのように感じる。以下のような、標的のドメインの地理的な分布によって、これはさらに支持される。上位10か国に中国がいないのは注目に値するが、マルウェアのオペレーター側が意図的に選定したというより、例外的なものと思う。

Piechart showing geographic distribution of target domains

結論

 マルウェアのオペレーターはMayhemを主に偵察ツールとして使い、簡単に侵害できるサーバへアクセスできるようにして、後にもっと洗練された攻撃のベースとして使えるようにしていると、当社では考えている。たとえばオペレーターは、最初にWordPressのサイトを見つけるためにcrawlerng.soモジュールを用い、続いてwpenum.soモジュールを使ってこうしたサイトから潜在的な被害者のユーザ名を列挙しているかもしれない。ユーザ名のリストを持っていれば、オペレーターはこうしたサイトへのアクセスを得ようとしてbruteforce.soモジュールに取り掛かることができる。オペレーターがアクセスできるようになれば、サイトをMayhemで感染させてボットネットを拡大したり、あるいは他の操作を組み込むために利用することもできる。

 マルウェアファミリーMayhemは、LinuxおよびFreeBSDのサーバ上で動作する、高度で非常に汎用的な脅威である。明らかに活発に開発がなされており、オペレーターは研究者やサーバ管理者の尽力を盛んに無効にしようとしている。また感染するホストが、低速のADSLの背後にあるごく普通の家庭用PCではなく、大容量、広帯域のサーバであることを考慮すると、運用の規模も重要である。

サンプルのハッシュ

 バージョン1

  • 0f1c66c3bc54c45b1d492565970d51a3c83a582d
  • 5ddebe39bdd26cf2aee202bd91d826979595784a
  • 6c17115f8a68eb89650a4defd101663cacb997a1


 バージョン2

  • 7204fff9953d95e600eaa2c15e39cda460953496
  • 772eb8512d054355d675917aed30ceb41f45fba9


 バージョン3(最新)

  • 1bc66930597a169a240deed9c07fe01d1faec0ff
  • 4f48391fc98a493906c41da40fe708f39969d7b7
  • 6405e0093e5942eed98ec6bbcee917af2b9dbc45
  • 6992ed4a10da4f4b0eae066d07e45492f355f242
  • 71c603c3dbf2b283ab2ee2ae1f95dcaf335b3fce
  • 7b89f0615970d2a43b11fd7158ee36a5df93abc8
  • 90ffb5d131f6db224f41508db04dc0de7affda88
  • 9c7472b3774e0ec60d7b5a417e753882ab566f8d
  • a17cb6bbe3c8474c10fdbe8ddfb29efe9c5942c8
  • ab8f3e01451f31796f378b9581e629d0916ac5a5
  • c0b32efc8f7e1af66086b2adfff07e8cc5dd1a62
  • c5d3ea21967bbe6892ceb7f1c3f57d59576e8ee6
  • cb7a758fe2680a6082d14c8f9d93ab8c9d6d30b0
  • e7ff524f5ae35a16dcbbc8fcf078949fcf8d45b0
  • f73981df40e732a682b2d2ccdcb92b07185a9f47
  • fa2763b3bd5592976f259baf0ddb98c722c07656
  • fd8d1519078d263cce056f16b4929d62e0da992a


 当社ではこれらをBackdoor:Linux/GalacticMayhem.Aとして検知する。

 調査執筆:Artturi Lehtio(@lehtior2

筆者注記

 筆者はフィンランドのヘルシンキにあるアールト大学の、情報科学の学生である。今春、同大で提供され、エフセキュアが運営したマルウェア分析の講義に出席した後、幸運なことに同社の夏季インターンシップに参加した。1か月前、私は新たなタスク「Linuxマルウェアについて興味深く見える事項を見つけて、それについてブログの記事を書くことをゴールとする」を与えられた。この記事とそれを裏付ける調査は、Linuxマルウェアの謎めいた世界への私の冒険の結果である。

システム破壊の本当の目的は?

韓国でのサイバー攻撃被害が話題です。ATMネットワークへの侵入方法や、その目的など不明な点があり、全容解明にはもう少し時間がかかりそうです。 特に韓国へのワイパー攻撃の歴史でも触れられた、MBR領域、ファイルシステム領域の上書き操作については非常に興味深いところです。

一見、韓国国内の混乱を狙った攻撃であるとの見方が強いようですが、本当の目的は意外なものかもしれません。そこで、このようなシステム破壊行為をする場合、その目的を3つ考えてみました。
 
(1)利用者への妨害のため(脅迫、愉快犯、テロ、etc)
(2)証拠を隠蔽したいため
(3)注目を集めたいため(注意を逸らしたいため)

今回のような大々的な事件となりますと、(1)のケースが思い浮かべてしまいます。しかし、(2)(3)のケースも想定すべきことのように思います。

実際に(2)はしばしば目にします。攻撃者が目的を達成し、自身の痕跡を消したい場合に行います。この場合はMBR領域の破壊くらいが一般的です。一見、OSの障害に見せかけ、利用者に復旧を促す際に行われることがあります。下図はMBR領域が破壊された端末から確認された攻撃者の操作痕跡です。

kill_os

この場合はこっそりと操作しないと意味がありませんので、今回の韓国のケースには当てはまらなそうですが。。。
次に(3)ですが、注目を集めたいので派手に破壊する必要がありそうです。本来の目的が目立つものであればあるほど、注意を逸らすために大きな花火を打ち上げる必要があります。
本当のところは全く分かりませんが、何となく(3)を勘ぐってしまいます。考え過ぎでしょうかね?
しばらく、韓国のニュースから目が離せませんね!

韓国のワイパー攻撃の背後にWhois?

 報道によれば、先週、韓国企業をワイパーマルウェアが襲った際に、韓国LGユープラス社のWebサイトも書き換えられていたとのことだ。

 以下はThe Registerからの引用だ。

The Register Report

 事件の関係者によれば、ワイパー攻撃の加害者として「Whois Team」に嫌疑がかけられている。ただしこれにはいまだ議論がある。

 Ars Technicaから以下を引用する。

Ars Technica Report

 我々が昨日、ワイパーのサンプル群を見て回ったところ、感染したシステム内のWebドキュメント(「.html」「.aspx」「.php」など)を検索するルーチンが含まれるバリアントを検出した。このマルウェアはこうしたドキュメントを、以下の動画とまったく同じように見えるドキュメントへ上書きする。



 このサンプルは、LGユープラス社のWebサイトの書き換えに用いられたものと明らかに関連があると考えている。

 当該サンプルには、他のワイパーのサンプルと同様のタイムスタンプがある。

 昨日の投稿にあったDLLワイパーのサンプルのタイムスタンプは次のようになっている。

DLL Wiper Timestamp

 書き換えを行ったワイパーのサンプルのタイムスタンプは以下だ。

Defacer-wiper Timestamp

 ただし、後者のバリアントではドライブの消去にまったく異なる方法を用いていた。こちらはMBR(Master Boot Record)に以下のコードを感染させ、次回起動した時にディスクを消去する。

Bootstrap Wiper

 また他のバリアントと異なり、このサンプルはファイルシステムを消去する際に「HASTATI」「PRINCIPES」といった文字列を用いていない。ファイルを「0」で上書きし、ランダムなファイル名に変更してから最終的にファイルを消去している。またWindowsとProgram Filesディレクトリ内で見つかったファイルは回避する。攻撃者は上書きしたページで感染したWebサーバを提供し続けたかったわけなので、これですべて意味が通る。

 では、攻撃同士が関連していると思われるか?関連しているというのが、もっともあり得る。これは別の攻撃メンバーによって実行されただけだ。

リバース・エンジニアリングおよびマルウェア分析についての大学の講義

 本日、フィンランドのアールト大学(Espooキャンパス)にて、リバース・エンジニアリング・マルウェア講座の、2013年春期の初めての講義が開催の運びとなる。

 この講座は、以前の講座と同様、ヘルシンキのセキュリティ研究所の研究員達が教鞭をとる。悪意のあるコードとは何か、どうすればそれを分析できるのか、WindowsとAndroidなど異なるプラットフォーム用の実行形式のコードをリバース・エンジニアリングするにはどのようにするか、について学生達に指導する。バイナリの難読化やエクスプロイトを含め、さまざまな題材について、学生達は探求することになるだろう。またこの講義では技術的なトピック以外にも、情報セキュリティに関連のある倫理的あるいは法的な問題などを取り上げる。

 当社の講座ではいつものことだが、学生達は非常に実習的な手法で学習していく。これには、当社の研究員が作成した、以下のようなリバース・エンジニアリングのパズルを解くことが含まれる。

homework

 地球の反対側のクアラルンプール(マレーシア)にも当社の別のセキュリティ研究所がある。ここでもモナシュ大学の情報技術学校(Sunwayキャンパス)の講師たちと協力して、同様の講座を立ち上げた。

monash

 Androidプラットフォームを狙ったマルウェアの分析に、もっと重点がおかれたシラバスとなっている。このようなマルウェア分析の講義が、学生に対して初めて提供される。

 この講座では、講義と実習に最新の題材を盛り込み、学生がこの分野についてより広角的な視野を持ち、マルウェア分析に必要な専門スキルを身につける一助となるようにする。講義や実習で取り上げる題材には、Androidのセキュリティ・フレームワークや、OS、ファイルシステム、さらにはマルウェアの静的あるいは動的な分析が含まれる。

「MBRファイルシステムインフェクタ」の分析

  Portable Executable(PE)ファイルインフェクタウイルスを見かけることは非常に良くあることだ。RAWファイルシステムを経由したファイルインフェクタ、このケースでは「Master Boot Record(MBR)ファイルシステムインフェクタ」は、もう少し珍しい。

  これには、PEインフェクタの方が作成の厄介さが少なく、そしてより強固で、開発やコントロールがより容易だからという理由もある。対照的にMBRインフェクタはより複雑で、サイズは62セクタ(7C00H)に限定されている。またエラーの余地も少ない。すなわち、MBRファイルシステムインフェクタでの小さなミスやバグは、システムを起動不能にするのだ。

  よって、いくつかの無料ファイル共有ネットワークによって配布されているらしい「Trojan:W32/Smitnyl.A (98b349c7880eda46c63ae1061d2475181b2c9d7b)」のようなMBRファイルシステムインフェクタは、一つのPortable Executableシステムファイルを標的にしているだけであっても、そしてその感染が一般のウイルスファイルインフェクタと比較して単純であっても、迅速に分析することは価値があると思われる。

  「Smitnyl.A」は最初に、RAWディスクアクセスを介してMBRを感染させる。次にそれを、ファイルインフェクタルーチンを含む悪意あるMBRで置き換える(セクター32に保存される)。

画像1&2:オリジナルのMBRを上書き。パート1(上)とパート2(下)
1: Overwriting original MBR

2: Overwriting original MBR

  なぜMBRファイルシステムインフェクタなのか? おそらくは、それがWindows File Protection(WFP)をバイパスすることができるからだろう。WFPはプロテクトモードで動作しているので、もし置き換えられれば、すべてのWFP保護ファイルは即座にリストアされる。

  インフェクタペイロードがサイズA00Hでセクタ39から開始される一方で、オリジナルのMBRはセクタ5に保存される。このペイロードは、Windowsのクリティカルシステムファイル「userinit.exe」に上書きされる。

画像3&4:16進法による感染したMBR(左)とオリジナルのMBR(下)
3: Hex view of infected MBR

4: Hex view of original MBR

画像5:16進法によるMBRファイルシステムインフェクタルーチン
5: Hex View MBR File System Infector Routine

画像6:16進法によるUserinitインフェクタペイロード
6: Hex View Userinit Infector Payload

  なぜ「Userinit」なのか? おそらくは、システムがスタートすると自動的にローンチされるプロセスの一つであり、システムスタート時にマルウェアが自動的に実行可能になるためだろう。

  「Smitnyl」はブートシーケンスの最初のステージから、Userinitを感染させる。これはMBRが0x7C00にロードされる際、パーティションテーブル、さらにはブートセクタのstarting offsetからアクティブパーティションを測定する。

  次にマシンのファイルシステムタイプをチェックする:

画像7:ブートセクタタイプの測定
7: Determine Boot Sector Type

  NTFSファイルシステムが見つかれば、マスタファイルテーブル(MFT)を解析し、(MFTが正しく解析されると仮定して)ディスク内の「Userinit」の生データを確定するため、$ROOT (.)ファイルレコードの属性を読んで$INDEX_ALLOCATION属性を探す。「Smitnyl」は、userinit.exeが置かれている、$ROOTからSystem32ディレクトリまでWindowsのパスをチェックする。

画像8&9:Userinit.exeの位置を特定する。パート1
8: Locate Userinit.exe, Part 1

9: Locate Userinit.exe, Part 1

  このマルウェアは、userinit.exeファイルを見つけるのに「get_userinit_data_content_addr」ルーチンを使用し、次にExtended Write Function(ファンクションナンバー ah = 43H)を使用して、セクタ39でインフェクタペイロードを書き込む。userinit.exe感染ルーチンの間、同マルウェアはoffset 0x28で感染マーカの存在も(後からより詳しく)チェックする。

画像10&11:Userinit.exeの位置を特定する。パート2
10: Locate Userinit.exe, Part 2

11: Locate Userinit.exe, Part 2

  マシンが感染したMBRとともに、うまくブートされると、userinit.exeは感染され、自動的にローンチされるはずだ。感染したuserinit.exeを確認する一つの方法は、ファイルプロパティのチェックだ:

画像12&13:userinit.exeプロパティ。オリジナルと感染したもの
userinit.exe Properties, original userinit.exe Properties, infected

  幸いなことに、違いはかなり明白だ。

  16進表示で、感染したファイルを見てみよう:

画像14:感染したUserinit
14: Infected Userinit

  インフェクタルーチンが、感染させる前に感染マーカ0x55AAをチェックすると指摘したことを思い出されるだろうか? ではこれが実行される際、何をしようとするのだろうか? 主要なペイロードはセクタ45にある、エンコードされた実行ファイルをローンチすることだ:

画像15:セクタ45のエンコードされた実行ファイル
15: Encoded Executable File at Sector 45

  これはデコードを開始し、最終ペイロードをローンチする前に、いくつかの準備を行う:

  •  360safeアンチウイルスの存在をチェックする。もし見つかれば、360safe IEブラウザプロテクションが無効にされる。

画像16:360safe IEプロテクション・レジストリキーチェック
16: 360safe IE Protection Registry Key Checking

  •  仮フォルダに偽のexplorer.exeを作成する。これは、デコードされた実行ファイルだ。

画像17:デコードされた実行ファイルによる偽Explorer
17: Fake Explorer with Decoded Executable

画像18:デコードされた実行ファイルによる偽Explorer
18: Fake Explorer with Decoded Executable

  •  デコーディング後、ShellExecuteを使用して「%temp%\explorer.exe」がローンチされる。これは感染を隠すデコイとして用いられる。同時に、「Winexec」を使用して本物の「explorer.exe」が実行される。

偽の「explorer.exe」を実行し、オリジナルの「explorer.exe」をローンチ
19: Execute fake explorer.exe and launch original explorer.exe

  準備が終了すると、ペイロードがローンチされる。

画像20:最終ダウンローダペイロード
20: Final Downloader Payload

  幸いにも、この最終ペイロードには何ら特別なところは無い。単なるダウンローダだ。感染した「userinit.exe」は、360safeのIEブラウザ保護を無効にし、それによりダウンローダがリモートサーバー「http://[...]」からファイルを取り出すことが可能になる。

投稿はLow Chin Yickによる。

バックナンバー
セキュリティ関連リンク
セキュリティ機関

政府関連

セキュリティ関連団体

研究機関・大学
詳細カテゴリ
メディア関係者の皆様へ
エフセキュアブログメンバー
エフセキュアブログメンバー
ミッコ・ヒッポネン
エフセキュア CRO(セキュリティ研究所主席研究員)(ヘルシンキ)
(Twitterアカウント)
(研究所Twitter)
ショーン・サリバン
エフセキュア セキュリティ・アドバイザー(ヘルシンキ)
(Twitterアカウント)
高間 剛典
メタ・アソシエイツ代表
(公式ブログ)
(Twitterアカウント)
星澤 裕二
株式会社セキュアブレイン 最高技術責任者
(公式ブログ)
(人物紹介)
岩井 博樹
デロイト トーマツ リスクサービス株式会社 (〜2013年3月 株式会社ラック) 情報セキュリティ大学院大学 客員研究員
(Twitterアカウント)

(人物紹介)
福森 大喜
株式会社サイバーディフェンス研究所 上級分析官
CDI-CIRTメンバー
(人物紹介)
鵜飼 裕司
株式会社FFRI 代表取締役社長
(人物紹介)
福本 佳成
楽天株式会社
執行役員
OWASP Japan
アドバイザリーボード
Rakuten-CERT representative
(人物紹介)
神田 貴雅
エフセキュア株式会社 プロダクトグループ 部長
富安 洋介
エフセキュア株式会社 プロダクトグループ
コーポレートセールスチーム
エフセキュア株式会社
(エフセキュアブログ公式Twitterアカウント)

海外記事翻訳
株式会社イメージズ・アンド・ワーズ
エフセキュアメールマガジン

ブログに載らないメルマガ限定情報や、技術者インタビュー、製品情報、技術解説を掲載して毎月一回配信します。アドレスのみの登録で購読無料。

エフセキュアブログQRコード
QRコード