エフセキュアブログ

2011年02月

Facebook HTTPS:実現は完璧よりも優れているのか?

  私のFacebookアカウントが先週ついに、「可能な場合は常に」HTTPS接続を使用するオプションの提供を開始した。

  同オプションは「Account Settings」ページの「Account Security」セクションにある:

Facebook Account Security

  そこで私はこのオプションを選択して、変更を保存した:

Facebook Account Security

  それで、FacebookはセキュアなHTTPS接続をデフォルトに設定している:

https://www.facebook.com/?sk=nk

  あるいは、私はそう考えていた…(詳細は以下)

  今日、私は「http://omg」についてFacebookサーチを行い、スパムに遭遇した。

  典型的なFacebookスパムのエサ「see who stalks your profile(誰があなたのプロフィールをストーキングしているか見る)」だ:

OMG, see who stalks your profile...it's Working

  このリンクをクリックすると、以下の表示が開いた:

Switch to regular connection (http)?

  オーケー… このアプリケーションはHTTP接続でのみ見られるのだろう。

  そこで私は「Continue」ボタンをクリックした。

  そして以下が、同アプリケーションが許諾を求める「Request for Permission」だ:

Request for Permission

  うーん、「Who Spends Watching Your Profile?」の開発者は誰だって?

Who Spends Watching Your Profile?

  Justn Bieber? Justn?

  なるほど。さて、我々は現在、このスパマーの標的となるグループが分かっている。

  「Justn Bieber」は、ジャスティン・ビーバー・ファンページについてのコメントに時間を費やしているようだ:

Justn Bieber

  私はこのスパムアプリケーションをFacebookに報告し、立ち去った…

  その少し後で、私は自分のアカウントがもはやセキュアでないことに気づいた:

http://www.facebook.com/?sk=nf

  待てよ、何だって?

  設定をチェックしたところ:

Facebook Account Security

  セキュリティ設定が取り消されている? だが、このオプションは「可能な場合は常に」のはずであり、「標準接続」に切り替える、以前のプロンプトは、単に一時的なものだったのでは?

  いや。

  数回テストしてみたが、毎回、アプリケーションが「標準接続」を「続ける」よう求め、デフォルトの「Account Security」設定がHTTPに戻っていた。

  これに最初に気づいたのは私ではない。Facebookはこの問題を認識しており、SSLプリファランスを持続させるよう作業を行っている

  Facebookはこのような事を故意に行っているのでは、と言うであろう皮肉な人たちもいるはずだ。個人的に、私はそうは思わない。単なる見落としだろう。

  何故って?

  Facebook HQからの以下の写真を見てほしい:

Move fast and break things — Done is better than perfect

  何が見えるだろうか?(ケイティ・ペリーではなく。もう一度見てほしい。)

  ドアの上だ。「move fast and break things(迅速な行動が物事を動かす)」「done is better than perfect(完璧を目指すより実現すべし)」という言葉が見えるだろうか?

  それで分かった。なるほど。Facebookは革新に向け突き動かされているのだ。

  (Googleが王座を奪おうとしている状況の中)彼らは成長し、ソーシャルネットワーキングの先頭にとどまる必要がある。

  しかし、「Account Security」設定に関して言えば、完璧を目指すよりも実現することの方が、本当にベターなのだろうか?

  完璧である必要は無いが、個人的には、中途半端よりは完成したものの方が良いと思う。

  中途半端は、長い目で見れば混乱を引き起こすだけだ。

  それでは、我々が中途半端な結果を得る理由は何だろう? 率直に言って、(ある程度)Twitterのせいだと私は思う。

  まじめな話だ。

  Blogosphere(ブログ圏)は現在Twittersphereであり、昨年10月、Firesheepがニュースになったとき、Twittersphereはツイートを開始した。ではFacebookは? 彼らは人々に、彼らが要求していたもの、すなわちHTTPSオプションを提供した。

  このオプションがいつ中途半端でなくなるかは、実際、問題ではないのかもしれない。Twittersphereはいずれにせよ、次の旬なトピックについてツイートするのに忙しく、気づかないだろうから。

