エフセキュアブログ

メン を含む記事

トランプ政権のサイバーセキュリティ政策

2017年1月20日にドナルド・トランプ氏が大統領に正式就任し、約2ヶ月が経過したが、トランプ政権でのサイバーセキュリティ政策は一体どのようなものになるのだろうか? じつはサイバーセキュリティ政策についての大統領令は、すでにドラフトが上がっている。(PDF)

簡単にまとめた分析によると、この政策は、まず軍・インテリジェンス機関を含む各省でのセキュリティ対策状況を監査レビューし、現在は各省ごとに行なわれているサイバーセキュリティ対策をホワイトハウスの予算管理の元に横断的に一本化するといったもので、また学校で教えるサイバーセキュリティについて国防省と国土安全保障省がレビューするという項目もあるようだ。

とはいえ、トランプ政権のサイバーセキュリティ担当として選ばれたのはその分野の経験があるとは思えないルドルフ・ジュリアーニ元ニューヨーク市長であり、また2月中旬にサンフランシスコで開催されたRSAコンファレンスにはトランプ政権からは誰も顔をだしていないなど、トランプ政権のサイバーセキュリティに対しての本気度を疑問視する声もある。

さらに2月19日にはトランプ氏のウェブサイトがイラクのハッカーにより侵入され書き換えられるなど、トランプ氏自身でサイバーセキュリティ問題を経験することになったようだ。

また、トランプ氏は以前から使っているAndroidスマートフォンを大統領就任後も手放さず毎日Twitter投稿に明け暮れているが、この電話機もいつハッキング攻撃の対象に狙われてもおかしくない。

もし実際に政府レベルでのサイバーセキュリティのインシデントが起きた場合にトランプ政権が対応できるのかについても厳しい見方がある。さらに、スノウデンによるNSAのサーベイランス・プログラムが多数暴露された際によく公聴会に呼び出されていたDirector of National Intelligenceだったジェームズ・クラッパー氏は1月末で任期が切れているのだ。しかし少なくともクラッパー氏はサイバーセキュリティ脅威を通常のテロリズムより重視していたので、そのような問題の理解者がいないまま大統領令を出したところで、現実的に何ができるのだろうか。

さらに現在のトランプ政権の動きは、サイバーセキュリティだけでなく各種プライバシー情報を含むパーソナルデータの保護にも大きな影響を与えると思われる。トランプ政権が選んだFCC(連邦通信委員会)の委員長アジット・ペイ氏はテレコム企業出身で、ネット中立性に反対を唱えてきた人物だからだ。それを後押しするように、3月22日、共和党が多数派を占める米議会上院は、たった数カ月前の2016年10月にオバマ前政権のもとで成立したブロードバンドのプライバシー保護規則を撤回する決議を、50対48で可決したのだ。これにより、ISPやモバイルインターネット通信事業者が、運営するネットワークを流れる利用者のデータを、利用者の同意なしにマーケティング企業などに売ることができるようになるのだ。これは、EUで成立したパーソナルデータ保護法制度の「EU General Data Protection Regulation」と、さらに2018年に同時に施行予定の「EU ePrivacy Regulation」とも対立しうるはずで、そのため2016年に成立したEUとアメリカの間でのパーソナルデータ移動を認める合意である「EU US Privacy Shield」合意が反故になる可能性があると思われる。



実際のところ、トランプ政権のホワイトハウスは日に日に混迷状況をあらわにしているように見える。

当初の政権人事として国家安全保障担当大統領補佐官に選ばれたマイケル・フリン氏は、就任前に駐米ロシア大使と対ロシア制裁措置について協議した件が明るみに出たため、早くも辞任した。じつはドナルド・トランプ氏は大統領選挙前から、ロシアの犯罪組織のボスから工面してもらった金で破産を免れたといった話題が流れるなど、ロシアとの関係に疑惑が持たれている。

また選挙中からトランプ候補の戦略を担当していたスティーブン・バノン氏が大統領主席戦略官として政権参加した上、さらにトランブ氏により国家安全保障会議(NSC)へのメンバーとして選ばれたことが発表されると大きな波紋を呼んだ。バノン氏はトランプ氏の選挙戦略を担当する以前は、Alt Rightと呼ばれる新興右翼勢力のメディア「Breitbart」ニュースの元会長で白人至上主義や排外主義のヘイト記事を多数執筆していた人物であり、政府機能の経験はまったく持っていない。そして一部ではトランプ政権を裏ですべて操っているのはバノン氏であるとすら噂されている。

さらにこの選択では、今までの政権では国家安全保障会議に通常参加していたインテリジェンス機関の代表になるDirector of National Intelligence担当者と、軍の代表になるJoint Chief of Staff担当者を外した上で、トランプ氏はバノン氏を選んだ。インテリジェンス機関代表と軍の代表の参加しない国家安全保障会議は前代未聞といえるし、実際それで有事に際して何か有効な決定を行えるのかはまるで疑問だ。マイケル・マレン元統合参謀本部議長などもこのバノン氏の採用を激しく非難した。

またトランプ政権に失望したという声は、就任後すぐにCIAなどのインテリジェンス機関からも聞こえてきた。

そしてついに2月24日には、ホワイトハウス内部の報道官室での記者会見からCNN、BBC、AFP、New York Times、Los Angeles Timesなどの主要メディアを締め出すなど、トランプ政権はおよそ独裁政権しか行わないような行動に出た。

そしてトランプ氏が公の場での演説やTwitterへの投稿で繰り返す、感情のアップダウンの激しい見境のない不適切な言動は問題となりつつある。大統領に職務遂行能力がない場合の手続きを定めた合衆国憲法修正第25条第4項を使って政権内クーデターを起こしてトランプ氏を追い出し、元副大統領のマイク・ペンス氏が大統領代理を執務するという憶測すら既にでている。

アメリカメディア調査での3月のトランプ大統領の支持率は新たな最低レベルの更新で36%と言われ、現在のところは当面トランプ政権の行方は予測しても不透明なままとしか思えない。

Rakuten Global CISO Summit

 みなさん、こんにちは。Rakuten-CERTの福本です。
 先日、楽天初のRakuten Global CISO Summitを開催しました。今回はそのイベントの共有をしたいと思います。実は昨年、楽天グループ全社においてCISOの任命を義務づける新たなポリシーを策定し、本社CISO及び子会社CISOを数十名任命しました。これは楽天グループの重要なディレクションで、セキュリティガバナンスの強化は経営課題であり、そして僕らのセキュリティが次のステージに向かっていることを意味しています。そして、今回、全てのCISOが集まり、Rakuten Group CISO communityをスタートさせることが出来ました。このイベントを通じて楽天グループ全体のセキュリティにとっての大事な一歩が踏み出せたのかなと思います。
summit_logoDSC_8251DSC_8249fukumoto

 2日間の盛り沢山のセッションで構成されたCISOサミットですが、豪華なゲストスピーカーにもご登壇頂きました。OWASPでも有名なTobias GondromさんとJerry Hoffさんからは大変参考になる最新のセキュリティトピックやセキュリティマネジメントに関するお話を頂き、また、3人でパネルディスカッションも出来て、とても刺激的なセッションになりました。また、各社CISOからの最新の取り組みやチャレンジを共有してもらったり、セキュリティ改善のアクションアイテムを決めるワークショップを実施したり、CISO向けのセキュリティトレーニングセッションを提供したり、大変実りの多いイベントになったと思います。
 
P2090288P2090241booth3workshop

 最後に、CISOという仕事には相当な覚悟がいるかなと思います。No upside, nobody will do it for you, your responsibility. その覚悟を背負って、組織のセキュリティのためにリーダーシップを発揮するということは並大抵な事ではないと思います。何を大義名分にしてCISO業務を邁進するか。本気でセキュリティをやる上で、そこは大事なポイントだと思います。

IoTはどこで作られているのか?

深圳(Shenzhen)は香港から電車で45分の中国国境内のきわにある「ハードウェアのシリコンバレー」とも呼ばれる経済特区の都市だ。人口は1500万人とも2000万人ともいわれ東京よりも大きく、高層ビルは278本もあり中国第4位の大都市となっている。
そして Tencent, Huawei, DJI, OnePlus, ZTE, Coolpad, Gionee, TP-Link, Beijing Genomics Instituteなどのエレクトロニクス、テレコム、バイオなどのハイテク企業が集中し、华强北(Huaqiangbei)という秋葉原の100倍はある巨大なエレクトロニクスタウンがある。iPhone他のエレクトロニクス製造で拡大してきた都市なので、電子部品、プリント基板製造、アセンブリー、プラスティック成形、金属加工などの企業が群をなして営業している。また好調な経済のため、生活物価は東京とたいして変わらなくなっている。

この深圳についてのビデオドキュメンタリー "Shenzhen: The Silicon Valley of Hardware" をWired UKが制作し、6月に公開された。全部で1時間強になるこのシリーズは、深圳でのIoTとMakersの興味深い最新の動きを取り上げている。

