エフセキュアブログ

漏えい を含む記事

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


信頼できるインターネット:監視ソフトウェア企業からスパイウェアを買う人を誰が統制するのか?

 秘密が暴露されるのは、ハッカーがハッキングされたときだ。イタリアを拠点とする監視技術の企業Hacking Team社が、7月5日にハッキングされた。ハッカーたちは内部資料、ソースコード、メールを含む400GBのtorrentファイルを一般に公開した。これには顧客のリストも60件近く含まれている。

 同社は圧政国家との取引を公式には否定しているが、このリストにはスーダン、カザフスタン、サウジアラビアといった国家も載っている。また漏えいした資料からは、東南アジア地域のシンガポール、タイ、マレーシアの政府当局が、RCS(Remote Control System)いう名前の最先端のスパイウェアを購入していたことが強く示唆された。

 Citizen Lab(訳注:カナダ、トロント大学内の研究所)の研究者によると、このスパイウェアは並外れて深く侵入する。モバイル端末上のマイクやカメラを起動し、Skypeやインスタントメッセージを傍受し、収集した情報からC&Cサーバへと追跡されるのを回避するために、プロキシサーバによる匿名化ネットワークを使用するのだ。

 Pastebinに投稿された顧客リストの画像に基づくと、このソフトウェアはマレーシアではマレーシア汚職防止委員会、MI(Malaysia Intelligence)、首相官邸で購入された。

hacking_team_client_list (86k image)

 medium.comに投稿された、漏えいした請求書の追加画像では、このスパイウェアがMiliserv Technologies (M) Sdb Bhdという社名の、現地のマレーシア企業(マレーシア財務省に登録)を通じて販売されたことが示されている。同社はデジタルフォレンジック、インテリジェントな収集、公安サービスの提供に特化している。

hacking_team_hack_1 (95k image)

hacking_team_hack_2 (72k image)

 首相官邸が監視ソフトウェアを必要とする理由は、謎のままだ。よく聞いてほしい。プロ仕様のスパイウェアは安くはない。ライセンスのアップグレードには40万マレーシア・リンギット(約1,300万円)かかるし、保守の更新には約16万マレーシア・リンギット(約500万円)を要する。

 マレーシアの非主流派のメディアによるこの事件の報道によれば、2013年の総選挙へ向けて(検出数が)急増する中でマルウェアFinFisherが検知されたが、マレーシアの政府機関はおそらくこの発見の前から当該スパイウェアを使っていたということだ。

 偶然にも、マレーシアは年次のISS World Asiaという見本市の開催地に頻繁になっている。ここでは、法執行機関や、通信会社、政府の担当者に対して、企業が「合法的な」監視ソフトウェアという武器をプロモーションしている。2014年の同イベントにHacking Team社は参加しており、共同で最大のスポンサーとなっていた。

 MiliServ Technologiesは現在のところ、クアラルンプールで次に開催される2015 ISS World Asiaに関与している。同イベントに参加するには招待が必要だ。Hacking Team社が今年も参加しているかを確認したいかもしれないが。


Post by – Su Gim

BabarはBunny?

Babar-cartoon-wallpaper
 この頃、Babarというマルウェアの奇妙な事件にまつわる研究や報道が相次いでいる。SNOWGLOBEと称される高度な諜報作戦の疑惑に関わりがあるマルウェアだ。

 フランスのルモンド紙がメディアとして初めてSNOWGLOBEを取り上げたのが約1年前だ。他でもないエドワード・スノーデンその人が漏えいした、SCECの極秘スライドについての記事を掲載した。一連のスライドの中には、内部的にBabarと自称する、フランス発祥のマルウェアに関して数々の主張がある。セキュリティコミュニティがBabarに似たサンプルを掘り下げるまでに、長い時間はかからなかった。[1] [2] [3]

 Bunnyや、BunnyとBabarとの繋がりについて、我々ははっきりとは説明できない。BunnyとEvilBunnyについては我々は多くの研究成果を得ており、すでにセキュリティコミュニティによく知られた存在だ。しかしBabarのこととなると、謎の多い極秘スライドのスクリーンショットしか持ち合わせていないのだ。しかしながら、SCECのスライドで述べられているとおり、BunnyとBabarには十分に相関関係があり、同じ諜報ツールファミリーに属している、と高い確度で言えるだろう。

