エフセキュアブログ

インジェクション を含む記事

ブラウザとメール:マルウェア配信における最大の攻撃経路

 エフセキュアラボでは、顧客が一般的に遭遇するような普及している脅威について継続的に監視している。脅威の大勢を観察する際、我々はサイバー犯罪者が用いる感染経路を調査する。また、こうした攻撃から顧客を保護する効果的な方法を探る。

 以下は、当社の顧客を保護した検知の上位10件である。なお、上位2つはエクスプロイトとスパムメールに関連している。

top10_worldmap_20160428

 まず、最上位にランクされた検知について見ていこう。

ブラウザ経由での攻撃:Angler EK(エクスプロイトキット)

 当社における検出でExploit:JS/AnglerEK.DとなるAngler EK(現在もっとも活動的なエクスプロイトキット)は、当社の世界地図上の統計で最上位の1つになっていることが多い。

 ここ24時間で、同エクスプロイトキットは攻撃的なキャンペーンを再開したように見える。

AnglerEK_hits_20160428

 ユーザは大抵の場合、侵害されたWebサイトを訪れることで感染する。こうしたWebサイトには、インジェクションするリダイレクタのスクリプトや、悪意ある広告(マルバタイジング)が含まれている。このキャンペーンでは、ヒットするのは侵害されたWebサイトからだが、一部はOpenXの広告プラットフォーム経由でもやってくる。

angler_adplatform_blur

 Angler EKは、ワンクリック詐欺のトロイの木馬をインストールすることで知られているBedepを配信し続けている。また、最近ではランサムウェアCryptXXXもインストールする。

angler_saz_20160427_blur

メール経由での攻撃:JavaScriptのダウンローダ

 当社の統計で2番目に多く検知したのは、JavaScriptのダウンローダであるTrojan:JS/Kavala.Dだ。このJavaScriptのダウンローダは、大抵の場合スパムメールに添付されたzipファイルに格納されて届く。当社のテレメトリー上で急上昇を引き起こした、現行のスパムキャンペーンのメールのサンプルを以下に示す。

locky_spam1

locky_spam2

 Locky、TeslaCryp、Dridex、GootKit、Kovter、Boaxxe、Gamarueのようなマルウェアを配信するスパムキャンペーンにおいて、過去数か月の間、ダウンローダとしてJavaScriptを使用するケースが増加しているのを当社では目撃してきた。通常、このようなスパムは様々なテーマで届く。「請求」「写真共有」「支払・注文」「履歴書」「スキャン画像」「VISAの景品」「宅配便の通知」「保険」「Amazonの注文」といったものだ。攻撃者は被害者の範囲を広げるべく、より大きな網を打とうとしているのだ。

 JavaScriptのダウンローダで使用されているファイル名の例を以下に挙げる。

0061705_006774.js
CAN0000013502.js
20160403_914618_resized.js
01c4b975.js
details.jse
63e0f3bc.js
2016 Sales Invoice 700422016.pdf.js
bill.js
copy.js
ADCWYuEi.js
dino kennedy.js

 今回のキャンペーンでは、JavaScriptのダウンローダはランサムウェアLockyの配信を試みる。

locky_blur
Lockyの脅迫メッセージ

 当社の世界地図上でのこれら2つの検知は、マルウェアを配信する最大の攻撃経路がブラウザとメールであることを示唆している。

 顧客の皆さんには、常にブラウザおよび、Flash PlayerやSilverlightといったプラグインを最新バージョンに更新するように注意喚起する。また使用しないのであればプラグインを無効にすることをお勧めする。スパムについては、メールの添付ファイルには慎重になるようにアドバイスする。

Tinbaの分析:設定データ

分析および投稿:Mikko Suominen

 2年前、Tinbaはマルウェアのシーンに参入した。目下のところ、もっとも一般的なバンキング型トロイの木馬の1つとしてシーンに存在している。Tinbaの機能の中でも、あらかじめ設定が組み込まれている点と高度な暗号化方式を実装している点は注目に値する。これにより運用中の効率が高まり、分析される可能性が抑えられる。

 この記事では設定データについて、特に処理メモリから設定データを展開する方法に焦点を合わせる。当社(と読者のみなさんの一部)が設定データに関心を持つ理由は、Tinbaがどのように動作するか、また標的にしているのは誰か、ということを理解する一助となるためだ。

XOR暗号化のクラック

 Tinbaは、フォームグラビングやWebインジェクションといった機能で知られる。この機能は、侵害されたサイトに知らずに訪れたユーザから、銀行の認証情報を盗むために使われる。システムへ侵入する経路は、大半がスパムメールかエクスプロイトキットだ。

 ダウンロードされた時点でフォームグラビングやWebインジェクションの設定がディスク上に格納され、4バイトのキーによるXOR、続いてRC4、最後にApLibでの圧縮により保護される。XORのキーはTinbaのファイル群があるフォルダ名で、文字列から整数に変換したものだ。設定ファイルが一切ダウンロードされなかった場合、Tinbaは自身のバイナリにある、あらかじめ作成された設定データを使用するという手段に出る。このデータは、XORの暗号化を除き設定ファイルと同じ暗号化が用いられている。

 XORの暗号化は、設定ファイルを特定のマシンと紐づけるためのものだ。マシンとボットネットの特定データとの組み合わせをXORキーとして使用することで、感染したマシンへのアクセス権限を持たない人が設定ファイルの復号を試みると、難題に直面することになる。

設定ファイルの復号

 しかしながら、設定ファイルの復号は不要かもしれない。Tinbaが設定データを隠ぺいする方法が、現在の標準に比べると著しくお粗末だからだ。フォームグラビングのデータおよびWebインジェクションのデータの両方は、完全に復号された状態でWebブラウザのメモリに恒久的に格納される。これは非常にうかつである。他のバンキング型トロイの木馬は設定データを用心しながら保護する傾向にあり、必要なときにのみデータを復号し、もはや不要となれば直ちに復号されたデータをメモリから一掃する。

