Seputar Bug Hunter, Bug Bounty Program dan Tips Pembuatan Laporan Kerentanan yang Baik

(FEATURE) - Cyber Securiy based on Experience. 

DISCLAIMER: Tulisan ini dibuat sebagai edukasi terkhusus bagi para bug hunter. Buat belajar lebih dalam tentang Cyber Security bisa baca Convert Cyber Security Into MONEY dan untuk Bug Bounty bisa baca Bug Bounty: An Introduction to Earning Money as an Ethical Hacker SECRY

Bug Bounty Program merupakan inisiatif perusahaan untuk mengapresiasi temuan celah keamanan dari ethical hacker berupa reward. Penggiat dari program bug bounty disebut juga bug hunter yang mana dalam bahasa Indonesia berarti pemburu bug atau penguji bug yang pekerjaannya adalah mencari, meneliti dan menguji celah keamanan pada aplikasi, sistem ataupun layanan tertentu. 

Program bug bounty sangat berguna bagi perusahaan sebagai developer. Melalui program ini perusahaan dapat menemukan kerentanan lebih awal sebelum pihak yang tidak bertanggung jawab menemukan dan mengeksploitasinya hingga menimbulkan kerugian yang signifikan bagi perusahaan. Melalui program ini, perusahaan juga dapat menerapkan kontrol keamanan secara berkelanjutan.

Selain berguna bagi perusahaan, program bug bounty juga menguntungkan seorang bug hunter. Karena pada dasarnya tujuan dari program ini bagi seorang bug hunter adalah untuk mendapatkan sebuah imbalan tertentu. Imbalan yang dimaksud tidak hanya dalam bentuk finansial tetapi juga bisa dalam bentuk sertifikat penghargaan, pengakuan berupa rekomendasi (biasanya melalui LinkedIn) atau pengalaman. 

Jika kegiatan ini dilakukan dengan benar dan etis maka dapat memberikan banyak manfaat. Namun jika dilakukan secara sembarangan dan tidak bertanggung jawab bisa berbahaya karena bisa dikategorikan sebagai cyber crime dan tidak sedikit dari bug hunter yang dapat berakhir di dalam jeruji akibat hal ini. 

Beberapa program bug bounty diadakan oleh perusahaan baik itu secara mandiri atau biasa disebut dengan private bug bounty program ataupun bisa juga lewat platform tertentu. Ada beberapa platform bug bounty yang cukup terkenal dan terbukti memberikan reward diantaranya seperti Hackerone, Bugcrowd, Redstorm.io,  cyberarmy.id, cobalt.io, bugbounty.jp, hackenproof, antihack.me, zerocopter dan masih banyak lagi.

PENTINGNYA KEMAMPUAN BERKOMUNIKASI YANG BAIK DALAM MELAPORKAN BUG

Komunikasi antara bug hunter dengan developer dalam sebuah laporan bug adalah salah satu hal penting saat bug hunter hendak menyampaikan sebuah kerentanan baik saat berkontribusi di dalam program bug bounty resmi yang diadakan ataupun di dalam pekerjaan yang lebih legal yaitu pentester dan sejenisnya.  

Informasi tentang fungsi dari sebuah fitur disertai dengan letak permasalahan (kerentanan) dari fitur yang dimaksud, merupakan suatu hal dasar yang perlu disajikan oleh para penguji ke developer dengan harapan dapat memberikan informasi yang optimal dalam memahami dampak serta rekomendasi perbaikan (remediation) yang ada.

Namun demikian, sayangnya tidak sedikit para bug hunter yang cukup kesulitan dalam berkomunikasi dengan developer. Hal ini biasa terjadi misal ketika bug hunter ingin menghubungi developer terkait saat pertama kali menemukan celah keamanan. 

Ini juga termasuk sulitnya merangkai suatu laporan sehingga berujung pada beberapa situasi kurang baik seperti kurang pahamnya penerima laporan dalam memahami kerentanan maupun dampak dari kerentanan terkait. Misalkan saja ketika pada akhirnya seorang bug hunter membuat laporan yang sifatnya terlalu umum dan tidak memberikan petunjuk terhadap akar dari suatu permasalahan. 

Selain itu dalam beberapa kasus ada juga seorang penguji yang tidak bisa menjalin komunikasi yang baik dengan  developer karena tidak memperhatikan etika-etika dalam melaporkan sebuah permasalah terkait celah keamanan pada product scope yang dimiliki.

