Pendahuluan
Sebagian besar pengujian keamanan aplikasi mobile berfokus pada apa yang terjadi saat aplikasi berjalan: traffic yang dikirim, respons yang diterima, perilaku saat input dimanipulasi. Dynamic analysis memang penting, tapi ada kategori kerentanan yang tidak akan pernah terlihat dari sana karena tidak membutuhkan eksekusi untuk ditemukan.
Static analysis adalah pendekatan yang berbeda: kita membedah aplikasi tanpa menjalankannya, memeriksa kode, konfigurasi, dan resource yang tersimpan di dalam binary. Untuk aplikasi iOS, pendekatan ini memberikan visibilitas ke lapisan yang tidak terekspos ke permukaan.
Artikel ini membahas bagaimana static analysis dilakukan pada aplikasi iOS, apa yang bisa ditemukan, dan mengapa pendekatan ini seharusnya menjadi bagian awal dari setiap engagement mobile security.
Mengapa iOS Berbeda dari Android
Pada Android, APK adalah file ZIP yang bisa langsung di-extract dan source code bisa di-decompile ke Java atau Kotlin dengan cukup baik menggunakan tools seperti jadx. Barrier-nya rendah.
Pada iOS, aplikasi didistribusikan dalam format IPA yang terenkripsi melalui App Store. Untuk menganalisis binary-nya secara static, kita perlu bekerja dengan Mach-O binary, format executable yang digunakan Apple. Tanpa langkah dekripsi terlebih dahulu, yang kita pegang hanyalah binary yang terenkripsi.
Ini bukan berarti iOS lebih aman dari sisi static analysis. Artinya prosesnya berbeda, dan tools yang digunakan pun berbeda.
Langkah Awal: Mendapatkan Binary yang Bisa Dianalisis
Untuk aplikasi yang diinstall dari App Store pada device yang sudah di-jailbreak, proses dekripsi binary bisa dilakukan menggunakan tools seperti frida-ios-dump atau Clutch. Hasilnya adalah IPA yang sudah terdekripsi dan siap dianalisis.
Untuk aplikasi enterprise atau aplikasi yang didapatkan langsung dari client dalam bentuk IPA (yang umum dalam konteks pentest), proses ini bisa dilewati karena binary biasanya belum dienkripsi untuk distribusi App Store.
Dalam praktiknya, workflow yang biasa penulis jalankan pada tahap ini dimulai dari jailbreak terhadap device pengujian, dilanjutkan dengan dekripsi binary aplikasi yang menjadi target. Binary hasil dekripsi kemudian dipindahkan ke mesin lokal melalui scp, sebelum akhirnya diunggah ke Ghidra dan/atau MobSF untuk dianalisis lebih lanjut. Untuk proses dekripsi binary itu sendiri, TrollStore dan DumpDecrypter adalah dua tools yang paling sering digunakan penulis dalam engagement semacam ini.
Apa yang Dicari dalam Static Analysis
1. Secrets dan Credential yang Hardcoded
Ini adalah temuan yang paling sering muncul dan paling langsung berdampak. Developer kadang meninggalkan API key, token akses, credential database, atau bahkan password dalam kode atau file konfigurasi yang dibundle bersama aplikasi.
Pada binary iOS, pencarian ini bisa dilakukan dengan beberapa pendekatan: strings extraction dari binary untuk mencari pola yang terlihat seperti credential, analisis file yang di-bundle dalam direktori aplikasi (plist, json, sqlite), dan analisis Mach-O binary menggunakan tools seperti otool atau nm untuk melihat simbol dan string yang tersimpan.
Sebagai gambaran dari engagement nyata (dianonimkan), salah satu temuan yang pernah didapati penulis adalah Google API key yang dikonfigurasi terlalu longgar (misconfigured atau permissive) dan tertanam langsung dalam aplikasi. Jika kredensial semacam ini jatuh ke tangan attacker, risiko utamanya adalah penyalahgunaan layanan Google Maps atas nama aplikasi tersebut, yang berpotensi menimbulkan kerugian finansial bagi pemilik aplikasi akibat biaya penggunaan API yang membengkak di luar kendali.
2. Konfigurasi Transport Security yang Lemah
iOS memiliki mekanisme App Transport Security (ATS) yang secara default memaksa koneksi HTTPS dengan standar tertentu. Dalam static analysis, kita bisa memeriksa file Info.plist untuk melihat apakah developer telah melemahkan atau menonaktifkan ATS.
Konfigurasi yang sering ditemukan bermasalah antara lain pengecualian domain yang terlalu luas, penggunaan NSAllowsArbitraryLoads yang menonaktifkan ATS sepenuhnya, atau pengecualian yang dibuat untuk domain third-party yang tidak diaudit keamanannya.
3. Penggunaan API yang Tidak Aman
Binary iOS berisi daftar simbol yang merujuk ke framework dan function yang digunakan. Dari sini, kita bisa mengidentifikasi penggunaan API yang sudah deprecated karena alasan keamanan atau API yang penggunaannya membutuhkan perhatian khusus.
Misalnya, penggunaan UIPasteboard yang tidak dibatasi bisa menyebabkan data sensitif tersalin ke clipboard sistem dan dapat dibaca aplikasi lain. Penggunaan NSUserDefaults untuk menyimpan data yang seharusnya di Keychain adalah kerentanan yang sering ditemukan tapi sering dianggap minor padahal dampaknya bisa signifikan.
4. Analisis Entitlement dan Permission
Setiap aplikasi iOS memiliki entitlement yang mendefinisikan kapabilitas dan akses yang dimilikinya: akses ke Keychain, push notification, iCloud, dan sebagainya. Dalam static analysis, kita memeriksa apakah entitlement yang diminta sesuai dengan fungsi aplikasi.
Aplikasi yang meminta akses lebih dari yang dibutuhkan, atau yang memiliki entitlement yang tidak konsisten dengan fungsinya, patut diperiksa lebih lanjut. Ini bukan selalu kerentanan langsung, tapi bisa menjadi indikator desain yang tidak mengikuti prinsip least privilege.
5. Implementasi Keychain yang Tidak Tepat
Keychain adalah mekanisme penyimpanan credential yang direkomendasikan Apple untuk iOS. Tapi cara Keychain diimplementasikan sangat mempengaruhi keamanannya. Dalam static analysis, kita bisa memeriksa parameter kAccessibility yang digunakan: apakah data hanya bisa diakses saat device unlocked, atau bisa diakses kapan saja termasuk saat backup?
Data Keychain dengan accessibility kSecAttrAccessibleAlways atau kSecAttrAccessibleAlwaysThisDeviceOnly bisa diakses bahkan saat device terkunci, yang meningkatkan risiko jika device jatuh ke tangan yang salah.
Tools yang Umum Digunakan
Beberapa tools yang paling sering digunakan dalam static analysis aplikasi iOS antara lain:
MobSF (Mobile Security Framework) menyediakan analisis otomatis yang komprehensif untuk IPA, mencakup pemeriksaan Info.plist, binary analysis, dan identifikasi pola kerentanan umum. Cocok untuk initial scan sebelum analisis manual.
otool dan nm adalah tools bawaan macOS untuk analisis Mach-O binary. otool digunakan untuk memeriksa load commands, sections, dan strings; nm untuk melihat symbol table.
Hopper Disassembler atau IDA Pro digunakan untuk analisis yang lebih dalam ketika kita perlu memahami logika kode, bukan hanya string dan simbol yang tersimpan.
class-dump untuk mengekstrak informasi class, method, dan properti dari Objective-C binary, memberikan gambaran arsitektur kode tanpa harus membaca assembly.
Di luar keempat tools tersebut, dua tools lain yang juga sering digunakan penulis dalam engagement adalah Ghidra, untuk analisis disassembly yang lebih mendalam, dan lief, sebuah library yang digunakan untuk parsing dan manipulasi Mach-O binary secara terprogram.
Keterbatasan Static Analysis dan Kapan Harus Beralih ke Dynamic
Static analysis memiliki keterbatasan yang penting untuk dipahami. Obfuscation kode yang agresif bisa membuat analisis binary menjadi jauh lebih sulit. Kerentanan yang bergantung pada kondisi runtime, seperti race condition atau state yang bergantung pada input pengguna, tidak akan terlihat dari static analysis.
Karena itu, static analysis selalu menjadi awal dari engagement, bukan satu-satunya pendekatan. Temuan dari static analysis memberikan hipotesis yang kemudian diverifikasi dan diperdalam melalui dynamic analysis.
Kombinasi keduanya memberikan coverage yang jauh lebih komprehensif dibanding salah satunya saja.
Implikasi untuk Tim Development
Banyak kerentanan yang ditemukan dalam static analysis bisa dicegah dengan praktik development yang tepat sejak awal:
Jangan pernah hardcode credential dalam kode atau file konfigurasi. Gunakan environment variable atau layanan secrets management yang terpisah dari binary aplikasi.
Audit entitlement dan permission secara berkala. Pastikan setiap permission yang diminta memiliki justifikasi yang jelas dan digunakan secara konsisten.
Gunakan Keychain dengan parameter accessibility yang paling ketat yang memungkinkan. Jangan menggunakan accessibility yang lebih longgar dari yang benar-benar dibutuhkan.
Tinjau konfigurasi ATS sebelum rilis. Setiap pengecualian yang ditambahkan harus memiliki justifikasi yang terdokumentasi dan diaudit secara berkala.
Kesimpulan
Static analysis adalah langkah yang sering dilewati dalam pengujian keamanan aplikasi mobile karena hasilnya tidak sevisual dynamic analysis. Tidak ada request yang diintersepsi, tidak ada response yang dimanipulasi. Tapi kerentanan yang ditemukan di lapisan ini sering kali adalah yang paling fundamental dan paling sulit diperbaiki setelah aplikasi sudah di-deploy.
Menemukan API key yang hardcoded atau Keychain yang salah dikonfigurasi jauh lebih mudah dan murah sebelum aplikasi live dibanding sesudahnya.
Jika Anda ingin memastikan aplikasi iOS perusahaan Anda aman dari lapisan yang paling dalam, tim Security Squad LOGIQUE siap membantu.