Part 1

Part 2

Part 3

Part 4

特にPart 2は、IntelがIoT向けに一昨年発表したフルPCの機能をSDカードサイズにまとめた「Edison」チップのディベロッパーフォーラムが4月に深圳で開催された場面から始まる。明らかにIntelは深圳がIoT開発の中心地のひとつになると踏んでいる。またIntelが食い込もうとしているIoT開発で、他に使われているのはArduinoやRaspberry Piなどで、ほとんどLinuxやオープンソース・ソフトウェアで動いているものが多い。
Intel Edison

深圳にはハードウェア開発に関わる大きな外国人コミュニティができていて、ヨーロッパやアメリカから来て深圳に住み着いてエレクトロニクス・ハードウェア開発のヒジネスを運営している人達も多い。一説ではシリコンバレーでのハードウェアも3割は深圳で作られていると云われるほどだからだ。

その一つ、HAXはハードウェア・スタートアップ企業のための世界最大のアクセラレーターだ。

当然地元の中国の人達が始めたハードウェア開発のサポートやブローカービジネスも多数ある。Seeed Studioはよく知られているものの一つで、日本にも窓口がある。

そして半田付け用具や測定器、金属加工器具、レーザーカッター、3Dプリンターなどを揃えた、ハードウェア自作派やスタートアップ向けのMaker Spaceと呼ばれる場所がいくつも出来ている。

深圳の動きには当然に日本でも注目している人達がいて、ニコニコ技術部の有志が一昨年から深圳の視察ツァーを開催している。その報告をまとめた「メイカーズのエコシステム」という書籍が4月に発売された。

このメイカーズというのはMakersのことで、O'Reillyが出している「Make」という自作派向けの雑誌から派生して開催されている「Maker Faire」というイベントなどで自作のハードウェアを見せたり販売したりする人達のことを指す。先週8月6,7日には「Maker Faire Tokyo」が東京でも開催されたばかりだ。
Maker Faireは深圳でも開催されている。

これらのインフラが出来ていることで、深圳発のハードウェア・スタートアップ企業が多数出現している。そして彼らのかなりがIoTを手がけている。Intelが深圳がIoT開発スタートアップの中心地のひとつになると考えるのは当然の流れだ。

クラウドファンディングサイトのKickstarterやIndieGoGoなどを眺めても、IoTカテゴリーに入るプロジェクトが多数見つかるし、それらはほとんどスタートアップ企業のことが多い。ところが日本では、特に政府関係者はIoT製品は既存の電機メーカーが作ると考えているのではないか? 7月にIoT推進コンソーシアムと経済産業省と総務省が共同で「IoTセキュリティガイドライン」を発表した。しかし、製品化に脇目も振らずに邁進するスタートアップ企業がこのようなややこしい資料を気にかけるとは考え難い。
さらにそれ以前に、日本でだけこのようなIoTセキュリティガイドラインを作ったとしても、IoT開発の主力地が深圳など海外にあるならまったく影響力は期待できないだろう。

さよならFLASH!第2.5弾 MICROSOFT EDGEの「CLICK TO FLASH」

FirefoxのFlashサポート縮小について記事を投稿したところ、Edgeブラウザに関する4月のMicrosoftの発表について指摘するコメントがいくつか寄せられた。これは、Edgeブラウザも「Click To Flash(クリックしてFlashを再生)」方式に変更されるというものだ。発表によれば、ウェブページの中心に配置されていないFlashプラグインは自動的に一時停止されるようになり、ゲームや動画などのコンテンツはこれまで通りに実行されるという。そうしたEdgeの変更はWindows 10のアニバーサリーアップデートで提供される。

もちろん、4月の時点でこのニュースには注目していたし、MicrosoftおよびEdgeチームの英断に対しては賛辞を送りたいと思っていた。

ms-edge-logo
 Microsoft Edgeのロゴ(画像の出典元: microsoft.com)

全文はBusiness Security Insider 日本語版で。 

#Citizenfour が6月11日から日本で公開 - スノウデンへの密着ドキュメンタリー

元NSA契約業者職員だったエドワード・スノウデンに密着取材したドキュメンタリー作品「Citizenfour」が6月11日から日本でもやっと公開される。「Citizenfour」2014年アカデミー賞のベスト・ドキュメンタリー賞として選ばれたことは1年ほど前にエフセキュアブログにも書いたが、アメリカでの初公開から1年半遅れの日本公開となる。
とはいえ6月4日にはJCLUのイベントでネット経由で出演し日本でのメディア報道の自由の状況に警告を発したり、 2013年の暴露以前にNSA内でも問題を指摘しようとしていたことがVICE Newsのアメリカ情報公開法に基づくNSA内部資料入手により明らかになるなど、スノウデンの告発による衝撃はいまでも続いている。 
JCLUイベント  https://www.youtube.com/watch?v=fL3x_9PHrWY 
Exclusive: Snowden Tried to Tell NSA About Surveillance Concerns, Documents Reveal 

日本版トレイラー

(しかし相変わらず日本ではこの映画も含め「元CIA職員」という肩書きが使われ、スノウデンが「元NSA契約業者Booz Allen Hammilton職員」だったことが歪められている)
劇場情報はこちらから http://gaga.ne.jp/citizenfour/info/?page_id=20 
 

スキャンエンジンの現状はどうなってる?

 当社のスキャンエンジンはいかに動作するのか。シグニチャエンジンや他の種類のスキャンエンジンとの違いは何か。人々(技術ジャーナリストや製品レビューを行う人など)が頻繁にこのような質問を我々に投げかける。実際に、そうした質問を先週尋ねられたばかりだ。それなら、この話題について、深く掘り下げようではないか…。

 シグニチャベースのスキャンとは、対象のファイルを判定すべく、ファイル全体のハッシュやファイルの一部のハッシュ群をリストやデータベースに照らし合わせる動作を指す。1980年代、アンチウィルスはおおよそここから始まった。1990年代初頭に多様なマルウェアが出現し、シグニチャベースの手法からより複雑なファイルスキャンエンジンへの進化に拍車をかける触媒となった。

Brain. On a floppy.
1980年代における、新たなサンプルを受け取る方法

 エンドポイントの保護ソリューションには、ファイルスキャンエンジンが含まれる。しかし実際にはファイルのスキャンだけを行っているわけではない。メモリの断片やネットワークストリームといった、あらゆる種類の入力バッファがあればスキャンする。

 ファイルスキャンエンジンは非常に洗練されてきている。アーカイブをトラバースする仕組みを持ち、複数のファイルフォーマットを解析し、静的および動的な解凍や逆アセンブリを行い、スクリプトと実行形式のファイルの双方の実行をエミュレートする。現在の検知は実際のところでは複雑なコンピュータプログラムに過ぎず、クライアント上で直接的に複雑なサンプルの分析を行うように設計されている。最近の検知では、数千の、いや数十万のサンプルを捕捉するように設計されている。かつての日々の、サンプルごとにハッシュ1件というアプローチとは程遠い。

 ご想像のとおり、洗練された検知を構築するには時間を要する。最終的に顧客にリリースするまでに、アナリストはサンプルを収集して精査し、コードを書き、テストを行わなければならない。一方で、かなりシンプルなシグニチャベースの検知は、自動的に簡単に生成することが可能だ。新たなサンプルがやってくると、一連の静的および動的な分析ツールやルールエンジンにかけられる。判定をすばやく配信するためだ。

 それゆえに、新たな脅威が出現した場合、アナリストが適切な検知コードを書く作業を行っている間に、バックエンドの自動ツールが作動し、早期にサンプルをカバーする。今日ではソフトウェアが迅速かつ簡単にインターネット経由でハッシュを参照できるため、こうしたシンプルな検知はローカルのデータベースの更新の一部として配信されることさえない。このクラウド参照メカニズムは、脅威がいつ出現するかに関わらず、出現した脅威から非常に迅速に顧客を保護できるようなるという点でメリットがある。