Pada umumnya, developer sebagai penerima laporan akan mengalami kesulitan yang berarti dalam mengidentifikasi suatu permasalahan sebagaimana yang telah dipaparkan sebelumnya. Terkadang ada juga security team (sebutan bagi tim keamanan sistem) sebagai penerima bukanlah tim developer sebagai pembuat. Sehingga di dalam realitanya, mereka tetap akan memerlukan waktu untuk memahami isi laporan dan flow dari objek yang dianggap rentan. 

BERKURANGNYA BOUNTY DAN BEBERAPA ISTILAH DALAM PROGRAM BUG BOUNTY: NOT APPLICABLE, INFORMATIVE DAN DUPLICATE

Ketika seorang bug hunter gagal mengkomunikasikan celah keamanan yang ada, maka bukan tidak mungkin bila nilai bounty yang diperoleh akan berkurang dari nilai yang seharusnya didapat. Pada situasi lain, bahkan sangat memungkinkan ketika kesempatan memperoleh bounty ini menjadi hilang. Dan yang terburuk apabila developer malah menganggap tindakan yang dilakukan bug hunter adalah ilegal.

Masalah lain mungkin saja muncul apabila penutupan kerentanan yang tidak efektif atau memungkinkan munculnya kerentanan baru. Dan masih banyak lagi kemungkinan-kemungkinan lain yang dapat muncul, seperti berkurangnya prioritas untuk laporan ditanggapi oleh pemilik program atau bahkan tidak dipercayanya bug hunter untuk melakukan uji celah keamanan yang ada dan mengancam karir serta dari bug hunter itu sendiri.

Dalam program bug bounty terdapat istilah-istilah untuk penutupan laporan dengan indikasi bahwa suatu laporan bug tidak dapat diterima, invalid, tidak terlalu berbahaya ataupun tidak layak menerima bounty yang biasa disebut dengan closed report state diantaranya sebagai berikut:

1) Informative

Status ini diberikan apabila laporan bug berisi informasi yang berguna tetapi tidak menjamin tindakan segera atau perbaikan. Contoh laporan informatif meliputi:
- Pemberitahuan tautan rusak
- Masalahnya tidak dapat direprocude secara konsisten

- Celah keamanan yang dilaporkan tidak terlalu membahayakan sistem utama.
Dalam status ini sebuah program dapat mempertimbangkan untuk memberikan penilaian risiko alternatif atau faktor mitigasi lainnya. Kemudian laporan menjadi disclosed (laporan dibuka ke publik) atas dasar kesepakatan bersama setelah bug dianggap telah selesai dan tidak lagi memerlukan informasi tambahan dari bug hunter. 

2)  Duplicate

Merupakan status yang diberikan setelah laporan bug ternyata telah dilaporkan oleh bug hunter lain. Program dapat membangun kepercayaan dengan mengaitkan masalah dengan penemu aslinya dan menautkannya ke laporan sebelumnya atau menyertakan detil lain tentang penemuannya. Pengungkapan publik tidak tersedia untuk status ini.

Catatan: Jika bug hunter mengarsipkan duplikat laporan publik, reputasi mereka akan turun.

3) Not Applicable

Not Applicable atau N/A merupakan status yang terjadi ketika sebuah laporan tidak berisi masalah yang valid dan tidak memiliki implikasi keamanan. Dalam hal ini tim keamanan atau perusahaan penyelenggara program harus menjelaskan mengapa laporan itu tidak valid, sehingga peretas dapat meningkatkan keterampilan meretas mereka. Dalam beberapa kasus laporan bug dianggap N/A tidak selalu karena laporan tidak valid, terkadang hal ini bisa terjadi karena kurangnya keterampilan bug hunter untuk melaporkan celah bug secara baik dan benar sehingga bug tersebut gagal direproduce dan dianggap Not Applicable atau N/A.

TIPS MELAPORKAN CELAH KEAMANAN ATAU MENULIS LAPORAN BUG BOUNTY

Dalam melaporkan celah keamanan ada beberapa hal yang harus diperhatikan agar laporan yang kita kirimkan dapat dipahami dan dianggap valid oleh developer atau perusahaan penyelenggara bug diataranya seperti:

1. Pemberian Judul Yang Sedikit Mendeskripsikan Celah Keamanan

