UUID Security Audit Skill

A skill for identifying and assessing UUID-related security vulnerabilities in web applications and systems.

When to Use This Skill

Use this skill when:

• Analyzing web applications that use UUIDs for tokens, session IDs, or identifiers
• Reviewing password reset mechanisms that rely on UUIDs
• Assessing the security of any system using UUIDs as secrets or tokens
• Investigating potential identifier prediction vulnerabilities
• Performing security audits on authentication systems
• Understanding UUID version implications for security

UUID Security Fundamentals

UUID Versions and Security Implications

Version	Generation Method	Security Risk
v1	Time-based + MAC address	HIGH - Predictable, exposes system info
v2	Time-based + local domain	HIGH - Similar to v1
v3	MD5 hash	MEDIUM - Deterministic from namespace+name
v4	Random	LOW - Cryptographically random
v5	SHA-1 hash	MEDIUM - Deterministic from namespace+name

UUID Structure

UUIDs follow this format:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

• Position M (13th character): Indicates UUID version (1-5)
• Position N (17th character): Indicates UUID variant

Example:

12345678-abcd-1a56-a539-103755193864

• Version:

  1

  (v1 - time-based)
• Variant:

  a

  (standard UUID variant)

Security Assessment Checklist

1. Identify UUID Version

Check the version digit in position 13:

• v1/v2: Time-based, potentially predictable
• v3/v5: Hash-based, deterministic
• v4: Random, most secure for tokens

2. Assess Predictability Risk

High Risk Indicators:

• UUID v1 used for security tokens (password resets, session IDs)
• Sequential UUID generation without randomness
• UUIDs generated in rapid succession
• No rate limiting on UUID-based endpoints

Medium Risk Indicators:

• UUID v3/v5 with predictable namespace/name
• UUIDs exposed in URLs or logs

Low Risk Indicators:

• UUID v4 with proper random number generator
• UUIDs used only as non-secret identifiers

3. Evaluate Implementation Context

Critical Security Contexts (require UUID v4 or better):

• Password reset tokens
• Session identifiers
• API keys or secrets
• Two-factor authentication codes
• Account recovery links

Acceptable for Non-Secret Identifiers:

• Database primary keys (when not exposed)
• Internal object references
• Non-sensitive tracking IDs

Sandwich Attack Analysis

The sandwich attack exploits predictable UUID v1 generation in time-sensitive operations.

Attack Scenario

1. Prerequisites:

   • Application uses UUID v1 for security tokens
   • Multiple accounts can trigger token generation
   • No rate limiting on token validation endpoints

2. Attack Flow:

   Attacker Account 1 → Request Token → Get UUID_A
   Victim Account     → Request Token → Get UUID_V (unknown)
   Attacker Account 2 → Request Token → Get UUID_B
   
   UUID_V falls between UUID_A and UUID_B
   Brute force the range to find UUID_V
   

3. Detection Signs:

   • UUIDs generated in sequence show predictable patterns
   • Time-based components increment sequentially
   • Same node ID (MAC address) across UUIDs

Mitigation Strategies

1. Use UUID v4 for all security-sensitive tokens
2. Implement rate limiting on token validation endpoints
3. Add expiration to all tokens (short-lived)
4. Use cryptographically secure random generators
5. Consider alternative token formats (JWT, opaque tokens)

Testing Procedures

Step 1: Enumerate UUID Usage

Identify where UUIDs appear in the application:

• URLs and query parameters
• API responses
• Cookies and headers
• Database schemas
• Log files

Step 2: Analyze UUID Patterns

For each UUID found:

1. Extract the version digit (position 13)
2. Check for sequential patterns across multiple UUIDs
3. Look for consistent node IDs (last 12 characters in v1)
4. Assess if UUIDs are used as secrets or just identifiers

Step 3: Test Predictability

If UUID v1 is detected:

1. Generate multiple UUIDs in quick succession
2. Compare the time-based components
3. Calculate the time delta between UUIDs
4. Estimate brute-force feasibility

Step 4: Validate Token Endpoints

For each UUID-based endpoint:

1. Test with invalid UUIDs (check error messages)
2. Test rate limiting (rapid requests)
3. Test with sequential UUIDs
4. Check for information disclosure in responses

Tools and Resources

Detection Tools

• UUID Detector (Burp Suite): Extension to identify UUIDs in traffic
• Custom scripts: Use

  scripts/analyze-uuids.py

  for batch analysis

Attack Simulation (Educational Only)

• Sandwich Tool: https://github.com/Lupin-Holmes/sandwich
• Custom brute-force: Use

  scripts/uuid-range-test.py

  for testing

References

• UUID Security Best Practices
• RFC 4122 - UUID Specification
• OWASP - Broken Authentication

Reporting Findings

Severity Classification

Finding	Severity	Remediation
UUID v1 for security tokens	Critical	Switch to UUID v4
No rate limiting on UUID endpoints	High	Implement rate limiting
UUID v3/v5 with predictable input	Medium	Use UUID v4 or random namespace
UUIDs in URLs (non-sensitive)	Low	Consider POST or headers

Report Template

## UUID Security Finding

**Location**: [endpoint/path]
**UUID Version**: [v1/v2/v3/v4/v5]
**Usage Context**: [password reset/session ID/etc.]
**Risk Level**: [Critical/High/Medium/Low]

**Description**:
[Explain the vulnerability]

**Evidence**:
[Sample UUIDs, request/response examples]

**Impact**:
[What an attacker could achieve]

**Remediation**:
[Specific steps to fix]

Quick Reference

UUID Version Detection

# Position 13 (0-indexed: 14) indicates version
uuid_string = "12345678-abcd-1a56-a539-103755193864"
version = uuid_string[14]  # Returns '1' for v1

Security Decision Tree

1. Is the UUID used as a secret/token? → Must use v4
2. Is the UUID exposed in URLs/logs? → Prefer v4
3. Is the UUID generated frequently? → Avoid v1
4. Is the UUID for internal use only? → v1 acceptable

Common Mistakes to Avoid

❌ Using UUID v1 for password reset tokens ❌ Relying on UUID obscurity for security ❌ Not rate-limiting UUID validation endpoints ❌ Using predictable namespaces in v3/v5 ❌ Exposing UUIDs in error messages

✅ Use UUID v4 for all security tokens ✅ Implement proper rate limiting ✅ Add token expiration ✅ Use cryptographically secure RNG ✅ Validate UUIDs server-side