Deface, Sniffing, Hijacking

Teknik Web Deface

dan Cara

Pencegahannya

Posted by: foruminformatika on: September 30, 2007

• In: Security
• Comment!

Published on http://batampos.co.id/content/view/31768/98/
Beberapa minggu lalu, ketika masalah pemukulan warga negara Indonesia oleh polisi Malaysia, dunia internet Indonesia ramai oleh kelakuan para hacker merusak tampilan situs-situs yang berdomain Malaysia.

Juga beberapa bulan lalu ketika krisis Ambalat berlangsung, kedua kubu saling serang web deface.
Deface adalah teknik mengganti atau menyisipkan file pada server, teknik ini dapat dilakukan karena terdapat lubang pada sistem security yang ada di dalam sebuah aplikasi.

Defacer website dapat merubah tampilan sebagian atau seluruhnya tergantung kemauan defacer dan lubang yang bisa dimasuki, namun jika dia sudah putus asa, defacer akan melakukan denial of servis (DoS) attack yaitu mengirimkan request palsu pada server yang berlebihan sehingga kerja server lambat dan lama-kelamaan server akan crash dan down. Untuk dapat melakukan web deface, defacer melakukan beberapa tahap sebagai berikut :

a. Mencari kelemahan pada sistem security, menemukan celah yang dapat dimasuki untuk melakukan eksplorasi di server target. Dia akan melakukan scanning tentang sistem operasi, service pack, service yang enable, port yang terbuka, dan lain sebagainya. Kemudian dianalisa celah mana yang bisa dimasuki.
b. Melakukan penyusupan ke server korban. Teknik ini dia akan menggunakan beberapa tools, file yang akan disisipkan, file exploit yang dibuat sengaja untuk di-copy-kan. Setelah berhasil masuk , tangan-tangan defacer bisa mengobok-obok isi server.
Tapi tidak adil kiranya jika hanya sharing tentang teknik deface web. Maka untuk pengelola situs harus waspada, karena deface bisa jadi bencana yang sangat merepotkan. Pekerjaan menata ulang dan memperbaiki bagian yang rusak, bukan pekerjaan yang mudah. Karena itu sebelum situs anda digerayangi seyogyanya melakukan langkah-langkah preventif sebagai berikut :
1. Rutin melakukan update, upgrade dan patch pada sistem operasi dan aplikasi-aplikasi yang dipakai.
2. Memeriksa ulang dan memperbaiki konfigurasi pada sistem operasi, web server dan aplikasi lainnya.
3. Menganalisa kembali service-service yang aktif, matikan jika tidak perlu.
4. Mengatur jadwal untuk melakukan backup data penting, file konfigurasi sistem, database, sehingga jika sewaktu-waktu terjadi deface, anda tinggal menggunakan data backup.
5. Melindungi server dengan firewall dan IDS. Kedua tools ini ampuh untuk mengatasi serangan denial of service(DoS) attack.
6. Selalu memperhatikan hal-hal yang mencurigakan pada server, baca log system operasi, log web server ataupun log aplikasi.
7. Melakukan vulnerability scanning secara rutin, juga melakukan private security test.
Demikian beberapa trik, baik melakukan deface (meskipun tak secara detail/teknis) maupun menangkal deface. Semoga website anda aman dari serangan para hacker

Sniffer Paket

Dari Wikipedia bahasa Indonesia, ensiklopedia bebas

Langsung ke: navigasi, cari

Sniffer Paket (arti tekstual: pengendus paket — dapat pula diartikan 'penyadap paket') yang juga dikenal sebagai Network Analyzers atau Ethernet Sniffer ialah sebuah aplikasi yang dapat melihat lalu lintas data pada jaringan komputer. Dikarenakan data mengalir secara bolak-balik pada jaringan, aplikasi ini menangkap tiap-tiap paket dan terkadang menguraikan isi dari RFC (Request for Comments) atau spesifikasi yang lain. Berdasarkan pada struktur jaringan (seperti hub atau switch), salah satu pihak dapat menyadap keseluruhan atau salah satu dari pembagian lalu lintas dari salah satu mesin di jaringan. Perangkat pengendali jaringan dapat pula diatur oleh aplikasi penyadap untuk bekerja dalam mode campur-aduk (promiscuous mode) untuk "mendengarkan" semuanya (umumnya pada jaringan kabel).

