Bagian sebelumnya sudah dipaparkan bagaimana serangan Sinkronisasi Token dapat mematahkan ‘mata-rantai’ terlemah sistem keamanan internet banking. Mitigasi dengan menutup celah keamanan di sisi user sejauh ini sudah dilakukan bank dengan memberikan tips pengamanan. Nah, bagian ini akan fokus membahas usulan perbaikan di sisi sistem internet banking, bukan di sisi pengguna. Secara umum, terdapat dua kerawanan utama yang dieksploitasi dalam kasus serangan ini, yaitu:
1. Komunikasi antara user dan web-server hanya menggunakan satu jalur (channel). Komunikasi antara PC pengguna dengan server internet banking seluruhnya melewati jalur. credential dari pengguna, yakni username, password dan token-OTP, juga dikirimkan melalui jalur ini. Jalur ini sudah diamankan dengan protokol HTTPS. Namun demikian, penyerang masih tetap dapat melakukan MITM dengan cara seperti yang dijelaskan di subbab sebelumnya. 2. Jika terjadi man-in-the-middle-attack (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 halaman web internet banking selama berlangsungnya proses transaksi. Mengenai kerawanan (1), komunikasi lewat satu jalur ini sebenarnya sudah diamankan protokol HTTPS yang masih terbukti aman. Namun demikian, protokol ini akan berjalan baik hanya jika PC-pengguna benar-benar 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 dapat digagalkan penyerang. Kerawanan (2) sudah jelas, jika terjadi MITM, maka tidak akan ada lagi lapis pengamanan berikutnya. Berhasil atau tidaknya serangan, akan sepenuhnya bergantung kejelian pengguna untuk mengenali adanya request yang tidak valid. Usulan perbaikan sistem keamanan harus secara efektif menutup kerawanan-kerawanan di atas. Karena itulah, di mata penulis, prinsip utama yang harus dipenuhi dalam perbaikan protokol keamanan ada dua. Pertama, mekanisme pengamanan tambahan harus menggunakan jalur komunikasi yang sepenuhnya terpisah dari jalur komunikasi yang terserang MITM. Kedua, mekanisme pengamanan tambahan dengan dua alternatif. Yakni 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 back end system yang dapat mencegah terjadinya mutasi rekening ke tujuan rekening yang belum didaftarkan pengguna. Permintaan pendaftaran rekening tujuan mutasi harus dilakukan sebelum transaksi melalui jalur komunikasi yang terpisah. Dengan memenuhi dua prinsip di atas, maka tingkat kerawanan dapat diminimalkan. Akan sangat baik jika usulan perbaikan ini juga mempertimbangkan aspek kemudahan implementasi. Sebisa mungkin perbaikan ini direalisasikan hanya dengan modifikasi sistem yang sudah ada, bukan dengan merombak mekanisme keamanan saat ini. 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 masing-masing sistem internet banking dengan sistem token berbeda 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 sistem token yang digunakan. Nah, ada tiga alternatif perbaikan sistem keamanan internet banking. Alternatif Pertama, 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 secara umum diawali dengan server memberikan challenge yang berupa sederetan angka (biasanya 6-8 angka) melalui halaman internet banking, pengguna membaca challenge tersebut dan memasukkannya ke token-device, token-device akan membangkitkan deretan angka baru sebagai respons, dan pengguna memasukkan response tersebut ke halaman web internet banking. Baik kode challenge ataupun response, saat ini semuanya dipertukarkan melalui jalur internet yang mungkin diserang MITM. Berdasarkan pertimbangkan tersebut, alternatif perbaikan protokol keamanannya adalah 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 usulan perbaikan ini antara lain agar penyerang sulit melakukan modifikasi terhadap pesan yang dikirim melalui SMS. Kemudian pengguna dapat melakukan verifikasi kebenaran transaksi yang dilakukan dengan memeriksa nilai uang dan tujuan mutasi rekening sementara penyerang tidak dapat memperoleh kode challenge dari jalur yang terserang MITM. Dengan MITM, penyerang dapat melakukan login, memasukkan nilai transaksi dan rekening tujuan. Namun, kecil kemungkinan transaksi 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.
Alternatif Kedua, 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 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 sudah menggunakan jalur komunikasi lain yang berbeda dengan jalur internet yang mungkin diserang 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 terdapat MITM, maka tetap saja pengguna tidak dapat memverifikasi apakah transaksi yang saat ini berlangsung memang merupakan transaksi yang sedang dilakukan oleh pengguna.
Maka, berdasarkan pertimbangkan di atas, alternatif perbaikan protokol keamanannya adalah dalam protokol yang baru, nilai uang dan tujuan mutasi rekening dikirimkan lewat jalur SMS kepada pengguna bersama-sama dengan token-OTP.
Adapun tujuan usulan perbaikan ini adalah agar penyerang sulit untuk melakukan modifikasi terhadap pesan yang dikirim melalui SMS, dan pengguna dapat melakukan verifikasi kebenaran transaksi yang dilakukan dengan memeriksa nilai uang dan tujuan mutasi rekening.
Sama dengan alternatif yang sebelumnya, pada 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.
Alternatif ketiga, penambahan mekanisme pendaftaran tujuan transfer. Secara umum, prosedur transaksi internet banking tidak mensyaratkan pengguna 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 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 keamanannya adalah:
(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.
(4) Pendaftaran dapat dilakukan melalui jalur lain yang aman, misalnya: SMS, USSD, atau mendatangi customer service. 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.
Adapun tujuan usulan perbaikan ini adalah penyerang MITM tidak dapat melakukan transfer ke sembarang rekening tujuan transfer dan penyerang MITM tidak dapat mendaftarkan tujuan transfer lewat halaman web internet banking.
Akhir kata, sebagai epilog dua tulisan artikel ini, upaya pengamanan sistem internet banking harus kita lakukan secara berkesinambungan karena prinsipnya tidak ada keamanan absolut! Identifikasi kerawanan, skenario serangan, hingga perbaikan keamanan yang dipaparkan di atas dimaksudkan untuk hal ini. Usulan perbaikan protokol keamanan yang telah dijelaskan setidaknya akan dapat meminimalkan kemungkinan berulangnya serangan yang serupa, sehingga rakyat Indonesia terus merasakan aman dan nyaman ke depannya.
Dr. Budi Sulistyo CISA adalah Security Expert dari Lembaga Riset Telematika Sharing Vision, Bandung.
