Menentukan Severity Kerentanan Menggunakan CVSS

Sabtu, 25 September 2021

Cara Menghitung CVSS. Oke ini hanyalah catatan pribadi bagi saya mengenai bagaimana kita menentukan sebuah severity dari temuan bug menggunakan Common Vulnerability Scoring System atau CVSS. Common Vulnerability Scoring System adalah standar industri yang bebas dan terbuka untuk menilai tingkat severity kerentanan keamanan sistem. CVSS mencoba untuk menetapkan skor severity dari sebuah kerentanan, memungkinkan responden untuk memprioritaskan object mana yang harus diperbaiki terlebih dahulu sesuai dengan tingkat resikonya.

Berdasarkan CVSS terbaru yakni CVSS 3.1, ada 8 kriteria (base score) yang dinilai untuk menentukan tingkat severity dari sebuah celah atau vulnerability yang ditemukan yaitu Attack Vector (AV)Attack Complexity (AC)Privileges Required (PR)User Interaction (UI), Scope (S), Confidentiality (C), Integrity (I), dan Availability (A).

Oke disini saya akan menjelaskan satu-persatu dari delapan kriteria tersebut menggunakan contoh kasus saja agar tidak bingung.

Attack Vector (AV)

Attack Vector adalah bagaimana cara kita mengakses dan mengeksploitasi object yang memiliki kerentanan. Ada empat kategori yang bisa kita pilih, yakni:

  • Network (N)
  • Adjacent (A)
  • Local (L)
  • Physical (P)

Network (N)

Ketika kita bisa mengakses dan mengeksploitasi target secara remote, tanpa harus berada di jaringan yang sama dengan target. Atau simplenya, target bisa dieksploitasi over the Internet.

Contoh kasus: Pentester diharuskan menguji keamanan dari domain target.com dan domain tersebut dapat diakses oleh pentester menggunakan akses internet pribadinya.

Adjacent (A)

Ketika kita membutuhkan pendekatan khusus untuk mengakses target yang ingin dieksploitasi. Contohnya, kita harus berada di jaringan yang sama dengan target (misalnya di local subnet yang sama), atau kita harus menggunakan VPN untuk mengakses target yang ingin dieksploitasi.

Contoh kasus: Pentester diharuskan menguji keamanan dari domain target.com namun domain tersebut hanya bisa diakses melalui VPN yang sudah dikonfigurasi sebelumnya.

Local (L)

Target tidak bisa dieksploitasi dari jaringan dan hanya bisa dieksploitasi dengan berinteraksi secara langsung dengan target entah menggunakan console ataupun secara remote menggunakan SSH.

Contoh kasus: Celah privilege escalation dengan menjalankan localroot hanya bisa dieksekusi ketika kita sudah mendapatkan akses SSH ataupun TTY Shell.

Physical (P)

Eksploitasi hanya bisa dilakukan ketika kita memiliki akses fisik ke target.

Contoh kasus: Pada CVE-2014-2005, pentester harus memiliki akses fisik ke komputer target untuk melakukan bypass kredensial Windows Lock Screen dengan menekan tombol resume untuk mensukseskan eksploitasi Sophos Login Screen Bypass Vulnerability.

Attack Complexity (AC)

Attack Complexity adalah level kesulitan kita untuk mengeksploitasi target yang sudah ditentukan. Hanya ada dua rating yang bisa dipilih yakni:

  • Low (L)
  • High (H)

Low (L)

Ketika kita sukses mengeksploitasi sebuah kerentanan tanpa mengalami kesulitan.

Contoh kasus: Pentester menemukan kerentanan SQL Injection dan bisa dieksekusi langsung menggunakan sqlmap atau, pentester menemukan kerentanan berdasarkan CVE dan exploitnya sudah tersedia di publik.

High (H)

Ketika eksploitasi sebuah kerentanan berhasil dilakukan dengan dengan persiapan dan kontrol dari pentester.

