Memoles e-Banking Guna Menangkal Serangan Sinkronisasi Token: Usulan Perbaikan Keamanan Internet Banking (bagian 3 dari 3 tulisan)

Artikel sebelumnya sudah memaparkan bagaimana serangan ‘sinkronisasi token’ dapat mematahkan ‘mata-rantai’ terlemah dari sistem keamanan internet banking. Sebelum beranjak pada alternatif solusi, kita perlu menegaskan terlebih dahulu beberapa hal yang akan menjadi referensi dalam merumuskan solusi perbaikan keamanan internet banking , yaitu:

  1. Skenario dasar serangan ini tidak cukup ditangkal hanya dengan mengandalkan kapabilitas, kejelian dan kepedulian pengguna.
  2. Serangan tidak mematahkan mekanisme pengamanan yang saat ini ada, yang mencakup protokol HTTPS, otentikasi dengan username dan password, dan juga sistem token.
  3. Skenario dasar serangan adalah man-in-the-middle-attack yang memotong jalur komunikasi antara PC pengguna dan server internet banking.
  4. Penyerang mengeksploitasi kerawanan yang ada di sisi pengguna, yaitu PC-pengguna, diduga dengan menanamkan virus. Variasi lain dari skenario dasar yang sama dapat dilakukan dengan menyerang proxy server ataupun DNS server. Intinya, serangan tidak diarahkan pada sistem internet banking yang menjadi kewenangan pihak bank.
  5. Serangan efektif karena ada faktor social engineering yaitu teknik untuk mengelabui pengguna.
  6. Penyerang berhasil melakukan transaksi dengan menggunakan otorisasi pengguna yang sah.

Mitigasi dengan menutup celah keamanan di sisi pengguna sejauh ini sudah dilakukan oleh bank dengan memberikan tips pengamanan kepada pengguna (lihat artikel bagian 1). Bagian artikel ini akan fokus membahas usulan perbaikan di sisi sistem internet banking (yang merupakan wewenang Bank), bukan di sisi pengguna.

Dalam kasus serangan ini, terdapat dua kerawanan utama yang dieksploitasi oleh penyerang, yaitu:

  1. Komunikasi antara user dan web-server hanya menggunakan satu jalur (channel). Komunikasi antara PC pengguna dengan server internet banking seluruhnya melewati satu jalur. Credential dari pengguna, yakni username, password dan token-OTP, juga dikirimkan melalui jalur ini. Jalur ini sebenarnya sudah diamankan dengan protokol HTTPS. Namun demikian, penyerang masih tetap dapat melakukan MITM dengan cara seperti yang dijelaskan di artikel bagian 2.
  2. Jika terjadi MITM, pengguna tidak memiliki informasi yang cukup untuk membedakan request valid (berasal dari server internet banking) dari request tidak valid (yang disisipkan oleh penyerang), yang ditampilkan oleh halaman web internet banking selama berlangsungnya proses transaksi.

Mengenai kerawanan (1), komunikasi lewat satu jalur ini sebenarnya sudah diamankan dengan protokol HTTPS yang masih terbukti aman. Namun demikian, protokol ini akan berjalan dengan baik hanya jika PC-pengguna benar-benar dapat berkoneksi dengan server internet banking sehingga protokol HTTPS dapat dimulai. Jika penyerang dapat membelokkan paket data dari PC pengguna ke  server penyerang sebelum HTTPS dimulai, maka mekanisme pengamanan tersebut akan dapat digagalkan oleh penyerang. Kerawanan (2) sudah jelas, jika terjadi MITM maka tidak akan ada lagi lapis pengamanan berikutnya. Berhasil atau tidaknya serangan, akan sepenuhnya bergantung pada kejelian pengguna untuk mengenali adanya request yang tidak valid.

Usulan perbaikan sistem keamanan harus secara efektif menutup kerawanan-kerawanan di atas. Berikut adalah prinsip-prinsip yang harus dipenuhi dalam usulan perbaikan keamanan ini:

  1. Mekanisme pengamanan tambahan harus menggunakan jalur komunikasi yang sepenuhnya terpisah dari jalur komunikasi yang terserang MITM
  2. Alternatif mekanisme keamanan tambahan
    • Alternatif 1: Ketika MITM terjadi, sistem keamanan harus menyediakan mekanisme tambahan yang memungkinkan pengguna memverifikasi transaksi yang sedang berlangsung. Informasi yang diverifikasi dalam mekanisme ini adalah: nilai uang dan tujuan mutasi rekening.
    • Alternatif 2: Ketika MITM terjadi, sistem keamanan harus menyediakan mekanisme tambahan di sisi backend system  yang dapat mencegah terjadinya mutasi rekening ke tujuan rekening yang belum didaftarkan oleh pengguna. Permintaa pendaftaran rekening tujuan mutasi harus dilakukan sebelum transaksi melalui jalur komunikasi yang terpisah sesuai dengan prinsip (1).

