10月 29

zmapを32bitのKaliにインストールしましたよ。

ミシガン大学の研究者たちが開発したオープンソースのネットワークスキャナ「ZMAP」を32bit環境インストールしたときのメモです。このツールは、ステートレス化を行なうことでインターネット上にあるすべてのIPv4アドレスをわずか45分でスキャンできたという鳴り物入りのツールです。

下準備

sudo apt-get install libgmp3-dev libpcap-dev gengetopt

ダウンロードと展開・移動

wget https://github.com/zmap/zmap/archive/v1.0.3.tar.gz
tar zxvf v1.0.3.tar.gz
cd v1.0.3

このツールは64bit環境での動作を想定しているそうなのですが
32bit環境でもソースの一部を修正することで動作させることが可能となります。

修正箇所は以下の通りです。

【lib/blacklist.c】
127行

allowed, allowed*100./(1L << 32)); ↓ allowed, allowed*100./((long long int)1 << 32));

【src/zmap.c】
84行

#define SLU(w,x,y) printf(“%s\t%s\t%lu\n”, w, x, y);

#define SLU(w,x,y) printf(“%s\t%s\t%lu\n”, w, x, (long unsigned int)y);

461行

v = v * (1L << 32) / 100.; ↓ v = v * ((unsigned long long int)1 << 32) / 100.;

470行

