Membedah: mandiri e-money isi ulang

Seperti yang pernah saya singgung pada postingan sebelumnya, memberikan aplikasi untuk layanan e-money merupakan pilihan yang bisa dibilang beresiko. Apalagi untuk proses top-up. Masalahnya tentu pada aspek security dari layanan ini tentunya.

Sebelum terlalu dalam (karena waktu juga yang belum ada), mari kita coba dulu apakah aplikasi ini benar-benar bekerja sesuai yang dijanjikan.

Prosesnya cukup mudah:

  1. Registrasi terlebih dahulu, seperti halnya layanan online, pengguna harus mendaftarkan e-mail & set password
  2. NFC ON
  3. Tap kartu pada handset
  4. Aplikasi akan memunculkan informasi saldo terakhir, setelah itu muncul denominasi nilai top-up yang bisa dipilih
  5. Setelah memilih denom, user akan diminta untuk input nomor kartu ATM, expiry date, & CVV kartu
  6. Selanjutnya proses authentikasi 3DS seperti biasa kode OTP akan dikirim melalui SMS; perlu dicatat bahwa tipe SMS yang dipergunakan adalah class-0, sehingga pesan OTP hanya muncul sebagai pop-up dialog pada handset Android. Menyebabkan user harus benar-benar mengingat nilai OTP yang dikirim, untuk selanjutnya diinputkan dalam aplikasi (sebenarnya hanya menampilkan tampilan web 3DS-nya Bank Mandiri)
  7. Setelah proses 3DS selesai, user diharuskan untuk melakukan tap ulang kartu e-money pada handset; di sinilah proses top-up saldo offline kartu dilakukan
  8. Dan notifikasi akan muncul bahwa saldo e-money sudah terkredit; notifikasi juga dikirim melalui e-mail

Setelah mencoba sendiri, rasanya aplikasi ini layak mendapat acungan jempol karena,

  • Berjalan sesuai dengan yang diharapkan
  • Inovasi layanan e-money pertama di Indonesia yang memperbolehkan mekanisme top-up melalui mobile device milik user

Lalu bagian analisa security-nya?

Seperti anda memiliki dompet kemudian diberikan sebuah alat khusus untuk melakukan cetak uang asli. Walaupun harapan penyedia layanan adalah anda hanya akan bisa melakukan cetak uang sejumlah uang yang anda miliki di rekening bank, namun adakah kemungkinan untuk menerobos batasan ini?

Teknis..

Untuk sementara berikut analisa sekilas saya:

  1. Aplikasi pure Java — tidak ada native code seperti aplikasi cek saldo e-money
  2. Tidak ada proteksi khusus terhadap command APDU — khususnya APDU untuk cek saldo yang jika pada aplikasi cek saldo e-money diproteksi sedemikian rupa dengan native code
  3. Command-command APDU di-populate dari server — ada kemungkinan sebuah celah yang memungkinkan attacker menganalisa komunikasi command APDU dari server ke kartu melalui aplikasi ini

Poin terakhir saya coba gali lagi, tentunya dengan tetap mempertahankan kerahasiaan jika memang celah ini benar-benar bisa dipergunakan.

Wasalam.

[UPDATE 2015/03/11]

Baru sempat nulis lagi.

Analisa terkait otorisasi dengan server (mmhh.. lebih tepat server-server) menunjukan security sudah solid, kemungkinan sudah pernah dilakukan penetration testing sebelumnya.

Di sisi lain pada aplikasi ini sebenarnya ada sebuah “feature” yang seharusnya tidak diperlukan untuk sebuah aplikasi dalam environment production. Berikut salah satu informasi yang bisa diextract dari “feature” ini:

Tenang, APDU command-nya ngga bisa diplayback kok — sudah dicoba sebagai bagian dari test, karena ada proses otorisasi sebelumnya yang melibatkan validasi value dari kartu dan server. Jika penasaran, ini adalah contoh data dari server pada saat top-up sejumlah Rp100.000. Terlihat APDU yang dikirim ke kartu memiliki nilai hexstring .. A0 86 01.. (0x0186A0h = 100000).

Mungkin perlu belajar Differential Power Analysis 😀

Masukan saya untuk Bank Mandiri/vendor-nya:

  1. Hilangkan saja “feature” ini — pada environment SIT/UAT boleh saja sebagai bagian proses debugging; namun untuk production? bisa menjadi celah untuk exploit
  2. Encrypted JSON? — mungkin dengan cara yang sama menggunakan RSA seperti password pada saat login?

Demikian sementara analisa dari saya.

[UPDATE 2016/01/07]

Akhirnya ada yang mencoba melakukan attack dan berhasil (menurut pengakuannya — saya belum melihat dokumentasi attack ini dilakukan). Sesuai dengan analisa pertama saya bahwa memberikan fasilitas debug/logging pada aplikasi production (sebelumnya saya hanya menyebut “feature“, karena toh sudah ada yang menulis secara detil di blog) memberikan kemudahan attacker melakukan analisa alur program, terlebih lagi protokol komunikasi yang dipergunakan.


Sebagai catatan sekaligus disclaimer: dalam tulisan ini tidak dimaksudkan untuk melakukan proses reverse engineering untuk tujuan komersil. Dan seluruh review terkait aplikasi dan desain sistem dalam tulisan blog ini dibatasi sedemikian rupa sehingga hal-hal sensitif terkait HAKI maupun ide kreatif tidak dilanggar. Jika tidak berkenan silakan contact melalui comment maupun e-mail. 

  • Emir S

    Menarik. Entah kenapa di aplikasi ini apdu baca saldonya malah dibiarkan terbuka begitu saja, gak seperti aplikasi sebelumnya yg pake NDK buat nyimpen apdu.
    Plus, apdu dipopulate dari server mungkin karena di HP Android, secure element yg sifatnya sbg SAM malah gak bs diakses? CMIIW.

    Btw, boleh bagi alamat emailnya buat diskusi? Kebetulan saya lagi belajar oprek2 NFC di Android dan smartcard. Thx.

    • Hi Mas Emir, silakan alamat email saya ada di sini: http://sybond.web.id/project/?page_id=127

    • Arina Nuha

      apdu untuk baca saldo menurut saya gak masalah jika dibuka, toh tidak berbahaya.

      kalau menurut saya SAM di server lebih praktis, karena bank tidak perlu menginstall applet di secure element hp customer, selain itu tidak semua hp punya SE.

      untuk HCE, bukannya itu hp sebagai emoney-nya ya, sedangkan post diatas hp sebagai acquirer/reader

    • Setuju.
      Komen saya perlu diralat, maksud saya SE bukan HCE 😀

      Salam kenal!

  • andre

    Artikel tentang Native NFC di Android bisa di share? Thx