Month: March 2020

---

MITRE’s ATT&CK là một framework về kỹ thuật-chiến thuật-chiến lược tấn công của adversary (kẻ tấn công) dựa vào những tình huống thực tế.

MITRE’s ATT&CK framework provide names, descriptions, and links to examples of the high-level tactics adversaries’ use during an operation, as well as the techniques the adversary uses to achieve them. For example, the ATT&CK framework has a tactic called ‘Launch’ that refers to an adversary attempting to penetrate a network. One technique associated with this tactic is called “Spear phishing messages with malicious attachments”, which describes how the adversary would launch an attack on the network. This provides common definitions and understandings of how a specific goal is accomplished by attackers.

Trong quá trình Threat Hunting đầy gian khổ, chúng tôi nhận thấy ATT&CK này rất hiệu quả trong việc tổng hợp và đưa ra một cái nhìn có tính tổng quan về các surface có thể bị tấn công để áp dụng . Chúng ta sẽ bắt đầu kỹ thuật đầu tiên mà các adversary sử dụng cho mục đích Persistence, đó là lợi dụng các tính năng về Accessibility features trong Windows.

---

Accessibility Features

Nội dung chính:

• Khái niệm
• Các kỹ thuật hiện có
• Các case study
• Các cách phát hiện và phòng chống

Khái niệm

• Adversary lợi dụng tính năng accessibility (trợ năng) có sẵn trên Windows để khởi tạo 1 tổ hợp phím trước khi người dùng đăng nhập (ví dụ khi người dùng ở màn hình đăng nhập và nhấn 5 lần phím SHIFT) để có thể thực hiện lệnhCMD hoặc bất kỳ file thực thi nào mà không cần phải đăng nhập.
• Trên thực tế, kỹ thuật tấn công này thường được sử dụng trên các máy tính đang bật Remote Desktop Protocol (RDP). Các adversary sử dụng RDP như một kênh để thực hiện tấn công.

Kỹ thuật thực hiện

Có 2 cách phổ biến để thực hiện kỹ thuật này:

• Thay thế file thực thi của accessibility feature(ví dụ như C:\Windows\System32\sethc.exe) bằng file thực thi khác, thường là cmd.exe hoặc explorer.exe để phục vụ các bước tiếp theo của adversary.
• Thay đổi Registry để chạy một debugger mỗi khi C:\Windows\System32\sethc.exe được thực thi. Đăng ký debugger đó là cmd.exe hoặc bất kỳ file thực thi nào. Ví dụ với cmd.exe được sử dụng như một debugger.

Các case study

Attack	Thông tin về nhóm	Kỹ thuật
APT29	Được cho là của chính phủ Nga, bắt đầu hoạt động từ khoảng 2008	Thay thế Sticky Keys binary C:\Windows\System32\sethc.exe bằng cmd.exe
APT3	Có trụ sở tại Trung Quốc. Trong bài viết được đề cập, nhóm này còn được gọi là UPS	Tham khảo thêm bài viết sau
Axiom	Có liên quan đến chính phủ Trung Quốc. Vận hành chiến dịch Operation SMN, sử dụng mã độc Winnti	Cơ bản kỹ thuật cũng giống các nhóm khác. Tham khảo thêm bài viết sau
Deep Panda	Nhóm TQ từng tấn công vào công ty Anthem	Sử dụng kỹ thuật sticky-keys để bypass RDP login

Các cách phát hiện và phòng chống

• Do kỹ thuật này thường phải sử dụng kết hợp với RDP, ta phải đảm bảo tính năng Network Level Authentication đang enable để các phiên RDP đều phải được authen. Hiện tại tính năng này là mặc định trên các phiên bản từ Vista trở lên. Đối với các mạng nội bộ (của công ty hoặc gia đình, tổ chức,…), có thể sử dụng tính năng Remote Desktop Gateway để quản lý các kết nối RDP. Tham khảo thêm cách cấu hình Remote Desktop Gateway trên Windows Server 2008.
• Sử dụng whitelist tool như AppLocker hoặc Software Restriction Policies để ngăn chặn việc load các malicious file.
• Theo dõi Registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

Đây là trường hợp một cuộc tấn công sử dụng Accessibility Features được phát hiện.

Tham khảo

Technique: Accessibility Features – MITRE ATT&CK™
bash_profile and .bashrc Accessibility Features Account Manipulation AppCert DLLs AppInit DLLs Application Shimming…attack.mitre.org

…

Gần đây, Zepto có nhận được một số mẫu mã độc được cho rằng có liên quan tới các cuộc tấn công APT vào hệ thống ngân hàng của Việt Nam mà báo chí có đưa tin gần đây [1]. Trong đó có đề cập đến 2 mẫu mã độc được cho là sử dụng trong chiến dịch trên.

Liệu 2 mẫu trên thật sự làm gì và có gì liên quan đến nhau? Bức tranh toàn cảnh của chiến dịch này là gì? Câu trả lời sẽ dần được hé lộ trong series bài viết phân tích về cuộc tấn công APT này.

