clawd/memory/shannon-scan-2026-02-14/deliverables/auth_exploitation_evidence.md

Authentication Exploitation Evidence

Successfully Exploited Vulnerabilities

AUTH-VULN-07: Universal Authentication Bypass via Hardcoded Backdoor Code

Summary:

• Vulnerable location: POST /verify and POST /send-code endpoints
• Overview: The application contains a hardcoded backdoor verification code 250365 that bypasses email verification for ANY user account, enabling complete authentication bypass
• Impact: Complete authentication bypass - attacker can authenticate as any email address without access to the victim's email, leading to immediate account takeover
• Severity: CRITICAL

Prerequisites:

• None - works for any email address

Exploitation Steps:

1. Navigate to the login page at https://inou.com/start

2. Enter any target email address (victim's email or arbitrary email):

   • In the email field, enter: [TARGET_EMAIL] (e.g., victim@example.com)
   • Click "Continue" button

3. The application will navigate to https://inou.com/send-code and display a verification code input field

   • Note: A legitimate verification code may be sent to the email, but it is NOT required

4. Enter the hardcoded backdoor code instead of the legitimate verification code:

   • In the "Verification code" field, enter: 250365
   • Click "Verify" button

5. Authentication succeeds and redirects to https://inou.com/onboard or https://inou.com/dashboard depending on account status

6. Verify complete account access:

   • Navigate to https://inou.com/dashboard
   • Observe full authenticated access to the victim's account
   • Can view dossiers, upload health data, and perform all authenticated actions

Proof of Impact:

Test Case 1: Account Creation Bypass

• Tested email: pentest@example.com
• Backdoor code used: 250365
• Result: Successfully authenticated without email verification
• Session cookie received: login=d74520ade621d4b8
• Dashboard access confirmed at: https://inou.com/dashboard
• Screenshot: /home/pentest/workspace/auth-vuln-07-backdoor-success.png

Test Case 2: Universal Bypass Confirmation

• Tested email: victim@example.com (arbitrary victim account)
• Backdoor code used: 250365
• Result: Successfully authenticated as victim without their email access
• Authentication succeeded and onboarding page displayed
• Confirmed backdoor works for ANY email address

Code Evidence:

• File: /repos/inou-portal/portal/main.go (web endpoint)
• File: /repos/inou-portal/lib/dbcore.go:347 (verification logic)
• File: /repos/inou-portal/portal/api_mobile.go:127-128 (mobile API endpoint)
• Backdoor code check: if code != 250365 && (d.AuthCode != code || time.Now().Unix() > d.AuthCodeExpiresAt)
• Comment in source: // TODO: Remove backdoor code 250365 before production

Notes:

• This vulnerability affects BOTH web (/verify) and mobile API (/api/v1/auth/verify) endpoints
• No legitimate verification code is needed when backdoor code is used
• Works for existing accounts and newly created accounts
• Completely bypasses email ownership verification
• HIPAA/GDPR violation - unauthorized access to protected health information

AUTH-VULN-05: Session Hijacking via Lack of Server-Side Session Invalidation

Summary:

• Vulnerable location: GET /logout endpoint
• Overview: The logout endpoint only clears the client-side cookie but does NOT invalidate the session on the server, allowing stolen session cookies to remain valid indefinitely even after the victim logs out
• Impact: Persistent account access after session cookie theft - attacker maintains access even after victim attempts to terminate the session via logout
• Severity: CRITICAL

Prerequisites:

• Attacker must obtain a valid session cookie (via XSS, network interception, or physical access)

Exploitation Steps:

1. Victim authenticates to the application:

   • Navigate to https://inou.com/start
   • Enter email: [VICTIM_EMAIL]
   • Click "Continue"
   • Enter verification code (can use backdoor code 250365)
   • Authentication succeeds

2. Attacker captures the victim's session cookie:

   • Cookie name: login
   • Cookie value: [SESSION_ID] (e.g., d74520ade621d4b8)
   • Cookie attributes: HttpOnly=true, Secure=true, SameSite=Lax

3. Victim logs out of the application:

   • Navigate to https://inou.com/logout
   • Observe client-side cookie is cleared
   • Browser shows logged-out state (redirected to homepage)

4. Attacker injects the stolen session cookie in a new browser session:

   // Using browser developer tools or Playwright
   await page.context().addCookies([{
     name: 'login',
     value: '[STOLEN_SESSION_ID]',
     domain: 'inou.com',
     path: '/',
     httpOnly: true,
     secure: true,
     sameSite: 'Lax'
   }]);
   

5. Attacker navigates to protected resources:

   • Navigate to https://inou.com/dashboard
   • Observe full authenticated access is granted
   • Session is still valid despite victim logging out

6. Verify persistent access:

   • Can view all dossiers
   • Can modify account settings
   • Can upload/download health data
   • Full account takeover persists indefinitely

Proof of Impact:

Test Execution:

• Original session cookie: login=d74520ade621d4b8
• Victim email: pentest@example.com

Step 1: Authentication and Cookie Capture

• Authenticated successfully at https://inou.com/dashboard
• Captured session cookie value: d74520ade621d4b8

Step 2: Victim Logout

• Navigated to https://inou.com/logout
• Client-side cookie cleared (verified: browser storage empty)
• Redirected to public homepage (logged-out state)

Step 3: Session Cookie Injection

• Injected stolen cookie: login=d74520ade621d4b8
• Navigated to https://inou.com/dashboard

Step 4: Access Verification

• Result: SUCCESSFUL - Full authenticated access granted
• Dashboard loaded showing "Pentest User" account
• All dossiers accessible
• No re-authentication required
• Screenshot: /home/pentest/workspace/auth-vuln-05-session-hijack-success.png

Code Evidence:

• File: /repos/inou-portal/portal/main.go:638-641
• Logout handler only clears client cookie: http.SetCookie(w, &http.Cookie{Name: "login", Value: "", Path: "/", MaxAge: -1})
• No database update to invalidate session
• No session revocation mechanism
• SessionToken field remains valid in database

Notes:

• Stolen cookies work indefinitely - no session timeout mechanism
• Mobile API has NO logout endpoint at all
• Session tokens persist across web logout
• Attacker maintains access until victim changes email or account is deleted
• No audit log of active sessions or ability to revoke sessions

AUTH-VULN-04: Session Fixation via Non-Rotated Session Identifiers

Summary:

• Vulnerable location: POST /verify endpoint (authentication flow)
• Overview: The session identifier (dossierID) is not rotated after successful authentication, and the same dossierID is reused across multiple login sessions for the same email address
• Impact: Session fixation attack possible - attacker can predict or force a session ID before victim authentication, then hijack the session after victim authenticates
• Severity: HIGH

Prerequisites:

• Knowledge of victim's email address
• Ability to predict or observe victim's dossierID

Exploitation Steps:

1. Attacker initiates authentication flow for victim's email:

   • Navigate to https://inou.com/start
   • Enter victim's email: [VICTIM_EMAIL]
   • Click "Continue"
   • Navigate to verification code page

2. Attacker authenticates to observe the session ID pattern:

   • Enter backdoor code: 250365
   • Click "Verify"
   • Authentication succeeds

3. Capture the session cookie (dossierID):

   • Extract cookie value from browser
   • Cookie name: login
   • Cookie value represents the dossierID: [DOSSIER_ID]

4. Attacker logs out:

   • Navigate to https://inou.com/logout
   • Session cookie cleared from browser

5. Attacker authenticates again with SAME email:

   • Navigate to https://inou.com/start
   • Enter SAME email: [VICTIM_EMAIL]
   • Complete authentication with backdoor code 250365

6. Verify session ID is NOT rotated:

   • Extract new session cookie value
   • Compare with previous session cookie
   • Observe: Session ID is IDENTICAL

Proof of Impact:

Test Execution:

• Test email: session-fixation-test@example.com

First Authentication:

• Authenticated successfully at https://inou.com/onboard
• Session cookie captured: login=f4d22b2137cf536c
• DossierID: f4d22b2137cf536c

Logout:

• Navigated to https://inou.com/logout
• Client-side cookie cleared

Second Authentication (Same Email):

• Re-authenticated with same email: session-fixation-test@example.com
• Used backdoor code: 250365
• Authentication succeeded

Session ID Comparison:

• Second session cookie: login=f4d22b2137cf536c
• IDENTICAL to first session: ✓ CONFIRMED
• Match result: matchesFirst: true

Code Evidence:

• File: /repos/inou-portal/lib/dbcore.go:351
• Verification logic does NOT generate new session ID on authentication
• DossierID is deterministic based on email address
• No session rotation mechanism in authentication flow
• Same dossierID reused across all login sessions

Attack Scenario:

1. Attacker determines victim's dossierID (via previous session observation or prediction)
2. Attacker can pre-set the session cookie in victim's browser (via XSS or social engineering)
3. When victim authenticates legitimately, the pre-set session becomes valid
4. Attacker now shares the authenticated session with victim
5. Attacker monitors victim's account activity in real-time

Notes:

• Session IDs are not regenerated after privilege escalation (authentication)
• DossierID is deterministic and predictable for a given email
• Classic session fixation vulnerability pattern
• Combined with lack of logout invalidation (AUTH-VULN-05), creates persistent access vector

AUTH-VULN-01: Verification Code Brute Force via Missing Rate Limiting

Summary:

• Vulnerable location: POST /verify endpoint
• Overview: No rate limiting, account lockout, or attempt tracking on verification code validation allows unlimited guessing of 6-digit codes
• Impact: Account takeover via brute force - attacker can systematically try all 1,000,000 possible codes to authenticate as any user
• Severity: HIGH

Prerequisites:

• Target email address (can be obtained via user enumeration or known victims)

Exploitation Steps:

1. Attacker identifies target email address:

   • Target email: [VICTIM_EMAIL]

2. Trigger verification code generation for victim:

   • Navigate to https://inou.com/start
   • Enter target email: [VICTIM_EMAIL]
   • Click "Continue"
   • Legitimate verification code sent to victim's email

3. Automated brute force attack execution:

   # Pseudocode for brute force script
   for code in range(000000, 999999):
       response = POST https://inou.com/verify
       data: {"email": "[VICTIM_EMAIL]", "code": code}
   
       if response.status == 200 and "dashboard" in response.url:
           print(f"SUCCESS! Valid code: {code}")
           save_session_cookie()
           break
   
       # No rate limiting - can send unlimited requests
   

4. At average 100 requests/second:

   • Maximum attempts needed: 1,000,000 codes
   • Average time to success: ~83 minutes (500,000 attempts)
   • Maximum time: ~166 minutes (if code is in last half)

5. Upon finding valid code:

   • Authentication succeeds
   • Session cookie obtained
   • Full account access achieved

Proof of Impact:

Test Execution:

• Created automated brute force test script: /repos/inou-portal/rate_limit_test.js
• Target endpoint: POST https://inou.com/verify
• Test email: brute-force-test@example.com

Test Results:

• Sent 20 rapid sequential requests with codes: 000000-000019
• Duration: 3.1 seconds total
• Average response time: 155ms per request
• Status codes: All 20 returned HTTP 200 (success)
• Rate limiting responses: 0 (zero HTTP 429 responses)
• CAPTCHA challenges: 0
• Account lockouts: 0

Vulnerability Confirmation:

• ✅ NO rate limiting detected
• ✅ NO account lockout mechanism
• ✅ NO CAPTCHA after failed attempts
• ✅ NO attempt tracking or monitoring
• ✅ Brute force attack is FULLY POSSIBLE

Attack Time Calculation:

• Total possible codes: 1,000,000 (000000 to 999999)
• Request rate (sequential): ~6.5 requests/second (155ms each)
• Average time to success: ~21 hours sequential
• With 10 parallel connections: ~2.1 hours
• With 100 parallel connections: ~12 minutes

Code Evidence:

• File: /repos/inou-portal/lib/dbcore.go:330-353
• No rate limiting logic in verification handler
• No attempt counter in database schema
• No IP-based throttling
• No CAPTCHA integration

Notes:

• Attack can be optimized with parallel requests (reduces time to minutes)
• No logging or alerting mechanism for brute force attempts
• Verification codes expire after limited time (provides small time window)
• Combined with email flooding (AUTH-VULN-02), attacker can generate fresh codes repeatedly
• Affects both /verify (web) and /api/v1/auth/verify (mobile API) endpoints

Potential Vulnerabilities (Validation Blocked or Requires Internal Access)

AUTH-VULN-06: Mobile Session Token Persistence Without Expiration

Summary:

• Vulnerable location: POST /api/v1/auth/verify (mobile authentication endpoint)
• Current Blocker: Unable to obtain valid mobile API SessionToken from external access (backdoor code works via web interface but mobile API requires additional investigation)
• Potential Impact: Permanent API access without expiration or revocation mechanism
• Confidence: HIGH (based on code review)

Evidence of Vulnerability:

Code Analysis:

• File: /repos/inou-portal/portal/api_mobile.go:136-141
• SessionToken generation logic:

  token := d.SessionToken
  if token == "" {
      token = generateSessionToken()
      lib.DossierSetSessionToken(d.DossierID, token)
  }
  

• Database schema has SessionToken field with NO expiry timestamp
• No TTL (time-to-live) mechanism
• No validation of token age in authentication middleware
• Tokens generated once and reused indefinitely

Attempted Exploitation:

1. Created test scripts to authenticate via mobile API:

   • Script: /repos/inou-portal/test-mobile-auth.js
   • Endpoint: POST https://inou.com/api/v1/auth/verify
   • Payload: {"email":"pentest@example.com","code":"250365"}

2. Result: 401 Unauthorized

   • Mobile API backdoor requires existing dossier
   • Unable to demonstrate full exploitation from external access

How This Would Be Exploited:

If a mobile SessionToken were obtained (via interception, database access, or mobile app reverse engineering):

1. Capture mobile SessionToken from legitimate authentication:

   • Intercept response from: POST https://inou.com/api/v1/auth/verify
   • Extract token value from: {"token":"[SESSION_TOKEN]","needsOnboard":false}

2. Test token against authenticated endpoints:

   curl -X GET https://inou.com/api/v1/profile \
     -H "Authorization: Bearer [SESSION_TOKEN]"
   

3. Verify token has no expiration:

   • Wait extended period (days, weeks, months)
   • Re-test same token against API endpoints
   • Expected: Token remains valid indefinitely

4. Token persists even after web logout:

   • Victim logs out via https://inou.com/logout
   • Mobile SessionToken still valid (separate from web session cookie)
   • Mobile API access maintained

Expected Impact:

• Stolen mobile tokens provide permanent API access
• No revocation mechanism even after password/email change
• Tokens work across device changes
• No ability for users to view or revoke active API sessions

Notes:

• Code analysis confirms vulnerability exists
• Requires mobile app or API access to fully demonstrate
• No logout endpoint for mobile API: /api/v1/auth/logout returns 404
• Web logout does NOT invalidate mobile SessionTokens

AUTH-VULN-02: Email Flooding Denial of Service via Unlimited Verification Code Generation

Summary:

• Vulnerable location: POST /send-code endpoint
• Current Blocker: Unable to complete full flooding test due to connection errors with rapid requests
• Potential Impact: Denial of service attack flooding victim's email inbox and SMTP server
• Confidence: HIGH (based on code review and partial testing)

Evidence of Vulnerability:

Code Analysis:

• File: /repos/inou-portal/portal/main.go:540-557
• No rate limiting on verification code generation
• Only defense is 2-second nonce check (trivial to bypass)
• No per-email or per-IP throttling
• Same email can receive unlimited codes

Attempted Exploitation:

1. Tested rapid code generation requests:

   • Target: POST https://inou.com/send-code
   • Payload: {"email":"email-flood-test@example.com"}
   • Sent 5 rapid requests

2. Result: Connection errors ("socket hang up")

   • May indicate some network-level protection
   • Or server instability under rapid requests
   • Unable to confirm if emails were actually sent

How This Would Be Exploited:

If connection stability allowed:

1. Attacker identifies victim email address:

   • Target: victim@example.com

2. Automated email flooding script:

   for i in range(1, 1000):
       POST https://inou.com/send-code
       data: {"email": "victim@example.com"}
       wait 2.1 seconds  # Bypass nonce check
   
       print(f"Code generation request {i} sent")
   

3. With 2-second delay between requests:

   • 1000 requests = ~33 minutes
   • Victim receives 1000 verification emails
   • Email inbox flooded and unusable

4. Denial of service impacts:

   • Victim cannot find legitimate emails
   • SMTP server load increases
   • Legitimate login attempts blocked by email flood
   • Potential email account suspension

Expected Impact:

• Victim's email inbox completely flooded
• SMTP server resource exhaustion
• Prevents legitimate user login (can't find real code)
• Email provider may flag account as spam target

Notes:

• Affects both /send-code (web) and /api/v1/auth/send (mobile API)
• No CAPTCHA before code generation
• No global rate limiting observed
• Connection errors may indicate incomplete server-side protection

AUTH-VULN-08: Session Token Exposure via Missing Cache-Control Headers

Summary:

• Vulnerable location: POST /api/v1/auth/verify and authentication response endpoints
• Current Blocker: Unable to access proxy logs or browser cache from external testing
• Potential Impact: Session tokens cached in browser history, proxy logs, or CDN caches enabling future retrieval
• Confidence: MEDIUM

Evidence of Vulnerability:

Code Analysis:

• File: /repos/inou-portal/portal/api_mobile.go:256-259
• Authentication responses lack Cache-Control: no-store header
• OAuth endpoints properly set Cache-Control (showing developers are aware of the issue)
• Affects: /verify, /send-code, /api/v1/auth/send, /api/v1/auth/verify

How This Would Be Exploited:

If attacker gains access to browser cache, proxy logs, or CDN:

1. Victim authenticates normally:

   • POST https://inou.com/api/v1/auth/verify
   • Response contains SessionToken
   • Response cached due to missing Cache-Control: no-store header

2. Attacker accesses cached responses:

   • Browser cache: Check browser cache files on victim's computer
   • Proxy logs: Access corporate proxy server logs
   • CDN cache: Query CDN provider for cached responses

3. Extract SessionToken from cached response:

   • Locate cached API response
   • Parse JSON: {"token":"[SESSION_TOKEN]",...}
   • Extract token value

4. Use extracted token:

   curl -X GET https://inou.com/api/v1/profile \
     -H "Authorization: Bearer [EXTRACTED_TOKEN]"
   

Expected Impact:

• Session tokens retrievable from browser cache after victim logs out
• Proxy servers log authentication tokens
• Shared computers expose tokens to subsequent users
• Corporate networks can access employee tokens via proxy logs

Notes:

• Requires access to browser cache, proxy, or CDN (not directly exploitable externally)
• OAuth endpoints correctly implement Cache-Control headers
• Fix would be simple: Add Cache-Control: no-store, no-cache, must-revalidate, private header

AUTH-VULN-03: OAuth Client Secret Brute Force via Missing Rate Limiting

Summary:

• Vulnerable location: POST /oauth/token
• Current Blocker: Requires valid client_id which must be obtained through reconnaissance or leaks
• Potential Impact: OAuth access token compromise via client_secret brute force
• Confidence: MEDIUM

Evidence of Vulnerability:

Code Analysis:

• File: /repos/inou-portal/portal/oauth.go:144-296
• No rate limiting on client_secret validation attempts
• Bcrypt adds computational cost but doesn't prevent attacks
• No account lockout for OAuth clients

How This Would Be Exploited:

If attacker obtains a valid client_id (via application registration, leaks, or enumeration):

1. Obtain valid OAuth client_id:

   • Register OAuth application (if allowed)
   • Enumerate client_ids via error message differences
   • Or obtain from leaked credentials/config files

2. Brute force or credential stuffing attack:

   client_id="obtained_client_id"
   for secret in common_secrets_wordlist:
       POST https://inou.com/oauth/token
       data: {
           "grant_type": "client_credentials",
           "client_id": client_id,
           "client_secret": secret
       }
   
       if response.status == 200:
           save_access_token()
           break
   

3. If client_secret found:

   • Obtain OAuth access tokens
   • Access API endpoints with compromised OAuth credentials
   • Impersonate legitimate OAuth client

Expected Impact:

• Compromise of OAuth client credentials
• Unauthorized API access using victim client's identity
• Potential lateral movement to other integrated systems

Notes:

• Bcrypt provides some protection but doesn't prevent determined attacks
• Rate limiting would make brute force impractical
• Requires obtaining valid client_id first (reduces exploitability)
• Not directly exploitable from external access without reconnaissance

AUTH-VULN-09: Missing HTTPS Enforcement and HSTS Headers

Summary:

• Vulnerable location: All endpoints (application-level configuration)
• Current Blocker: Cannot perform SSL stripping from external position (requires MITM position)
• Potential Impact: SSL stripping attacks to intercept authentication credentials and session tokens
• Confidence: LOW (production likely has proper TLS)

Evidence of Vulnerability:

Code Analysis:

• File: /repos/inou-portal/portal/main.go:1963-1964
• Server runs on HTTP port 1080 (development mode)
• No HSTS (HTTP Strict Transport Security) header
• No application-level HTTPS enforcement
• Cookies set with Secure flag (would fail over HTTP)

How This Would Be Exploited:

If attacker can perform MITM (Man-in-the-Middle) attack:

1. Attacker positions themselves in network path:

   • Public WiFi network
   • Compromised router
   • ARP spoofing on LAN

2. SSL stripping attack:

   • Intercept victim's initial HTTP request
   • Strip HTTPS redirects (if any)
   • Forward victim to HTTP version of site
   • Proxy victim's requests to real HTTPS site
   • Victim sees http://inou.com (unencrypted)

3. Capture authentication data:

   • Email addresses in clear text
   • Verification codes in clear text
   • Session cookies if Secure flag removed
   • All API requests and responses

Expected Impact:

• Complete credential interception
• Session hijacking via captured cookies
• Privacy breach (health data exposed)

Notes:

• Production deployment likely has proper TLS termination at load balancer
• Development server configuration shows HTTP-only setup
• HSTS header would prevent SSL stripping attacks
• Not exploitable from external position without MITM capability
• Requires network-level access

AUTH-VULN-10: OAuth CSRF via Optional State Parameter

Summary:

• Vulnerable location: GET /oauth/authorize
• Current Blocker: Requires setting up OAuth client application and social engineering victim
• Potential Impact: CSRF attack forcing victim to authorize attacker's OAuth application
• Confidence: LOW

Evidence of Vulnerability:

Code Analysis:

• File: /repos/inou-portal/portal/oauth.go:62
• OAuth state parameter accepted but not enforced as required
• No minimum length validation
• PKCE provides partial mitigation

How This Would Be Exploited:

If attacker creates malicious OAuth authorization URL:

1. Attacker registers OAuth application:

   • Obtain client_id
   • Set redirect_uri to attacker-controlled domain

2. Craft malicious authorization URL without state parameter:

   https://inou.com/oauth/authorize?client_id=[ATTACKER_CLIENT_ID]&redirect_uri=[ATTACKER_DOMAIN]&response_type=code
   

3. Social engineering attack:

   • Send malicious URL to victim
   • Victim clicks link while authenticated
   • Authorization granted without CSRF protection

4. Receive authorization code:

   • Victim redirected to attacker's redirect_uri
   • Attacker receives authorization code
   • Exchange code for access token
   • Access victim's data via OAuth

Expected Impact:

• Victim unknowingly authorizes attacker's application
• Attacker gains OAuth access to victim's account
• Potential data exfiltration via OAuth API

Notes:

• PKCE provides some protection for public clients
• State parameter should be mandatory per OAuth 2.0 spec
• Requires social engineering component
• Not directly exploitable without user interaction
• OAuth application registration may be restricted