メモリ割り当てにおけるうっかりミス?

 Tinbaの作者は、物事をさらに簡単にするため、非常に怠惰な方法で設定データのメモリ割り当てをコーディングした。データに必要な量だけメモリを割り当てるのではなく、どんな設定データでも確実に格納できるほど十分に大きなメモリ容量をハードコーディングで割り当てることにしたのだ。その結果、0x1400000バイトという巨大なメモリブロックが、Webブラウザのメモリ空間の中でひどく目立っている。フォームグラビングの設定データはこの領域の先頭に保持されるが、Webインジェクションのデータはオフセットが0xa00000の位置に配置される。両方のデータ塊は設定データのサイズから始まる。

 一例に、サンプル「9c81cc2206c3fe742522bee0009a7864529652dd」が受け取ったWebインジェクションのデータの1エントリを挙げる。

Tinda web injection data
ポーランドの金融機関が標的であることをこのサンプルは示している

Zeusのフォーマットとの類似性

 Tinbaの設定データが不気味なほどZeusにそっくりに見えるのだとすれば、それはZeusや他の多数のマルウェアファミリーが使用しているのと同一のフォーマットをTinbaが採用しているからだ。このフォーマットは、どうもクライムウェア業界のちょっとした標準となりつつあるようだ。同一の悪意あるWebインジェクションを異なるボットネットで使用することが可能になるためだ。

 別々のマルウェアの作者が、自分のマルウェアの設定データに同一のフォーマットを使用するようになった経緯を解明するのは興味がそそられる。Webインジェクションのデータはボットネットの保有者が開発したのではなく、サードパーティーから購入したものだと仮定する。もしそうなら、特定の設定のフォーマットが一致するには、Webインジェクションの開発者らと、マルウェアの開発者らの間で連携することが求められる。数年前、Zeusは大きな市場シェアを握っていたので、おそらくこれは単に組織的に行われたのだ。顧客がWebインジェクションをより簡単に達成することを目的に、他の作者たちが同一のフォーマットを使用することは道理にかなっていた。


 Mikko Suominenは当社のレメディエーションチームのシニアアナリストである。

 詳細はJean-Ian Boutinによる論文「The Evolution Of Webinjects」(VB2014)を参照のこと。

SofacyがCarberpとMetasploitのコードを再利用する

1. まえがき

 Sofacy Group(Pawn StormまたはAPT28の別名でも知られる)は、彼らの仕掛けるAPTキャンペーンにおいてゼロデイエクスプロイトをデプロイすることでよく知られている。一例を挙げると、Sofacy Groupが最近利用した2件のゼロデイは、Microsoft OfficeのCVE-2015-2424とJavaのCVE-2015-2590という脆弱性の悪用だった。

 この悪用が成功するとSofacyのダウンローダコンポーネントがインストールされるが、我々が今まで目にしてきたダウンローダとは異なっている。このダウンローダは悪名高きCarberpのソースコードをベースにしている。当該コードは2013年の夏に漏えいし、パブリックドメインとなったものだ。

1.1 Firefoxのブートストラップ型アドオン

 我々は今年の春、ゼロデイエクスプロイトとは別に、Firefoxのブートストラップ型アドオンなど別の手段でデプロイされた、Carberpベースのダウンローダにも遭遇した。だがブートストラップ型のアドオンとは何だろうか?Mozillaによれば、ブラウザを再起動することなくインストールおよび使用が可能なアドオンの一種とのことだ。

 このSofacyのアドオンのインストールは、主にソーシャルエンジニアリングに頼っている。ユーザが悪意のあるWebサイトや侵害されたWebサイトを訪れると、このアドオンをインストールするように促されるのだ。

HTML5 Rendering Enhancements 1.0.
図1:Sofacyのアドオン「HTML5 Rendering Enhancements」

 メインのコードは、アドオンのパッケージ内にあるbootstrap.jsに格納されている。アドオンが有効になった時点で、前述のJavaScriptはSofacyのCarberpベースのダウンローダを次のURLからダウンロードする。

hxxp://dailyforeignnews.com/2015/04/Qih/north-korea-declares-no-sail-zone-missile-launch-seen-as-possible-reports/579382/hazard.edn

 ペイロードはvmware_manager.exeとしてローカルに保存される。

 このブートストラップ型アドオンの技術は、完全に新規のものというわけではない。2007年にはドキュメント化されており、主に潜在的に迷惑なアプリケーションで使われている。しかしながら、Sofacyがこの手法を使っているのを目にするのは、初めてのことだ。Sofacyのbootstrap.jsファイル内のコードの大半は、Metasploitから直接コピーされたもので、{d0df471a-9896-4e6d-83e2-13a04ed6df33}というGUIDや「HTML5 Rendering Enhancements」というアドオン名が含まれている。その一方で、ペイロードをダウンロードする部分はMozillaのコード片の1つからコピーしていた。

2. ドロッパーとDLLに関する技術情報

 このエクスプロイトを使用した文書ファイルやアドオンは、PE実行ファイルを運んでくる。この実行ファイルは、自身に組み込まれているDLLをシステムにインストールするものだ。実行ファイルの大きさは100KB内外で、ファイル圧縮はされていない。一方、インストールするDLLは標準的なWindows APIを用いて圧縮されており、ディスクにドロップする前にRtlDecompressBufferで展開する。我々が見てきた全サンプルが有する重要かつ共通の特徴は、「jhuhugit.temp」という名前の一時ファイルだ。このファイル名は、実行ファイル内にあるほぼ唯一の平文の文字列だ。他の文字列は、固定の11バイトのキーを使ったXORアルゴリズムにより難読化が図られている。一部のサンプルに現れる興味を引く別の文字列は、「bRS8yYQ0APq9xfzC」という暗号キーだ。GitHubにあるCarberpのソースツリーで見つかった固定の「メインパスワード」の1つと一致するものだった。

 このDLLは、OSの実行ファイルであるrundll32.exeを使い、「init」という名前でエクスポートされているものが実行される。DLL自体には多くの機能はない。単純にループし続けて、30分ごとに決まったC2サーバ群のうちの1台に問い合わせを行う。我々は生きているペイロードをこれらのサーバからいまだ取得できていないが、コードに基づくと、DLLは最初に自身が実行されたときとまったく同じ方法でペイロードの実行のみを行う。C2サーバのアドレスや他の設定データは、同じ11バイトのXORキーアルゴリズムを用いて難読化されている。これまでのところ手が込んでいるようなことは何もないが、同じCarberpのパスワードが、しかも我々が見てきたすべてのDLLで使われている。我々はこの関連性を発見しようとするほど、好奇心をそそられた。

 DLLのリバースエンジニアリングを注意深く行うことで、このファミリーはCarberpのソースコードをベースとしていることが明確になった。コードのレポジトリはGitHubで見つかるものとまったく同じではないが、後述する主張をするのに十分なほど似通っている。今回Sofacyが使ったCarberpのソースをベースにした機能には、API解決アルゴリズムとコードインジェクションメカニズムが含まれる。またランダムなURLを生成するために用いたアルゴリズムも、大まかにはCarberpに基づいている。