しかし話はこれで終わらない

 最近のすべてのエンドポイント保護ソリューションでは、複数のメカニズムを用いて、顧客を継続的に保護する。今日のエンドポイント保護がどのように作用するかについて、以下に非常に簡単な概観を示す。

  1. URLのブロック。エクスプロイトキットや他の悪意あるコンテンツを保有するサイトにユーザが晒されないようにすれば、さらなる保護手段の必要性がなくなる。当社では、この大部分をURLおよびIPのレピュテーションクラウドへの問い合わせで実現している。スパムメールのブロックや、メールフィルタリングもここで行われている。
  2. エクスプロイトの検知。エクスプロイトキットを保有するサイトにユーザがどうにかして訪れた上に、脆弱性のあるソフトウェアを実行しているのなら、脆弱なソフトウェアを悪用しようとする試みは、当社のビヘイビア監視エンジンによってブロックされる。
  3. ネットワークスキャンとアクセス時のスキャン。ユーザがメール経由またはダウンロードで悪意あるファイルを受け取ったら、ネットワーク上で、またはディスク書き込み時にスキャンが行われる。ファイルに悪意があることが判明すると、ユーザのシステムから削除される(瞬時に、隔離するために)。
  4. ビヘイビアベースのブロック。仮にそうした悪意あるオブジェクトに対するファイルベースの検知が存在しないとしたら、ユーザは悪意あるドキュメントやスクリプトやプログラムを、開いたり実行するかもしれない。この時点で、悪意ある振る舞いは当社のビヘイビアエンジンによってブロックされ、またもやファイルが削除される。結局のところ、マルウェア配信メカニズムの大半はビヘイビアに基づき簡単にブロックされるのだ。ほとんどの場合、当社が新たな脅威を見つけたときには、それが用いているメカニズムに対応するロジックをすでに大昔に追加している。

 ディスクを研磨するかのように予定されたスキャンを夜実行する昔のアンチウィルスソフトウェアが、現在使われている最新世代のエンドポイント保護へと進化してきた。最新の脅威に対し、エンドポイントを保護する最善の方法の1つは、そもそも被害者と脅威が出会うのを回避することだ。これに失敗しても、複数方面からのアプローチを用いて攻撃の媒介をブロックすることで、その場で攻撃を阻止するための複数の機会があることになる。

 ファイルスキャンとは、「アンチウィルスベンダー」がエンドポイントの保護に用いている多数のメカニズムの中の1つに過ぎない。エクスプロイトの検知およびビヘイビアによるブロックの双方により、実際にあった攻撃の媒介からたびたび守ることができているため、わざわざ(たとえば静的なシグニチャなど)ファイルベースの検知を追加しないことも多い。そして覚えておいて頂きたい。1日の終わりに、常に我々は現実世界の脅威に対して当社の保護コンポーネントの試験を行っている。製品の個別の部分だけでなく、製品全体を用いてだ。

久々に確認、埋め込みオブジェクトの悪用した攻撃

3月頃から埋め込みオブジェクトを悪用した攻撃メールをちらほら見かけます。
Outlookユーザを狙った攻撃と推測され、Outlook 2010より古いバージョンなどでは添付ファイルのコピーをそのまま保存することができません。ドラッグ&ドロップでは、偽装アイコンの画像ファイルのみが保存されることになります。そのため、標的ユーザはファイルの内容を確認するためについクリックしてしまうようです。

添付ファイル

なお、Outlook 2013からのバージョンでは埋め込まれたオブジェクトのコピーを保存することができます。取り出してみると、おなじみの(?)ドキュメントファイルを装った実行ファイルであることがわかります。

添付ファイル1

ただ、埋め込みオブジェクトであるためか若干状況が異なります。EXEファイルでは先頭にあるはずのMZシグネチャが中央付近に確認できます。その上部には埋め込んだドキュメントファイルのパスが記述されています。つまり、単純にファイルシグネチャのみでファイルの種別を判定し、解析の実行有無を決定している類のセキュリティツールでは実行ファイルであることが認識できず、該当メールを見逃してしまう可能性があります。
#現在、そのような製品があるかは未確認です。昔あったような・・・。

Hex Editor


埋め込みオブジェクトを利用した攻撃は以前から存在しているものですが、APTで利用されたものは久しぶりに見ましたので報告させて頂きました。社内のサイバーセキュリティ訓練・演習や啓発活動に使ってみてはいかがでしょうか。



TeslaCryptの要約

 2年前、ランサムウェアについての一連のブログ記事を公開した折には、活発なランサムウェア・ファミリーは一握りしかなかった。しかしながら今年は、ランサムウェアがサイバー犯罪者達を熱狂させる最新の流行マルウェアとなった。

 そのため、我々は当社の若きTET(訳注:後述)の生徒Miroに、ランサムウェアの歴史、とりわけTeslaCryptの歴史についての短いレッスンを受けさせようと考えた。なぜならTeslaCryptは、いまだに流行っている、比較的「古い」ランサムウェアの1つだからだ。

 以下は、その彼の研究結果だ。


 TeslaCryptはランサムウェア・ファミリーに分類される。ランサムウェアが被害者のコンピュータに侵入すると、被害者のファイルを暗号化する。サイバー犯罪者たちが求めるもの、つまり金を得るまでは、暗号化したファイルはそのままだ。

 TeslaCryptは支払い方法としてBitcoinに加え、初めてPayPal My Cash Cardを追加したものの1つだ。

 TeslaCryptは通常のドキュメントや画像のファイルを暗号化するだけでなく、ビデオゲーム関連のファイルも標的にすることで知られるようになった。とりわけCall of Duty、Minecraft、League of Legends、Steamに関連付けられたファイルだ。

 これまでのところ、TeslaCryptには4つのバージョンがある。2015年2月に最初に発見され、最新のものは2016年3月に特定された。

 最初のバージョンでは、RSA-2048を用いていると称していたが、実際には暗号化方式としてAESを使用していた。暗号化されたファイルの名前には、.ECCという拡張子が付けられた。

Your presonal files are encrypted!

What happened to your files?

 TeslaCryptの2つ目のバージョン、つまりTeslaCrypt 2.0は、2015年7月辺りに出現した。同バージョンでもやはりAESを用いているのにも関わらず、RSA-2048のアルゴリズムを採用していると主張していた。暗号化されたファイルの拡張子は変更され、たとえば.VVVや.ABCといったものになった。身代金の要求も変わった。HTMLページ、テキストファイル、壁紙またはフォトギャラリー中の画像の3つの異なるフォーマットで提示される。この2つのバージョン間の違いは、文章だけでなく脅迫メッセージの外観に見て取れる。読みやすくするために、タイトルと章が追加された。新たな身代金の要求では、支払いまでの残り時間のカウントダウンも削除された。

TeslaCrypt 2 - What happened to your files?

 TeslaCrypt 3.0は2016年1月に発見された。TeslaCrypt 3.0では暗号化にRSA-4096を用いていると主張しているが、やはり依然としてAESを使用している。しかしながら、このバージョンでは暗号キー交換アルゴリズムは異なるものを使用しており、暗号を破るのが一層困難になっている。このバージョンでのもう1つの違いは、暗号化されたファイルの拡張子に.MP3、.XXX、.TTT、.MICROが使用される点だ。HTMLの脅迫メッセージはTeslaCrypt 2.0と同じだが、テキストファイルのフォーマットが以下のように多少変更になった。バージョン3.0ではGoogle Translateへのリンクが含まれており、「What does this mean」という行が削除された。

TeslaCrypt 3 - What happened to your files?

 TeslaCrypt 4.0はTeslaCryptランサムウェア・ファミリーの最新版だ。これは2016年3月前後に初お目見えした。同バージョンとそれ以前のバージョンとの最大の違いの1つは、4.0では暗号化されたファイルの拡張子に.VVVや.MP3といったものを使わないことだ。また、以前のバージョンでは、4GBを超えるファイルを暗号化する際に破損してしまうというバグがあった。最新バージョンではこのバクは修正されている。被害者のコンピュータに関するさらなる情報を探ろうと試み、犯罪者のネットワークへ情報を送信することもする。

 TeslaCrypt 4.0もやはり暗号化にRSA-4096を用いていると主張しているが、依然としてAESを使用している。身代金の要求の外観には変化はないが、TeslaCrypt 4.0と3.0で中に書かれた文章には相当な数の違いがある。たとえば3.0では「What happened to your files」と書かれているが、4.0では「What’s the matter with your file」だ。TeslaCrypt 4.0ではまた、バージョン2.0から「What does this mean」という行を戻している。

TeslaCrypt 4 - What's the matter with your files?

その他の情報源:


記述および調査:Miro Ikaheimonen


 著者によるメモ:私はフィンランドのヘルシンキにいる中学生で14歳です。エフセキュア社で5日間のTET(Tyoelamaan tutustuminen、訳注:フィンランドのインターンシップ制度)プログラムを行っている最中です。なぜ、エフセキュアを選択したのでしょうか?通信技術に興味があったのと、学校のプロジェクトでミッコ・ヒッポネンにインタビューする機会もあり、エフセキュアのマルウェアとの戦いに興味を抱くようになったためです。ここでは楽しい時間を持ち、マルウェアについての新しい内容をたくさん、特にランサムウェアとそれと戦うことについて学びました。

Miro

インターネットの現状についてのデータマイニング

 当地ヘルシンキにあるアールト大学では、毎年ソフトウェア・プロジェクトの演習を2〜3年生に向けて開催している。この演習の考えは、リアルな目的、リアルな顧客、リアルな締め切りがあるリアルなソフトウェア・プロジェクトの作業を学生が味わえるようにすることだ。演習は初秋に始まる。学生がチームを組み、地元企業から提示される一連のプロジェクトの中から選択する。プロジェクトの作業は10月下旬に始まり、翌年の4月中旬まで続く。演習の最後には、最良のプロジェクトが3つ選定され、この3つのチームが最終決戦のデモで戦う。そして1チームが勝者となる。今年はエフセキュアが後援するチームが、優勝トロフィーを4月19日に授与されて、持ち帰った。