Phân tích mẫu 1— syschk.ps1

Để ngắn gọn, đây là 1 script Powershell với mục đích inject 1 đoạn code DLL vào process Explorer. Đoạn code DLL này tạo ra 3 thread trong DLLMain có tác vụ lần lượt như sau:

• Keylog: gồm lưu lại phím và Clipboard
• Screenshot: lưu lại ảnh màn hình
• Hàm Sleep: Đưa 2 thread trên vào trạng thái ngủ

Cụ thể khi mẫu mã độc tìm được process Explorer, nó sẽ tạo ra 1 mẫu Powershell khác ở thư mục %temp%tmp\XXXX.ps1 với XXXX là [0–9][A-F].

Sau đó mẫu XXXX.ps1 được thực thi bằng lệnh sau:

Start-Process powershell.exe -PassThru -WindowStyle Hidden -ArgumentList -ep bypass -file C:\Windows\Temp\tmp\XXXX.ps1

Nội dung của file tmp trên là sử dụng một kỹ thuật Invoke-ReflectivePEInjection để inject một file DLL từ bộ nhớ (RAM) vào 1 process đang chạy [2], dù hàm này bị thay đổi khá nhiều tuy nhiên chúng cùng chung 1 mục đích như đã nói.

FYI: Mẫu DLL chính là $PEBytes

Tiếp đó ta load file DLL vào IDA để phân tích kỹ hơn các tính năng theo dõi nạn nhân.

Phân tích mẫu DLL

Nhảy vào entry point, ta thấy có 3 thread riêng biệt

Cần chú ý thư mục %temp%GoogleChrome, vì nơi đây sẽ chứa dữ liệu mà hàm Screenshot và Keylog ghi lại từ User.

Phân tích Thread 1 — Keylog

Ta tóm gọn T1 thực thi lần lượt như sau:

• Lấy Title của “Cửa sổ” hiện tại mà User đang sử dụng
• Hàm Keylog (trùng tên với thread)
• Hàm lấy Clipboard
• Lưu ra file

FYI: Tại sao một mã độc APT tấn công vào ngân hàng VN lại không hỗ trợ log lại tiếng Việt hay Unicode. Dù log tiếng Việt nằm ở 1 phạm trù khác với các ngôn ngữ Unicode.

Ngoài ra project này [3] đề cập chi tiết cách log được kí tự Unicode.

Sau đó 2 loại log phím trên lưu dữ liệu tại %temp%chromeupdater_pk.

Demo

Phân tích Thread 2 — Screenshot

FYI: Nội dung hàm takeScreenshot rất giống link này[4]

Phân tích Thread 3 — Hàm Sleep
Với Thread này, ta thấy nó đang cố gắng điều khiển 1 biến boolean shouldSleep dựa vào kiểm tra file C:\ProgramData\2.dat có tồn tại hay không.

Biến shouldSleep cũngđược sử dụng ở 2 thread còn lại (hình dưới). Nói ngắn gọn, thread số 3 này đưa 2 thread còn lại vào trạng thái Sleep. Đây là 1 cách cơ bản để đưa mã độc vào trạng thái Inactive để bypass các AV và sandbox online đang scan các hành vi độc hại.

Kết thúc của thread này là hàm deleteAllInLogFolder và WINAPI RemoveDirectoryA.

Nhiệm vụ của 2 hàm này để xóa toàn bộ các thư mục lưu log của thread Keylog và Screenshot, nói đơn giản là nó đang xóa các dấu vết của chính nó.

Nhận xét

Mẫu Powershell và DLL đều đi vay mượn code, và không có gì đặc biệt về mặt kỹ thuật.

Ngoài ra ta chắc chắn mẫu này sẽ cần đi kèm với các mẫu mã độc khác để hoạt động được, ví dụ như gửi thông tin thu thập được đến C&C server hay ra lệnh Sleep (chỉnh sửa file 2.dat).

Phân tích mẫu 2 — hs.exe

Load mã độc vào IDA, mở tab Import ta có

Nhìn vào số lượng các hàm được sử dụng, ví dụ như hàm connect được gọi ở 4 nơi. Ta đoán chương trình này sử dụng Winsock (WS2_32.dll) để thiết lập kết nối (connect), gửi (send) và nhận (recv) lệnh và dữ liệu.

Bắt đầu với hàm WinMain. Ở đây ta tách được 2 tác vụ rõ ràng như:

• Giải mã tham số đầu vào (ở đây là thông tin về C&C server)
• Tạo 1 thread để nhận lệnh của C&C server

FYI: Tham số đầu vào của mã độc này được truyền vào bởi một mẫu khác (giải thích ở cuối bài) như sau

hs.exe [địa chỉ bị encrypt của victim]

Đầu tiên, ta để ý tham số đầu vào đi qua hàm decrypt. Sau đó, ta có địa chỉ C&C cần kết nối tới.