では、
ショーン

スキャムでありフィッシングの試みでもある

  Facebookでばらまかれている悪意あるリンクに関する以前の記事で、これらのリンクはフィッシングの試みであることを紹介した。これはスパイウェアスキャムであることも判明している。

  そして、あちこちにばらまかれているのが目撃されたこれらのリンクは、偽のFacebookログインページへと続いていた:



  ここまでは、単純でありきたりなフィッシングの試みのように見える。しかし、ダミーアカウントでさらにテストすると、もう少し興味深いことが続く。

  ログインページのように見えるページにアカウントの詳細を入力すると、以下の魅力的な案内に導かれる:



  無料のiPadが欲しくない人がいるだろうか? 非常に素敵な賞品のいずれかを期待して「Claim Now(いますぐ申し込む)」ボタンをクリックすると、以下のサイトに誘導されることになる:



  まだ賞品は無い。このページの大きな輝くボタンをクリックすると、以下の表示が現れる:



  そしてダウンロードを行えば、残念賞として…スパイウエアを獲得することになる。自分のアカウントの詳細で、これをあがなったわけだ。その後すぐ、Facebookは我々のダミーアカウントでの疑わしいアクセス活動について知らせてきた:

suspicious-acc

  いや、これは我々が居るところではない。「I don't recognize(認証しない)」ボタンをクリックすると、新しいパスワード設定ページに導かれる。このページはダミーアカウントを回復するために使用できるものだ。

  OK、だからこのスキャムは、まだそれほど新しくないか、独創的ではない。我々は昨年8月、Twitter周辺で進行していた似たようなスキャムについて記事を掲載している。

  幸いなことに、ユーザをこれらのサイトに導くこの悪意あるリンクは、現在アクティブではなく、大部分の関連サイトはダウンしているようだ。エフセキュアの製品も、ダウンロードされたスパイウェアを検出し、削除する。

  とは言え、油断せず気をつけて欲しい。

- 投稿はShantiniによる。

ZeuS Mitmoが再び攻撃:ポーランドING銀行

  今日、ポーランドから最新ニュースがあった:ZeuS trojanの亜種が、「ING Bank Slaski(ポーランドING銀行)」が使用している、モバイルフォンベースの2要素認証を標的としているというものだ。

  セキュリティーコンサルタントでありブロガーでもあるPiotr Koniecznyが、自分のブログ「Niebezpiecznik」に詳細(Google翻訳)を書いている。

ZeuS in the Mobile, Zitmo, ING Poland, http://niebezpiecznik.pl/post/zeus-straszy-polskie-banki/

  我々がこれまでに集めた詳細から見て、これは昨年スペインで起こったZeuS Man in the Mobile攻撃と同種のもののようだ。スペインのセキュリティ会社「S21sec」が、ZeuS Mitmo(Man in the Mobile)について、最初にここで報告を行った。

  ZeuS MitmoはmTANsを盗むよう設計されており、ZeuS Mitmo trojanに感染したコンピュータは、Webバンキングプロセスに「セキュリティ通知」を入れ込み、ユーザに電話番号を提供させようとする。電話番号が提供されれば、そのユーザはモバイルコンポーネント「ZeusMitmo.A」を示すSMSリンクを受け取ることになる。

新たなFacebookフィッシング詐欺の進行

  Facebookのフィッシング詐欺。これは新しいことではないし、高度なものでもない。しかし、不注意な人をいまだに引っ掛けているし、戦略にちょっとした調整を加えながら、現在もまだ登場している。

  2010年の終わりに、我々はチャット機能を通じてばらまかれているフィッシングリンクが進行しているのを目撃した。現在、新たな進行が見られる。以下のリンクはチャットメッセージとランダムに選ばれた友達のウォールへの投稿を通じて(乗っ取られたアカウントから)送られる:

  •  http://apps.facebook.com/dealscentral[...]/dsuguo[...]/
  •  http://apps.facebook.com/reallytimeto[...]/
  •  http://apps.facebook.com/backseatdriver[...]/
  •  http://apps.facebook.com/fishingfor[...]/

  これらのリンクは、Appにアクセスするもののようだが、実際はユーザを本物のFacebookログインページのように見えるページに誘導する:

Facebook phishing chat February 2011

Facebook phishing chat February 2011

  明らかに、これらのページのURLは正当なものではない。

  ここには変わった点は無いが、いずれにせよ警戒を怠らず、距離を置くことだ。これは現在、わずかにしか進行していないようで、早く消えてくれれば結構なことだ。執筆の時点では、上に挙げた最初のフィッシングリンクは、すでにアクティブではないが、他のリンクは現在も稼働中だ。

  FacebookのSecurity Pageで、フィッシングに関する詳細を読むことができるほか、詐欺らしきものを報告する方法をチェックすることができる。

では。
Shantini

「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による。

Trojan:Android/Adrd.A

  2、3日前、ミッコが「ADRD」という名の新しいAndroid trojan(我々はこれを「Trojan:Android/Adrd.A」として検出している)についてツイートした。

  「Adrd」は、大部分が中国のサードパーティアプリケーションプロバイダによる、いくつかのアプリケーションにトロイの木馬が仕込まれてリパッケージされている状態で発見された。これまでのところ、感染したアプリケーションの大部分は、ウオールペーパー関連のものだ。

  以下は、感染したアプリケーションの例だ:



  インストールされた「Adrd」が感染したアプリケーションは、以下のようなパーミッションを示すかもしれない:



  これらのパーミッションは、端末のスタートアップ中に「Adrd」がそのルーチンを開始することを可能にし、ネットワークデータアクセスの許可/禁止といったデータ接続の変更を行う。パーミッションの中には、SDカード、端末、Access Point Name(APN)設定へのアクセスも含まれる可能性がある。

  「Adrd」の機能には、以下のようなリモートホストへの更新が含まれるようだ。

- adrd.tax[..].net
- adrd.xiax[..].com

そして、端末の情報、特に国際移動体装置識別番号(IMEI)と、移動加入者識別番号(IMSI)を送信する。送信されるデータは、DESで暗号化されている。

  リモートホストはリンクのリストでリプライする。そのうちの一つを「Adrd」がランダムにセレクトし、内蔵するシンプルな乱数ジェネレータを使用して接続する。選択されたリンクが交信を受けると、定義済みのサーチ文字列を返し、「Adrd」がこれを処理し、バックグラウンドで検索を実行する。

例:
1. 「Adrd」の乱数ジェネレータは、リモートホストから得られるリストの配列を示す数を生成する。例えば http: //59.[...].12.105 /g /g.[...]?w=959a_w1 といったものだ。
2. このリンクは実際、「Adrd」が使用する検索基準を含んでおり、例は以下の様になる:

http://wap.baidu.com/s?word=%e5%[...]e5%89%a7%e7%85%a7 &vit=uni&from=979a

「Adrd」はこれをバックグラウンドで処理し、実行する。

  もう一つの機能は、「myupdate.apk」という名のAPKをダウンロードすることで、これは/sdcard/uc /フォルダに保存される。これはおそらく、アップデートコンポーネント用だ。

  「Adrd」のネットワークアクセスは、高速データ使用に繋がり、これは結局、高額料金へと結びつく可能性がある。我々は「Adrd」が「cmnet」、「cmwap」(China Mobile Net)、「uniwap」、「uninet」(China Unicom)に接続しているのを確認しており、「Adrd」は中国のマーケットにのみ配布されているようで、中国のネットワークにのみ特有なものである可能性がある。


- 分析はZimry Ongによる。

