Demam Panggung: Eksploitasi yang Mengubah Android

Salah satu keunggulan Android adalah sifatnya yang open source, yang memungkinkan para pemangku kepentingan untuk melakukan fork, memodifikasi, dan mendistribusikan ulang OS dengan cara yang sesuai dengan kebutuhan khusus mereka. Namun keuntungan menjadi open source ini bertindak seperti pedang bermata dua ketika menyangkut masalah malware dan keamanan. Lebih mudah untuk menemukan dan menambal kekurangan ketika Anda memiliki banyak kontributor yang mampu pada sebuah proyek yang kode sumbernya tersedia secara bebas. Namun, memperbaiki masalah di tingkat sumber sering kali tidak berarti bahwa masalah tersebut terselesaikan di tangan konsumen akhir. Oleh karena itu, Android bukanlah pilihan utama dalam memilih OS untuk kebutuhan perusahaan yang sensitif terhadap data.

Pada Google I/O 2014, Google memberikan dorongan pertamanya menuju ekosistem yang lebih aman dan ramah perusahaan dengan meluncurkan

Program Android Untuk Kerja. Android For Work mengadopsi pendekatan profil ganda untuk kebutuhan perusahaan, sehingga administrator TI dapat membuat profil pengguna yang berbeda untuk karyawan - satu fokus pada pekerjaan, meninggalkan profil lain untuk pribadi karyawan menggunakan. Melalui penggunaan enkripsi berbasis perangkat keras dan kebijakan yang dikelola admin, data pekerjaan dan pribadi tetap berbeda dan aman. Selanjutnya, Android For Work mendapat lebih banyak perhatian pada bulan-bulan berikutnya, dengan fokus utama pada keamanan perangkat terhadap malware. Google juga berencana melakukannya aktifkan enkripsi perangkat penuh untuk semua perangkat yang akan dirilis dengan Android Lollipop secara langsung, tetapi ini dibatalkan karena masalah kinerja dan perpindahan tersebut dijadikan opsional untuk diterapkan oleh OEM.

Dorongan untuk menciptakan Android yang aman bukanlah sepenuhnya pekerjaan Google, karena Samsung telah memainkan peran yang cukup signifikan dalam hal ini melalui perusahaannya Kontribusi KNOX untuk AOSP, yang pada akhirnya memperkuat Android For Work. Namun, eksploitasi dan kerentanan keamanan baru-baru ini di Android menunjukkan adanya tugas berat dalam hal popularitas untuk diadopsi oleh perusahaan. Contoh kasusnya adalah kerentanan Stagefright yang terjadi baru-baru ini.

Isi:

• Apa itu Demam Panggung?
• Seberapa seriuskah Demam Panggung?
• Apa yang membuat Stagefright berbeda dari "kerentanan besar" lainnya?
• Dilema Pembaruan
• Android, Pasca Demam Panggung
• Catatan Penutup

Apa itu Demam Panggung?

Secara sederhana, Stagefright adalah eksploitasi yang memanfaatkan pustaka kode untuk pemutaran media di Android yang disebut libstagefright. Mesin libstagefright digunakan untuk mengeksekusi kode yang diterima dalam bentuk video berbahaya melalui MMS, sehingga hanya memerlukan nomor ponsel korban untuk melakukan serangan yang berhasil.

Kami menghubungi pakar internal kami, Pengembang Senior yang Diakui XDA, dan Admin Pengembang pulser_g2 untuk memberikan penjelasan lebih detail.

"Saat saya menulis ini, eksploitasi [Stagefright] akan dijelaskan di BlackHat [Tautan], meskipun belum ada slide atau rincian kertas putih yang tersedia.

Oleh karena itu saya memberikan penjelasan ini lebih sebagai gambaran kasar tentang apa yang sedang terjadi, daripada sebagai penjelasan yang sangat mendalam dengan akurasi penuh, dll.

Ada sejumlah bug berbeda yang membuat Stagefright, dan ini memiliki CVE-nya sendiri [Kerentanan & Eksposur Umum] nomor untuk pelacakan:

• CVE-2015-1538
• CVE-2015-1539
• CVE-2015-3824
• CVE-2015-3826
• CVE-2015-3827
• CVE-2015-3828
• CVE-2015-3829

Sayangnya patch yang tersedia tidak terhubung langsung ke setiap CVE (sebagaimana mestinya), jadi penjelasannya akan agak berantakan.

1. [CVE-2015-1538]