Dengan memenuhi dua prinsip di atas, maka tingkat kerawanan yang ada akan dapat diminimalkan. Akan sangat baik jika usulan perbaikan ini juga mempertimbangkan aspek kemudahan implementasi. Sebisa mungkin perbaikan ini dapat direalisasikan hanya dengan sedikit modifikasi pada sistem yang sudah ada, bukan dengan merombak mekanisme keamanan saat ini.

1. Alternatif perbaikan sistem keamanan internet banking

Saat ini terdapat dua jenis sistem token sebagai mekanisme pengaman internet banking, yakni: sistem token yang menggunakan token-device dan sistem token yang menggunakan sms-token. Alternatif usulan perbaikan protokol keamanan akan diajukan untuk masing-masing sistem internet banking dengan sistem token yang berbeda ini, yaitu dengan menambahkan mekanisme verifikasi transaksi. Diusulkan juga satu alternatif lain yang menambahkan mekanisme pendaftaran tujuan mutasi rekening sebelum transaksi. Alternatif yang terakhir ini dapat diterapkan tanpa bergantung pada sistem token yang digunakan.


Alternatif 1A: Penambahan mekanisme verifikasi transaksi untuk sistem_internet_banking_dengan_token_device.


Untuk sistem yang ada saat ini, dalam proses transaksi normal terdapat mekanisme challenge-and-response ketika server internet banking melakukan otentikasi dengan meminta token-OTP dari pengguna (contoh: BCA, BNI, Mandiri). Prosedur otentikasi token-device eksisting secara umum adalah sebagai berikut:

  1. Server memberikan challenge yang berupa sederetan angka (biasanya 6-8 angka) melalui halaman internet banking
  2. Pengguna membaca challenge tersebut dan memasukkannya ke token-device.
  3. Token-device akan membangkitkan deretan angka baru sebagai
  4. Pengguna memasukkan response tersebut ke halaman web internet banking.

Baik kode challenge ataupun response,  saat ini semuanya dipertukarkan melalui jalur internet yang mungkin diserang olen MITM. Berdasarkan pertimbangkan tersebut, perbaikan protokol keamanan yang diusulkan adalah:

Alternatif 1A: Usulan perbaikannya adalah sebagai berikut, dalam protokol yang baru, kode challenge, nilai uang dan tujuan mutasi rekening dikirimkan lewat jalur SMS kepada pengguna. Tidak ada pengiriman kode challenge lewat halaman web internet banking.

Tujuan perbaikan ini adalah agar:

  1. Penyerang sulit untuk melakukan modifikasi terhadap pesan yang dikirim melalui SMS.
  2. Pengguna dapat melakukan verifikasi kebenaran transaksi yang dilakukan dengan memeriksa nilai uang dan tujuan mutasi rekening.
  3. Penyerang tidak dapat memperoleh kode challenge dari jalur yang terserang MITM.
  4. Berdasarkan no (3), karena penyerang tidak mengetahui kode challenge, maka ia tidak dapat memancing pengguna untuk memberikan token-OTP. Serangkaian langkah social engineering untuk meminta token-OTP dari pengguna tidak dapat dilakukan oleh penyerang, karena untuk melakukan hal itu penyerang membutuhkan kode challenge.

Dengan MITM, penyerang dapat melakukan login, memasukkan nilai transaksi dan rekening tujuan. Namun, kecil kemungkinan transaksi akan berhasil karena pengguna dapat memverifikasi nilai dan rekening tujuan berdasarkan pesan yang diterima melalui SMS. Pengguna dapat menghentikan transaksi ketika mengetahui bahwa ada perubahan dalam nilai dan tujuan transaksi. Berikutnya, penyerang tidak dapat melanjutkan transaksi karena ia tidak menerima token-OTP dari pengguna. Berikut ini adalah protokol keamanan yang diusulkan (gambar 5).

perbaikan protokol alternatif 1A

Gambar 5 Tambahan mekanisme verifikasi transaksi untuk internet_banking_dengan_token_device (alternatif 1A)


Alternatif 1B: Penambahan mekanisme verifikasi transaksi untuk sistem_internet_banking_dengan_sms_token.


Dalam transaksi normal tidak terdapat mekanisme challenge and response ketika server internet banking meminta otentikasi dengan sistem token. Token-OTP dikirimkan melalui SMS ke ponsel pengguna pada saat pengguna melakukan proses transaksi. (contoh: CIMB Niaga). Prosedur otentikasi SMS-Token eksisting secara umum adalah sebagai berikut:

  1. Server internet banking meminta pengguna untuk memasukkan token-OTP melalui halaman web.
  2. Server token akan mengirimkan token-OTP menggunakan SMS ke ponsel pengguna.
  3. Pengguna membaca token-OTP di layar ponsel dan kemudian memasukkannya ke halaman web internet banking.

Dalam kasus ini, sistem internet banking memang sudah menggunakan jalur komunikasi lain yang berbeda dengan jalur internet yang mungkin diserang oleh MITM. Namun serangan MITM masih dapat dilakukan karena yang dikirim via SMS hanyalah token-OTP, tanpa menyertakan informasi mengenai nilai uang dan tujuan mutasi rekening. Jika terjadi MITM, maka tetap saja pengguna tidak dapat memverifikasi apakah transaksi yang saat ini berlangsung memang benar merupakan transaksi yang sedang dilakukan oleh pengguna.