Contoh kasus: Untuk sukses melancarkan serangan POODLE Attack, pentester melakukan MiTM dimana dia harus memodifikasi trafik jaringan antara korban dengan web target.

Privileges Required (PR)

Sesuai dengan nama metric-nya, hal ini ditentukan oleh dibutuhkan tidaknya kredensial tertentu untuk mensukseskan exploitasi kerentanan pada target. Ada tiga pilihan rating yakni:

  • None (N)
  • Low (L)
  • High (H)

None (N)

Ketika eksploitasi berhasil dilakukan tanpa memerlukan kredensial pada object.

Contoh kasus: Kerentanan XSS yang ditemukan pada fitur search pada website target yang bisa dieksekusi tanpa harus login terlebih dahulu.

Low (L)

Ketika eksploitasi berhasil dilakukan dengan minimal harus memiliki akses user dengan privilege rendah pada target.

Contoh kasus: Kerentanan XSS yang ditemukan pada fitur edit profile user pada sebuah website.

High (H)

Ketika eksploitasi berhasil dilakukan namun mengharuskan akses pengguna dengan kredensial yang tinggi.

Contoh kasus: Pentester menemukan kerentanan RCE pada website target dengan melakukan bypass fitur upload yang ada pada pada sebuah website. Namun fitur upload tersebut hanya bisa diakses oleh user dengan hak akses admin dan tidak bisa diakses menggunakan user dengan level dibawahnya.

User Interaction (UI)

Dibutuhkan atau tidaknya interaksi dari pengguna lain untuk mensukseskan serangan atau eksploitasi yang sedang dijalankan. Ada dua pilihan rating yang bisa dipilih yaitu:

  • None (N)
  • Required (R)

None (N)

Ketika eksploitasi berhasil dilakukan tanpa perlu adanya interaksi dari user lain.

Contoh kasus: Untuk melakukan privilege escalation melalui kernel yang memiliki kerentanan, pentester bisa langsung mengeksekusi localroot karena sebelumnya sudah memiliki akses ke TTY shell.

Required (R)

Eksploitasi berhasil dilakukan ketika ada interaksi dari pengguna lain.

Contoh kasus: Untuk mendapatkan data dari user lain menggunakan kerentanan CSRF, user lain tersebut harus meng-klik link berisi script CSRF yang sudah disiapkan oleh si pentester.

Scope (S)

Mengenai berubah tidaknya scope object yang terdampak ketika eksploitasi berhasil dilakukan. Rating yang bisa dipiloh:

  • Unchanged (U)
  • Changed (C)

Unchanged (U)

Scope object yang terdampak tidak berubah ketika eksploitasi berhasil dilakukan.

Contoh kasus: Ketika attacker melakukan serangan DDoS pada sebuah aplikasi, yang terdampak dari serangan tersebut adalah aplikasi yang sedang menjadi target.

Changed (C)

Scope object yang terdampak ikut berubah ketika eksploitasi berhasil dilakukan.

Contoh kasus: Scope dari serangan XSS bernilai "Changed" karena meskipun yang memiliki kerentanan adalah aplikasi yang diuji, yang terdampak adalah browser dari pengguna. 

Selanjutnya kita akan membahas metrics dampak dari eksploitasi yang sudah dilakukan meliputi Confidentiality (C), Integrity (I), dan Availability (A). Dan ini biasanya menjadi "ujung tombak" untuk menentukan severity karena meskipun eksploitasi mudah dilakukan tetapi jika tidak ada dampak berarti kepada sistem, skor akhir dari penilaian bisa saja bernilai Low atau bahkan hanya Informational.

Penilaian CIA ini merupakan satu kesatuan, dan saya akan membahasnya satu-persatu.

Confidentiality (C)

Confidentiality diisini menyangkut kerahasiaan data yang terdampak setelah setelah eksploitasi berhasil dilakukan. Ratingnya terbagi menjadi tiga yaitu:

  • None (N)
  • Low (L)
  • High (H)

