Pendahuluan
Over-the-Air (OTA) update adalah mekanisme yang memungkinkan aplikasi atau firmware Android diperbarui tanpa proses instalasi manual oleh pengguna. Mekanisme ini umum dipakai bukan hanya oleh vendor perangkat untuk update sistem, tapi juga oleh aplikasi mobile untuk mendorong pembaruan konten, konfigurasi, atau bahkan kode eksekusi secara langsung — pola yang makin populer lewat pendekatan seperti hot update atau dynamic feature delivery.
Masalahnya, mekanisme yang dirancang untuk mendistribusikan perubahan ke perangkat pengguna, jika diimplementasikan tanpa kontrol keamanan yang memadai, berubah jadi jalur ideal bagi attacker untuk mendorong kode berbahaya ke perangkat korban dengan cara yang terlihat sah di mata sistem.
Artikel ini membahas bagaimana OTA update bekerja pada aplikasi Android, kerentanan yang paling sering ditemukan dalam implementasinya, dan bagaimana mekanisme ini seharusnya diamankan.
Bagaimana OTA Update Bekerja
Secara umum, alur OTA update pada aplikasi Android melibatkan beberapa tahap: aplikasi memeriksa ke server apakah ada versi baru, server merespons dengan informasi update (biasanya berupa URL paket update dan metadata seperti versi dan hash), aplikasi mengunduh paket tersebut, memverifikasinya, lalu menerapkan update — baik dengan mengganti file tertentu, memuat kode baru secara dinamis, atau memicu instalasi ulang APK.
Keamanan mekanisme ini bergantung pada tiga hal yang harus terjaga sepanjang alur: kanal komunikasi yang tidak bisa disadap atau dimanipulasi, paket update yang keasliannya bisa diverifikasi, dan proses penerapan update yang tidak bisa dipaksa mundur ke versi yang rentan. Jika salah satu dari tiga hal ini gagal, seluruh mekanisme update bisa disalahgunakan untuk mendorong kode arbitrer ke perangkat pengguna.
Kerentanan yang Paling Sering Ditemukan
1. Update Tanpa Verifikasi Signature
Ini adalah kerentanan paling mendasar dan paling sering ditemukan: aplikasi mengunduh paket update lalu langsung menerapkannya tanpa memverifikasi bahwa paket tersebut benar-benar berasal dari penerbit yang sah.
Tanpa verifikasi signature, siapa pun yang bisa menempatkan diri di antara aplikasi dan server update — misalnya lewat man-in-the-middle di jaringan publik, atau lewat kompromi terhadap server distribusi — bisa mengirimkan paket update palsu yang akan diterima dan dieksekusi begitu saja oleh aplikasi.
Dalam pengujian, kerentanan ini kerap ditemukan pada implementasi update kustom yang dibangun sendiri oleh tim development, di luar mekanisme resmi Google Play, karena verifikasi signature dianggap langkah opsional yang bisa ditambahkan belakangan.
2. Distribusi Update Lewat Kanal Tidak Terenkripsi
Paket update yang diunduh lewat HTTP polos, atau lewat HTTPS tanpa certificate pinning, rentan terhadap manipulasi di tengah jalan. Attacker dengan posisi man-in-the-middle — situasi yang realistis di jaringan Wi-Fi publik atau pada perangkat yang sudah terpasang certificate authority palsu — bisa mengganti isi paket update sebelum sampai ke aplikasi.
Bahkan ketika HTTPS sudah dipakai, tanpa certificate pinning aplikasi tetap rentan terhadap serangan yang memanfaatkan certificate authority yang dipercaya secara tidak sah, baik lewat CA yang dikompromikan maupun CA yang sengaja ditanam di perangkat korban.
3. Rollback Attack ke Versi yang Rentan
Kerentanan yang lebih halus tapi cukup sering ditemukan adalah ketiadaan mekanisme anti-rollback. Jika aplikasi tidak memvalidasi bahwa versi update yang diterima lebih baru dari versi yang sedang berjalan, attacker bisa memaksa aplikasi menerima paket update versi lama yang sudah diketahui memiliki kerentanan, lalu mengeksploitasi kerentanan tersebut.
Skenario ini relevan terutama saat vendor pernah merilis versi dengan celah keamanan yang sudah diperbaiki di versi berikutnya. Selama paket versi lama itu masih valid secara signature dan bisa diakses attacker, rollback attack tetap jadi jalur yang dapat dieksploitasi.
4. Integrity Check yang Lemah atau Tidak Ada
Sebagian implementasi memvalidasi paket update hanya dengan hash yang dikirim lewat kanal yang sama dengan paket itu sendiri, atau bahkan tidak memvalidasi integritas sama sekali. Jika hash referensi bisa dimanipulasi bersamaan dengan paket update, verifikasi integritas ini tidak memberikan proteksi apa pun.
Kasus lain yang cukup sering ditemukan adalah aplikasi yang memvalidasi hash tapi mengambil nilai referensinya dari response API yang sama yang juga menyediakan URL paket update — sehingga attacker yang bisa memanipulasi satu, otomatis bisa memanipulasi yang lain.
5. Penyimpanan dan Eksekusi Paket Update yang Tidak Aman
Setelah diunduh, paket update sering disimpan di lokasi yang bisa diakses atau ditulis oleh aplikasi lain pada perangkat yang sama, seperti external storage tanpa kontrol permission yang memadai. Aplikasi lain yang berjalan di perangkat yang sama — termasuk aplikasi berbahaya yang sengaja dipasang attacker — berpotensi mengganti isi paket sebelum sempat dieksekusi oleh aplikasi target.
Dari kelima kerentanan di atas, ketiadaan verifikasi signature adalah yang paling sering ditemukan penulis dalam engagement pengujian aplikasi mobile. Frekuensinya lebih tinggi dibanding kerentanan lain karena tim development sering berasumsi bahwa penggunaan HTTPS untuk kanal distribusi sudah cukup, padahal HTTPS hanya mengamankan kanal, bukan mengamankan keaslian isi paket itu sendiri.
Implementasi yang Benar
Verifikasi Signature Paket Update
Setiap paket update harus ditandatangani secara digital oleh penerbit menggunakan private key, dan aplikasi harus memverifikasi signature tersebut menggunakan public key yang sudah ditanam (embedded) di dalam aplikasi sejak awal, bukan diambil dari server pada saat runtime. Public key yang diambil dari server yang sama dengan sumber paket update tidak memberikan proteksi terhadap server yang sudah dikompromikan.
Kanal Distribusi yang Aman
Paket update harus didistribusikan lewat HTTPS dengan certificate pinning, sehingga aplikasi hanya mempercayai sertifikat spesifik milik server update, bukan sertifikat mana pun yang diterbitkan oleh CA yang dipercaya sistem.
Mekanisme Anti-Rollback
Aplikasi harus menyimpan catatan versi yang sudah pernah dipasang — idealnya dengan penomoran versi monotonic yang tidak bisa berkurang — dan menolak paket update dengan nomor versi yang lebih rendah dari versi yang sudah pernah berjalan, meskipun signature-nya tetap valid.
Integrity Check yang Independen
Hash atau checksum paket update sebaiknya menjadi bagian dari data yang ikut ditandatangani secara digital bersama metadata versi, bukan dikirim terpisah lewat kanal yang bisa dimanipulasi secara independen dari paket itu sendiri.
Penyimpanan yang Terisolasi
Paket update sebaiknya disimpan di internal storage aplikasi yang tidak bisa diakses aplikasi lain, dan proses download, verifikasi, hingga penerapan update sebaiknya dilakukan secara atomik agar tidak ada window waktu ketika paket yang belum terverifikasi bisa diakses atau dimodifikasi pihak lain.
Pertimbangan Tambahan: Update Lewat Google Play vs Mekanisme Kustom
Untuk sebagian besar kasus, memanfaatkan mekanisme update resmi dari Google Play — termasuk In-App Updates API — jauh lebih aman dibanding membangun mekanisme OTA kustom, karena signature verification, integrity check, dan distribusi amannya sudah ditangani oleh platform. Mekanisme kustom biasanya dibangun karena kebutuhan spesifik seperti update konten dinamis atau hot-fix tanpa melalui proses review Play Store, dan justru kebutuhan semacam inilah yang paling sering luput dari kontrol keamanan yang memadai.
Kesimpulan
OTA update adalah mekanisme yang bermanfaat untuk menjaga aplikasi tetap up to date tanpa bergantung sepenuhnya pada inisiatif pengguna, tapi fleksibilitasnya menciptakan permukaan serangan yang signifikan jika tidak diamankan dengan benar. Kerentanan OTA update bukan hanya soal kanal distribusi yang tidak terenkripsi; banyak yang berakar dari asumsi keliru bahwa HTTPS saja sudah cukup untuk menjamin keaslian isi update.
Pengujian mekanisme OTA update harus menjadi bagian standar dari setiap engagement security testing aplikasi mobile, bukan hanya memeriksa apakah update berfungsi, tapi bagaimana keasliannya diverifikasi di setiap tahap.
Jika Anda ingin memastikan mekanisme update aplikasi Android Anda sudah aman dari eksploitasi, tim Security Squad LOGIQUE siap membantu.