事実1。 双方の作戦は、共に主として2010〜2011年に活発であったように見受けられる。これはBunny PEのヘッダのタイムスタンプと、CSECのスライドが2011年からである点より明白だ。

事実2。 前述のスライド内で記載されたUser-Agentのタイプミスと同じものが、一部のBunnyのサンプルに存在する(MSIEの代わりにMSIと記述。SCECのスライドのSNOWBALL Beaconsを参照のこと)。偶然の一致のようには見えない。

MSI (81k image)

事実3。 Bunnyとつながりのあるサンプルの1つがntrass.exeという名前のファイルをドロップするが、SCECのスライドでも当該ファイルに触れている。偶然の一致のようには見えない。

事実4。 Bunnyファミリーについての最新の知見では、内部プロジェクトの名称としてBabar64というものが明らかになった。[2] [3]偶然の一致のようには見えない。

事実5。 バニーも小象(訳注:Barbarは「ぞうのババール」という絵本の主人公)も、かわいくてフワフワな小さな動物だ。APTの世界では、まったく一般的でないが。

 また、このマルウェアはフランス発祥であると、高い確率で言うことができる。Bunnyのサンプルの一部では、HTTPヘッダでAccept-Language: frを用いている。また内部のネーミングで本当におかしな決定をしている。たとえば、タスクのスレッドを「hearer」としている点だ。 [1]英語でのソフトウェア開発の世界では、こうした種類のタスクにはたいてい「listener」や「monitor」といった名前が付けられる。「hearer」というのは、英語を話す開発者が必ずしも普通に使う単語というわけではない。英語のネイティブスピーカーでない人が、使い慣れた言語から文字面どおりに翻訳したような感じがする。一例を挙げると、フランス語の「auditeur」は「auditor」「listener」「hearer」のように訳される。

 しかし、この繋がりについて言えないこともある。最初に、スライド自体に、特定の当事者の名前は挙がっていない。つまりフランスの諜報機関という噂は、現時点で確固とした証拠に基づいているというわけではないのだ。Bunnyがプログラミング言語Luaを使用して機能を拡張しているという事実も、結局のところ混乱を生むことになる(Flameを覚えているか?)。さらに、この点には触れねばならない。帰属についての興味をそそる部分はすべてスライドにある。つまり、それについて一次証拠は何も手に入れていないのだ。またBunnyの複雑さの度合いについて、考慮すべき点もある。TurlaやEquationのような、際立った水準のAPTとはかけ離れているのだ。ただし、もちろんSNOWGLOBEの背後の関係者のレベルが低いことを意味するわけでない。この関係者達がなぜ、暗闇の中で光るクリスマスツリー並みに分かりやすいツールを作ったのか、不思議である。

 ハッシュ:

   •  2c678924a3d4307644208b199afd20940c058b62
   •  c923e15718926bb4a80a29017d5b35bb841bd246

ボブとアリスがMacのOPSEC問題を発見

 これは本当の話だ。ここでは氏名を差し替えているが、関係者の正体については関係ないためだ。


Mac files on a USB drive as seen via Linux

 Macユーザとファイルを交換したことのある人なら誰でも、Mac OS Xがさまざまな「隠し」ファイルをUSBドライブにコピーすることを知っている。

 興味深い部分はここからだ…。

 ボブはこれらのファイルの機能について、疑問に思った(で、なんでこんなに多いのだろう?何をするものだろう?)。ボブはリバースエンジニアリングを行い、当然ながらバイナリエディタでファイルを分析してみた。そしてその時のことだ。メールアドレスや題名の行、一部のケースではアリスのメッセージの冒頭の文が「.store.db」というファイルに含まれていることをボブは知った。

 ボブは自分のUSBドライブにそのようなデータやメタデータがコピーされたことに驚き、さらに調査して次のことが分かった。こうした.dbファイル群を参照するように特別に設計されたフォレンジックツールを使うと、これらの情報を見ることはできないのだ。標準的な見方では「.store.db」は「store.db」と同一のように見える。バイナリエディタで見た場合のみ、.store.dbに埋め込まれた、漏えいした情報が明らかになる。つまり通常のフォレンジックツールではまったく分からないのだ。

 当社ではボブのUSBドライブを調査し、絶対にそこにあるはずのないデータが.store.dbファイルの中にあることを確認できた。当社のMacコンピュータで問題を再現することには成功していない。アリスや彼女のコンピュータへアクセスできないので、推測することしかできない。データは未知の設定によって漏れた可能性も、サードパーティ製のソフトウェアによって漏れた可能性も、マルウェアによって漏れた可能性もある。

 懸念すべきは以下だ…。

 自身がレポーターだと想像してみてほしい。誰か他の人のUSBドライブに漏えいする、あなたの情報ソース宛てのメールについてのデータを欲しいと思うだろうか?もちろんお断りだ!一部の国では、今回のようなOPSECの不具合で、簡単に人々が刑務所行きになる。

 当社では通常は未知の件については書かない。しかし特に今回のケースでは、誰かが問題の根源を特定できることを期待して、記事にした。そして誰かが解明したら、このポストを更新する。

