1000 third parties could have stolen RIPE NCC session tokens - by design

The RIPE NCC made its all-powerful single sign-on tokens available to over 1000 third parties. From a single link click, any logged-in RIPE NCC user would leak their session token. That token grants full access to the RPKI dashboard, the RIPE Database, and the member portal. RPKI and the Database govern internet routing for Europe, the Middle East, and Central Asia.

This access could be made persistent without being obvious to the compromised user, as it also allowed silently adding admin users and API keys to the account.

The token in question is the crowd.token_key cookie¹, used to authenticate access to all RIPE NCC services. RIPE NCC scoped it to *.ripe.net, so any HTTPS server under that domain receives it from any logged-in browser. That scope is the core of the problem.

This is a companion to my XSS+CSRF exploit chain, which compromised the RIPE NCC RPKI Dashboard and RIPE Database. This approach is simpler and broader: a full session, not blind writes.

Why session tokens are worse than CSRF

My RPKI and Database chain used CSRF: blind writes that could modify ROAs and RIPE Database objects, but could not read responses. A stolen session token is far more powerful.

A stolen session gives full read and write access to every RIPE NCC service the victim uses: the member portal, RPKI dashboard, RIPE Database, RIPE Atlas, resource transfers, ticket history, and any API keys or personal data visible there. It is not limited to blind writes.

I confirmed the cookie is not bound to IP, device, or browser by transferring my own token to a different device on a different network, and pointed this out to RIPE NCC in February 2025.

Keeping persistent access

A session token still has a limited lifetime. If the original user logs out, the session is destroyed. However, with full access to the RIPE NCC portals, an attacker can persist their access beyond the session.

Two methods are available:

• Creating API keys for the IP Analyser and My Resources (which I think might be read-only), and more importantly, RPKI.
• Adding new users, including admins, to the LIR account, i.e. full access to any RIPE NCC service.

Neither of these requires re-authentication, and neither notifies the original user or the company contact. This is only visible if a user happens to open the page. Even then, keys aren’t too hard to hide if given a generic description, but user accounts may be more suspect from their email address.

Persisting access has several benefits for an attacker. They can harvest accounts over time, then use them all in a coordinated attack at the most opportune moment, e.g. when defender response is slowest. Or abuse their access multiple times.

CAA, and why it wasn’t a barrier

Certification Authority Authorisation (CAA) is a DNS record type that specifies which Certificate Authorities may issue TLS certificates for a domain. Without a CAA record, any CA can issue a certificate to anyone who can prove control over a hostname under that domain. If you have an IP address that resolves to a name under *.ripe.net, and there is no CAA restriction, you can pass the standard domain ownership verification² and get a legitimate TLS certificate from Let’s Encrypt or any other public CA.

There was actually a CAA for ripe.net, which by default applies to anything more specific that doesn’t have its own CAA. However, this already included Let’s Encrypt, and had no other restrictions, so this was not an obstacle.

A legitimate TLS certificate means browsers trust the site and will send the (Secure) crowd.token_key cookie with any request to it. That is all an attacker needs.

Scenario 1: the RIPE meeting network

RIPE NCC hosts RIPE meetings twice a year. The meeting network is operated under mtg.ripe.net. Attendees connect to the meeting wifi and receive DHCP addresses, each with a forward DNS record like dhcp-25-50.mtg.ripe.net.

At the time of my report in February 2025, there was no CAA record on mtg.ripe.net. Anyone at the meeting, sitting in the audience with a laptop on the wifi, could:

1. Request a TLS certificate from Let’s Encrypt for their DHCP hostname, e.g. dhcp-25-50.mtg.ripe.net
2. Serve any content over HTTPS on that hostname
3. Get any RIPE NCC user to visit that link
4. Collect their crowd.token_key cookies, sent automatically by the browser because the hostname was under *.ripe.net
5. Use those cookies to access every RIPE NCC service as the victim

RIPE meetings bring together many of the people who manage RPKI and RIPE Database objects for networks across Europe, the Middle East, and Central Asia. The attack required nothing beyond attending the meeting, which is open to anyone.

This was fixed by adding a restrictive CAA record to mtg.ripe.net in February 2025, approximately 10 days after my report.

Scenario 2: the Atlas anchor network

RIPE Atlas anchors are measurement nodes hosted by volunteers and organisations worldwide. At the time of my report, there were over 1000 anchor hosts. These are hosted under anchors.atlas.ripe.net, on IPs belonging to their host. There was no CAA record on anchors.atlas.ripe.net.

