Vulnerability Analysis

The CVE System

Every publicly disclosed vulnerability gets a CVE (Common Vulnerabilities and Exposures) identifier:

CVE-YEAR-NUMBER
CVE-2021-44228   → Log4Shell (Log4j RCE)
CVE-2017-0144    → EternalBlue (SMB RCE)
CVE-2019-0708    → BlueKeep (RDP RCE)
CVE-2014-0160    → Heartbleed (OpenSSL info disclosure)

Where to search:

• nvd.nist.gov — National Vulnerability Database (authoritative)
• cve.mitre.org — CVE list
• exploit-db.com — CVEs with working exploits
• vulhub.org — Docker-based vuln labs
• cvedetails.com — searchable CVE database

CVSS Scoring

CVSS (Common Vulnerability Scoring System) assigns a 0-10 severity score. Understand it to prioritize work and write reports.

Score Range → Severity
0.0         → None
0.1 – 3.9   → Low
4.0 – 6.9   → Medium
7.0 – 8.9   → High
9.0 – 10.0  → Critical

CVSS v3 Base Score components:

Attack Vector (AV):
  Network (N)   → exploitable remotely          → higher score
  Adjacent (A)  → same network segment required  
  Local (L)     → requires local access          
  Physical (P)  → requires physical access       → lower score

Attack Complexity (AC):
  Low (L)   → no special conditions required → higher score
  High (H)  → specific conditions required

Privileges Required (PR):
  None (N)  → no auth needed → higher score
  Low (L)   → standard user auth
  High (H)  → admin auth required

User Interaction (UI):
  None (N)      → no user action needed → higher score
  Required (R)  → user must click/open something

Scope (S):
  Unchanged (U) → only the vulnerable component is affected
  Changed (C)   → other components can be affected → higher score

CIA Impact:
  High/Low/None for each of Confidentiality, Integrity, Availability

Example: Log4Shell (CVE-2021-44228)

AV:N / AC:L / PR:N / UI:N / S:C / C:H / I:H / A:H
Score: 10.0 — Critical
Reason: Remotely exploitable, no auth, no user interaction, full system compromise

Searching for Exploits

# SearchSploit — offline exploit-db search (ships with Kali)
searchsploit apache 2.4.29
searchsploit vsftpd 2.3.4
searchsploit --id "phpMyAdmin"    # show CVE IDs

# Copy exploit to current dir
searchsploit -m exploits/linux/remote/17491.rb

# Update database
sudo apt update && sudo searchsploit -u

# Online searches
# exploit-db.com
# github.com/search?q=CVE-2021-44228+poc
# packetstormsecurity.com

# Find Metasploit modules for a CVE
msfconsole
msf6> search CVE-2017-0144
msf6> search type:exploit name:vsftpd
msf6> search eternalblue

Automated Vulnerability Scanners

OpenVAS (Free)

# Install and start
sudo apt install openvas
sudo gvm-setup      # initial setup (takes 20+ min)
sudo gvm-start

# Access web UI
firefox https://127.0.0.1:9392
# Default: admin / (password shown during setup)

# CLI scan
gvm-cli socket --gmp-username admin --gmp-password PASS \
  --xml "<create_target><name>Target</name><hosts>192.168.1.100</hosts></create_target>"

Nessus (Commercial, free for home use)

Nessus Essentials — free for up to 16 IPs:

# Download from tenable.com
# Install the .deb
sudo dpkg -i Nessus-*.deb
sudo systemctl start nessusd
firefox https://localhost:8834

Nmap as Vulnerability Scanner

# Run all vuln scripts
sudo nmap --script vuln 192.168.1.100

# Specific vulnerability checks
sudo nmap --script smb-vuln-* 192.168.1.100 -p 445
sudo nmap --script http-shellshock 192.168.1.100 -p 80
sudo nmap --script ssl-heartbleed 192.168.1.100 -p 443

# HTTP vulnerability checks
sudo nmap --script http-sql-injection,http-csrf,http-dombased-xss 192.168.1.100 -p 80

Manual Vulnerability Research

Automated scanners miss logic flaws. Manual analysis finds what tools can’t.

Version → CVE Workflow

# Step 1: Identify exact versions from scanning
# Apache/2.4.29 (Ubuntu) from HTTP header
# OpenSSH 7.4 from SSH banner
# vsftpd 2.3.4 from FTP banner

# Step 2: Search for known vulnerabilities
searchsploit apache 2.4.29
# Results show CVE-2017-7679, CVE-2017-7668 — check if applicable

# Step 3: Read the CVE, understand the conditions
# CVE-2017-7679: mod_mime buffer overread — requires mod_mime enabled
curl -I http://192.168.1.100  # does response suggest mod_mime?

# Step 4: Test the exploit in your lab first
# Never run untested exploits on a production engagement

# Step 5: Document your finding
# Title, CVE, CVSS score, evidence of vulnerability, proof of concept, remediation

Exploit-DB POC Quality Tiers

Not all exploit code is equal:

1 — Works as-is, tested, reliable
2 — Works with minor modification (adjust IP, port, path)
3 — Conceptual, needs significant development
4 — False positive, doesn't actually work

Read the code before running it. Scripts from exploit-db can be:
- Poorly written and crash the target
- Actually backdoored (rare but real)
- Outdated and need updating for modern versions

Common Vulnerabilities by Service

Web Applications

SQL Injection      → CVSS 9.8 (often critical)
RCE via deserialization → CVSS 9.8
XXE injection      → CVSS 7.5
SSRF               → CVSS 7.2 (can become critical via cloud metadata)
IDOR               → CVSS 6.5 (horizontal privilege escalation)
XSS (stored)       → CVSS 6.1
Open redirect      → CVSS 4.3

Infrastructure

Unauthenticated Redis    → CVSS 9.8 (often leads to RCE)
Default credentials      → CVSS 9.8
EternalBlue (MS17-010)  → CVSS 9.8
BlueKeep (RDP RCE)      → CVSS 9.8
Heartbleed (SSL)         → CVSS 7.5
Shellshock (bash)        → CVSS 9.8

Building a Vulnerability Matrix

After analysis, build a prioritized matrix before moving to exploitation:

| # | Host | Port | Service | Vulnerability | CVE | CVSS | Confidence | Priority |
|---|------|------|---------|---------------|-----|------|------------|----------|
| 1 | .100 | 21 | vsftpd 2.3.4 | Backdoor | CVE-2011-2523 | 10.0 | High | P1 |
| 2 | .100 | 445 | Samba | EternalBlue | CVE-2017-0144 | 9.8 | High | P1 |
| 3 | .100 | 80 | Apache 2.4.29 | HTTP/2 dos | CVE-2018-1333 | 7.5 | Medium | P2 |
| 4 | .100 | 22 | OpenSSH 7.4 | User enum | CVE-2018-15473 | 5.3 | High | P3 |

Exploit P1 targets first, document everything, then move to lower-priority findings.

Responsible Disclosure

When you find vulnerabilities during authorized testing:

1. Document the finding with proof of concept (screenshot, request/response)
2. Report immediately if it’s critical (active exploitation risk)
3. Don’t exploit beyond proof of concept — stopping at “vulnerable” is usually sufficient
4. Never exfiltrate real data — capture a screenshot, not the actual records

For public disclosures of vulnerabilities you discovered independently:

• Contact the vendor privately first (security@vendor.com or HackerOne/Bugcrowd)
• Give 90 days for a patch (coordinated disclosure)
• Publish after patch is available