追記

 Mark Janssenは、自身のデータやメタデータがUSBデバイス上のSpotlight検索に関連するインデックスファイルで見つかることを確認した。その後彼はアップル社の製品セキュリティチームへメールを送り、「Apple is aware of the issue and is investigating(アップルは問題を認識、調査している)」と報告を行った。

  Macユーザは、システム環境設定、Spotlight、プライバシーと辿って、Spotlightで検索インデックスの作成を回避できる。Nicholas Ptacekがこの点を指摘した。

 残念なことに、Spotlightの検索インデックスの作成を無効にすることでUSBドライブへのデータの漏えいを防いでいる間は、この設定によりMac自体の機能が制限される。Nicholasはここに掲載されている情報により、他のワークアラウンドが提示される可能性があることを示唆している。

 Jimmy Wall博士は、ドライブから「ジャンク」を自動的に消去する機能を持つ、CleanMyDriveというツールを推奨している。このアプリはMac App Storeで入手できる。

 あなたのSpotlightのインデックスで、隠ぺいされているのが何か見たい?

 Go to the top level of an Indexed volume, and check .Spotlight-V100/Store-V2/[RANDOM HASH]/.store.db.(インデックスされたボリュームのトップレベルに行き、.Spotlight-V100/Store-V2/[RANDOM HASH]/.store.db.を確認しよう)

 注記:当社のアナリストは、いまだ自分のMacからUSBデバイスに「悪い」.store.dbファイルをコピーできないでいる。そのため、当研究所のMacと、Janssenの言う世のMacとの間には、知られざる変数がまだある。

NCR社製ATMのAPIドキュメントが百度(バイドゥ)で公開される

 最近起きた、マレーシアにおけるATM(現金自動預け払い機)の侵害では、いくつかの地元の銀行に大混乱を巻き起こした。報告されたところでは、おおよそ300万マレーシア・リンギット(約100万米ドル)が18台のATMから盗まれた。犯人がどのような方法で犯行を行ったのか詳細な情報はないが、地元のニュースで報じられたことによると、「ulssm.exe」というファイル名のマルウェアを犯人がインストールしたと警察は述べているとのことだ。このマルウェアは侵害されたATMで見つかった。ファイル名からすると、問題のマルウェアはシマンテック社が最初に発見した、「PadPin」として知られているものだと我々は考えている。このマルウェアに関する基本的な技術情報はこちらにある。マレーシアでATMのハッキングに使われたものとPadPinが同一のものであるかについて、我々には確信はない。しかしそれでも、当社にてPadPinのコードの分析を行ったところ、興味深い点が見つかった。

 当社のバックエンドである、サンプル集約システムをくまなく探し、すぐに前述のファイル名に関連するサンプルをいくつか特定した。このサンプルは典型的なWindowsコンピュータでは動作しなかったため、当社のサンプル自動分析システムは、当該サンプルが悪意のあるものと判定しなかった。このサンプルは、ATMやセルフサービス端末などWindows Embedded OSを実行するマシン上にあると思われるDLLライブラリを必要とするのだ。このDLLライブラリはXFS(Extension for Financial Services)と呼ばれる。

