NgeSec Bebas #3 — How to Avoid N/A on Submissions
Introduction
Pernah ga sih kalian sudah melakukan recon dan melakukan scanning berjam-jam namun kesulitan mendapatkan sebuah bug atau aplikasi yang dapat kita jadikan target untuk pelaporan sebuah bug? baik itu konteksnya dalam kegiatan pentesting ataupun bug bouty hunter.
Sekalipun kita dapat sebuah aplikasi yang kita jadikan target, kalian pernah terfikir tidak mengapa temuan kita sering kali mendapatkan sebuah status N/A pada submission di bug bounty report? atau kalau dalam konteks kegiatan pentesting kita selalu hanya mendapatkan bug yang tergolong kategori informatif ataupun low.
Hal tersebut disebabkan karena kurangnya pemahaman kita terkait beberapa hal yaitu:
- Program Requirements (Syarat pelaksanaan Bug Bounty / Pentesting)
- Security Framework Concept (CIA Triad) & Risk Assessment (Analisis Resiko)
- Analysis Attack Surface (Analisis Asset Target) & Threat Modeling (Membuat Skema Model Penyerangan)
Untuk memastikan laporan bug Anda tidak mendapatkan status N/A, penting untuk memahami tiga konsep kunci: Program Requirements, Security Framework Concepts (seperti CIA Triad dan Risk Assessment), serta Attack Surface dan Threat Modeling. Di bagian berikutnya, kita akan membahas masing-masing aspek ini secara mendetail untuk membantu Anda memaksimalkan hasil pentesting dan bug bounty.
1. Program Requirements
Program Requirements adalah prasyarat yang ditetapkan untuk melakukan pentesting pada aplikasi dalam program bug bounty. Syarat ini menentukan domain atau aplikasi yang boleh diuji serta jenis bug yang bisa dilaporkan.
Seringkali, status N/A pada laporan bug disebabkan oleh ketidaksesuaian dengan program requirements. Misalnya, jika Anda menemukan bug di domain atau aplikasi yang tidak termasuk dalam cakupan, meskipun bug tersebut relevan, submission Anda bisa mendapatkan status N/A. Demikian pula, jika targetnya sesuai tetapi kerentanan yang ditemukan tidak sesuai dengan syarat yang berlaku, status submission juga bisa N/A. Jadi, penting untuk memahami dan mengikuti ketentuan yang berlaku agar laporan bug Anda diterima.
Terdapat Dua Hal Penting untuk Menghindari N/A pada Submission: In-Scope dan Out-of-Scope Program
1.1 In-Scope (Cakupan Target)
“In-Scope” merujuk pada elemen-elemen yang diperbolehkan untuk diuji sesuai dengan peraturan yang telah ditetapkan, baik itu domain/aplikasi maupun klasifikasi tingkat risiko vulnerability-nya. Berikut ini yang biasanya termasuk dalam cakupan target:
Cakupan Target Web Domain atau Aplikasi:
- Domain: Menentukan domain atau subdomain mana yang boleh diuji, contohnya example.com dan subdomain seperti sub.example.com.
- Aplikasi: Menentukan aplikasi atau fitur tertentu yang diizinkan untuk diuji, seperti halaman login, API, atau modul spesifik dari aplikasi.
Bug yang Diterima dan Diklasifikasikan:
Jenis Bug: Bug yang diterima bisa termasuk SQL injection, XSS (Cross-Site Scripting), CSRF (Cross-Site Request Forgery), dan lainnya.
Level Risiko: Menyebutkan level risiko yang diterima, yaitu:
- Critical: Bug yang bisa menyebabkan akses tidak sah ke data sensitif atau kerusakan sistem yang serius.
- High: Bug dengan dampak signifikan tapi tidak se-critical bug dalam kategori critical.
- Medium: Bug yang mempengaruhi fungsi aplikasi tapi tidak langsung membahayakan data atau integritas sistem.
- Low: Bug dengan dampak kecil dan tidak segera membahayakan aplikasi atau data.
1.2 Out-of-Scope (Luar Cakupan Target)
“Out-of-Scope” merujuk pada elemen-elemen yang tidak boleh diuji dan tidak akan diterima dalam laporan. Berikut ini yang biasanya termasuk dalam luar cakupan target:
Cakupan Target Web Domain atau Aplikasi:
- Domain: Domain atau subdomain yang tidak diizinkan untuk diuji, seperti legacy.example.com kalau yang diizinkan cuma www.example.com.
- Aplikasi: Modul atau fitur tertentu yang dikecualikan dari pengujian, seperti halaman admin atau API yang tidak boleh diuji.
Bug yang Tidak Diterima:
- Jenis Bug: Bug atau kerentanan yang tidak diterima termasuk masalah non-sekuriti, atau masalah fungsionalitas yang bukan masalah keamanan.
- Level Risiko: Bug dengan level risiko yang terlalu rendah atau tidak sesuai dengan kriteria cakupan, seperti masalah kosmetik yang tidak mempengaruhi keamanan.
Dengan memahami dan mematuhi program requirements, kita bisa meningkatkan peluang untuk mendapatkan hasil yang diterima dan mengurangi kemungkinan mendapatkan status N/A.
2. Analysis Attack Surface & Threat modeling
2.1 Attack Surface
Memahami konsep attack surface sangat penting bagi seorang pentester atau bug hunter. Attack surface merujuk pada semua area dalam sistem, aplikasi, atau jaringan yang dapat diakses oleh peretas untuk mencoba masuk, mencuri data, atau menyebabkan kerusakan.
Attack surface mencakup:
- Semua celah yang dapat digunakan untuk mengakses sistem.
- Tempat-tempat yang dapat digunakan untuk mengakses data sensitif.
- Bagian-bagian yang dapat dimanipulasi untuk mengganggu fungsi sistem.
- Titik-titik yang dapat dieksploitasi untuk menyebabkan layanan tidak berfungsi.
Untuk melakukan analisis attack surface, seorang pentester harus terlebih dahulu mengidentifikasi semua komponen dalam sistem, termasuk server, database, aplikasi, dan perangkat jaringan. Setelah itu, evaluasi semua titik masuk dan keluar data dalam sistem seperti form pengguna, API, dan port yang terbuka. Pentester juga perlu menganalisis bagaimana komponen-komponen ini berinteraksi satu sama lain untuk mengidentifikasi vektor serangan potensial. Meninjau konfigurasi sistem dan aplikasi untuk mencari kelemahan, serta melakukan audit keamanan pada source code dan aplikasi juga menjadi bagian dari proses analisis attack surface. Dengan melakukan langkah-langkah ini, pentester dapat menemukan kelemahan yang ada.
2.2 Threat Modeling
Threat modeling adalah proses sistematis untuk mengidentifikasi dan mengevaluasi potensi risiko dan kelemahan dalam sistem atau aplikasi. Proses ini memungkinkan organisasi untuk memahami berbagai ancaman yang dapat mengancam aset digital mereka, sehingga mereka dapat memprioritaskan langkah-langkah keamanan dengan lebih optimal.
Manfaat bagi Pentest dan Bug Bounty Hunting:
- Memprioritaskan Area Kritis: Threat modeling membantu penetration tester mengidentifikasi area paling kritis untuk diuji dengan memprioritaskan ancaman dan kerentanan berdasarkan tingkat keparahan dan kemungkinan terjadinya.
- Memahami Sistem dengan Lebih Baik: Dengan menganalisis sistem atau aplikasi dari perspektif penyerang, penetration tester dapat memahami target yang diuji dengan lebih mendalam.
- Mengidentifikasi Kerentanan Tersembunyi: Threat modeling dapat mengungkap kerentanan dan vektor serangan yang mungkin terlewat saat perencanaan awal penetration test.
- Pertimbangan Ancaman yang Komprehensif: Proses ini mendorong tim penetration testing dan organisasi untuk mempertimbangkan berbagai ancaman dan kerentanan yang mungkin ada dalam sistem atau aplikasi.
- Mengidentifikasi Titik Buta: Threat modeling dapat mengidentifikasi kelemahan dalam proses pengujian dan mengungkap kemungkinan ancaman seperti rekayasa sosial yang mungkin tidak termasuk dalam scope penetration test.
- Memahami Risiko Bisnis: Sesi threat modeling yang tepat dapat membantu organisasi memahami risiko bisnis dalam istilah kuantitatif, memberikan gambaran lebih jelas tentang aset dan risiko yang terkait.
Mengintegrasikan threat modeling ke dalam proses penetration testing memberikan nilai signifikan bagi tim penetration testing dan organisasi. Ini meningkatkan hasil pengujian keamanan secara keseluruhan dengan memastikan semua potensi ancaman dan kerentanan dipertimbangkan dan diatasi.
Salah satu-nya bisa menggunakan OWASP Top 10 Framework:
- OWASP Top 10 Web
- OWASP Top 10 API Security
- OWASP Top 10 Mobile Apps Security
Menggunakan OWASP Top 10 sebagai bagian dari threat modeling memberikan banyak keuntungan bagi pentester dan bug bounty hunter. Ini membantu mengidentifikasi dan memprioritaskan ancaman yang paling signifikan serta memastikan pengujian dilakukan sesuai dengan standar industri yang diakui. Dengan pendekatan ini, pengujian menjadi lebih efektif dan komprehensif, serta memberikan nilai lebih bagi klien atau platform bug bounty yang dikerjakan.
3. Security Framework Concept (CIA Triad) & Risk Assessment
3.1 CIA Triad
Banyak pentester atau bug bounty hunter sering mendapatkan status N/A pada submission mereka karena kurang memahami konsep security framework serta risk assessment, khususnya dalam menilai dan menghitung risiko serangan atau tingkat ancaman pada kerentanan yang mereka temukan. Security framework dapat diibaratkan sebagai panduan untuk menjaga sistem informasi dari berbagai ancaman, membantu kita memahami dan menerapkan langkah-langkah keamanan yang tepat serta mengelola risiko dengan benar.
Salah satu contoh security framework yang sering digunakan adalah CIA Triad, yang terdiri dari tiga prinsip dasar dalam keamanan informasi: Confidentiality (Kerahasiaan), Integrity (Integritas), dan Availability (Ketersediaan).
- Confidentiality (Kerahasiaan): Prinsip ini memastikan bahwa informasi sensitif hanya dapat diakses oleh pihak yang berwenang. Contoh penerapannya adalah menggunakan enkripsi untuk data yang disimpan dan dikirim, serta menerapkan kontrol akses yang ketat.
- Integrity (Integritas): Prinsip ini memastikan bahwa data tetap akurat dan tidak dapat diubah secara sembarangan. Contoh penerapannya adalah menggunakan validasi input untuk mencegah perubahan data yang tidak sah, serta teknik seperti checksum atau hash untuk memastikan data tidak dimodifikasi tanpa izin.
- Availability (Ketersediaan): Prinsip ini memastikan bahwa sistem dan data dapat diakses kapan saja oleh pihak yang berwenang. Contoh penerapannya adalah menggunakan solusi redundansi seperti load balancing, backup data secara teratur, dan perlindungan terhadap serangan DDoS untuk menjaga agar sistem tetap operasional.
Bagi pentester atau bug hunter, memahami konsep CIA Triad sangat penting untuk mengevaluasi apakah bug yang mereka temukan melanggar salah satu dari ketiga prinsip ini. Misalnya, jika ada bug yang bisa menyebabkan data sensitif bocor, itu berarti melanggar prinsip Confidentiality. Jika ada bug yang bisa mengubah data tanpa izin, itu berarti melanggar prinsip Integrity. Dan jika ada bug yang bisa menyebabkan sistem down, itu berarti melanggar prinsip Availability.
Dengan memahami dan menerapkan CIA Triad, pentester atau bug hunter dapat lebih tepat dalam mengukur dampak dan risiko dari bug yang ditemukan, serta menentukan apakah bug tersebut layak untuk disubmit atau tidak. Memastikan bahwa bug yang ditemukan relevan dengan prinsip-prinsip dasar ini dapat membantu mengurangi kemungkinan mendapatkan status N/A pada submission mereka.
3.2 Risk Assesment
Risk assessment memungkinkan pentester untuk memprioritaskan pengujian pada area yang memiliki risiko tertinggi. Dengan mengklasifikasikan risiko, mereka bisa fokus pada bagian sistem yang berpotensi menyebabkan dampak paling besar jika dieksploitasi, sehingga membuat pengujian menjadi lebih efisien dan efektif.
Seringkali, bug bounty hunter mendapatkan status N/A karena bug yang dilaporkan dianggap tidak cukup signifikan atau tidak sesuai dengan kriteria program. Dengan melakukan risk assessment, hunter bisa lebih tepat dalam menilai dan mengkomunikasikan risiko dari bug yang ditemukan, sehingga meningkatkan peluang untuk mendapatkan penghargaan atas temuan mereka.
3.2.1 Qualitative Risk Assessment
Qualitative Risk Assessment adalah metode untuk menilai dan mengklasifikasikan risiko ke dalam kategori seperti “Low,” “Medium,” atau “High” berdasarkan dampak dan kemungkinan terjadinya kerentanan. Pendekatan ini lebih bersifat subjektif dan tidak melibatkan angka yang konkret, tetapi memberikan panduan umum mengenai tingkat risiko yang terlibat. Di sisi lain, CVSS (Common Vulnerability Scoring System) adalah alat yang lebih kuantitatif untuk menilai kerentanan dengan memberikan skor yang terukur berdasarkan metrik yang terdefinisi dengan jelas.
Contoh perhitungan dengan CVSS Score
Mari kita berikan penilaian untuk kasus bug “tampering price”, terdapat sebuah request awal pembelian barang seperti berikut:
POST /api/checkout HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <your_token>
{
"cart_id": "12345",
"items": [
{
"product_id": "Pepsodent 80g",
"quantity": 2
}
],
"total_price": 40000
}Request setelah parameter value total_price di tampering menjadi nilai 0:
POST /api/checkout HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <your_token>
{
"cart_id": "12345",
"items": [
{
"product_id": "Pepsodent 80g",
"quantity": 2
}
],
"total_price": 0
}CVSS:3.1/AV/AC/PR/UI/S/C/I/A
Penjelasan Metrik:
- AV (Attack Vector): Network (Akses dari jaringan, bisa dilakukan secara remote).
- AC (Attack Complexity): Low (Eksploitasi mudah dilakukan tanpa memerlukan kondisi khusus).
- PR (Privileges Required): Low (Pelaku serangan memerlukan hak akses terbatas).
- UI (User Interaction): None (Tidak memerlukan interaksi pengguna untuk eksploitasi).
- S (Scope): Unchanged (Dampak tidak meluas ke sistem lain).
- C (Confidentiality): None (Tidak ada dampak pada kerahasiaan data).
- I (Integrity): Low (Kerusakan minimal pada integritas data).
- A (Availability): None (Tidak ada dampak pada ketersediaan sistem).
Untuk kasus “tampering price”, CVSS score menggambarkan seberapa serius kerentanan tersebut dengan mempertimbangkan faktor-faktor seperti aksesibilitas, kerumitan, dan dampak pada kerahasiaan, integritas, dan ketersediaan. Dengan nilai CVSS yang mencerminkan dampak rendah pada kerahasiaan, integritas, dan ketersediaan, kerentanan ini dianggap sebagai risiko rendah, Untuk memahami risiko secara menyeluruh, terutama dalam konteks kerugian keuangan dan reputasi, penting untuk melibatkan pendekatan Quantitative Risk Assessment.
Quantitative Risk Assessment membantu dalam mengukur dampak kerentanan dengan menghitung potensi kerugian finansial dan seberapa sering bug bisa dieksploitasi. Dengan menggunakan rumus seperti Severity (SLE), Likelihood (ARO), dan Annual Loss Expectancy (ALE), kita dapat memberikan analisis yang lebih mendalam dan konkret mengenai risiko yang dihadapi.
Selanjutnya, kita akan membahas bagaimana menerapkan perhitungan Quantitative Risk Assessment ini untuk memberikan pemahaman yang lebih baik dan langkah-langkah mitigasi yang efektif dalam konteks bug bounty dan pentesting.
3.2.2 Quantitative Risk Assessment
Dalam Quantitative Risk Assessment, risiko diukur menggunakan nilai-nilai numerik. Alih-alih kategori “Low”, “Medium”, dan “High”, lu akan menggunakan angka yang mewakili rentang tersebut. Ketika melakukan Quantitative Risk Analysis, kita bisa menggunakan alat untuk menentukan Severity dan Likelihood atau serangkaian perhitungan khusus berdasarkan proses perusahaan.
Contoh Perhitungan dengan Risk Matriks
5x5 Risk Matrix adalah alat visual yang membantu mengidentifikasi dan menilai risiko berdasarkan dua dimensi utama: probabilitas (kemungkinan) dan dampak (severity). Matriks ini biasanya dibagi menjadi 5 tingkat
Mari kita berikan penilaian untuk kasus bug “tampering price”, terdapat sebuah request awal pembelian barang seperti berikut:
POST /api/checkout HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <your_token>
{
"cart_id": "12345",
"items": [
{
"product_id": "Pepsodent 80g",
"quantity": 2
}
],
"total_price": 40000
}Request setelah parameter value total_price di tampering menjadi nilai 0:
POST /api/checkout HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <your_token>
{
"cart_id": "12345",
"items": [
{
"product_id": "Pepsodent 80g",
"quantity": 2
}
],
"total_price": 0
}Severity, Bug ini memungkinkan barang dibeli dengan harga gratis, yang bisa menyebabkan kerugian finansial besar bagi perusahaan. Oleh karena itu, kita kategorikan sebagai High.
Likelihood, Jika bug ini dapat diakses dengan mudah oleh pelanggan tanpa adanya perlindungan atau validasi yang memadai, kemungkinan eksploitasi tinggi. Jadi kita kategorikan sebagai High.
Perhitungan Risk
Dengan menggunakan rumus:
Risk=Severity×Likelihood
Kita asumsikan bahwa kita menggunakan skala numerik sebagai berikut:
Severity: Critical = 4, High = 3, Medium = 2, Low = 1
Likelihood: High = 4, Medium = 3, Low = 2, Very Low = 1
Untuk kasus ini, Severity: High = 3 dan Likelihood: High = 4
Maka, Risk=3×4=12
Contoh Perhitungan Risk Assessment (Financial Loss)
ARO (Annual Rate of Occurrence), SLE (Single Loss Expectancy), dan ALE (Annual Loss Expectancy) adalah metode kuantitatif yang lebih spesifik untuk menilai risiko dalam konteks keuangan.
Severity (SLE — Single Loss Expectancy):
- Definisi: Mengukur seberapa besar kerugian yang dapat terjadi jika bug dieksploitasi.
- Contoh: Jika setiap transaksi yang terkena dampak dapat menyebabkan kerugian sebesar 40,000 IDR (harga barang yang di-tamper), maka SLE = 40,000 IDR.
Likelihood (ARO — Annual Rate of Occurrence):
- Definisi: Estimasi seberapa sering bug ini bisa dieksploitasi dalam setahun.
- Contoh: Jika bug ini kemungkinan dieksploitasi 5 kali dalam setahun, maka ARO = 5.
Annual Loss Expectancy (ALE):
- Definisi: Potensi kerugian tahunan dari bug tersebut.
- Rumus: ALE = SLE × ARO
- Perhitungan: ALE = 40,000 IDR × 5 = 200,000 IDR
Dalam penilaian risiko kuantitatif, menghitung Severity (SLE), Likelihood (ARO), dan Annual Loss Expectancy (ALE) memberikan wawasan lebih mendalam tentang potensi dampak dan frekuensi eksploitasi suatu bug. Meskipun perhitungan ini bisa sangat berguna untuk analisis mendalam dan debat dengan triager atau developer, tidak selalu perlu untuk melibatkan detail rumus dalam setiap kasus. Sebagai pentester atau bug bounty hunter, fokus utama Anda adalah memahami dan mengkomunikasikan dampak dan risiko secara jelas dan efektif.
Informasi kuantitatif ini dapat menjadi alat tambahan yang berguna jika terjadi diskusi teknis yang mendalam atau untuk memperkuat argumen Anda. Namun, pada umumnya, menjelaskan dampak dan risiko secara kualitatif sering kali sudah cukup untuk memadai dalam laporan bug atau komunikasi dengan pihak terkait.
Penutup
Memahami Program Requirements, CIA Triad, dan Risk Assessment sangat penting untuk laporan pentesting dan bug bounty. Program Requirements memastikan temuan sesuai dengan cakupan yang ditetapkan, sementara CIA Triad membantu menilai dampak kerentanan berdasarkan Confidentiality, Integrity, dan Availability.
Menilai risiko, terutama terkait kerugian finansial dan reputasi, bisa rumit. Tidak semua data yang tampaknya kurang penting dianggap serius oleh triager atau developer, yang dapat mempengaruhi penilaian risiko. Penjelasan kualitatif sering diperlukan untuk mengkomunikasikan dampak ini secara efektif.
Selain itu, perhatikan isu terkait penutupan program atau perubahan aturan yang mendadak di platform seperti HackerOne atau Bugcrowd, yang dapat menyebabkan kerugian bagi bug hunter. Memahami dan mengatasi masalah ini membantu meningkatkan kualitas laporan dan komunikasi, serta mengurangi dampak negatif dari perubahan aturan atau penutupan program yang tidak terduga.