The winning team
アールト大からの当社チームが勝利を祝っているところ

 今回は16チームが形成され、42のプロジェクトが提案された。エフセキュアの提案は「インターネットの現状についてのデータマイニング(DMSI、Data Mining The State Of The Internet)」という名称なのだが、当社のセキュリティクラウド部門の長Ville Lindforsが提出した。熾烈な争いであったが、学生チームの1つが当社プロジェクトを選択した。

 このプロジェクトの目的は、AWS(Amazon Web Services)サービスを用いて、データマイニングのフレームワークを開発することだ。エフセキュアはこのフレームワークを使って、Whoisのデータに基づいてインターネットドメイン同士の接続、相関関係、依存関係を分析することになっている。ここでは、データマイニングの技術が広範に用いられている。このプロジェクトで我々が達成したかったことの例を以下に挙げる。

  • 既知の悪意あるドメインと、ネームサーバを共有するドメインの発見
  • 未知の、害を及ぼすインターネットサイトの検知
  • 新たに登録されたドメインのレピュテーション(評判)を自動的に予測する機能
  • 未知の潜在的なフィッシングサイトの発見
Data Science
最終的に構築したもの

 今回のプロジェクトで作業したチームには7人が参加しており、うち1名はこのラボで働いている。またプロジェクトの期間中、チームをサポート、指導する者がいた。何かにつけ手助けした者を以下に挙げる。

  • Jouni Kuusistoはアールト大の理学修士の研究の一環として、チームの一員となった。またスクラムマスターとしての役割を担った
  • Perttu Ranta-Ahoは、技術専門家として、またプロダクトオーナーとしてチームを支援した
  • Jukka Haapalaはプロダクトオーナーおよびファシリテーターとして対応した
  • Christine Bejerascoは今回のフレームワークの構築に使用されるユースケースを提供した
  • Jaakko Harjuhahtoは2年連続でチームを指導した
Project demo meeting - man pointing at thing.
初期のプロジェクト会議での、学生とエフセキュアのスタッフ

 プロジェクトでは多数の技術を採用することになった。Apache Sparkはデータマイニングのタスクを実行するために選定された。外部情報源からのデータを展開して処理したり、展開したデータに対する問い合わせを実施する。AWSはデータの処理および保管のために幅広く利用した。後続のデータ処理のためにAmazon EMRも用いた。Amazon DynamoDBは、使用するシステムの設定やサービスの状態を格納する目的で使用した。ストリーミングデータのソースを扱うために、Amazon Kinesisを組み込んだ。最後に、使用中のAWSのリソース群を管理するためにAWS CloudFormationを用いた。

Tech used in DMSI
DMSIプロジェクトで使われている技術のほんの一部

 エフセキュアが後援したチームは、献身的であること、非常に難易度の高い技術群を採用した点、網羅的なドキュメント、顧客との熱心な関わり(エフセキュア・ラボで分析ワークショップやデモを開催)、高品質のインテグレーション、模範的な開発プロセス、そして最終プレゼンテーションの品質により称賛された。我々はさらには、夏休みの仕事として3チームを連れてきて、5月に開始する。

 ところで、当社では既に数年に渡ってこの演習に何とか参画している。6位以内に入ることは頻繁で、時には3位以内になったことがある。今回は初のポールポジションだった。勝ち負けに関わらず、これは地元の学生たちにとって素晴らしい機会だ。業界関連の物事に参加し、現実の世の中でソフトウェアエンジニアリングがいかに機能するかを確認し、地域のソフトウェア企業のエンジニアたちに会うのだ。我々のチームが何を達成したかについてご興味があれば、以下2つのリンクに詳細がある。

#Wassenaar アレンジメントのゆくえ3 -- 今週から始まる予定の「Intrusion Software」の修整再交渉

3月18日、脆弱性テストツールMetasploitを提供しているRapid7社がブログで「Wassenaarアレンジメント - サイバーセキュリティ輸出コントロールへの推奨事項」という提言記事をポストした。記事中ではまさに今週にあたる4月11日の週からWassenaarアレンジメントの再交渉に関するミーティングが始まる事の指摘があり、それを睨んだ提言だ。

このWassenaarアレンジメントの再交渉の件は、前回私が1月15日にF-Secureブログに「#Wassenaar アレンジメントのゆくえ2 -- 国際武器輸出規制と「Intrusion Software」定義の影響とは」のポストを書いたのと同時期に動きだしていた。  http://blog.f-secure.jp/archives/50761446.html
この『再交渉』というのは、アメリカ国内での対応制度の話ではなく、41ヶ国の合意となっているWassenaarアレンジメントの本体の文言を書き換えるということだ。

1月12日にアメリカ議会のITサブコミッティーでヒアリングが行われた。
WASSENAAR: CYBERSECURITY AND EXPORT CONTROL

そして2月29日にはアメリカ議会動向のニュースを扱うThe Hillに、オバマ政権が「Intrusion Software」のルールへ再交渉へ舵をきったと流れた。
Obama administration to renegotiate rules for 'intrusion software'

3月1日には、アメリカ商務省がWassenaarアレンジメントの書き換え交渉の提案を受領したことが通知された。


Rapid7による提言そのものは、228ページにわたるWassenaarアレンジメント本文の中の「Intrusion Software」に関する条項の文言それぞれについて、法律家の支援を得て添削を試みたもので、以下のPDFになる。

Rapid7の提言によるWassenaarアレンジメントの添削ドラフトでは、以下の3つの点が変更すべき推奨のポイントになっている。
1) Exceptions to the Wassenaar Arrangement controls on "systems," "software," and "technology."
Wassenaarアレンジメントによる「システム」「ソフトウェア」「テクノロジー」のコントロールへの例外をはっきりすること

2) Redefining "intrusion software."
「イントルージョン・ソフトウェア」を再定義すること

3) Exceptions to the definition of "intrusion software."
「イントルージョン・ソフトウェア」の定義への例外をはっきりすること

F-Secureブログの1月15日のポストでも触れたが、MetasploitはWassenaarアレンジメントの影響を受けるツールとしてよく例に上げられている。理由は、Metasploitにはオープンソース版と商用版があるが、Wassenaarアレンジメントではオープンソースやパブリックドメインのソフトウェアのようにソースコードが公開されていればの規制から除外されることになっているので、オープンソース版MetasploitならばWassenaarアレンジメントの規制から除外されるが、商用版Metasploitは輸出ライセンスを得る必要があるという問題だ。そのため、このMetasploitを提供するRapid7がこのような提言を出して来るのはとても意味がある。

再交渉が始まるタイミングならば、Wassenaarアレンジメントの影響を受け得る日本の企業も積極的に意見を表明していく必要があるだろう。

Locky:明らかによろしくない振る舞い

 ここ1週間、「Locky」と呼んでいる新たなる暗号化ランサムウェアの脅威が大きなニュースになっている。

 これまでのところ、Locky感染の媒介としてもっとも一般的なのはメールである。Wordファイルを添付した、請求書だというメールが送付される。このファイルを開くと暗号化されているように見え、表示するためにマクロを有効にするように促される。もしここでマクロを有効にすると、実行ファイル(ladybi.exe)がドロップされる。その後、実行ファイルは128ビットAES暗号によるデータファイルの暗号化を開始する。

_Locky_recover_instructions

 今回のキャンペーンでは、世界中広く展開するために多数のローカライズがなされており、非常に組織立っているように見える。また、それをサポートする大規模で堅牢なインフラが整えられている。数多くの報告で示唆されているのは、現在Lockyを拡散しているスパムキャンペーンの背後にいるのは、バンキング型トロイの木馬Dridexを拡散したのと同一の集団ではないかということだ。

 Lockyは、C&Cに用いるドメイン名を自動生成する。ドメイン生成アルゴリズムについては、Forcepoint社が詳細を掲載している。

 当社のソフトウェアDeepGuardを実行している場合、ビヘイビア検知エンジンが、Lockyの用いる攻撃の媒介メールと、マルウェアの振る舞いの双方を阻止する。すでにかなり長い間、双方とも検知している。以下に述べるような当社で十分に試験された阻止戦略により、DeepGuardはコンテンツをダウンロードしたり、ファイルをドロップしたり、コードを実行したりするOfficeドキュメントのような、悪意のある振る舞いを検知する。DeepGuardでは、こうした類の脅威があなたのマシンを感染させるようなメカニズムをその場で阻止する。

 Lockyおよびそのバリアントに関連する悪意ある振る舞いは、以下の3つの検知によりブロックする。

  • Trojan-Dropper:W32/Agent.D!DeepGuard
  • Trojan:W32/Pietso.A!DeepGuard
  • Trojan:W32/TeslaCrypt.PE!DeepGuard

 この3つの検知により、Pony、Vawtrakおよび最新版のTeslaCryptからも顧客を保護する。

 週末の間に、Lockyの感染を媒介するものが他に表面化した。JavaScriptのファイルを含むzipの添付ファイルだ。もしこのJavaScriptを実行すると、Lockyの実行ファイルをダウンロードし実行する。このバリアントはTrojan-Downloader:JS/Dridex.Wとして検知する。

