Mencari bug

Ada yang bertanya ke saya: bagaimana sih caranya mencari bug di aplikasi? Karena jawabannya tidak bisa ditulis singkat di chat, di tulisan kali ini saya akan berusaha menjawab pertanyaan itu.

Apa itu bug?

Kalau Anda disuruh mencari sebuah benda tapi tidak tahu benda itu seperti apa bentuknya maka Anda tidak akan bisa menemukannya (Contoh: tolong ambil logic analyzer di laci saya). Sama halnya dengan bug: pertama pahami dulu berbagai jenis bug yang ada, baru Anda bisa menemukannya.

Contoh-contoh bug web misalnya: SQL Injection, IDOR, XSS, dan command injection. Contoh bug aplikasi misalnya: buffer overflow. Selain tahu apa itu sebuah bug, kita juga perlu tahu bagaimana cara mengeksploitasinya.

Black box testing

Ini testing yang paling umum. Kita coba-coba berbagai input dengan harapan keluar suatu pesan error yang bisa menunjukkan kesalahan di sebuah program. Contoh kecil: jika ada input petik tunggal (‘) dan programnya menampilkan SQL error, maka kemungkinan ada bug SQL injection.

Tentunya coba-coba ini harus yang masuk akal. Ini biasanya tergantung pada: aplikasinya seperti apa, servernya memakai OS apa. Contoh: berusaha melakukan command injection dengan berbagai command Windows di server Linux maka tidak akan berhasil. Berusaha melakukan angular template injection di aplikasi yang tidak memakai Javascript juga tidak akan berhasil.

Intinya: meskipun ini adalah black box testing, yang sepertinya sekeda menebak-nebak, ada hal-hal masuk akal yang bisa kita coba. Jika kita ingin membeli suatu barang, kita bisa mencoba mengganti nilai pembelian, berusaha membypass proses pembayaran, dsb.

White box testing

Jika kita memiliki akses ke source code, maka kita bisa mencari bug dengan membaca source code aplikasinya. Source ini bisa didapat dari beberapa cara:

  • Aplikasinya memang open source (contoh: berbagai aplikasi web seperti WordPress ada source codenya)
  • Dari hasil dekompilasi (contohnya: berbagai game bisa didekompilasi)
  • Dari bug lain (contoh: jika menemukan bug web untuk membaca sebuah file, maka bisa kita manfaatkan untuk membaca source code aplikasi)

Nah di sini kemampuan membaca source code diperlukan. Dengan adanya source code, kita bisa melihat alur program dan menentukan apakah sebuah input dicek atau tidak, dan apakah inputnya bisa dipakai untuk membypass sesuatu atau mengeksekusi apa yang seharusnya tidak boleh dieksekusi.

Memahami Tool

Untuk melakukan testing, kita perlu paham berbagai tool yang sesuai. Contohnya untuk testing aplikasi web, kita sebaiknya memakai intercepting proxy (seperti Burp atau Zaproxy). Dengan memakai tool tersebut, kita bisa mengganti request dari browser atau dari aplikasi baik desktop maupun mobile yang akan berkomunikasi dengan server di internet.

Untuk testing aplikasi mobile, keahlian mengekstrak package, melakuan dekompilasi diperlukan. Berbagai tools yang spesifik juga bisa dipakai (misalnya XPosed Framework di Android, atau Frida di berbagai OS lain).

Fuzzing

Untuk bug jenis tertentu, kita bisa memakai tools untuk melakukan fuzzing. Intinya adalah mencoba-coba berbagai input secara otomatis. Ini bisa diaplikasikan ke aplikasi web, atau bahkan aplikasi desktop (contohnya ada yang namanya AFL). Penggunaan fuzzer ini relatif mudah, tapi hasilnya tetap harus dipahami oleh orang yang memiliki skill.

Otomasi

Sebagian bug bisa ditemukan dengan menggunakan tool otomatis. Saya tidak akan membahas ini secara dalam. Intinya ada beberapa scanner aplikasi web yang bisa menemukan berbagai bug yang umum. Ada juga source code analyzer yang bisa menemukan berbagai masalah di source code.

Penutup

