Dalam postingan blog Project Zero terbaru, tim telah menemukan cara untuk melewati perlindungan kernel real-time Samsung, yang disebut Knox Hypervisor.
Tim Project Zero Google telah memverifikasi sejumlah eksploitasi yang memungkinkan ponsel Samsung yang menjalankan rangkaian keamanan Samsung Knox yang seharusnya aman dapat diserang. Blog tersebut mencatat bahwa semua kerentanan telah diteruskan ke Samsung yang sebenarnya telah merilis perbaikan untuk kerentanan tersebut pada pembaruan perangkat lunak bulan Januari.
Latar belakang
Sebagai bagian dari rangkaian perangkat lunak keamanan Samsung Knox yang diperkenalkan oleh Samsung, terdapat perangkat lunak yang berada di antara aplikasi Android dan kernel yang disebut a hipervisor. Ini dapat digunakan sebagai lapisan tambahan untuk lebih mengamankan perangkat Android. Samsung Knox Hypervisor disebut "Perlindungan Kernel Waktu Nyataatau disingkat RKP yang akan saya rujuk pada sisa artikel ini.
Kernel berada di bawah RKP dalam tumpukan perangkat lunak Android, dan aplikasi yang berjalan pada perangkat berada di urutan teratas. Ide di balik RKP adalah untuk memberikan lapisan keamanan ekstra untuk perangkat karena semua permintaan (memori dan sumber daya lainnya) dibuat oleh aplikasi ke Kernel harus melalui Knox terlebih dahulu, yang mencoba mendeteksi apakah suatu aplikasi sedang melakukan sesuatu tidak seharusnya. RKP juga memberikan keamanan melalui ketidakjelasan dengan lapisan tambahan untuk menyembunyikan informasi sensitif yang dapat digunakan aplikasi untuk menyusupi perangkat.
Posting blog ini membahas secara mendalam cara kerja memori Android, RKP, dan Sistem Operasi secara umum, jadi saya telah memadatkan dan menyederhanakannya untuk memberikan gambaran singkat tentang apa yang ditemukan. Saya mendorong Anda untuk membaca artikel selengkapnya jika Anda punya waktu, karena artikel ini sangat mencerahkan.
Eksploitasi #1:
KASLR atau Pengacakan Tata Letak Ruang Alamat Kernel adalah proses mengubah lokasi kode kernel di memori dengan jumlah acak pada saat boot. Setiap kali perangkat di-boot, kernel dimuat ke ruang alamat yang berbeda (area di memori). Idenya adalah untuk mempersulit pencarian lokasi kode kernel agar dapat menyerangnya karena setiap kali boot, kode kernel "bergeser" dalam jumlah acak di memori. Ini sepertinya merupakan langkah bagus untuk mencegah calon penyerang, tetapi baru-baru ini riset telah menunjukkan bahwa Anda sebenarnya dapat mengatasi masalah ini tanpa memerlukan bug atau kerentanan perangkat lunak, karena KASLR sebenarnya sangat sulit untuk diterapkan dengan cara yang kuat terhadap penyerang lokal.
Dalam kasus software RKP, kemampuan bypass KASLR sebenarnya lebih sederhana dibandingkan penelitian yang dirujuk di atas. Memori semua perangkat Android direferensikan oleh pointer dan untuk melindungi perangkat dari serangan, kapan pun perangkat Android mencetak atau mengeluarkan (baik untuk menyaring atau untuk mengajukan log atau debugging), referensi pointer dianonimkan, - sehingga tidak mungkin untuk mengetahui ke mana sebenarnya pointer menunjuk ketika membaca keluaran.
Pikirkan penunjuk memori seperti tanda jalan yang menunjuk ke suatu lokasi dan anggap anonim sebagai mengaburkannya. Sama seperti televisi, penganoniman dilakukan setelah pembuatan film, Android juga menerapkan penganoniman ini pada waktu keluaran dan hanya jika penganoniman dikonfigurasi dengan benar, dan penulis menyatakan bahwa setiap perangkat yang ia temui memiliki penunjuk anonim yang dikonfigurasi dengan benar. Ini mungkin terdengar sangat sulit untuk dipecahkan, namun yang perlu Anda lakukan hanyalah menemukan satu penunjuk (pikirkan rambu jalan) yang tidak dianonimkan (diburamkan) oleh pengembang kernel (berhati-hatilah karena ini bukan pengembang aplikasi Android rata-rata) ketika penunjuk ditulis ke log atau lokasi lain, misalnya. layar atau a mengajukan.
Jadi, jika Anda dapat menemukan penunjuk yang tidak dianonimkan, Anda dapat menghitung perpindahan alamat acak kernel sebagai selisih di antara keduanya. Menariknya penulis tidak dapat menemukan pointer yang dapat dieksploitasi di kernel tetapi menemukannya di dalam RPK di mana pengembang lupa menganonimkan penunjuk dalam keluaran debug (logging), yang muncul melalui a salah ketik. Untuk menganonimkan pointer di Android Anda harus menggunakan kode khusus dan ternyata pengembang RPK salah menggunakan a huruf kecil 'k' bukannya sebuah huruf besar 'K'. Oleh karena itu relatif mudah untuk mengetahui jumlah pergeseran acak dari kode kernel dan menyerangnya.
Eksploitasi #2:
Eksploitasi berikutnya sedikit lebih kompleks: Samsung Knox melindungi perangkat Anda dengan menerapkan serangkaian aturan pada memori perangkat untuk menghentikan kode berbahaya. Aturannya adalah sebagai berikut:
- Semua halaman (kode di memori), kecuali kode kernel, ditandai sebagai "Privileged Execute Never" (artinya kode di sini tidak akan pernah bisa dijalankan)
- Halaman data kernel (data yang digunakan program di memori) tidak pernah ditandai sebagai executable (jadi kode di sini tidak akan pernah bisa dijalankan)
- Halaman kode kernel (kode dalam memori) tidak pernah ditandai dapat ditulis (jadi tidak ada kode berbahaya yang dapat mengubahnya)
- Semua halaman kernel ditandai sebagai read-only pada tabel terjemahan tahap 2 (tabel yang berada di antara aplikasi dan kernel untuk mencegah aplikasi mengetahui lokasi memori sebenarnya)
- Semua entri terjemahan memori ditandai sebagai hanya-baca untuk aplikasi.
Kami akan fokus pada aturan 3 karena di sinilah penulis menemukan masalah dalam penerapan aturan di atas. RPK sebenarnya menandai memori untuk kernel sebagai hanya-baca, namun karena kelalaian terhadap KASL, sebuah lubang ditemukan, yang menyebabkan menulis kode ke bagian yang seharusnya "hanya-baca".. Untuk mengaburkan lokasi kernel pada saat boot, memori dialokasikan ke kernel, namun jumlah memori ini jauh lebih besar daripada segmen teks kernel. Dengan mengalokasikan jumlah memori yang lebih besar, akan lebih sulit untuk menemukan kode kernel sebenarnya yang dapat ditemukan di mana saja, dan seperti yang kita lihat di atas, kode tersebut dipindahkan secara acak pada setiap boot perangkat.
Penulis dapat memastikan bahwa memori yang digunakan oleh kernel memang ditandai sebagai "read-only", namun sisa memori dalam jumlah besar yang digunakan untuk menyembunyikan kernel adalah bukan ditandai sebagai "hanya-baca". Hal ini karena RKP hanya melindungi wilayah yang berisi teks kernel setelah menerapkan slide KASLR.
Eksploitasi #3
Pada eksploitasi ketiga, penulis dapat mengakses area memori lain yang juga harus dibatasi hanya untuk dibaca. RKP melindungi memori dan menggunakan a Daftar Konfigurasi Hypervisor (HCR) untuk mengontrol operasi kernel utama. Inti dari HCR adalah untuk memungkinkan operasi kernel yang valid dan nyata mengakses register dan memblokir serangan jahat. Hal ini dilakukan dengan memeriksa panggilan yang dibuat ke register yang mengatur fitur virtualisasi. HCR dikonfigurasi untuk memblokir operasi tertentu yang biasanya ditangani sehingga memungkinkan RKP memilih apakah akan mengizinkan atau menolak permintaan.
Dalam eksploitasi ini kontrol HCR berada tidak mencakup dua register itu ternyata sangat penting. Penulis menggali jauh ke dalam manual Referensi ARM dan menemukan bahwa register pertama memungkinkan dia mematikan RKP untuk aplikasi. "Register Kontrol Sistem untuk EL1 (SCTLR_EL1) menyediakan kontrol tingkat atas atas sistem, termasuk sistem memori." Dalam dunia yang sempurna, aplikasi akan menggunakan memori yang dipetakan melalui RKP sehingga RKP dapat mengontrol apa yang dapat diakses oleh aplikasi. Namun, mematikan register ini mengizinkan RKP untuk dinonaktifkan dengan secara efektif mengembalikan perangkat ke keadaan semula sebelum RKP diinstal - artinya perangkat dipetakan ke memori fisik tanpa keamanan tambahan yang disediakan oleh RKP. Hal ini berarti penulis dapat membaca dan menulis ke memori yang aslinya dan diblokir dengan benar oleh perangkat lunak RKP.
Register kedua yang terlewat mempunyai dampak yang lebih halus, namun pada akhirnya sama buruknya terhadap keamanan. Itu Kontrol Terjemahan Daftar untuk EL1 (TCR_EL1) register berhubungan langsung dengan jumlah memori tempat aplikasi bekerja yang disebut halaman. RKP di-hardcode ke ukuran halaman 4kb karena kernel Linux AARCH64 (seperti Android) menggunakan ukuran terjemahan 4KB. Register yang dimaksud (TCR_EL1) menyetel chipset ARM ke ukuran memori yang akan dikembalikan. Ternyata itu register ini tidak dilindungi oleh HCR dan oleh karena itu penyerang dapat mengubahnya seperti pembuatnya mengubahnya menjadi ukuran halaman 64kb.
Artinya, ketika permintaan dipenuhi oleh RKP, jumlah sebenarnya memori yang dapat diakses kini menjadi 64kb, bukan 4kb. Alasannya adalah chipset ARM masih mengontrol ukuran halaman dan disetel ke 64kb karena eksploitasi. Karena RKP melindungi memori agar tidak ditulisi, sebagai bagian dari aturan yang tercantum dalam eksploitasi #2, memori sebenarnya masih terlindungi. Tapi inilah masalahnya - karena RKP di-hardcode menjadi 4kb, maka ukuran halamannya tidak berubah menjadi 64kb ketika register diperbarui, jadi hanya memori 4kb pertama yang dilindungi memungkinkan penyerang melakukannya apapun yang dia inginkan dengan sisa 60kb.
Eksploitasi #4
Eksploitasi terakhir yang penulis tunjukkan adalah mereferensikan memori di mana software RKP berada, sehingga penyerang dapat menyerang software RKP itu sendiri. Salah satu trik untuk menghentikan jenis serangan yang juga digunakan oleh kernel Linux adalah dengan menghapus peta program Anda dari ruang alamat memori virtual sehingga tidak ada aplikasi yang dapat menyerangnya karena mereka tidak dapat mereferensikannya.
Ingatlah bahwa memori adalah tentang pointer dan tabel yang memetakan memori fisik ke memori virtual. Sesuai pertahanan normal dalam jenis serangan ini, RKP membuka peta dirinya sendiri sehingga tidak dapat diserang. Namun, jika kernel tidak menyediakan kemampuan tersebut, RKP mengizinkan sepotong memori untuk dipetakan dan ditandai sebagai Baca/Tulis. Satu-satunya pemeriksaan adalah bahwa itu bukan kernel yang mendasarinya karena RKP tidak melakukan pemeriksaan untuk melihat apakah alamat yang diminta untuk dipetakan adalah area di mana RKP itu sendiri berada di memori. Pada dasarnya RKP memungkinkan dirinya untuk dipetakan ulang kembali ke ruang alamat yang dapat diakses aplikasi dan sebagai dampak samping memori secara otomatis ditandai sebagai Baca/Tulis jadi penyerang sekarang dapat menggunakan memori tersebut sesuai keinginannya.
Kesimpulan
Salah satu masalah terbesar dengan empat eksploitasi yang tercantum di atas adalah penulis menyebutkan betapa sulitnya melakukan eksploitasi karena kurangnya fungsi pada kernel dasar Android. Ironisnya, RKP Hypervisor yang aman menyediakan semua alat yang diperlukan untuk melakukan serangan. Hal ini menunjukkan bahwa terkadang perangkat lunak yang bermaksud baik menyebabkan lebih banyak masalah daripada menyelesaikannya dan kami beruntung memiliki orang-orang seperti Gal Beniamini yang rela mengotori tangan mereka dan menguji apakah dokumentasinya sesuai dengan perangkat lunak yang sebenarnya melakukan.
Meskipun eksploitasi ini tampak menakutkan dan membuat Knox terdengar sangat rentan, saya ingin meyakinkan semua orang bahwa semua masalah ini telah terjadi. diperbaiki dalam pembaruan bulan Januari dari Samsung. Selain itu, eksploitasi ini memerlukan pemahaman mendalam tentang prosesor dan pemrograman ARM, sehingga hambatan untuk menggunakan eksploitasi ini sangat tinggi.
Sumber: Proyek Nol