Sniffer paket dapat dimanfaatkan untuk hal-hal berikut:

• Mengatasi permasalahan pada jaringan komputer.
• Mendeteksi adanya penyelundup dalam jaringan (Network Intusion).
• Memonitor penggunaan jaringan dan menyaring isi isi tertentu.
• Memata-matai pengguna jaringan lain dan mengumpulkan informasi pribadi yang dimilikanya (misalkan password).
• Dapat digunakan untuk Reverse Engineer pada jaringan.

Sniffing SSL Traffic using oSpy

April 17th, 2009 By Rizki WicaksonocloseAuthor: Rizki Wicaksono Name: Rizki Wicaksono
Email: rizki@ilmuhacking.com
Site: http://www.ilmuhacking.com/
About: See Authors Posts (33)

Goto comments Leave a comment

SSL menjamin confidentiality data dari endpoint ke endpoint, itu artinya di tengah jalan tidak ada pihak ke-3 yang bisa menyadap data yang dikirimkan. Nah, kalau di tengah jalan tidak bisa disniff, bagaimana dengan sniffing di salah satu endpoint, baik di komputer klien atau server? Itulah yang akan saya tunjukkan dalam artikel ini.

SSL: The Secure Tunnel for All

SSL adalah protokol yang menjamin confidentiality dan authentication komunikasi dari satu titik awal ke titik akhir. Data apapun yang dilewatkan melalui SSL dijamin aman dari pengintip di tengah jalan karena semua data dikirim dalam keadaan terenkripsi. Karena itu SSL sering dijadikan terowongan (tunnel) untuk membuat protokol lain yang tidak secure menjadi secure.

Contoh pemakaian SSL sebagai tunnel adalah pada https. Http sejatinya adalah protokol clear text, artinya semua request dan response http yang lewat tidak terenkripsi dan bisa disadap siapapun yang berminat. Namun untuk web tertentu yang sensitif seperti bank memerlukan jaminan confidentiality, oleh karena itu protokol Http ini dibungkus dan dilewatkan tunnel SSL, sehingga menjadi apa yang dikenal sebagai https yaitu http tunneled over SSL. Penjelasan lebih detil tentang https bisa dibaca di understanding https. Masih banyak protokol lain yang bisa dilewatkan tunnel SSL, antara lain IMAP, SMTP, POP, LDAP.

Sniffing at Endpoint

SSL memang menjamin keamanan sepanjang perjalanan dari titik asal menuju titik tujuan. Data yang terkirim dari dan ke komputer klien/server dijamin keamanannya karena terenkripsi. Kalau ada attacker yang mencoba mengintip data di tengah perjalanan, data yang dia dapatkan adalah data yang terenkripsi, bukan plain-text, sehingga tidak ada gunanya mengintip data yang dilindungi SSL.

Jaminan keamanan SSL hanya berlaku dari titik A ke titik B (end-to-end). Pertama saya harus jelaskan dulu apa yang dimaksud dengan titik. Titik disini adalah aplikasi atau program komputer yang berjalan di atas operating system, contohnya adalah browser, instant messenger, outlook. Aplikasi ada yang berfungsi sebagai client dan ada pula yang sebagai server.

Agar data yang dikirimkan aman, aplikasi tersebut harus melakukan enkripsi data terlebih dahulu sebelum mengirimkan data ke tujuan. Begitu pula dari titik penerima, data yang diterima harus dikenakan proses dekripsi agar bisa dimengerti dan bisa diproses. Proses tersebut digambar seperti pada gambar berikut ini:

simplified SSL data flow

Pada gambar di atas, dicontohkan yang menjadi titik adalah browser sebagai client dan web server sebagai server. Pada saat paket data diserahkan dari aplikasi ke network adapter (ethernet, wifi adapter dsb), paket tersebut sudah dalam keadaan terenkripsi. Jadi dalam aplikasi yang memakai SSL data yang dikirim dan diterima dalam keadaan terenkripsi, namun justru dalam aplikasinya sendiri data masih dalam keadaan tidak terenkripsi.

Data hanya aman ketika berada di luar rumah, justru di dalam rumah data tidak terlindungi enkripsi

Karena data hanya aman ketika berada di luar rumah (proses/aplikasi), maka ada peluang bagi aplikasi/proses lain yang memiliki hak akses yang cukup untuk melakukan sniffing ketika data masih berada di dalam rumah. Salah satu skenario attack yang mungkin adalah: dalam sistem operasi multi user seperti linux dan windows, ada satu user yang dipakai beberapa orang. Dalam kondisi ini ketika ada orang yang sedang browsing, maka orang lain dengan user yang sama bisa mengintip isi rumah browser korban. Hal ini dimungkinkan karena kedua orang tersebut login dengan user yang sama. Jadi walaupun korban sedang login mengggunakan https (SSL) di browser tersebut, attacker tetap bisa melakukan sniffing dengan cara masuk langsung ke dalam rumah proses browser korban.

Sniffing Google Talk SSL Traffic

Agar lebih jelasnya mari kita langsung praktek mencoba sniffing SSL google talk di komputer yang sama. Sebelumnya anda harus sudah berhasil download oSpy. Kemudian silakan extract dan jalankan file oSpy.exe. Untuk dapat melakukan sniffing proses saya harus menginjeksi agen ke dalam proses tersebut. Agen ini mirip dengan mata-mata yang disusupkan ke daerah lawan agar saya bisa mendapatkan informasi segala sesuatu tentang lawan. Agen yang disusupkan ke proses googletalk.exe ini akan memberikan saya informasi fungsi apa saja yang dijalankan oleh sebuah proses.

Untuk menginjeksi agen, di dalam oSpy, klik menu Capture kemudian pilih menu Inject Agent. Silakan pilih proses yang akan diintip, dalam contoh ini saya memilih googletalk.exe. Setelah memilih proses, kemudian klik tombol Inject. Proses injeksi agen diperlihatkan pada gambar di bawah ini.

injecting agent

Setelah agen berhasil disusupkan ke sebuah proses, kini tiba saatnya untuk mengantifkan modus mata-mata, caranya adalah dengan klik menu Capture, kemudian pilih Start. Setelah itu saya coba login ke googletalk,kemudian saya klik Stop Capture untuk melihat hasil capture. Mari kita lihat informasi apa saja yang dikirimkan oleh agen yang saya susupkan ke daerah musuh.

captured information

Dalam gambar di atas terlihat informasi yang dikirim oleh agen rahasia saya. Google talk menggunakan https untuk melakukan authentication. Walaupun menggunakan https, namun agen rahasia saya mampu membaca paket http yang dikirimkan ke google dan yang diterima dari google.

POST /accounts/ClientAuth HTTP/1.1
Connection: Keep-Alive
Content-Length: 171
Content-Type: application/x-www-form-urlencoded
Host: www.google.com:443
User-Agent: Google Talk

Email=rizki.wicaksono%40gmail.com&Passwd=%74%65%73%74%69%6E%67%70%61%73%73%77%6F%72%64&PersistentCookie=false&source=googletalk&accountType=HOSTED_OR_GOOGLE&skipvpage=true

Request POST tersebut mengirimkan username dan password saya dalam bentuk url encoded ke https://www.google.com. Namun karena username dan password salah, maka response yang didapatkan adalah 403 Forbidden. Kalau password benar, response status code adalah 200 OK.