Sau khi có địa chỉ C&C server, mẫu sẽ tạo 1 thread(main_thread) với mục đích nhận lệnh từ C&C server (xem hình tổng quan ở trên).

Mục đích chính của việc nhận lệnh này là forward các lệnh điều khiển từ C&C server đến máy đã bị lây nhiễm (địa chỉ của máy lây nhiễm lấy từ C&C server).

Sau đây ta chứng thực lại điều đó.

Trong main_thread này mã độc nhận một số lệnh tiếng Nga như dưới

Vì ở đây có 1 trường hợp thú vị về việc người phát triển mã độc cố gắng đánh lừa người phân tích bằng cách tạo sự sai lệch giữa tên và mục đích thực sự của 1 đoạn nhận lệnh (poluchit), nên ta sẽ đi phân tích tên câu lệnh, tên dịch và lệnh thực thi thực sự của mã độc.

FYI: Tất cả các câu lệnh ở đây đều được mã hóa khi cả gửi và nhận. Tuy nhiên các câu lệnh dưới đây đều dưới dạng không mã hóa để trực quan hơn.

Gửi lệnh “Nachalo”: Khởi tạo kết nối với C&C server. Cụ thể hình dưới là khởi tạo kết nối với C&C server 5 lần để nhận các lệnh tiếp theo (forwarder).

Nhận lệnh “Ustanavlivat”: Nhận địa chỉ của máy cần forward lệnh tới

Hình dưới giải thích khá rõ cách hoạt động. Bắt đầu với nhận dữ liệu từ C&C server, tuy nhiên chỉ lấy ra 4 byte đầu tiên để decrypt ra được kích cỡ của dữ liệu còn lại (gọi là A). Sau đó so sánh kích cỡ lấy được với kích cỡ của A. Nếu sai thì ngừng Session hiện tại, nếu đúng thì tiếp tục .

Nhận lệnh “Poluchit”: Gửi địa chỉ của máy bị lây nhiễm mã độc lên C&C server.

Đây có thể coi là bước xác thực sau quá trình nhận được IP cần forward tới.

Điểm thú vị ở đây nghĩa của từ “Poluchit” là nhận, trong khi mục đích thực sự của nó lại là gửi địa chỉ máy bị lây nhiễm lên C&C server.

Đây là 1 trong những điểm nghi ngờ mấu chốt giúp chúng tôi tiếp tục phân tích và tìm thêm những mẫu khác có liên quan tới một nhóm chuyên tấn công APT vào các ngân hàng ĐNÁ, Lazarus.