Any of the host organisations could have used the same approach. It did not require the organisation itself to be malicious: one rogue employee would have been sufficient.

The fix, adding a restrictive CAA record, was deployed sometime before May 2025. I noticed it when I checked independently, as I was not notified of the fix (a pattern I describe in the disclosure post).

Curiously, a restrictive CAA record had already been created for probes.atlas.ripe.net, the subdomain for probes, which can be hosted by literally anyone who registers a RIPE NCC account and plugs in a device. Someone had thought about the risk for probes, but not for anchors. I still recommend that anchors and probes should not be hosted under *.ripe.net at all, regardless of CAA: the architecture is risky.

Trust scope vs responsible disclosure scope

The RIPE NCC responsible disclosure policy lists several exclusions:

• *.probes.atlas.ripe.net
• *.anchors.atlas.ripe.net
• Any *.ripe.net host located outside of the in-scope IP ranges
• RIPE Meeting network (2001:67c:64::/48 and 193.0.24.0/21)

That’s a curious gap in scope: anchors and the RIPE meeting network are explicitly excluded from responsible disclosure, but not from cookie trust.

The exclusion makes sense to some degree: RIPE NCC has limited control over these hosts, like my laptop on the meeting wifi or my Atlas probe at home. They acknowledged that by excluding such hosts from the disclosure scope. And yet those same hosts are inside the SSO cookie’s trust scope.

The scope of responsible disclosure reflects what RIPE NCC can manage. The trust scope is much wider, and that gap created this vulnerability.

Has this been exploited?

All certificates are recorded in Certificate Transparency logs, so it is possible to check.

For mtg.ripe.net, there are no certificates other than nscache.mtg.ripe.net. There has been no exploitation of this vector.

For anchors, there were numerous certificates around 2020, but these most likely represent legitimate certificates. No certificates have been requested for several years.

The broader lesson

Scoping the crowd.token_key cookie to *.ripe.net meant that every HTTPS-serving hostname under that domain was implicitly trusted with authenticated access to all RIPE NCC services. The SSO trust domain was far larger than the security model assumed, and RIPE NCC likely never consciously put Atlas anchor hosts or the meeting wifi in a position where they could obtain session tokens.

This is why you often see different domains used for sensitive and user content. GitHub uses github.com for the ordinary site, github.io for user content. Even with restrictive CAA, hosts run by complete strangers should never be placed under the same domain as critical infrastructure like the RIPE NCC RPKI dashboard.

The fix was two DNS records. But even then, the design is flawed and risky: strange computers should not get hostnames under *.ripe.net.

Other good measures would be:

• Restrict the CAAs on ripe.net to specific accounts with the accounturi parameter. This means even full access to a .ripe.net host is not enough to request a new certificate, the attacker would need the private key too. This can be annoying, but worth it for critical domains like ripe.net.
• Require additional authentication for critical changes such as adding users or changing API key configuration. I’ve noted “sudo mode” in my earlier post too.
• Notify the user/LIR for these critical changes.

OWASP has a relevant cheat sheet on subdomain takeover. The typical case is accidental: a subdomain is left pointing at an unclaimed external service. Here it was deliberate: RIPE NCC intentionally placed third-party hosts under their own cookie domain.

Disclosure

These issues were reported to RIPE NCC in February 2025. mtg.ripe.net was fixed within approximately 10 days. anchors.atlas.ripe.net was fixed sometime before May 2025. I was not notified and discovered it independently.

These issues were part of Intigriti report RIPENCC-MMP7ZVEF, which paid € 1100 (tier 1, critical) covering both this and the XSS+CSRF chain to RIPE Database. The bounty was released 11 months after the report.

RIPE NCC has not published any acknowledgement of this vulnerability, nor credited me as the reporter on their own channels, despite their responsible disclosure policy committing to such reports for major security issues.

I’ve written more extensively on the disclosure process in the companion post: Inside a 14-month responsible disclosure with the RIPE NCC.

These posts were shared with RIPE NCC for factual review prior to publication. Factual feedback from RIPE NCC has been incorporated.

I'm Sasha Romijn, an independent developer and internet infrastructure specialist in Amsterdam. I find security issues in internet infrastructure, usually in configurations, trust relationships, and cross-system behaviour that got overlooked. Previous finds include rooting OpenWrt via SSID and, some years back, compromising Apple keychain access groups.

Find me on Mastodon, Bluesky, or work with me.