Pada gambar tersebut juga terlihat bahwa sebelum googletalk mengirimkan data, dia memanggil fungsi EncryptMessage() yang gunanya mengenkrip pesan yang akan dikirim ke web server google. Begitu pula sebaliknya, data yang diterima dari web server google diterima oleh fungsi recv() setelah itu diikuti dengan fungsi DecryptMessage() yang gunanya mendekrip pesan yang diterima dari web server google.

Kesimpulan

SSL adalah protokol yang sangat bagus karena bisa menjamin keamanan data dari titik ke titik. Namun keamanan data di titik itu sendiri tidak bisa dijamin SSL karena itu adalah domain dari keamanan sistem operasi. Dengan menggunakan oSpy saya bisa mengintip komunikasi SSL yang dilakukan sebuah aplikasi/proses. Komunikasi SSL tidak bisa diintip dengan menggunakan network sniffer seperti wireshark(ethereal) walaupun sniffer dijalankan di komputer yang sama dengan aplikasi. Kenapa network sniffer tidak berguna walau di komputer yang sama? Hal ini karena sniffer bekerja di layer physical dengan mengubah network adapter ke modus promiscious. Dalam gambar sebelumnya saya jelaskan bahwa data yang dikirimkan melalui network layer (physical layer) adalah hasil dari fungsi EncryptData(), yang artinya data tersebut sudah dalam bentuk terenkripsi, walaupun masih dalam satu komputer yang sama.

Dalam aplikasi yang menggunakan SSL, data hanya aman ketika berada di luar rumah (di luar process address space), sehingga data yang dikirim ke luar melalui network adapter sudah dalam keadaan terenkripsi. Untuk dapat melakukan sniffing SSL saya harus melakukan itu di dalam rumah (di dalam proses itu sendiri). Dalam gambar sebelumnya saya menjelaskan bahwa sebelum memanggil fungsi send(), proses memanggil fungsi EncryptData(). Fungsi inilah yang saya target karena fungsi ini mengubah plaintext menjadi ciphertext, plaintext inilah yang dilaporkan kepada saya oleh agen mata-mata saya (ospy).

Attack dengan oSpy ini akan efektif bila attacker telah mendapatkan akses penuh di sebuah komputer. Untuk menyadap password internet banking pengguna, bila keylogger tidak berguna karena user menggunakan virtual keyboard, bila FFSniff juga tidak berguna karena user tidak memakai Firefox, maka oSpy akan sangat berguna

Session Hijacking Basics

January 3rd, 2009 By Rizki WicaksonocloseAuthor: Rizki Wicaksono Name: Rizki Wicaksono
Email: rizki@ilmuhacking.com
Site: http://www.ilmuhacking.com/
About: See Authors Posts (33)

Goto comments Leave a comment

What really is Session?

Bayangkan ketika anda nonton bioskop, lalu tiba-tiba di tengah pertunjukan anda ingin ke toilet yang letaknya di luar studio. Setelah anda selesai dari toilet, menurut anda apakah anda dibolehkan masuk atau diminta membeli tiket lagi? Bila anda diminta membeli tiket lagi, berarti dia “lupa” bahwa anda adalah penonton yang sah. Bagaimana cara penjaga pintu studio mengingat bahwa anda adalah pentonton yang sah? Saking banyaknya pentonton tidak mungkin penjaga hafal wajah tiap penonton. Maka cara yang dipakai adalah dengan bukti berupa tiket masuk.

Itulah ilustrasi dari session. Mulai bioskop memutar film sampai selesai adalah satu sesi. Setiap penonton bebas keluar masuk studio selama sesi masih berlangsung, namun setelah sesi selesai, penonton tidak boleh lagi masuk studio. Karena penjaga pintu studio tidak mungkin mengingat setiap penonton, maka diperlukan bukti berupa tiket.