FYI: Có 1 bài phân tích [5] đối với 1 mẫu khá tương tự mẫu này(sample #5), tuy nhiên đây có vẻ là 1 chiến dịch khác của nhóm Lazarus. Vì vậy, chúng tôi sẽ viết phần 2 về việc phân tích chiến dịch có sử dụng mẫu Forwarder này.

Nhận lệnh “Pereslat”: Chuyển tiếp dữ liệu giữa C&C server và máy đã bị cài mã độc.

Khi nhận lệnh “derzhat” tiếp tục giữ kết nối. Còn lại, nếu nhận lệnh “vykhodit” thì sẽ thông báo cho C&C server và thực thi việc ngắt Session.

Dựa vào phân tích trên, ta thấy đây chỉ là 1 mẫu mã độc dùng để chuyển tiếp (forward) dữ liệu giữa C&C server và mã độc. Sự chuyển tiếp này rất có thể xảy ra trong mạng private của tổ chức bị tấn công, nghĩa là C&C server cũng nằm trong mạng của tổ chức, và cũng nhận lệnh thông qua mẫu Forwarder này.

Ngoài ra, mẫu thứ nhất (Powershell) đóng vai trò là 1 trong nhiều mẫu RAT được cài đặt vào Client.

Chưa dừng ở đó, dựa vào những điểm nghi ngờ nêu trong bài viết, chúng tôi cũng tìm được những thông tin, dẫn chứng về các chiến dịch tấn công vào ngân hàng Việt Nam có liên quan tới nhóm Lazarus (thông tin cụ thể ở phần 2).

Góc nhìn hiện tại

Hiện tại chúng tôi khá chắc chắn đây là mẫu mã độc được phân tán bởi nhóm Lazarus đến từ Triều Tiên. Với hồ sơ và các bài phân tích về nhóm này, đây là 1 nhóm được quản lý trực tiếp bởi Cục 121 của cơ quan tình báo Triều Tiên. Mục tiêu của nhóm này những năm gần đây là tấn công vào hệ thống tài chính của các nước ĐNÁ, đặc biệt là các ngân hàng. Đặc biệt là vụ suýt đánh cắp thành công 1 tỷ đô-la ở ngân hàng TW Bangladesh. Ngoài ra trong quá khứ nhóm này cũng đã từng thực hiện các cuộc tấn công APT vào ngân hàng Việt Nam.

FYI: Hiện tại C&C server vẫn đang hoạt động.

Tạm gác lại 2 con chuồn chuồn con, đáp án cho những câu hỏi chưa được giải đáp sẽ dần được hé lộ qua phần 2: Lộ diện.

Tham khảo

1. http://ictnews.vn/cntt/bao-mat/canh-bao-khan-ma-doc-dang-tan-cong-co-chu-dich-vao-ngan-hang-va-ha-tang-quan-trong-quoc-gia-170123.ict
2. https://clymb3r.wordpress.com/2013/04/06/reflective-dll-injection-with-powershell/
3. https://github.com/SherifEldeeb/UniLogger/blob/master/README.md
4. https://www.apriorit.com/dev-blog/193-multi-monitor-screenshot
5. https://baesystemsai.blogspot.com/2017/02/lazarus-false-flag-malware.html
6. https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/a-look-into-the-lazarus-groups-operations

@nl @floppydisk @bakhoang @tofu

—

Gần đây trong quá trình nghiệp vụ, chúng tôi nhận được 1 mẫu mã độc có đuôi SCR trong phần đính kèm ở mail của nạn nhân.

Qua phân tích, chúng tôi phát hiện mục đích chính của mẫu gốc (Techcombank…) là unpack và thực thi một mã độc RAT khá nổi tên là NanoCore.

Mẫu RAT này có tính năng ghi lại phím bấm trên bàn phím (Keylog), thực thi lệnh (Remote command), sử dụng giao diện đồ họa của máy nạn nhân (Remote desktop), …

Nhìn hình trên, ta thấy mẫu gốc NanoCore được ẩn mình 2 lớp. Tiếp ta sẽ cùng bóc tách mẫu này để hiểu sâu và tìm cách phòng chống.

Phân tích mẫu Wrapper

Sử dụng bất kỳ phần mềm PE viewer nào, ta đều nhận được đây là 1 file .NET

Trong trường hợp này ta sử dụng Detect It Easy

Với file .NET, ta sử dụng dnSpyđể view/debug code. Kết quả ta có là tên các namespace, class và method đều là tiếng ngoại quốc.

Chữ kiểu này làm giảm hiệu suất đọc hiểu của chúng ta. Ta sử dụng de4dot để deobfuscate (nếu có) mẫu này và có một kết quả dễ nhìn hơn.

Lướt qua nội dung code 1 lượt, ta thấy đây chính là 1 Wrapper với mục đích giải mã và thực thi một mẫu khác nằm trong Resource Directory.

Hàm giải mã ở đây là thực hiện phép XOR giữa 1 đoạn Assembly và 1 array byte cùng được lưu trong Resource Directory.

Cách hoạt động của mẫu này có thể đơn giản hóa như sau, bạn quan sát hình 4 để có cái nhìn cụ thể.

• Load 1 object từ Resource Directory
• Decrypt object (smethod_0)
• Tạo Assembly với object (smethod_3)
• Load EntryPoint của Assembly (smethod_1)
• Thực thi đoạn EntryPoint

Hiểu được cách hoạt động, ta xử lý và có được 1 mẫu từ bộ nhớ. Tạm đặt tên là Stub.

Phân tích mẫu Wrapper số 2

Tương tự như trên, ta load mẫu Stub này dnSpy. Tuy nhiên kết quả nhận được là hàm Main không có nội dung, và các hàm khác còn bị lỗi không decompile được.

Vì hàm Main không có nội dung, ta xem thử qua đoạn mã khởi tạo của class StubCode này. Một kĩ thuật thường thấy là giấu code trong static class constructor (.cctor) để giấu mã độc trước khi chạy EntryPoint thường thấy.

Thật vậy, có code ở đây. Dù tên của những hàm này đều bị obfuscate, dưới dạng Unicode không in được.

Dựa trên watermark của một số công cụ obfuscate tự động, ta biết rằng mẫu này sử dụng ConfuserEx v1.0.0 [1]

Note: Bước deobfuscate quá dài và không liên quan tới chủ đề, nên ta sẽ bỏ qua và mặc định rằng mẫu này đã được deobfuscate.

Sau khi phân tích mẫu đã được deobfuscate, ta nhận định đây là 1 Wrapper cho mẫu RAT (mục đích chính của kẻ tấn công).

Mẫu Wrapper số 2 này có rất nhiều tính năng, điều thú vị nó có thể được điều chỉnh thông qua Config của Resource Directory (lần nữa). Vì quá nhiều tính năng, ta sẽ chỉ phân tích những tính năng ta cần quan tâm liên quan tới dấu vết của mã độc (IOC).

Vì là Config, nên có thể bật/ tắt. Mẫu Stub có những tính năng sau được sử dụng:

• Decompress và thực thi mẫu RAT
• Khởi động cùng hệ thống thông qua Registry hoặc TaskScheduler
• Bypass AV (Avast)
• Cố gắng tắt các chức năng liên quan tới Security của Windows như Cmd, Task Manager và UAC

Ngoài ra, những tính năng bị tắt:

• Downloader
• Anti-Dump
• Anti-Sandbox
• Ẩn file với attribute là Hidden và System
• Và nhiều nữa

Ta sẽ phân tích tính năng đầu tiên: giải nén và thực thi mẫu RAT.

Để ngắn gọn, mẫu này sử dụng MainFile từ Resource Directory.

Cụ thể, mẫu này cho ta 2 lựa chọn giải nén là sử dụng thuật toán LZMA hoặc thuật toán phần mềm GZIP sử dụng.

Tuy nhiên Config cho 2 tính năng này đều bị tắt, nên mẫu RAT chính là MainFile trong Resource.

Tính năng thứ 2 là khả năng mã độc khởi chạy cùng hệ thống.

Đầu tiên, Stub tạo 1 bản sao có tên là <filename>. Sau đó, Stub dùng Reg để thực thi cmd với tham số là một file Update.txt, file này chứa nội dung thực thi mẫu mã độc <filename>.

Phân tích mẫu RAT

Sau khi chúng ta có được mẫu RAT, kéo thả vào de4dot phát hiện mẫu RAT bị obfuscate với Eazfuscator.NET v3.3

Dựa vào tên mẫu và chức năng các hàm, ta xác thực đây là mẫu NanoCore Client. Cách tốt nhất để thuyết trình về mã độc RAT chính là đứng trên góc nhìn của kẻ tấn công để xác thực lại các chức năng mà mã độc RAT cung cấp.

Điều này có nghĩa là chúng ta sẽ cài đặt NanoCore Server và kiểm tra những tính năng mà kẻ tấn công có thể thực hiện trên máy nạn nhân.

Có nhiều cách để thực hiện điều trên, cụ thể ở đây ta tạo 1 loopback adapter để lừa mã độc kết nối tới IP của ta. Sau đó đọc HDSD và “trải nghiệm” những tính năng của NanoCore Server.

FYI: NanoCore là sản phẩm được phát triển dưới công ty “Nimoru Software”. Trong NanoCore Server có mục feedback để bạn có thể nhận được sự trợ giúp từ nhà phát triển, và địa chỉ của feedback được gửi đi là “nimoru.com”. Và cha đẻ của mẫu mã độc này đã phải nhận án phạt 33 tháng, bạn có thể đọc thêm tại [2]

Với 1 mẫu RAT khá đầy đủ chức năng như NanoCore, Remote Desktop là tính năng phổ thông.

Tính năng này giúp kẻ tấn công dễ dàng thực thi các hành vi xấu trên máy nạn nhân một cách dễ dàng hơn, nhanh hơn và không cần có chủ đích.

Ngoài ra mẫu NanoCore còn có các tính năng sau :

• Quản trị file từ xa
• Thực thi lệnh từ xa (CMD)
• Remote Desktop
• Keylog
• Ghi âm
• Và nhiều nữa

Như nói ở trên, việc mã độc RAT này là phần mềm thương mại và UI của nó dễ dàng cho những kẻ tấn công phổ thông, nên những loại mã độc này thường được phát tán rất nhiều và không có chủ đích.

Điều xấu là chúng ta có khả năng cao sẽ trở thành nạn nhân, tuy nhiên điều tốt ở đây là những loại tấn công này thường sẽ đơn giản, việc sử dụng phần mềm diệt virus hay cẩn trọng với các email và đường link nguồn gốc không rõ ràng sẽ giúp bạn trên Internet hơn rất nhiều.

FYI: Ta có thể lấy được Config bao gồm địa chỉ C&C server của mã độc thông qua sử dụng script RatDecoders [3]

Ngoài ra hiện tại C&C server của mẫu RAT này vẫn còn hoạt động.

IP này đến từ Hàn Quốc. Ngoài ra, IP này cũng được cho rằng là NanoCore BotNet Server [4] và spam Email [5]. Cùng đó trên VirusTotal, ta thấy mẫu mã độc này đang trong giai đoạn phát tán.

Một lần nữa, các bạn nên cẩn trọng trong việc mở các email, các đường link có nguồn gốc không rõ ràng. Đồng thời, rà soát hệ thống với các dấu hiệu ở dưới (sẽ cập nhật thêm).

IOCs

Registry:

\\HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Update

IP & Domain:

160.202.163.240

Hash:

58B25347820B820F4FA46680CFF6BFC8 — TechcomBank_Dien_201883.scr

353F5EAACF70554CEB327D3578244177 — stub.exe

28C864D3F592B51AB646CEC8B1FF2CD7 — NanoCore Client.exe

References

1. https://github.com/yck1509/ConfuserEx/blob/master/Confuser.Core/ConfuserEngine.cs#L303
2. https://krebsonsecurity.com/wp-content/uploads/2017/04/W.D.Ark_._null_null_0.pdf
3. https://github.com/kevthehermit/RATDecoders/blob/master/StandAlone/NanoCore.py
4. https://www.spamhaus.org/sbl/query/SBL398403
5. https://www.spamhaus.org/sbl/query/SBL320946

@nl @floppydisk @tofu @bakhoang

---

TLDR;

02/01/2018 công ty bảo mật XYX ra mắt công cụkiểm tra email có bị rò rỉ thông tin. Tuy nhiên việc cài đặt Chrome Extension mở ra lỗ hổng cho phép attacker có thể tấn công XSS vào trang inbox.google.com. Từ đây attacker có thể chiếm đoạt tài khoản Gmail hay thực hiện các tình huống tấn công nguy hiểm khác.

Introduction

Tình cờ ngày tối qua được một người bạn chia sẻ bài blog công cụ kiểm tra email trong danh sách rò rỉ thông tin của công ty bảo mật XYX, cũng tò mò nên có vọc vạch thử bên trong nó có cái gì hay ho không :D. Trong bài viết có 2 app là app Android và Chrome Extension. Trong bài viết này mình sẽ kể lại quá trình vọc vạch cái extension.

Chrome Extension

Cài đặt Extension vào dùng thử :D.

Xem qua demo thấy cũng khá thú vị đó chứ, view thử source xem sao.

… Nhận ra bất ngờ đầu tiên:

Extension này sử dụng API từ trang thứ 3 haveibeenpwned.com, trong khi trong bài viết không hề đề cập đến việc này.

Mình sẽ không comment gì về vấn đề này, tiếp tục xem code để tìm sạn nào 😀

Có thể nói nôm na cách hoạt động của extension này như sau:

---

• Lấy danh sách toàn bộ Email trên trang inbox/gmail
• Kiểm tra địa chỉ email có tồn tại trong localStorage của trình duyệt, nếu tồn tại, tạo 1 cái InfoDiv kèm ảnh như dưới, nếu di chuột vào ảnh, sẽ show infoDiv ra.

• Nếu email chưa có trong localStorage, gửi request kèm địa chỉ email lên API https://haveibeenpwned.com/api/v2/breachedaccount/ và thực hiện như bước trên.

Có một vấn đề gặp phải ảnh hưởng đến độ tin cậy của kết quả cũng như ảnh hưởng việc tìm sạn đó là API Rate Limit của trang haveibeenpwned=))

