Hiệu suất của Android được Docker hóa trên các hệ điều hành khác nhau

:::info Tác giả:

(1) Daniele Capone, SecSI srl, Napoli, Italy ([e-mail]);

(2) Francesco Caturano, Dept. of Electrical Engineering and Information, Technology University of Napoli Federico II, Napoli, Italy (francesco.caturano@unina.i)

(3) Angelo Delicato, SecSI srl, Napoli, Italy ([e-mail]);

(4) Gaetano Perrone, Dept. of Electrical Engineering and Information Technology, University of Napoli Federico II, Napoli, Italy ([e-mail])

(5) Simon Pietro Romano, Dept. of Electrical Engineering and Information Technology, University of Napoli Federico II, Napoli, Italy ([e-mail]).

:::

Bảng liên kết

Tóm tắt và I. Giới thiệu

II. Các nghiên cứu liên quan

III. Dockerized Android: Thiết kế

IV. Kiến trúc Dockerized Android

V. Đánh giá

VI. Kết luận và Phát triển trong tương lai, và Tài liệu tham khảo

V. ĐÁNH GIÁ

Phần này đánh giá nền tảng Dockerized Android bằng cách xem xét nhiều khía cạnh. Đầu tiên, chúng tôi nhấn mạnh sự khác biệt giữa các thành phần Core for Emulator và Core for Real Device về tính năng và làm nổi bật khả năng tương thích với ba Hệ điều hành được sử dụng phổ biến nhất. Sau đó, chúng tôi cung cấp các ví dụ sử dụng thực tế của Dockerized Android và thảo luận về việc đáp ứng các yêu cầu được định nghĩa trong Phần III.

\

\ A. Sự khác biệt giữa Core for Emulator và Core for Real Device

\ Ngay cả khi đã có nỗ lực đáng kể trong việc tạo ra một hệ thống có cùng tính năng cho cả hai loại thiết bị, vẫn có những hạn chế khi sử dụng giả lập:

\ • Tính năng gửi/nhận SMS qua ADB: trong các thiết bị giả lập, có thể tự động hóa việc gửi và nhận tin nhắn SMS thông qua phần mềm ADB. Rõ ràng, điều này không thể thực hiện một cách tự nhiên đối với thiết bị thực. Do đó, người dùng phải gửi và nhận tin nhắn SMS theo cách thủ công để thực hiện các kịch bản tấn công SMS. Một giải pháp để giải quyết vấn đề này có thể là việc tạo ra một ứng dụng Android tùy chỉnh có thể được cài đặt trên thiết bị thực và có thể được điều khiển để gửi và nhận tin nhắn tự động.

\ • Mạng: mạng khá khác nhau giữa phiên bản Emulator và thiết bị thực. Trong phiên bản giả lập, AVD được tạo bên trong container Docker, và do đó nó chia sẻ địa chỉ IP của container. Thay vào đó, thiết bị thực được kết nối vật lý với máy chạy container và giữ địa chỉ IP riêng của nó.

\ • Ảo hóa phần cứng: đối với các thành phần phần cứng, tình hình cũng khá khác biệt: một số thiết bị phần cứng như GPS và microphone có thể được giả lập. Cụ thể, vị trí GPS của thiết bị có thể được thiết lập thông qua ADB, và microphone của máy chủ có thể được chia sẻ với trình giả lập. Có những thành phần phần cứng khác hiện không thể được giả lập, chẳng hạn như Bluetooth.

\ B. Đánh giá máy chủ về khả năng tương thích đa nền tảng

\ Yêu cầu phi chức năng NF04 (Khả năng tương thích đa nền tảng) nêu rõ rằng hệ thống kết quả nên có thể sử dụng được từ bất kỳ hệ điều hành máy chủ nào. Điều này đề cập đến hệ điều hành của máy chạy các container Docker. Bảng III cung cấp tóm tắt về khả năng tương thích với Linux, Windows và OS X.

\

\ Vấn đề với Windows là hiện tại, cách tốt nhất để sử dụng Docker là thông qua framework Windows Subsystem for Linux (WSL). Đáng tiếc là WSL chưa hỗ trợ ảo hóa lồng nhau, và tính năng này là cần thiết để chạy trình giả lập Android bên trong container Docker. Tuy nhiên, tính năng này sẽ có sẵn trong các phiên bản WSL sắp tới. Có thể chạy Core for Emulator trên Windows bằng cách sử dụng máy ảo, mặc dù sẽ mất tất cả các lợi ích về hiệu suất liên quan đến containerization. Một vấn đề tương tự cũng tồn tại với OS X, hiện tại không có cách nào để chạy Core for Emulator. Ngoài ra, OS X không cho phép chia sẻ thiết bị USB với container Docker. Vì lý do này, các cách duy nhất để sử dụng Core for Real Device là chạy ADB qua Wi-Fi hoặc kết nối với ADB của máy chủ từ bên trong container Docker.

\ Trong phần còn lại của phần này, chúng tôi cho thấy hiệu quả của Dockerized Android trong việc tái tạo các chuỗi tấn công bảo mật bằng cách sử dụng cả Core for Emulator và Core for Real Device.