Malware import Extension for Financial Services library
画像:マルウェアはXFSライブラリをインポートしている

 コードの調査中、見慣れないAPIファンクション群を発見した。見たところ、上の画像で示したMSXFS.dll経由でインポートされるものだ。残念ながらマイクロソフトはこれらのAPIについて公式なドキュメントを提供しておらず、そのことがマルウェアのコードの理解を難しくしている。マルウェアコードのある部分に出くわすまで、疑問は続いた。前述のAPI群のうちの1つを用いて、ATMの暗証番号入力パッドとの通信チャネルの確立を試みる部分だ。基本的にその目的は、犯人が暗証番号入力パッドに入力したキーをリッスンし待機することだ。これは、シマンテックの記事で述べられている別のタスクを実行するためのものだ。言い換えると、マルウェアがサポートするコマンドは、暗証番号入力パッドで入力できるキーに限られる。たとえば、犯人が暗証番号入力パッドで「0」と入力すると、ATM自動機から現金の払い出しを始める。コードを分析しながら、我々は不思議に思い始めていた。暗証番号入力パッドのサービス名として何をAPIに提示すれば、プログラムが暗証番号入力パッドと通信できるようになるのか、マルウェアの作者はどうやって知ったのだろうか。これはもっともな疑問である。コード内で使われているサービス名は非常に独特なもので、マニュアル無しにサービス名を特定できることは、まったくもってありそうにない。

 そこで我々は、API名とサービス名を用いて、APIのマニュアルがないかWebで検索を行った。その結果は?百度に設置された専用の電子書籍のWebサイトにて、容易にマニュアルが見つかった。NCR社のプログラマ用のリファレンス・マニュアルのようだ。

WOSA/XFS Programer's Reference Manual

 マニュアル全体をざっと読んで、ATMとの通信を行うソフトウェアをどのようにプログラミングするかについて予備知識がない人にとっても、ATM自動機とやり取りをするプログラムを書くことは、お手軽になったと結論付けた。このドキュメントは、その上プログラマにコードのサンプルを提示するほど親切である。我々は偶然、次のことにも気付いた。マレーシアの銀行のATM自動機を標的にする件のマルウェアが、Windowsのスタートアップフォルダから「AptraDebug.lnk」というショートカットファイルを削除しようと試みている。それと同様に、感染したマシン上のローンチポイントのレジストリキー「AptraDebug」もだ。その目的はおそらく、マシン上で実行中のデフォルトのATMソフトウェアを無効化し、マシンが再起動する際にそれをマルウェアで置き換えることだ。このファイルとレジストリキーは、NCR APTRA XFSソフトウェアを参照しているように見受けられる。そのため当該マルウェアが、このセルフサービスのプラットフォーム用のソフトウェアを実行しているマシンのみを狙ったものと仮定しても間違いないだろう。

 結論として、PadPinの作者ではない何者かがこのドキュメントを漏えい、アップロードした可能性がある。そして、銀行の従業員で経験豊かなプログラマがこのマルウェアを書いたという説を排除してはならない。

 ドキュメントがインターネット上でいったん入手可能となったら、誰かがそれを閲覧したりダウンロードしたりするのを止めることは、現実的には不可能だ。しかし、こうした侵害が再び起こることを避けるために銀行が採用できる対策がある。USBやCD-ROMから直接ファイルを実行しないようにATM自動機を守ることは、もっとも単純な対応方法の1つだ。

Post by — Wayne

エフセキュア 法人向け製品でWindows Server 2003のサポートを延長

エフセキュア株式会社は、法人向け製品でWindows Server 2003のサポート終了後も一定期間サポートを継続いたします。

日本マイクロソフト社のオペレーティングシステム Windows Server 2003のサポートが2015年7月14日に終了します。開発元がサポートを終了したオペレーティングシステムを継続して利用することは、セキュリティやコンプライアンスの観点からみて大きな危険性があります。サポート終了後は、新たにオペレーティングシステムの脆弱性が発見されたとしても、セキュリティパッチが提供されることがないため、エクスプロイトを利用したハッカーやマルウェアの侵入、またそれに伴う情報漏えいの危険性がつきまとい、時間と共にそのリスクレベルは大きくなっていきます。しかしながら、Windows Server 2003は多くの企業で業務の基幹システムなどにも採用されており、サポート終了日の2015年7月14日までに全てを最新のオペレーティングシステムに移行させることは困難な状況です。

