Hah? Apa nggak salah nih. Https kan secure, mana mungkin bisa dibajak. Benar, tidak ada yang salah kok. Kalau anda sudah membaca dua artikel saya sebelumnya, understanding https dan session hijacking basics , anda akan mengerti bahwa dalam sebuah koneksi https tidak mungkin dibajak. Namun dengan trik yang akan saya jelaskan ini kita akan bisa membajak session https.
Cookie Basic
Cookie merupakan teknik server untuk membuat browser “menyimpan” data di browser, dan meminta browser mengirimkannya kembali ke server berdasarkan kriteria tertentu. Cookie dikirimkan dari browser ke server atau dari server ke browser sebagai bagian dari request/response http yang disisipkan dalam header http.
Cookie terdiri dari beberapa field: name, value, path, domain, secure bit,expired time. Dalam sebuah request, apakah browser akan mengirimkan suatu cookie tergantung dari field-field tersebut, apakah expired atau belum, apakah URL yang di-request cocok dengan domain+path, dan apakah koneksi melalui https atau tidak.
Insecure Cookie
Cookie yang secure bitnya diaktifkan bukan artinya cookie tersebut di-enkrip. Field secure pada cookie, digunakan untuk membatasi pengiriman kembali data di cookie ke server hanya melalui koneksi https. Bila field ini dikosongkan, maka artinya cookie tersebut boleh dikirim kembali ke server pada koneksi http maupun https (any type of connection). Sedangkan bila secure bit diaktifkan, maka cookie tersebut haram dikirimkan melalui http.
Sniffing Cookie
Session hijacking dilakukan dengan mencuri sessionid. Dalam kasus ini saya membahas sessionid yang disimpan dalam cookie. Kalau seorang attacker berhasil mencuri cookie yang mengandung sessionid, maka session korban telah sukses dibajak attacker.
Salah satu cara mencuri cookie adalah dengan teknik sniffing, yaitu dengan menguping percakapan http yang dilakukan orang lain. Dengan sniffing paket http yang lalu lalang, maka orang bisa menjaring cookie. Namun sniffing cookie hanya bisa dilakukan pada koneksi yang tidak ter-enkrip, yaitu http biasa. Sniffing cookie tidak mungkin dilakukan pada koneksi https.
CSRF Attack to Trigger Cookie Sending over HTTP
Apabila cookie tidak di-set https only, artinya kita bisa memaksa korban membuat request http (bukan https) ke URL yang termasuk dalam domain+path cookie yang ditarget attacker sehingga dalam request tersebut cookie akan disertakan juga (naked, not encrypted).
Jangan kuatir, request tersebut tidak harus ke URL yang valid, bahkan ke URL yang tidak ada sekalipun cookie tetap dikirimkan asalkan URLnya termasuk dalam domain dan path cookie. Di sini kita tidak peduli dengan response, terserah server mau jawab apa (200 OK, 404 Not Found, 403 Forbidden dsb), yang penting browser melakukan request yang mengandung cookie melalui koneksi yang tidak ter-enkrip.
CSRF attack adalah serangan yang mirip dengan XSS. Serangan ini hanya menerang client, dan tidak berpengaruh pada server. Inti dari serangan ini adalah pada REQUEST, yaitu bagaimana bisa membuat korban melakukan request HTTP untuk memaksa korban berbuat sesuatu yang tidak diinginkannya.
Salah satu metode yang populer dalam CSRF adalah dengan memanfaatkan tag image (saya gunakan tag ini juga dalam artikel saya menjaring password klikBCA ). Bila browser menemukan tag image, maka serta merta dia akan melakukan request ke isi dari attribut src, begitu juga bila javascript mengubah atribut src ini, maka browser juga akan melakukan request.
Triknya adalah dengan mengisi atribut src dengan URL yang termasuk dalam domain+path cookie yang ditarget, lalu mengirimkan halaman html yang mengandung tag image tersebut ke korban. Begitu korban membuka halaman itu, maka browsernya akan mengirimkan request tanpa disadari korban, that’s it CSRF.
Hijacking PermataNet Session
PermataNet adalah situs internet banking bank permata. Web server PermataNet menerima koneksi yang masuk melalui http maupun https, namun setiap koneksi yang masuk melalui kanal http, akan diberi peringatan dan di-redirect menuju koneksi https. Ini bagus, mendidik user untuk selalu menggunakan https di situsnya. Namun bila tidak hati-hati justru ini menjadi celah.
Kenapa saya sebut ini adalah celah? Karena dengan membuka dua kanal, maka memungkinkan bagi seseorang untuk mengirimkan http request (bukan https). Bila cookie tidak diset https only, maka ada peluang naked cookie terkirim melalui jaringan.
Ketika browser membuka http://www.permatanet.com , maka server akan menjawab dengan HTTP 403 (Access Forbidden). Pada tahap ini tidak ada cookie yang diminta server untuk disimpan browser.
Selanjutnya browser akan membuka koneksi ke URL: https://www.permatanet.com/login/login.asp . Berikut percakapan yang terjadi:
https://www.permatanet.com/login/login.asp
GET /login/login.asp HTTP/1.1
Host: www.permatanet.com
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
Server: Microsoft-IIS/5.0
Date: Sat, 10 Jan 2009 07:54:35 GMT
Content-Length: 18481
Content-Type: text/html
Expires: Sat, 10 Jan 2009 07:54:36 GMT
Set-Cookie: ASPSESSIONIDSSDCARRA=OJBNBHIDDICNKDOODCAKBPKJ; path=/
Cache-Control: private
Perhatikan header Set-Cookie pada response yang artinya: “Hey browser! tolong simpan data ini, dan kirimkan kembali ke aku setiap kamu request ke host www.permatanet.com, lewat koneksi http atau https terserah.”
Cookie ini adalah cookie yang menyimpan sessionid, jadi kalau ingin membajak session PermataNet, attacker harus mencuri cookie ini. Setelah saya login (saya memang nasabah permata), cookie itu tetap menjadi tempat penyimpanan session id saya.
Oke, sekarang saya sudah login, itu artinya session established, dan isi cookie itu adalah kunci untuk membajak account saya.
Untuk mencuri cookie tersebut, pertama attacker harus sudah siap men-sniff jaringan saya. Kemudian attacker harus menunggu sampai saya berbuat kesalahan fatal, yaitu mengirim request yang mengandung cookie tersebut tanpa ter-enkripsi.
Sebagai contoh mari kita buat jebakan berupa tag image yang URLnya mengarah pada logo permatanet. Logo tersebut aslinya URLnya adalah:
https://www.permatanet.com/login/images/logo_permatanet.jpg , namun karena server permatanet membuka juga koneksi ke http, maka URLnya bisa juga menjadi:
http://www.permatanet.com/login/images/logo_permatanet.jpg (tanpa http).
Setiap request dengan http ke server PermataNet selalu dijawab dengan Forbidden Error (403). Tapi itu tidak penting, yang penting adalah request, bukan response.
Bila saya siapkan sebuah halaman html yang mengandung tag berikut:
Lalu html ini saya kirim melalui email, atau korban terbujuk untuk membuka halaman itu, maka browser korban akan mengirimkan request ke server permatanet melalui koneksi http. Bila korban saat itu sedang login (session masih valid), maka sessionid korban akan terbang tanpa perlindungan.
Kalau kita coba buka url tersebut di browser, kita lihat apa yang dikirimkan browser saya dan diresponse server PermataNet:
http://www.permatanet.com/login/images/logo_permatanet.jpg
GET /login/images/logo_permatanet.jpg HTTP/1.1
Host: www.permatanet.com
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: image/png,image/*;q=0.8,*/*;q=0.5
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
Cookie: ASPSESSIONIDSSDCARRA=OJBNBHIDDICNKDOODCAKBPKJ;HalJini=main
HTTP/1.x 403 Access Forbidden
Server: Microsoft-IIS/5.0
Date: Fri, 09 Jan 2009 07:10:03 GMT
Connection: close
Content-Length: 1873
Content-Type: text/html
Benar kan, error 403 Forbidden. Itu artinya URL itu dilarang keras diakses. Tapi lihat header Cookie pada request yang dilakukan browser. Ternyata cookie ini tetap dikirimkan ke server melalui koneksi http biasa. Ya iya laah, request ini kan ke URL yang masuk dalam domain+path cookie, dan server PermataNet tidak mensyaratkan harus dengan https.
Dengan terjadinya request ini, attacker dengan mudah mengkopi isinya, dan memasukkan ke browsernya sehingga ketika dia membuka halaman PermataNet maka yang terbuka adalah account saya. Sungguh berbahaya!
Pencegahan
Bagaimana cara mencegah agar cookie kita tidak tercuri? Kita harus mengubah cookie PermataNet di browser kita menjadi “Https Only”. Bagi pengguna Firefox ini mudah, dengan Addon Cookie Editor kita bisa bebas meng-edit cookie.
Kesimpulan
Anda telah melihat bahwa men-set bit cookie menjadi https only sangat-sangat penting. Hal ini berbeda bila server tidak membuka koneksi di port 80, sehingga walaupun cookie diset any connection, tetap hanya bisa di https karena port 80 closed.
Selain PermataNet, situs PayPal.com juga mengalami masalah yang sama, silakan investigasi sendiri sebagai latihan dan tuliskan hasilnya sebagai komentar di sini.
Saya yakin banyak situs yang punya masalah serupa. Tambahin dikit dong mengenai bagaimana mendeteksi web2 yang punya kelemahan seperti itu (hint: http://fscked.org/blog/fully-automated-active-https-cookie-hijacking)
@Yohanes Nugroho
halo mas, makasih udah komen.aku nulis ini jg abis baca2 itu,cuman sekilas tapi,blm sempet merhatiin scriptnya dia yg otomatis hijack. Aku baca2 dulu deh,thanks infonya.
gila! dua orang hacker berbicara dalam satu bahasa dan satu situs 😛 heheheh…
wah payah ga bisa di mengerti
Bro, ngehack PermataNet percuma kalo gak punya TIN, untuk bisa transaksi pake PermataNet ada TIN yang harus diinput pada setiap transaksi, TIN berbeda dari PIN. Jadi PermataNet masih tetep yg paling secure.
wew.., ngeri juga yah..,