HTTP adalah protokol yang sifatnya stateless, artinya setiap transaksi request dan response adalah bebas, tidak ada hubungannya dengan transaksi sebelum atau sesudahnya. Server tidak mungkin mengingat dan mengetahui bahwa transaksi X dan transaksi Y dilakukan oleh orang yang sama.

Session Identifier is Your Ticket

Seperti pada ilustrasi bioskop, untuk membantu penjaga pintu studio mengetahui setiap penonton yang masuk adalah penonton yang sah diperlukan bukti berupa tiket. Dalam HTTP, tiket bioskop itu berupa session identifier yang tidak lain adalah untaian karakter dan angka yang panjang dan acak.

Ketika pengunjung pertama kali datang, server akan memberikan tiket berupa session id. Ketika server menerima request dari pengunjung yang membawa session id, server akan memeriksa apakah session id itu valid. Jika session id valid, maka server yakin bahwa request ini datang dari “returning visitor” bukan orang asing. Ingat ilustrasi bioskop di awal, ini seperti penjaga pintu studio yakin bahwa anda adalah penonton yang kembali masuk setelah sebelumnya keluar ke toilet.

Ada 2 media untuk membawa sessionid, yaitu cookie dan URL. Cookie biasanya berupa file text yang disimpan oleh browser dan dikirimkan kembali ke server bersama setiap request. Sedangkan sessionid yang dibawa melalui URL umumnya berbentuk parameter seperti ?sessionid=123123 .

Server umumnya memberikan sessionid melalui cookie karena cara ini lebih aman dari cara URL.

Web Application Session

Dalam web aplikasi umumnya pengunjung diharuskan memasukkan username dan password, setelah itu baru pengunjung bisa menikmati beragam fasilitas yang diberikan sampai pengunjung melakukan logout. Mari kita lihat apa yang terjadi ketika pengunjung melakukan login.

Ketika pengunjung memasukkan username (katakanlah “Budi”) dan password yang benar, web server akan memberikan tiket berupa sessionid katakanlah “1234″. Kemudian dalam database akan dicatat bahwa sessionid “1234″ adalah milik seorang pengunjung yang bernama “Budi”. Setiap kali ada request yang membawa tiket sessionid “1234″, server yakin bahwa request itu adalah dari pengunjung yang namanya adalah “Budi”. Tiket ini akan terus valid sampai suatu saat “Budi” melakukan logout. Setelah logout, ketika ada request dengan sessionid “1234″, maka server akan tahu bahwa sessionid itu sudah tidak valid, dan memaksa anda login.

Stealing Session

Bayangkan bila ketika anda keluar bioskop untuk ke toilet, tiket anda jatuh dan saya temukan. Lalu saya masuk ke studio dengan tiket itu, apakah saya diijinkan masuk? Tentu saja boleh! Karena saya memegang bukti tak terbantahkan berupa tiket. Sedangkan anda yang kehilangan tiket tidak akan boleh masuk studio karena penjaga studio tidak hafal wajah anda.

Itulah yang akan terjadi bila seseorang mencuri sessionid. Jika anda sedang baca email dan sessionid anda dicuri orang lain, maka orang lain itu akan bisa juga membaca email anda dan server akan yakin bahwa orang lain itu adalah anda.

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

Bagaimana cara mendapatkan sessionid korban? Secara garis besar ada 3 kategori teknik untuk mendapatkan sessionid, yaitu predict, capture dan fixate.

1. Predict

Teknik ini mirip dengan judi togel, yaitu dengan cara menebak-nebak angka. Kemungkinan berhasilnya tergantung dari tingkat ke-acak-an sessionid. Bila sessionid tidak cukup random, bahkan cenderung mengikuti suatu pola, maka kemungkinan sessionid bisa ditebak. Namun umumnya sessionid sekarang sudah menggunakan fungsi random dan ukurannya panjang, sehingga kecil kemungkinan berhasil dengan cara ini (jauh lebih mudah menebak togel yang cuma 4 angka, daripada menebak sessionid).