Dalam kode penanganan MPEG4, kode penanganan metadata 3GPP (hal-hal yang menjelaskan format dan info tambahan lainnya, ketika video dalam format 3GPP) bermasalah. Itu tidak menolak metadata, jika datanya terlalu besar, melainkan hanya memeriksa apakah datanya terlalu kecil. Artinya, penyerang dapat membuat file yang "dimodifikasi" atau "rusak", yang akan memiliki porsi metadata lebih panjang dari yang seharusnya.

Salah satu tantangan besar dalam menulis kode untuk menangani data "tidak tepercaya" (yaitu dari pengguna atau dari tempat lain di luar kode Anda) adalah menangani data dengan panjang variabel. Video adalah contoh sempurna untuk ini. Perangkat lunak perlu mengalokasikan memori secara dinamis, bergantung pada apa yang terjadi.

Dalam hal ini, buffer dibuat sebagai penunjuk ke beberapa memori, tetapi panjang array yang ditunjuknya adalah satu elemen yang terlalu pendek. Metadata kemudian dibaca ke dalam larik ini, dan entri terakhir dalam larik ini dapat dibuat bukan "null" (atau nol). Sangat penting bahwa item terakhir dalam array adalah nol, karena itulah cara perangkat lunak memberitahukan bahwa array telah selesai. Dengan dapat membuat nilai terakhir menjadi bukan nol (karena array berpotensi memiliki satu elemen yang terlalu kecil), kode berbahaya dapat dibaca oleh bagian kode lain, dan membaca terlalu banyak data. Daripada berhenti di akhir nilai ini, ia bisa terus membaca data lain yang tidak seharusnya dibaca.

(Ref: OmniROM Gerrit)

2. [CVE-2015-1539]

"Ukuran" metadata yang sesingkat mungkin harus 6 byte, karena itu adalah string UTF-16. Kode ini mengambil ukuran nilai bilangan bulat, dan mengurangi 6 darinya. Jika nilainya kurang dari 6, pengurangannya akan "mengalir" dan berputar-putar, dan kita akan mendapatkan angka yang sangat besar. Bayangkan jika Anda hanya bisa menghitung dari 0 hingga 65535, misalnya. Jika Anda mengambil angka 4, dan mengurangi 6, Anda tidak bisa berada di bawah nol. Jadi Anda kembali ke 65535 dan menghitung dari sana. Itulah yang terjadi di sini!

Jika panjang yang diterima kurang dari 6, hal ini dapat menyebabkan frame didekodekan secara salah, karena Proses byteswap menggunakan variabel len16 yang nilainya diperoleh dari perhitungan yang diawali dengan (ukuran-6). Hal ini dapat menyebabkan terjadinya operasi swap yang jauh lebih besar dari yang diharapkan, yang akan mengubah nilai dalam data frame dengan cara yang tidak terduga.

(Ref: OmniROM Gerrit)

3. [CVE-2015-3824]

Masalah besar! Yang ini jahat. Ada kebalikan dari masalah terakhir ini - integer overflow, di mana integer bisa menjadi "terlalu besar". Jika Anda mencapai 65535 (misalnya) dan tidak dapat menghitung lebih tinggi lagi, Anda akan berguling, dan selanjutnya menuju ke 0!

Jika Anda mengalokasikan memori berdasarkan ini (yang dilakukan Stagefright!), Anda akan mendapatkan terlalu sedikit memori yang dialokasikan dalam array. Ketika data dimasukkan ke dalamnya, hal ini berpotensi menimpa data yang tidak terkait dengan data yang dikontrol oleh pembuat file berbahaya.

(Ref: OmniROM Gerrit)

4. [CVE-2015-3826]

Satu lagi yang jahat! Sangat mirip dengan yang terakhir - integer overflow lainnya, di mana array (digunakan sebagai buffer) akan dibuat terlalu kecil. Hal ini akan memungkinkan memori yang tidak berhubungan untuk ditimpa, yang lagi-lagi buruk. Seseorang yang dapat menulis data ke dalam memori dapat merusak data lain yang tidak terkait, dan berpotensi menggunakannya agar beberapa kode yang mereka kendalikan dapat dijalankan oleh ponsel Anda.

(Ref: OmniROM Gerrit)

5. [CVE-2015-3827]

Sangat mirip dengan yang terakhir ini. Variabel digunakan ketika melewatkan beberapa memori, dan ini dapat dibuat negatif selama pengurangan (seperti di atas). Hal ini akan menghasilkan panjang "lewati" yang sangat besar, buffering meluap, memberikan akses ke memori yang tidak boleh diakses.

(Ref: OmniROM Gerrit)