あまりにも誇張されている「AutoRun」終焉のニュース

  先週、私はWindows XPテストマシンの一台に、Microsoft Updatesを適用し、「AutoPlayダイアログのAutoRunエントリを、CDおよびDVDドライブのみに」制限するオプショナルアップデートに注目した。

Update for Windows XP (KB971029)

  上の画像から、このアップデートがオプショナルであることが分かるだろう。

  だが、同アップデートに関するMicrosoftのブログ記事は、これを「重要な非セキュリティアップデート」と呼んでいる。

  重要なアップデートは、Microsoft Updatesにより自動的に適用される。

  その結果、多くの歓喜が起こり、AutoRunは終焉を迎えたと宣言された

  しかし、ちょっと待って欲しい!

  Larry Seltzerの(Microsoftの声明に基づいた)技術的に正確なAutoRun削除に関する記事に、Microsoftからの訂正を含むもう一つの記事が続いた。

  「Autorunの機能性の変化は、当面、Windows XP用のオプショナルとされる。OptionalおよびImportantアップデートの両方をインストールするよう自動アップデートをセットしているユーザは、すでに同アップデートを獲得し始めた。我々はこれから数週間のうちに、Importantにリセットする予定で、それによりAutomatic Updateを使用している残りのXPユーザ層に到達が可能になる。」

  「Microsoftは、これはミスコミュニケーションであり、間違いではないと語っている。」

  したがって、AutoRunは生き続けており、MicrosoftがWindows XPに対し、同アップデートをOptionalからImportantに変更しても、アップデートKB971029は非光学式メディア機能を制限するのみだ。

  だから…AutoRunを制限するには、手動でMicrosoft Updatesを動作させる必要がある。AutoRunを完全に終わらせるには、ここをクリックし、「fix it for me」オプションを使用して欲しい。

では。
ショーン

「Stuxnet」再び

stuxnet  久しぶりに登場した最も重要なマルウェア「Stuxnet」は、フォレンジックな観点から見ると興味深い機能をいくつか有している。たとえば、新しいシステムを感染させる際、日付、時間、感染したコンピュータのいくつかのシステム情報を記録する。

  これにより、「Stuxnet」が拡散する仕方のタイムラインを作成することが可能になる。

  我々は、収集した全ての「Stuxnet」サンプルをSymantecと共有した。概して彼らは、複数のセキュリティベンダから、3000以上の固有のサンプルを集めることができた。

  次に彼らは、サンプルをクロスリファレンスし、いくつかの興味深い事実を発見した。たとえば:
  • 「Stuxnet」は5つの異なる組織に対する標的型攻撃だった。
  • 2009年6月、2009年7月、2010年3月、2010年4月、2010年5月に標的とされた。
  • 標的とされた組織は全てイランに存在する。
  詳細についてはSymatecのブログの記事を参照して欲しい。


Nokia Windows Phoneとセキュリティ

Nokia, Windows Phone 7  Nokiaは今日、将来のスマートフォン用主要オペレーティングシステムとして、Windows Phoneを採用すると発表した

  世界最大の携帯電話メーカによるものであることを考えると、歴史的発表だ。

  大多数のPCマルウェアはWindows向けに書かれているが、「Windows Phone 7」は全く異なる状況だ。

  「Windows Phone 7」のセキュリティモデルは、Windows XP/Vista/7等とは全く異なり、Application Certification、Isolated Storage、Application Isolationといった機能を含んでいる。たとえば、サードパーティのアプリケーションは、セキュリティの問題から、バックグラウンドで動作することはできない。

  「Windows Phone 7」および「XBOX」は、ユーザがアプリケーションを動作させる以前に、Microsoftにより事前に承認されなければならない唯一のMicrosoftプラットフォームだ。

  その結果、我々はNokiaの参入により、何らかの主要なモバイルマルウェアが発生するとは考えていない。





 

USBオートランを制限する:Windows用アップデート(KB971029)

  Microsoftによる昨日のオプショナルソフトウェアアップデートには、Windows XP/Vista/non-Windows 7用のアップデート(KB971029)が含まれている。