3. Carberpのソースコードとの比較

3.1. API解決アルゴリズム

 公開されているCarberpのソースコードでは、実行時にAPIが解決される。これには以下のようなコードの構造を用いている。

#define pLoadLibraryA   pushargEx< DLL_KERNEL32, 0xC8AC8026, 2 >

 例では、pLoadLibraryAという関数が別のpushargEx関数で定義されている。この関数には以下の引数が与えられている。

  • モジュールの識別子として、この例ではDLL_KERNEL32
  • 関数名のハッシュ値としてC8AC8026。これは実行時に計算される
  • 関数のキャッシュのインデックスとして「2」

 このpushargEx関数は複数の定義により、見込まれる引数の数のすべてに対応する。引数が5個の場合の定義を以下に例示する。

inline LPVOID pushargEx(A a1, B a2, C a3, D a4, E a5)
{
    typedef LPVOID (WINAPI *newfunc)(A, B, C, D, E);
    newfunc func = (newfunc)GetProcAddressEx2( NULL, h, hash, CacheIndex );
    return func(a1, a2, a3, a4, a5);
}

 PushargExGetProcAddressEx2に行きつく。この関数は名前のハッシュ値に基づきAPIの関数アドレスを割り出すものだ。その後、当該アドレスの関数が実行される。このような構造にした目的は、通常コード内にある標準的なWin32のAPI関数を、「p」という文字を関数名の先頭に追加して使えるようにすることだ。その結果得られるコンパイル後のコードは、あまり読みやすいものではない。したがってリバースエンジニアリングの過程に時間がかかるようになる。また、このような完全な位置独立コードによる恩恵もある。コードインジェクションには都合が良いのだ。

 CarberpのソースツリーにはAPIのハッシュ値と、対応するキャッシュのインデックスのリストが含まれる。以下のような素敵なリストだ。

Carberp API list.
図2:CarberpのAPIリスト

 ここでSofacyのバイナリコードに戻ろう。逆コンパイルしたコード片の実例から、Sofacyが同じハッシュアルゴリズムとインデックスの採番方式を採用していることは明白だ。

