Manipulating RPKI (and more) with marquees in TLS certificates (and more)

What if someone could disrupt your RPKI configuration or take over your RIPE Database objects? All because you clicked a single link to a RIPE NCC website?

I've spent the past year putting marquee tags and XSS injection payloads into every protocol field I control: TLS certificate SANs, DNS NSID and version.bind responses, HTTP Server headers, RIPE Database objects, wifi SSIDs, and much more. Many tools that display these fields treat them as safe data. And some of these share a trust boundary with more critical systems.

So far, my findings span two RIRs, several hosting providers, router firmware, DNS tooling, and more. The impacts range from funny, to taking over hosting customer accounts to rooting OpenWRT routers wirelessly.

At the most serious end, I found multiple paths via the RIPE NCC single sign-on session. From a single click, on a real ripe.net link, I could modify your RPKI ROAs, and you would not even know it happened until your packets started to drop. And I'd have taken over your RIPE Database objects too.

The common thread: some of our critical infrastructure turns out to be just a website with a login. RPKI has HSMs and key ceremonies, but the thing that actually changes your ROAs is a web app authenticated by a cookie. This talk covers patterns across all my findings, with a detailed walkthrough of the RPKI attack chain. And if you run any kind of tooling on your own network, I'll show you what to watch out for.