RIPE NCC SSO Cookie Scope Exposed Session Tokens to 1,000-Plus Third Parties

A guest post on RIPE Labs by security researcher Sasha Romijn, published alongside RIPE NCC's own disclosure response, reveals that the organisation's single sign-on session cookie was architecturally available to every HTTPS-serving host under the *.ripe.net domain — a scope that encompassed well over a thousand nodes outside RIPE NCC's direct control.

The cookie in question, crowd.token_key, authenticates users across the full suite of RIPE NCC services: the RPKI Dashboard, the RIPE Database, the LIR member portal, RIPE Atlas, resource-transfer workflows, and stored API keys. Romijn confirmed the token carried no binding to IP address, device, or browser, meaning a copy obtained from one session could be used freely on another network entirely.

Two concrete attack surfaces were identified. During RIPE meetings, attendees on the conference Wi-Fi receive DHCP hostnames under mtg.ripe.net. Because no restrictive Certificate Authority Authorization record existed on that subdomain, any attendee could obtain a legitimate TLS certificate from a public CA for their assigned hostname, serve a page over HTTPS, and collect crowd.token_key cookies from any logged-in visitor who followed a link to that address. RIPE meetings draw the very operators who manage routing policy for Europe, the Middle East, and Central Asia.

The second surface was the Atlas anchor network. At the time of the report, more than 1,000 anchor nodes were hosted by external organisations under anchors.atlas.ripe.net, again without a restricting CAA record. A single rogue employee at any of those organisations could have exploited the same approach — the anchor's hosting organisation did not need to be compromised as a whole.

What makes stolen sessions more dangerous than the CSRF vulnerabilities Romijn also reported is the difference between blind writes and full authenticated access. The CSRF chain allowed an attacker to push changes to RPKI Route Origin Authorizations and RIPE Database objects without reading responses. A captured session token provides unrestricted read and write access, and can be extended: adding new admin-level users or creating RPKI API keys requires no further authentication and generates no automatic notification to the account holder or designated company contact.

Certificate Transparency logs show no certificates were actually issued for mtg.ripe.net addresses beyond an infrastructure record, and anchor-domain certificate activity predates the vulnerability period, suggesting neither vector was exploited.

RIPE NCC's own post-mortem acknowledges that the initial CSRF fix was incomplete — a subsequent review found the original proof-of-concept still worked — and that communication with Romijn fragmented across channels, slowing coordination between internal teams. The bounty payment arrived 11 months after the report. RIPE NCC states it is now overhauling its authentication and authorisation architecture and improving cross-team coordination for complex multi-service disclosures.

Romijn's recommended mitigations go beyond the two CAA records that were deployed: move Atlas anchors and probes off *.ripe.net entirely, restrict CAA records to specific account URIs so that domain control alone is insufficient to obtain a certificate, and require step-up authentication before critical account changes such as adding users or rotating API keys.

For hosting and infrastructure operators running SSO across subdomains that include third-party or user-controlled hostnames, the case illustrates that cookie scope and responsible-disclosure scope can diverge in consequential ways: RIPE NCC's bug bounty policy explicitly excluded the Atlas and meeting-network subdomains, yet the SSO trust boundary included them.