KB971029

  これは「AutoPlayダイアログでのAutoRunエントリを、CDおよびDVDドライブのみに」制限する「重要な非セキュリティアップデート」だ。

  素晴らしい。これはAutoRunワーム抑制するのに実際役立つだろう。もし古いWindowsコンピュータを使用しているなら、このオプショナルアップデートを適用することを強くお勧めする。

  「update.microsoft.com」にアクセスし、「Custom」アップデートを選択する必要がある。

Express and Custom

  そして「Software, Optional」カテゴリで「KB971029」を見つけることができる。

Optional software updates

  このアップデートは、AutoPlayダイアログでUSB AutoRun機能を制限する。さらなる処置をとりたいなら、AutoPlayを完全に無効にすることだ。ここおよびここで、このトピックに関する記事をご覧頂きたい。

「SHA-1+salt」はパスワードに十分だと思いますか?

  アナーキーなインターネットグループ「Anonymous」が先頃、HBGary Federalとルートキットテクノロジの分析と開発に専心しているオンラインフォーラム「rootkit.com」をハッキングした。「rootkit.com」の全ユーザパスワードに障害が起きている。

  この件に関連して、アプリケーションセキュリティで気に入っているトピック、すなわちパスワードハッシュについて指摘したい。

I've forgotten your password again, could you remind me?

  Web(およびその他の)アプリケーションが、ユーザパスワードのハッシュにMD5、SHA1またはSHA-256を使用しており、先進的なデベロッパさえ、そのパスワードをsaltしている。そして私は長年に渡って、salt値はどのように生成されるべきか、どのくらいの長さであるべきかについて、白熱した議論を目にしてきた。

  残念なことに、ほとんどの場合、MDおよびSHAハッシュファミリーは計算速度のために設計されており、そして「rootkit.com」で起こったように、salt値のクオリティは、攻撃者が完全なコントロールを握ったとき、重要ではないという事実が見逃されている。攻撃者がルートアクセスを有するとき、彼らはあなたのパスワード、saltおよびあなたがパスワードを確認するために使用するコードを獲得する。

  そして、どんなセキュリティ設計でも基づくべき推測は、攻撃者がサーバ上のすべてにアクセス可能である、ということだ。

  saltは主として、レインボーテーブルとしても知られる、事前計算された攻撃を防止することを目的としている。そして事前計算された攻撃が防止される限り、たとえ攻撃者がユーザパスワードと共にsalt値を獲得したとしても、パスワードは比較的安全だと、一般に推測されてきた。

  しかしMDおよびSHAハッシュバリアントは、計算速度のために設計されており、これは、処理用のビデオグラフィックスディスプレイカードを使用すると、攻撃者が1秒に何億ものブルートフォースを容易に試みることができるということを意味する。

  以下を参照:http://www.golubev.com/hashgpu.htm

  すなわち、単一のATI HD 5970でさえ、攻撃者は33日で典型的レインボーテーブル(2^52.5ハッシュ)に相当するパスワードスペースをカバーすることができる、ということを意味している。そしてシリアスな攻撃者が、仕事に複数のカードを使用していることは間違いない。

  攻撃者があなたのsalt値とコードを獲得した場合、ユーザアカウントを保護するものは、使用されているパスワードの強度しかないが、我々はあまり、エントロピーの良いソースであるとは言えない。辞書攻撃とブルートフォースの手法を組み合わせることによって、多くのアカウントを持つ大規模サイトであっても、かなりの量のパスワードを破るのに、それほど長い時間はかからないだろう。

  このような事態を避けるには、どうすべきだろう?

  最初に考えるべきことは、パスワードが現実世界の金庫に非常に似ているということだ。重要なのは、中身を守る金庫を開けるのに必要なコードの長さだけでなく、開けるのにどのくらいの時間が掛かるかということだ。

  これは、SHA1あるいは他のプレーンなハッシュアルゴリズムは明らかに、セキュアなパスワード認証向きではないことを意味している。

  我々が使いたいのは、ブルートフォースに対して無力でないものだ。1秒あたり23億回の試みを行う代わりに、あなたは攻撃者を10,000回あるいは100,000回の試みに制限する何かを望むだろう。

  そしてsalt値の使用は適切なインプリメンテーションに不可欠であるものの、あなたの問題を解決する確実な方法ではないのだ。

  それには、以下のプロパティを満たすパスワードハッシュスキームが必要だ:

  •  処理パワーが増大した場合、必要とされる計算時間を容易に調節することができる。
  •  各ユーザが反復の固有番号を持つことができる。
  •  各ユーザハッシュがユニークであり、2人のユーザが同じパスワードであるかを、ハッシュを比較して知ることが不可能である。

  以下から、こうしたスキームをいくつか選ぶことができる:

  •  PBKDF2 http://en.wikipedia.org/wiki/PBKDF2
  •  Bcrypt http://www.openwall.com/crypt/
  •  HMAC http://en.wikipedia.org/wiki/HMAC

  各選択肢はそれぞれの強みと弱みがあるが、これらは全てSHA1+saltのような汎用ハッシュのインプリメンテーションより、はるかに強力だ。

  よって、あなたがパスワードを扱っているなら、上記のスキームのうち1つを選び、望ましい時間(10、200msなど)内にサーバがパスワードをチェックする反復の回数を決定し、それを使用する。攻撃者が各反復で全アカウントに対して試せるようにするのではなく、各アカウントに個別にフォーカスさせるよう、各ユーザに対してユニークなsalt値と反復カウントを用意することだ。