\ C. Tái tạo tấn công bảo mật trên trình giả lập

\ Chúng tôi tập trung vào một kịch bản lỗ hổng mẫu liên quan đến CVE-2018-7661[1]. CVE này liên quan đến phiên bản miễn phí của ứng dụng "Wi-Fi Baby Monitor". Ứng dụng này phải được cài đặt trên hai thiết bị để hoạt động như một thiết bị giám sát trẻ em (một hệ thống radio được sử dụng để lắng nghe từ xa âm thanh phát ra từ trẻ sơ sinh). Như được báo cáo trong Cơ sở dữ liệu lỗ hổng quốc gia, "Wi-Fi Baby Monitor Free & Lite" trước phiên bản 2.02.2 cho phép kẻ tấn công từ xa lấy dữ liệu âm thanh thông qua các yêu cầu cụ thể đến số cổng TCP 8258 và 8257".

\

\ Phiên bản cao cấp của ứng dụng này cung cấp cho người dùng khả năng chỉ định mật khẩu để sử dụng trong quá trình ghép nối. Bằng cách giám sát lưu lượng mạng, có thể quan sát thấy rằng:

\ • kết nối ban đầu diễn ra trên cổng 8257;

\ • cùng một chuỗi luôn được gửi để bắt đầu quá trình ghép nối;

\ • vào cuối quá trình ghép nối, một kết nối mới được bắt đầu trên cổng 8258. Cổng này được sử dụng để truyền dữ liệu âm thanh;

\ • sau khi kết nối với cổng 8258, kết nối khác trên cổng 8257 được giữ mở và được sử dụng như một heartbeat cho phiên;

\ • trên kết nối heartbeat, máy khách định kỳ gửi byte thập lục phân 0x01 (khoảng một lần mỗi giây);

\ Bằng chứng khái niệm cho phép kẻ tấn công lấy dữ liệu âm thanh được đưa ra trong [21]. Proof of Concept (PoC) này dễ dàng tái tạo trên Dockerized Android thông qua việc thực hiện một cơ sở hạ tầng bao gồm ba dịch vụ:

\ • core-emulator: một phiên bản của thành phần Core với ứng dụng Baby Monitor được cài đặt sẵn đóng vai trò là người gửi;

\ • ui: thành phần UI để kiểm soát những gì đang diễn ra;

\ • attacker: một phiên bản tùy chỉnh của Kali Linux tự động cài đặt tất cả các phụ thuộc cần thiết cho việc thực thi PoC.

\ Đây cũng là một ví dụ hoàn hảo để hiển thị tính năng Port Forwarding được sử dụng để kích hoạt các giao tiếp.

\ D. Tái tạo tấn công bảo mật trên thiết bị thực

\ Với thiết bị thực, chúng tôi xem xét một lỗ hổng khác, được gọi là BlueBorne. Thuật ngữ "BlueBorne" đề cập đến nhiều lỗ hổng bảo mật liên quan đến việc triển khai Bluetooth. Những lỗ hổng này được phát hiện bởi một nhóm các nhà nghiên cứu từ Armis Security, một công ty bảo mật IoT, vào tháng 9 năm 2017. Theo Armis, tại thời điểm phát hiện, khoảng 8,2 tỷ thiết bị có khả năng bị ảnh hưởng bởi vector tấn công BlueBorne, ảnh hưởng đến các triển khai Bluetooth trong Android, iOS, Microsoft và Linux, do đó tác động đến hầu hết các loại thiết bị Bluetooth như điện thoại thông minh, máy tính xách tay và đồng hồ thông minh. BlueBorne đã được phân tích chi tiết trong một bài báo được xuất bản vào ngày 12 tháng 9 năm 2017 bởi Ben Seri và Gregor Vishnepolsk [22]. Tám lỗ hổng khác nhau có thể được sử dụng như một phần của vector tấn công.

\ Đối với Android, tất cả các thiết bị và phiên bản (do đó các phiên bản cũ hơn Android Oreo, được phát hành vào tháng 12 năm 2017) đều bị ảnh hưởng bởi các lỗ hổng đã đề cập ở trên, ngoại trừ các thiết bị hỗ trợ BLE (Bluetooth Low Energy). Nói chung, hai yêu cầu cần được đáp ứng để khai thác lỗ hổng: (i) thiết bị mục tiêu phải bật Bluetooth; (ii) kẻ tấn công phải đủ gần với thiết bị mục tiêu. Vì tính năng Bluetooth không có sẵn trong Core Emulator, chuỗi tấn công này chỉ có thể được tái tạo trên các thiết bị thực.

\ 1) Tái tạo đầy đủ BlueBorne trên Dockerized Android: Để thể hiện hiệu quả của Dockerized Android, chúng tôi đã phát triển một chuỗi tấn công khai thác hai lỗ hổng Remote Code Execution (RCE) ảnh hưởng đến Android, tức là CVE-2017-0781 và CVE-2017-0782. Những lỗ hổng này nằm trong bộ lỗ hổng Bluetooth được định nghĩa là "BlueBorne" và được phát hiện bởi một nhóm các nhà nghiên