Berdasarkan pertimbangkan di atas, alternatif perbaikan protokol keamanan yang diusulkan adalah:

Alternatif 1B: Usulan perbaikannya adalah sebagai berikut, dalam protokol yang baru, nilai uang dan tujuan mutasi rekening dikirimkan lewat jalur SMS kepada pengguna bersama-sama dengan token-OTP.

Tujuan usulan perbaikan ini adalah agar:

  1. Penyerang sulit untuk melakukan modifikasi terhadap pesan yang dikirim melalui SMS.
  2. Pengguna dapat melakukan verifikasi kebenaran transaksi yang dilakukan dengan memeriksa nilai uang dan tujuan mutasi rekening.

Sama dengan alternatif yang sebelumnya (1A), dalam protokol baru ini, dengan MITM penyerang masih bisa melakuan login ke halaman web internet banking. Namun, ketika penyerang akan memulai transaksi mutasi rekening, pengguna akan dengan mudah mendeteksi hal tersebut dengan memverifikasi informasi nilai uang dan tujuan transfer yang dikirim melalui SMS.

perbaikan protokol alternatif 1B

Gambar 6 Tambahan informasi nilai uang dan tujuan mutasi rekening untuk internet_banking_dengan_sms_token (alternatif 1B)


Alternatif 2: Penambahan mekanisme pendaftaran tujuan transfer


Secara umum, prosedur transaksi internet banking tidak mensyaratkan pengguna untuk mendaftarkan rekening-rekening tujuan transfer (mutasi rekening) sebelum dapat melakukan transaksi. Untuk kondisi ini, jika terjadi MITM, maka penyerang dapat memasukkan nomor rekening apapun sebagai tujuan transfer. Satu perkecualian adalah untuk internet banking BCA. Pengguna memang harus mendaftarkan terlebih dahulu tujuan transfer. Berikutnya, pengguna hanya dapat memilih salah satu dari sejumlah nomor rekening tujuan transfer yang sudah didaftarkan. Namun demikian, mekanisme yang ada di sistem internet banking BCA ini tetap tidak dapat mencegah penyerang untuk melakukan transaksi via serangan MITM. Ini karena pendaftaran nomor rekening tujuan transfer dapat dilakukan melalui halaman web internet banking yang sudah diserang dengan MITM.

Berdasarkan pertimbangkan di atas, alternatif perbaikan protokol keamanan yang diusulkan adalah:

Alternatif 2: Usulan perbaikan keamanan adalah sebagai berikut,

1. pengguna hanya dapat melakukan transfer ke rekening penerima yang sudah tertera dalam daftar. Halaman web dapat menampilkan daftar ini dalam menu yang dapat dipilih oleh pengguna.

2. Pendaftaran rekening penerima harus dilakukan sebelum proses transaksi.

3. Pendaftaran tidak dapat dilakukan melalui halaman web internet banking. Pendaftaran hanya dapat dilakukan melalui jalur lain yang aman, misalnya: SMS, USSD, atau mendatangi customer service.

4. Dalam proses pendaftaran tujuan rekening ini, harus ada mekanisme untuk mengotentikasi pengguna. Contoh: jika lewat SMS dan USSD, nomor ponsel dapat digunakan sebagai faktor otentikasi what-you-have.

Tujuan usulan perbaikan ini adalah agar:

  1. Penyerang MITM tidak dapat melakukan transfer ke sembarang rekening tujuan transfer.
  2. Penyerang MITM tidak dapat mendaftarkan tujuan transfer lewat halaman web internet banking.

Dalam protokol yang diusulkan, penyerang mungkin saja berhasil melakukan MITM. Namun ketika penyerang bermaksud melakukan transfer ke nomor rekening tertentu, jika nomor rekening tersebut belum didaftarkan sebelumnya, maka upaya penyerang tersebut akan ditolak oleh server internet banking.

usulan protokol alternatif 2

Gambar 7 Penambahan mekanisme pendaftaran tujuan transfer (alternatif 2)

2. Penutup

Usulan perbaikan protokol keamanan yang telah dijelaskan dibuat untuk meminimalkan kemungkinan berulangnya serangan yang serupa. Alternatif usulan tersebut juga relatif mudah untuk diimplementasikan. Ini tentunya akan mempermudah institusi perbankan untuk membangun mitigasi dengan cepat di sisi sistem internet banking yang menjadi kewenangannya.

Penulis:

  • Dr. Budi Sulistyo CISA adalah Security Expert dari Lembaga Riset Telematika Sharing Vision, Bandung. (budi@sharingvision.com)
  • Masagus Krisna, ST. adalah White Hat Hacker dan Reseacher dari Lembaga Riset Telematika Sharing Vision, Bandung. (krisna@sharingvision.com)

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s