2.2.3. Mơi trường Sandbox (SE)
IoT Botnet được xây dựng để chạy trên nhiều kiến trúc CPU khác nhau để phù hợp với sự đa dạng của các thiết bị IoT. Để cĩ thể chạy và phân tích IoT Botnet trên các kiến trúc CPU khác nhau trong mơi trường mơ phỏng, nghiên cứu sinh đã chọn sử dụng QEMU [83]. Dự án mã nguồn mở QEMU hỗ trợ nhiều kiến trúc CPU như ARM, MIPS, PowerPC, SPARC,… Bên trong mỗi mơi trường Sandbox SE sẽ sử dụng bản ảnh Debian dựng sẵn của Aurel [82] với máy chủ QEMU, các tác tử quản lý, giám sát và thu thập các hành vi tệp ELF được thực thi (minh họa trong Hình 2.6). Các tham số cấu hình để khởi chạy máy chủ QEMU, được đọc từ tệp “Configuration file”. Khối Giả lập máy chủ C&C (C&C simulator) sử dụng các địa chỉ IP này để tạo kết nối giữa máy chủ QEMU và máy chủ C&C mơ phỏng. Tên tệp và đường dẫn của thư viện liên kết động được sử dụng để thêm các thư viện bị thiếu từ cơ sở dữ liệu thư viện liên kết động vào bản ảnh Debian. Máy chủ QEMU được khởi chạy với các tham số cấu hình được minh họa như trong Hình 2.7.
Hình 2.6 Kiến trúc bên trong SE
Hình 2.7 Lệnh khởi động mơi trường SE
Các tác tử (agents) được viết bằng ngơn ngữ C và được biên dịch chéo (cross- compiled) bởi Toolchains [84] cho các kiến trúc CPU tương ứng. Verma [85] đã trình
bày cách sử dụng Toolchains để tạo các ứng dụng chạy trên các thiết bị IoT với các kiến trúc CPU khác nhau. Với các đặc trưng của IoT botnet được trình bày trong Chương 1 của luận án, mơi trường SE sẽ được tích hợp với các cơng cụ để giám sát các hành vi của mã độc, bao gồm các lời gọi hệ thống, hoạt động liên quan tới tệp và thư mục, hiệu năng máy chủ, yêu cầu thư viện liên kết động và hành vi mạng. Trong mơi trường SE, để thu thập các thơng tin kể trên nghiên cứu sinh tích hợp các tác tử, bao gồm:
- Controller agent: quản lý các tác vụ chung của các tác tử thu thập thơng tin, kích hoạt thực thi tệp ELF, nhận và truyền thơng tin được thu thập đến khối RDP.
- File agent: thu thập các hành vi liên quan đến tệp và thư mục (dựa trên cơng cụ “lsof” [86]). Nghiên cứu sinh đã chọn sử dụng cơng cụ “lsof” để theo dõi sự tương tác với các tệp và thư mục của các tệp ELF vì hai lý do. Thứ nhất, cơng cụ này hiệu quả trong giám sát các tập tin đang được truy cập bởi các tiến trình. Ngồi ra, “lsof” cĩ thể sử dụng trên nhiều kiến trúc CPU khác nhau vì được tích hợp sẵn vào Kernel Linux.
- Host performance agent: thu thập các hành vi liên quan đến việc sử dụng tài nguyên hệ thống, chẳng hạn như CPU, RAM (dựa trên cơng cụ “top” [87]). Để theo dõi hiệu năng của máy chủ, cĩ nhiều cơng cụ khác nhau như “top”, “iostat”, “mpstat”,… Tuy nhiên, trong đĩ cơng cụ “top” phù hợp hơn cho vấn đề này. Cơng cụ này cung cấp
khả năng giám sát thời gian thực của một hệ thống đang chạy, hoạt động của các tiến trình.
- SystemCall agent: thu thập lời gọi hệ thống của tệp ELF (dựa trên cơng cụ
“strace” [88]). Để hiểu rõ hơn về hành vi của tệp ELF khi được thực thi, thơng tin hữu
ích nhất là các lời gọi hệ thống của chính nĩ. Trong Linux, cĩ nhiều cơng cụ hỗ trợ thu thập lời gọi hệ thống của một tệp thực thi (như “ftrace”, “ptrace”,…) nhưng về cơ bản hoạt động như cơng cụ “strace”. Strace theo dõi các lời gọi hệ thống và hữu ích khi
khơng cĩ mã nguồn và muốn phân tích chương trình bằng cách thực thi. Trong IoT Sandbox Limon, Monnappa [52] đã sử dụng Strace để theo dõi các lời gọi hệ thống.
- Shared library requirement agent: khi xây dựng danh sách các thư viện liên kết động ngồi sử dụng “readelf” (trong khối EMF), nghiên cứu sinh cịn sử dụng cơng cụ
“ldd” [89]. Cơng cụ “ldd” liệt kê các thư viện liên kết động theo yêu cầu của từng
chương trình thực thi. Khơng giống như cơng cụ “readelf” trong khối EMF (phần III-
B) chỉ phân tích nội dung tệp ELF tĩnh để xác định thư viện liên kết động, “ldd” giám sát tệp ELF ngay trong mơi trường SE để xác định các thư viện liên kết động theo yêu cầu của ELF. Điều này mang lại hiệu quả cao hơn cho việc xác định các thư viện liên kết động và đã được chứng minh bằng thực nghiệm trên Dataset của nghiên cứu sinh khi so sánh với các IoT Sandbox khác (như LiSa [51], Cuckoo [49]). Kết quả của danh sách các thư viện liên kết động xác định bởi “ldd” và “readelf” được minh họa như trong
Hình 2.8 và Hình 2.9 (lưu ý rằng ldd xác định thêm hai thư viện được chia sẻ là libc.so.6 và ld-uClibc.so.0 và đường dẫn thư mục đầy đủ hơn sử dụng readelf).
- Network agent: thu thập hành vi mạng của tệp ELF (dựa trên cơng cụ
“TCPdump” [90]). Một trong những hành vi quan trọng của IoT Botnet là kết nối với
mạng Bot và nhận lệnh từ Bot master (máy chủ C&C) - đây là những hành vi mạng điển hình của IoT Botnet. Vì vậy, Network agent được xây dựng để thu thập hành vi mạng
của tệp ELF đầu vào bằng cơng cụ “TCPdump”, đây là một cơng cụ đơn giản giúp thu thập và đọc lưu lượng mạng. Cơng cụ này đã được sử dụng nhiều trong xây dựng hệ thống phát hiện xâm nhập mạng (NIDS) [91–93].
Hình 2.8 Thơng tin thư viện liên kết động xác định bởi ldd
Hình 2.9 Thơng tin thư viện liên kết động xác định bởi readelf
2.2.4. Tiền xử lý dữ liệu thơ thu thập được (RDP)
Trong nghiên cứu này, mã độc mà nghiên cứu sinh tập trung phân tích là IoT Botnet. Trong chương 1, luận án cũng đã trình bày các đặc điểm của IoT Botnet bao gồm quét các mục tiêu phù hợp, truy cập các thiết bị dễ bị tởn thương khác, lây nhiễm các thiết bị IoT, giao tiếp với máy chủ C&C qua địa chỉ IP của URL, chờ đợi và thực hiện các lệnh từ máy chủ C&C. Do đĩ, để hiểu hành vi của IoT Botnet, cần phải phân tích dữ liệu thơ thu thập từ Sandbox, bao gồm hành vi mạng (gửi yêu cầu và kết nối với máy chủ C&C, quét các thiết bị IoT khác qua cởng Telnet, SSH), lời gọi hệ thống (tải xuống tệp nhị phân từ máy chủ, thực hiện tệp nhị phân được tải xuống, tấn cơng Brute force tài khoản Telnet, SSH các thiết bị dễ bị tởn thương khác, vòng lặp chờ kết nối đến máy chủ C&C,…), các thay đởi tệp và thư mục, yêu cầu sử dụng thư viện liên kết động, chiếm dụng tài nguyên hệ thống (CPU, RAM,…).
Vì lý do đĩ, khối RDP phân tích dữ liệu thơ được thu thập từ mơi trường SE để làm đầu vào cho khối tính tốn khả năng thực thi lại Sandbox (SR), bao gồm:
- Lưu lượng mạng: Trích xuất thơng tin cần thiết như địa chỉ IP đích, giao thức kết nối, cởng kết nối, dữ liệu chuỗi (nếu khơng được mã hĩa).
- Các lời gọi hệ thống: Thơng tin được trích xuất bao gồm tên của lời gọi hệ
- Hoạt động của tệp/thư mục: Tập trung vào việc xác định các tệp và thư mục mà các tệp ELF tương tác (mở, viết, viết lại, xĩa, đởi tên, tạo, thay đởi quyền) bao gồm cả các tệp thư viện liên kết động (nếu cĩ). Các thơng tin được trích xuất bao gồm tên của tệp, đường dẫn thư mục chứa tệp, hành vi tương tác.
- Hiệu năng máy chủ: Trích xuất thơng tin CPU và RAM như tởng tỉ lệ sử dụng tài nguyên, tỉ lệ sử dụng tài nguyên của từng tiến trình liên quan đến tệp ELF theo thời gian.
Kết quả tiền xử lý dữ liệu của khối này được cập nhật vào tệp “Configuration
file” như minh họa trong Hình 2.10.
Hình 2.10 Khối RDP cập nhật nội dung tệp “Configuration file”
2.2.5. Tính tốn khả năng thực thi lại Sandbox (SR)
Khối SR sử dụng dữ liệu từ đầu ra của khối RDP bao gồm tởng số lời gọi hệ thống (ts), tởng số gĩi tin mạng (tntp), tởng số lượng tương tác tệp (tfr), tỷ lệ phần trăm trung bình của CPU được sử dụng (avgCPU), tỷ lệ phần trăm trung bình của RAM được sử dụng (avgRAM). Kết quả của khối này là lựa chọn cĩ cần thiết phải chạy lại mơi trường Sandbox hay khơng để phục vụ mục đích thu thập thêm thơng tin về hành vi tệp ELF. Thuật tốn của khối SR được mơ tả trong Thuật tốn 2.1 (Thuật tốn RDM). Thuật tốn với đầu vào là thơng số thống kê dữ liệu được trích xuất từ dữ liệu hành vi của mã độc đã được thu thập gồm: Tởng số lời gọi hệ thống được gọi (ts); Tởng số gĩi tin mạng được bắt giữ (tntp); Tởng số tệp tin liên kết được yêu cầu (tfr); Giá trị trung bình cộng tỉ lệ phần trăm CPU được sử dụng (avgCPU); Giá trị trung bình cộng tỉ lệ phần trăm RAM được sử dụng (avgRAM). Đầu ra của thuật tốn là một giá trị logic (d) cho biết sẽ chạy
lại mơi trường Sandbox hay khơng. Khởi tạo ban đầu, giá trị d = true và biến trạng thái thu thập dữ liệu của Sanbox vt sẽ bằng tởng số liệu thống kê các hành vi tương tác của mã độc được Sanbox thu nhận được. Mơi trường Sandbox sẽ tiếp tục chạy (d=true) cho đến khi biến trạng thái vt khơng tăng nữa. Tức là, mơi trường Sandbox khơng thu thập được thêm các dữ liệu hành vi mới nào nữa của mã độc.
Thuật tốn 2.1 Thuật tốn RDM Input: Extract from Behavior data (
Total system calls: ts,
Total network traffic packets: tntp, Total file name request: tfr,
The average percentage of CPU used: avgCPU, The average percentage of RAM used: avgRAM)
Output: Decision of rerun the Sandbox: d
d = true; t = 0; i = 0; n = 100
1: vt ← (ts+tntp+tfr+avgCPU+avgRAM) 2: while d do
3: t ← t +1 4: Run Sandbox
5: Extract from Behavior data (ts; tntp; tfr; avgCPU; avgRAM) 6: vt ← (ts+tntp+tfr+avgCPU+avgRAM) 7: if vt ≤ vt−1 or t = n then 8: d ← false 9: end if 10: end while 11: return d
2.2.6. Giả lập máy chủ C&C (C&C simulator)
Máy chủ C&C là một thành phần thiết yếu trong mạng Botnet nĩi chung và mạng IoT Botnet nĩi riêng. Máy chủ C&C cung cấp cho người quản trị mạng lưới Botnet một cách quản lý tập trung để theo dõi trạng thái Botnet và ra lệnh thực thi các cuộc tấn cơng DDoS. Giao thức được sử dụng để kết nối giữa máy chủ C&C và bot thường là IRC, HTTP, P2P,… Kết nối của các thành phần trong IoT Botnet được minh họa bởi Angrishi như trong hình 2.20. Để IoT Botnet thể hiện tồn bộ hành vi của nĩ, cần phải tạo kết nối
giữa bot và máy chủ C&C. Sau đĩ, máy chủ C&C phải truyền các lệnh thích hợp để IoT Bot thực thi. Đây là đĩng gĩp chính của khối giả lập máy chủ C&C. Khối giả lập máy chủ C&C tiến hành tạo máy chủ C&C dựa trên tập hợp các địa chỉ IP trong tệp “.config” (minh họa trong Hình 2.11). Một cơ sở dữ liệu về các lệnh C&C được thu thập từ nhiều nguồn khác nhau, như mã nguồn IoT Botnet [25, 94] và các nghiên cứu [35, 43, 95]. Để đơn giản, tất cả lệnh C&C từ cơ sở dữ liệu sẽ được lần lượt gửi đến mục tiêu đang chờ lệnh.
Hình 2.11 Kiến trúc kết nối chung của IoT Botnet [2]
2.2.7. Cơ sở dữ liệu thư viện liên kết động (Share Object DB)
Cơ sở dữ liệu thư viện liên kết động (Share Object DB) tiến hành thêm các tệp thư viện “so” từ cơ sở dữ liệu vào mơi trường Sandbox dựa trên thơng tin trong tệp “.config”. Cơ sở dữ liệu này được thu thập từ các nguồn được chia sẻ trên Internet và
firmware thiết bị IoT (Router, IP camera, Smart TV,…) mà các nhà sản xuất cơng bố trên mạng. Cơng cụ C500-Reverse [96], do nhĩm thực hiện đề tài cấp Bộ cĩ nghiên cứu sinh tham gia phát triển, được sử dụng để trích xuất các tệp thư viện từ firmware. Thơng thường, các tệp “so” sẽ nằm trong thư mục “lib” được đĩng gĩi trong firmware. Nội
dung firmware được trích xuất của router Netgear WNAP320 được hiển thị trong Hình 2.12. Đối với các thiết bị khơng tìm thấy firmware trực tuyến, nĩ sẽ được trích xuất trực
tiếp từ thiết bị với sự trợ giúp của C500-Extractor [96]. Thiết bị phần cứng C500- Extractor được minh họa trong Hình 2.13.
Hình 2.12 Các thư mục được trích x́t từ firmware của Router Netgear WNAP320
Hình 2.13 Thiết bị C500-Extractor
2.2.8. Sinh báo cáo tự động (Report)
Cuối cùng, khi khối SR trả về giá trị “false”, hệ thống sẽ tự động tạo một báo cáo tĩm tắt về hành vi tệp ELF từ dữ liệu hành vi (kết quả của khối RDP). Minh họa cho nội dung của báo cáo cĩ thể được tìm thấy trong kết quả kiểm nghiệm V-Sandbox.
2.3. Thử nghiệm và đánh giá
2.3.1. Bộ dữ liệu thử nghiệm
Để đánh giá mơ hình đề xuất, tập dữ liệu đĩng một vai trị quan trọng. Hiện tại, khơng cĩ nhiều bộ dữ liệu cho IoT Botnet nĩi chung và các thiết bị IoT giới hạn tài nguyên nĩi riêng, chủ yếu là các mẫu mã độc, ít mẫu lành tính. Vì vậy, trong luận án này, nghiên cứu sinh đã thu thập và xây dựng bộ dữ liệu của riêng mình.
Để phục vụ quá trình thử nghiệm và đánh giá các phương pháp đề xuất, bộ cơ sở dữ liệu thử nghiệm (dataset) đảm bảo các tiêu chí cụ thể như sau:
- Là tập hợp các tệp thực thi (nhị phân) của các mẫu mã độc IoT Botnet và các tệp mẫu lành tính đã được thu thập và cơng bố tại các nguồn cơng khai, rõ ràng, cĩ cập nhật của các nhà nghiên cứu trong, ngồi nước.
- Đảm bảo về tỉ lệ cân bằng tương đối giữa số lượng mẫu mã độc và lành tính. - Đảm bảo cĩ các mẫu chạy được trên những nền tảng kiến trúc vi xử lý phở biến của thiết bị IoT (như MIPS, ARM, PowerPC,…).
Để đánh giá tính hiệu quả của V-Sandbox, nghiên cứu sinh xây dựng một bộ Dataset chứa 11069 mẫu bao gồm 6316 mẫu mã độc IoT Botnet và 4753 mẫu lành tính (đảm bảo cân bằng tỉ lệ giữa mẫu mã độc và lành tính). Các mẫu mã độc IoT Botnet được thu thập từ ba nguồn chính từ IoTPOT [31], Virustotal [117] và VirusShare [118]. Các mẫu lành tính được trích xuất từ hình ảnh phần sụn của các thiết bị IoT hạn chế tài nguyên trên mạng như bộ định tuyến, camera IP, đèn thơng minh,… Nghiên cứu sinh sử dụng cơng cụ FMK (Firmware Modification Kit) [79] và Binwalk [153] cho cơng việc trích xuất này. Bộ cơ sở dữ liệu thử nghiệm đã đảm bảo độ đa dạng về kiến trúc vi xử lý gồm: ARM (2279 mẫu), MIPS (2811 mẫu), Intel 80386 (2058 mẫu), PowerPC (918 mẫu),…
2.3.2. Triển khai thử nghiệm
Thử nghiệm được tiến hành trên máy chủ với cấu hình CPU Intel Xeon E5-2689 2,6 GHz, RAM 32 GB. V-Sandbox hỗ trợ nhiều kiến trúc CPU khác nhau, về cơ bản bao gồm ARM, MIPS, MIPSEL, i386, x86-64, PowerPC (cĩ thể được mở rộng với nhiều kiến trúc khác) được minh họa trong Hình 2.14. Tất cả các máy ảo QEMU này được kết nối với Virtual Switch để quản lý, cung cấp mơi trường mạng mơ phỏng cũng như khả năng kết nối với máy chủ C&C, giám sát lưu lượng mạng, thêm thư viện liên kết động bị thiếu. Main Controller chịu trách nhiệm quản lý các tác vụ bao gồm nhận và chuyển tệp ELF sang máy chủ ảo, xác định kiến trúc CPU của ELF để chạy máy chủ ảo tương ứng, kích hoạt tệp ELF và tác tử giám sát, cung cấp tệp Share Object ("so") khi ELF yêu cầu, tạo kết nối với máy chủ C&C mơ phỏng khi cần thiết và tởng hợp báo cáo phân tích từ tác tử giám sát hành vi.
Hình 2.14 Mơ hình triển khai thử nghiệm của V-Sandbox
2.3.3. Kết quả kiểm nghiệm V-Sandbox
Trong Bảng 2.2, mơ tả kết quả chạy Dataset trên V-Sandbox. Kết quả thử nghiệm cho thấy với Dataset chứa 11069 mẫu bao gồm 6316 mẫu mã độc IoT Botnet và 4753 mẫu lành tính, V-Sandbox đã chạy và phân tích thành cơng 8911 mẫu với nhiều kiến trúc CPU khác nhau. Đáng chú ý, tỷ lệ mẫu liên kết tĩnh đạt hơn 80% và mẫu liên kết động là hơn 70%. Kết quả này là một lợi thế khi kết hợp máy chủ C&C và thư viện liên kết động trong V-Sandbox. Các kết quả phân tích được thu thập từ V-Sandbox cho các mẫu trong Bộ dữ liệu được minh họa trong các hình dưới đây.
Bảng 2.2 Thống kê kết quả chạy V-Sandbox
Kiến trúc CPU
Số mẫu liên kết tĩnh
chạy thành cơng Số mẫu liên kết động chạy thành cơng
Tởng số mẫu chạy thành cơng ARM 1672 (81.36%) 607 (78.63%) 2279 (80.62%) MIPS 1790 (86.56%) 1021 (77.82%) 2811 (83.17%) Intel 80386 1745 (94.12%) 313 (83.47%) 2058 (92.33%) PowerPC 770 (66.09%) 148 (35.92%) 918 (58.21%) x86-64 692 (84.39%) 153 (64.83%) 845 (80.02%) Toàn bộ