「Brain」から「Stuxnet」へ:コンピューターウイルスの25年

  われわれは、PCマルウェアの25年の歴史を9分間で振り返るビデオを発表した。

  同ビデオには、昔のウイルスがどのように見えたかに関する、いくつかのデモが含まれている。

  ここからチェックして欲しい。



Safer Internet (Update) Day

  2月8日は、子供たちにとってインターネットをより良い場所にすることを目指す日、「Safer Internet Day」だ。あなたのお子さんがオンラインになる前に、彼らのコンピュータがセキュアなソフトウェアで最新の状態になっていることを確認したい。今月は、インストールすべきアップデートやパッチが数多く登場している。

  Microsoftの「セキュリティ情報」には、全バージョンに影響を与える「Internet Explorer」用のアップデートが含まれている。

Microsoft Security Bulletin February 2011

  最も影響の少ないOSは「Windows XP Service Pack 3」であることに注意したい。「Service Pack 2」は昨年、アップデートサイクルから外れたからだ。子供たちはしばしば、「お下がりの」コンピュータを与えられる。子供に古いハードウェアを与える前に、現在のサービスパッックがインストールされていることを確認しよう。代用のブラザも考慮すべきだ。

  とはいえ、他の選択肢もまた、不安要因が無いわけではない。

  Googleは最近、「Chrome」をバージョン9.0.597.84に修正した。

  もう一つのポピュラーな選択肢であるVLCメディアプレーヤには、悪意ある攻撃者が任意のコード実行を誘発する事が可能になる、無効なMKVファイルをパースする際の欠陥がある。VLCメディアプレーヤー1.1.7はこの問題に対処しているので、アップデートするか、信頼できないダウンロード(そしてVLCプラグインをインストールしているなら信頼できないサイト)を避けることだ。

  Adobeも今日、Adobe ReaderおよびAcrobat用のアップデートをリリースしている。影響を受けるバージョンは、WindowsおよびMacintosh用のAdobe Reader X (10.0) およびそれ以前のバージョンだ。