#Wassenaar アレンジメントのゆくえ2 -- 国際武器輸出規制と「Intrusion Software」定義の影響とは

  クリスマス直後の12月27日からドイツで Chaos Computer Congress (CCC) が開催された。ここでも「Wassenaarアレンジメント」についてのパネルディスカッションがあり、2015年夏以降の状況がアップデートされた。このCCCでのパネルでは衝撃的な話が出た。それは、昨年に自社内部メールの流出暴露で物議をかもしたイタリアの「Hacking Team」が、Wassenaarアレンジメントに基づいて輸出業者としての登録が認められたという話題だった。このパネルは以下URLでビデオを視ることができる。


  Wassenaarアレンジメント (経産省の表現では「ワッセナー・アレンジメント合意」)とは、41ヶ国が参加する国際武器輸出規制の枠組みだが、2013年にソフトウェア技術への規制として「Intrusion Software」と「Surveillance Systems」が追加され、この定義と取り扱いをめぐって2015年前半から大きな議論が巻き起こっているのだ。参加国の顔ぶれは以下で見ることができる。
  また、このサイトのWassenaarアレンジメントの輸出規制対象を示した「Control List」などの書類も、いくつか2015年12月3日付でアップデートされている。

  Wassenaarアレンジメントの「Intrusion Software」への規制に関して、日本語で記述されたものが今のところ著しく少ないが、日本ネットワークセキュリティ協会のこのページも参考になるひとつだろう。

  この件について私も7月に「#Wassenaar アレンジメントのゆくえ -- マルウェアやゼロデイ発見報奨プログラムへの影響とは」のポストを書いた。
  このポストで書いたのは主にアメリカのセキュリティ業界の反応についてだったが、それはアメリカのセキュリティ企業の製品やサービスが世界的にかなりのシェアを取っていたり、業界をリードしている企業がアメリカに多いことから大きく聞こえて来たためとも云える。しかし実際は、Wassenaarアレンジメントへの「Intrusion Software」「Surveillance Systems」の追加はEU側から提案されたものであり、EUでの規制の進められ具合はアメリカと違っている。EUでは、Wassenaarアレンジメントの条文に基づいた内容の規制案が今後2年かけて用意されるようだ。

  さらに、Wassenaarアレンジメントとはその名のとおり「アレンジメント」なので、「条約 (Treaty, Convention)」のような国際法的拘束力はなく、そのため参加国政府は国内での規制措置を用意することになっているが、法律の制定までは行うことは求められていないので参加各国それぞれでの規制状況は必ずしも足並みが揃ろっているわけではないようだ。またWassenaarアレンジメントが「Intangible Technology Transfer (無形技術移転)」の制限という枠組みで規制しようとしているのは、攻撃型マルウェアのような「製品」そのものではなく、それらを製作するための「テクノロジー」という物質として存在しないモノだという点が話を複雑にしている。「テクノロジーの輸出」は果たして輸出入の法的規制の枠組みで対処できるものなのか?という疑問があるからだ。

  Wassenaarアレンジメントへ「Intrusion Software」と「Surveillance Systems」が追加された理由は、2011年に中東アフリカ圏で起こったチュニジア、エジプト、リビア、バーレーンなどの民衆蜂起の際に、いわゆる西側諸国の企業が開発した「FinFisher」などのサーベイランス・ソフトウェアが独裁的政権に購入され国民の監視抑圧目的に使われていたことが判明したことから、そのような「ソフトウェア兵器」にあたるものも輸出規制をするべきという機運が高まったためだ。2013年のWassenaarアレンジメントの改訂が紹介された理由などは以下の記者会見ビデオが詳しい。何も規制が無い状態よりもとにかく何か始めるべき、というのが提案者から何度か強調されている。
Controlling Surveillance: Export Controls as a Tool for Internet Freedom, Mar 25, 2014


  この記者会見にも参加しているが、Wassenaarアレンジメントへの「Intrusion Software」と「Surveillance Systems」の追加議論に関して初期から関わっていた Collin Anderson が詳細な検討の資料を作っている。
Considerations on WASSENAAR ARRANGEMENT CONTROL LIST ADDITIONS FOR SURVEILLANCE TECHNOLOGIES Authored by Collin Anderson
New white paper recommends targeted approach to controlling export of surveillance technologies

  ところが、CCCでのWassenaarアレンジメント・パネルで明らかになったように、スパイ用マルウェアなどの製作販売を行うイタリアのHacking TeamがWassenaarに準拠した輸出業者として認定されるという展開では、このアレンジメントによる「Intrusion Software」や「Surveillance System」の輸出規制の実効性には疑問を持たざるをえないと思える。この輸出規制は、その事業者の存在する国の政府や監視機関が積極的に行動しない限り実現しないし、もし政府方針が輸出に協力的ならば有名無実になりうるだろう。Hacking Teamは、2015年の始めからプレスリリースで「Wassenaarを遵守する」と言ってきた。しかしその時点でイタリア政府が輸出業者としての認定を出すかどうかの審査は果たして規制寄りだったのだろうか。

  また、スパイウェアFinFisherを独裁国家政府などへ製作販売していたイギリスのGamma社は、このソフトウェアの独裁政府による使用での人権侵害について追求していた英NGOのPrivacy Internationalが提訴するなどしたため、イギリスから他国へ本社を移動している。

  現状のWassenaarアレンジメントは、参加国から参加国あるいは参加国から非参加国への輸出を規制する仕組みであり、非参加国同士での移動は当然まったく規制から自由だし、非参加国から参加国への輸入についてどのような扱いなのかも疑問になる。例えば、Wassenaarアレンジメント参加国同士では、ウィルスの検体の移動すら規制対象に該当しうるという解釈のために悲鳴が上がっているのに、非参加国同士ならまったく制限がない。実際、多数のセキュリティ企業があるイスラエルや中国やインドは非参加国だし、アジア圏では日本と韓国しか参加していないので、レベルの高いハッカーコンファレンスが開催されているマレーシアやシンガポールや香港や台湾も非参加国だ。

  どうやらWassenaarアレンジメントの前提になっているのは、開発に高度な技術が要る兵器やソフトウェアはいわゆる「先進国」のみが作れるので、Wassenaarへそれら「先進国」を参加させることで規制できるという発想だが、その発想自体がすでに疑問なものといえる。

  さらに、現状のWassenaarアレンジメントでは、個人のセキュリティ研究者や小規模独立系セキュリティ企業が最大の影響を受けることが状況的に明らかになって来たことが、これが議論の俎上に上がっている理由のひとつだ。
  例えば、アメリカの法律に基づく解釈では「Deemed Export」という概念があり、これは口頭で伝えるだけでも輸出に該当してしまうという解釈になる。これでは、多数の国籍の従業員で構成されたセキュリティ企業で、Wassenaar非参加国の従業員が含まれていた場合、ウィルスに関しての技術情報を口頭で伝えるだけでWassenaarアレンジメント違反になってしまう。

  また、オープンソースやパブリックドメインのソフトウェアのようにソースコードが公開されていればWassenaarアレンジメントの規制から除外されることになっているが、これも話は単純ではない。例えばMetasploitにはオープンソース版と商用版があるが、もしWassenaar非参加国でのペンテストの業務があるとして実施のためにスタッフがMetasploitをツールとして持って入国するには、オープンソース版MetasploitならばWassenaarアレンジメントの規制から除外されるが、商用版Metasploitを持って行くならば輸出業者として登録しなければならいない事になる。
  あるいは、どのようなオープンソース・ソフトウェアであっても実際にコードが書かれる前の、プログラマーの頭の中で考えている段階ではソースコードはまだ公開されていない。ということは、ソースコードが頭の中にあるプログラマーがWassenaar非参加国に入国すると、Wassenaarアレンジメント違反という解釈ができうる。これらの例は、CCCでのWassenaarパネルで実際に出た話題だ。

  アメリカの商務省でのWassenaarアレンジメント対応規制については、2015年7月のパプリックコメントを反映した新しいドラフトが今年出てくるであろう。EUでは今後2年間かけで対応する規制を作ると言われているので、すでにそれへ向けてセキュリティ協会から意見を注入しようとする動きがある。

  しかし、結局は「Wassenaarアレンジメント」の条文自体を修正しなければ問題はなくならないだろう。それに向けてのセキュリティ関係者の動きも起きている。
Overhaul Wassenaar or ruin next Heartbleed fix, top policy boffin says

  上記の Collin Anderson は、日本のセキュリティ業界からも意見を求めている。Wassenaarアレンジメントの対応への不安や興味のある方は、以下のURLのアンケートに英語だが無記名で良いので意見を送ってみて欲しい。