Sofacy GetModuleHandleA
図3:SofacyのGetModuleHandleA

 GetModuleHandleAは、Sofacyが動的に解決する数多くの関数の1つに過ぎない。ただしそれらの関数はすべて、Carberpのソースコードと完全に一致する。ハッシュ値や引数、インデックス値までもだ(図2のインデックス番号の#43を見てほしい)。

 API解決部分までさらに観察していくと、GetProcAddressExおよびGetProcAddressEx2と名付けられた関数に著しい類似性が見られた。CarberpのソースとSofacyのバイナリを逆コンパイルしたコードのGetProcAddressEx2のスクリーンショットを、以下に並べて示す。

GetProcAddressEx2 from Carberp and Sofacy.
図4:CarberpおよびSofacyのGetProcAddressEx2

 CarberpのソースとSofacyのバイナリを逆コンパイルしたコードのGetProcAddressExの類似性の比較は以下のようになる。

GetProcAddressEx from Carberp and Sofacy
図5:CarberpおよびSofacyのGetProcAddressEx

 上記の逆コンパイルしたコード片においては、意図的にすべての関数と変数の名前がCarberpのソースに従うようにした。これは単に説明のためだ。

3.2. コードインジェクション

 Sofacyは、ネットワーク周りのコードすべてにおいてコードインジェクションを用いている。自身の関数をブラウザのプロセス群にインジェクションするのだ。プロセス群を探すために、Carberpのプロセス名ハッシュアルゴリズムを用いている。このような仕組みにした目的は、十中八九パーソナルファイアウォールやその他のビヘイビア検知システムを迂回するためだ。

 コードインジェクションはInjectIntoProcessという名前の関数から開始する。この関数はプロセスをオープンしてInjectCode4 によりコードを注入し、CreateRemoteThreadで実行する。以下にCarberpのコード片を示す。

InjectCode4 from the Carberp source.
図6:CarberpのソースにあるInjectCode4

 SofacyのバイナリにあるInjectIntoProcessInjectCode4が、この機能を結び付けている。

InjectIntoProcess from Sofacy
図7:SofacyにあるInjectIntoProcess

Figure 8: InjectCode4 from Sofacy
図8:SofacyにあるInjectCode4

3.3. ミステリアスなメインパスワード

 Carberpのソースには、MainPassword、あるいはRC2_Password、DebugPasswordと呼ばれるパスワードが存在する。このパスワードの取り得る値の1つが「bRS8yYQ0APq9xfzC」というもので、Sofacyでも使用されている。Carberpにおけるこのパスワードの目的は、たとえばHTTPトラフィックの暗号化だ。一方Sofacyでは、まったく異なる方法で使用されている。SofacyではAPI解決のためのアルゴリズムに手が加えられており、そこでこのパスワードを用いている。Carberpでは、API解決部分において平文でDDL名のリストを持っている。GetProcAddressEx2が参照するインデックスパラメータのことだ。Sofacyではこのリストは、Carberpの「メインパスワード」を用いて単純なXORベースのアルゴリズムで難読化がなされている。

4. 結論

 本ブログ記事で示された分析に基づけば、新たなSofacyのダウンローダはCarberpのソースコードをベースにしている。しかしながら非常に大きな違いもある。たとえばAPIの解決や、Carberpのメインパスワードの使用といったものだ。その関連について我々が下せる結論とは?Sofacyの一味は、Carberpのソースコードのプライベートなソースツリーを保有していることを意味すると、我々は考えている。APIの解決部分でDDL名を保護するためにパスワードを使用していることは、GitHubで一般公開されているソースよりも新しいことを示唆するものだ。これはSofacy一味は単にソースツリーをコピーして開発を継続していることを意味するのだろうか?あるいは、舞台裏で誰か別の人物がさらに開発を重ねているのだろうか?これについては、我々はまだ把握していない。しかしSofacyとのつながりや、さらに加えて(Carberpをベースにしている)AnunakやCarbanakによる最近のインシデントにより、Carberpがいまだに健在であることが示唆される。

5. ハッシュ値

bootstrap.js:

e7d13aed50bedb5e67d92753f6e0eda8a3c9b4f0

ドロッパー:

b8aabe12502f7d55ae332905acee80a10e3bc399
015425010bd4cf9d511f7fcd0fc17fc17c23eec1
51b0e3cd6360d50424bf776b3cd673dd45fd0f97
4fae67d3988da117608a7548d9029caddbfb3ebf
b7788af2ef073d7b3fb84086496896e7404e625e
63d1d33e7418daf200dc4660fc9a59492ddd50d9
b4a515ef9de037f18d96b9b0e48271180f5725b7
f3d50c1f7d5f322c1a1f9a72ff122cac990881ee

DLL:

5c3e709517f41febf03109fa9d597f2ccc495956 (逆コンパイルされたコードの例)
ed9f3e5e889d281437b945993c6c2a80c60fdedc
21835aafe6d46840bb697e8b0d4aac06dec44f5b
d85e44d386315b0258847495be1711450ac02d9f
ac61a299f81d1cff4ea857afd1b323724aac3f04
7319a2751bd13b2364031f1e69035acfc4fd4d18
b8b3f53ca2cd64bd101cb59c6553f6289a72d9bb
f7608ef62a45822e9300d390064e667028b75dea
9fc43e32c887b7697bf6d6933e9859d29581ead0
3b52046dd7e1d5684eabbd9038b651726714ab69
d3aa282b390a5cb29d15a97e0a046305038dbefe


広告インジェクションを避けるために、なぜVPN以上のものが必要なのか



インターネット上では、かなりの量の広告を目にしますよね。しかし、見るべき以上のものを目にしている可能性がかなり高いと思います。携帯電話会社、インターネットプロバイダー、Wi-Fiホットスポット、マルウェア、ツールバー、ブラウザ拡張機能はすべて、皆さんがお使いのウェブブラウザに広告を注入することができます。そして、それらの広告からマルウェアを仕込まれる可能性があるのです。

この夏の初め、Yahoo!にアクセスした何人かの人たちは、「広告の影響は人の心以外のものにも及ぶ」ということを、身をもって学びました。『ニューヨークタイム』誌は次のように報道しています。

ハッカーたちは7日間、Yahooの広告ネットワークを利用して、Yahooのなかでもトラフィックの非常に多いウェブサイトにアクセスするコンピュータに悪意のあるコードを送っていたと、月曜、Yahooから発表がありました。

7月28日に始まったこの攻撃は、オンラインで何百万人もの人にリーチできるよう設計されている、インターネットの広告ネットワークを悪用した一連の攻撃のなかで最新のものでした。


この特定の脅威は、Adobe Flashの脆弱性を悪用したものでした。Flashには、ほぼ常に悪用可能な脆弱性が見つかりますね。Adobeは火曜、Flashに対して今年12回目となるアップデートをリリースしました(皆さんがFlashの使用の停止を考慮すべきもっともな理由ですよね)。

第三者によりブラウザに注入された広告をユーザーがかなりの頻度で目にしていることに、専門家たちは気づいていました。しかし、Googleが今年の5月に研究結果を発表するまで、問題の範囲がはっきりとしていませんでした。その発表によると、ウェブサイトのオーナー、つまりこのケースではGoogle自身に無断で注入された広告を表示していたGoogleのサイトに、何百万人というユーザーがアクセスしていたということです。

報告書では、「ユーザーのブラウザと注入された広告を操る50,000以上のブラウザ拡張機能、34,000以上のソフトウェアアプリケーションが発見されました。これらのパッケージの30%以上が、完全に悪意のあるものであり、同時にアカウントの認証情報を盗み出し、サーチクエリを乗っ取り、追跡目的でユーザーのアクティビティを第三者に報告していました」とされています。

この問題を完全に解決するには、すべての広告ネットワーク、モバイルプロバイダー、インターネットサービスプロバイダーが、私たちのブラウザに広告を詰め込むという非常に利益性の高い慣習に厳しい措置を取る必要があります。しかし、そうなるとは思わないでください。少なくとも近いうちに実現することはありません。
だからと言って、何もできないというわけではありません。

残念ながら、皆さんも知っているような、頭文字で表される主なプライバシー/セキュリティ機能の多くは、役に立ちません。Secure Sockets Layerを表すSSLなどのことです。これは、皆さんがお使いのブラウザとウェブサイト間の通信を暗号化するものです。VPNもそうです。これはVirtual Private Networkの略です。こうしたタイプのソフトウェアは、インターネットトラフィックのために暗号化したトンネルを構築するものですが、不正なトラフィックをブロックしたり、フィルターにかけることはありません。

では、何なら役に立つのでしょうか?

エフセキュアのマルウェア保護チームのリーダーであるティモ・ヒルヴォネンは、「携帯端末も含め、インターネットに接続している時は、不正なウェブコンテンツを自動的にブロックするエフセキュアのFreedomeのようなセキュリティソフトを必ず使い、保護を行うようにしてください」と述べています。
FreedomeはVPNでは? そうです。しかし、それだけではありません。

Freedomeは皆さんのデータを暗号化し、皆さんのデバイスやPCの位置情報の管理を可能にします。また、トラッカーが皆さんに関する情報を探るのを防ぎます。さらに、マルウェアのスキャニングを行い、害のあるサイトやトラッカー、アプリからの保護を提供します。

インターネット利用時に余計な広告が表示されると、セキュリティが脅かされるだけでなく、気も散りますよね。自分で対処しようと思っているのであれば、VPN以上のものが必要になります。

>>原文へのリンク

Neutrino:現行犯で逮捕

 先週我々は、エクスプロイトキットへと導くiframeインジェクションを提供する、ハッキングされたサイトについて、Kafeineからヒントを得た。我々は非常に興味深いと考え、感染したWebサイトの1つを監視して、以下のコード片が潜んでいるのを見つけた。

sitecode



 ぼかしていない方(deobfuscated)のコードは、挿入されたiframeのURLがどこから集められるのかを示している。また同時にリダイレクトを許可するcookieを使用していることが分かる。さらにIE、Opera、Firefoxからブラウズしたユーザのみを標的に感染させることを表している。

 そして現在、ソースサイトや感染したサイトからの、古いが良質な断片情報がある。

injected



 感染したWebサイトが首尾よくリダイレクトをすると、ユーザはNeutrinoエクスプロイトキットに行き着く。これはJavaエクスプロイトを提供するものだ。

redirections



 トロイの木馬のペイロードをまだ十分に解析していないが、最初に確認した際に、以下のIPアドレスにHTTPポストを行っていることが判明した。

mapp



 今週の初め、おそらくまだ完全に影響を受けていない頃、挿入されたURLはgoogle.comに向けられていた。しかしながら、昨日の夕方、完全なオペレーションが開始され、Javaエクスプロイトを提供するNeutrinoにリダイレクトし始めた。

first_instance



 この時系列に基づき、感染したサイトを訪れた各IPアドレスの地点を地図上にプロットした。これらのIPアドレスはこの脅威における潜在的な犠牲者だ。おおよそ8万個のIPアドレスが存在する。

visitor3



 我々はまた、これまでに感染したWebサイトもプロットした。この脅威の影響を受けたドメインは2万超に達する。感染したサイトは、WordPressもしくはJoomla CMSのいずれかを使用しているように見受けられる。

hacked



 なお、この脅威に関する別の情報が、Kafeineのブログに投稿されている。

 このポストに関連があるサンプルは、Trojan:HTML/SORedir.A、Exploit:Java/Majava.A、Trojan:W32/Agent.DUOHとして検知される。

 Post by — Karmina and @Daavid

9.18のサイバー攻撃に関しての補足的情報(追記)

恒例の918サイバー攻撃の時期が近づいていますが、対策は万全でしょうか。
概要はニュースなどで報道されていますので、内容は割愛させて頂きます。

さて、報道にもありましたように9/18に向け、今年も紅客(ほんくー:中国のハクティビズムのグループの総称)らより攻撃の標的リストが公表されています。
しかし、残念ながら必ずしもこれらのリスト通りに攻撃が行われるわけではありません。
一部の攻撃者らはGoogleなどの検索エンジンを利用することで、標的を絞っています。つまり、攻撃者らの検索結果として表示されたウェブサイトは攻撃対象となる可能性がある、ということになります。
そういった意味では、リストに記載されていない組織においても警戒をしておくに越したことはない、と言えます。

標的リスト例


では、攻撃者はどのような文字列を検索し、標的を絞っているのでしょうか。
例えば、ある紅客はSQLインジェクションの標的を絞り込むために、次のような文字列を利用しています。
site:.jp inurl:php?id= site:.jp inurl:asp?id=
結構、大雑把に検索していることが分かります。とりあえず、リスト化して攻撃しようということなのでしょう。
このような検索文字列に関しての情報は、9月に入り日本への攻撃を示唆する内容と共に複数確認されています。
他の検索文字列として次のものが紹介されています。(9/18の攻撃と直接関連するかは分かりませんが、、、)

google hacks
※「inlitle:」は「intitle:」のtypoかと思われます。

他にも様々な検索文字列により検索されることが推測され、多くのウェブサイトが攻撃対象となる可能性があります。そういった意味では、これらの検索結果に、自身のウェブサイト上の脆弱点が表示されていないか、など事前に確認しておくことは攻撃対象から逃れる点では、有効な対応策の1つと言えます。

ちなみに、これらの検索結果にはWordpressなどのCMSの情報も含まれています。メジャーなCMSは脆弱性も多く報告されていることから、標的となる可能性が高いと考えられますため、確実に対策を実施してください。
※WordpressやMovable Typeに関してはIPAからも注意喚起がされていますので参照ください。
http://www.ipa.go.jp/security/topics/alert20130913.html

尚、Google Hackingはキャッシュから調査しています。そのため、標的の絞り込みの段階でウェブサーバに対して明らかに攻撃と判断できる通信は発生しません。

実際に日本組織を狙った大規模なサイバー攻撃があるかは分かりません。しかし、毎年恒例のことですので、避難訓練のつもりでエスカレーション・チェックなどを実施しても良いかと思います。
現在のところ、DDoS攻撃や多数のウェブサイト改竄などの目立った動きが報告されていませんが、目立った情報が得られましたら随時追記していきたいと思います。


【追記 9/18】
複数のウェブ改竄が確認され始めました。
ウェブサーバのコンテンツに日本を挑発するようなファイルがありましたら、侵入されている可能性大です。
例えば、Fuck-JP.html などです。
念のため、不審なコンテンツが追加されていないか確認されることを推奨します。

1937CnTeam

ちなみに、記載されている内容は満州事変とは直接関係のあるものではありません。


GhostShellの第6次プロジェクトについて

10月に世界中の100の大学(日本を含む)のサーバから窃取した情報をネット上に掲載し話題となった「GhostShell」が次のプロジェクト予告をしたことが注目されています。
#少し時間が経っていますが・・・


ghostshell_20121106


過去の攻撃手口から、恐らく今回もSQLインジェクションや管理アプリケーションの脆弱性などを狙った攻撃を行うのではないか、との見方が強いようです。
現在のところ具体的な標的などの詳細情報は掲載されていませんが、念の為公開サーバ群のセキュリティ・チェックをしておくことをお勧めします。
例えば、
・ウェブアプリケーションの脆弱性の修正
・データベースやコンテンツ管理システムなどへのアクセス制限
・IPSやWAFの動作確認(検知しなかったら意味がありませんので)
などなど、確認すべきことは多いように思います。

ちなみに、GhostSehllの過去のプロジェクトはPastbinに掲載されています。
今回もプロジェクトに関する情報がPastbinに掲載されるかはわかりませんが、気になるようでしたら参照しておくと良いかもしれません。

http://pastebin.com/u/TeamGhostShell

プロジェクトが実行されないことが一番良いのですが。。。

追記
12月10日付けで掲載されたようですね。
#ProjectWhiteFox
http://pastebin.com/agUFkEEa

ベルリン警察:Android版銀行口座向けトロイの木馬を警戒

ベルリン警察局は先週火曜日、現金引き出し詐欺に対する刑事告訴関して、プレスリリースを発表した。すべての事件に、SMS mTansとAndroidスマートフォンが関与している。

Pressemeldung #3628
オリジナルGoogle翻訳

 このことは、Mobile ZeuS Man(Zeus Mitmo)とも呼ばれることがある、Mobile ZeuSの事件(Zitmo)に似ていると思われる。我々がZitmoのことを最初に書いたのは、2010年9月に遡る。Zitmoに関して気を付けなければならないことは、それが「モバイル」マルウェアの類のものではないということだ。それより、ZitmoはWindowsベースのZeuSボットと同類/補足コンポーネントなのだ。Zitmoは、銀行の顧客が認証用の追加レイヤーにSMS mTansを使用する際に、WindowsベースのZeuSと一緒に実行される。

 セキュリティの mTansレイヤーに対応するために、ZeuSボットは口座取引中に顧客に電話機のモデルや番号を尋ねる「セキュリティ上の注意」画面を挿入する。悪意ある者は続いて、いわゆる「セキュリティの更新」にSMSリンクを送信するが、これは、実際にはmTansの裏をかくために必要なMobileコンポーネントのManなのだ。

 実害が発生しているZeuSボットにはさまざまなものがある。たとえば、2か月前に我々はZeuSのP2PバージョンであるGemaoverについて書いた。1つのZeuSベースのボットネットだけでも、ドイツで4千9百万近い感染がある。この感染は、どれをとってもZitmoの標的になり得るのだ。

 それでは、Zitmoに対する最適な防御とは何であろうか?ベルリン警察局は、市民が自分の銀行から要請される「セキュリティ更新」に疑念を持ち、ホームコンピュータを防御することを推奨する。

 このことは、最新のウィルス駆除ソフトをインストールすることも含まれる。

-----

 自己プロモーションには次のように書かれている:

 Zitmoのような脅威は、弊社がインターネットセキュリティとモバイルセキュリティをセットとしてご提供する理由の1つです。

 そして、ZeuSのような脅威こそが、弊社の最新のインターネットセキュリティ機能を、中間介在者をブロックしインジェクション攻撃するように設計し、銀行口座防御と呼ぶこととなった原因です。

 ご利用のデバイスはすべて繋がっています。安全を心掛けてください。

FBIはDNSChangerサーバの継続で再認可されるべきか?

  DNSChangerの最新のデッドラインである7月9日が、急速に近付きつつある。(前回のデッドラインは3月8日だった。)あとたったの1週間だ!

  DNSChangerとは何か?

  DNSChangerは、F.B.I.とエストニア当局が昨年後半、「Operation Ghost Click」で壊滅させた広告詐欺ボットネットだ。

  「Operation Ghost Click」?

  「Click」はクリック詐欺を意味している。DNSサーバの設定を変更することで、ギャングたちは中間者広告インジェクションを実行することが可能になった。

  中間者広告インジェクションとは? 悪党たちはそれでどのように利益を得たのか?

  そう、2006年頃には、広告詐欺では「クリックボット」が使用され、この問題がメディアの注目を集め始めると…広告主はGoogleがクリック詐欺防止のため、十分な手を打っていないと文句を言い始めた。そして彼らは、クリック単価の損害について訴訟を起こすと威嚇した。

  そこでGoogleは、この問題に技術者を投入し、現在では、事前に準備したクリックボットは、かなりのアンチ詐欺防御に直面している。Googleの自動化の方が、詐欺師よりもはるかに優れているのだ。さよなら、クリックボット。

  すると賢い広告詐欺師たちは、「オフスクリプト」に向かう必要を感じ、人間を関わらせることになった。すなわち広告インジェクションだ。人間の「被害者」は、広告を見た際、クリックを強要されないため、ある意味では、それはGoogleが自動化した防衛によって予測可能な「広告詐欺」とは言えない。そんなわけで、マン・マシンボット(サイボーグと呼ぶべき?)の組み合わせが金儲けに使用された。

  非常に賢い。

  そう。そしてそれがおそらく、F.B.I.の関心を引いた理由の一つだろう。感染したコンピュータの数は、ある時点で50万台以上を数えた。

  うわー、それはたくさんだ。現在も感染しているコンピュータは何台あるのだろうか?

  6月11日現在、30万以上のIPアドレスが「仮の」DNSサーバに登録されている。

  以下は、トップ25カ国の内訳だ:

Unique DNSChanger IPs, June 11
ソース:国ごとのDNS Changer上位感染ランキング

  すると7月9日のデッドラインはどういうことになるのだろう?

  3月、ニューヨーク南部地区の米連邦地裁が、代用のクリーンな「一時的」DNSサーバの認可を延長した。この認可が再度延長されなければ、DNSサーバをシャットダウンする必要がある。

  すると何が起きるのか?

  その時点で、影響を受けたコンピュータはすべて、DNSサーバから切断される。コンピュータはそれでもインターネットに接続しているが、インターネットリソースを探すのに必要な「アドレス帳」により設定されることは無い。

  アドレス帳?

  DNSサーバは、google.comのようなURLを、173.194.32.7といったIPアドレスに変換する。

  DNSが無ければ、数字のアドレスを知っている必要がある?

  その通り。

  代用サーバが打ち切られたら、とんでもない混乱が起きそうだ。法廷は再認可を与えるだろうか?

  イエス。しかし…そうすべきだろうか?

  そうすべきでは無いのか?

  6カ月で、感染したコンピュータの半数以下が修正された。F.B.I.がこれらのゾンビコンピュータを使用可能にするのに、あとどのくらいかけるべきだろうか? 確かに、DNSサーバの切断は若干の混乱を引き起こすだろうが、現時点では、残りの感染を解決する最も速い方法かもしれない。そして率直に言えば、早ければ早いほど良い。これらのコンピュータはボットのままでいる限り、他の感染にも脆弱だからだ。

  このアンケートに参加して欲しい:F.B.I.は7月9日以降も継続するよう再認可されるべきか?




  コンピュータのチェックは以下で行える:http://www.dcwg.org/detect/

また新たなSQLインジェクション攻撃

  どういうわけか、ASP/ASP.netサイトを標的とする、こうしたSQLインジェクションはまったく衰える気配が無い。

  最初にLizamoonがあった…何百万ものWebサイトが感染し、驚かされた。

  次にnikjju.comhgbyju.comといった、2、3の事例が続いた…

  そして今やnjukolだ…

google_results (256k image)

  その名はもはやLizamoonほどキャッチーではないが、そのアイディアは変わらない。

  このnjukol.comは、まだかなり新しいものだ。同ドメインは4月28日に登録されている。面白いのはドメインの登録者が以前のもの全てと同じままだということだ。

registrant (6k image)








自身をブロックするウイルス

  「Virus:W32/Ramnit」は、2010年に感染が確認されており、多くのマルウェアアナリスト/リサーチャーによく知られている。

  この興味深いウイルスのテクニカルな詳細については、他のマルウェアリサーチャーたちがブログに記事を書いている(たとえばここここにある)。しかし若干の注目すべき技術と、そして「イースターエッグ」が、発見されるのを待っている。

  その興味深い技術の一つは、「Ramnit」が使用するインジェクションメソッドだ。従来の方法とは異なり、ウイルスが停止したスレッドを作成し、メモリ書き込みWindows API機能を使用し、コードの注入を行い、インジェクション完了後、停止したスレッドを再開する。

  このケースで、「Ramnit」を独特の物にしているのは、デフォルトのWebブラウザプロセス、もしくは「svchost.exe」として知られるGeneric Host Process for Win32 Servicesという新しいプロセスを生み出すのに、これがWindows API機能をコールすることだ。この新たに生み出されたプロセスにインジェクトすることで、コードはユーザに不可視となり、ファイアウォールをバイパスすることができる。

  しかし、それ以前に、「Ramnit」は「Ntdll!ZwWriteVirtualMemory」と呼ばれる、マニュアルに記載されていないWindowsネイティブシステムサービスに、インラインフックをインストールする。以下の画像は、このインジェクションの仕組みを示したものだ:

ramnit infection

  フックされたWindowsネイティブシステムサービスは、コードインジェクションルーチンを実行するため、コード実行フローをコーラプロセスに定められたモジュールにリダイレクトする。新しいプロセスでインジェクトされたコードは、バックドアおよびダウンローダ機能のほか、ファイル感染力(Windows実行ファイルとHTMLファイル)を含んでいる。

  「Ramnit」でもう一つ注目すべき点は、上記のプロセスにインジェクトされるDLL内に見られる「イースターエッグ」だ。以下に挙げた同コードのスナップショットが、すべてを説明するだろう:

antidot

  基本的にこのイースターエッグは、レジストリキーにナビゲートし、「WASAntidot」を探す:

antidot

  我々がテストマシンで「WASAntidot」レジストリキーを作成しようとすると、以下のような画面を見ることになった:

antidot activate

  ほら! マシンは「Ramnit」の感染から安全だ!

Threat Solutions post by — Wayne

リアルとサイバーの狭間で 〜 APECからみるサイバーテロ

APECが無事終了し、物々しかった横浜もすっかりいつもの風景に戻りました。
APECといえば、過去にスペインで開催された際に爆破テロが思い出されます。あのようなテロが起きないよう、横浜の警備は厳戒態勢で行われていたわけです。その甲斐もあり、大事もなく無事閉会しました。

ところで、APECの事前資料である「2010年APECの成功に向けて」に、サイバー空間も警備対象となっていたことはご存知でしたでしょうか?
テロというと過激派のイメージがあり、あまりインターネット・セキュリティと関係なさそうですよね。しかし、実はStuxnetが話題になったように、ITもテロに利用される可能性があるため、ネット上も厳戒態勢(?)だったわけです。

私どもが(こっそり)実施した調査では、以前から武装組織と推測されるサーバからサイバー攻撃が行われていたことが分かっています。
JSOCに蓄積されている攻撃元データ(今年1月から9月まで)と、武力組織が利用していると推測されるIPアドレスと照合しマッピングしますと、大体こんな感じになります。

terro_2010

何となくですが、傾向を見ますと大きな武力組織ほど攻撃レベルは高く、本気度も高いように思いました。また、攻撃の内容ですが、SQLインジェクションからTrojanの配布まで様々で、各組織毎に思惑が異なるようです。
残念ながら、攻撃目的が資金調達目当てなのか、Stuxnetの件で噂されるように重要インフラを狙ったものかは、現段階では不明です。

現在、ネット接続の出来ない国は殆ど無いと言われています。当たり前ですが、これはどこからでもサイバーテロが実行可能であるということです。
さすがに、多くの攻撃はテロとは関係のないものだとは思いますが、幾つかはテロと関連した攻撃だということは言えそうです。
つまり、もしかすると自分の会社が今受けている攻撃は、実はテロの一部なのかもしれないわけです!
こう考えると、ちょっとはテロが身近に感じられるのではないでしょうか?(笑)
#といっても、実感が無いのでオバケの警告みたいですが。。。

次回、日本で大きな国際イベントがある際は、是非サイバーテロ対策にも目を向けてみてください!
きっと、インターネット・セキュリティを通じて世界が身近に感じられるかと思います。

リバースエンジニアリング本

オライリージャパン宮川様より「リバースエンジニアリング――Python によるバイナリ解析技法」を献本いただきました。本書はGray Hat Python(Justin Seitz著)の日本語版で、DebuggerやFuzzerなどの基本原理や構築方法がPythonのサンプルコードとともに解説されています。技術監修はラック社の中津留さんです。
本ブログの読者の方々、特にリバースエンジニアリングに少しでも興味のある方は、まさに本書の対象読者でしょう。以下目次です。いかがでしょう?ちょっと読みたくなってきませんか?

1章 開発環境のセットアップ
2章 デバッガの基本原理
3章 Windowsデバッガの構築
4章 PyDbg―ピュアPythonのWindowsデバッガ
5章 Immunity Debugger―両方の世界をまたにかけ
6章 フック
7章 DLLインジェクションとコードインジェクション
8章 ファジング
9章 Sulley
10章 Windowsドライバのファジング
11章 IDAPython―IDA Proでのスクリプティング
12章 PyEmu―スクリプティング対応のエミュレータ

本書は/ART/OF/REVERSINGシリーズ3部作の第一弾で、第二弾は来月2日発売予定の「デコンパイリングJava――逆解析技術とコードの難読化」です。そして第三弾は今秋発売予定の新井悠、岩村誠、川古谷裕平、青木一史、星澤裕二による「アナライジング・マルウェア――フリーツールを使った感染事案対処(仮)」です。そうです、筆者も執筆陣に加えていただいております。というわけで、ただ今鋭意執筆中。

Adobe Readerゼロデイの検出

昨年末からAdobe Reader/Acrobatのゼロデイ、CVE-2009-4324を攻撃するPDFファイルが出回っています。
私のところに届いたマルウェア入りPDFも検知率はあまりよくなく、9.76%でした。

1

このマルウェアはいろいろ細かい動きをするのですが、主な動きは、
・PDFファイルの中に埋め込まれたバックドアDLLを取り出す
・svchost.exeを起動し、コードインジェクションを行う
・インジェクションされたコードがバックドアDLLをインジェクションする
という部分でして、このバックドアの検知率はというと26.83%まで上がります。

2


このように見た目ほど検知率が悪い訳ではありませんが、決して高いとは言えませんので、依然として注意が必要です。

福森大喜さん:エフセキュアブログメンバーご紹介

高間さん星澤さん岩井さんにつづいて、Webアプリケーションセキュリティの専門家でいらっしゃる福森大喜さんに、先月から当ブログのオフィシャルコメンテータとしてご参加いただいております。

※オフィシャルコメンテータは、エフセキュア社外からゲストブロガーとしてご参加いただいている皆様です

さっそく、福森さんのご紹介を申し上げたいと思います。

11月下旬、神田の福森さんのオフィスでお話をお聞きしました。

●福森大喜さん

福森 大喜(ふくもり だいき)
株式会社サイバーディフェンス研究所 上級分析官

大手セキュリティベンダーでIDS、IRT等に従事した後、Webアプリケーションのセキュリティ検査サービスを立ち上げる。その後、Webセキュリティベンチャーを設立。2009年よりサイバーディフェンス研究所に参加。


専門領域:
Webセキュリティ、ペネトレーションテスト、マルウェア解析

受賞:
2007年 第3回 IPA賞(情報セキュリティ部門)
2009年 グーグル Native Client セキュリティコンテスト 世界4位

寄稿記事:
ここが危ない!Web2.0セキュリティ」 (gihyo.jp)
セキュリティから読み解くWeb2.0」 (警察庁@police)
いざラスベガス、いざDEFCON CTF決勝へ」 (@IT)
など

講演実績:
2007年4月12日 セキュリティ・ソリューションフォーラム(「Web 2.0は危険がいっぱい」)
2007年4月26日 RSA CONFERENCE JAPAN(「Webセキュリティはなぜ破られるのか」)
2008年10月11日 AVTokyo 2008(「Flashを媒介したXSSワームの可能性」)
2007年11月15日 POC Korea 2007(「Attacking Web 2.0」)
2008年11月 Email Security Expo & Conference 2008(「SQLインジェクションの基本と応用」)
2009年4月22日 Shibuya Perl Mongers テクニカルトーク(「Native Client Hacks」)
など

SQLインジェクション攻撃のニューウェーブ

  多くのWebサイトに障害を出している、新たなSQLインジェクション攻撃に関する報告が届いた。その攻撃で使用されている悪意あるiframeのGoogleでの検索結果は、10万ヒット以上に達する:

Google search results for SEO attack

  最初のiframeがHTMLページに導き、このページが難読化されたJavaScriptを含むiframeをロードし、さらに不運な訪問者を悪用しようとするというのが典型的な流れだ。エクスプロイトに成功すると、Buzusファミリーのマルウェアのダウンロードへと導かれる。

  我々はすでにこのマルウェア・バイナリを、最新の「エフセキュア インターネット セキュリティ 2010」データベースでは「Trojan.Generic.2823971」と、他の製品では「Trojan.Win32.Buzus.croo」と特定している。

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

政府関連

セキュリティ関連団体

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

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

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

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

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