in Advisory, Web Security

Hacking Mandiri Internet Banking dengan Session Fixation

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:

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.

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:

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.

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.

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.

    1. 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?

    1. 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.

    1. 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).

‘|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

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

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.

Write a Comment

Comment

This site is using OpenAvatar based on

61 Comments

  1. Mas, bagus banget tulisannya. Mau nanya nih, gimana kalo pada situs tertentu seperti Facebook dan Gmail. Sepertinya walaupun kita memiliki akses fisik, beberapa session seperti kasus di FB itu mempunyai masa expired sampe setelah kita log out. dan setelah saya coba dengan tidak log out dan membersihkan cookie kemudian memakai cookie tersebut ternyata bisa, tapi setelah saya log out dan dengan memakai cookie yang sama itu sudah gk bisa dipake. Sy juga pernah coba dengan merubah semua isi cookienya menjadi expired bbrp hari, tapi setelah saya coba, tetap aja gak bisa kl kita habis log out. ini artinya, session di fb berakhir setelah log out. Namun kalo diliat, ada beberapa isi cookie spert “datr” dan “lu” itu expiredx adalah 2 tahun ke depan sejak log in. Kalau demikian, apa gunanya kedua elemen tersebut berbeda masa expiredx? bukankah tetap saja tidak bisa digabungkan dengan cookie lain yang sudah expired? atau bahkan cookie dari akoun lain yg tidak expired dgn hanya mengganti kedua elemen tersebut. Semuanya masih belum sy mengerti. Mohon penjelasannya mas, makasih sebelumnya…

  2. nice info..mungkin attacker sampai bisa melihat informasi nasabah saja…
    .tapi di internet banking harus make token pula kalo mau transfer dana…..gmana apa bisa jga d hack sampai ke sana??? hehe…..

    thanks infonya…. 🙂

  3. wah nice info cukup tau algoritmanya aja….
    tapi walaupun bisa akses attacker kan cuma bisa ngecek saldo aja..
    sedangkan transfer uang atau belanja pake ib kan membutuhkan token..

Webmentions

  • Rentannya e-Banking dan Pencegahan/Penanganan Pertamanya | PULUNG WASESA BAYU AJI ( plgaji / plg aji ) dalam Kisah December 6, 2013

    setelah 2 artikel saya baca,… saya akan berencana membaca artikel lain dari http://www.ilmuhacking.com
    salam buat mas rizqi