Mencari bug kadang mudah kadang sulit, tergantung program yang kita cari bugnya. Sebagian orang yang meretas web tidak mencari bug khusus, tapi biasanya yang terjadi seperti ini:

  • ada yang menemukan bug di aplikasi tertentu (contoh: Drupal)
  • ada yang membuat exploit untuk bug tersebut
  • script kiddies menggunakan Google untuk mencari website yang memakai Drupal (dengan dorking, misalnya mencari “Powered By …”
  • script kiddies mencoba exploit drupal pada website yang ditemukan

Selamat mencari bug.

Bug Insecure Direct Object References (IDOR)

Bug Insecure Direct Object References (IDOR) ini merupakan bug yang sangat sederhana, sangat umum dan biasanya sangat berbahaya. Intinya pengguna aplikasi bisa mengubah input sedemikian hingga bisa mengakses objek/data yang bukan miliknya.

Bug paling sederhana adalah jika ada URL seperti ini:

http://example.com/edit.php?produk=1

Jika kita ganti produk menjadi 2 (atau nilai lain) dan keluar detail produk yang seharusnya bukan milik kita, itu namanya IDOR. Sering kali bug IDOR tidak bisa dieksploitasi dengan sederhana seperti itu. Biasanya untuk mengeksploitasi bug semacam ini kita akan memanfaatkan intercepting proxy seperti burp suit atau zaproxy (pernah saya bahas di sini).

Kadang kala ketika berusaha mengedit suatu data, kita tidak bisa memakai IDOR, tapi ketika kita menekan tombol “UPDATE” dan datanya di POST ke server, ternyata kita bisa mengedit id produknya. Jadi dalam kasus ini kita bisa menimpa/update produk lain walaupun tidak bisa melihat hasilnya.

Dalam aplikasi mobile, IDOR ini juga banyak ditemui, tapi secara umum lebih sulit dieksploitasi. Pertama kita perlu mensetup proxy, lalu jika aplikasinya melakukan SSL pinning maka perlu dibypass, dan kadang kala di atas itu masih ada enkripsi custom.

IDOR yang tipenya sangat berbahaya adalah dalam aplikasi yang melibatkan uang. Sering kali saya temu kasus di mana kita bisa mengganti id pengirim transaksi sehingga bisa memindahkan uang dari satu account ke yang lain. Kebanyakan kasus ini terjadi pada aplikasi mobile yang mengakses API dari web dan dienkripsi dengan sangat ribet. Proteksi di sisi client sering kali lebih dipentingkan daripada sisi server.

HTTP Cookie dan Session

Ini hal dasar dalam protokol HTTP yang sangat berguna untuk security. Cookie adalah data kecil yang dikirim oleh server ke browser, dan akan dikirimkan kembali oleh browser ketika mengunjungi website yang sama. Analoginya jika kita pergi ke dokter, kita diberi kartu, dan ketika kembali lagi ke dokter tersebut, kita memberikan lagi kartunya supaya bisa dikenali.

Setelah server memberi “Cookie”, browser akan memberikan lagi “Cookie” ke server di request berikutnya

Dalam kasus sebuah kartu berobat, ada beberapa opsi dalam penyimpanan data. Mungkin kita hanya diberi kartu dengan nomor pasien, lalu seluruh datanya disimpan di dalam komputer klinik atau rumah sakit (atau sekedar di sebuah folder khusus).

Sebuah session dalam aplikasi web adalah sejumlah request dan response yang berhubungan. Misalnya: login, memilih barang, membeli barang,. sampai logout. Sesuai analogi kartu yang hanya berisi ID, cookie juga bisa berisi ssession ID saja, yaitu berupa karakter random yang tidak bisa ditebak (jika bisa ditebak, kita bisa seolah-olah menjadi orang lain)

Session ID saja

Dalam kasus lain, misalnya untuk dokter anak, kita diberi buku kecil, dan data mengenai anak disimpan di buku itu. Contohnya adalah data mengenai perkembangan berat badan anak. Bagusnya dengan buku seperti ini, kita bisa membawanya ke dokter anak manapun. Dalam kasus Cookie: jika data disimpan di client, maka jika sebuah domain memiliki banyak server, maka tidak perlu sinkronisasi data antar server atau memakai database terpusat.

Data cookie di client, dilindungi dengan signature

Ketika sebuah aplikasi web butuh menyimpan data seseorang yang sedang login, maka biasanya yang dipakai adalah Cookie. Cookie ini bisa sekedar berisi informasi session id (dengan seluruh data ada di server), bisa juga berisi datanya langsung. Karena cookie bisa diedit, maka sebuah aplikasi yang aman akan menambahkan digital signature (pernah saya bahas di sini) atau bahkan datanya semuanya dienkrip.

Ada banyak aturan detail mengenai Cookie, yang meliputi:

  • di domain mana cookie berlaku, apakah hanya di domain utama atau sub domain (analoginya: kartu buat dokter kulit di klinik ini apakah berlaku juga buat dokter gigi?). Dan juga apakah hanya untuk path tertentu (misalnya cookie untuk URL /pembelian/ apakah akan dikirimkan untuk /penjualan)
  • kapan masa berlaku cookie?
  • apakah cookie bisa diakses Javascript
  • apakah cookie yang diset dalam mode HTTPS harus dikirim balik ketika memakai mode HTTP?

Berbagai hal detail tersebut bisa jadi masalah security. Beberapa masalah security lain adalah:

  • pencurian cookie (misalnya dengan XSS/Cross Site Scripting)
  • pengeditan cookie atau pembuatan cookie palsu. Ini hanya terjadi kalau cookienya tidak aman (contoh kasus adalah cookie JWT yang menerima alg none)

Detail mengenai pengeditan cookie ini bisa cukup panjang, jadi tidak akan saya tuliskan di sini. Secara umum bug yang berhubungan dengan cookie sangat bergantung pada framework dan bahasa pemrograman yang dipakai.

Demikian penjelasan singkat mengenai cookie. Sebaiknya buatlah web kecil untuk memahami berbagai perilaku cookie ini agar lebih mengerti, baik dari sisi server maupun sisi client. Install juga program untuk mengedit cookie di browser (atau gunakan intercepting proxy) untuk lebih memahami lagi semuanya.

Security untuk pemula: POST dan GET

Kadang saya merasa lucu membaca komentar dari posting saya. Kalau postingnya terlalu kompleks (seperti berbagai hal yang yang saya tuliskan di blog saya yang berbahasa inggris: tinyhack.com), sedikit sekali yang paham jadi kurang ada komentar yang membangun. Sedangkan jika terlalu sederhana, seperti posting sebelumnya, banyak yang “protes”, atau malah nggak percaya.

Beberapa komentar yang muncul misalnya:

  • Masak bank securitynya seperti itu?
  • Itu kan POST, kok diakses pake GET?

Untuk hal pertama: jangan pikir security bank itu sangat ketat. Untuk hal kedua: sepertinya banyak pemula kurang paham mengenai POST dan GET, dan perlu penjelasan lebih lanjut.

Untuk sistem core banking biasanya cukup dijaga ketat, tapi berbagai sistem disekitarnya tidak demikian. Alasannya:

  • Tidak semua modul dikerjakan oleh internal bank, kadang oleh pihak ketiga
  • Tidak semua bank menyewa pentester atau punya ahli security
  • Tidak semua ahli security atau pentester kerjanya bener
  • Kadang sudah ada SOP internal untuk security tapi dibypass karena “harus tayang hari ini”

Bahkan ketika pentesting, sudah beberapa kali saya menemukan bug super parah di beberapa bank seperti:

  • Bisa transfer dari siapa saja ke siapa saja, termasuk keluar bank
  • Root access di server utama
  • Mendapatkan source code ibanking beberapa bank
  • Akses ke firewall utama bank

Karena posisi saya di Thailand, itu semua akses dari eksternal (bukan testing jaringan internal bank). Jadi bug super parah itu bisa diakses dari luar bank.

Nah sekarang ke pelajaran teknisnya: mengenai request POST dan GET. Secara umum kedua request ini ada dengan tujuan berbeda:

  • GET untuk request yang idempoten (artinya boleh diulangi)
  • POST untuk request yang tidak idempoten, dan umumnya ukuran datanya lebih besar

Di dalam program, kita bisa mengakses isi variabel dari POST dan GET secara terpisah. Tapi di berbagai bahasa pemrograman, kita bisa meminta agar mengakses variabel dari POST (jika ada), lalu GET (jika ada), atau bahkan dari cookie jika ada. Catatan: urutannya tidak harus seperti itu, di berbagai bahasa bisa dikonfigurasi

Misalnya di PHP: $_POST untuk mengakses post, dan $_GET untuk mengakses get. Dan ada $_REQUEST untuk mengakses GET atau POST atau Cookie.

Jadi jika ada request POST ke URL /data/?a=5 dan di dalam data POST ada a=7, maka $_GET["a"] pasti 5, $_POST["a"] pasti 7, dan $_REQUEST["a"] bisa 5 atau 7 tergantung setting variables_order di PHP. Defaultnya adalah nilai GET tapi jika ada nilai POST yang sama, maka akan diganti dengan nilai dari POST.

Bagaimana dengan bahasa lain? sama saja, tergantung framework yang dipakai. Contoh: di framework Flask untuk python ada requests.args untuk GET, requests.form untuk POST, dan request.values untuk POST atau GET (nilai GET akan dipakai jika ada nilai sama antara POST dan GET).

Lalu apa gunanya tahu ini?

Beberapa pengecekan security hanya di level URL atau GET saja. Jadi kadang jika dicek di URL, dan kita ganti jadi request POST, hasilnya jadi lolos. Kadang saya mengetes apakah method POST (seperti dalam posting sebelumnya) bisa diakses juga via GET. Jika bisa, ini memudahkan testing cepat dengan browser.

Dalam kasus tertentu: satu method memakai spesifik $_GET (yang diperiksa adalah isi variabel $_GET["q"] misalnya), lalu di method lain memakai $_REQUEST["q"]. Jika URL dipanggil dengan GET, maka kedua variabel tersebut sama, tapi jika dipanggil dengan POST dengan variabel "q" maka sesuai default PHP, isi $_GET["q"] menjadi berbeda dengan $_REQUEST["q"].

Untuk lebih jelasnya lihat contoh berikut ini. Bisa dilihat source code programnya, lalu programnya diberi request GET dan POST dengan curl. Bisa terlihat bedanya.

Karena mengubah POST/GET ini adalah hal yang umum, banyak yang membuat skrip untuk ini. Misalnya di skrip zaproxy sudah ada yang membuat untuk mengubah POST menjadi GET

Sesuai judulnya: ini hanya membahas bagian dasar sekali mengenai POST dan GET. Saya belum masuk ke berbagai hal/trik lain yang berhubungan dengan request, misalnya:

  • Memakai method lain (PATCH/PUT, dsb)
  • Mengganti content type ketika melakukan post (misalnya dari JSON ke XML)
  • Melakukan injection di semua header (misalnya user agent)

Berbagai hal tersebut mungkin akan saya bahas di posting lain.

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.