2. Capture
   • (Passive) Sniffing.

     Menyadap komunikasi http antara browser korban dan server web. Teknik ini sangat mungkin dilakukan untuk situs yang tidak dilindungi https karena paket http tidak ter-enkripsi.

   • Man-in-them-middle (MITM).

     Situs dengan https tidak bisa disniff secara passive. Man-in-the-middle attack diperlukan untuk sniffing komunikasi antara browser korban dan server yang dilindungi https. Namun tanpa sertifikat yang di-sign CA yang dipercaya browser, serangan ini mudah dicegah karena browser akan memberi warning bahwa sertifikat attacker tidak bisa dipercaya.

   • Cross Site Request Forgery (CSRF).

     CSRF attack bertujuan untuk membuat korban melakukan request yang mengandung sessionid. Bila sessionid disimpan dalam cookie, maka request akan mengandung sessionid dalam header cookie. (baca contoh PoC-nya di membajak session https permatanet). Bila sessionid disimpan dalam URL (url rewriting), maka request akan mengandung sessionid dalam header referer.
     

   • Cross Site Scripting (XSS).

     XSS dilakukan dengan cara meng-injeksi code javascript (client side script) yang akan dieksekusi oleh browser korban. Code javascript ini bertujuan mengirimkan cookie ke server yang sudah disiapkan attacker. Baca contoh PoC-nya di menjaring password klikBCA dengan XSS.

3. Fixate.

   Kalau menebak dan menyadap sessionid sulit dilakukan, maka cara lain adalah dengan memaksa korban menggunakan sessionid yang sudah dipilih sebelumnya oleh attacker. Serangan ini disebut dengan session fixation attack.

Session Telkom.net

Anda ingin tahu bagaimana rasanya mencuri session? Benarkah bila anda mendapatkan sessionid orang lain, maka anda bisa menjadi orang lain? Untuk membuktikannya, anda harus mencoba sendiri. Contoh kasus yang mudah adalah dalam session webmail telkom.net.

Saya pakai contoh telkom.net karena telkom.net menyimpan sessionid dalam URL, bukan dalam cookie sehingga lebih mudah untuk contoh. Jika anda login ke webmail telkom.net, maka URL anda akan tampak seperti ini:

http://mail.telkom.net/Session/1348362-ri33mMyYqlqEBizKv9lW-kmbcuww/Mailbox.wssp?Mailbox=INBOX

Dalam URL di atas sessionid adalah 1348362-ri33mMyYqlqEBizKv9lW-kmbcuww. Coba saja klik URL di atas. Anda akan melihat halaman login telkom.net dengan pesan error: Anda telah disconnect dari server. Silakan login kembali. Hal itu terjadi karena anda mengakses webmail dengan sessionid yang sudah tidak valid karena sudah pernah logout.

Untuk merasakan mencuri session, coba saja buat account sendiri di mail.telkom.net, kemudian login. Setelah anda berhasil login, copy URL anda lalu berikan URL itu pada teman anda melalui Yahoo Messenger atau Email. Jika teman anda mengklik URL itu, maka teman anda otomatis menjadi anda dan bisa melakukan semua hal yang bisa anda lakukan. Atau anda bisa membuka URL anda di browser yang berbeda, hasilnya akan sama saja, di browser yang lain juga akan terbuka email anda.

Sekarang coba anda logout. Setelah logout, anda buka kembali URL yang sudah anda copy sebelumnya. Kini anda tidak bisa lagi membuka email anda karena sessionid sudah tidak valid.

Kesimpulan

Anda telah mengerti tentang session dan melakukan pencurian session dengan cara manual “Copy-Paste”. Karena artikel ini hanyalah introduction maka saya tidak menjelaskan tentang teknik pencurian session yang lebih canggih. Dalam artikel lainnya saya akan jelaskan teknik pencurian session yang lebih canggih.