Ada juga beberapa (kemungkinan) perbaikan terkait yang tampaknya telah berhasil diterapkan pada [Android] 5.1 juga.

(Ref: OmniROM Gerrit)

Ini menambahkan pemeriksaan untuk menghentikan masalah dengan perbaikan keamanan sebelumnya untuk menambahkan pemeriksaan batas, yang dapat meluap dengan sendirinya. Di C, angka yang dapat direpresentasikan sebagai int yang ditandatangani disimpan sebagai int yang ditandatangani. Jika tidak, mereka tetap tidak berubah selama pengoperasian. Dalam pemeriksaan ini, beberapa bilangan bulat bisa saja dibuat ditandatangani (daripada tidak ditandatangani), yang nantinya akan mengurangi nilai maksimumnya, dan memungkinkan terjadinya overflow.

(Ref: OmniROM Gerrit)

Beberapa lagi aliran bilangan bulat (dimana angka-angkanya terlalu rendah, dan kemudian pengurangan dilakukan pada angka-angka tersebut, sehingga angka-angka tersebut menjadi negatif). Hal ini sekali lagi mengarah pada jumlah yang besar, bukan jumlah yang kecil, dan hal ini menyebabkan masalah yang sama seperti di atas.

(Ref: OmniROM Gerrit)

Dan akhirnya, bilangan bulat lainnya meluap. Sama seperti sebelumnya, ini akan digunakan di tempat lain, dan bisa meluap.

(Ref: OmniROM Gerrit)"

Seberapa seriuskah Demam Panggung?

Sesuai dengan postingan blog diterbitkan oleh perusahaan riset induk, Zimperium Research Labs, eksploitasi Stagefright berpotensi terekspos 95% perangkat Android - sekitar 950 Juta - mengalami kerentanan ini karena memengaruhi perangkat yang menjalankan Android 2.2 dan ke atas. Lebih buruk lagi, perangkat sebelum Jelly Bean 4.3 berada pada “risiko terburuk” karena perangkat tersebut tidak memiliki mitigasi yang memadai terhadap eksploitasi ini.

Sehubungan dengan kerusakan yang dapat ditimbulkan oleh Stagefright, pulser_g2 berkomentar:

[blockquote author="pulser_g2"]"Dengan sendirinya, Stagefright akan memberikan akses kepada pengguna sistem di telepon. Anda harus melewati ASLR (pengacakan tata letak ruang alamat) untuk benar-benar menyalahgunakannya. Apakah hal ini telah tercapai atau tidak, masih belum diketahui saat ini. Eksploitasi ini memungkinkan "kode sewenang-wenang" dijalankan pada perangkat Anda sebagai pengguna sistem atau media. Mereka memiliki akses ke audio dan kamera pada perangkat, dan pengguna sistem adalah tempat yang tepat untuk meluncurkan eksploitasi root. Ingat semua eksploitasi root menakjubkan yang Anda gunakan untuk melakukan root pada ponsel Anda?

Itu berpotensi digunakan secara diam-diam untuk mendapatkan root pada perangkat Anda! Dia yang memiliki root memiliki telepon. Mereka harus melewati SELinux, tetapi TowelRoot berhasil melakukannya, dan PingPong juga berhasil. Setelah mereka mendapatkan root, semua yang ada di ponsel Anda terbuka untuk mereka. Pesan, kunci, dll."[/blockquote]Berbicara tentang skenario terburuk, hanya MMS yang diperlukan untuk mengirimkan kode dan memicu eksploitasi ini. Pengguna bahkan tidak perlu membuka pesannya karena banyak aplikasi perpesanan melakukan pra-proses MMS sebelum pengguna berinteraksi dengannya. Ini berbeda dengan serangan spear-phishing karena pengguna mungkin sama sekali tidak menyadari serangan yang berhasil, sehingga membahayakan semua data saat ini dan masa depan di telepon.

Apa yang membuat Stagefright berbeda dari “kerentanan besar” lainnya?

"Semua kerentanan menimbulkan risiko bagi pengguna. Yang ini sangat berisiko, karena jika seseorang menemukan cara untuk menyerangnya dari jarak jauh (yaitu mungkin, jika cara mengatasi ASLR ditemukan), hal ini dapat terpicu bahkan sebelum Anda menyadari bahwa Anda berada di bawah menyerang"

