Vulnerabilities 101

Overview

This room introduces what vulnerabilities are, how they are scored, and where to research them. It also shows the practical workflow of using a small finding such as version disclosure to pivot into vulnerability databases and locate real exploits or proof-of-concepts.

1) What a Vulnerability Is

A vulnerability is a weakness in the design, implementation, configuration, or behavior of a system that can be abused by an attacker.

The room groups vulnerabilities into five broad categories:

• Operating system: often related to privilege escalation.
• (Mis)configuration-based: insecure settings or exposed data.
• Weak/default credentials: guessable or factory-set logins.
• Application logic: bad design in how the app behaves.
• Human-factor: vulnerabilities that exploit human behavior, such as phishing.

2) CVSS

The Common Vulnerability Scoring System (CVSS) is the best-known vulnerability scoring framework and is widely used across the industry.

• Scores are based on exploitability, impact, and other characteristics.
• Severity levels range from None to Critical.
• It is free, widely recognized, and recommended by organizations such as NIST.

3) VPR

Vulnerability Priority Rating (VPR) is Tenable’s more risk-driven approach. It tries to measure how relevant and dangerous a vulnerability is in the real world, not just how severe it looks in theory.

• More dynamic than CVSS.
• Focuses on real risk and changing exploit conditions.
• Uses a similar numeric range but can produce very different prioritization than CVSS.

4) Vulnerability Databases

The room highlights two key resources:

• NVD: the National Vulnerability Database at nvd.nist.gov/vuln
• Exploit-DB: exploit and PoC database at exploit-db.com

Useful terminology:

• Vulnerability: the flaw itself
• Exploit: a method or action that abuses the flaw
• PoC: proof-of-concept showing the vulnerability can be exploited

5) NVD and CVEs

NVD is the main public database for standardized vulnerability tracking. Entries are organized around CVEs, using names like CVE-2017-0144.

• Useful for looking up confirmed public vulnerabilities.
• Good for understanding impact, references, and official metadata.
• Less convenient when you want practical exploitation material for a specific app version.

6) Exploit-DB

Exploit-DB is usually more practical during an assessment because it stores PoCs and exploit code by application name and version.

• Searchable by software name
• Searchable by version
• Directly useful when you already identified a product from banners or a web page

7) Example Workflow: Version Disclosure

The room demonstrates a very realistic chain:

1. Identify a visible application version, such as Apache Tomcat 9.0.17.
2. Treat the version disclosure itself as a useful weakness.
3. Search Exploit-DB for that exact product/version.
4. Review available PoCs that may apply to the target.

8) Practical Mindset

This room is less about exploitation itself and more about triage and research discipline.

• Find something concrete on the target.
• Classify what kind of weakness it is.
• Check severity and relevance.
• Search the right database for public history and exploitability.
• Use that information to decide whether deeper testing makes sense.

Exam Notes (PT1)

• Know the main vulnerability categories: OS, misconfiguration, weak credentials, logic, and human-factor.
• CVSS is about severity; VPR is more about real-world prioritization.
• NVD is best for official CVE research; Exploit-DB is often better for practical PoCs.
• Version disclosure is valuable because it enables targeted exploit research.
• Do not stop at “the app version is visible”; use that information to look for public vulnerabilities and exploitation paths.