UTCTF 2020 Forensics writeup
土, 07 3月 2020, 09:00 JST — 月, 09 3月 2020, 09:00 JST 2020/03/07 9:00 JST - 03/09 9:00に「zer0opsCTF 2020」の裏では、「UTCTF 2020」が行われておりました。ここで出題されたForesics問の話をする。とても易しくて分かりやすいものばかりであった。 ctftime.org
- 1 Frame per Minute
- Spectre
- Observe_Closely
- [basics]_forensics
- The Legend of Hackerman, Pt. 1
- The Legend of Hackerman, Pt. 2
- Zero
1 Frame per Minute
I recently received this signal transmission known as SSTV in a mode called Martian? This technology is all very old so I'm not sure what to do with it. Could you help me out?
与えられたファイルは、
# file signals.wav signals.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 48000 Hz
問題文を素直に受け取って良いのなら、SSTVでしょう。
SSTV
自分の場合は、RX-SSTVに再生した音声を聞かせて解いた。音が再生されると自動で録音してくれるが、雑音の少ないところでやりましょう。
flag: utflag{6bdfeac1e2baa12d6ac5384cdfd166b0}
Spectre
I found this audio file, but I don't think it's any song I've ever heard... Maybe there's something else inside?
与えられたファイルはコレ。
# file song.wav song.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 44100 Hz
おそらく、Spectreというからにはスペクトログラムを見るのではということでaudacityで開く。
メニューを開いて、スペクトログラムに切り替えると。
flag: utflag{sp3tr0gr4m0ph0n3}
一体どうやって作ったのか......
Observe_Closely
A simple image with a couple of twists... 与えられたファイルを見る。
# file Griffith_Observatory.png Griffith_Observatory.png: PNG image data, 320 x 155, 8-bit/color RGBA, non-interlaced root@kali:~/CTF/UTCTF2020/UTCTF2020/Forensic/Observe_Closely# binwalk Griffith_Observatory.png DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 PNG image, 320 x 155, 8-bit/color RGBA, non-interlaced 41 0x29 Zlib compressed data, default compression 127759 0x1F30F Zip archive data, at least v2.0 to extract, compressed size: 2587, uncompressed size: 16664, name: hidden_binary 130500 0x1FDC4 End of Zip archive, footer length: 22
binwalkを使って見たのは、何となく問題文からそんな気がしたからである。ファイルカービングは何でも良いが、今回はbinwalk -e
でいく。
# binwalk -e Griffith_Observatory.png DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 PNG image, 320 x 155, 8-bit/color RGBA, non-interlaced 41 0x29 Zlib compressed data, default compression 127759 0x1F30F Zip archive data, at least v2.0 to extract, compressed size: 2587, uncompressed size: 16664, name: hidden_binary 130500 0x1FDC4 End of Zip archive, footer length: 22 # cd _Griffith_Observatory.png.extracted/ # ls 1F30F.zip 29 29.zlib hidden_binary
zipが暗号化されていなかった所為か、zipの中身も一緒に出ている。
# strings hidden_binary /lib64/ld-linux-x86-64.so.2 (snip) Ah, you H found meH utflag{2H fbe9adc2H ad89c71dH a48cabe9H 0a121c0}H (snip)
動かすのが怖かったので、stringsを走らせた。
flag: utflag{2fbe9adc2ad89c71da48cabe90a121c0}
[basics]_forensics
My friend said they hid a flag in this picture, but it's broken! Now that I think about it, I don't even know if it really is a picture...
彼らの考えるForensicsとは一体何なのか、今明らかになる!
そんなことどうでもいいので、とりあえず与えられたファイルを見ていく。
# file secret.jpeg secret.jpeg: UTF-8 Unicode text, with CRLF line terminators
それはjpegではなかった。
# cat secret.jpeg | head The Project Gutenberg EBook of The History of Don Quixote by Miguel de Cervantes This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.net Title: The History of Don Quixote
テキストファイルのようである。
# strings secret.jpeg | grep "utflag" utflag{fil3_ext3nsi0ns_4r3nt_r34l}
flag: utflag{fil3_ext3nsi0ns_4r3nt_r34l}
これが、彼らの考えるForensicsであった......
The Legend of Hackerman, Pt. 1
My friend Hackerman tried to send me a secret transmission, but I think some of it got messed up in transit. Can you fix it?
では、そのHackermanさんから与えられたファイルがこちら。
# file hackerman.png hackerman.png: data
たぶんpngヘッダー直す系問題。
# cp hackerman.png fix.png # hexedit fix.png
自分は「hexedit」派。 間違いない。PNGといえば、
89 50 4E 47 0D 0A 1A 0A
から始まるので、このように書き換える。
# file fix.png fix.png: PNG image data, 1192 x 670, 8-bit/color RGBA, non-interlaced
flag: utflag{3lit3_h4ck3r}
最近はこんなものもあるらしい
# python PCRT.py -v -i fix2.png ____ ____ ____ _____ | _ \ / ___| _ \_ _| | |_) | | | |_) || | | __/| |___| _ < | | |_| \____|_| \_\|_| PNG Check & Repair Tool Project address: https://github.com/sherlly/PCRT Author: sherlly Version: 1.1 [Detected] Wrong PNG header! File header: 000000000D0A1A0A Correct header: 89504E470D0A1A0A [Notice] Auto fixing? (y or n) [default:y] y [Finished] Now header:89504E470D0A1A0A [Finished] Correct IHDR CRC (offset: 0x1D): 812E23AF [Finished] IHDR chunk check complete (offset: 0x8) [Finished] Correct IDAT chunk data length (offset: 0x2A1D length: 2000) [Finished] Correct IDAT CRC (offset: 0x4A25): CB097594 (snip) [Finished] Correct IDAT chunk data length (offset: 0x15F245 length: 1E83) [Finished] Correct IDAT CRC (offset: 0x1610D0): 69353954 [Finished] IDAT chunk check complete (offset: 0x2A1D) [Finished] Correct IEND chunk [Finished] IEND chunk check complete [Finished] PNG check complete [Notice] Show the repaired image? (y or n) [default:n] y
直ったwow......
ヘッダーだけで解決しないときに良いかもしれない。
The Legend of Hackerman, Pt. 2
Ok, I've received another file from Hackerman, but it's just a Word Document He said that he attached a picture of the flag, but I can't find it...
またまたハッカーマンから何か来たようである。与えられたファイルがこちら。
# file Hacker.docx Hacker.docx: Microsoft Word 2007+
このようなOffice系ファイルやオープンドキュメント系ファイルは、とりあえずunzipして色々見てみることが多い。
# cp Hacker.docx Hacker.zip # unzip Hacker.zip Archive: Hacker.zip (snip) inflating: word/media/image97.png inflating: word/media/image102.png inflating: word/media/image96.png inflating: word/media/image101.png inflating: word/media/image95.png inflating: word/media/image100.png inflating: word/media/image88.png inflating: word/media/image58.png (snip) inflating: word/media/image27.png inflating: word/media/image26.png inflating: word/media/image25.png inflating: word/media/image24.png inflating: word/media/image169.jpeg inflating: word/media/image37.png (snip)
大量に出てきた画像ファイルが明らかに怪しい。
# cd word/media/ # ls image1.png image12.png image140.png image161.png image182.png image37.png image58.png image79.png image10.png image120.png image141.png image162.png image183.png image38.png image59.png image8.png image100.png image121.png image142.png image163.png image184.png image39.png image6.png image80.png image101.png image122.png image143.png image164.png image19.png image4.png image60.png image81.png image102.png image123.png image144.png image165.png image2.png image40.png image61.png image82.png image103.png image124.png image145.png image166.png image20.png image41.png image62.png image83.png image104.png image125.png image146.png image167.png image21.png image42.png image63.png image84.png image105.png image126.png image147.png image168.png image22.png image43.png image64.png image85.png image106.png image127.png image148.png image169.jpeg image23.png image44.png image65.png image86.png image107.png image128.png image149.png image17.png image24.png image45.png image66.png image87.png image108.png image129.png image15.png image170.png image25.png image46.png image67.png image88.png image109.png image13.png image150.png image171.png image26.png image47.png image68.png image89.png image11.png image130.png image151.png image172.jpeg image27.png image48.png image69.png image9.png image110.png image131.png image152.png image173.png image28.png image49.png image7.png image90.png image111.png image132.png image153.png image174.png image29.png image5.png image70.png image91.png image112.png image133.png image154.png image175.jpeg image3.png image50.png image71.png image92.png image113.png image134.png image155.png image176.png image30.png image51.png image72.png image93.png image114.png image135.png image156.png image177.png image31.png image52.png image73.png image94.png image115.png image136.png image157.png image178.png image32.png image53.png image74.png image95.png image116.png image137.png image158.png image179.png image33.png image54.png image75.png image96.png image117.png image138.png image159.png image18.png image34.png image55.png image76.png image97.png image118.png image139.png image16.png image180.png image35.png image56.png image77.png image98.png image119.png image14.png image160.png image181.png image36.png image57.png image78.png image99.png
仕方がないので、順番に見ていく。
すると、「image23.png」にてflag発見。
flag: utflag{unz1p_3v3ryth1ng}
Zero
This file seems to be too large given how much text it contains, but I can find zero evidence of the flag. Maybe you'll have better luck than me?
与えられたファイルがこちら。
# file zero.txt zero.txt: UTF-8 Unicode (with BOM) text, with very long lines, with no line terminators # cat zero.txt Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus quis tempus ante, nec vehicula mi. Aliquam nec nisi ut neque interdum auctor. Aliquam felis orci, vestibulum sit amet ante at, consectetur lobortis eros. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. In finibus magna mauris, quis auctor libero congue quis. Duis sagittis consequat urna non tristique. Pellentesque eu lorem id quam vestibulum ultricies vel ac purus.
一見普通のテキストファイルだが、「zero evidence」が含まれている?
全然ぜ全然分からず、色々ガンバって辿り着いたのがこれ。
Unicode ゼロ幅スペースを利用して情報を隠して仕込む - A painter and a black cat
そんなんあるんか!早速試してみる。
Unicode Steganography with Zero-Width Characters
すげーです。なぜかLinux環境で表示させたやつのコピペは上手くいかなかった。
flag: utflag{whyNOT@sc11_4927aajbqk14}
Locked KitKat - zer0ops CTF 2020 Forensics writeup
世間様は4月ですが、自分は3月を振り返っています。
2020/03/07 09:00 JST — 2020/03/09 09:00 JSTに行われた「zer0ops CTF 2020」の「Locked KitKat」のwriteupをお届け。
ctftime.org
色んな人が書いているので、見飽きているかもしれないけれど見ている方には感謝しかない。
Locked KitKat
We've extracted the internal disk from the Android device of the suspect. Can you find the pattern to unlock the device? Please submit the correct pattern here.
とりあえず与えられたファイルの情報収集。
# file evidence.tar.gz_1a9268f23f3fb6590d05f30901b7be7b.tar.gz evidence.tar.gz_1a9268f23f3fb6590d05f30901b7be7b.tar.gz: gzip compressed data, last modified: Thu Mar 5 01:11:34 2020, from Unix, original size modulo 2^32 536872960 # tar zxvf evidence.tar.gz_1a9268f23f3fb6590d05f30901b7be7b.tar.gz android.4.4.x86.img # file android.4.4.x86.img android.4.4.x86.img: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (needs journal recovery) (extents) (large files)
パターンロックを解くのが今回の目的で、androidのイメージが渡されたってことはパターンロックファイルを持って来ればいいのでしょう。
ということで 「android pattern lock」とかでおググります。
良さそうなのを発見する。
Can You Bypass the Android Lock Screen?
このサイトから、「/data/system/gesture.key」にパターンロックが記録されていることが分かる。
では、「android.4.4.x86.img」から「gesture.key」を取り出すために、The Sleuth Kitでの解析準備に入る。
# img_stat -t android.4.4.x86.img raw # mmls android.4.4.x86.img Cannot determine partition type
てっきりファイル名「android.4.4.x86.img」からandroidの全体イメージかと思っていたけど違うようだ。
全体のイメージであれば複数のパーティション領域が確認できるはず。どういうことかというと。
Partitions and Images | Android Open Source Project
Android partitions explained
Android デバイスのパーティション構成概要 | まくまくAndroidノート
[Android] Androidの内部構成について - 攻撃は最大の防御なり
これらのサイトにあるように、androidはlinuxでいうrootディレクトリにあるような重要ディレクトリがパーティション分けされているような作りになっている。なので、本来ディスク全体のイメージは例えば、次のようになっている。
# mmls this_is_it.img GUID Partition Table (EFI) Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 000: Meta 0000000000 0000000000 0000000001 Safety Table 001: ------- 0000000000 0000000255 0000000256 Unallocated 002: Meta 0000000001 0000000001 0000000001 GPT Header 003: Meta 0000000002 0000000012 0000000011 Partition Table 004: 000 0000000256 0000131327 0000131072 modem 005: 001 0000131328 0000132351 0000001024 sbl1 006: 002 0000132352 0000132415 0000000064 DDR 007: ------- 0000132416 0000132607 0000000192 Unallocated 008: 003 0000132608 0000134655 0000002048 aboot 009: ------- 0000134656 0000135607 0000000952 Unallocated 010: 004 0000135608 0000136107 0000000500 rpm 011: ------- 0000136108 0000136607 0000000500 Unallocated 012: 005 0000136608 0000137607 0000001000 tz 013: 006 0000137608 0000137863 0000000256 hyp 014: ------- 0000137864 0000138631 0000000768 Unallocated 015: 007 0000138632 0000139655 0000001024 utags 016: 008 0000139656 0000143751 0000004096 logs 017: ------- 0000143752 0000143871 0000000120 Unallocated 018: 009 0000143872 0000143903 0000000032 sec 019: ------- 0000143904 0000144127 0000000224 Unallocated 020: 010 0000144128 0000151175 0000007048 factorytune1 021: 011 0000151176 0000154623 0000003448 padA 022: 012 0000154624 0000155647 0000001024 metadata 023: 013 0000155648 0000157695 0000002048 abootBackup 024: ------- 0000157696 0000158647 0000000952 Unallocated 025: 014 0000158648 0000159147 0000000500 rpmBackup 026: ------- 0000159148 0000159647 0000000500 Unallocated 027: 015 0000159648 0000160647 0000001000 tzBackup 028: 016 0000160648 0000161671 0000001024 utagsBackup 029: 017 0000161672 0000161927 0000000256 hypBackup 030: ------- 0000161928 0000162695 0000000768 Unallocated 031: 018 0000162696 0000172031 0000009336 padB 032: 019 0000172032 0000173055 0000001024 frp 033: 020 0000173056 0000176127 0000003072 modemst1 034: 021 0000176128 0000179199 0000003072 modemst2 035: 022 0000179200 0000180175 0000000976 hob 036: 023 0000180176 0000180239 0000000064 dhob 037: ------- 0000180240 0000180479 0000000240 Unallocated 038: 024 0000180480 0000183551 0000003072 fsg 039: 025 0000183552 0000183553 0000000002 fsc 040: 026 0000183554 0000183569 0000000016 ssd 041: 027 0000183570 0000183825 0000000256 cid 042: 028 0000183826 0000192017 0000008192 logo 043: 029 0000192018 0000200209 0000008192 clogo 044: ------- 0000200210 0000200447 0000000238 Unallocated 045: 030 0000200448 0000216831 0000016384 persist 046: 031 0000216832 0000217855 0000001024 misc 047: 032 0000217856 0000283391 0000065536 boot 048: 033 0000283392 0000348895 0000065504 recovery 049: 034 0000348896 0000369487 0000020592 factorytune2 050: ------- 0000369488 0000369663 0000000176 Unallocated 051: 035 0000369664 0000386047 0000016384 kpan 052: 036 0000386048 0000393215 0000007168 padC 053: 037 0000393216 0000425983 0000032768 sp 054: 038 0000425984 0000458751 0000032768 keystore 055: 039 0000458752 0000491519 0000032768 oem 056: 040 0000491520 0000524287 0000032768 carrier 057: 041 0000524288 0004227071 0003702784 system 058: 042 0004227072 0004751359 0000524288 cache 059: 043 0004751360 0015204095 0010452736 userdata 060: ------- 0015204096 0015269887 0000065792 Unallocated
凄いごちゃごちゃしている。そんで多分ちょっと古い。
~閑話休題~
話を戻して、「gesture.key」が必要なのでおそらく今回与えられたイメージはユーザーデータを扱う「/data」パーティションのハズ。
# fsstat -t android.4.4.x86.img ext4 # fls -i raw -f ext4 android.4.4.x86.img d/d 11: lost+found d/d 12: app d/d 27: nativebenchmark d/d 29: nativetest d/d 8193: dontpanic d/d 16385: misc d/d 24577: local d/d 8194: data d/d 24579: app-private d/d 8195: app-asec d/d 24580: app-lib d/d 8196: property d/d 8197: ssh d/d 24581: dalvik-cache d/d 24582: resource-cache d/d 24583: drm d/d 8199: mediadrm l/l 36: bugreports d/d 24584: security d/d 8200: user d/d 24585: media d/d 8204: system d/d 16402: backup r/r 37: .layout_version V/V 32769: $OrphanFiles (別にfls android.4.4.x86.imgでも良いんですけどね)
思った通り、androidの「data」パーティションのようである。つまり、「/data/system/gesture.key」にあるということだったので「/system」下に目的ファイルがある。
# fls -i raw -f ext4 android.4.4.x86.img 8204 r/r 8207: batterystats.bin d/d 8206: procstats d/d 8205: ifw d/d 8210: users d/d 8208: usagestats r/r 8214: uiderrors.txt r/r 8385: packages.xml r/r 8361: packages.list r/r 8346: entropy.dat d/d 8354: sync d/d 8359: inputmethod r/r 8363: locksettings.db d/d 8362: netstats r/r 8364: locksettings.db-wal r/r 8365: locksettings.db-shm r/r 8366: framework_atlas.config r/r 8383: called_pre_boots.dat s/h 8384: ndebugsocket d/d 8414: dropbox r/r 8396: appops.xml d/d 8421: registered_services r/r 8495: gesture.key r/r 8497: device_policies.xml r/r * 8497(realloc): device_policies.xml.tmp # icat -i raw -f ext4 android.4.4.x86.img 8495 > gesture.key
「gesture.key」は取得した。ここから脳死でパターンロックを解読する場合、「android gesture key decode」等とおググりなさって出てきたプログラムを走らせれば良い。
脳死でパターンロック解読例
GitHub - sch3m4/androidpatternlock: A little Python tool to crack the Pattern Lock on Android devices
この「aplc.py」を使用。
# python aplc.py gesture.key ################################ # Android Pattern Lock Cracker # # v0.2 # # ---------------------------- # # Written by Chema Garcia # # http://safetybits.net # # chema@safetybits.net # # @sch3m4 # ################################ [i] Taken from: http://forensics.spreitzenbarth.de/2012/02/28/cracking-the-pattern-lock-on-android/ [:D] The pattern has been FOUND!!! => 321564 [+] Gesture: ----- ----- ----- | | | 3 | | 2 | ----- ----- ----- ----- ----- ----- | 1 | | 6 | | 4 | ----- ----- ----- ----- ----- ----- | 5 | | | | | ----- ----- ----- It took: 0.7533 seconds
今回の場合は用意されたwebページでパターンロックを入力すると、flagが貰えた。
flag: zer0pts{n0th1ng_1s_m0r3_pr4ct1c4l_th4n_brut3_f0rc1ng}
「gesture.key」をもう少し詳しく見たい場合
「gesture.key」には、パターンロック画面の3×3に左上から例えば1,2,3,,,,9のように番号づけして、パターンロック解除に必要な数字の順番(最小4桁、最大9桁)がソルト無しのSHA-1ハッシュで記録されているらしい(参考
Password storage in Android M)。
Android's pattern unlock is entered by joining at least four points on a 3×3 matrix (some custom ROMs allow a bigger matrix). Each point can be used only once (crossed points are disregarded) and the maximum number of points is nine. The pattern is internally converted to a byte sequence, with each point represented by its index, where 0 is top left and 8 is bottom right. Thus the pattern is similar to a PIN with a minimum of four and maximum of nine digits which uses only nine distinct digits (0 to 8). However, because points cannot be repeated, the number of variations in an unlock pattern is considerably lower compared to those of a nine-digit PIN. As pattern unlock is the original and initially sole unlock method supported by Android, a fair amount of research has been done about it's (in)security. It has been shown that patterns can be guessed quite reliably using the so called smudge attack, and that the total number of possible combinations is less than 400 thousand, with only 1624 combinations for 4-dot (the default) patterns.
なので、ハッシュとパターンの番号のリスト(AndroidGestureSHA1.txt)と比較すれば、簡単に分かってしまう。
# grep -i `xxd -p gesture.key ` AndroidGestureSHA1.txt 432675;03 02 01 05 06 04;179E58178A7C5195110E0A26D91C71926AF01349
よって脳死と同じ結果が得られた。
どういうことかというと、
----- ----- ----- | 1 | | 2 | | 3 | ----- ----- ----- ----- ----- ----- | 4 | | 5 | | 6 | ----- ----- ----- ----- ----- ----- | 7 | | 8 | | 9 | ----- ----- -----
例えばこのように番号付けして、パターンロック解除パターンをSHA1ハッシュしたものが「gesture.key」らしい。実際はこのようになっている。
# xxd gesture.key 00000000: 179e 5817 8a7c 5195 110e 0a26 d91c 7192 ..X..|Q....&..q. 00000010: 6af0 1349 j..I # cat AndroidGestureSHA1.txt | head ; Android OS gesture.key dictionary ; (c) Oxygen Software 2011 ; http://www.oxygen-forensic.com ; http://www.android-forensics.com Gesture;Pattern sequence;Pattern SHA-1; 1234;00 01 02 03;A02A05B025B928C039CF1AE7E8EE04E7C190C0DB 1235;00 01 02 04;6E36A9BFACF6C4637D64042B11CB78BFDDAF8BF3 1236;00 01 02 05;101B2A675E9FB9546336D5B9EF70418B594184F4 1237;00 01 02 06;30F26B9825EA6F2EF6DBF6A88959774314D83F65 1238;00 01 02 07;8C33B9D8BB8398DA8F19D9E946D589F32321B7BD
じゃあ、同じように最小4桁、最大9桁の数字をSHA1ハッシュすればパターンロックファイルが再現できるのかというと、そうでは無かった。なぜか同じハッシュを作ろうと思っても作れなかった。単純に数字の組み合わせのハッシュではなく、パターンの座標とかがハッシュされているのだろうか。
このハッシュファイルは一体何のSHA1ハッシュ!?
謎が謎を呼ぶ。
何か情報を持っている人がいれば教えてください。
Autopsy & The Sleuth Kitの基本的な使い方(2020/04/12更新)
autopsyとthe sleuth kitいえば、ディスクイメージの解析に使われるツールキットである。
この記事では、基本的なautopsyとthe sleuth kitの使い方を軽くさらっていく。
The Sleuth Kit (TSK) & Autopsy: Open Source Digital Forensics Tools
今回はイメージ解析検証のために「Digital Forensics Tool Testing Images」のうちのJPEG Search Test #8で配布されている「8-jpeg-search.dd」のイメージを利用する。
%注意%
あくまでCTFとかで気軽に使うレベルの簡単な使い方の話をしているので、実務レベルの基本設定ではないと思います。
Autopsy(GUI版,4.10.0)
起動には時間が掛かるが使い方が一番分かりやすいのは、やはりGUI版。主にwindowsではGUIでインストールする人が多いのでは。
GUI版ではautopsyを起動すると、始めにケースを選択する画面が開く。
これは、統合開発環境とかでいうプロジェクトを選択するような画面。とりあえず初めてなのでNew caseを選択してケースを作成。
特にこだわりがなければケース名を指定するだけで、付加情報は入力しなくても良いと思っている。
ケースが作成されればすぐにデータソースの追加が選択されるが、自分でデータソースを追加する場合は左上の「データソースの追加」を選択する。
今回はイメージファイルの解析なのでイメージファイルを選択して、次へ。
解析したいイメージファイルのパスを選択する。タイムゾーンは、状況に応じて変更する。
不必要な部分があれば、無駄にモジュールを読み込むことが無いのでイメージ読み込みの時間が減るはずだが、あまり気にせずデフォルトでやっている。
ここで、赤文字でエラーとか出なければデータソースの追加成功。エラーが出ていれば、エラーに応じて変更を加えるか、イメージ自体に問題があればそちらをどうにかしてください。
ここまで来ればもう簡単。「8-jpeg-search.dd」を選択すれば、Explorerのようにイメージファイルを探索できる。
任意のディレクトリやファイルを右クリックすることで、ファイル抽出が可能である。
また、おすすめは「Timeline」。
ファイルアクセスの記録とか色々可視化してくれる。
ケースの削除の仕方はよく分からないので、ケース作成時に作成されたフォルダごと消してます。
Autopsy(WebGUI版)
AutopsyはWevGUI版もあって、Linux環境でよく使われているイメージ?がある。
とりあえず自分はKali linux環境でやっている。
まずは、autopsyを起動すると,
root@kali:~# autopsy ============================================================================ Autopsy Forensic Browser http://www.sleuthkit.org/autopsy/ ver 2.24 ============================================================================ Evidence Locker: /var/lib/autopsy Start Time: Wed Apr 1 23:28:54 2020 Remote Host: localhost Local Port: 9999 Open an HTML browser on the remote host and paste this URL in it: http://localhost:9999/autopsy Keep this process running and use <ctrl-c> to exit
このように準備されるので、webブラウザで「http://localhost:9999/autopsy」にアクセスすると、こちらもケース選択から始まる。
初めなので、NEW CASEを選択して、Case Nameを入力。
ここでケースの作成は完了するが、ケースの中にhostを作成する必要がある。
Caseの中で、hostごとに作業スペースがあるらしい。
特に必要がなければ、デフォルトでいく。
ここまで、来るとやっと「ADD IMAGE」が選択できるので解析するイメージを選択する。
「ADD IMAGE FILE」を選択すれば、イメージ選択画面に移る。Locationには絶対パスでファイルを指定する。ファイルの絶対パスの取得はLinux環境では、find `pwd` -name "[filename]"
がおススメ。例えば今回の場合。
# ls 8-jpeg-search.dd COPYING-GNU.txt README.txt index.html results.txt # find `pwd` -name "8-jpeg-search.dd" /root/DFIR/test/8-jpeg-search/8-jpeg-search.dd
このようにパス取得した。
イメージ選択画面では、イメージファイルのタイプとして「Disk」か「Partition」を選択できる。この判断は、解析対象がディスク全体のイメージならば「Disk」、パーティションやddイメージであれば「Partition」を選択。最後のImport Methodは基本的にcopyを選んでおけば良いと思っている。
特に必要なければ「Ignore」で、「File Sytem」に関して問題が無さそうならばそのまま。
イメージの追加に成功したならば、いざ「ANALYZE」!
遷移後の画面で、「FILE ANALYSIS」を選択するとGUI版と同じような画面を拝める。あとは、ディレクトリを選択すれば中に入れるし、ファイルを選択すればファイルの情報を見れえる。正直なところ、WebGUIはあまり使ったことがないのでこれ以上深い話はしない。
The Sleuth Kit
The Sleuth KitはAutopsyのコマンドラインツールキットである。
このブログでもちょっと扱ったことある。もしかしたら今回よりも詳しいこと書いているかもしれない。
The Sleuth Kitの使い方に触れながら Determine Window Version! - 4ensiX
「The Sleuth Kit」と調べると、とりあえずfls
使ってイメージの中を探索して、icat
でファイルを取り出すと書いてあるけど、それだけじゃ開けないイメージだってある。
パーティションだけのイメージファイルならば、fls [image_file]
で事足りるかもしれないが、ディスク全体のイメージファイルが渡された場合、ファイルタイプやファイルシステム、パーティションのアドレスを渡さなければ解析ができない。
結論から言うと今回の「8-jpeg-search.dd」の場合はパーティションなのでfls [image_file]
でいけるが丁寧にやっていく。
1. イメージファイルのタイプを判定
img_stat image_file
を利用。今回の場合は、
# img_stat -t 8-jpeg-search.dd raw
欲しい情報のみに絞るために-tオプションを利用。
2. パーティションを確認
mmls image_file
を利用する。解析対象が、パーティションであれば必要ない。よって今回のケースでは行う必要はないがmmls
を走らせてみると、
# mmls 8-jpeg-search.dd Cannot determine partition type
ディスク全体のイメージファイルに対して行った場合には、例としてThe Sleuth Kitの使い方に触れながら Determine Window Version! - 4ensiXで扱ったwindows10を見ると
#mmls win10simple.raw DOS Partition Table Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 000: Meta 0000000000 0000000000 0000000001 Primary Table (#0) 001: ------- 0000000000 0000002047 0000002048 Unallocated 002: 000:000 0000002048 0001187839 0001185792 NTFS / exFAT (0x07) 003: 000:001 0001187840 0025163775 0023975936 NTFS / exFAT (0x07) 004: ------- 0025163776 0025165823 0000002048 Unallocated
ディスク全体のイメージファイルであれば、fls
使用時にパーティション領域の始まりを指定する必要があるので、この確認は重要となる。
今のところの経験だと、Linuxと古いwindwos(XP以前?)は一つ目のパーティション領域、新しいwindowsは二つ目のパーティション領域(上記の「003: 000:001 0001187840 0025163775 0023975936 NTFS / exFAT (0x07)
」)を見ることが多いと思われる。
androidは、linuxのルートディレクトリ内のディレクトリがパーティションされているような作りになっている。
3. ファイルシステムを確認
fsstat -i file_type [-o partition_start] -t image_file
を利用する。今回の場合は
# fsstat -i raw -t 8-jpeg-search.dd ntfs
欲しい情報のみに絞るために-tオプションを利用した。
4. イメージの解析を開始
ここまで来れば、イメージの解析を始められるのでfls -i file_type -f file_system [-o partition_start] image_file [inode number]
を利用する。また、i-node番号を付けることで、ディレクトリの中身を確認できる。今回の場合。
# fls -i raw -f ntfs 8-jpeg-search.dd r/r 4-128-4: $AttrDef r/r 8-128-2: $BadClus r/r 8-128-1: $BadClus:$Bad r/r 6-128-1: $Bitmap r/r 7-128-1: $Boot d/d 11-144-4: $Extend r/r 2-128-1: $LogFile r/r 0-128-1: $MFT r/r 1-128-1: $MFTMirr r/r 9-128-8: $Secure:$SDS r/r 9-144-11: $Secure:$SDH r/r 9-144-5: $Secure:$SII r/r 10-128-1: $UpCase r/r 3-128-3: $Volume d/d 27-144-1: alloc d/d 37-144-1: archive d/d 30-144-1: del1 d/d 47-144-1: del2 d/d 33-144-1: invalid d/d 41-144-1: misc d/d 48-144-1: RECYCLER d/d 45-144-1: System Volume Information V/V 52: $OrphanFiles # fls -i raw -f ntfs 8-jpeg-search.dd 27-144-1 (イメージ的にはcd alloc/ をしたような感じ) r/r 29-128-3: file1.jpg r/r 28-128-3: file2.dat
このように、探索できる。ここには、ファイルタイプ、i-node番号、ファイル名が出力されている。
5. ファイルの抽出
icat -i file_type -f file_system [-o partition_start] image_file] inode_number > file
と、イメージ内のファイルを任意のファイル名で取得する。上記で発見した「file1.jpg」を抽出する場合には以下のように、fls
コマンドで確認したi-node番号「29-128-3」を指定してicatを利用する。
# icat -i raw -f ntfs 8-jpeg-search.dd 29-128-3 > file1.jpg # file file1.jpg file1.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 698x752, components 3
6. ディレクトリ/フォルダの抽出
tsk_recover [-a/-e] -i file_type -f file_system [-o partition_start] -d directory_inode number image_file output_directory
で取り出せる。ここで、tsk_recover
はデフォルトだと未割当のファイル(削除済み等)しか対象になっていない。オプションを付けて適宜、割り当て状態ファイル(-a)、未割当割り当て含む(-e)を対象として利用する。「alloc」ディレクトリを抽出する場合には、「alloc」のi-node番号を指定して以下のように利用する。
# fls -i raw -f ntfs 8-jpeg-search.dd (snip) d/d 27-144-1: alloc (snip) # fls -i raw -f ntfs 8-jpeg-search.dd 27-144-1 r/r 29-128-3: file1.jpg r/r 28-128-3: file2.dat # cd alloc/ ~/alloc# ls file1.jpg file2.dat
ついでに、タイムラインのようなものの取得は
ここにあるようにできる。今回の場合は
# fls -m " " -r 8-jpeg-search.dd > body2.txt # cat body2.txt (snip) 0|C:/alloc ($FILE_NAME)|27-48-4|d/drwxrwxrwx|0|0|76|1086838026|1086838026|1086838026|1086838026 0|C:/alloc|27-144-1|d/drwxrwxrwx|0|0|256|1086838056|1086838056|1086838056|1086838026 0|C:/alloc/file1.jpg ($FILE_NAME)|29-48-2|r/rrwxrwxrwx|0|0|84|1086838056|1086838056|1086838056|1086838056 0|C:/alloc/file1.jpg|29-128-3|r/rrwxrwxrwx|0|0|274260|1086838056|1086850780|1086838056|1086838056 0|C:/alloc/file2.dat ($FILE_NAME)|28-48-2|r/rrwxrwxrwx|0|0|84|1086838056|1086838056|1086838056|1086838056 0|C:/alloc/file2.dat|28-128-3|r/rrwxrwxrwx|0|0|26081|1086838056|1086850012|1086838056|1086838056 0|C:/archive ($FILE_NAME)|37-48-4|d/drwxrwxrwx|0|0|80|1086838117|1086838117|1086838117|1086838117 0|C:/archive|37-144-1|d/drwxrwxrwx|0|0|472|1086838132|1086838131|1086838131|1086838117 0|C:/archive/file10.tar.gz ($FILE_NAME)|38-48-2|r/rrwxrwxrwx|0|0|92|1086838130|1086838130|1086838130|1086838130 0|C:/archive/file10.tar.gz|38-128-4|r/rrwxrwxrwx|0|0|207272|1086838131|1086851934|1086838131|1086838130 0|C:/archive/file8.zip ($FILE_NAME)|39-48-2|r/rrwxrwxrwx|0|0|84|1086838131|1086838131|1086838131|1086838131 0|C:/archive/file8.zip|39-128-3|r/rrwxrwxrwx|0|0|335371|1086838131|1086851802|1086838131|1086838131 0|C:/archive/file9.boo ($FILE_NAME)|40-48-2|r/rrwxrwxrwx|0|0|84|1086838131|1086838131|1086838131|1086838131 0|C:/archive/file9.boo|40-128-3|r/rrwxrwxrwx|0|0|294124|1086838134|1086851866|1086838134|1086838131 0|C:/del1 ($FILE_NAME)|30-48-5|d/drwxrwxrwx|0|0|74|1086838080|1086838080|1086838080|1086838064 0|C:/del1|30-144-1|d/drwxrwxrwx|0|0|48|1086839955|1086839955|1086839955|1086838064 0|C:/del1/file6.jpg ($FILE_NAME) (deleted)|32-48-2|-/rrwxrwxrwx|0|0|84|1086838080|1086838080|1086838080|1086838080 0|C:/del1/file6.jpg (deleted)|32-128-3|-/rrwxrwxrwx|0|0|175630|1086838080|1086850088|1086838080|1086838080 0|C:/del2 ($FILE_NAME)|47-48-4|d/drwxrwxrwx|0|0|74|1086838999|1086838999|1086838999|1086838999 0|C:/del2|47-144-1|d/drwxrwxrwx|0|0|48|1086839963|1086839963|1086839963|1086838999 0|C:/del2/file7.hmm ($FILE_NAME) (deleted)|31-48-4|-/rrwxrwxrwx|0|0|84|1086838080|1086850158|1086838080|1086838080 0|C:/del2/file7.hmm (deleted)|31-128-3|-/rrwxrwxrwx|0|0|326859|1086839018|1086850158|1086839024|1086838080 0|C:/invalid ($FILE_NAME)|33-48-4|d/drwxrwxrwx|0|0|80|1086838088|1086838088|1086838088|1086838088 0|C:/invalid|33-144-1|d/drwxrwxrwx|0|0|360|1086838101|1086838100|1086838100|1086838088 0|C:/invalid/file3.jpg ($FILE_NAME)|35-48-2|r/rrwxrwxrwx|0|0|84|1086838100|1086838100|1086838100|1086838100 0|C:/invalid/file3.jpg|35-128-3|r/rrwxrwxrwx|0|0|214228|1086838100|1086852422|1086838100|1086838100 0|C:/invalid/file4.jpg ($FILE_NAME)|36-48-2|r/rrwxrwxrwx|0|0|84|1086838100|1086838100|1086838100|1086838100 0|C:/invalid/file4.jpg|36-128-3|r/rrwxrwxrwx|0|0|189021|1086838102|1086853086|1086838102|1086838100 0|C:/invalid/file5.rtf ($FILE_NAME)|34-48-2|r/rrwxrwxrwx|0|0|84|1086838100|1086838100|1086838100|1086838100 0|C:/invalid/file5.rtf|34-128-3|r/rrwxrwxrwx|0|0|148102|1086838100|1086853314|1086838100|1086838100 0|C:/misc ($FILE_NAME)|41-48-4|d/drwxrwxrwx|0|0|74|1086838140|1086838140|1086838140|1086838140 0|C:/misc|41-144-1|d/drwxrwxrwx|0|0|360|1086838158|1086838158|1086838158|1086838140 0|C:/misc/file11.dat ($FILE_NAME)|42-48-2|r/rrwxrwxrwx|0|0|86|1086838157|1086838157|1086838157|1086838157 0|C:/misc/file11.dat|42-128-3|r/rrwxrwxrwx|0|0|272753|1086838157|1086853486|1086838157|1086838157 0|C:/misc/file12.doc ($FILE_NAME)|43-48-2|r/rrwxrwxrwx|0|0|86|1086838157|1086838157|1086838157|1086838157 0|C:/misc/file12.doc|43-128-3|r/rrwxrwxrwx|0|0|131584|1086838158|1086852058|1086838158|1086838157 0|C:/misc/file13.dll ($FILE_NAME)|44-48-2|r/rrwxrwxrwx|0|0|86|1086838158|1086838158|1086838158|1086838158 0|C:/misc/file13.dll|44-128-3|r/rrwxrwxrwx|0|0|58391|1086838185|1086838185|1086838185|1086838158 0|C:/misc/file13.dll:here|44-128-5|r/rrwxrwxrwx|0|0|124038|1086838185|1086838185|1086838185|1086838158 0|C:/RECYCLER ($FILE_NAME)|48-48-2|d/dr-xr-xr-x|0|0|82|1086839950|1086839950|1086839950|1086839950 0|C:/RECYCLER|48-144-1|d/dr-xr-xr-x|0|0|328|1086839950|1086839950|1086839950|1086839950 0|C:/RECYCLER/S-1-5-21-1757981266-484763869-1060284298-1003 ($FILE_NAME)|49-48-2|d/dr-xr-xr-x|0|0|156|1086839950|1086839950|1086839950|1086839950 0|C:/RECYCLER/S-1-5-21-1757981266-484763869-1060284298-1003|49-144-1|d/dr-xr-xr-x|0|0|248|1086839950|1086839950|1086839950|1086839950 0|C:/RECYCLER/S-1-5-21-1757981266-484763869-1060284298-1003/desktop.ini ($FILE_NAME)|50-48-2|r/rr-xr-xr-x|0|0|88|1086839950|1086839950|1086839950|1086839950 0|C:/RECYCLER/S-1-5-21-1757981266-484763869-1060284298-1003/desktop.ini|50-128-1|r/rr-xr-xr-x|0|0|65|1086839950|1086839950|1086839950|1086839950 0|C:/RECYCLER/S-1-5-21-1757981266-484763869-1060284298-1003/INFO2 ($FILE_NAME)|51-48-2|r/rr-xr-xr-x|0|0|76|1086839950|1086839950|1086839950|1086839950 0|C:/RECYCLER/S-1-5-21-1757981266-484763869-1060284298-1003/INFO2|51-128-1|r/rr-xr-xr-x|0|0|20|1086839971|1086839971|1086839971|1086839950 0|C:/System Volume Information ($FILE_NAME)|45-48-2|d/dr-xr-xr-x|0|0|116|1086838858|1086838858|1086838858|1086838858 0|C:/System Volume Information|45-144-1|d/dr-xr-xr-x|0|0|160|1086839893|1086838858|1086838858|1086838858 0|C:/System Volume Information/tracking.log ($FILE_NAME)|46-48-5|r/rr-xr-xr-x|0|0|90|1086838858|1086838858|1086838858|1086838858 0|C:/System Volume Information/tracking.log|46-128-4|r/rr-xr-xr-x|0|0|20480|1086839077|1086839077|1086839077|1086838858 0|C:/$OrphanFiles|52|V/V---------|0|0|0|0|0|0|0
こんな感じで取得した。
The Sleuth Kitに関しては、ここら辺も見て頂きたい。
とりあえず以上!!!!!
NeverLAN CTF 2020 PCAP/Forensic writeup
今回は、2020/02/09 00:00 JST — 2020/02/12 08:00 JSTに行われた NeverLAN CTF 2020のPCAPとForensicジャンルのwriteupをお届けする。
とてもとっつき易く基本を学べるので、何も分からない状態で初めても大丈夫そうなCTF。今言っても意味ないけれど、オンラインCTFの入門としてとてもおススメ。
PCAP
このジャンルの問題は全て、writeupを書くほどのものか怪しいレベルの簡単さであったのでほんの少し触れるだけ。
FTP
FTPのパケットキャプチャファイルが与えられる。FTPはデフォルトで暗号化されていないので丸見えというお話。ストリームを眺めていればflag{*}が見える。
flag: flag{sftp_OR_ftps_not_ftp}
Teletype Network
問題のまんまtelnetのパケットキャプチャファイルが与えれる。こちらもデフォルトでは暗号化されていないので通信が見える。
flag: flag{telnet_1s_n0t_secur3}
Unsecured Login
httpの通信でログインしているので通信みえちゃうというお話。ストリームを眺めているとpassword入力にflagがある。
flag: flag{n0httpsn0l0gin}
Unsecured Login2
ちゃんとパケットの中身を見ていないので「Unsecured Login」と違いが分からなかった。同じようなところにflagがある。
flag: flag{ensure_https_is_always_used}
PCAPジャンルはパケットキャプチャファイルにstrings | grep でflag取れた。
Forensic
Forensicのキソのキソを学べる問題。
Listen to this
You hear that?
*Your flag will be in the normal flag{flagGoesHere] syntax
-ps This guy might be important
-ZestyFE
まず「HiddenAudio.mp3」が与えられる。このファイルは音声ファイルであり、「HiddenAuidio」という名であるからには何か音声が隠されているのだろうという推測でaudacityで開く。ただ波形をよく見ても分からなかったので、ctfでありがちな音声のスペクトログラム表示してみる。スペクトログラムを表示して一番初めのあたりを拡大してみると何か見える。
何かモールス信号ぽい気がするので、変換サイトで見てみる。
「FLA」とくれば、次は「G」となりそうな気がする。方向性は良さそうだが見づらいので、スペクトログラムを弄りたい。
波形を眺めたり、音を聞いているとボーカルを除去すればもう少し見やすくなる気がしてきた。
[エフェクト]->[Plug-in]->[ボーカルの低減と分離]を選択。そのまま「OK」を選択してみる。
凄い見やすくなったのでこれを変換にかける。変換してみると、flag{*}を何度も繰り返していることが分かる。
flag: flag{ditsanddahsforlife}
[メモ]もしかして、mp3はbinwalkに引っかからない?
Look into the past
We've captured a snapshot of a computer, but it seems the user was able to encrypt a file before we got to it. Can you figure out what they encrypted?
Your flag will be in the normal flag{flagGoesHere} syntax.
-N30
与えられた.tar.gzのファイルを解凍する。
$ ls look_into_the_past/ bin boot dev etc home lib media mnt opt proc root run sbin srv sys tmp usr var
マシンのルートディレクトリぽい。問題文から/home/Userに何かありそうな気がする。
$ ls * Desktop: Documents: flag.txt.enc libssl-flag.txt.enc Downloads: Music: Pictures: doggo.jpeg Public: Videos:
/home/User以下のディレクトリをみてみると、明らかに怪しい「flag.txt.enc」というファイルがある。.encとなっているということは暗号化されていそうな気がする。
$ file Documents/* # /home/User Documents/flag.txt.enc: openssl enc'd data with salted password Documents/libssl-flag.txt.enc: openssl enc'd data with salted password
やはりこのファイルは暗号化されている。opensslを使って復号するには、パスワードが必要になる。一瞬パスワードクラックを考えたが、このパスワードはどこかに在りそうな気がした。なぜならこの問題は「Look into the past」である。過去を見る。また、今回のような暗号化はコマンドラインで行われることが多い。よって「.bash_history」に何か手がかりがありそうな気がする。
$ ls -al 合計 52 drwxr-xr-x 9 1000 1000 4096 2月 9 01:24 . drwxr-xr-x 3 1000 1000 4096 2月 9 01:24 .. -rw-r--r-- 1 1000 1000 349 2月 7 03:33 .bash_history -rw-r--r-- 1 1000 1000 864 2月 7 03:34 .bashrc -rw-r--r-- 1 1000 1000 672 2月 7 03:34 .profile -rw-r--r-- 1 1000 1000 37 2月 7 03:33 .vimrc drwxr-xr-x 2 1000 1000 4096 2月 9 01:24 Desktop drwxr-xr-x 2 1000 1000 4096 2月 9 01:52 Documents drwxr-xr-x 2 1000 1000 4096 2月 9 01:24 Downloads drwxr-xr-x 2 1000 1000 4096 2月 9 01:24 Music drwxr-xr-x 2 1000 1000 4096 2月 9 01:24 Pictures drwxr-xr-x 2 1000 1000 4096 2月 9 01:24 Public drwxr-xr-x 2 1000 1000 4096 2月 9 01:24 Videos $ cat .bash_history cd Documents openssl enc -aes-256-cbc -salt -in flag.txt -out flag.txt.enc -k $(cat $pass1)$pass2$pass3 steghide embed -cf doggo.jpeg -ef $pass1 mv doggo.jpeg ~/Pictures useradd -p '$pass2' user sqlite3 /opt/table.db "INSERT INTO passwords values ('1', $pass3)" tar -zcf /opt/table.db.tar.gz /opt/table.db rm $pass1 unset $pass2 unset $pass3 exit
「.bash_history」に暗号化時のコマンドがしっかり残っていた。これに従って復号化すればいいのだが、パスワードは複数の場所に散りばめられているようである。なので一ずつ見つけていく。
まずは、「doggo.jpeg」に隠された「$pass1」から見ていく。「steghide」は画像ファイルにテキストなどを埋め込むステガノグラフィツールである。おそらく、「doggo.jpeg」さえあれば「$pass1」は見つけられる。
$ steghide extract -sf doggo.jpeg -xf pass1.txt $ cat pass1.txt JXrTLzijLb
展開時にパスワード入力が求められるが、パスワードは不要であった。
次に、追加したuserのパスワードが「$pass2」であるようなので、「/etc/shadow」をチェックする。
$ cat ../../etc/shadow # from /home/User (snip) user:KI6VWx09JJ:18011:0:99999:7:::
最後に、SQLiteのデータベースに「$pass3」が入っているようなので、「/opt/table.tar.gz」を解凍して「table.db」を「DB browser for SQLite」で確認する。 以上で、「flag.txt.enc」を復号するためのパスワードが揃った。
$ openssl enc -d -aes-256-cbc -salt -k JXrTLzijLbKI6VWx09JJnBNfDKbP5n -in Documents/flag.txt.enc -out flag.txt *** WARNING : deprecated key derivation used. Using -iter or -pbkdf2 would be better. $ cat flag.txt flag{h1st0ry_1n_th3_m4k1ng}
flag: flag{h1st0ry_1n_th3_m4k1ng}
Open Backpack
There's more to this picture
Your flag will be in the normal flag{flagGoesHere} syntax.
-NullB0n3s
まず次のようなファイル「openbackpack.jpg」が与えられる。 ここで、ファイル名や問題から「openbackpack.jpg」に他のファイルが含まれているような気がするのでbinwalkでチェックする。
$ binwalk openbackpack.jpg DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 JPEG image data, JFIF standard 1.01 30 0x1E TIFF image data, little-endian offset of first image directory: 8 328 0x148 JPEG image data, JFIF standard 1.01 9703 0x25E7 Copyright string: "CopyrightOwner> <rdf:Seq/> </plus:CopyrightOwner> <plus:Licensor> <rdf:Seq/> </plus:Licensor> </rdf:Description> </rdf:RDF> </x:" 9737 0x2609 Copyright string: "CopyrightOwner> <plus:Licensor> <rdf:Seq/> </plus:Licensor> </rdf:Description> </rdf:RDF> </x:xmpmeta> " 139267 0x22003 Zip archive data, at least v2.0 to extract, compressed size: 15928, uncompressed size: 695647, name: flag.png 155339 0x25ECB End of Zip archive, footer length: 22
思った通りいくつかファイルが含まれおり、それらのファイルの一つに「flag.png」を含むzipファイルを確認した。ここからファイルをカービングするのは、このままbinwalkでも、foremostでも宗教上の理由とかで色々あると思う。自分はddで。
$ dd if=openbackpack.jpg bs=1 skip=139267 of=output.zip 16094+0 レコード入力 16094+0 レコード出力 16094 bytes (16 kB, 16 KiB) copied, 0.0448263 s, 359 kB/s $ unzip output.zip Archive: output.zip inflating: flag.png
flag: flag{AlWaYs_cH3cK_y0ur_sTuFF}
色々キソを見直せるCTFだった
Find My Pass - HackTM CTF 2020 Forensic writeup
引き続きHackTM2020 Forensics Writeupをお届け。
前回記事
zarat.hatenablog.com
Find My Pass
問題文
I managed to forget my password for my KeePass Database but luckily I had it still open and managed to get a dump of the system's memory. Can you please help me recover my password?
Author: Legacy
https://mega.nz/#!IdUVwY6I!uJWGZ932xab44H4EJ-zVAqu6_UWNJcCVA4_PPXdqCyc
https://drive.google.com/open?id=1hUlGqJZYgbWaEu7w0JnPMqgYdFr8qVJe
password: eD99mLkU
リンクがいつまで生きているか分からない。
まず、与えられたファイル「HackTM.zip」でzipファイルだと思うので解凍する。
$ unzip HackTM.zip Archive: HackTM.zip skipping: HackTM.vmem need PK compat. v5.1 (can do v4.6)
何故か解凍できなかった。zipファイルのフォーマット確認して直すところから始まるのかぁと思ったが、調べてみるとzipのフォーマットにバージョンがあって、unzipでサポート外のバージョンもあるらしい。
unzip で "need PK compat. v5.1 (can do v4.5)" と言われて解凍できない件 - CUBE SUGAR CONTAINER
ならば7zipを使えばいい。
$ 7za x HackTM.zip 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=ja_JP.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz (806E9),ASM,AES-NI) Scanning the drive for archives: 1 file, 374180992 bytes (357 MiB) Extracting archive: HackTM.zip -- Path = HackTM.zip Type = zip Physical Size = 374180992 Enter password (will not be echoed): Everything is Ok Size: 2147483648 Compressed: 374180992
解凍して出てきたのはメモリダンプファイルなので、volatilityで解析していく。
$ volatility -f HackTM.vmem imageinfo Volatility Foundation Volatility Framework 2.6 INFO : volatility.debug : Determining profile based on KDBG search... Suggested Profile(s) : Win7SP1x86_23418, Win7SP0x86, Win7SP1x86_24000, Win7SP1x86 AS Layer1 : IA32PagedMemoryPae (Kernel AS) AS Layer2 : FileAddressSpace (/root/CTF/HackTMCTF2020/Find_Mypassword/writeup/HackTM.vmem) PAE type : PAE DTB : 0x185000L KDBG : 0x82b7cb78L Number of Processors : 2 Image Type (Service Pack) : 1 KPCR for CPU 0 : 0x80b96000L KPCR for CPU 1 : 0x807ca000L KUSER_SHARED_DATA : 0xffdf0000L Image date and time : 2019-11-11 20:50:09 UTC+0000 Image local date and time : 2019-11-11 12:50:09 -0800
とりあえず、pstreeを見る。
$ volatility --profile=Win7SP1x86_23418 -f HackTM.vmem pstree Volatility Foundation Volatility Framework 2.6 Name Pid PPid Thds Hnds Time -------------------------------------------------- ------ ------ ------ ------ ---- 0x85fff1e0:wininit.exe 432 360 7 92 2019-11-11 20:49:22 UTC+0000 . 0x86513a70:lsm.exe 512 432 12 166 2019-11-11 20:49:22 UTC+0000 . 0x86438c00:services.exe 484 432 25 270 2019-11-11 20:49:22 UTC+0000 .. 0x864e8030:dllhost.exe 1820 484 21 205 2019-11-11 20:49:26 UTC+0000 .. 0x8670f030:svchost.exe 876 484 36 587 2019-11-11 20:49:23 UTC+0000 ... 0x86b3ad20:dwm.exe 1956 876 5 77 2019-11-11 20:49:25 UTC+0000 .. 0x86abf1a0:vmtoolsd.exe 1676 484 11 199 2019-11-11 20:49:25 UTC+0000 ... 0x86a8f030:cmd.exe 3372 1676 0 ------ 2019-11-11 20:50:09 UTC+0000 .... 0x86611870:ipconfig.exe 3472 3372 0 ------ 2019-11-11 20:50:09 UTC+0000 .. 0x86606030:svchost.exe 664 484 16 379 2019-11-11 20:49:23 UTC+0000 ... 0x86dccc08:WmiPrvSE.exe 3228 664 14 330 2019-11-11 20:49:34 UTC+0000 ... 0x85ee9a38:WmiPrvSE.exe 1748 664 9 145 2019-11-11 20:49:26 UTC+0000 ... 0x85861678:mobsync.exe 2260 664 8 163 2019-11-11 20:49:55 UTC+0000 .. 0x86bc6978:svchost.exe 388 484 7 97 2019-11-11 20:49:26 UTC+0000 .. 0x86a4ed20:VGAuthService. 1600 484 4 87 2019-11-11 20:49:25 UTC+0000 .. 0x8673ea38:svchost.exe 928 484 34 804 2019-11-11 20:49:23 UTC+0000 .. 0x867b1aa0:svchost.exe 1064 484 7 124 2019-11-11 20:49:23 UTC+0000 .. 0x869f87d8:spoolsv.exe 1308 484 16 300 2019-11-11 20:49:24 UTC+0000 .. 0x866d5d20:svchost.exe 812 484 27 577 2019-11-11 20:49:23 UTC+0000 ... 0x86763d20:audiodg.exe 1024 812 6 133 2019-11-11 20:49:23 UTC+0000 .. 0x86c47030:msdtc.exe 2292 484 15 160 2019-11-11 20:49:27 UTC+0000 .. 0x86a58360:svchost.exe 1468 484 34 352 2019-11-11 20:49:24 UTC+0000 .. 0x86a0cac0:svchost.exe 1344 484 24 338 2019-11-11 20:49:24 UTC+0000 .. 0x86869030:svchost.exe 1184 484 23 437 2019-11-11 20:49:23 UTC+0000 .. 0x8672f7f8:svchost.exe 968 484 50 860 2019-11-11 20:49:23 UTC+0000 .. 0x86caf6f8:SearchIndexer. 2636 484 14 612 2019-11-11 20:49:32 UTC+0000 ... 0x86d1fd20:SearchProtocol 2904 2636 7 265 2019-11-11 20:49:33 UTC+0000 ... 0x86d4d030:SearchFilterHo 2928 2636 5 89 2019-11-11 20:49:33 UTC+0000 .. 0x86c77030:VSSVC.exe 2428 484 7 125 2019-11-11 20:49:27 UTC+0000 .. 0x86da3030:svchost.exe 3076 484 11 360 2019-11-11 20:49:33 UTC+0000 .. 0x86a8cc38:taskhost.exe 1580 484 11 223 2019-11-11 20:49:25 UTC+0000 .. 0x860e3030:dllhost.exe 2108 484 18 216 2019-11-11 20:49:26 UTC+0000 .. 0x86661ad0:svchost.exe 748 484 12 337 2019-11-11 20:49:23 UTC+0000 .. 0x86cf7030:wmpnetwk.exe 2728 484 20 473 2019-11-11 20:49:32 UTC+0000 .. 0x86e844f0:WmiApSrv.exe 3716 484 7 122 2019-11-11 20:49:47 UTC+0000 . 0x864b4d20:lsass.exe 504 432 12 811 2019-11-11 20:49:22 UTC+0000 0x863c5d20:csrss.exe 380 360 9 632 2019-11-11 20:49:22 UTC+0000 . 0x86ec7588:conhost.exe 2520 380 0 30 2019-11-11 20:50:09 UTC+0000 0x84a41800:System 4 0 97 410 2019-11-11 20:49:19 UTC+0000 . 0x8625aa30:smss.exe 280 4 5 30 2019-11-11 20:49:19 UTC+0000 0x86b468c0:explorer.exe 1988 1908 33 727 2019-11-11 20:49:25 UTC+0000 . 0x86ae4400:vmtoolsd.exe 1428 1988 10 217 2019-11-11 20:49:26 UTC+0000 . 0x86e1b810:KeePass.exe 3620 1988 10 251 2019-11-11 20:49:46 UTC+0000 . 0x86ae4710:vm3dservice.ex 1396 1988 5 43 2019-11-11 20:49:26 UTC+0000 0x86556030:winlogon.exe 540 424 6 127 2019-11-11 20:49:22 UTC+0000 0x85fffd20:csrss.exe 440 424 10 220 2019-11-11 20:49:22 UTC+0000
ここで気になったのは「Keepass.exe」
今回の問題文からKeepassのデータベースを使って何かするような気がする。ここで、「Keepass.exe」とは何か参考資料をどぞ。
KeePassツールでパスワードを安全・確実に管理する − @IT
次に「Keepass.exe」がどうやって使われたか見たいのでcmdlineでチェック
$ volatility --profile=Win7SP1x86_23418 -f HackTM.vmem cmdline | grep KeePass.exe Volatility Foundation Volatility Framework 2.6 KeePass.exe pid: 3620 Command line : "C:\Program Files\KeePass Password Safe 2\KeePass.exe" "C:\Users\HackTM\Desktop\Database.kdbx"
どうやら、「Database.kdbx」をデータベースファイルとして利用しているらしい。なので、「Database.kdbx」を取り出せるか試す。
$ volatility --profile=Win7SP1x86_23418 -f HackTM.vmem filescan | grep Database.kdbx Volatility Foundation Volatility Framework 2.6 0x000000007da1a248 2 0 RW-rw- \Device\HarddiskVolume2\Users\HackTM\AppData\Roaming\Microsoft\Windows\Recent\Database.kdbx.lnk 0x000000007df37c88 2 0 R--r-- \Device\HarddiskVolume2\Users\HackTM\Desktop\Database.kdbx $ volatility --profile=Win7SP1x86_23418 -f HackTM.vmem dumpfiles -Q 0x000000007df37c88 -D ./ Volatility Foundation Volatility Framework 2.6 DataSectionObject 0x7df37c88 None \Device\HarddiskVolume2\Users\HackTM\Desktop\Database.kdbx $ ls HackTM.vmem file.None.0x86551160.dat $ mv file.None.0x86551160.dat Database.kdbx $ file Database.kdbx Database.kdbx: Keepass password database 2.x KDBX
「Database.kdbx.lnk」はショートカットファイルなので無視。「Database.kdbx」を取り出すことができた。
ここで、このデータベースをチェックするには「master password」が必要である。次はこの「master password」の捜索をする。
どこにあるのかよく分からなかったので、とにかく色々volatilityコマンドを試したところclipboardに何らかの文字列を見つけた。
$ volatility --profile=Win7SP1x86_23418 -f HackTM.vmem clipboard -v Volatility Foundation Volatility Framework 2.6 Session WindowStation Format Handle Object Data ---------- ------------- ------------------ ---------- ---------- -------------------------------------------------- 1 WinSta0 0xc009L 0x7017b 0xfe9a05a8 0xfe9a05b4 1c 00 02 00 .... 1 WinSta0 CF_TEXT 0xd ---------- 1 WinSta0 0x2000L 0x0 ---------- 1 WinSta0 CF_TEXT 0x2000 ---------- 1 WinSta0 0xd0095L 0x0 ---------- 1 WinSta0 CF_TEXT 0x1 ---------- 1 ------------- ------------------ 0xe00cb 0xffbb46b0 0xffbb46bc 64 00 6d 00 56 00 5a 00 51 00 6d 00 64 00 7a 00 d.m.V.Z.Q.m.d.z. 0xffbb46cc 4f 00 6c 00 55 00 72 00 63 00 45 00 42 00 6c 00 O.l.U.r.c.E.B.l. 0xffbb46dc 52 00 6a 00 38 00 37 00 64 00 48 00 51 00 33 00 R.j.8.7.d.H.Q.3. 0xffbb46ec 55 00 53 00 56 00 42 00 49 00 6e 00 00 00 U.S.V.B.I.n... 1 ------------- ------------------ 0xd0095 0xfddf5300 0xfddf530c 09 04 00 00 .... 1 ------------- ------------------ 0xb0137 0xfd4b47b0 0xfd4b47bc 00 00 00 00 78 00 00 00 01 00 00 00 01 00 00 00 ....x........... 0xfd4b47cc 00 00 00 00 00 00 00 00 0d 00 37 71 00 00 00 00 ..........7q.... 0xfd4b47dc 01 00 00 00 ff ff ff ff 01 00 00 00 01 00 00 00 ................ 0xfd4b47ec 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xfd4b47fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xfd4b480c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xfd4b481c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xfd4b482c 00 00 00 00 00 00 00 00 ........
なんとなく、これがパスワードのような気がしなくもない。
$ strings HackTM.vmem | grep -20 dmVZQ (snip) %XPOIo OOIo LOPI "F?N> %% N W;>- !#7>" 444K91/ O8!YHn 40.&`? 40.&0 pA)0 1J_'" ];NS+ (&-.HTA a,+-$ #"#6 vspscc [~ZV copypaste.transport dmVZQmdzOlUrcEBlRj87dHQ3USVBIn or.lnk ons%29.lnk p~ZV ~ZV mpleSock: Couldn't bind on source port 1023, error 10013, An attempt was made to access a socket in a way forbidden by its access permissions powershell/windows%20powershell.lnk". lnk". .~ZV ~ZVo IPlatformGetExecInfoHash: Getting exec info hash for URL "file:///c:/programdata/microsoft/windows/start%20menu/programs/accessories/windows%20powershell/windows%20powershell%20ise.lnk". IPlatformGetExecInfoHash: Getting exec info hash for URL "file:///c:/programdata/microsoft/windows/start%20menu/programs/accessories/windows%20powershell/windows%20powershell%20ise.lnk". KEEPAS~1 KeePass.exe /C:\ PROGRA~1 KEEPAS~1 KeePass.exe /C:\ PROGRA~1 KEEPAS~1
他にも2回ほど使用しているようだが、「Keepass.exe」でも使用しているように思える。ということでこれが「master password」だと仮定して進めていく。
次に、データベースを開くのだが「keepass2」が必要なのでインストールの参考にしたリンクを貼っておく。
Linux Mint 18: パスワード一元管理ツール「KeePass2」の使い方 | 221B Baker Street
インストールが完了したならばデータベースを開いてみる。
$ keepass2 Database.kdbx
これで、GUIが出てくるので「master password」だと思われる「dmVZQmdzOlUrcEBlRj87dHQ3USVBIn」を入力して「OK」を押すとデータベースが確認できる。 このようにデータベースを開くと、「Jason」のところにAttachmentがあるので、右クリックで「Save Attached File(s) To」を選択してファイルを抽出する。抽出したファイルを確認する。
$ file nothinghere.7z nothinghere.7z: 7-zip archive data, version 0.4
取り出した7zファイルはパスワードが必要だが、先ほど「dmVZQmdzOlUrcEBlRj87dHQ3USVBIn」は何回か使い回されているのを確認したので、7zにも使用してみる。
$ 7za x nothinghere.7z 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=ja_JP.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz (806E9),ASM,AES-NI) Scanning the drive for archives: 1 file, 234 bytes (1 KiB) Extracting archive: nothinghere.7z -- Path = nothinghere.7z Type = 7z Physical Size = 234 Headers Size = 154 Method = LZMA2:12 7zAES Solid = - Blocks = 1 Enter password (will not be echoed): Everything is Ok Size: 72 Compressed: 234 $ ls Database.kdbx HackTM.vmem nothinghere.7z nothinghere.txt $ cat nothinghere.txt HackTM{d14c02244b17f4f9dfc0f71ce7ab10e276a5880a05fca64d39a716bab92cda90}
flag: HackTM{d14c02244b17f4f9dfc0f71ce7ab10e276a5880a05fca64d39a716bab92cda90}
教訓
暗号化しても、メモリダンプ取っちゃえば関係ねぇ。
他の人のwriteupを読んでみて
人によってはkdbxファイルの仕組みをしっかりと理解した上で、Keepassデータベースがロードされているところを探しパスワードをを発見するなどもありました。Keepassデータベースのロード部分から、「master password」やファイル名を探し、実体を「KeePass」プロセスのメモリダンプからカービングすることもあるかもしれないので色々と資料を残しておきます。
kdbxに関する資料
Keepass file format explained · GitHub
KDBX v2 File Format · Stoom/KeePass Wiki · GitHub
他のwriteupと過去のKeePass問
CTFtime.org / HackTM CTF Quals 2020 / Find My Pass / Writeup