---

Exploit

Câu hỏi đặt ra: Liệu mình có thể kiểm soát cái $email trong innerHTML kia không để làm cái mà ai cũng biết là cái đấy không?

Rất thú vị là tham số email đó mình có thể kiểm soát được bằng alias address.

Email gửi đi dạng nforma <nforma***@gmail.com>

-> Mục tiêu: nforma <nforma***+[inject_here]@gmail.com>

Đây là kết quả sau nhiều lần thử nghiệm

<“nforma***+<img src=x1 onerror=alert(document.domain)>[API][Email_X]”@gmail.com>

escape

<“nforma***+<img src=x1 onerror=alert(document.domain)>/../../../../../../../../api/v2/breachedaccount/[Email_X]”@gmail.com>

Final PoC

<“nforma***+<img src=x1 onerror=alert(document.domain)>/../../../../../../../../api/v2/breachedaccount/phenslei”@gmail.com

Tại sao lại là phenslei?

Proof of Concept

#1. Thử nghiệm trên mail.google.com

Có thể thấy kết quả FAIL do Gmail đã cấu hình CSP (Content Security Policy).

#2. Thử nghiệm trên inbox.google.com

Conclusion

Chrome extension mang đến nhiều tiện lợi cho người dùng nhưng bên cạnh đó cũng mang đến nhiều rủi ro. Chrome extension có thể thực thi JavaScript, thay đổi DOM,… ở bất kỳ trang web nào bạn ghé thăm, hay tận dụng các Chrome API để làm nhiều việc theo trí tưởng tượng của developer. Tuy nhiên developer với mục đích tốt cần cẩn thận hơn khi “vô tình” mở ra lỗ hổng nghiêm trọng đến chính người dùng của mình.