else if (v >= (1L << 32)) { ↓ else if (v >= ((unsigned long long int)1 << 32)) {

インストール

cd src
make
make install

参考URL:
https://github.com/zmap/zmap/commit/779424fe2c7bd6bee525a1705fa878b965fb242c

Category: memo | zmapを32bitのKaliにインストールしましたよ。 はコメントを受け付けていません
10月 25

Apple IDのログインを失敗するとどうなるか確認しましたよ。

最近話題になっているApple IDですが
気になったので自分のApple IDでログインの失敗をするとどうなるのかの確認をしてみました。

きっかけはこちらの記事に以下のようにあったためです。

まず実際に筆者がApple IDで受けた経験を基に、リスト攻撃を受けた際の状況を見てみよう。

 図1は、筆者がApple IDに対して攻撃を受けた際に、Appleから受け取ったパスワードリセットに関するメールのスクリーンショットである。このメールは図2に示した通り、2013年10月22日から23日の間に5回届いている。つまりこの短期間に5回の攻撃を受けたということだ。

このページから「Apple IDを管理」を選択。
WS000074

「サインイン」画面に移るのでそこで何度か間違えてみます。
WS000075

3回間違えると強制的に「パスワードの再設定」に移動します。
WS000077

この画面は「サインイン」の画面にある「パスワードをお忘れの場合」をクリックしたときと同じページです。
ここで自身のApple IDを入力すると(数回間違えた際にはサインイン時に入力したものが自動で入力されるようです。)以下のような画面に移ります。
WS000078

ここで「Eメール認証」を選択して「」次へをクリックすると設定しているメールアドレスにパスワード再設定のためのリンクが記載されたメールが「appleid@id.apple.com」から届きます。
WS000079

ボクが試して範囲では、ログイン試行を3回失敗して、なおかつ、「Eメールによる認証」を行うという選択をしなければAppleからのパスワード再設定のメールは届かないということが分かりました。オンラインパスワードクラッカーなどを使って多くの試行を行ってはいませんがそれだけではこのメールは届かないような気がします。試しに手動でパスワードの再設定を行わず10回ほどサインインの失敗をしてみましたがメールは届きませんでした。ログイン試行を繰り返す攻撃だけでは通知はいかないものと考えられます。

ボクの気になった記事とは別に
フィッシング?:アップルIDのパスワード狙う 大量にメール送信

【注意喚起】Apple IDの「パスワード再設定」をかたるメールに注意 / 念のためパスワード等の変更を
といった記事が出ていますがこれがフィッシングメールかどうかというところはこの話とは別に気になります。

もちろん、身に覚えのないメールであれば放置しておくことが一番だと思います。

どなたか受け取った方いらっしゃいましたらこっそり情報いただけると嬉しいです。

【10月27日追記】
このメールがフィッシングではないということを前提条件としてAppleからのメールを送ることで成立する攻撃を行なうためには、攻撃を行なうターゲットのメールアカウント自身の制御下に置いておく必要があると思います。
つまり、Apple IDでパスワードをリセットする前にリセット用のURLが送信されるメールアカウントを事前に乗っ取っておくということです。そうすれば、攻撃者は、リセットメールに記載されたURLにアクセスすることで自身の好きなパスワードを設定することが可能であるためターゲットのApple IDを乗っ取ることに成功することでしょう。

しかし、攻撃者はリセットを行なった後のメールは正規のユーザが見る前に削除すると思いますし、Apple IDのパスワードをリセットして正規のユーザのものと異なるものを設定した場合は、正規のユーザが利用するタイミングで発覚してしまいますね。発覚するまでに不正利用してしまうという考え方もあると思いますが、攻撃者としては正規のユーザが設定したパスワードを知りたいと思うような気がしますね。

転送先を追加しておくということも考えたのですが、それでも正規のユーザの目にメールが触れてしまうことを避けたいと考えるでしょう。
ものは試しということで自分のgmailアカウントに転送設定をしてみたのですが転送設定を完了させると転送元にログインした時点でこのような通知が表示されます。

gmail_fw_notify
設定では転送したメールをメールボックスから自動で削除することもできます。

gmail_fw_op

また、outlook.comでもgmail同様に設定ができ、転送されていることの通知も表示されました。
outlook_fw_op

outlook_fw_notify

引き続き、Apple IDからこの手のメールが来た方いらっしゃいましたら情報をいただければ幸いです。

Category: memo | Apple IDのログインを失敗するとどうなるか確認しましたよ。 はコメントを受け付けていません
9月 12

Apache Struts2のバージョン調査について

【背景】

日本国内でもApache Struts2(以下、Struts2)の脆弱性を利用した攻撃による被害が相次いでいます。
公表されているものでは「JINS」が有名ですね。(発表資料

少し前に、はやりだった(はやっている)ものは

S2-008CVE-2012-0391)(脆弱性検証レポート

S2-013CVE-2013-1966)(脆弱性検証レポート

S2-016CVE-2013-2251)(脆弱性検証レポート

あたりでしょうか。

推測の域を出ませんが、被害の大小問わず公表されていない被害も発生していると考えられます。
ボクはセキュリティの診断に長らく関わっています。その経験と観点から少しお話をしたいと思います。
(あくまでボクの経験ですので診断を提供している企業の中にはボクの定義が当てはまらないものがある可能性についてはご了承ください。)

セキュリティの診断には大きく分けて
「ネットワーク(プラットフォーム)診断(以下、NW診断)」と「Webアプリケーション診断」(以下、Web診断)があります。違いを凄く簡単に説明するとNW診断では主にOSやサーバアプリケーションの部分を、Web診断ではその上で動く、診断依頼者、つまり、「お客様の独自に作りこまれたアプリケーション」にセキュリティ上の問題点、脆弱性が存在しないかどうかを診断します。

「お客さんの独自に作りこまれたアプリケーション」と言っているのは、NW診断の範疇とWeb診断の範疇を可能な限り明確にするためです。ネットワーク機器やアプライアンス製品の多くはブラウザで設定、管理を行うことが可能です。この機能自体はWebアプリケーションであることには間違いはないのですが「お客様独自に作りこまれたアプリケーション」ではないため、NW診断の範疇となるわけです。

さて、問題のWebアプリケーションフレームワークである「Struts2」はどちらの検査の範疇となるのでしょうか。

cover

勘の良い方はもうお気づきかと思いますが。
フレームワーク自体は「お客様独自に作りこまれたアプリケーション」ではないためNW診断の範疇であるとボクは考えてます。しかし、診断を受ける側のお客様はWeb診断の範疇であると考えている方もいらっしゃると思います。このブログをお読みいただいている方にもいらっしゃるかもしれません。もちろん、どちらか一方の診断でしか診てはいけないというものではないため診断を行う際に診断業者とお客様の間で取り決めをしている場合もあるとは思います。
ボクが危惧していることは、WebアプリケーションフレームワークだからWeb診断で見てくれているだろうというお客様の思い込みと説明しなくても分かっているだろうという診断業者の思い込みがあってはいけないということです。
それに加えて、診断対象にネットワークを介して診断した場合はStruts2は非常に発見しずらいものだということです。どのWebアプリケーションからStruts2が使われているかということもですが、1つの診断対象内に複数のStruts2が共存している場合も大いにあります。
一言でいうと非効率であるということです。
もしかするとNW診断であったとしても発見できない場合もあれば、そもそも診ていないという場合もあるかもしれません。
診断を受けようとしている方はこの点を確認しておいたほうがいいでしょう。
場合によっては追加料金が発生する可能性があります。
(ボク個人としては、この程度のことで追加料金をもらうほどのことではないと考えていますが)

診てくれなかったり、予算がなかったり、足りなかったり
今すぐこれだけでも確認したいという場合に自身でチェックする方法について解説させていただきます。
(みなさんの環境と異なる点などあるかと思いますが、そこは適宜読み替えていただければと思います。)

【バージョン確認方法】

■Unix系の場合

findコマンドを利用してバージョン情報が含まれるjarファイルを検索

root@struts2:~# find / -name struts2-core*.jar
/opt/CVE-2013-2251/tomcat/webapps/struts2-showcase/WEB-INF/lib/struts2-core-2.3.15.1.jar
/opt/CVE-2013-2251/tomcat/webapps/struts2-blank/WEB-INF/lib/struts2-core-2.3.15.1.jar

ここで表示されるファイル名に含まれるバージョンがStruts2のバージョンとなります。
念の為、マニフェストファイル内に記述されているバージョンの調査方法も記載しておきます。

jarファイルを解凍するので作業用ディレクトリを作成し、コピーします。
そして、grepを利用して「Bundle-Version」の行を抽出して確認を行います。

root@struts2:~# mkdir /tmp/StrutsCheck
root@struts2:~# cp -p /opt/CVE-2013-2251/tomcat/webapps/struts2-blank/WEB-INF/lib/struts2-core-2.3.15.1.jar /tmp/StrutsCheck
root@struts2:~# cd /tmp/StrutsCheck
root@struts2:/tmp/StrutsCheck# unzip struts2-core-2.3.15.1.jar
Archive: struts2-core-2.3.15.1.jar
creating: META-INF/
inflating: META-INF/MANIFEST.MF
creating: org/
creating: org/apache/
~ 略 ~
creating: META-INF/maven/
creating: META-INF/maven/org.apache.struts/
creating: META-INF/maven/org.apache.struts/struts2-core/
inflating: META-INF/maven/org.apache.struts/struts2-core/pom.xml
inflating: META-INF/maven/org.apache.struts/struts2-core/pom.properties

root@struts2:/tmp/StrutsCheck# grep Bundle-Version META-INF/MANIFEST.MF
Bundle-Version: 2.3.15.1

root@struts2:/tmp/StrutsCheck# cd
root@struts2:~# rm -fr /tmp/StrutsCheck

■Windows系

dirコマンドを利用してバージョン情報が含まれるjarファイルを検索します。

C:\>dir /S /B struts2-core*.jar
C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps\struts2-blank\WEB-INF\lib\struts2-core-2.3.15.1.jar

ここで表示されるファイル名に含まれるバージョンがStruts2のバージョンとなります。

念の為、マニフェストファイル内に記述されているバージョンの調査方法も記載しておきます。
jarファイルを解凍するので作業用ディレクトリを作成し、コピーします。

C:\>md C:\Temp\StrutsCheck
C:\>copy “C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps\struts2-blank\WEB-INF\lib\struts2-core-2.3.15.1.jar” C:\Temp\StrutsCheck
1 個のファイルをコピーしました。

C:\>cd C:\Temp\StrutsCheck

C:\Temp\StrutsCheck>dir
ドライブ C のボリューム ラベルがありません。
ボリューム シリアル番号は xxx-xxxx です

C:\Temp\StrutsCheck のディレクトリ

2013/09/12 10:50 <DIR> .
2013/09/12 10:50 >DIR> ..
2013/07/14 21:02 802,044 struts2-core-2.3.15.1.jar
1 個のファイル 802,044 バイト
2 個のディレクトリ 17,165,873,152 バイトの空き領域

そして、コピーしたjarファイルを解凍ソフトを使用し解凍します。
extract

解凍してできたファイルの中のマニフェストファイル内に記述されているバージョンの調査方法は下記の通りです。

C:\Temp\StrutsCheck>dir
ドライブ C のボリューム ラベルがありません。
ボリューム シリアル番号は xxx-xxxx です

C:\Temp\StrutsCheck のディレクトリ

2013/09/12 10:51 <DIR> .
2013/09/12 10:51 <DIR> ..
2013/07/14 21:01 2,653 FREEMARKER-LICENSE.txt
2013/07/14 21:01 10,141 LICENSE.txt
2013/09/12 10:51 <DIR> META-INF
2013/07/14 21:01 418 NOTICE.txt
2013/07/14 21:01 2,563 OGNL-LICENSE.txt
2013/07/14 21:01 <DIR> org
2013/07/14 21:01 1,060 overview.html
2013/07/14 21:01 3,446 struts-2.0.dtd
2013/07/14 21:01 3,816 struts-2.1.7.dtd
2013/07/14 21:01 3,765 struts-2.1.dtd
2013/07/14 21:01 3,764 struts-2.3.dtd
2013/07/14 21:01 23,810 struts-default.xml
2013/07/14 21:01 1,239 struts.vm
2013/07/14 21:02 802,044 struts2-core-2.3.15.1.jar
2013/07/14 21:01 <DIR> template
2013/07/14 21:01 2,567 XWORK-LICENSE.txt
13 個のファイル 861,286 バイト
5 個のディレクトリ 17,162,178,560 バイトの空き領域

C:\Temp\StrutsCheck>findstr Bundle-Version META-INF\MANIFEST.MF
Bundle-Version: 2.3.15.1

C:\Temp\StrutsCheck>cd \

C:\>rd /S /Q C:\Temp\StrutsCheck

これでバージョンが判明しましたのでセキュリティ情報系のサイトやStruts2のサイトなどで脆弱性の影響を受けるバージョンかどうかをチェックすることができます。

【さいごに】

Struts2は潜在的に脆弱性が存在するという点においてまだまだ枯れていない印象があります。必ずしもこれから発見されないとは言い切れませんがApacheやsendmailなどなど過去にインパクトの大きな脆弱性が発見されてきて現在ではクリティカルなものはそれほど見つかっていません。
そのあたりの脆弱性が発見されないこともあってか攻撃の対象が移り変わってきたのかもしれません。
これはボクの推測でしかありませんが、攻撃者は普段から情報の収集を行っているのだと思います。どこでどのようなアプリケーションが使われているか。どのポートがオープンしているかといった調査を日常的に行い、来る脆弱性(その攻撃方法)が判明する日、つまり攻撃を行う日に備えてリスト化しているのではないかと考えています。
(例えばStruts2で言えば、Googleで「filetype:action」で検索しておけばStruts2を使っているインターネットに公開されているページをすべてではないにしても知ることができます。)
脆弱性(攻撃方法)が公表されてから実際の攻撃が行われるまでの時間が短くなっているきているのも頷けるのではないでしょうか。

しっかりと脆弱性情報を追いかけ、その対処を行うサイクルを回している組織でも脆弱性(攻撃方法)が公表されてから1日や2日で攻撃が来てしまうことを考えると侵入されることを完全に防ぐことはほぼ不可能な場合も起こり得るということになると思います。かなり前から言われていることではありますが、1つ目の砦を突破されてもその後の仕組みで早期発見、対処できる仕組みの大切さに気付き、アクションを起こすことの重要性を改めて感じますね。

Category: exploit, memo | Apache Struts2のバージョン調査について はコメントを受け付けていません
4月 4

ブルートフォース攻撃について考えてみました。

以下のようなニュースがありました。
NTTレゾナントの「gooID」に不正なログイン要求、約3万アカウントをロックし対処

このニュースには

特定のIPアドレスから秒間30件を超える機械的なログイン要求(ブルートフォース攻撃、関連記事)があった

とあります。(ブルートフォース攻撃、関連記事)と書かれたリンク先はブルートフォース攻撃の解説が書かれたページなのですが、自分の中で整理する意味も込めてブルートフォース攻撃について考えてみました。
(攻撃方法の可能性としてどこかで漏洩したユーザ名、パスワードを用いて使い回しを行なっているアカウントを狙っている可能性は捨てきれませんが今回はこの可能性については言及しません。)

ブルートフォースとは「強引な」とか「力任せな」という意味で基本的に認証を突破する際に用いられる手法の1つです。これにはいくつかパターンが存在するので1つずつ見ていきましょう。
といってもそんなに難しいものではなく、一般的にブルートフォース攻撃と言うと基本的に下のような分類のどれかに当てはまると思います。

スクリーンショット 2013-04-04 15.25.52

「リバースブルートフォース攻撃」という言葉がでてきましたがここではまだ気にしないでください。まずは「1. ブルートフォース攻撃」の「1-1. インクリメンタル攻撃」と「1-2. 辞書攻撃」を見てみましょう。

【1-1. インクリメンタル攻撃】
これはユーザ名を(ある程度)固定し、パスワードを連続した順番に試行して行くタイプのものです。
例えば以下の通り。
ユーザ名:ntsuji
パスワード:0001, 0002, 0003, 0004, 0005 0006, 0007....などなど
または
パスワード:aaaa, aaab, aaac, aaad, aaae, aaaf, aaag....などなど


【1-2. 辞書攻撃】
こちらもユーザ名を(ある程度)固定し、パスワードを順番に試行するタイプではあるのですが「1-1. インクリメンタル攻撃」が「連続した順番」に試して行くのに対し、こちらは「辞書ファイル」と呼ばれるテキストファイルなどに記載されている、よくパスワードに用いられるであろう文字列を試行していきます。
例えば以下の通り。
ユーザ名:ntsuji
パスワード:password, Password, P@ssword, 1234, 12345, asdf ...などなど

なんとなくお分かりいただけたかな?というところで
「2. リバースブルートフォース攻撃」の説明をしたいと思います。
名前を見て分かる通り「ブルートフォース攻撃」の逆(リバース)です。
「ブルートフォース攻撃」で紹介した2つが共通する部分
「ユーザ名を(ある程度)固定し、パスワードを順番に試行するタイプ」
であったのに対し、こちらはその逆
「パスワードを(ある程度)固定し、ユーザ名を順番に試行するタイプ」
と覚えればよいかと思います。

念の為先程の2つ同様説明をします。

【2-1. インクリメンタル攻撃】
パスワードを(ある程度)固定し、ユーザ名を連続した順番に試行するタイプのものです。
例えば以下の通り。
ユーザ名:0001, 0002, 0003, 0004, 0005...などなど
パスワード:1234


【2-2. 辞書攻撃】
こちらもパスワードを(ある程度)固定し、ユーザ名を順番に試行するタイプではあるのですが「2-1. インクリメンタル攻撃」が「連続した順番」に試して行くのに対し、こちらは「辞書ファイル」と呼ばれるテキストファイルなどに記載されている、よくユーザ名に用いられるであろう文字列を試行していきます。
例えば以下の通り。
ユーザ名:satou, suzuki, takahashi, tanahashi, takanashi....などなど
パスワード:1234

【雑感】
ブルートフォースはある程度クラックしたいユーザが決まっている場合に用いられるのに対し、リバースブルートフォースは特にクラックしたいユーザが決まっているのではなく、弱いパスワードを設定してしまっているユーザをクラックしたいという場合に用いられると思います。

どういった方法を用いるのかというのは攻撃者の持っている情報や状況、目的によって変わってくるのだと思います。
例えばユーザ名が連番で振られいるが、一定時間内に3回ログインに失敗したらアカウントがロックアウトされてしまうという条件がある場合では以下のようなパターンの試行が考えられると思います。
ユーザ名:1000, 1001, 1002, 1003, 1004....などなど
パスワード:1234, [ユーザ名と同一]

1ユーザに対してのログイン試行は2回までと制限をして2回の試行ごとにユーザ名を変化させていく。
これで弱いパスワードを設定しているユーザをクラックしアカウントロックもされず、少し時間をおけば再度試行するパスワードを変えて攻撃することが可能になるというわけです。

さて、冒頭で紹介したニュースはどのパターンが試行されたのでしょうか。
真相は分かりませんが状況から考えてみたいと思います。

スクリーンショット 2013-04-04 15.25.52

ポイントとなるのは

調査したところ、ログイン要求を送られたアカウントの数は約3万。

の部分だと思います。3万ものユーザ1つ1つに多くのパスワードを試すことは考えにくいため1つのユーザにはあまり固執した攻撃は行なわれてないのではないかと想像できますので「1-1」「1-2」ではなく、リバースブルートフォースである「2-1」か「2-2」が用いられたのではないかと考えられます。しかし、「gooID」ではログインの際のIDはユーザが任意に設定することが可能ですので「2-1」も可能性としては考えにくいと思われます。したがって、今回は「2-2」の「リバースブルートフォースによる辞書攻撃」ないしその応用が断続的に行なわれているのではないか?という推測ができます。

では、3万ものユーザ名をどのようにして用意したのか?ということなのですが、これに関しては2つの推測ができました。
1つ目は単純にどこかからの漏洩や売買。「gooID」は「gooメール」@よりも前で用いられているので、メールアドレスのリストの漏洩、もしくは購入で入手することも可能だと思います。もう1つは「gooID」を用いるサービスから。
例えば「gooブログ」を設置した際のアドレスは「http://http://blog.goo.ne.jp/ユーザ名」となりますのでこのようなものから収集することも可能です。

長々と書いてきましたが、これらはすべて1つの記事と自身の経験や感覚からの「推測」や「予想」でしかありません。このあと出てくる情報に寄ってはすべてが覆る可能性は大いにあります。
そして、真実の中には一番低いと思っていた可能性や思いも寄らなかった別の可能性だったということも多々あるでしょう。

あーでもない。こーでもない。と推測するのは実に楽しいことです。
終わりそうで終わらない。いつになったら終わるんだと思いながらも見続けているアニメのように。

しかし、そこで大事なことは事実と推測を分けて表現することなのかもしれないなと思います。
そこに気をつけないと専門家として認識されている人間やメディアが発したというだけで信じてしまう方々を増やしてしまうことになってしまいますから。

このエントリが「ブルートフォース攻撃」という言葉を見聞きしたときに考えられる可能性の幅を拡げることに繋がれば幸いです。

【追記】
・このエントリを書いている最中に3万件が10万件になったという続報が入りました…

・gooIDで設定できるパスワード文字数は4文字以上32文字以下です。

・使用できる文字種は下記の通り。
英字 a~z A~Z
数字 0~9
記号 ! " # $ % & ' ( ) = ~ | - ^ \ @ ` [ ; : ] , . / { * + } < > ? _

・ブログを読んでくださった方からコメントをいただきました。
いただいたコメントは下記の通りです。
「ブルートフォース攻撃と辞書攻撃は同列であってブルートフォース攻撃に辞書攻撃を含めるべきではないのではないか?」
これに対してボクの考えは以下の通りです。
このエントリを書くときに確認する意味も込めて調べてみたのですが
ブルートフォース攻撃に辞書攻撃が含まれるかということについては諸説ある感じになっていました。
そこで悩んだ挙げ句、(reverse)brute force attack の中に incremental attack と dictionary attackを入れ込むことである程度すっきり分類することを優先しつつも、用語の使い方、認識の問題はあるものの中身に影響を与えず間違いではないという形にできるかと判断しました。

【2013/4/5追記】

・「「gooID」に不正ログイン攻撃、10万アカウントが突破される」を読んで。

実際、すでに10万アカウントという規模で不正ログインが成功しているわけだが、ログからは、その何倍ものログイン試行が失敗していることが確認されているという。

という部分から拾い物のユーザ名、パスワードの組み合わせた辞書ファイルを片っ端からぶつけてるのかもしれませんね。
オンラインパスワードクラッカー「hydra」「medusa」でいうところの-Cオプションあたり。

hydraの-Cオプション↓

-C
colon seperated “login:pass” format, instead of -L/-P options

Category: memo | ブルートフォース攻撃について考えてみました。 はコメントを受け付けていません
3月 28

韓国での同時多発なサイバー攻撃についてのメモと雑感

皆さんご存知のとおり2013年3月20日に韓国の放送局や銀行で同時多発的に大規模な障害が発生しました。
それらの個々の事象やタイムラインについては既にとても素晴らしいまとめが公開されております。
以下をご覧いただくことを強くオススメします。

セキュリティは楽しいかね? Part 2 – 3/20 韓国同時多発サイバー攻撃について

piyolog – 2013年3月に発生した韓国へのサイバー攻撃をまとめてみた。

まずは自分メモと考えの整理をする意味で
カンタンまとめ。

【標的】
  韓国放送公社(KBS – Korean Broadcasting System)
  株式会社YTN(YTN – Your True Network)
  株式会社文化放送(MBC – Munhwa Broadcasting Corporation)
  済州銀行
  新韓銀行
  農協銀行 + 関連機関

【事象】
  ・Windows PCがマルウェアに感染

  ・3月20日の午後2時に破壊開始するロジック。

  ・破壊はPCの MBR、VBRなどに対して行ないその後、強制的に再起動。

  ・重要な領域が破壊されているためシステムは起動しなくなる。

  ・6つの組織の合計被害台数PC,ATMなどを合わせは32000台 by 韓国放送通信委員会

  ・組織内ネットワークにある資産管理サーバを乗っ取って、そこからマルウェアを配信
  (サーバ名称についてはココを参照)
  資産管理サーバとはパターンファイルの配信サーバという理解でいいと思います。

  ・LG U+の改ざん、犯行声明を残した WHOIS TEAMとの関係性は不明。

【推測される感染・侵入経路】
  ※マルウェアの感染経路および、更新管理サーバへの侵入経路、方法も不明。
  これを大前提として推測しています。

  ・添付メール
  ・攻撃用Webサイトへの誘導(偽サイトや正規サイトの改ざん)
  ・USBなどの物理メディア
  ・無線LAN APの利用
  ・外部からではなく内部犯行、内通者の存在も否定できない

【一考する価値のありそうな気になるポイント】
  ・どこのタイミングで検知できただろうか
  ・ミッションクリティカルな部分の分離、保護は充分だったか
  ・復旧手順は充分なものが存在していたのだろうか

【雑感】
この手の注目を集める事件が起きたときには、どうしても「ウチは大丈夫か?」という言葉が頭をよぎると思います。
特に今回のような大規模で、かつ目的や犯人、手法が不明であれば余計に不安や恐怖をかき立てるのだと思います。
PlayStation Networkの情報漏洩(not OpSONY)のときもそうでしたよね。

しかし、その不安や恐怖と向き合うことが大事なのだと思うんですよね。
その中にこそが答えがあるのではないかとボクは思います。

何故不安になるか? 何故怖いのか?
それは、分からないからですね。

何か失敗をしたときや失敗が想定されるときにそれを繰り返さない
もしくは起きないようにしようとすると思います。
対策ってやつですね。
対策は読んで字の如く原因や想定と「対」の「策」になっていないと意味がありません。
だからどのような事件、事故も原因の究明がスタートラインに立つための大事なアクションなわけです。

感染・侵入経路を推測してみたり、どこがポイントかなーと
考えてはみたものの結局のところ現段階で原因は分かりません。
もしかしたらこの先も公式に発表される保証もありません。

では、どうするのか?ということになるのですが…

この事件があったからそれに応じた対策を講じる。
というのではなく
自分たちがどこにある何を守りたいのかをはっきりさせる。

その上でそれがどこからのどのような脅威に晒されているのかを想定して
人、時間、お金などのリソースとの兼ね合いを考慮してどこまでの対策を講じるかを考える必要があると思います。
100%の「安全」は実現できっこないので、どこからは受容とするかというラインを決めて「安心」を得ようとする。
これは別に今に始まったことではなく今まで行なってきたことではないでしょうか。

普段の生活でいうなら

病気にかからないようによい習慣、体力を身につける。
病気を早期発見するために不安を感じたら診察してもらったり健康診断を受ける。
病気にかかったときのために薬を買い置きしたり掛かり付けを見つけておく。

これらと同じじゃないかなって思うわけです。

何か事件があったからあたふたするのではなく
普段からやるべきことをやる。

闇雲に不安になったり、恐怖におののいたりしないでくださいね。

間違えても、事象をしっかりと把握、分析もせず
韓国が大変なことになったから
ペネトレーションテストしましょう!とか言ってくる人を信用しないでくださいね。 ;p

Category: memo | 韓国での同時多発なサイバー攻撃についてのメモと雑感 はコメントを受け付けていません
10月 22

「パケット警察」いじってみましたよ。

ここのところ、巷を賑わしている「遠隔操作ウイルス」による誤認逮捕。
この件をきっかけに本日(2012/10/22)「パケット警察 for Windows」というソフトウェアがリリースされました。
リリース文によると

「パケット警察」は、パソコンの通信記録やソフトウェアの起動記録を見張り、自動的にハードディスク上に蓄積するソフトウェアです。万一、遠隔操作ウイルスによってあなたのパソコンが犯罪者にリモート操作され「踏み台」となった場合に、ウイルスの起動記録や犯人の通信記録がすべてログに残りますので、あなたの無実を証明したり、真犯人を追跡したりするための有力な証拠として利用可能です。

とのことです。
twitterでもつぶやいたのですがこのあたりがやはり気になります。
(法律に詳しい方。こっそり教えてくださると嬉しいです。)

容疑がかかっている人の管理下にあったり、ウイルスや侵入による汚染の可能性のあるコンピュータ内の情報ってどれほど証拠能力があるのかどうかという点についてはボクは法律の専門家ではないのでなんとも言えません。
ただ、単純に容疑がかかっている人が自由に操作できる状態にある情報を警察がどれだけ信じてくれるのだろうか。とやはり疑問は残ります。また、技術的な観点で見ても改ざんが可能である状態にあるコンピュータ内の情報はインシデントレスポンスをするにあたり鵜呑みにはできないもの。つまり、信用に足るとは言えないのかもしれないなとは感じます。
容疑がかかっている人が犯人であったとしても、その人のコンピュータを遠隔から操るどこかの誰かが真犯人であったとしても自由に操作できる環境下にあるという意味では同じことだと思います。
あと、ログも平文で保存されており、編集可能ですので、それこそ特定の組織の人や組織内で言えば管理者レベルしか見えない、編集できない、もしくは編集したことが分かるような仕組みでもない限り証拠とするには厳しい気もします。

と。頭で考えるのも限界があるので取り留めもなく手を動かしてみました。
主に外部から侵入したことを想定して検証しています。

インストールはすごく簡単(プロミスキャスモードが必要ないのでWindPcapなども不要)なので割愛。
気になった点としてはインストール中に「ユーザ情報」を入力する画面があったことくらいです。

新たにこのソフトウェアのためのユーザが追加されるのだろうかとも思い確認しましたが追加はされていませんでした。
(これなくてもいいと思うんですけどね。)

で、インストール完了。
プロセスをタスクマネージャで確認すると「ppsvc.exe」という名前で起動されていることが確認できました。

もちろん、サービス登録もバッチリされています。

インストールフォルダ内を見ていたら設定ファイルがあったので中身を確認したところ暗号化されたようなパスワードと共に「AdminPort」という文字列があり、気になったので確認したところ設定ファイルに書かれた番号のポートがオープンしていました。

このポートは設定を管理するためのツール「パケット警察」設定ツール(ppmgr.exe)が利用しているようで、念の為別のIPアドレスから接続を試みたところ接続することはできませんでした。(127.0.0.1でListenです。)

ざっと見たところは大体こんな感じです。

引き続き、何かしらの方法で制御を奪われた場合はどうなるか。
ということを想定しつつ手を動かしてみました。

制御を奪うには色々と方法があると思います。今回の事件のようにマルウェアをインストールさせるパターンや脆弱性を利用してアクセスしてきたブラウザ経由から制御を奪うパターンなどなど。今回は「Metasploit」を利用し、Administratorsグループの権限を奪ったという想定で検証を進めました。

試したことは、保存されているログを削除することです。

上図にように削除できませんでした。これは既にこのログファイルを「パケット警察」が開いているためですね。
ですので、今回はありませんが過去に保存した別のファイルがある場合は削除できるということになるでしょう。

ということで次に「パケット警察」(ppsvc.exe)を停止してから削除してみました。

当然ながら削除できてしまいました。
暫くするとログファイルが作成されていたので再度プロセスを確認してみると復活していました。

恐らくサービスが動作しているのでそちらが監視していて復活させているのでしょう。
アンチウイルスソフトなどでもよくあるパターンですよね。(マルウェアにもこういうのって実装されてたりしますがw)
ということでサービスを停止してみました。

これで「パケット警察」(ppsvc.exe)が復活してくることはなくなりました。
このようにこっそり止められると気付く方法は2つあるのかと思います。
①「パケット警察」設定ツール(ppmgr.exe)を起動するとサービスに接続できない旨のエラーがポップアップする。
②プロセスの監視ログに下記のような記録が残る。(パケットログと同様削除された場合はこの限りではない。)
2012-10-22 17:09:15.954 監視開始時にすでに起動していたプロセス: ID = 4092, EXE = "C:\WINDOWS\system32\cmd.exe"
2012-10-22 17:10:17.923 プロセスの起動: ID = 3840, EXE = "C:\WINDOWS\system32\cmd.exe"
2012-10-22 17:10:20.360 プロセスの起動: ID = 3660, EXE = "C:\WINDOWS\system32\net.exe"
2012-10-22 17:10:20.391 ----- 「パケット警察」の監視エンジンが正常終了しました。 -----

一度設定したらあまり触らないかもしれないので気付きにくいかもしれませんね。

と検証はここまでです。
奪取しているのは、Administrators権限なので当たり前といえば当たり前の結果なのだと思うのですが多くの方はAdministrators権限で使っているのではないでしょうか。

特に何がというわけでもないのですが興味が湧いたので取り留めもなくいじってみました。

一応のボクなりの個人的な見解を書いておきます。
予想通りではありましたが、乗っ取られしまった場合ですとこのソフトウェアによるパケットログが
「自己の無実を証明し真犯人を追跡するための重要な証拠」となり得るかどうかというと多くの場合において証拠とすることは厳しいのではないかと思います。検証にもあるとおりAdministrators権限以上(SYSTEMなども含むので)での操作が可能であれば改ざんなどの操作を行なうことが可能であるため、証拠となり得るには、このソフトウェアがインストールされているシステムに対して侵入が行なわれていないことの証明、もしくは、ログが改ざんされていないことの証明ができる必要があるのではないかと思います。事件がきっかけで世の中で情報が錯綜し、ある種の混乱をきたしている状態において、スピード感あるリリースを行なったことは本当に素晴らしいことであると思います。しかし、これをインストールしていれば大丈夫というように安易に安心してしまってはいけないとも同時に思います。

さいごに:
この話題。誤認逮捕をしてしまったこと。それに付随する明るみになってきている事象は確かに警察組織の不手際であるとボクも見ていて思います。しかし、リモートから捜査を行う際にたよりにできるものはIPアドレスくらいしかないのかもとも思います。(実際の捜査を知っているわけではないので想像になりますが。)となると現行の捜査、逮捕のプロセス自体に無理がでてきているのかもしれません。となったときに、冤罪を増やさないためにどうするか。
逮捕し容疑者と公表する前にワンクッション置くといった方法をとる?
そうなると捜査の及ぶ範囲が今よりも広げる?その場合のプライバシーはどうなる?
答えはボクにもありません。ただ言えることはこれを考え、形にしていくことが警察組織だけではなく私たちにも与えられた課題なのかもしれないということです。

Category: memo | 「パケット警察」いじってみましたよ。 はコメントを受け付けていません
9月 16

SMBCへのDoS呼びかけで勧められているツールについて



NetSecurityの記事によると
四川省のハッカーの一部が執拗に三井住友銀行(SMBC)のWebサーバーにDoS攻撃の実行を呼びかけつつ
ツールの配布をしているそうなのでダウンロードしてみました。起動すると文字化けしまくりですがめげません。

あ、その前にこのツールのVirusTotalでのスキャン結果はコチラ
18/42の検出となりました。(9/16現在)

ということで。

そのツールを自宅の閉じた環境で動かしてみました。

【検証環境】
・攻撃環境
OS: Windows XP

・被攻撃環境
OS: Debian/GNU Linux 6
Web Server Apache 2.2.16

・NW環境
攻撃及び被攻撃環境は無線LANネットワーク上の同一セグメントにある別のPC上のVMゲスト

攻撃環境ではこんな感じでDoSを行ないながら被攻撃環境とやり取りされているパケットを取得。

ツールから送出されるHTTPパケットはこんな感じ。

被攻撃環境上のApacheのログはこんな感じ。

ちなみに、この環境でのリクエスト数は、 113req/sec でした。

Category: memo | SMBCへのDoS呼びかけで勧められているツールについて はコメントを受け付けていません
8月 31

標的型攻撃メールの注意喚起から考えたこと。

色々な記事や注意喚起を見てると「標的型攻撃メール」が分からなくなってきたのですが、こういう状況を見るとバズワードになっては消えて行った(実際には完全に消えたわけではなく残っているとは思うのですが)言葉たちを思い出します。

できるだけの多くの人の安全のために注意喚起をするので注意を引きやすいものにしたいという気持ちはすごく分かります。ただ、そこで過剰になってはいけないと思うんです。

もちろん、それを気にするあまり不足になってもいけないわけですよね。

これは難しいです。となったときにはできるだけ細かくというか事実は事実、可能性は可能性として書いた方がいいのかなと思うんですね。逆にそうじゃなくて丸めて書いた方がいいんだよという意見もあると思いますがボクはそう思っちゃいます。なんででしょうね。細かいのでしょうw

例えばボクは
「標的型攻撃メールに関する注意喚起」
というものを見ると以下のように考えます。
ん?標的型攻撃メールと分かっている?
ということは、その標的になっているところに教えてあげればいいのでは?
いや、そうじゃないのかな。
もしかすると、強めの注意喚起をしたい?
よくよく考えると標的型であるかどうかということはすぐには分からないことだなぁ…
とにかく分析も進んでいないし、分析待つのもいつまでなんだってことなって
はっきりとは言えないけど注意喚起はしないといけない状態なのかもしれないな。
ということであれば
例えば少し前みたいに
「弊社をかたるウイルスメールに関する注意喚起」
って内容にして注意喚起本文の中で
「現時点では分析中であり明確には申し上げられませんがメールの本文が巧妙であることから標的型攻撃メールである可能性がございます。」
とかって書いて
その本文を共有の意味も込めて掲載するのはダメなの…かな?…

といった感じです。
# こうして書くとちょっと恥ずかしいものですね。

こうすれば、誤解も招きにくいと考えられますし、「標的型攻撃メール」という言葉を本文に入れることで、通常よりも注意を促すことも可能だと思うんですよね。
なんでもかんでもこのパターンで書かれてしまっては身も蓋もなくなるのですが。
なので、更に言うと
どんな内容のメールだったのかとか、公表に至った経緯とか、どういう括りで標的型と判断したのかとか続報とか可能な限りの情報を公開するということのもよいのではないかと思うんですよね。

こういうことを考えていると
言葉の定義ってすっごく大事だと思うこともあれば
案外大事ではないなと思うこともあったりします。

詳しい人間同士で話すときはある程度丸めた表現でも伝わる場合もあります。
詳しい人間同士だからこそ定義をはっきりとしないといけない場合もあります。
詳しい人間同士ではないからこそ丸めたほうが伝わるときもあります。
詳しい人間同士ではないからこそ厳密に伝えないといけないときもあります。
などなど

これって規則性がボクも分かっていないのですが
なんとなく思うのは、やり取りをする者の特定の知識量や親密さ、人となりが分かるかどうかといったようなある種の距離感なのかもれないなと思います。

距離感の隔たりに比例して厳密に伝えないといけないような気がしています。

普段の人間関係と同じでしょうか。
普段からやり取りをしている人と会話をしていて
相手がうまく説明できず、それを相手も感じていて、もどかしそうにしているときに
「それってこういうことだよね?!辛かったでしょ。」みたいに言うと相手は「そう!そうなんだよ!」
みたいな場面、誰しも経験があるのではないでしょうか。
これって初対面の人とはそうそうできるものではないですよね。

なので
多く様々な距離感が考えられる場合は可能な限り厳密に伝えようと努めるのがいいのかなと思っています。
それが距離感を埋める1つの方法なのかなーって。

限られたリソースをコントロールしながら日々生活をする中でのそれは言う程容易いことではないと思いますし、自分自身もまだまだできていないと思っているのですが、ほんの少しでも、1手間でもかけてきちんと伝えようとすることでコンピュータ・セキュリティだけに限らずとも、少しずつ良いサイクルって生まれてくるんじゃないかなって思っています。というより、そう思い、そうなっていく一助に自分もなりたいなと思っています。

ボクはこの性格なので失敗ばかりです。
それでも案外努力してたり、考えたり、思い悩んだりしてるのですがw(当社比)
少しずつでも進めてるといいなと思いながら
この業界が
オオカミ少年にも
恐怖を煽るという脅威にもならず
開発やその運用、そしてその利用者の方々という主役がその役割に専念できるよう
安全と安心を与えられる名脇役みたいになれればいいな
ならないといけないなーなんて思っています。

Category: memo | 標的型攻撃メールの注意喚起から考えたこと。 はコメントを受け付けていません
2月 15

CloudCrackerを試してみましたよ。

WPA/WPA2に加えてLMとNTLMハッシュを解析してくれるサービス「Cloud Cracker」を試してみました。
クラウドの潤沢なリソースを使って有料でクラックするよーってサービスのようです。

このサービスに手元で用意した10個のNTLMハッシュのクラックを依頼しました。

7_alpha_char:1007:NO PASSWORD*********************:4A5FD23A29584C8E9C7CD3A03F94BF92:::
7_alpha_only:1004:NO PASSWORD*********************:18DB3670736D98D1A05CEADD0EFFE0A9:::
7_lowalpha_char:1006:NO PASSWORD*********************:FAF3FA09DD976403F16DE17CDD688DDA:::
7_lowalpha_only:1003:NO PASSWORD*********************:56835505E5A5D8CECE2E25873ED74C97:::
7_mixalpha:1010:NO PASSWORD*********************:B87AC6CF7CD7AF9176B7E882D519D427:::
8_alpha_char:1011:NO PASSWORD*********************:C93F23EE39C74C0B7725177741B0D21A:::
8_alpha_only:1009:NO PASSWORD*********************:984CC59BABBD0736242BB6FBF53D92E1:::
8_lowalpha_char:1012:NO PASSWORD*********************:B5ED2C2D1193E76B3C02C94165D9E043:::
8_lowalpha_only:1008:NO PASSWORD*********************:25865A2F7E9CA0A289A481017BB3E6C3:::
8_mixalpha:1013:NO PASSWORD*********************:B13CF536509026ED371421515BE84D6C:::

上記のユーザと平文パスワードの対応は下記の通り。

7_alpha_char / QPMZ%*=
7_alpha_only / POILKJM
7_lowalpha_char / rtyu#-+
7_lowalpha_only / qazxswe
7_mixalpha / iKxsBNv
8_alpha_char / PM!CQ=\G
8_alpha_only / URNVSOLW
8_lowalpha_char / yo@ne*da
8_lowalpha_only / zplqmavu
8_mixalpha / GsXTiger

# なんか「ん?」っていうのが入っているのは気にしないでください。
# なんとなくですから。他意はないですよ。

手順としては以下の通りです。

クラックを試みるファイルの種類で「LM/NTLM」を選択して
ローカルにあるPWDUMP形式のファイルを指定します。
(このときPWDUMP形式のファイル内の改行コードがLFでないとinvalidと言われました。)

次にクラック開始の連絡とクラックの結果を送ってもらうメールアドレスを指定します。

次に辞書の選択と依頼するジョブについての確認です。
# 辞書はDefaultしかありませんでした。
今回は10個のハッシュで$5.00でした。

そして、Submit!

Submitを押して問題がなければ、支払い画面になります。
JCBで決裁してみました。

決裁が通れば後はメールを待つだけです。

数分すると開始連絡が来ました。
これはこれはご丁寧にありがとうございます。

で待つこと23分。結果が届きました。


クラックに成功しているのは10個中3個。
その3個は

「7文字の小文字のみ」で構成されているもの
「7文字の大文字のみ」で構成されているもの
「8文字の小文字のみ」で構成されているもの

というものでした。
って10個依頼したのに6個しか結果に反映されてないんですけどっ!
LMだったら手元のRainbow TableでクラックできちゃうからNTLMに期待してたのですが
思ったほどでもなかったですね。速度的には良いかもしれませんが。

2012/02/17追記:

検査チームで持ってる「ntlm_ascii-32-95#1-7」のrainbow tableを使って
7文字のパスワード5つ(上記の7_から始まるハッシュ)に対してThinkPadX200で
クラックを試みたところ6時間ほどで全部のクラックが完了しました。

25分ほどで7文字の大文字小文字のハッシュを有料でクラック
6時間かけて7文字のハッシュすべての文字種類を手元で無料でクラック

どちらを選びますか?

Category: memo, site | CloudCrackerを試してみましたよ。 はコメントを受け付けていません
5月 19

「ウイルスバスター2009 におけるキー入力暗号化機能に関する脆弱性」に関するメモ

先日、公表された「ウイルスバスター2009におけるキー入力暗号化機能に関する脆弱性」についていくつかのメディアでも取り上げていただきました。公表当日(2011/05/17)とその翌日にもリアルタイム検索をしてみたところ色々な反応があったので発見当時の記憶と残っているメールなどのデータを辿りながらこの脆弱性と発見の経緯について簡単に説明したいと思います。

Continue reading

Category: memo | 「ウイルスバスター2009 におけるキー入力暗号化機能に関する脆弱性」に関するメモ はコメントを受け付けていません