エフセキュアはこの状況を認識し、日本マイクロソフト社のサポート終了後も、Windows Server 2003にインストールされている法人向け製品に対し、延長サポートを提供することで、Windows Server 2003から最新のオペレーションシステムへのアップグレードの支援をいたします。なおこの延長サポートは、あくまでも上位のオペレーティング・システムへ一刻も早く移行するための経過処置であり、完全にセキュリティのリスクを回避できるものではありません。


Windows Server 2003向け延長サポート対象製品情報



  • サポートが終了したオペレーティングシステムを継続してご利用されることは、セキュリティリスクを抱えることになるため、早めにサポート対象のオペレーティングシステムへ移行されることを推奨致します。
  • セキュリティパッチが提供されず、脆弱性が修正されないままのオペレーティングシステムでは、エンドポイントセキュリティ対策製品でエクスプロイトから保護することが出来ない可能性があります。
  • サポート終了時点で、最新のサービスパックおよびパッチが適用されているオペレーティングシステムがサポート対象となります。
  • オペレーティングシステム自体に起因する不具合に対しては、弊社ではサポート対応できない場合がございます。

管理者達へ:Heartbleedの修正するときに設定基準を見直そう

 とにかくSSLの更新は必要なので、設定が最近の基準に沿っているかについても確認しようではないか。

 Heartbleedについてたくさんの大騒ぎがあったから、管理者ならすでに何をすべきか知っているだろう。

 1. 脆弱なバージョンのOpenSSLを使っているものをすべて特定する
 2. 最新バージョンのOpenSSLに更新する
 3. 古いプライベートキーとSSL証明書は漏えいした可能性があるので、新しいものを作成する
 4. 古い証明書を失効にする

 だがサーバの設定を触って、新しいSSL証明書を作成しなければならないのなら、証明書生成の設定やサーバの設定にも手を伸ばすことをお勧めする。HeartbleedはSSL/TLSの実装における問題だけではない。プロトコルを下手に選択したり、暗号方式が弱いと、Heartbleedのバグと同等に危険になり得る。

 OWASP Transport Layer Protection Cheat Sheet(Open Web Application Security Projectによるトランスポート層保護についてのチートシート)を一読することを推奨する。

 そしてボーナスポイントのチャンス!

 5. PFS(Perfect Forward Secrecy)を実装する。これは件のOWASPのチートシートの「Prefer Ephemeral Key Exchanges」というルールのところに記載がある。

 詳細については、EFEの「Why the Web Needs Perfect Forward Secrecy More Than Ever(なぜかつてないほどWebにPFSが必要なのか)」というポストを参照してほしい。

追記:

 もう1つ追加する。

 6. トランスポート層のセキュリティのみに依存してはならない。もしデータがクリティカルであるなら、実装において追加的な保護を用いる。

 一例を挙げるならYounitedだ。「How do I turn on advanced login authentication?(高度なログイン認証を有効にする方法は?)」というサポートの質問を参照してほしい。

younited's 2FA

 2要素認証だ。提供してほしい。お願いだ。

更新:

 プライベートキーの変更が当然必要なことや、古い証明書を失効にすることを明確にする記述を追加した。ありがとう。@oherrala.

政府とWebと監視

 Webがありふれたものとなったとき、政策決定者たちはそれを無視したり、重要でないと考えていたりした。その結果、オンライン上では自由が花開いた。人々はコンテンツを消費するばかりでなく、コンテンツを作った。

 しかし、とうとうインターネットがいかに重要か政治家や指導者も気付いた。そして他の目的、とりわけ市民の監視のために、インターネットがどれほど有用になり得るかにも気付いた。我々の世代における2つの重要な発明、インターネットと移動電話が世界を変えた。その一方、監視国家にとっては、双方とも結局はうってつけの道具となった。そしてそうした国家では、すべての人が罪を犯していると仮定される。

 米国の情報機関は外国人を監視する最大限の法的権限を持っている。我々の大半はアメリカ人にとっては外国人だ。つまり我々がアメリカを拠点とするサービスを使うと、監視下に置かれることになる。そして我々が使用するサービスの大半は、アメリカに拠点がある。

 計算能力やデータ記憶装置の進歩により、大規模な監視が可能になってきた。ただしこの進歩により、情報漏えいも起こし得るようになり、組織は不正行為を捉えようと悩まされ続けるだろう。Webの未来は、我々を監視下に置き続けたい一派と、そうした監視の性質を暴露したい一派との間で、均衡が取れないままだろう。両派それぞれがデータ革命を起こしているからだ。

 政府が我々を監視している一方で、我々が政府を監視していることを政府は知っている。