Timeline

Sáng 3/1: Phát hiện vulnerable

Trưa 3/1: Report XYX, XYX đã có biện pháp xử lý ngay

Chiều 3/1: Viết blog, chờ confirmed

Sáng 4/1: Publish

@bakhoang @floppydisk

Tuần trước tụi mình có cơ hội trên tay chiếc USB 2.0 8GB bảo mật có bằng sáng chế tại Việt Nam. Lúc đầu chỉ định xài thử, nhưng nghe quả giá hơn 800k thì vọc ngay xem nó có worth với cái giá trên hay không?

Giới thiệu

USB này được BQP cấp bằng sáng chế và vừa mới được thương mại hóa, trước đó đã sử dụng trong quân đội nhiều năm nên mình cũng không nghĩ kiếm chác được gì. Nhưng đời ai biết đâu chữ ngờ, một bạn trong nhóm mình (credit: floppydisk) nhanh chóng tìm ra được thiếu sót trầm trọng trong quá trình làm sản phẩm này…

Giờ mình xin chia sẻ với các bạn cách làm của tụi mình (zepto team). Title mặc dù là phân tích USB nhưng bài này sẽ đi sâu vào RE phần mềm, đặc biệt là .NET.

Tìm hiểu thêm về sản phẩm tại đây:
http://tic.vn/usb-an-toan-bao-mat-vskey-8gb

