Giải mã tính năng che giấu của TriangleDB trong chiến dịch Operation Triangulation
Thành phần xác thực
Trong chiến dịch tấn công Operation Triangulation, nạn nhân sẽ nhận được tệp đính kèm iMessage độc hại khởi chạy một chuỗi khai thác và việc thực thi chúng cuối cùng dẫn đến việc khởi chạy phần mềm độc hại TriangleDB. Chi tiết hơn, chuỗi lây nhiễm có thể được tóm tắt bằng Hình 1.
.png)
Hình 1. Chuỗi lây nhiễm trong chiến dịch Operation Triangulation
Ngoài các hoạt động khai thác và thành phần của TriangleDB, chuỗi lây nhiễm còn có hai giai đoạn trình xác thực, bao gồm trình xác thực JavaScript và trình xác thực nhị phân.
Những trình xác thực này thu thập nhiều thông tin khác nhau về thiết bị nạn nhân và gửi nó đến máy chủ chỉ huy và kiểm soát (C2). Thông tin này sau đó được sử dụng để đánh giá xem iPhone hoặc iPad được nhúng TriangleDB có thể là thiết bị nghiên cứu hay không. Bằng cách thực hiện các kiểm tra như vậy, kẻ tấn công có thể đảm bảo rằng các lần khai thác zero-day và triển khai phần mềm độc hại của chúng không bị phát hiện.
Trình xác thực JavaScript
Khi bắt đầu chuỗi lây nhiễm, nạn nhân nhận được tệp đính kèm iMessage vô hình với cách khai thác không cần nhấp chuột (zero-click). Mục tiêu cuối cùng của hành động này là bí mật mở một URL duy nhất trên miền backuprabbit[.]com.
Trang HTML được lưu trữ trên URL đó chứa mã JavaScript bị xáo trộn của thư viện mật mã NaCl cũng như payload được mã hóa. Payload này là trình xác thực JavaScript, nó thực hiện nhiều hoạt động kiểm tra khác nhau, bao gồm các phép toán số học như Math.log(-1) hoặc Math.sqrt(-1), tính khả dụng của các thành phần như nguồn API Media, WebAssembly và các thành phần khác.
Bên cạnh đó, trình xác thực này thực hiện một kỹ thuật lấy dấu vân tay được gọi là Canvas Fingerprinting bằng cách vẽ một hình tam giác màu vàng trên nền màu hồng bằng WebGL và tính tổng kiểm tra của nó.
Hình 2. Mã nguồn vẽ hình tam giác
Hình 3. Hình tam giác được vẽ
Trên thực tế, tam giác này là lý do tại sao các nhà nghiên cứu gọi toàn bộ chiến dịch này là Operation Triangulation. Sau khi chạy trình xác thực, nó sẽ mã hóa và gửi tất cả thông tin được thu thập đến một URL duy nhất khác trên backuprabbit[.]com để nhận (hoặc không nhận) giai đoạn tiếp theo của chuỗi lây nhiễm.
Trình xác thực nhị phân
Như chúng ta thấy từ biểu đồ chuỗi lây nhiễm, trình xác thực này được khởi chạy trước khi triển khai bộ phần mềm độc hại TriangleDB. Ngược lại với trình xác thực JavaScript là một tập lệnh, trình xác thực này là tệp nhị phân Mach-O (do đó có tên là trình xác thực nhị phân). Khi khởi chạy, nó sẽ giải mã cấu hình của nó bằng AES.
Hình 4. Mã nguồn danh sách các hành động được thực thi
Tập lệnh này chứa danh sách các hành động (chẳng hạn như DeleteLogs, DeleteArtifacts,…) mà người xác thực phải thực hiện. Cụ thể là:
- Xóa nhật ký sự cố khỏi thư mục /private/var/mobile/Library/Logs/CrashReporter có thể đã được tạo trong quá trình khai thác.
- Tìm kiếm dấu vết của tệp đính kèm iMessage độc hại trong nhiều cơ sở dữ liệu khác nhau, chẳng hạn như ids-pub-id.db hoặc KnowledgeC.db, sau đó xóa chúng. Để có thể làm điều đó, cấu hình của trình xác thực chứa 40 mã băm MD5 của ID Apple được sử dụng để gửi iMessages độc hại. Các nhà nghiên cứu của Kasperksy đã cố gắng bẻ khóa phần lớn các hàm băm này, nhờ đó có được danh sách các địa chỉ email Apple ID do kẻ tấn công kiểm soát.
Hình 5. Danh sách địa chỉ email của kẻ tấn công
- Nhận danh sách các tiến trình đang chạy trên thiết bị, cũng như danh sách các giao diện (interface) của mạng.
- Kiểm tra xem thiết bị mục tiêu có được bẻ khóa hay không. Trình xác thực thực hiện kiểm tra một loạt các công cụ bẻ khóa, bao gồm: Pangu, xCon, Evasion7, Electra, unc0ver, checkra1n và nhiều công cụ khác.
- Bật theo dõi quảng cáo được cá nhân hóa.
- Thu thập nhiều loại thông tin về nạn nhân, chẳng hạn như tên người dùng, số điện thoại, IMEI và ID Apple.
- Truy xuất danh sách các ứng dụng đã cài đặt.
Điều thú vị về những hành động này là trình xác thực triển khai cho cả hệ thống iOS và macOS. Kaspersky cũng phát hiện ra rằng trình xác nhận thực hiện một hành động không được sử dụng, được những kẻ tấn công gọi là PSPDetect.
Hình 6. mã nguồn về hành động PSPDetect
Hành động này truy xuất danh sách các tệp từ cấu hình của trình xác thực (danh sách này trống đối với các cấu hình trình xác thực mà các nhà nghiên cứu đã phân tích), kiểm tra xem chúng có trong hệ thống tệp hay không và tạo danh sách các tệp được tìm thấy làm đầu ra.
Chữ viết tắt PSP trong tên của hành động này có thể có nghĩa là một giải pháp bảo mật. Do đó, có thể hành động này có thể được khởi chạy trên các thiết bị macOS để phát hiện các sản phẩm anti-virus đã được cài đặt.
Sau khi thực hiện tất cả các hành động này, trình xác thực sẽ mã hóa và gửi dữ liệu thu được, bao gồm danh sách các tiến trình, thông tin người dùng,… đến máy chủ C2. Để phản hồi, máy chủ trả về bộ phần mềm TriangleDB đã mô tả trước đó.
Tìm kiếm dấu vết trong nhật ký
Tác nhân đe dọa đằng sau chiến dịch này thực hiện hành vi lén lút không chỉ bằng cách đưa hai trình xác thực vào chuỗi lây nhiễm. Trên thực tế, chúng thực hiện mọi thao tác với TriangleDB rất cẩn thận.
Sau khi phần mềm độc hại thiết lập liên lạc với máy chủ C2 và gửi heartbeat, nó sẽ nhận được nhiều lệnh CRXShowTables và CRXFetchRecord từ máy chủ C2. Các lệnh này liên quan đến việc truy xuất nhật ký có thể hiển thị dấu vết của chuỗi lây nhiễm hoặc chính phần mềm độc hại. Một số tệp được truy xuất là:
- Các tệp nhật ký sự cố (ví dụ: các tệp trong /var/mobile/Library/Logs/CrashReporter).
- Các tệp cơ sở dữ liệu (ví dụ: /private/var/mobile/Library/IdentityServices/ids-gossip.db). Các tệp này có thể chứa ID Apple được kẻ tấn công sử dụng để gửi iMessage độc hại.
Sau khi những kẻ tấn công nhận được các tệp này, chúng sẽ xóa chúng khỏi thiết bị để nạn nhân không thể kiểm tra chúng và có thể tìm thấy dấu hiệu xâm phạm. Sau khi hoàn tất việc thu thập và xóa nhật ký, kẻ tấn công sẽ gửi nhiều lệnh CRXPollRecords đến phần mềm độc hại, hướng dẫn nó trích xuất định kỳ các tệp từ thư mục /private/var/tmp.
Bảng 1: Vai trò của các biểu thức chính quy
Ghi âm micrô
Một trong những module xâm phạm quyền riêng tư nhất là ghi micrô, có tên là msu3h (các nhà nghiên cứu tin rằng 3h là viết tắt của ba giờ, thời lượng ghi mặc định). Sau khi thực thi, nó sẽ giải mã (sử dụng thuật toán tùy chỉnh lấy từ hàm băm GTA IV) cấu hình của nó, nhưng nó chỉ thực hiện các hành động tiếp theo nếu pin được sạc trên 10%.
Bản thân tệp cấu hình chứa dữ liệu cấu hình điển hình, chẳng hạn như thời lượng ghi và khóa mã hóa AES được sử dụng để mã hóa các bản ghi, cũng như nhiều thông số đe dọa hơn, chẳng hạn như:
- SuspOnDeviceInUse: Đặt xem có nên dừng ghi hay không nếu màn hình thiết bị được bật.
- syslogRelayOverride: Đặt xem có nên ghi âm thanh khi ghi nhật ký hệ thống hay không.
Quá trình ghi diễn ra bằng Audio Queue API và các đoạn âm thanh được nén bằng Speex codec, sau đó được mã hóa bằng AES. Ngoài dữ liệu âm thanh, mỗi bản ghi còn chứa các thông báo có mã định danh kiểu 4 byte (Bảng 2).
Bảng 2: Mã định danh của các mã thông báo
Module đánh cắp SQLite
Nhiều ứng dụng trên iOS sử dụng SQLite để lưu trữ dữ liệu nội bộ của chúng. Do đó, không có gì ngạc nhiên khi những kẻ tấn công đã triển khai các module có khả năng đánh cắp dữ liệu từ nhiều cơ sở dữ liệu SQLite khác nhau.
Tất cả các module này có cùng codebase và chứa các truy vấn SQL khác nhau sẽ được thực thi. Một lần nữa, chúng có cấu hình được mã hóa. Khi điều này được giải mã, chỉ có thể tìm thấy các biến tiêu chuẩn như đường dẫn tệp, khóa AES, chuỗi truy vấn,…
Code của các module này khá đặc biệt. Ví dụ: những kẻ tấn công đã triển khai một trình bao bọc xung quanh hàm fopen(), thêm cờ Z (cho biết rằng tệp được tạo phải được mã hóa AES và nén zlib) được sử dụng kết hợp với cờ w (ghi) tiêu chuẩn, như có thể nhìn thấy trong hình ảnh dưới đây.
Hình 7. Mã nguồn module đánh cắp SQLite
Mỗi module mà các nhà nghiên cứu tìm thấy sẽ thực hiện các truy vấn cơ sở dữ liệu SQL khác nhau. Ví dụ: có một module xử lý dữ liệu sử dụng ứng dụng từ cơ sở dữ liệu KnowledgeC.db. Một module khác trích xuất metadata liên quan đến ảnh, chẳng hạn như có trẻ em trong ảnh hay không, người đó là nam hay nữ,…
Module giám sát vị trí
Module này chạy trong một luồng riêng biệt và cố gắng mạo danh gói được ủy quyền sử dụng các dịch vụ định vị được chỉ định trong cấu hình (ví dụ: /System/Library/LocationBundles/Routine.bundle).
Ngoài việc sử dụng GPS để xác định vị trí, nó còn sử dụng GSM, truy xuất các giá trị MCC (MobileCountryCode), MNC (MobileNetworkCode), LAC (LocationAreaCode) và CID (CellID) thông qua framework CoreTelephony. Một lý do để sử dụng dữ liệu liên quan đến GSM là để ước tính vị trí của nạn nhân khi không có dữ liệu GPS.
Hồng Đạt
(tổng hợp)