Questionnaire on Intrusion Software Export Regulations in Japan (English)

Dridexの解体

 先日、英国NCA(National Crime Agency、国家犯罪対策庁)はFBIおよびアメリカ合衆国司法省とともに、Bugat、Cridex、Dridexの作者を告訴した。Andrey Ghinkulは2015年8月28日にキプロスで逮捕された。現在、米国は身柄の引き渡しを求めている。報じられているところでは、Dridexは世界各国で金融機関や金融業者に数百万ドルの損失を招いた。

 Dridexは、正規のファイルに見せかけた、悪意あるマクロコードが埋め込まれたMicrosoft Wordドキュメントを通じて伝播することが分かっている。こうしたマクロはいずれ、C&Cサーバや侵害されたWebサイトから実行ファイルをダウンロードすることになる。エフセキュアでは、Officeドキュメントに特化してファイル内の悪意あるマクロを探す、一般的な検知を行っている(Trojan:W97M/MaliciousMacro.GEN)。

 当局がDridexボットネットを駆除するにつれ、当社のバックエンドの統計情報に悪意のあるマクロの発見が感知され、急増が見られた。

 当社の顧客は、Hydra(スキャンエンジン)およびDeepGuard(ビヘイビアベース)の両技術にて守られている。

Virus and spyware history Trojan:W97M/MaliciousMacro.GEN
Trojan:W97M/MaliciousMacro.GENの検知

F-Secure Internet Security, Harmful file removed
害のあるファイルが削除された

 一般的なシグニチャによって悪意あるマクロの検知を行っているほか、ビヘイビアエンジンであるDeepGuardでもブロックする。1階層より2階層の保護のほうが優れている。

F-Secure Internet Security, Application blocked
不正なビヘイビアのためにブロックされたアプリケーション

 Wordドキュメントが実行ファイルをドロップするって?そうだ、それに良いことなんか1つもない。

 Q:こうしたDridexの動きは、すべて当局がボットネットを解体したことと関係があるのか?
 A:当社では分からない。

CISAに関するQ&A

 2015年9月10日、米議会(特別)諜報委員会が世界規模のサイバー上の脅威について公聴会を開いた。

House (Select) Intelligence Committee Hearing on World Wide Cyber Threats – September 10, 2015
「世界規模のサイバー脅威」

 有力メンバーであるアダム・シフ議員は冒頭陳述において、CISA(Cybersecurity Information Sharing Act、サイバーセキュリティ情報共有法)の米議会版であるPCNA(Protecting Cyber Networks Act)の目的についてコメントしている。

House (Select) Intelligence Committee Hearing on World Wide Cyber Threats Transcript – Transcript
情報源:C-SPAN

 以下は、この件に関連するテキストの全文だ。

House (Select) Intelligence Committee Hearing on World Wide Cyber Threats – Schiff Opening Statement

 これでお分かりだろう。CISAの目的は「マルウェアを共有すること(to share malware)」なのだ。

 Q:それで、あなたはそう考えていると?

 A:そうだ、それがその目的だ。情報共有はマルウェアサンプルの共有と等しい。

 Q:CISAは監視法案だろうか?

 A:いや、そうではない。少なくとも私の考えでは違う。

 Q:しかしCISAは優れた法案だろうか?

 A:いや、私はそう思っていない。

 Q:なぜ?

 A:なぜなら私の見解では、CISAは軍とサイバー企業の複合体(military-digital complex)のための企業助成政策に過ぎないように見えるからだ。

 Q:CISAは成立するだろうか?

 A:諸々の兆候示すところは…イエスだ。

 @5ean5ullivan

Apple iOS 9のセキュリティ機能

 アップル社の2015年のスペシャルイベントが本日開催される。つまり、9月9日=iOS 9の発表、だ。

 アップルはiOS 9においてセキュリティが向上していることを確約している。Touch ID用に6桁のパスコードを実装したことは、広く報道されているものの一例だ。

iOS 9 improved security
ソース:アップル

 セキュリティ研究者のFrederic Jacobsによる、ドキュメントにある変更点についての秀逸な要約がMedium上にある。

 私がiOS 9のパブリックベータ版をテストしている際に気付いた細かい変更点は、Windowsに関連するものだ(*1)。

 iTunesがインストールされているコンピュータ(OS Xを実行しているあらゆるコンピュータを含む)に、iOS 9のデバイスを接続した際に目にするプロンプトを以下に示す。

iOS 9, Trust This Computer?
Trust This Computer?(このコンピュータを信頼しますか?)

 そして以下は、iTunesのドライバがインストールされていない(Windows)コンピュータに、iOS 9のデバイスを接続した際に見られるプロンプトだ。

iOS 9, Allow this device to access photos and videos?
Allow this device to access photos and videos?(このデバイスが写真およびビデオにアクセスすることを許可しますか?)

 これは些細だが、興味深い差異だ。「Allow」は制限されたアクセスを示唆する一方で、「Trust」ではより重要な何かを示唆している。かつて、iOSを狙ってクロスプラットフォームのマルウェアが試みられたことがあった。このAllowプロンプトがあることで、注意深い観察者なら、そうしたクロスプラットフォームのマルウェアがそこに存在していることを判定できるだろう。iTunesがインストールされていないと分かっているWindowsコンピュータにiOS 9デバイスを接続したとして、信頼する(Trust)かどうかを尋ねられたら…、信頼してはならない。

 もう1つ、細かいが大歓迎の変更点は、7月にブログに書いたSafariの新たな機能だ。

 SafariをJavaScriptによる警告ダイアログの無限ループに陥らせようとする詐欺サイトは、Safariの新たなオプション「Block Alerts(警告をブロックする)」によって、彼らの努力が無になったことを知るだろう。

iOS 9 Safari, Block alerts from?
Block alerts from?(〜からの警告をブロックしますか?)

 全般的に見て、iOS 9は良い感じだ。今日のアップルのイベントの最中に、さらにセキュリティに関する情報が出てくることを望んでいる。また9月16日に予定されている、iOS 9の一般公開を楽しみにしている。

 @5ean5ullivan

 (*1) Kali Linuxでテストしたところ「Trust」プロンプトが得られた



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


AmazonがFlash広告にノーを突きつける

 近頃、Flashベースのマルバタイジングが猛威を振るっている。そのため以下のような発表がなされるのは時間の問題でしかなかった。

 「Beginning September 1, 2015, Amazon no longer accepts Flash ads on Amazon.com, AAP, and various IAB standard placements across owned and operated domains.)、または所有および運用するドメイン上のIAB(Interactive Advertising Bureau)標準の様々なプレースメント広告において、Flash広告を受理することはない。」

Amazon Advertising Technical Guidelines
Amazon Advertising Technical Guidelines

 AmazonはFlashを禁止する以上のことを行っている。以下に例を挙げる。

  • 広告を提供するサーバのドメインからのみコンテンツを受け付ける
  • ドメイン名がある場合に限定し、IPアドレスしかないものは受け付けない
  • 表示されるURLは実際の宛先でなければならず、リダイレクトは認められない

 詳細はこちら

 これはAmazonとしては非常にすばらしい動きであり、願わくば他の企業も遅かれ早かれ同様の措置を講じてほしい。Flashベースの広告は、現在は非常にありふれたセキュリティ上のリスクだ。ない方が、みんながより幸せになる。

 @5ean5ullivan

