エフセキュアブログ

by:岩井 博樹

AutoItScript→VBScriptによる検出回避とか

2013年8月頃よりマルウェア開発者らのコミュニティ内でマルウェアをVBScriptへ変換を依頼するなどのスレッドを見かけるようになりました。
下図は一例で、或るRAT(Remote Administration Tool)をVBScriptへ変換して欲しい、といった依頼のものです。

convert request

既存のマルウェアをわざわざ他の開発言語で作り直す主な理由として、
  ・一時的なセキュリティ対策ツールの回避
  ・VBScriptなどのスクリプト言語ではエンコード処理が容易
  ・スクリプト言語への変換、公開により別の開発者が登場し、機能面などで機能向上が期待
などが挙げられます。
いずれにせよ、マルウェア開発者側にこのような動きがあるということは、次のサイバー攻撃の流れとして融通がきき易いスクリプト言語ベースのマルウェアの脅威が増大すると予測できそうです。
ちなみに、現在ちらほら確認しているのはZeuSの亜種でも利用されているとされるAutoItScriptからVBScriptへの変換です。
(このAutoItScriptで開発されたマルウェアの増加に関してトレンドマイクロ社のブログで報告されています。)
#ZeuS自身の変換は見た事ありませんが、ソースコードが流出していることを考えると有り得るかも?
傾向からしますと、VBScriptの利用が目立っていますので、そういった意味では対応策を考え始めた方が良いかもしれません。
下の記事に主な対応策が記載されていますので、参考にしてみては如何でしょうか。

VBScript Malware Demo using FileSystemObject


AutoItScriptで開発されたマルウェアについて
補足で、上述のAutoItScriptについて触れてみたいと思います。
AutoItScriptはAutoItがインストールされた環境下でなければ動作しません。そこで、AutoItにより
スクリプトをコンパイルしますとUPXによりパックされEXEファイルとして出力することができます。
但し、コンパイルした結果は、
  ・UPXの利用はプログラムの善悪に関係無く、一部のセキュリティ対策ツールに検出されてしまう
  ・EXEファイルはサンドボックス型のセキュリティ対策ツールで検出されてしまう可能性がある
  ・AutoItで作成したことはすぐに分かってしまう
などの理由によりセキュリティ対策ツールに処理されてしまう可能性が高まります。
そこで、攻撃者らは試行錯誤した結果、解決策のひとつとしてソースコードの変換を考えたと推測されます
参考までに変換前と後は下のサンプルのような内容となります。(イメージだけ・・・)
サンプル1:AutoItScript
FUNC __IS_SPREADING ()