Vọc thử

Cắm USB vào lap, cảm nhận độ chất của cái giá trên.

Với tính năng AutoPlay enable, 1 phần mềm autorun yêu cầu quyền Administrator để hiện ra 1 Form Login sau.

Nhập password mặc định “admin”, ta có phần mềm quản lý USB. Phần mềm không có gì đặc biệt, ngoài trừ việc không cho user tạo file trực tiếp trên USB.

Sau khi sử dụng thử vài phút, cảm nhận đầu tiên là các thao tác copy/paste từ/sang USB chậm hơn bình thường. Nhưng lại không rõ cụ thể vì không có tốc độ copy/paste. Cái hay nhất của phần mềm là giao diện Tiếng Việt đem lại cảm giác thoải mái khi sử dụng 😅

Vọc thêm chút nữa

Quay về bước đầu cắm USB. Nhận thấy USB mount 1 CD-ROM drive, gồm các phần mềm

Tụi mình đã thử dd toàn bộ physical disk ra, tuy nhiên ngoài CD-ROM drive thì không collect được partition nào khác.

File autorun.inf giúp user , vậy ta sẽ kiểm tra nội dung của file này

[AutoRun]
label=X
open=Run.exe
icon=Run.exe,0

Vậy autorun.inf gọi tới file Run.exe. Mở CFF Explorer xác định file này dùng VB Compiler.

Ta sẽ dùng VB Decompiler để decompile file này.

Kết quả Run.exe chạy các file .NET với OS tương ứng

• OS 7 trở xuống sẽ sử dụng .NET 2 (Tool20.exe)
• OS 8, 10 sẽ sử dụng .NET 4.5 (Tool45.exe)

Những file Tool*.exe tiếp tục gọi đến fileU_Tools.exe với quyền Administrator.

Xác định đượcU_Tools.exe là phần mềm quản lý USB gốc, kéo thả nó vào CFF Explorer (cách làm như trên) thì xác định là .NET application.

Reverse Engineering .NET app

Có rất nhiều tool decompile hoặc debug .NET app, tuy nhiên ở đây mình sử dụng và recommend dnSpy. Vì nó open-source, rất nhiều tính năng và tác giả rất active trên Github.

Giao diện của dnSpy rất user-friendly. Sau khi kéo thả U_Tools.exe vào dnSpy, ở tab bên trái Assembly Explorer ta thấy 1 mục tên U_Tools. Tiếp theo Right-Click -> Go To Entry Point để nhảy vào hàm Main

Nhìn vào các namespace (màu vàng) ta đoán phần mềm này đã bị obfuscate. Tiếp đây mình cũng giới thiệu 1 công cụ deobfuscate và unpack (đồng tác giả với dnSpy) — de4dot. Cách làm đơn giản như sau:

> de4dot.exe -f <obfuscated> -o <deobfuscated>

Thêm argument -d ta xác định được U_Tools dùng Reactor Obfuscator.

Theo Entry Point của file được deobfuscate trong dnSpy một lần nữa (cách làm giống trên), ta tới được hàm Main(). Đọc code thì thấy tạo 1 authentication dialog tên frmLogin , nếu auth succeed thì sẽ chạy phần mềm quản lý USB LTOOLSnet .

Dựa vào hàm constructor mặc định của Form/Window là InitializeCompnent, ta đặt được 2 breakpoint trong classfrmLogin là frmLogin_Load khi load form và 1 EventHandler tên cmdLogin_Click khi submit password.

Dừng việc debug tại đây 1 lát, giờ mình sẽ nói qua về phân tích tĩnh file này..

Có 3 class cần chú ý RAW.DISK, X.{frmLogin, LTOOLSnet}.

Đại khái chức năng chính của 3 class này:

• RAW.DISK: tương tác với PHYSICALDRIVE(trường hợp này là USB), nhiệm vụ chính là read/write các sector trên USB.
• frmLogin: class tạo ra Form Login (hình Form Login trên)
• LTOOLSnet: phần mềm quản lý USB (hình Phần Mềm Quản Lý trên), cóp nhặt phần mềm từ các nơi..

Ngoài lề: rất nhiều hàm trong các class dưới đây không được sử dụng. Như class DISK.RAW là 1 file .DLL được share trên 1 forum, và rất nhiều tính năng “ẩn” vô hại nữa 🙂 Quan trọng điều này làm phần mềm bloat một cách không cần thiết…

Tiếp tục debug..

Đặt được 2 breakpoint này, ta nhập đúng pass và trace tới khi fLogin(object init từ frmLogin) Dispose (tạm hiểu là trace đến khi Form Login biến mất). Ta có thể tóm tắt cách hoạt động của Form Login như sau:

Giờ đi vào chi tiết xíu…

Hàm smethod2 ở bước 3: compute hash SHA512 với tham số là pass từ input— strPassword. Salt ở đây là MD5.CODE_STRING.