Eksploitasi lama seperti Android Installer Hijacking, FakeID serta eksploitasi root seperti TowelRoot dan PingPong memerlukan interaksi pengguna di beberapa titik agar dapat dieksekusi. Meskipun mereka masih merupakan “eksploitasi” dalam kenyataan bahwa banyak kerugian dapat timbul jika digunakan secara jahat, faktanya tetap saja Stagefright secara teoritis hanya membutuhkan nomor ponsel korban untuk mengubah ponsel mereka menjadi trojan dan karenanya mendapat banyak perhatian akhir-akhir ini. hari.

Android tidak sepenuhnya bergantung pada eksploitasi ini. Insinyur Utama Keamanan Android, Adrian Ludwig membahas beberapa kekhawatiran dalam a pos Google+:

[blockquote author="Adrian Ludwig"]"Ada asumsi umum yang keliru bahwa bug perangkat lunak apa pun dapat diubah menjadi eksploitasi keamanan. Faktanya, sebagian besar bug tidak dapat dieksploitasi dan ada banyak hal yang telah dilakukan Android untuk meningkatkan peluang tersebut...

Daftar beberapa teknologi yang telah diperkenalkan sejak Ice Cream Sandwich (Android 4.0) tercantum Di Sini. Yang paling terkenal disebut Pengacakan Tata Letak Ruang Alamat (ASLR), yang telah selesai sepenuhnya di Android 4.1 dengan dukungan untuk PIE (Position Independent Executables) dan kini ada di lebih dari 85% Android perangkat. Teknologi ini mempersulit penyerang untuk menebak lokasi kode, yang diperlukan agar mereka dapat membangun eksploitasi yang berhasil...

Kami tidak berhenti pada ASLR, kami juga menambahkan NX, FortifySource, Read-Only-Relocations, Stack Canaries, dan banyak lagi."[/blockquote]

Namun, tidak dapat disangkal bahwa Stagefright adalah masalah serius bagi masa depan Android, dan oleh karena itu hal ini ditanggapi dengan serius oleh para pemangku kepentingan yang terlibat. Stagefright juga menyoroti gajah putih di dalam ruangan - masalah fragmentasi dan pembaruan yang akhirnya sampai ke konsumen.

Dilema Pembaruan

Berbicara tentang pembaruan, ada baiknya melihat bahwa OEM bertanggung jawab atas keamanan pengguna, seperti yang dijanjikan banyak orang meningkatkan proses pembaruan khususnya untuk memasukkan perbaikan keamanan dan patch untuk eksploitasi seperti Stagefright.

Di antara yang pertama merilis pernyataan resmi, Google telah berjanji pembaruan keamanan bulanan (selain pembaruan OS dan platform yang direncanakan) untuk sebagian besar perangkat Nexus, termasuk Nexus 4 yang hampir berusia 3 tahun. Samsung juga mengikuti langkah tersebut dengan mengumumkan bahwa mereka akan bekerja sama dengan operator dan mitra untuk menerapkan a program pembaruan keamanan bulanan tetapi gagal menentukan rincian perangkat dan garis waktu implementasi ini. Hal ini menarik karena menyebutkan pendekatan “jalur cepat” terhadap pembaruan keamanan yang bekerja sama dengan operator, sehingga kami bisa melakukannya mengharapkan pembaruan yang lebih sering (walaupun berbasis keamanan, tapi mudah-mudahan ini juga akan mempercepat peningkatan firmware) pada operator perangkat.

OEM lain yang bergabung termasuk LG yang akan bergabung pembaruan keamanan bulanan. Motorola juga telah mengumumkan daftar perangkat yang akan diperbarui dengan perbaikan Stagefright, dan daftarnya mencakup hampir semua perangkat yang dibuat perusahaan sejak 2013. Sony juga mengatakan hal itu perangkatnya akan segera menerima patch tersebut juga.

Untuk kali ini, operator juga akan memberikan pembaruan. Sprint punya mengeluarkan pernyataan bahwa beberapa perangkat telah menerima patch Stagefright, dan lebih banyak perangkat dijadwalkan untuk pembaruan. AT&T juga mengikutinya dengan mengeluarkan patch ke beberapa perangkat. Verizon juga telah mengeluarkan tambalan, meskipun peluncurannya lambat dan memprioritaskan ponsel pintar kelas atas seperti Galaxy S6 Edge dan Note 4. T-Mobile Note 4 juga menerima pembaruan patch Stagefright.

Sebagai pengguna akhir, ada beberapa langkah pencegahan yang dapat diambil untuk mengurangi peluang Anda diserang. Sebagai permulaan, nonaktifkan pengambilan otomatis pesan MMS di aplikasi perpesanan yang ada di ponsel Anda. Hal ini akan mengendalikan kasus-kasus di mana tidak diperlukan interaksi pengguna agar eksploitasi dapat bekerja. Setelah ini, berhati-hatilah untuk menghindari mengunduh media dari pesan MMS dari sumber yang tidak dikenal dan tidak tepercaya.