ミッコ・ヒッポネン

 このコラムはWired誌のWeb at 25 Special
で最初に発表された。Tim Berners-Lee、Jimmy Wales、Vint Cerf他による別のコラムも読んでほしい。

It looks like you're trying to redact a document...

 The New York TimesProPublicaThe GuardianはNSAおよびGCHQが標的を追跡するために、どのように「情報漏えいする」モバイル電話アプリを使ったかについて、たった今詳細な記事を掲載した。残念なことにNew York Timesから発表されたソースドキュメントのうちの1つは、適切に編集されていなかった。そして最終的な結果として、NSA職員の名前が開示されてしまった(NSAの標的についての情報も)。

It looks like you're trying to redact a document.

 情報が自由になりたいみたいだ…。

 このゴタゴタについての詳細はThe Daily Banterにある。

ポリスウェア:善か悪か

 マルウェアの状況は絶えず変化しているが、注目すべき変化の1つは、今日の悪玉が善玉になるかもしれないことだ。つまり、やつらが善人になると考えられるのだ。これをもう少し混乱しないように説明すると、当局はマルウェアの主要なプレイヤーの1つとなっており、アメリカの政府機関はすでに世界でもっとも大口のエクスプロイトの購入者なのだ。

 これにより、我々のような対マルウェア戦士にとって、昔ながらの倫理上の論点がかつてないほど重要になっている。ポリスウェアにはどのように対応すべきだろうか?この種のマルウェアは検知すべきか否か?エフセキュアの立場は明確だ。イエス。当社はどんな種類のマルウェアでも検知する。そしてノー。当局のポリスウェアのためにホワイトリストを持つことはしない。ポリスウェアをホワイトリストに登録する要求を受け取ったことはないし、もし要求されても拒否する。

 これには複雑な心境になるかもしれない。警察が公共の利益のために取り組んでいることに疑問の余地はないからだ。鉄格子の中に送られるべき危険な犯罪者が存在しているのだから、彼らに対して使える武器はなんでも使ってはいけないのだろうか?ポリスウェアをホワイトリストに登録するのを拒否することで、我々は彼らを保護することになっていないか?この問題についてもっと詳しく見ていこう。そうすれば当社の現行のポリシーに対し、別の選択肢が本当に存在しないことが分かるだろう。

 ポリスウェアをホワイトリストに登録することが、なぜアンチマルウェア・ベンダーにとって悪い考えなのだろうか?

  •  当局の権力は常に規定された地域に限られているが、当社のアンチマルウェア技術は世界中で使用されている。ポリスウェアが当該機関の管轄内で使用されているのかをスキャナエンジンが検証する、信頼できる方法はない

  •  いつでも正規の令状が容疑者を特定する。しかし当社のアンチマルウェア技術は全顧客一般に対するもので、ポリスウェアが正規の標的に用いられているのかを確認できない

  •  ホワイトリスト上のファイルに出くわした時に、誰がそれを制御しており、誰に報告を返すのかを当社のスキャナが検証できない。本当のマルウェアがそのようにしてすり抜ける可能性があるので、ホワイトリストは信頼できない

  •  我々には可能な限り顧客をマルウェアから守る義務がある。これは製品を販売する際に約束したことだ。ユーザに対し有効な令状があるケースにおいては、当然ながら例外を作ることはできる。しかし上述したように、その条件を検証することは不可能だ

  •  法律が国ごとに異なる。ポリスウェアが、ある国では合法だが別の国では違法な可能性がある。これは我々が調査するには複雑で実現不可能だ

  •  我々はどの国の権力に仕えるべきか?我々は自国の警察を信じることができるが、スペインや、ブラジル、カナダ、イスラエル、エジプト、中国、北朝鮮、そしてアメリカはどうだろうか?いくつかの国を適当に取り上げただけだが。こうした国にも仕えるべきか?諜報ツールを使うにあたって合法的な動機があることを、当社はどのように検証できるのだろうか?

  •  ポリスウェアが適切な令状がないまま間違って使われたり、あるいは法律に違反しているなら、当社は犠牲者に通知する道義的責任がある。そうでなければ、当社が犯行の一端を担うことになる

 つまり問題なのは、有効な令状が対象にするのはきちんと特定された個人またはグループである点だ。一方、ポリスウェアをホワイトリスト化すると、当社の世界中のユーザベース全体を対象とすることになる。これでは、ホワイトリストの欠点が利点よりも大きくなる

 しかし、これがすべてではない。ホワイトリストについて依頼するのは、政府機関にとってはさらに悪い考えだ、という理由を以下に挙げる。

  •  ホワイトリスト化するには、我々がホワイトリストにあるべきものを知っている必要がある。ポリスウェアは一意性があり信頼性のある識別機構を持っていなければならないことになる。マルウェアの主要な目標は可能な限り検知されにくくすることだが、こうした識別子のおかげでポリスウェアは検知されやすくなり、効果が薄くなる。ホワイトリストにもブラックリストにも使われ得るのだ

  •  ホワイトリストに登録するには、当局がポリスウェアプログラムについて外部に詳細を開示する必要に迫られる。これにより情報漏えいのリスクが高まる。またプログラムの存在そのものについて明らかにしなければならない。ホワイトリストを効果的にするには、当社に限らず多数のアンチマルウェア・ベンダーに持ちかける必要がある

  •  識別機能に信頼性を持たせるには、ホワイトリスト上でポリスウェアと当局とを結び付ける必要がある。これは、自身が当局によって監視されていると知る術を容疑者に与えることになる。さもないと、検知されたマルウェアへの感染が、マルウェアの脅威全体の中に溶け込んでしまい、容疑者へのアラートが必ずしも行われなくなる

  •  最近のニュースで取り上げられて明らかになったように、ポリスウェアの大部分は完全に法律違反であるか、少なくとも根拠があやふやだ。これについて外部に話すのは、当局にとっては賢明ではないということになる

 当局にとって最善の戦略は、不良少年と同じゲームに参加することだ。ポリスウェアを継続的に変更し、アンチマルウェア製品のレーダーをかいくぐって飛ぶようにする。当局のプログラムが捕捉されたら、これを変更して再度試す。標的は、通常のマルウェアの攻撃だと思うかもしれない。法執行機関には大量のリソースがあり、このゲームはうまく成功するだろう。また数多くの犯罪者にはおそらくそれほど技術的な知識はない。巨大で組織化されたギャングでさえ、適切に保護されたコンピュータなしで活動しているかもしれない。真実は映画とは異なる。悪党が世界的な麻薬の売人で、なおかつスーパーハッカーであるというようなことはない。ポリスウェアをホワイトリストに登録しなくとも、大半の犯罪者は標的として脆弱だ。

 ホワイトリストを用いないという当社のポリシーは既に古いものだが、今日ではこれがいまだかつてないほど重要になっている。古き良き時代には、警察は信頼に足るものであった。容疑者に対する令状や行動は、犯罪対策の合法的な部分であるように見えた。こうした伝統的な警察の行為が、まったく異なる動機によって秘密の大衆監視に融合されるのを見るのは悲しいことだ。悲しいだけではない。市民と当局の間に亀裂を生むことになり、恐ろしい。

 これを心に留めると、ホワイトリスト化に厳密なポリシーを適用するのが実際に唯一の選択肢だ、という理由が簡単にわかる。これは常に簡単な選択であったし、今も頭を使う必要はない。

