Bagaimana Performa Android yang Di-Dockerized di Berbagai Sistem Operasi

:::info Penulis:

(1) Daniele Capone, SecSI srl, Napoli, Italia ([email protected]);

(2) Francesco Caturano, Dept. of Electrical Engineering and Information, Technology University of Napoli Federico II, Napoli, Italia ([email protected])

(3) Angelo Delicato, SecSI srl, Napoli, Italia ([email protected]);

(4) Gaetano Perrone, Dept. of Electrical Engineering and Information Technology, University of Napoli Federico II, Napoli, Italia ([email protected])

(5) Simon Pietro Romano, Dept. of Electrical Engineering and Information Technology, University of Napoli Federico II, Napoli, Italia ([email protected]).

:::

Daftar Tautan

Abstrak dan I. Pendahuluan

II. Karya Terkait

III. Dockerized Android: Desain

IV. Arsitektur Dockerized Android

V. Evaluasi

VI. Kesimpulan dan Pengembangan Masa Depan, serta Referensi

V. EVALUASI

Bagian ini menilai platform Dockerized Android dengan memeriksa beberapa aspek. Pertama, kami menekankan perbedaan antara komponen Core for Emulator dan Core for Real Device dalam hal fitur dan menyoroti kompatibilitas dengan tiga Sistem Operasi yang paling banyak digunakan. Kemudian, kami memberikan contoh penggunaan praktis dari Dockerized Android dan membahas cakupan persyaratan yang didefinisikan dalam Bagian III.

\

\ A. Perbedaan antara Core for Emulator dan Core for Real Device

\ Meskipun upaya signifikan telah dilakukan untuk menciptakan sistem yang memiliki fitur yang sama untuk kedua jenis perangkat, ada keterbatasan ketika emulasi digunakan:

\ • Fitur pengiriman/penerimaan SMS ADB: pada perangkat yang diemulasikan, dimungkinkan untuk mengotomatisasi pengiriman dan penerimaan pesan SMS melalui perangkat lunak ADB. Jelas, ini tidak mungkin dilakukan secara native untuk perangkat nyata. Oleh karena itu, pengguna harus mengirim dan menerima pesan SMS secara manual untuk mengimplementasikan skenario serangan SMS. Solusi untuk mengatasi masalah ini bisa berupa realisasi aplikasi Android kustom yang dapat diinstal pada perangkat nyata dan dapat diinstrumentasi untuk mengirim dan menerima pesan secara otomatis.

\ • Jaringan: jaringan cukup berbeda antara versi Emulator dan perangkat Real. Dalam versi emulator, AVD dibuat di dalam kontainer Docker, dan karenanya berbagi alamat IP kontainer. Sebaliknya, perangkat nyata terhubung secara fisik ke mesin yang menjalankan kontainer dan mempertahankan alamat IP-nya sendiri.

\ • Virtualisasi perangkat keras: untuk komponen perangkat keras, situasinya juga cukup berbeda: beberapa perangkat keras seperti GPS dan mikrofon dapat diemulasikan. Secara khusus, lokasi GPS perangkat dapat diatur melalui ADB, dan mikrofon mesin host dapat dibagikan dengan emulator. Ada komponen perangkat keras lain yang saat ini tidak dapat diemulasikan, seperti, misalnya Bluetooth.

\ B. Evaluasi host untuk kompatibilitas lintas platform

\ Persyaratan non-fungsional NF04 (Kompatibilitas lintas platform) menyatakan bahwa sistem yang dihasilkan harus dapat digunakan dari dalam OS host mana pun. Ini mengacu pada OS mesin yang menjalankan kontainer Docker. Tabel III memberikan ringkasan kompatibilitas dengan Linux, Windows, dan OS X.

\

