Tôi mới bắt đầu tìm hiểu về Forensic (Computer Forensic – Digital Forensic) được khoảng tầm hơn 1 tháng trở lại đây. Trước đây thì tôi chỉ tập trung hết vào RE. Đọc code và debug nhiều cũng oải lắm chứ, nhưng biết sao được, vì đam mê nên cứ làm riết thôi. Mãi sau tôi mới lân la sang vọc vạch 1 chút Forensic này, trước là để thỏa mãn trí tò mò, sau là vì sẽ rất cần thiết cho công việc của tôi trong tương lai (có lẽ là như vậy J ).
Tình cờ bên WhiteHat có tổ chứ WhiteHat Contest 8 để cho các đôi CTF cùng nhau tham dự, thi đấu và giành giải. Cái giải cũng to to, nghe đâu giải nhất được những 20 triệu. Nghe cũng hấp dẫn quá chứ, nhưng tôi tham gia không phải vì giải thưởng, mà là để kiểm tra xem trong thời gian qua mình đã thu lượm được những cái gì. Và rất may là kết quả không đến nỗi tệ, với một forensic newbie như tôi. Thế nên tôi viết cái bài này để đánh dấu lại kết quả đầu tiên tôi gặt hái được. Không là cái gì quá nổi bật, nhưng cũng khiến tôi cảm thấy vui vui J. Newbie mà, cứ làm được là sướng.
Trong bài này tôi sẽ không tập trung vào việc tìm flag một cách nhanh nhất, mà tôi sẽ kéo dài ra để nói về quá trình phân tích, và sẽ cố gắng viết sao cho càng đầy đủ càng tốt, để cho những bạn mới học Forensic như tôi có một cái nhìn dễ dàng hơn về cách mà tôi đã làm. Thế nên, cách làm của tôi sẽ không phải là cách tôi ưu nhất. Tôi gần như làm thủ công mọi bước để có thể moi ra thông tin.
OK, nói thế để rồi, chúng ta sẽ cần một vài thứ sau để thực hiện:
- 1 Linux Distro: Cái này thì không quan trọng lắm, nhưng tôi hay dùng Linux vì có shell/terminal quá tiện.
- WireShark: Để xem và phân tích packet
- Hex Editor: Để làm vài thứ hay ho, các bạn sẽ thấy trong bài viết nay. Ở đây tôi dùng 010 Editor
- Text Editor: Ghi chép lặt vặt. Nano cũng được
Đề bài cho là 1 file zip, bên trong có 2 file dump1 và dump2 (các bạn có thể tải về tại đây). Như một thói quen, tôi dùng ngay lệnh “file” trong Linux để xem xem 2 file này là gì:, bonus thêm luôn lệnh “ls –l” để kiểm tra thuộc tính file:
[levis@Levis-ARCH tmp]$ file dump1 dump2 dump1: tcpdump capture file (little-endian) - version 2.4, capture length 65535) dump2: tcpdump capture file (little-endian) - version 2.4, capture length 65535) [levis@Levis-ARCH tmp]$ ls -l dump1 dump2 -rwxrwxrwx 1 levis levis 3077703 Jan 13 14:47 dump1 -rwxrwxrwx 1 levis levis 1350 Jan 13 14:55 dump2
OK, cả 2 file đều là file packet capture. File dump1 có dung lượng lớn hơn cho nên sẽ phân tích file đó trước. Đổi tên cả 2 file thành dump1.pcap và dump2.pcap. Lại quen tay với RE, tôi lại dùng tiếp lệnh strings để xem trong file dump1.pcap có cái gì đọc được không. Hên xui mà, biết đâu lại có manh mối gì đó. Lệnh: strings dump1.pcap > dump1.txt. Thật may mắn là trong file dump1.txt chứa các string được extract ra từ file djmp1.pcap, tôi tìm thấy dòng này:
Có 1 file secret.txt gì đó nằm trong đống packet được capture. Tên nghe nhạy cảm quá, tôi cần phải tìm xem nó lằm ở packet nào trong đống packet kia. Thê là search trong Wireshark, search string ở các packet bytes. Và tôi tìm được packet này:
ở Packet 2636 là 1 USB Protocol từ thiết bị 3.1 vào host, kích thước packet là 4123 bytes, và ở phần Info ghi là URB_BULK. Đây là Bulk data transfer protocol của USB, URB là viết tắt của USB Request Block (Google với từ khóa (URB Protocol). Bây giờ tôi sẽ save lại packet này ra 1 file mới và tiến hành phân tích tiếp, chỉ riêng packet này thôi. Save lại và mở bằng 1 hex editor, tìm đến đoạn chứa string “secret.txt”. Và tôi phát hiện ra đây là 1 flie zip vì có header PK rất quen thuộc (Wikipeia về Zip File Format). Và tên của file zip này là secret.zip. Vậy tôi cần làm là tìm cách extract file zip này ra. Dựa vào những thông tin tôi đọc được trên wikipedia thì file zip có header là 0x04034B50, như trong hình dưới đây là tại ofset 0x0520. Như vậy là ta đã xác định được phần đầu của file zip, việc còn lại là xác định EOF. Cũng theo trong wikipedia, phàn footer của file zip bắt đầu từ “PK” cuối cùng (0x06054B50) và kéo dài thêm 20 byte nữa để chứa các thông tin cần thiết. Như trong hình này thì EOF sẽ là ở offset 0x060C.
Vậy là ta cần phải copy các byte từ 0x0520 đến 0x060C và save lại 1 file mới, với tên gốc là secret.zip, như thế này:
Sau đó dùng lệnh unzip để thử unzip ra xem có gì:
[levis@Levis-ARCH tmp]$ unzip secret.zip Archive: secret.zip [secret.zip] secret.txt password: password incorrect--reenter: password incorrect--reenter: skipping: secret.txt incorrect password [levis@Levis-ARCH tmp]$
File này có đặt password, tôi thử nhập bừa password vào và bị fail sau 3 lần thử. Bên trong file có 1 file secret.txt rất khả nghi. Vậy làm thế nào để mở được file? Tôi đã thử dùng John the Ripper để crack password, và thực tế là nghĩ rằng việc crack này chỉ là lấy lệ, vì tôi biết trước là sẽ không crack được ngay trong lúc này. Bắt đầu cảm thấy bế tắc, mọi việc đang rất suôn sẻ từ đầu cho đến lúc này, thì lại lòi ra cái việc bắt nhập password. Tôi đã ném bài đó qua một bên, để cho thoải mái đầu óc…
Trên đường từ công ty về nhà, tôi lại nghĩ là còn 1 file mình chưa analysis, là file dump2, vì file size nó quá nhỏ và ít packet, lúc đầu tôi mở trong wireshack thì thấy 1 loạt các packet URB_INTERRUPT, khoảng tầm 2 chục cái packet như thế, mà nhìn thấy chữ INTERRUPT là chán rồi, nên ném nó qua 1 bên để tìm cách kéo file zip ra, và chạy John :v . Mãi đến lúc đó tôi mới nghĩ là có thể password nằm ở đây, trong các byte của hai mươi mấy cái packet kia. Về đến nhà, tôi bật lap rên rồi mở lại file dump2.pcap để cố gắng tìm kiếm xem có cái gì đọc được hay không, nhưng rồi thất vọng vì length của mỗi packet là quá ngắn, chỉ khoảng 35 byte.
Thế rồi tôi tập trung vào tìm hiểu về info của từng packet đó:
Trong Wireshark tôi thấy được là data được Transfer từ thiết bị 4.1 nào đó vào host, giao thức URB_INTERRUPT, và thời gian giữa các packet được transfer khá ngắn. Điều gì khiến packet được gửi nhanh như vậy? Và cái tôi đang cần là tìm mật khẩu cho file zip. Tự nhiên trong 1 giây tỏa sáng, tôi nghĩ rằng đây là các packet được transfer khi người dùng gõ phím trên 1 usb keyboard. Ý tưởng đã có, thế là tôi lao vào tìm một số thông tin về URB_INTERRUPT và USB Keyboard protocol. Về nhà thì không có mạng, thế là căng mắt ra tìm google qua cái màn hình điện thoại bé tí. Tình cờ mò được cái writeup này: http://blog.lse.epita.fr/articles/32-csaw-ctf-2012-donglepcap-net300.html khiến cho tôi càng tin vào giả thuyết của mình hơn. Trong bài viết có 1 link cho download 1 table (bằng tiếng Nga, bạn có thể tìm thấy file pdf đó trong file nén chứa đề bài tôi gửi link ở phía trên) ghi rõ các keycode. Thế là ok rồi, Tôi cần tìm xem keycode nằm ở đâu trong packet, bỏ qua đoạn header của packet, tôi thấy được có byte tại vị trí 0x2C là thay đổi, và byte này nằm trong phần leftover data.
Vậy đây là keycode cần tìm, đối chiếu keycode này với table download về lúc trước (bỏ qua keycode 00), từ đầu cho đến hết 26 packet (bỏ qua 13 packet 00, còn lại 13 packet chứa keycode, cuối cùng có được 1 strings rất quen thuộc: just in time. Đây có thể là password để unzip file chăng? Nghi lắm, thử cái xem nào:
[levis@Levis-ARCH tmp]$ unzip secret.zip
Archive: secret.zip
[secret.zip] secret.txt password:
inflating: secret.txt
[levis@Levis-ARCH tmp]$ cat secret.txt
WhiteHat{b02f0e7bed6ad69dd0ab74c1bf44dfc61cdaa74b}
WOW! Quá ngon, file đã được unzip, và tôi tiện tay xem luôn nội dung của file secret.txt. Trong đó có thứ tôi cần tìm: flag. Nhấc điện thoại, gọi cho 1 người bạn trong team kêu họ dùng pass đó để unzip, lầy flag và submit (không có mạng khổ thế đấy).
Cuối cùng thì cũng thành công, bài for đầu tiên làm được, kể cũng vui đó chứ. Team thì rank lèo tèo thôi, tại ít người involve, giống lúc đầu tôi nói đó, làm chơi chơi cho vui ấy mà J.
Levis's Little Blog about Reverse Code Engineering (RCE) 