#Wassenaar アレンジメントのゆくえ -- マルウェアやゼロデイ発見報奨プログラムへの影響とは

  Wassenaarアレンジメントに対して、主にアメリカのセキュリティ業界はここ2ヶ月の間静かに大騒ぎしていた。アメリカ商務省がドラフトを書いた、この国際合意への「Intrusion Software」追加の提案の影響は、マルウェアのサンプルだけででなく今後報告されるであろうゼロデイ・エクスプロイットや、最近盛んになってきている多数の脆弱性発見報奨プログラムにも及ぶだろうからだ。またこの改訂に含まれる要件は、出身国が多様なセキュリティ研究者に影響を与え得る。この改訂によると「Intrusion Software」の輸出を行う事業者は輸出事業者免許を取得することが必要になるからだ。

  Wassenaarアレンジメントとは、もともとは兵器と関連品の輸出入管理についての多国間の合意だった。しかし2011年に中東アフリカ圏で起こったチュニジア、エジプト、リビア、バーレーンなどの民衆蜂起の際に、いわゆる西側諸国の企業が開発したサーベイランス・ソフトウェアが独裁的政権に購入され国民の監視抑圧目的に使われていたことが判明したことから、「ソフトウェア兵器」にあたるものの規制として「Intrusion Software」がそこへ加えられることになったのだ。ところが、その定義と規制が広過ぎることから今回の騒動が始まったといえる。

  F-Secureのショーン・サリバンが6月9日のポストでアンチウィルス・ベンターとしてのWassenaarへの懸念を書いていたが、影響する範囲はもっと広い。ショーンは「Intrusion Software」の定義にマルウェアが当てはまると指摘していたが、ゼロデイ・エクスプロイットもこの定義に該当することになるはずだからだ。 

  そして「Intrusion Software」の輸出を行う事業者はその国の輸出事業者免許を取得することが必要になるとすると、脆弱性発見報奨プログラムへの報告を行おうとするセキュリティ研究者も輸出事業者免許の取得が必要なのだろうか? 多くのセキュリティ研究者は個人やたった数人のグループなのだが? もし研究者のグループが複数の国籍者の集まりならばどうなるのか? 輸出事業者免許の取得にはいったい幾らかかるのか? また逆に、先月から話題になっているイタリアの「Hacking Team」のようなハッキングを販売する企業が輸出事業者免許を取得することは禁止できるのか?

  このWassenaarアレンジメントの改訂は有害なパラドックスも引き起こしうる。「Intrusion Software」であっても公知の状態に公開されたテクノロジーならば除外対象になるとされているのだが、ならばゼロデイを発見した研究者は、いきなり公表することはできるが、まずメーカーに通知し修正が済んだ時期まで待ってから公表するという「責任あるディスクロージャー」として長年にわたり定着しているプラクティスは輸出事業者免許を取得しない限り行えないことになる。

  Wassenaarの現状の参加国は次のような顔ぶれだが、アジアからは日本と韓国だけが参加している。しかし中国やマレーシアのセキュリティ研究者からレベルの高い報告が為されている現状を見るならば、非Wassenaar参加国からWassenaar参加国への「Intrusion Software」の移動はどう扱われるべきなのか? :
 Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Croatia, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, Latvia, Lithuania, Luxembourg, Malta, Mexico, Netherlands, New Zealand, Norway, Poland, Portugal, Republic of Korea, Romania, Russian Federation, Slovakia, Slovenia, South Africa, Spain, Sweden, Switzerland, Turkey, Ukraine, United Kingdom, United States

  アメリカ商務省は、Wassenaarの「Intrusion Software」追加に関するパブリックコメントを7月20日まで受付ていたので、この2ヶ月のあいだ意見を送る啓蒙活動が起きていた。Wired誌は7月16日に、脆弱性バウンティプログラムを運営するHackerOneのチーフポリシーオフィサーKaite Moussourisによる事態の詳細を解説する寄稿を掲載した。(彼女は以前Microsoftのセキュリティ・レスポンスセンター(MSRC)にて脆弱性バウンティプログラムを立ち上げた人である)

  Wassenaarに関するパブリックコメントには、実際にアメリカの多数のセキュリティ・防衛産業企業からのコメントがあった模様だ。(Raytheon社などは「夏休み中にWassenaarを施行しないでくれ」というコメントだったらしい噂もあったが)

  エレクトロニック・フロンティア・ファウンデーション(EFF)では対応チームを作り、Center for Democracy and TechnologyやHuman Rights Watchなど6つの団体と連合を組んで啓蒙活動を行っていた。

  それらのパブリックコメントやEFFなどの活動は商務省へそれなりの影響を起こしたようで、Wassenaarの文面は現状のドラフトから書き換え中で新バージョンは「かなり変わることになる」との発言が商務省関係者からあったとのニュースが7月29日に出た。

  しかしWassenaar改訂案文面の新バージョンがかなり変わることになるとしても、実際の文面を見るまでは予断を許さないだろう。また第2回目のパブリックコメントが行われるだろうという説もある。

  Wassenaarについては、Blach Hat USAの8月6日と、その後続いて開催されるDefconの8月8日10:00am Track3にセッションが予定されている。セキュリティ関係者は議論の動向に注目しよう。

APT攻撃を行うDukeグループの最新のツール:クラウドサービスとLinuxサポート

 ここ数週間で、Dukeグループのツールセットに2つの補強メンバーが登場したことが判明した。SeaDukeとCloudDukeだ。これらのうちSeaDukeはシンプルなトロイの木馬で、Pythonで書かれている点が興味深い。さらに不思議なことに、SeaDukeはWindowsとLinuxの両方を同時にサポートしている。我々が観察してきたDukeグループによるマルウェアとしては、初のクロスプラットフォームのマルウェアである。SeaDukeはクロスプラットフォームであるにも関わらず、単一のトロイの木馬だ。一方、CloudDukeはマルウェアコンポーネントの完全なツールセットのように見える。あるいは、Dukeグループが呼ぶように「ソリューション」なのだろう。これらのコンポーネントには、独自のローダーやダウンローダ、1つではなく2つの異なるトロイの木馬型のコンポーネントが含まれている。C&Cおよび盗んだデータを抜き出すための経路として、Dukeグループはクラウドストレージサービス、とりわけマイクロソフトのOneDriveを使用しているということをCloudDukeが雄弁に物語っている。最後に、CloudDukeの最近のスピアフィッシングキャンペーンの一部は、1年前からのCozyDukeのスピアフィッシングキャンペーンと酷似している。

クロスプラットフォームのマルウェアSeaDukeにLinuxサポートが追加

 先週、シマンテックおよびパロアルトネットワークスの両社はSeaDukeに関する研究内容を公開した。SeaDukeは、Dukeグループが使用するトロイの木馬の武器庫に新たに追加されたものである。これまでのDukeグループによるマルウェアは、常にCおよびC++言語の組み合わせだけでなくアセンブリ言語によっても書かれていた。一方、SeaDukeは珍しくPythonで書かれており、複数のレイヤに渡って難読化がなされている。こうしたPythonのコードは通常、py2exeやpyinstallerを用いてWindowsの実行形式にコンパイルする。しかし今回のPythonのコードは、WindowsとLinuxの双方で動作するように設計されている。それ故、我々が推測するところでは、DukeグループはLinuxユーザの標的に対しても同一のSeaDukeのPythonコードを使っている。DukeグループがLinuxプラットフォームを標的にしたマルウェアを採用したのを我々が目にしたのは、このときが初めてだ。

seaduke_crossplatform (39k image)
SeaDukeで見つかった、クロスプラットフォームサポートの例

マルウェアツールセットCloudDukeにおける新たなソリューション群

 先週、パロアルトネットワークス社およびカスペルスキー社は、各社がMiniDionisおよびCloudLookと呼んでいるマルウェアのコンポーネントについて、研究内容を公表した。MiniDionisおよびCloudLookは、ともに当社がCloudDukeと称するより大きなマルウェアツールセットのコンポーネントだ。このツールセットは、多岐に渡る機能を提供するマルウェアのコンポーネント群から構成される。さらに、共有コードフレームワークに部分的に依存し、常に同じローダーを用いている。当該サンプルの中で見つかったPDB文字列に基づくと、マルウェアの作者はCloudDukeのコンポーネントを「DropperSolution」「BastionSolution」「OneDriveSolution」などと「ソリューション(solution)」と呼んでいた。我々が観察したPDB文字列の一覧を以下に示す。

C:\DropperSolution\Droppers\Projects\Drop_v2\Release\Drop_v2.pdb
c:\BastionSolution\Shells\Projects\miniDionis4\miniDionis\obj\Release\miniDionis.pdb
c:\BastionSolution\Shells\Projects\miniDionis2\miniDionis\obj\Release\miniDionis.pdb
c:\OneDriveSolution\Shells\Projects\OneDrive2\OneDrive\obj\x64\Release\OneDrive.pdb

 我々が最初に観察したCloudDukeのコンポーネントは、内部的に「DropperSolution」と呼ばれているダウンローダである。ダウンローダの目的は、被害者のシステムにさらなるマルウェアをダウンロードして実行することだ。もっとも多く観察されたケースでは、当該ダウンローダは侵害されたWebサイトへの接続を試み、暗号化された悪意あるペイロードをダウンロードして、復号と実行を行う。ダウンローダの構成されていた状況によるが、一部の例ではまず手始めにマイクロソフトのクラウドストレージサービスOneDriveへログインし、そこからペイロードを取得することを試みる。OneDriveでペイロードが得られなければ、ダウンローダは侵害されたWebサイトからダウンロードするという、先に述べた方法へ逆戻りする。

 また、CloudDukeツールセット中に、2つの異なるトロイの木馬のコンポーネントが観察された。1つ目は内部的に「BastionSolution」と呼ばれており、パロアルトネットワークス社が同社の研究において「MiniDionis」としているトロイの木馬である。興味深いことに、BastionSolutionは機能的にはSeaDukeの完全なコピーのように見える。唯一の実質的な違いは、プログラミング言語の選択だけだ。BastionSolutionはまた、内部的に「Z」と呼ばれているらしいコードフレームワークをかなり使っている。このフレームワークは、暗号化、圧縮、ランダム化、ネットワーク通信などの機能を持つクラスを提供している。