\ Masalah dengan Windows adalah bahwa saat ini, cara terbaik untuk menggunakan Docker adalah melalui kerangka kerja Windows Subsystem for Linux (WSL). Sayangnya, WSL belum mendukung virtualisasi bersarang, dan fitur ini diperlukan untuk menjalankan emulator Android di dalam kontainer Docker. Namun, fitur ini akan tersedia dalam rilis WSL mendatang. Mungkin untuk menjalankan versi Core for Emulator di Windows dengan menggunakan mesin virtual, meskipun kehilangan semua manfaat kinerja yang terkait dengan kontainerisasi. Masalah serupa juga ada dengan OS X, yang saat ini tidak ada cara untuk menjalankan Core for Emulator. Selain itu, OS X tidak memungkinkan berbagi perangkat USB dengan kontainer Docker. Untuk alasan ini, satu-satunya cara untuk menggunakan Core for Real Device adalah dengan menjalankan ADB melalui Wi-Fi atau menghubungkan ke ADB host dari dalam kontainer Docker.

\ Dalam sisa bagian ini, kami menunjukkan efektivitas Dockerized Android dalam mereproduksi rantai pembunuhan keamanan dengan menggunakan baik Core for Emulator maupun Core for Real Device.

\ C. Reproduksi serangan keamanan pada emulator

\ Kami di sini fokus pada skenario kerentanan sampel yang terkait dengan CVE-2018-7661[1]. CVE ini terkait dengan versi gratis dari aplikasi "Wi-Fi Baby Monitor". Aplikasi ini harus diinstal pada dua perangkat untuk bertindak sebagai apa yang disebut baby monitor (sistem radio yang digunakan untuk mendengarkan suara yang dikeluarkan oleh bayi dari jarak jauh). Seperti dilaporkan dalam National Vulnerability Database, "Wi-Fi Baby Monitor Free & Lite" sebelum versi 2.02.2 memungkinkan penyerang jarak jauh untuk mendapatkan data audio melalui permintaan tertentu ke nomor port TCP 8258 dan 8257".

\

\ Versi premium dari aplikasi ini menawarkan pengguna kemampuan untuk menentukan kata sandi yang akan digunakan dalam proses pemasangan. Dengan memantau lalu lintas jaringan, dimungkinkan untuk mengamati bahwa:

\ • koneksi awal terjadi pada port 8257;

\ • urutan yang sama selalu dikirim untuk memulai proses pemasangan;

\ • pada akhir proses pemasangan, koneksi baru dimulai pada port 8258. Port ini digunakan untuk mengirimkan data audio;

\ • setelah terhubung ke port 8258, koneksi lain pada port 8257 tetap terbuka dan digunakan sebagai detak jantung untuk sesi;

\ • pada koneksi detak jantung, klien secara berkala mengirimkan byte heksadesimal 0x01 (sekitar sekali per detik);

\ Bukti konsep yang memungkinkan penyerang untuk mendapatkan data audio diberikan dalam [21]. Proof of Concept (PoC) ini mudah direproduksi pada Dockerized Android melalui realisasi infrastruktur yang terdiri dari tiga layanan:

\ • core-emulator: sebuah instance dari komponen Core dengan aplikasi Baby Monitor yang telah diinstal sebelumnya yang bertindak sebagai pengirim;

\ • ui: komponen UI untuk mengontrol apa yang sedang terjadi;

\ • attacker: versi kustom dari Kali Linux yang secara otomatis menginstal semua dependensi yang diperlukan untuk eksekusi PoC.

\ Ini juga merupakan contoh sempurna untuk menunjukkan fitur Port Forwarding yang digunakan untuk mengaktifkan komunikasi.

\ D. Reproduksi serangan keamanan pada perangkat nyata

\ Dengan perangkat nyata, kami memeriksa kerentanan lebih lanjut, yang dikenal sebagai BlueBorne. Istilah "BlueBorne" mengacu pada beberapa kerentanan keamanan terkait dengan implementasi Bluetooth. Kerentanan ini ditemukan oleh sekelompok peneliti dari Armis Security, perusahaan keamanan IoT, pada September 2017. Menurut Armis, pada saat penemuan, sekitar 8,2 miliar perangkat berpotensi terpengaruh oleh vektor serangan BlueBorne, yang mempengaruhi implementasi Bluetooth di Android, iOS, Microsoft, dan Linux, sehingga berdampak pada hampir semua jenis perangkat Bluetooth seperti smartphone, laptop, dan smartwatch. BlueBorne dianalisis secara detail dalam makalah yang diterbitkan pada tanggal 12 September 2017 oleh Ben Seri dan Gregor Vishnepolsk [22]. Delapan kerentanan berbeda dapat digunakan sebagai bagian dari vektor serangan.