「Poika」を連れて街を練り歩く

  我々フィンランド人は、スウェーデン人が嫌いだ。

  これはホッケーに関連している。

  ご承知の通り、ホッケーはフィンランドの国技だ。なのに我々はたいてい、スウェーデンに負けてしまう。

  だが負けなかったときは、盛大にお祝いする。

  我々の伝統の一つに、我がホッケーチームがトロフィーをあらゆる所に持って行くというものがある。そしてトロフィーは常に「Poika」(フィンランド語で「息子」)と呼ばれる。

  ところで、エフセキュアは「AV-Comparatives Product of the Year」アワードを受賞したばかりだ。

  以下が、我々の獲得したトロフィーだ:

F-Secure - AV-Comparatives Product of the Year

  我々は伝統を受け継ぐべきだと考えた。

  以下は、街を練り歩く我々の「Poika」の様子だ:

F-Secure - AV-Comparatives Product of the Year
エフセキュア本部の側の「Poika」

F-Secure - AV-Comparatives Product of the Year
ヘルシンキ大聖堂近くの「Poika」

F-Secure - AV-Comparatives Product of the Year
ヘルシンキ中心部の「Poika」

F-Secure - AV-Comparatives Product of the Year
公園の「Poika」

F-Secure - AV-Comparatives Product of the Year
雪の中、一人たたずむ「Poika」

F-Secure - AV-Comparatives Product of the Year
Esplanadi Parkの「Poika」

F-Secure - AV-Comparatives Product of the Year
Valtioneuvoston Linna側の「Poika」

F-Secure - AV-Comparatives Product of the Year
海辺の「Poika」

F-Secure - AV-Comparatives Product of the Year
マーケットスクエアの「Poika」

F-Secure - AV-Comparatives Product of the Year
氷結した海を見つめる「Poika」

F-Secure - AV-Comparatives Product of the Year
サウナで温まる「Poika」

F-Secure - AV-Comparatives Product of the Year
「Poika」とKiasmaアートギャラリー

F-Secure - AV-Comparatives Product of the Year
「Poika」と国会議事堂(左)

F-Secure - AV-Comparatives Product of the Year
ニコライ2世号と凍える「Poika」

P.S. AV-ComparativesおよびAV-Test.org(リンク)による最新のテストで、我々は他社全てを凌駕した。これらのテストには、スピードのほか検出率も含まれている。これにより、エフセキュアは「The Best Antivirus in The World」となった。

情報セキュリティの日に

2月2日は情報セキュリティの日ということで、情報セキュリティへの意識と理解を深める日だそうです。由来はよくわかりませんが記念すべき日という事ですので、情報セキュリティへの意識と理解を深めるために普段私がやっている遊びを紹介します。
ウイルスを一つ、はじめに用意します。せっかくなのでなるべく誰が見てもウイルスだというもののほうがいいです。

vt_default

きれいにほぼすべてのアンチウイルスソフトでウイルスと判定されています。使用しているのは数年前のウイルスですが、なかなかいい素材です。
まずは簡単に検知できそうなものということで、メジャーなパッカーであるUPXでパックしたもので調査してみます。

vt_upx

しかし思ったより検知できないアンチウイルスソフトがあることがわかりました。単純にツールを使うだけでもアンチウイルスソフトをだますことができるようです。
今度は気を取り直して逆アセンブルして中身を少しだけ書き換えてみましょう。
例として、一番始めの命令を1バイトだけ書き換えてみます。

editbyimm

vt_imm

かなり減りましたね。
ラストは思考を変えて実行ファイルを壊してみます。

broken

vt_broken

もはやファイルは壊れていて実行できないので、検出しないほうが正しいのですが検知してしまいました。よくある誤検知(False Positive)というやつですね。

労力をかけて工夫していけば、どのアンチウイルスソフトにも検知されないようにもできると思います。試行錯誤しているとPEファイルの構造など、勉強にもなります。繰り返しいるうちに各アンチウイルスソフトの特徴も見えてきて、情報セキュリティへの意識と理解も深まるのではないでしょうか。
バックナンバー
セキュリティ関連リンク
セキュリティ機関

政府関連

セキュリティ関連団体

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

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

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

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

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