Artikel ini membahas bagaimana perangkat iOS dibuat untuk menahan jenis serangan.
Mengurangi daerah serangan
Apple telah mengurangi daerah yang berpotensi menjadi titik serangan pada iOS dibandingkan dengan Mac OS X (dan platform lain) sebisa mungkin. Sebagai contoh, suka atau tidak, Java dan Flash tidak tersedia di iOS. Kedua aplikasi tersebut memiliki sejarah kerentanan keamanan, dan dengan tidak memasukkannya ke iOS itu membuat penyerang semakin sulit menemukan celah keamanan yang bisa dimanfaatkan. Demikian pula dengan iOS yang tidak akan memproses beberapa jenis file, tetapi Mac OS X akan memprosesnya. Satu contoh adalah file .PSD. Jenis file ini bisa ditangani di Safari tetapi tidak pada MobileSafari.
Pengurangan fitur iOS
Selain mengurangi kode potensial yang mungkin saja bisa dieksploitasi oleh penyerang, Apple juga mengurangi jumlah aplikasi yang mungkin bisa digunakan oleh penyerang pada saat proses eksploitasi. Contoh yang paling nyata adalah tidak adanya shell (/bin/sh) di iOS. Karena tidak adanya shell di iOS, seseorang harus mengembangkannya untuk keperluan exploit iOS. Namun, bahkan jika terdapat shell di iOS, itu tidak akan cukup berguna karena penyerang tidak akan bisa menjalankan utiliti lain dari shell, misalnya rm, ls, ps dan lainnya.
Pemisahan hak/wewenang
iOS memisahkan setiap process dengan menggunakan user, group dan mekanisme perizinan file UNIX lainnya. Sebagai contoh, banyak aplikasi di mana pengguna memiliki hak akses langsung, seperti web browser, mail client, atau aplikasi-aplikasi pihak ketiga. Proses-proses penting dijalankan dengan hak akses root. Dengan menggunakan model seperti ini, seorang penyerang yang mendapatkan kontrol penuh dari sebuah proses seperti web browser akan dibatasi oleh fakta bahwa kode yang ia eksekusi akan berjalan sebagai user mobile. Ada batasan terhadap apa yang bisa dikerjakan oleh sebuah exploit; sebagai contoh, exploit tidak akan mampu membuat sebuah konfigurasi pada tingkat sistem. Demikian pula, aplikasi dari App Store terbatas terhadap apa yang bisa dilakukannya karena aplikasi-aplikasi tersebut dijalankan sebagai user mobile juga.
Code Signing (Penandatanganan Kode)
Salah satu mekanisme keamaman yang terpenting pada iOS adalah code signing. Semua binari dan library harus ditandatangani oleh otoritas terpercaya (seperti Apple) sebelum kernel memperbolehkannya untuk dieksekusi. Selain itu, hanya halaman dalam memori yang telah ditandatangani saja yang akan dieksekusi. Ini artinya, aplikasi tidak bisa mengubah perilakunya secara dinamis atau meng-upgrade dirinya sendiri. Bersama-sama, tindakan ini mencegah pengguna dalam men-download dan mengeksekusi file acak dari Internet.
Semua aplikasi harus berasal dari App Store. Apple memiliki persetujuan akhir dan akan memeriksa aplikasi-aplikasi sebelum aplikasi tersebut diluncurkan ke App Store. Dengan begini, Apple memainkan perannya sebagai antivirus untuk perangkat iOS/iPadOS. Apple akan memeriksa setiap aplikasi dan menentukan apakah aplikasi tersebut aman atau tidak untuk dijalankan pada perangkat iOS/iPadOS. Proteksi ini membuat perangkat iOS/iPadOS sangat sulit untuk terinfeksi malware. Dan kenyataannya, hanya sedikit malware yang pernah ditemukan di iOS/iPadOS.
Dampak lain dari code signing ini adalah membuat proses eksploitasi semakin kompleks. Setelah sebuah exploit dieksekusi dalam memory, exploit ini mungkin akan men-download, meng-install atau mengeksekusi aplikasi jahat lainnya. Ini akan ditolak karena apapun yang tidak ditandatangani tidak akan diproses.
Proteksi code signing adalah salah satu orang melakukan jailbreak pada perangkat iOS mereka. Setelah sebuah perangkat di-jailbreak, aplikasi yang tidak ditandatangani (bajakan, dll) akan bisa dijalankan.
Data Execution Prevention (Pencegahan eksekusi data)
Normalnya, DEP adalah mekanisme di mana prosesor dapat membedakan mana bagian dari memori yang merupakan kode yang dapat dieksekusi dan mana yang merupakan data. DEP tidak mengijinkan pengeksekusian data, hanya boleh kode. Ini penting karena ketika sebuah exploit mencoba menjalankan sebuah payload (bagian dari data) exploit ini akan meng-inject payload kedalam process dan mengeksekusinya. DEP akan membuat proses ini mustahil karena payload akan dikenali sebagai data dan bukan kode.
Mekanisme code-signing pada iOS bertingkah seperti DEP tetapi lebih kuat lagi. Serangan khas terhadap DEP yang diaktifkan adalah menggunakan ROP untuk membuat sebuah bagian dari memori yang dapat di baca-tulis dan bisa dieksekusi. Penyerang bisa menulisi payload mereka dan mengeksekusinya. Namun, code signing mengharuskan tidak boleh ada halaman yang dieksekusi kecuali bersumber dari kode yang ditandatangani oleh otoritas terpercaya. Oleh karena itu, ketika ROP berjalan di iOS, DEP tidak dapat dimatikan sebagaimana yang akan dilakukan oleh penyerang. Menulis payload yang besar di ROP memakan banyak waktu dan rumit. Ini membuat eksploitasi iOS lebih sulit dibanding platform lainnya.
Address Space Layout Randomization (ASLR)
Cara seorang penyerang untuk melewati DEP adalah dengan menggunakan kembali potongan-potongan kode (ROP). Namun, untuk melakukan ini, penyerang perlu mengetahui di mana lokasi dari segmen kode yang ingin digunakan kembali. ASLR membuat proses ini menjadi sulit dengan mengacak lokasi dari objek yang berada dalam memori. Pada iOS, lokasi dari binari, library, dan tumpukan semuanya diacak. Ketika sistem telah memiliki DEP dan ASLR, tidak ada lagi cara umum untuk mengeksploitasinya. Dalam prakteknya, ini biasanya berarti penyerang membutuhkan dua kerentanan keamanan. Satu untuk mendapatkan kode eksekusi dan satu untuk membocorkan alamat memori agar dapat mengerjakan ROP.
Sandboxing
Pertahanan terakhir dari iOS adalah sanboxing. Sanboxing memungkinkan kontrol yang lebih ketat terhadap process yang berjalan berdasarkan sistem perijinan pada UNIX. Sebagai contoh, baik aplikasi SMS dan web browser berjalan sebagai user mobile, tetapi bekerja dengan teknik yang berbeda. Aplikais SMS pastinya tidak membutuhkan akses ke cookies yang terdapat pada web browser dan web browser tidak membutuhkan akses untuk membaca pesan teks Anda. Aplikasi pihak ketiga dari App Store pun seharusnya tidak memiliki akses ke salah satu aplikasi (web browser/SMS) ini. Sandboxing memecahkan masalah ini dengan mengijinkan Apple untuk menentukan izin apa saja yang diperlukan untuk menjalankan aplikasi.
Sandboxing memiliki dua efek. Yang pertama, membatasi kerusakan yang disebabkan oleh malware terhadap perangkat. Jika seandainya ada sepotong malware yang mampu menyusup ke bagian proses review App Store dan men-download aplikasi dari sana lalu mengeksekusinya dari perangkat iOS, aplikasi tersebut masih dibatasi oleh proses sandbox. Malware ini mungkin saja bisa mencuri foto-foto Anda tetapi sudah pasti tidak dapat mengirim pesan atau menelepon secara acak yang bisa membuat kerugian yang lebih besar.
Sandboxing juga membuat eksploitasi semakin sulit. Jika seorang penyerang menemukan kerentanan keamanan, berhasil mengeksekusi kode walaupun sempat dihadang ALSR dan DEP, dan mampu menulis payload pada ROP, payload ini masih akan tetap dibatasi di dalam sandbox.