Dalam dunia bug bounty, beberapa perusahaan penyelenggara program ada yang hanya memerlukan rincian informasi ringkas dari judul untuk dapat mengetahui dimana letak permasalahan terkait celah keamanan yang ada. 

Di beberapa situasi judul dapat meringkas waktu bagi developer atau tim keamanan untuk mengidentifikasi suatu kerentanan pada sistem. Meskipun tidak semua developer seperti itu, namun tidak ada salahnya apabila judul telah sedikit dideskripsikan pada judul. Contoh: "IDOR PADA SERVER APLIKASI **** LEAD TO DISCLOURE DATA USER DAN AND ACCOUNT TAKE OVER"

2. Menyertakan URL, ENDPOINT  dan Parameter Yang Vuln

Informasi ini akan sangat berguna bagi tim keamanan atau developer dalam menemukan dan memperbaiki celah keamanan yang ada secara lebih cepat.

3.  Memberikan Penjelasan Ringkas Terhadap Jenis BUG

Hal ini merupakan sesuatu yang dapat dikatakan penting karena mungkin saja tim keamanan atau developer tidak memahami bug yang dimaksud dan seperti apa dampaknya. 

Dengan memberikan penjelasan ringkas tentang bug tentu akan membuat tim tersebut lebih paham dan menjadi lebih aware serta memprioritaskan laporan bug yang kita buat. Contoh: "IDOR adalah adalah kependekan dari Insecure direct object references merupakan jenis kerentanan kontrol akses yang muncul saat aplikasi menggunakan input yang diberikan pengguna untuk mengakses objek secara langsung."

4. Menyertakan Video ataupun GIF 

Dalam membuat laporan, biasanya di bagian step to reproduce atau langkah-langkah bug hunter akan menggunakan screenshot atau tangkapan layar. Namun alangkah lebih baik apabila dalam langkah-langkah disertakan juga GIF ataupun video sehingga tim keamanan atau developer dapat lebih mengerti cara mereproduce bug dan memverifikasi  bug untuk menentukan valid atau tidak valid.

5. Beritahukan Versi Aplikasi atau Sistem yang Memiliki Kerentanan Beserta Keterangan Device  yang Dipakai

Ketika bug hunter melakukan pengetesan  pada sistem atau aplikasi yang memiliki versi di dalamnya, maka akan lebih baik apabila menyertakan versi dari aplikasi atau sistem yang diuji berserta dengan detil dari device yang digunakan untuk melalukan pengetesan. 

Aplikasi atau sistem yang kita tes bisa saja menggunakan framework atau CMS tertentu, oleh karena itu informasi mengenai versi akan sangat berguna bagi tim keamanan atau developer untuk melakukan mitigasi dan perbaikan. Contoh: "SSRF Vulnerability disini ada pada library urlgetreq/0.19.2 dan telah dites menggunakan Chrome versi n 96.0.4664.110 (Official Build) (64-bit) dengan Windows 10 Single Language."

6. Deskripsikan Dampak dengan Jelas dan Cantumkan CVSS Score

Dalam melaporkan celah keamanan, hal yang paling menentukan jumlah nominal reward atau kevalidan dari laporan kita adalah dampak (impact) dari celah keamanan yang kita temukan. Semakin besar dampak dari bug terhadap sistem ataupun terhadap pengguna dari sistem tersebut  maka akan semakin diprioritaskan laporan kita dan tentu reward yang kita dapatkan bisa menjadi lebih besar. Bug hunter perlu memberi penekanan terhadap informasi dampak ini dengan membuat sub-bab khusus yang menjelaskan akan setiap dampak secara detil dan merinci.

Mungkin sekian pengalaman dan tips yang bisa saya sampaikan. Secara ringkas saya berharap manfaat dari tulisan ini dapat diperoleh dengan baik bagi bug hunter sebagai pihak penguji maupun perusahaan sebagai developer yaitu menjadi sarana berbagi pengetahuan yang dapat menghadirkan pengetahuan baru untuk setiap bughunter, membangun personal branding penguji secara positif untuk jejak karir di masa mendatang, meningkatkan kemampuan dalam membangun relasi dan kerjasama yang baik dengan developer, serta mampu menjalin kerjasama berkelanjutan lewat laporan celah keamanan yang dibuat dengan komprehensif.