Post by — Micke

Targetの侵害で「メタデータ」は漏えいしたか?

 数週間前にBrian Krebs氏が報じて以来、Target(米国の大手スーパー)のデータ侵害が継続的に大きなニュースになっている。

 そして当社のアナリストは関連するマルウェアのサンプルを調査した。非常に興味深いのだが、1つ知りたいことがある。もしあなたが妊娠していることをTargetが知っていたとしたら、それは今やハッカーも知るところなのだろうか?

 さかのぼること2012年2月、New York Times紙はCharles Duhigg氏による自著The Power of Habit(邦題、習慣の力)に基づく記事を掲載した。この記事の中で明らかになった、より興味深い物事のうちの1つは、Targetが非常に積極的に顧客の習慣のパターンを分析している点だ。

life events.

pregnancy prediction score

 言い換えると、Targetは大量のメタデータと顧客分析情報を生成している。

 またBloomberg,によれば、過去数年間に基本情報を提供した顧客が、今回のデータ窃盗の影響を受ける可能性があるとTargetが述べているとのことだ。提供?

 信用情報のために登録時に書き込んだようなデータのこと?あるいは、買い物のパターンをもとに学習したデータも「提供」に含まれる?今回の氏名や自宅住所を含む7千万件の記録の侵害は、販売用のマルウェアという観点よりもずっと深刻な情報漏えいを暗示している。

 我々はここ半年間にメタデータの価値をじっくりと学習した。

 漏えいしたクレジットカード番号については忘れてよい。Targetの分析は、アイデンティティの窃盗の金鉱となり得る。
 
