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:
   ```javascript
   // 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:
   ```bash
   # 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:
  ```go
  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:
   ```bash
   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:
   ```bash
   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:
   ```bash
   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:
   ```bash
   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