Pendahuluan
Aplikasi e-money adalah salah satu target paling menarik bagi attacker. Di satu sisi, aplikasi ini memproses transaksi keuangan secara real-time dan menyimpan informasi sensitif pengguna di perangkat. Di sisi lain, tekanan bisnis untuk rilis cepat dan pengalaman pengguna yang mulus sering kali membuat aspek keamanan tidak mendapat perhatian yang cukup sejak awal.
Dalam salah satu engagement penetration testing yang kami lakukan pada aplikasi e-money berbasis Android di Indonesia, kami menemukan pola kerentanan yang tidak lazim ditemukan dalam checklist pengujian standar: celah pada mekanisme komunikasi antar-komponen di sisi client. Bukan kerentanan jaringan, bukan pula broken API — melainkan cara komponen-komponen dalam aplikasi itu sendiri saling berinteraksi yang membuka celah eksploitasi serius.
Artikel ini membahas dua kerentanan spesifik yang kami temukan, bagaimana keduanya dieksploitasi dalam kondisi nyata, dan apa yang bisa dilakukan untuk mencegahnya.
Konteks Regulasi: Mengapa Ini Bukan Sekadar Masalah Teknis
Sebelum masuk ke temuan teknis, penting untuk memahami konteks regulasi yang melingkupi industri keuangan digital di Indonesia. OJK melalui berbagai POJK dan SEOJK mewajibkan penyelenggara e-money untuk melakukan pengujian keamanan secara berkala, termasuk penetration testing pada aplikasi yang digunakan nasabah.
UU PDP (UU No. 27 Tahun 2022) menambahkan lapisan kewajiban lain: pelanggaran data pengguna bukan lagi sekadar risiko reputasi, tapi berpotensi membawa sanksi hukum yang signifikan.
Artinya, kerentanan yang ditemukan dalam pengujian bukan hanya masalah teknis yang perlu diperbaiki, tapi juga potensi celah compliance yang harus didokumentasikan dan ditangani secara formal. Yang membuat temuan dalam artikel ini semakin relevan: kedua kerentanan yang dibahas tidak memerlukan perangkat yang di-root untuk dieksploitasi, sehingga tingkat risikonya lebih tinggi dalam skenario produksi nyata.
Kerentanan yang Ditemukan
1. Direct Return of Intent Result pada Exported Component
Analisis statis terhadap manifest file aplikasi mengungkap sebuah Activity yang dikonfigurasi sebagai exported, artinya komponen ini dapat dipanggil oleh aplikasi pihak ketiga mana pun yang terinstal di perangkat yang sama.
Setelah mendecompile APK menggunakan JADX, kami menemukan bahwa Activity tersebut memiliki callback onComplete() yang langsung mengembalikan data intent yang diterima dari komponen pemanggil melalui metode setResult() — tanpa validasi atau sanitasi apapun terhadap data yang masuk.
Dalam fase eksploitasi, kami membangun aplikasi Android berbahaya yang mengirimkan explicit intent ke Activity target, menyertakan URI menuju file internal aplikasi e-money melalui content provider-nya, sekaligus menambahkan flag FLAG_GRANT_READ_URI_PERMISSION. Karena intent ini dikembalikan langsung dari konteks aplikasi target, sistem Android mengizinkan akses sementara ke file tersebut sebagaimana diminta.
Hasilnya: aplikasi berbahaya kami berhasil membaca konten file yang tersimpan di direktori sandboxed aplikasi e-money — termasuk file yang berpotensi menyimpan riwayat OTP akun yang sedang login.
Mitigasi: Sanitasi data intent yang diterima dari komponen pemanggil sebelum dikembalikan via setResult(), misalnya dengan menghapus URI permission flag menggunakan removeFlags() atau mereset flag intent ke 0. Selain itu, komponen yang tidak perlu berinteraksi dengan aplikasi pihak ketiga sebaiknya tidak dikonfigurasi sebagai exported.
2. Mutable Pending Intent
Kerentanan kedua ditemukan pada metode sendIntentToWhatsApp() dalam kode aplikasi. Aplikasi mengirimkan pending intent dengan flag bernilai 0 (kosong) yang membungkus base intent kosong ke aplikasi WhatsApp dan WhatsApp for Business melalui broadcast intent.
Pending intent dengan konfigurasi ini bersifat mutable pada perangkat Android dengan versi SDK di bawah 31 (Android < 12) — artinya aplikasi penerima dapat memodifikasi isi intent tersebut sebelum menggunakannya.
Dalam fase eksploitasi, kami membangun aplikasi trojan yang berpura-pura menjadi WhatsApp dengan menggunakan package name yang identik (com.whatsapp). Broadcast receiver pada trojan kami dikonfigurasi dengan prioritas tertinggi (999) sehingga selalu menangani broadcast lebih awal dibanding aplikasi non-privileged lainnya.
Setelah pending intent diterima, kami memutasikan base intent untuk menyertakan URI file target dan permission flag yang diperlukan, lalu mengarahkan intent tersebut ke Activity berbahaya milik kami. Karena pending intent dieksekusi dari konteks aplikasi e-money, sistem Android kembali mengizinkan akses ke file sandboxed-nya.
Hasilnya sama: pencurian file berhasil dilakukan, kali ini tanpa memerlukan interaksi langsung dengan komponen exported aplikasi target.
Mitigasi: Gunakan flag FLAG_IMMUTABLE saat membuat pending intent untuk mencegah mutasi oleh aplikasi penerima. Jika penggunaan FLAG_MUTABLE tidak dapat dihindari, pastikan base intent bersifat explicit (menentukan target class secara eksplisit) untuk mencegah pengalihan ke komponen pihak ketiga yang tidak diinginkan.
Pola yang Berulang: Mengapa Ini Terjadi
Dari pengalaman kami, kedua kerentanan di atas bukan muncul karena kelalaian semata. Ada beberapa faktor struktural yang membuat aplikasi mobile e-money rentan terhadap kelas serangan ini.
- Kurangnya visibilitas terhadap permukaan serangan client-side. Tim security dan developer cenderung berfokus pada keamanan lapisan API dan jaringan. Mekanisme komunikasi antar-komponen Android — Intent, Pending Intent, Content Provider — sering luput dari threat modeling karena tidak terlihat dalam traffic HTTP/S yang biasa diintersepsi.
- Asumsi bahwa sandbox Android cukup sebagai lapisan proteksi. Sandbox Android memang mencegah akses langsung antar-aplikasi, namun celah muncul ketika mekanisme berbagi akses yang sah (seperti file provider dengan grantUriPermissions) dieksploitasi melalui komponen yang tidak diamankan dengan baik.
- Pengujian yang terbatas pada permukaan yang terlihat. Banyak engagement penetration testing berfokus pada UI dan traffic jaringan. Analisis statis terhadap manifest file, decompiled source code, dan konfigurasi komponen membutuhkan waktu dan keahlian tambahan, sehingga sering tidak masuk dalam scope pengujian standar.
Rekomendasi untuk Tim Security dan Development
Berdasarkan temuan dari engagement ini, ada beberapa langkah yang paling berdampak jika diprioritaskan.
- Audit konfigurasi exported components secara menyeluruh. Setiap Activity, Service, dan Broadcast Receiver yang dikonfigurasi sebagai exported adalah potential entry point bagi aplikasi pihak ketiga. Terapkan prinsip least privilege: komponen hanya di-export jika memang dirancang untuk berinteraksi dengan aplikasi lain.
- Validasi dan sanitasi semua data intent yang masuk. Jangan pernah menggunakan atau mengembalikan data intent dari komponen eksternal tanpa terlebih dahulu memvalidasi isinya — terutama URI dan permission flag yang dapat memberikan akses ke resource internal.
- Selalu gunakan FLAG_IMMUTABLE untuk pending intent. Ini adalah praktik default yang disarankan sejak Android 12. Untuk aplikasi yang masih mendukung versi Android lebih lama, review seluruh implementasi pending intent dan pastikan base intent-nya bersifat explicit.
- Enkripsi data yang disimpan secara lokal. Kedua serangan yang didemonstrasikan berhasil membaca konten file internal karena file tersebut tidak dienkripsi. Mengenkripsi data sensitif di local storage — menggunakan Android Keystore — memastikan bahwa bahkan jika file berhasil dicuri, isinya tidak dapat langsung dieksploitasi.
- Masukkan analisis statis APK dalam scope pengujian. Tools seperti JADX untuk decompiling dan objection untuk runtime exploration memungkinkan identifikasi kerentanan yang tidak tampak dari traffic jaringan. Pengujian yang hanya mengandalkan intersepsi HTTP akan melewatkan seluruh kelas kerentanan client-side ini.
Kesimpulan
Aplikasi e-money menghadapi permukaan serangan yang lebih luas dibanding aplikasi mobile pada umumnya. Dua kerentanan yang kami temukan dalam engagement ini bukan anomali — keduanya merupakan konsekuensi dari implementasi mekanisme Android yang valid, namun digunakan tanpa mempertimbangkan implikasi keamanannya.
Yang membuat temuan ini patut mendapat perhatian lebih adalah bahwa eksploitasinya tidak memerlukan perangkat yang di-root, tidak memerlukan intersepsi traffic jaringan, dan sepenuhnya dapat dilakukan oleh aplikasi berbahaya yang didistribusikan kepada korban. Dalam skenario nyata, aplikasi semacam ini bisa disamarkan sebagai aplikasi utilitas biasa.
Penetration testing yang mencakup analisis client-side secara mendalam — bukan hanya lapisan jaringan dan API — adalah langkah krusial untuk mengidentifikasi celah seperti ini sebelum ditemukan oleh pihak yang tidak bertanggung jawab, sekaligus memenuhi kewajiban pengujian keamanan yang diamanatkan oleh regulasi OJK dan UU PDP.
Jika Anda ingin memahami postur keamanan aplikasi mobile e-money perusahaan Anda secara lebih mendalam, tim Security Squad LOGIQUE siap membantu.