Post by — @Sean

NSA:私たちは防衛に大きく偏っていた

 1月7日、Wired誌は「How the NSA Almost Killed the Internet(NSAがほとんどインターネットを殺した方法)」と題するSteven Levy氏の記事を掲載した。

 これは絶対に読む価値がある。

 何といっても、メディアへの情報漏えいに関するタスクフォースを率いるNSA幹部のRick Ledgett氏による以下の部分がある。

 「私たちは防衛に大きく偏っていた。」とLedgett氏は付け加えた。世界中のユーザに影響を与えてきた可能性のある、ある企業のソフトウェアの深刻な脆弱性をNSAが発見した事案について言及したときのことだ。「我々は数日間内部でこれについて議論し、米国政府全体また米国の大半にとって非常に重要な問題なので(当該企業の脆弱性を)開示することを決定した。広範な標的に対して、いつまでも続く好機ではあったのだが。」

Rick Ledgett

 えっ。NSAが責任を持って「ある1つの」深刻な脆弱性を開示した。えーと…。NSAに賞賛を!

 開示に関するこの事例の話は、数多くのゼロデイエクスプロイトや、(JMicron社とRealtek社の)盗まれた証明書で署名されたドライバー、MD5のハッシュ値の衝突、それにStuxnetDuquFlame経由で世界中に解き放たれたCPLINKの脆弱性をほとんど(かなり、どころではない)埋め合わせてしまうものだ。

 我々は防衛に大きく偏っていた?

 お願いだ。これは真面目くさった顔のテストを通らない、というだけのことではない。

Windows XPのサポート終了への対応

Windows XPのサポートが2014年4月9日に終了します。サポート終了後は、新しくオペレーティングシステムの脆弱性が発見されても、セキュリティパッチが提供されることがないため、エクスプロイトの侵入や情報漏えいの危険性がつきまとい、時間と共にそのリスクレベルは大きくなっていきます。
サポートが終了したオペレーティングシステムを継続してご利用されることは、セキュリティリスクを抱えることになるため、早めにサポート対象のオペレーティングシステムへ移行されることを推奨致します。

ところがIDC Japanの2012年秋の調査によると、Windows XPをインストールしている法人向けPCは40.3%にあたる1419万台と言われています。サポート打ち切りまでに、全てのWindows XPを最新のオペレーティングシステムに移行させることは現実的に困難と思われます。

エフセキュアはこの状況を認識し、マイクロソフト社のサポート終了後も、Windows XPにインストールされているコーポレート向けライセンス製品に対し延長サポートを提供することで、Windows XPから最新のオペレーションシステムのアップグレードをご支援することになりました。

詳細は弊社プレスリリースをご覧ください。
http://www.f-secure.com/ja/web/home_jp/news-info/product-news-offers/view/story/1008718/
バックナンバー
セキュリティ関連リンク
セキュリティ機関

政府関連

セキュリティ関連団体

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

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

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

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

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