Sebagai pengguna kuat XDA, Anda juga bisa edit prop build Anda untuk menonaktifkan Stagefright. Ini bukanlah cara yang lengkap dan pasti untuk menyelamatkan diri Anda dari Stagefright, namun Anda dapat memanfaatkan peluang ini untuk mengurangi kemungkinan serangan yang berhasil jika Anda terjebak pada versi Android yang lebih lama. Ada juga solusi ROM khusus, yang sebagian besar menyinkronkan sumber dengan AOSP secara teratur dan karenanya, akan menyertakan perbaikan Stagefright. Jika Anda menjalankan rom berbasis AOSP, sangat disarankan agar Anda memperbarui ke rilis ROM yang lebih baru yang menyertakan patch Stagefright. Anda dapat gunakan aplikasi ini untuk memeriksa apakah pengemudi harian Anda saat ini terpengaruh oleh Stagefright.

Android, Pasca Demam Panggung

Stagefright hanyalah peringatan terhadap Android dan masalah fragmentasi serta pembaruannya. Hal ini menyoroti bagaimana tidak adanya mekanisme yang jelas agar perbaikan penting tersebut dapat diterapkan secara tepat waktu pada banyak perangkat. Meskipun OEM sedang mencoba meluncurkan tambalan untuk perangkat, kenyataan pahitnya adalah sebagian besar perbaikan ini akan terbatas pada perangkat andalan terbaru saja. Perangkat non-unggulan dan lama lainnya, apalagi dari OEM yang lebih kecil akan terus terkena dampak seperti Stagefright.

Ada hikmahnya dalam eksploitasi ini: Hal ini menarik kembali perhatian atas proses pembaruan Android dan menyorotinya dalam pandangan yang tidak akan menarik banyak perusahaan di masa depan untuk mengadopsi Android untuk penggunaan perusahaan. Saat Google berupaya untuk mengadopsi lebih banyak perusahaan, Google akan terpaksa memikirkan kembali strategi pembaruannya dan jumlah kendali yang dapat diberikan kepada OEM.

Dengan Android M yang semakin dekat dengan peluncuran pasar dari hari ke hari, tidak mengherankan jika Google memilih untuk memisahkan lebih banyak komponen AOSP demi paket layanan Play-nya. Bagaimanapun, ini adalah salah satu area di mana Google masih memegang kendali penuh jika suatu perangkat dikirimkan bersama Google Play Store. Ini mempunyai kelemahan tersendiri berupa penggantian area open source dengan close source wall.

Saat berspekulasi tentang masa depan Android, ada kemungkinan (sangat kecil) bahwa Google juga membatasi perubahan yang dapat dilakukan OEM pada AOSP. Dengan kerangka RRO karena hadir dalam keadaan fungsional di Android M, Google dapat membatasi OEM untuk hanya melakukan perubahan kosmetik dalam bentuk skin RRO. Hal ini seharusnya memungkinkan penerapan pembaruan lebih cepat, namun akan mengakibatkan hilangnya kesempatan bagi OEM untuk sepenuhnya menyesuaikan Android.

Cara lain yang mungkin bisa dilakukan adalah menjadikannya wajib untuk semua perangkat yang dikirimkan Google Play Store menerima pembaruan keamanan yang terjamin untuk jangka waktu tertentu, mungkin dua bertahun-tahun. Kerangka Layanan Play dapat digunakan untuk memeriksa keberadaan pembaruan dan patch keamanan penting, dan akses Play Store akan dibatalkan jika terjadi ketidakpatuhan.

Catatan Penutup

Ini masih merupakan spekulasi karena tidak ada cara elegan untuk memperbaiki masalah ini. Selain pendekatan yang sangat totaliter, akan selalu ada kekurangan dalam upaya perbaikan. Karena banyaknya perangkat Android di luar sana, melacak status keamanan setiap perangkat akan menjadi tugas yang sangat besar. Kebutuhan saat ini adalah memikirkan kembali cara pembaruan Android karena cara saat ini tentu bukan yang terbaik. Kami di XDA Developers berharap Android tetap setia pada akar Sumber Terbuka sambil bekerja sama dengan rencana sumber tertutup Google.

Apakah ponsel Anda rentan terhadap Stagefright? Apakah menurut Anda ponsel Anda akan menerima patch Stagefright? Beri tahu kami di komentar di bawah!