\ Mengenai Android, semua perangkat dan versi (oleh karena itu versi yang lebih lama dari Android Oreo, yang dirilis pada Desember 2017) terpengaruh oleh kerentanan yang disebutkan di atas, kecuali untuk perangkat yang mendukung BLE (Bluetooth Low Energy). Secara umum, dua persyaratan harus dipenuhi untuk mengeksploitasi kerentanan: (i) perangkat target harus memiliki Bluetooth yang diaktifkan; (ii) penyerang harus cukup dekat dengan perangkat target. Karena fitur Bluetooth tidak tersedia di Core Emulator, kill-chain yang dimaksud hanya dapat direproduksi pada perangkat nyata.

\ 1) Reproduksi penuh BlueBorne pada Dockerized Android: Untuk menunjukkan efektivitas Dockerized Android, kami mengembangkan rantai pembunuhan yang mengeksploitasi dua kerentanan Remote Code Execution (RCE) yang mempengaruhi Android, yaitu, CVE-2017-0781 dan CVE-2017-0782. Kerentanan ini termasuk dalam set kerentanan Bluetooth yang didefinisikan "BlueBorne" dan ditemukan oleh sekelompok peneliti keamanan dari Armis Security [23].

\ Diagram pada Gambar 4 memberikan gambaran umum tentang rantai pembunuhan yang dikembangkan:

\

1. Penyerang membuat email phishing melalui Gophish, perangkat lunak generator phishing.

\ 2) Email phishing dikirim ke kotak surat korban.

\ 3) Korban membaca email phishing dan secara keliru mengklik tautan berbahaya yang terdapat dalam isi email.

\ 4) Tautan berbahaya memungkinkan penyerang untuk memicu serangan yang mengunduh dan menginstal aplikasi palsu pada perangkat mobile korban.

\ 5) Informasi berbahaya mengirimkan informasi mobile yang relevan ke penyerang. Informasi ini diperlukan untuk eksploitasi kedua kerentanan.

\ 6) Penyerang membuat payload berbahaya untuk mengeksploitasi kerentanan.

\ 7) Penyerang mengirimkan serangan dengan mengeksploitasi kerentanan komponen Bluetooth dan memiliki akses jarak jauh ke perangkat korban.

\

\ Skenario kompleks mencakup beberapa ancaman yang didefinisikan dalam Tabel I. Tabel V menunjukkan ancaman tersebut dan baik fungsionalitas platform maupun komponen yang memungkinkan reproduksi skenario. The

\

\ skenario memerlukan komunikasi jaringan yang kompleks (F07) dan melibatkan penggunaan Bluetooth. Untuk alasan ini, kita harus menggunakan perangkat fisik (F10). Dalam skenario yang diusulkan, kita harus mensimulasikan instalasi aplikasi berbahaya ketika pengguna menerima email. Ini dapat dilakukan baik secara manual (F02) atau dengan mengimplementasikan skrip ADB utilitas (F03). Untuk mereproduksi skenario, elemen tambahan diperlukan:

\ • Gophish: sebuah webapp yang memungkinkan untuk membuat dan mengirim email phishing, yang versi Docker-nya sudah ada.

\ • Ghidra: aplikasi yang dibuat oleh National Security Agency (NSA) untuk tujuan rekayasa balik. Dalam konteks ini, digunakan untuk mendapatkan beberapa informasi berguna tentang perangkat target. Aplikasi ini digunakan pada mesin host tanpa Docker.

\ • Fake Spotify: aplikasi yang tampaknya jinak yang berpura-pura menyediakan pengguna dengan versi gratis dari aplikasi Spotify Premium yang terkenal, tetapi justru mengirimkan ke server penyerang file yang dieksfiltrasi yang direkayasa balik pada Ghidra. Juga, aplikasi ini dibuat tanpa penggunaan Docker.