LOCAL $W_KEY = STRINGSPLIT (@SCRIPT,".")
$SPREADING = REGREAD ("HKEY_LOCAL_MACHINE\SOFTWARE\" & $W_KEY[1],"")
IF  $SPREADING = "" THEN
     $SPREADING = "FALSE"
     IF  STRINGUPPER (STRINGMID (@FULLPATH,2)) = STRINGUPPER (":\" & @SCRIPT) THEN $SPREADING = "TRUE"
     REGWRITE ("HKEY_LOCAL_MACHINE\SOFTWARE\" & $W_KEY[1],"","REG_SZ",$SPREADING)
ENDIF
ENDFUNC
サンプル2:VBScript
spreading = shellobj.regread ("HKEY_LOCAL_MACHINE\software\" & split (install,".")(0) & "\")
if spreading = "" then
   if lcase ( mid(wscript.scriptfullname,2)) = ":\" &  lcase(install) then
      spreading = "true - " & date
      shellobj.regwrite "HKEY_LOCAL_MACHINE\software\" & split (install,".")(0)  & "\",  spreading, "REG_SZ"
   else
      usbspreading = "false - " & date
      shellobj.regwrite "HKEY_LOCAL_MACHINE\software\" & split (install,".")(0)  & "\",  spreading, "REG_SZ"

   end if
end If  

実際はサンプル2からさらにエンコードされますので、可読性のあることは殆どありません。意識せずにみると、
複数のマルウェアが存在するように見えます。ここまでのイメージとしては、次のようになります。元はひとつの検体なのですが、自由度の高い(?)言語に変換することで形体を変化させ生存率を高めているわけです。

autoit

最終的にエンコードや暗号処理を用いていますので、検体そのものを被害PC上よりピンポイントで発見することはなかなか骨が折れそうです。また、
暫くはサイバー攻撃手法に変化が起こるというよりは、このような回避手法とのいたちごっこが続くと考えています。このような状況を踏まえますと、利用頻度が低いスクリプトなどは予め動作制限をしておき、脅威レベルを軽減しておいた方が安心かもしれません。

 

UNRECOMは今後のRATの主流になれるか

2013年も12月となり、今年も残り僅かとなりました。そんな中、Java RATのひとつであるAdwind RATがUnrecom Soft(UNiversal REmote COntrol Multi-Platform)に買収され、新たな展開をみせようとしています。
Adwindは、Android RATの1つであるAndroRat(流出したソースコードと推測)をベースとしたAndroidの遠隔操作機能を追加し、クロス・プラットフォーム(Windows、MacOS、Linux、Android)の統合管理をいち早く実現したことで知られています。
このことは他のRAT開発者らにも影響を与えたとも考えられ、今後のトレンドを占う意味でも注目のRATであったと思います。

unrecom

このようにPCとスマートフォンが攻撃者により統合管理され始めますと、それらを繋ぐオンライン・ストレージなども標的となる可能性も出てくるのでは?と勘ぐりたくなりますね。
どの程度の実現性があるか分かりませんが、リスクの対象範囲は徐々に拡大し始めているようです。
※Adwindは2013年11月20日以降は利用できなくなっています。

アナウンス

さて、Unrecomの機能面ですが、現在のところほぼAdwind v3.0と同様です。Adwindの特徴でもあるPluginを一通り引き継いでいます。遠隔操作をする際に、あると便利なものは一通り揃っているようです。今後どのような機能が追加されるのかが興味深いところです。注目はAndroid向けのPluginをどの程度充実させてくるか、でしょうか。
ちなみに、下図にあるFunnyのようなお遊び的なものもあります。利用価格は$10。

Funny:
It this a simple funny option for move the mouse of remote pc and push aleatori keys


plugins



尚、現在のところ検出状況は芳しくありません。アンチウイルスソフトでの検出結果はマチマチな状況です。。
但し、次のようにSnortのシグネチャも公開されていますので、IDS/IPS等による検出も可能ですので、被害にいち早く気付くことは出来そうです。(少なくともUnrecomの仕様に変更がなければ、です。)

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg: "[CrowdStrike] -RECOMM/Adwind Default Password Auth"; \flow: to_server, established; \
content: "|00||28|e3a8809017dd76bd26557a5b923ab2ae16c0cdb3"; \
sid: 1981310201; rev: 20131115)


alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg: "[CrowdStrike] -RECOMM/Adwind Ping/Pong"; \
flow: to_server, established; dsize: 1024; \
content: "|00 00 53 09 58 58 58 58|"; depth: 16; \
content: "|58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58|"; offset: 1008; \
sid: 1981310202; rev: 20131115)

    参照URL:
    http://www.crowdstrike.com/blog/adwind-rat-rebranding/index.html


Java RATは以前より存在しましたが、今年6月頃より実用化されてきています。現在のところ大規模な攻撃情報は聞いていませんが、サイバー犯罪の世界では一般的になってくるのではないでしょうか。
何はともあれ、来年はJava RATやAndroid RATから目が離せません。


追記:
   かなり粗いですが、yara signatureです。
{
 strings:
  $Class = /opciones\/\w+\.class/
  $made = "desinstalador/MaDe.adwind"
  $gcon = "JTextPaneExample.class" nocase
  $plugin = "AdwindServer.class" nocase
 condition:
  any of ($Class) and ($made or $gcon) or $plugin
}

KINSのソースコード流出にみるサイバー犯罪対策の難しさ

オンラインバンキング詐欺ツールで知られる「KINS」のソースコードが、遂にアンダーグラウンド系フォーラムに流出しているのが確認されました。これにより、オンラインバンキングの利用者を狙ったサイバー犯罪はさらに複雑化していくことが予想されます。

KINSとは今年7月頃に報告され、次代のZeuSやSpyEyeと呼ばれる不正プログラムの1つです。

9月末にKINSの詳細情報が報告されました。10月10日頃よりセキュリティ専門家より一部の捜査機関、およびセキュリティベンダー等にKINSソースコードが配布され始め、ようやく対策が取られ始めたところでした。
#ソースコードの入手の際には所属組織、氏名、職位等の情報が必要。

参考
http://touchmymalware.blogspot.ru/2013/10/kins-source-code-leaked.html
http://www.xylibox.com/2013/09/having-look-on-kins-toolkit.html
http://pastebin.com/T1A80ZYF
https://blogs.rsa.com/is-cybercrime-ready-to-crown-a-new-kins-inth3wild/


KINS source code

ところが、先週この配布されたソースコードはあっさりと流出したことが確認されました。
KINSのソースコードは、配布者の承認を得たセキュリティベンダー等とされているだけに非常に残念な事です。
#インテリジェンスの共有が難しいのは、この辺りでしょうか。

leaked source code

残念ながら、KINSが完全に検出はできない状態ですが、かろうじて救いなのは、KINS自体は一部の関連ファイルから見て取れるように、ZeuSがベースとなっていることでしょうか。そのため、実行時にZBOTもしくはSpyEye関連のファイルとして検出されることがあります。例えば、次に示す関連ファイルはその典型です。

bot32.dll

参考URL
https://www.virustotal.com/en/file/8c8055c9e972ab37d0880f2b8f63605be52babd779a29e78be3647194ef31aa2/analysis/

また、Dropperに限定されますが、AlienVault-LabsからYaraのルールが提供されています。
https://github.com/AlienVault-Labs/AlienVaultLabs/blob/master/malware_analysis/KINS/kins.yar
オリジナルルールが追加可能なセキュリティ製品を所有しているのであれば、このルールを参照してみるのも良いかもしれません。

勿論、組織としてこれらの対策を講じることは大事ですが、まずは個々の口座で不正送金等が無いかの確認をする方が先決です。


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

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


Android RATのオープンソース化で行きつく先は・・・


2011年に著名なBotであるZeuSのソースコードが流出したことは記憶に新しいです。その後、CitadelやKINSなどのBotの開発コミュニティは活性化し、サイバー犯罪に悪用される不正プログラムはより高度化したように思います。併せて、Malware as a Serviceの市場も拡大し、サイバー犯罪被害の増大に滑車を掛けました。(下図はCitadel Botnet Build Serviceの例)

citadel1

このような状況になった切っ掛けは、前述したソースコードの流出が要因の1つと考えられるわけですが、それが意図的であったかどうかは分かりません。しかし、結果として情報がオープンになったことで、それらの産業(?)は飛躍的に伸びたことは間違いなさそうです。
また、最初から不正プログラムをオープンソースとして配布したり、APIを公開するなどしコミュニティからアイデアを募ることで開発力を高めている例も少なくありません。

この流れはPCを対象としたマルウェアだけでなく、Androidにおいても幾つか確認されています。
例えば、AndroRatなどはその典型です。このRatはオープンソースとして配布されており、案の定、公開と同時に悪用が確認され、犯罪利用の増大が懸念されています。(下図はAndroRatのソースコードの一部)

androrat1

また、今後追加されるであろう機能についても注目されています。先ず、AndroRatの標準の機能においては、次のものがあります。
#他のRatでも確認できる標準的な機能を有しているように思います。
  • Get contacts (and all theirs informations)
  • Get call logs
  • Get all messages
  • Location by GPS/Network
  • Monitoring received messages in live
  • Monitoring phone state in live (call received, call sent, call missed..)
  • Take a picture from the camera
  • Stream sound from microphone (or other sources..)
  • Streaming video (for activity based client only)
  • Do a toast
  • Send a text message
  • Give call
  • Open an URL in the default browser
  • Do vibrate the phone
これに対し、他のオープンソースのAndroid Ratで追加が予定されていた機能として次のようなものがあります。これらのアイデアがAndroRatに取り込まれるかは分かりませんが、少なくともこういった機能を有するRATが登場する可能性はある、とは言えそうです。
#ちなみに、この開発プロジェクトは現在ストップしています。
  • Facebook Poster
  • Twitter Poster
  • Password Stealer 
  • Screenshot look
  • Root All Android Devices! (With 30 Working official verizon/at&t/sprint/Phonebooth ROMS)
  • Look At cam
  • LOAD ALARM
  • Time Changer
  • Text Reader
  • File Manager
この中で個人的に気になったのは、パスワード・スティーラーやスクリーンショットの閲覧、ルート化でしょうか。現在、Androidをはじめとしたスマートデバイスから、金融機関(銀行や証券会社など)を含め様々な取引きが可能です。この点を踏まえますと、上述の機能は非常に脅威です。
これらのアイデアが他のAndroidマルウェアにどの程度取り込まれるかは分かりません。しかし、Androidマルウェアのソースコードの公開により、この他にもサイバー犯罪の敷居を下げるような機能がが次々と登場するのは時間の問題かもしれません。(考え過ぎかもしれませんが。。。)
ちなみに、AndroRatはコンパイルサービスが確認されています。Androidマルウェアに関しても近い将来、本格的なMalware as a Serviceなどが提供されるようになるかもしれません。




人気のJava Exploitに改めて注意

現在、UGマーケットではJavaの脆弱性に関連した商品やサービスに注目が集まっています。
下図のようにJavaの脆弱性を標的としたEaaS(Exploit Pack as a Service)が提供されるなど、その注目度の高さが窺えます。このサービスでは、BASICとPROFESSIONALで提供されるExploitコードのタイプが異なります。端的にいえば、PROFESSIONAL版の方は標的に気付かれづらい作りになっています。6ヶ月間で50USDの差額をどう考えるかですが、ビジネスとしてサイバー攻撃を行っているグループには安い買い物でしょう。

security pack


このような背景があってかわかりませんが、2012年は日本国内を含め、ウェブ改竄被害が大変多く報告されています。先日、IPAよりウェブサイトの改竄に対して注意喚起が出ており、2013年も増加し続けています。国外の状況を含め調査しますと、これらの被害サイトの多くには悪性コードが挿入されたり、設置されています。複数のウェブサイトにおいて、類似ケースも確認されていることから、EaaSやSpreader等のサービスが利用された可能性は高いと考えられます。

このような現状に対し、IPAではこの注意喚起の中では、対策として主に次の3点を改めて推奨しています。
・Windowsの自動更新を有効に
・各種プログラムを最新に
・アンチウイルス以外の機能も持つ「統合型セキュリティソフト」の活用

いずれも基本的な対策であり、且つ大変重要な対策です。上図でも確認できるように、EaaSや一部のWeb Exploit Packではアンチウイルスソフトを回避するために、利用するExploitコードや不正プログラム等をチェックするためのツールが提供されています。そのため、アンチウイルススキャンのみでの検出が難しい場合があります。
この点を踏まえますと、上述の対策は最低限実施しておきたいところです。
また、UGマーケット内でのJava Exploitの人気を考えますとウェブブラウザのJavaを無効化等の対策も実施しておくとさらに安心です。

何はともあれ、これらの背景を踏まえますと、
・PCはJavaへの対応策は万全か
・ウェブサーバに覚えの無いコンテンツが設置されていないか
・アクセスログに不審なログは無いか(そもそも適切にログが取得されているか)

など改めて確認されてみては如何でしょうか。
併せて、攻撃トレンドの変化に付いていけるようにExploitコードや不正プログラム等の情報チェックも忘れずに。


g01packがシェア拡大の兆し

多段攻撃を介してペイロードを配布することが報告されたばかりのg01pack exploit kitがシェアを伸ばしているようです。
4月上旬くらいまではBlackHole exploit kitの改ざん被害が相次いでいましたが、ここ数日の間に変化が見られています。

Web Exploit Kitの統計情報を確認しますと、3月〜4月上旬までは、明らかにBlackHole exploit kitの検出率が多いことが分かります。

g02pack1

ところが、ほぼ1ヶ月が経過した4月23日頃からg01pack exploit kitの件数が増加し始めています。
#任意のスキャン結果ですので網羅性はありません。


g01pack2
参考:urlquery.netのスキャン結果より

これらの活動がBlackhole exploit kitに関係したものであるかは不明ですが、g01pack exploit kitのシェアが拡大している可能性はありそうです。
とりあえず、対応のおさらいを以下に記載します。

■端末への対応
Javaの脆弱性(CVE-2012-1723)が悪用されていることが確認されています。既に対策済みである組織が多いとは思いますが、念のため最新の脆弱性に対しても対応しておくことを推奨します。

参考URL:
Oracle Java の脆弱性対策について(CVE-2013-2383等)
https://www.ipa.go.jp/security/ciadr/vul/20130417-jre.html
2013年4月 Oracle Java SE のクリティカルパッチアップデート (定例) に関する注意喚起
https://www.jpcert.or.jp/at/2013/at130021.html
WebブラウザでJavaを無効にするにはどうすればよいですか。
https://www.java.com/ja/download/help/disable_browser.xml


■サーバへの対応
改ざんされたウェブサイトへの対応ですが、現在のところ手口が分かっていません。基本的な対応として、
・セキュリティパッチの適用状況
・アクセス制限
・パスワードの強度
などは見直しておくと安心です。また、ホスティングサービスやクラウドサービスなどを利用している場合ですが、管理用のアプリケーション(Parallels Plesk Panelなど)も攻撃対象となりますので注意が必要です。

■IDS/IPS等での対応
g01pack exploit kitに関するシグネチャは主なセキュリティ対策製品により対応済みです。万一、対応されていない場合は、Snortなどのシグネチャを参照ください。

参考:
http://pulsifer.ca/drop/CNDA/snort/snort.doc
https://lists.emergingthreats.net/pipermail/emerging-sigs/2012-September/020415.html


昨年から続いていたBlackHole exploit kitの大規模改ざんと同様に、g01pack exploit kitも過去に大規模なウェブ改ざんにより設置した経緯があります。
恐らく一定の操作は自動化されていることが考えられ、同様の攻撃は継続して行われる可能性があります。
不正に設置されたウェブコンテンツの有無や、SSHなどのメンテナンス経路などに対策の不備が無いか再確認されることをお勧めします。
何か新しい動きがありましたら、随時追記していこうと思います。





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

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

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

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

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

kill_os

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

グリーティングカードを装った標的型メールに注意

グリーティングカードを装った標的型メールが複数確認されています。
実在するサービスなので、ついクリックしてしまいそうですのでご注意ください!

greeting_card

今回、確認したケースでは記載されたURLへアクセスしますと、CVE-2013-0422(Javaの脆弱性)を悪用する攻撃コードが実行される仕組みとなっていました。
Javaの脆弱性を狙った攻撃は今後も継続することが予想されますので、特に必要のないユーザはアンインストールしておいた方が妥当かもしれません。

ちなみに、ダウンロードされる攻撃コードはmetasploitにより作成された可能性があります。
metasploit用に開発された攻撃コードの多くは研究し尽くされていますので、標的型攻撃で利用されるのは珍しいケースだなぁ、と思いました。(広範囲に対しての攻撃だったのかもしれませんが。)
もしかすると、実験的な攻撃なのかもしれませんね。

jar


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

Oracle Java 7の脆弱性を狙った攻撃について

28日にJVNに登録されたJavaの脆弱性(0day)が話題です。
影響範囲は、Java 7 (Java SE7, JDK 7, JRE 7)となっています。
既に攻撃コードを悪用したウェブサイトも複数報告されており、警戒が必要な状況となっています。

JVNにも記載されていますが、現在のところOracle社からはセキュリティ・パッチが配布されていません。そのため、一時的な対策としてウェブブラウザのJava Plug-inを無効化することが推奨されています。

現在確認されている悪性サイトには、次のようなコードが含まれており、Javaの脆弱性を悪用後にDrive-by Downloadによりマルウェアをインストールします。
※実際はDadong's JSXX 0.44 VIPにより暗号化されています。Dadong's JSXXは過去にChinese Packと呼ばれるExploit Kitが利用していたことでも知られています。

js_java0day

今回確認された悪性サイトよりダウンロードされるマルウェアに関しては、殆どのウイルス対策ソフトウェアが対応しています。
(ちなみに、F-SecureではGen:Trojan.Heur.FU.bqW@a4uT4@bbで検出します。)
尚、筆者が確認(28日19時頃)したところ、まだ一部の悪性サイトはアクティブなようです。

【WindowsでのJava Plug-inの無効化】
IEの場合は、次のサイトの情報が参考になります。幾つか方法が紹介されていますので、参考になればと思います。

http://www.kb.cert.org/vuls/id/636312
http://kb.iu.edu/data/ahqx.html
https://krebsonsecurity.com/how-to-unplug-java-from-the-browser/
     
【MacOSXでのJava Plug-inの無効化】
OSXの場合はこちらが参考になります。
http://www.maclife.com/article/howtos/how_disable_java_your_mac_web_browser
https://krebsonsecurity.com/how-to-unplug-java-from-the-browser/

safari_javaoff
                SafariのJava Plug-in無効化の例

SANS Internet Storm Centerの記事にもある通り、セキュリティ・パッチが公開されるまで時間がかかりそうです。
The next patch cycle from Oracle isn't scheduled for another two months (October.)
恐らくWeb Exploit Packなどにも組み込まれるのも時間の問題と予測されますため、早めの対策を推奨します。特にBlackhole Exploit Kit などは非常に不気味です。

また、IPSやアンチウイルスゲートウェイなどのセキュリティ機器による対策ですが、パッと思いついた対策を3つ挙げますと、ありきたりですが次の対策を実施しては如何でしょうか。
(1)Web Exploit Packの検知ルールを確認する(念の為)
(2)既知の攻撃コードの検知ルールを適用する
(3)既知の悪性サイトをブラックリストに登録する
とりあえず、現在報告されているドメインは次の3つがあります。
ok.aa24.net
59.120.154.62
62.152.104.149

(2)はMetasploitにより生成された攻撃コードと現在確認された悪性サイトで悪用された攻撃コードの両方を想定しておいた方が良いかもしれません。
今回確認された悪性サイトに関しては、特徴としてDadong's JSXX Scriptを利用していますので、既存のSnortのルールを参考にして作成してみるのも手だと思います。
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET CURRENT_EVENTS JavaScript Obfuscation Using Dadong JSXX Script"; flow:established,to_client; file_data; content:"Encrypt By Dadong"; distance:0; classtype:bad-unknown; sid:2014155; rev:2;)

今後、この脆弱性を悪用する攻撃サイトが増加することが予想されます。
現状ではウイルス対策ソフトウェアの定義ファイルを最新の状態にするなどの一般的な対策を見直すことも忘れずに実施しておきたいところです。
当面、関連情報がセキュリティ関連サイトに次々とアップデートされていくと思いますので、情報収集もお忘れなく。。。

私も効果の高い対策がありましたら、随時更新したいと思います。
ではでは。

【参考情報】
http://www.deependresearch.org/2012/08/java-7-0-day-vulnerability-information.html
http://labs.alienvault.com/labs/index.php/2012/new-java-0day-exploited-in-the-wild/
http://blog.fireeye.com/research/2012/08/zero-day-season-is-not-over-yet.html

Poison Ivyにみるマルウェアの隠し場所


最近、「マルウェア感染したと思うのだが、アンチウイルスソフトや不正プログラム抽出ツール等を試したが何も見つからない」といった話をよく耳にします。
その多くは、IDS/IPSやURLフィルタなどにより不正通信を検出しているのですが、いざPCを調べると何も見つからない、といったものです。
#当然、マルウェア作成側も念入りにアンチウイルスソフト等では検出されないように設計していますので、そう簡単には見つからないです。

そこで、今回は検出されずらいマルウェア隠し場所とその検出方法の一例を紹介してみたいと思います。少しでもお役に立てて頂ければ幸いです。

今年に入ってから、ときどき見かけるものとして、古典的な手法ですが、ADS(NTFS代替データストリーム)を利用してマルウェアの本体を隠す手口です。
この手口を悪用するものとして、例えば最近人気(?)のPoison Ivy(トロイの木馬)などがあります。
Poison Ivyの機能に取り込まれたのは、比較的最近のバージョン(2.3.0〜)からですので、攻撃者から見ればそれなりに効果が期待できるということなのでしょう。

Poison Ivyの場合、ファイルを隠すために利用されるフォルダは、Windowsフォルダとsystemフォルダに限定されています。
ディスクエディタ等で確認すると、下図のhkcmds.exe(C:¥Windows¥system32:hkcmds.exe)のような状態となります。
#ADSにより隠されたファイルは、通常のWindowsのエクスプローラー等の操作では見えません。

ads

この隠されたマルウェアに対し(1)〜(3)の操作により検出および抽出を試みます。
(1)Windowsのファイル検索
(2)アンチウイルスソフトによるフルスキャン
(3)ADSファイル検索ツール

これらの操作の結果は、
(1)では見つけられません。恐らく、Windows APIを利用している資産管理ツール等でも見つからないと思います。(未確認)
(2)は5つのソフトウェアをテストしたところ、2つが検出されました。いまいち確実性に乏しいです。
(3)は確実に抽出することが可能です。ADSを検出することに特化してますので当然ですね。

他にレジストリを確認することで検討をつけることは可能ですが、この作業はなかなか骨が折れます。
ちなみに、上の例ですとレジストリは次のような内容が書き加えられていました。

Key: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
 Value Name: HotKeyscmd
 New Value: “C:\WINDOWS\system32:hkcmds.exe”


#感染日時がある程度目星がついており、感染端末の保全状況が良いと比較的容易に見つけられるかもしれません。

今年に入ってから、本ケースのような事例は少なくありません。もしアンチウイルスソフト等では何も検出されていないが、不審な通信を行っている、などの挙動がありましたら一応ADSもチェックしておくと良いかもしれません。
また、何か興味深い事例等ありましたら投稿したいと思います。
ではでは。

中国で開発されたHacktoolの検知に注意

HacktoolやNetToolといったウイルスが検出されたことはありませんか?
ウイルス対策ソフトによっては、HackToolとかNetTool、xxx_Transmit(xxxはBackdoorやTrojan)のような検知名が付けられています。

lcx

これらのツールは感染機能は持たず、攻撃者がC&Cサーバなどと通信を確立するために、しばしば利用されます。
例えば、昨年のRSAの事件で悪用されましたBackdoor.Liondoor(HTran)などがそれにあたります。
ちなみに、Backdoor.Liondoor(HTran)は、2003年頃に中国紅客連盟により開発されたパケット転送ツールです。
※開発元は中国なのですが、他国の攻撃者も利用していますので、一概に中国邉劼砲茲觜況發箸呂い┐泙擦鵝
これらのツールは、プログラムが自動的に感染やバックドアを作成することはありません。攻撃者の操作によりバックドアに悪用されたりするプログラムです。
つまり、一般的な企業環境(?)においてHacktoolが発見された場合、往々にして既に攻撃者が侵入しており何らかの被害を被っている可能性が高いといえます。
この辺は古典的な話ですので、詳細は割愛しますね。

さて、このHacktoolですが悪用されていても中々見つけられない、という相談をよく受けることがあります。
一般に、これらのツールは大抵のウイルス対策ソフトで駆除できますが、駆除されずに悪用されているのはどういうことでしょうか。
マルウェア感染のインシデント対応全般的に言えることなのかもしれませんが、
まず考えられるのは、"検知できない状況"であるということが、理由のひとつとして挙げられると思います。
何故、駆除できないのかの理由は色々ありますが、よく見かけるのは次の3つです。
.Εぅ襯溝从ソフトが停止されている
▲Εぅ襯溝从ソフトの検索対象外の領域が利用されている
6扈すべきHacktoolが被害ホスト上に無い

,蝋況蘯圓管理サーバを不正操作していたり、ホスト上の設定が変更された可能性などが考えられます。
△魯Εぅ襯溝从ソフトの設定やユーザの利用環境などに依存することが多いです。
#製品によってリスクウェアをスキャン対象外にしていると検知できない場合があります。
は被害ホストとは異なるリモート・ホスト上にHacktoolが存在している場合などがあります。
#この場合、攻撃者が不正操作の起点となっている親玉のシステムが存在する可能性があります。その場合、親玉システムの発見に手間取り、被害が収束するまでに時間を要すことがあります。

いずれにせよ、攻撃者がすでに標的のシステムを乗っ取った後の操作となりますので、これらの操作がされていても不思議ではありません。

もしHacktool関連の検知ログが1つでも見つけた場合、(ネットワーク的に)周辺のホストやADのログを至急調査してみてください。
#業務情報などが漏洩していないことを祈りつつ
攻撃の痕跡は、あっという間に削除されますので、スピード勝負となりますが、運が良ければ邉匚具を利用した痕跡が発見されるかもしれません。

気をつけて頂きたいのは、Hacktoolの発見はネットワークトラフィックとホスト上のログとの相関分析が必要となることが多いです。
そのため、基本ではありますが事前にOSなどのログに関しても確実に取得しておくことをお勧めします。特にWindowsのログオン成功のログは重要です。

何はともあれ、Hacktoolが発見された場合はLAN内の複数のシステムが乗っ取られていることを前提に、迅速にダメージコントロールを心がけた動きが重要です。
侵入台数が少ないことを祈りつつ。

最近のマルウェア感染の痕跡 - 画像ファイルへの偽装

最近のマルウェアは非常に巧妙でディスク上、通信などからの発
見は一苦労です。そのため、マルウェア感染の早期発見が、今ま
で以上に重要視されています。
とはいえ、マルウェアの通信に決まったパターンがあるわけでは
ありませんので、簡単には見つからないのが現状ではないで
しょうか。

そこで、今回は少しでも参考になればと思い、最近度々見かける
マルウェア通信のログを紹介してみたいと思います。
ProxyログなどからHTTP/HTTPSへのリクエストログを漁れば、
もしかすると、類似のログが発見できるかもしれません。

今回は、画像ファイルのPOSTのように見せかけ、マルウェアの
感染端末のリモート操作や窃取した情報のアップロードなどの
操作を行っているパターンです。
例えば、次のPOSTリクエスト(抜粋)は最近よく見かけるもの
のひとつです。

post1

中央付近のContent-Disposition以下を参照しますと、画像ファイ
ルらしきファイル(GIF)がPOSTされています。
ところが、よくログを見てみると、画像ファイルにも関わらず
Content-Typeが、"text/plain" となっておりバイナリではありま
せん。
# 一般的には image/gif が利用されます。

実は、このファイルの正体はDOSコマンドの出力結果をXORで
符号化したもので、テキストファイルです。
そのため、Content-Typeには "text/plain" となっています。
# 但し、いろいろ細工はできますので必ずこのようになるとは限
# りません。

つまり、この手口を用いているマルウェアに関して言えば、POST
しているにも関わらず、Content-Typeが矛盾しているものを探せ
ば、見つけられそうです。
Proxyのログ出力の設定などにより探せない場合は、代替となるロ
グから探してみてください。ログが何も無い場合は、ログ収集から
始めるしかありませんが・・・。

尚、高度なステガノグラフィを用いたものや、銀河系の衝突
記事で解説されているようなレベルのものは、残念ながら今回の
簡易的な方法では、すぐに見つかりません。もう一工夫必要です。

ということで、今回は比較的容易に見つけられそうなものを紹介し
てみました。参考になれば幸いです。

では、良いお年を!


ソニーのPSNからの情報漏洩に学ぶ事後対応策の重要性

PSNからの情報漏洩で大騒ぎ中ですが、差し出がましいようですが、私もひとつコメントさせて頂きます。
ちなみに、私も新聞各紙で出ている情報以外は知りませんので悪しからず。

本件は事後対応策を全くしていないかった典型的事例だと思います。
セキュリティ対策は、予防策から事後対応策までバランス良く実施できれば、それに超した事はありません。しかし、運用面やコスト、リソースなどの課題を考えると、中々そうはいかないのが現実です。

ところが、万一事故が発生した際に、確実に顧客の信頼を失うのは、事後対応策を怠った場合です。
なぜならば、事後対応策がとられている組織の場合、比較的原因究明が早いためです。そのため、
「○○の可能性で侵入された可能性が高いため、確認中です。」と第一報。
「○○に原因があったため、至急対策を実施しました。」
と最終報告がしやすいわけです。

それに対し、事後対応策が不十分である場合、これが言えません。
「鋭意調査中です。」
「恐らく、○○が原因だと思われます。」
「取り合えず、セキュリティ対策を強化しました。」
くらいの台詞がお約束です。
もし、ユーザであったら、どちらが安心感があるでしょうか。
勿論、広報の発表の仕方にもよりますが、事故後のアクション次第で組織への影響は大きく変わるものです。
いくつも、類似の事件を見てきましたが、今回は失敗の典型的事例に映ります。
IPS、WAF、アンチウイルスなどの予防策だけがセキュリティ対策では無いのです。


消えそうで消えないAndroidマルウェアの登場か!?

先日の記事にも取り上げられていますDroidDream(Rootcager)についてです。
記事にもあります通り、「
rageagainstthecage」を利用しroot権限を奪取します。
その後にパッケージなどをダウンロードしたりします。詳細はこちら。
参考URL: 新たな Android の脅威による端末の root 権限の取得

Android Marketでマルウェア入りアプリケーションが配布されたことも驚きですが、マルウェアによるroot権限の奪取は、「ついに来たか!」といった印象を持ちました。
$ pwd
$ SuperSolo/assets
$ ls -l
total 184
-rw-r--r--  1 analysis  staff  15360  3  4 09:55 GuitarData
-rw-r--r--  1 analysis  staff    347  3  4 09:55 Hallelujah
-rw-r--r--  1 analysis  staff    335  3  4 09:55 Hotel California
-rw-r--r--  1 analysis  staff    346  3  4 09:55 House Of The Rising Sun
-rw-r--r--  1 analysis  staff    331  3  4 09:55 Majors
-rw-r--r--  1 analysis  staff    338  3  4 09:55 Minors
-rw-r--r--  1 analysis  staff    590  3  4 09:55 behold.ivt
-rw-r--r--  1 analysis  staff  15295  3  4 09:55 exploid
-rw-r--r--  1 analysis  staff    566  3  4 09:55 galaxy.ivt
-rw-r--r--  1 analysis  staff    470  3  4 09:55 piezoerm.ivt
-rw-r--r--  1 analysis  staff   3868  3  4 09:55 profile
-rw-r--r--  1 analysis  staff   5392  3  4 09:55 rageagainstthecage ←これ!
-rw-r--r--  1 analysis  staff  14075  3  4 09:55 sqlite.db
$
Androidの場合、アプリケーションは、Linuxでいうところの一般ユーザ権限で動作しています。これは外部から持ち込まれたマルウェアにおいても同様です。そのため、仮にマルウェア付きアプリケーションをインストールしてしまった場合においても、端末に与える被害範囲は想像がつき易いです。しかし、root権限が奪取されますと、マルウェアはこの制限が無くなり、(現状では)厄介なことなります。

例えば、マルウェアがシステム領域に設置されたとしたらどうでしょうか。
この場合、一般のアンチウイルス・アプリでは駆除できなくなります。なぜなら、アンチウイルス・アプリも普通のアプリケーションと同様の権限しか持っていないためです。
(私の手元にあるアプリでは削除出来ていません。)
次にデータ初期化を試みることを思いつくのではないでしょうか。
しかし、残念ながらAndroidのデータ初期化はデータ領域のみであるため、システム領域内のマルウェアは削除されません。
結局、SDKを用いて、削除することになります。(root化が必要になります)

droiddream1

root権限の奪取による攻撃者側のメリットとAndroidの仕様を考えますと、root権限を奪取するマルウェアは今後のトレンドとなりそうです。Android端末による本格的なボットネットの構築は来年かな、と思ってましたが、意外に近い未来かもしれません。

やっぱり出てきた!Androidボット

「これは結構ヤバいのでは!?」と話題の「Geinimi」。
昨年末に、Lookout Mobile Securityの記事で報告され、今後の動向が気になります。

現在のところ、マルウェアの配信元は中国の公式外マーケットのみですので、被害範囲もある程度限定されていると思われます。

今回、配布されているサイトの内の1つを調べてみますと、Geinimiが混入されたアプリケーションは比較的信頼のおける(?)アップロード職人がアップしたものに含まれていました。
#サイトの信頼度は別として・・・
恐らく、アップロードしたユーザも、Geinimiが混入されていることに気付いていないと思われます。
(そもそも、このアプリケーション自体が拾い物の可能性が大きいですが・・・)

また、現在配布されているGeinimi入りアプリケーションが、二次配布されたものと仮定しますと、オリジナルはどこかに存在していることになります。
場合によっては、中国語圏から日本語圏、英語圏と攻撃範囲を拡大してくるかもしれないですね。

geinimi_bbs



Geinimiの動作は、他のサイトで解説されておりますとおり、「位置情報」や「端末情報(端末識別番号や加入者識別子)」などをC&Cサーバへ送信するなどします。
モバイルセキュリティの専門家のご指導のもと、Geinimi入りアプリケーションをバラしてみました。
(apk拡張子はZIP形式)
送信される箇所を参照しますと、端末内の詳細な情報が送信されることが何となく分かると思います。

~/Geinimi_APP/smali/com/dseffects/MonkeyJump2/jump2/e/p.smali ← これ
method=post&IMEI=
&IMSI=
&AdID=
&CPID=
&PTID=
&SALESID=
&msgType=
imei=
&imsi=
&sms=
&type=send
&latitude=
&longitude=
&type=receive
&phone=
&MODEL=%s&BOARD=%s&BRAND=%s&CPU_ABI=%s&DEVICE=%s&DISPLAY=%s&FINGERPRINT=%s&HOST=%s&ID=%s&MANUFACTURER=%s&PRODUCT=%s&TAGS=%s&TIME=%s&TYPE=%s&USER=%s&SoftwareVersion=%s&Line1Number=%s&NetworkCountryIso=%s&NetworkOperator=%s&NetworkOperatorName=%s&NetworkType=%s&PhoneType=%s&SimCountryIso=%s&SimOperator=%s&SimOperatorName=%s&SimSerialNumber=%s&SimState=%s&SubscriberId=%s&VoiceMailNumber=%s&CPID=%s&PTID=%s&SALESID=%s&DID=%s&sdkver=%s&autosdkver=%s&shell=%s
データの送信先は、SANSでも紹介されている通り、次のドメインです。
いずれも既に接続できません。
www.widifu.com:8080;www.udaore.com:8080;www.frijd.com:8080;www.islpast.com:8080;
www.piajesj.com:8080;www.qoewsl.com:8080;www.weolir.com:8080;www.uisoa.com:8080;
www.riusdu.com:8080;www.aiucr.com:8080;117.135.134.185:8080

攻撃者側の目的は、Android端末の情報であることは容易に想像できますが、これらの情報が何に悪用されようとしているのかが、非常に興味深いところです。
昨年のZeuSがMITMO(Man in the Mobile)を使ってモバイル・バンキング口座の認証を破ったことがちょっと話題になりました。このときの攻撃対象はブラックベリーなどでしたが、もしAndroid端末を乗っ取られたことを考えますと、日本のような便利機能満載な端末は非常に恐いなぁ・・・と思うのは私だけでしょうか。

今後、スマートフォンの普及率を踏まえますと、さらにAndroid端末を狙ったマルウェアは増加していくことが予想されます。
その多くは、Geinimiのようなアプリケーションに混入するタイプが多いと思っています。

これらの対策としては、Lookoutなどでも記載されているように、
・信頼できるサイトからのみアプリをダウンロードする
・アプリケーションをインストールする際に表示される警告を確認する
・スマートフォンなどの振る舞いに異常がないかどうかチェックする
は勿論のこと、Android端末向けのアンチウイルスソフトウェアをインストールは忘れずにしておきたいところです。

来年にはどうなっているか・・・非常に興味深いですね!

あっちでもこっちでもクリスマス・プロモーション

今年もクリスマス・アタックがちらほら始まりました。
お祭りみたいなものなので、放っておきましょう。
#改ざんページのデザインも、何となく幸せそうです・・・。

xmas_deface

クリスマスに便乗しているのは、クラッカーだけではありません。
新しい攻撃ツールやらマルウェアもクリスマス・プロモーションをはじめているようです。(笑)
セールは期間限定でしょうから、悪用されだすのは年始以降と推測されます。
これらの中から、来年ブレイクするマルウェアが出てくるかもしれません。

取り合えず、年末年始のお休みに入る前に、サーバやPCの大掃除や整備もお忘れなく!

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

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

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

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

terro_2010

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

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

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

そのApacheのモジュールは本物ですか?

隣部屋に隔離中のSEKI隊員曰く、
Apacheのモジュールが改ざんされたウェブサイトが確認され、結構厄介とのこと。

最近のウェブサイトの改ざんといえば、iframeやJavaScriptの挿入が主流です。これらは、目視でも確認することが可能です。そのため、grepコマンドを使った簡易チェックを実施した方も多いのではないでしょうか。また、挿入の対象ファイルは、多くの場合はコンテンツフォルダ内なので、セキュリティツールなどが改ざんを検知してくれるケースもあったかと思います。

しかし、改ざん対象がApacheのモジュールとなると、話が違います。さすがに、サーバアプリケーションのモジュールまでチェックしているウェブ管理者は少ないのではないでしょうか。

以前、紹介した.htaccessの改ざんも気付きづらいですが、Apacheのモジュールはさらに気付きづらいです。しかもバイナリファイルですので、ちょっと調べてみようかな、なんて思う気合いの入ったウェブサイト管理者も多くはないはずです。

apache_module

いい加減、気が滅入ってきますよね。
現在のところ、数件(片手で数えられる程度)しか事例を確認しておりませんので、大流行というわけではありませんが、注意は必要そうです。
お宅のApacheは、大丈夫そうですか?
#特に放置されたサーバは要チェックです!
バックナンバー
セキュリティ関連リンク
セキュリティ機関

政府関連

セキュリティ関連団体

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

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

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

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

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