None (N)

Tidak ada kerahasiaan data yang terdampak dari celah yang ditemukan.

Contoh kasus: Pentester menemukan Directory Listing namun didalamnya hanya berisi file static seperti file gambar dan javascript yang diload oleh object yang sedang diuji.

Low (L)

Celah ini dapat menyebabkan kebocoran data, namun attacker tidak memiliki kontrol atas data apa yang akan terdampak.

Contoh kasus: Pentester menemukan celah IDOR pada aplikasi yang memungkinkannya untuk melihat data pengguna lain.

High (H)

Celah ini memungkinkan attacker untuk mengontrol data apa yang bisa didapat melalui eksploitasi yang dilakukan.

Contoh kasus: Pentester menemukan celah LFI yang memungkinkan untuk mengakses data di object yang terdampak. Atau, pentester menemukan celah Directory Listing yang didalamnya berisi backup database.

Integrity (I)

Metrik Integrity ini untuk menilai integritas data yang dilindungi dari object yang terdampak. Ratingnya terbagi menjadi tiga yaitu:

  • None (N)
  • Low (L)
  • High (H)

None (N)

Pelaku tidak dapat memodifikasi data melalui eksploitasi yang dilakukan.

Contoh kasus: Serangan DDoS.

Low (L)

Dampak dari celah yang ditemukan memungkinkan attacker untuk memodifikasi sebagian data dari object yang terdampak. Modifikasi data tidak membawa dampak langsung yang serius pada target.

Contoh kasus: Pentester menemukan celah XSS pada website target dengan memodifikasi value pada filed yang memiliki kerentanan, namun "tujuan akhir" dari XSS bukan itu, serta dampaknya lebih ke user yang mengakses, bukan pada aplikasi itu sendiri.

High (H)

Celah ini memungkinkan attacker untuk mengontrol data apa yang bisa dimodifikasi setelah eksploitasi sukses dilakukan. Dan berdampak secara langsung pada aplikasi yang diuji.

Contoh kasus: Pentester menemukan celah price tampering pada website online shop, dan berhasil mlakukan checkout barang dengan harga Rp.0.

Availability (A)

Metrik ini menilai ketersediaan dari komponen yang memiliki kerentanan. Ada tiga rating yang bisa dipilih yakni:

  • None (N)
  • Low (L)
  • High (H)

None (N)

Ketersediaan data pada aplikasi tidak terganggu oleh celah yang ditimbulkan.

Contoh kasus: Pentester menemukan celah directory listing yang berisi data penting dari user aplikasi tersebut. Meskipun Confidentiality dari temuan bisa bernilai High, namun Avaliability bernilai None.

Low (L)

Dampak dari celah yang ditemukan membuat resource aplikasi sedikit terganggu.

Contoh kasus: Pentester menemukan celah HTML Injection yang menyebabkan sebagian halaman dari komponen terganggu.

High (H)

Celah ini memungkinkan attacker untuk mengontrol ketersediaan dari object yang terdampak.

Contoh kasus: Pentester menemukan celah RCE pada sistem dan memungkinkan untuk menghapus komponen aplikasi yang menyebabkan aplikasi tidak bisa diakses.

Catatan: Untuk menilai CIA, kita harus melihat impact yang akan terjadi kepada aplikasi itu sendiri. Celah yang sama bisa saja menghasilkan nilai yang berbeda. Sebagai contoh, Integrity untuk temuan Directory Listing yang berisi data penting dari user dan Directory Listing yang hanya berisi file static tentu berbeda.

Oke mungkin itu saja sharing kali ini, mungkin jika ada yang salah bisa dikoreksi. Atau jika ada yang kurang bisa ditambahkan.

Referensi:

  • https://www.first.org/cvss/specification-document
  • https://www.netsparker.com/blog/web-security/cvss-characterizing-and-scoring-vulnerabilities/

Artikel Terkait Security