bastion_z (12k image)
トロイの木馬BastionSolution内のクラスのリスト。「Z」フレームワーク由来の複数のクラスを含む

 暗号化やランダム化のクラスのように、同じ「Z」フレームワークに由来するクラスは、CloudDukeツールセットのもう1つのトロイの木馬型のコンポーネントでも使用されている。この2番目のコンポーネントは内部的には「OneDriveSolution」と呼ばれている。C&Cの経路としてマイクロソフト社のクラウドストレージサービスOneDriveに依存しているため、とりわけ興味深い。これを実現するため、OneDriveSolutionは事前に設定されたユーザ名とパスワードでOneDriveにログインを試みる。成功すると、続いて被害者のコンピュータからOneDriveのアカウントへデータのコピーを始める。また同時に、マルウェアが実行すべきコマンドが格納されたファイルをこのOneDriveのアカウントから探す。

onedrive_z (7k image)
トロイの木馬OneDriveSolution内のクラスのリスト。「Z」フレームワーク由来の複数のクラスを含む

 すべてのCloudDukeの「Solution」は同一のローダーを用いている。このローダーはあるコードの一部分となっているが、それは埋め込まれて暗号化された「Solution」を復号したり、メモリに読み込んで実行することが主目的であるコードだ。Dukeグループは自身のマルウェアのためにローダーをたびたび利用するが、以前彼らが使っていたローダーと異なり、CloudDukeのローダーはずっと融通が利く。最終的なペイロードの読み込みおよび実行に複数の方式をサポートしており、また追加的なマルウェアコンポーネントをディスクに書き込んで実行する機能があるのだ。

CloudDukeのスピアフィッシングキャンペーンと、CozyDukeにおける類似性

 CloudDukeはこのところスピアフィッシングメール経由で広がりを見せている。報告されているところでは、米国防衛省のような組織などが標的にされている。こうしたスピアフィッシングメールには侵害されたWebサイトへのリンクが含まれており、サイト上にはCloudDukeの実行ファイル群を含むzipファイルが置かれている。大半の場合、このような実行ファイルを実行することで、被害者のハードディスクに2つの新しいファイルが書き込まれることになる。両ファイルのうち1つ目は、音声ファイルやPDFファイルのような囮だ。一方でもう1つのファイルは、いわゆる「DropperSolution」というCloudDukeのダウンローダが埋め込まれた、CloudDukeのローダーである。こうしたケースでは、被害者には囮ファイルが提示され、バックグラウンドではダウンローダがCloudDukeのトロイの木馬である、「OneDriveSolution」または「BastionSolution」のいずれかのダウンロードへと進む。

decoy_ndi_small (63k image)
CloudDukeのスピアフィッシングキャンペーンで採用された囮ドキュメントの例。攻撃者がここからコピーしているのは明らかだ

 だが興味深いことに、当社でこの7月に観察した、CloudDukeの別のスピアフィッシングキャンペーンの一部は、2014年7月初めという、ほぼ1年前に見られたCozyDukeのスピアフィッシングキャンペーンに驚くほど似ている。これら双方のスピアフィッシングキャンペーンでは、囮のドキュメントはまったく同一のPDFファイル「US letter fax test page」である(28d29c702fdf3c16f27b33f3e32687dd82185e8b)。同様に、悪意のあるファイルが置かれたURLは、双方のキャンペーンにおいて、eFaxと関連があるようなものになっている。また興味深いことに、CozyDukeに触発されたCloudDukeのスピアフィッシングキャンペーンでは、メール内でリンクが張られた悪意のあるアーカイブのダウンロードと実行を行うと、CloudDukeのダウンローダの実行につながるわけではなく、「BastionSolution」が実行されるのだ。つまり、その他のCloudDukeスピアフィッシングキャンペーンのために記述された処理が、1ステップ飛ばされる。

decoy_fax (72k image)
CloudDukeおよびCozyDukeの双方のスピアフィッシングキャンペーンで採用された囮の「US letter fax test page」

検出回避のために、クラウドサービスがますます使用される

 Dukeグループが彼らの作戦の一部として、クラウドサービス全般やMicrosoft OneDriveを使ったのを、我々が目にしたのはCloudDukeが初めてというわけではない。今年の春頃、当社はCozyDukeの研究結果を公開 し、そこで次の点を述べた。すなわちCozyDukeは、盗んだデータをこっそり運び出すために時にOneDriveアカウントを直接的に用いたり、あるいはまた時には同じOneDriveアカウントから追加のコマンドを含むファイルを取得する。

 こうした以前のケースにおいて、Dukeグループは補助的なコミュニケーション手段としてOneDriveを使用するだけであり、依然として、動作の大半においてC&Cの経路を従来のものに頼っていた。そのため、実際のトロイの木馬をダウンロードしてコマンドを渡すところから、盗んだデータを最終的に持ち出すところまで、作戦の各ステップにおいてCloudDukeが本当にOneDriveのみに依存するようになったことは、興味深い。

 C&Cの経路としてOneDriveのようなサードパーティのWebサービスにのみ依存することによって、Dukeグループはよりうまく検出をかいくぐろうとしたのだと我々は考える。組織のネットワークから、未知のWebサーバへ大量のデータが転送されたら、いともたやすく疑いが生じる。しかし、人気のあるクラウドストレージサービスへデータを転送するのは普通のことだ。攻撃者が大量の盗んだデータを秘密裏に転送するのにより適した方法とは、人々が正規の理由で同じデータを日々転送するのと同じ方法である(たまたまだが、サードパーティのWebサービスがC&Cの経路として使用されることの影響を題材にした講演が、VirusBulletin 2015カンファレンスで行われる予定だ)。

限りある資源を、検出を回避し防衛側に先んじることへ回す

 多目的なマルウェアツールセットを1つ開発するのですら、細かいことを置いてくとして、時間と資源を要するものだ。したがって、異なるツールセット間でフレームワークをサポートするなど、コードの再利用を試みることは理に適っているように思える。しかしながら、SeaDukeとCloudDukeのコンポーネントBastionSolutionにおいて複数のプログラミング言語で同じコードを書き直したことによって、Dukeグループはさらにもう1歩進んだようだ。内部は似通ってはいるが、外部ではまったく違うように見える2つのマルウェアツールセットを提供することにより、時間と資源を節約できる明白な利点がある。これで一方のツールセットが発見されても、2つ目のツールセットの発見にただちに結び付くことはない。

 Dukeグループはロシアと結びつきあることが長い間疑われているが、異常に長い期間、また特に最近は異常な厚かましさで諜報活動を行っている。最近のCloudDukeやSeaDukeのキャンペーンは、Dukeグループが近いうちに活動終了するつもりはないという、明確な兆候のように見える。

 Research and post by Artturi (@lehtior2)

 エフセキュアはCloudDukeをTrojan:W32/CloudDuke.BまたはTrojan:W64/CloudDuke.Bとして検知する。

サンプル:

04299c0b549d4a46154e0a754dda2bc9e43dff76
2f53bfcd2016d506674d0a05852318f9e8188ee1
317bde14307d8777d613280546f47dd0ce54f95b
476099ea132bf16fa96a5f618cb44f87446e3b02
4800d67ea326e6d037198abd3d95f4ed59449313
52d44e936388b77a0afdb21b099cf83ed6cbaa6f
6a3c2ad9919ad09ef6cdffc80940286814a0aa2c
78fbdfa6ba2b1e3c8537be48d9efc0c47f417f3c
9f5b46ee0591d3f942ccaa9c950a8bff94aa7a0f
bfe26837da22f21451f0416aa9d241f98ff1c0f8
c16529dbc2987be3ac628b9b413106e5749999ed
cc15924d37e36060faa405e5fa8f6ca15a3cace2
dea6e89e36cf5a4a216e324983cc0b8f6c58eaa8
e33e6346da14931735e73f544949a57377c6b4a0
ed0cf362c0a9de96ce49c841aa55997b4777b326
f54f4e46f5f933a96650ca5123a4c41e115a9f61
f97c5e8d018207b1d546501fe2036adfbf774cfd

C&Cに使われている、侵害されたサーバ:

hxxps://cognimuse.cs.ntua.gr/search.php
hxxps://portal.sbn.co.th/rss.php
hxxps://97.75.120.45/news/archive.php
hxxps://portal.sbn.co.th/rss.php
hxxps://58.80.109.59/plugins/search.php

CloudDukeを置くために使われている、侵害されたWebサイト:

hxxp://flockfilmseries.com/eFax/incoming/5442.ZIP
hxxp://www.recordsmanagementservices.com/eFax/incoming/150721/5442.ZIP
hxxp://files.counseling.org/eFax/incoming/150721/5442.ZIP

ドキュメンタリー「ゼロデイ」

 ドイツの公共放送機関であるVPROが、ハッキングやゼロデイ脆弱性の取引に関する45分間のドキュメンタリーを制作した。このほど、その英語版がYoutubeで公開された。



 このドキュメンタリーには、Charlie Miller、Joshua Corman、Katie Moussouris、Ronald Prins、Dan Tentler、Eric Rabe(Hacking Team)、Felix Lindner、Rodrigo Branco、Ben Nagy、The Grugq、他大勢が出演している。

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

政府関連

セキュリティ関連団体

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

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

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

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

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