FYI: Salt ở đây là hardcoded string “Ivan Medvedev”. Không riêng mình mà cũng có người có câu hỏi :))
https://www.codeproject.com/Articles/5719/Simple-encrypting-and-decrypting-data-in-C?msg=3654375#xx3654375xx

Đoạn xác thực password dựa vào compare hash SHA512 — @string với key xác thực — txtKey.text

Quan trọng nhất, là USB không hề encrypt dữ liệu. Việc xác thực password này chỉ có tác dụng với cái form 😨

Đơn giản kiểm tra thiếu sót này bằng cách tạo 1 file trong USB

Sau đó copy sang USB (thậm chí đổi cả pass nữa), dùng hex editor với USB

Dễ dàng thấy file trong USB không hề được encrypt. Chứng tỏ USB không hề encrypt dữ liệu. Myth confirmed!

Mã hóa ngoại truyện

Mình có nói qua là phần mềm này được cóp nhặt từ rất nhiều nơi, vì vậy có 1 vài feature “ẩn” khá là hài hước.

USB mặc định không encrypt dữ liệu. Tuy nhiên việc mã hóa là một tính năng “ẩn” của 1 “USB an toàn bảo mật” :))

Sau khi patch lại ta có menu như sau

Khi chế độ trên bật lên, phần mềm sẽ sử dụng Rijndael AES để encrypt file với biến bientoancuc.FORMAT_KEY và salt (vẫn là magic string khi hash SHA512).

Điều thú vị là FormatKey và mã hash SHA512 đều có thể dễ dàng lấy từ USB như nhau.

Ngoài ra đoạn kiểm tra định dạng của USB có thể nói vô cùng nhảm, ở các hàm sau:

• frmLogin.method_5(không resolve được tên) — compare magic string với sector 8
• frmLogin.ReadCountPassFalse() — compare magic string với sector 16 , đồng thời lưu số lần nhập sai password vào trong sector 16 + 33 bytes
• DISK.CreateStream() — compare 2 byte 450 và 466 ở sector 0 với magic value. Đặc biệt hàm này là cách duy nhất mà tác giả gọi tới hàm CreateFile()…
• Một vài hàm nữa…

Bypass

Tóm lại mình có 2 cách để bypass

• Ghi đè hash SHA512 của salt+password vàosector 5
https://gist.github.com/zeptovn/710911f6ef373c330a8afa993c6b2d0c
• Patch phần mềm U_Tools ở đoạn compare hash và key xác thực…

Cách 3 là extract hash SHA512 từ USB rồi tìm pass tương ứng với mã hash, nhưng không khả thi với password phức tạp.

Clone USB

Trong quá trình làm, nhóm thường hay đùa về giá cả của chiếc USB này. Giờ mình để lại script clone chiếc USB này dựa vào hàm format của chính nó, đầu tiên là giúp các bạn có thể kiểm chứng lại bài viết này mà không cần mua USB (tất nhiên firmware hay cách tạo CD-ROM thì chắc để lần sau zz)

https://gist.github.com/zeptovn/c22151dc75cce3a110a3dfc1f20dbbf4

Script trên có gọi tới 3 file .bin, những file này đều nằm trong CD-ROM.

Kết luận và Gợi ý

Kiểm lại những gì tụi mình vọc:

• Tìm và bypass phần xác thực USB
• Clone USB

Tới đây, chiếc USB này có thể thực sự gọi là USB bảo mật hay không là tùy cách nghĩ của bạn!

Ngoài ra, mình có 1 vài personal recommendation cho những bạn nào muốn thử nghiệm làm USB an toàn hơn:

• Có option FDE (Full Disk Encrytion) cho user, nên đặt làm mặc định. Bạn có thể sử dụng AES mode XTS vì Bitlocker Windows 10 sử dụng cái này làm mặc định 😳
• Hardware Encryption thay vì Software Encryption.

Software Encryption đơn giản là dựa vào phần mềm để encrypt/decrypt dữ liệu. Tuy nhiên phần mềm chậm, yêu cầu cài đặt driver/update và dễ dàng bị crack/detect cho các cuộc tấn công trong tương lai.

• Áp dụng KEK (Key Encryption Key) cho DEK (Data Encryption Key) nếu sử dụng FDE.

DEK là key dùng để encrypt dữ liệu.

KEK được tạo nên bởi nhiều yếu tố, dùng để encrypt DEK.

FDE software sẽ khởi tạo một giá trị random cho DEK. KEK cũng được khởi tạo bởi nhiều yếu tố và password của user cũng là 1 trong. Một lợi ích của việc sử dụng KEK/DEK là khi user đổi password thì sẽ chỉ re-encrypt lại KEK, thay vì toàn bộ volume.

Cảm ơn các bạn đã đọc tới đây!

By nl+tofu

Về chất lượng bài viết hay bạn có thắc mắc, đừng ngại comment phía dưới. Mình rất sẵn lòng trả lời các bạn.