Hoe één klik je netwerk platlegt: RPKI-kwetsbaarheden uitgelegd

De routing van het internet draait op vertrouwen. Netwerkbeheerders rekenen erop dat systemen voor route-autorisatie waterdicht zijn. Maar een simpele cross-site scripting-fout gooit dat omver.

Onderzoekers legden onlangs een slimme aanval bloot op de RPKI-infrastructuur van RIPE NCC. Dit systeem beveiligt routing in Europa, het Midden-Oosten en Centraal-Azië. Met een kwaadaardige link en wat slordige ontwerpkeuzes leg je een heel netwerk lam.

Wat doet RPKI en waarom raakt het jou?

RPKI – Resource Public Key Infrastructure – tackelt een basisprobleem in internetrouting: hoe voorkom je dat iemand jouw IP-adressen kaapt en verkeer omleidt?

Het systeem gebruikt Route Origin Authorizations (ROAs). Dat zijn crypto-ondertekende verklaringen over wie bepaalde IP-prefixen mag aankondigen. Routers wereldwijd checken dit via een globale registry. Klinkt solide. Maar het hangt af van een webapp.

De realiteit? RPKI is in feite een website. Met HSM's, key-rotaties en audits. Toch verloopt wijziging van ROAs via een simpele session cookie. Daar begon de ellende.

De aanval in stappen: van link naar blackout

Zo verloopt het in de praktijk:

Stap 1: Visphishing
De aanvaller stuurt een link naar RIPE Atlas, een vertrouwd diagnosetool van RIPE NCC. Engineers klikken zoiets vaak. "Kijk eens naar deze rare routing?" Bam, geklikt.

Stap 2: Onzichtbare code
Slachtoffer zit ingelogd in een RIPE-dienst. De link activeert XSS. De pagina lijkt normaal, maar JavaScript knoeit stiekem met de sessie.

Stap 3: ROA-sabotage
De code herschrijft alle ROAs in het dashboard. Ze blokkeren routing van de IP's. Het slachtoffer merkt niks.

Stap 4: Afgekapt
Binnen minuten pikken routers de fake ROAs op. Verkeer van het netwerk wordt geweigerd. In een test verloor de onderzoeker na 26 minuten Cloudflare-toegang. Na een uur dropte 80% van de netwerken alles.

Waarom zo gevaarlijk?

Een paar keuzes maakten van XSS een ramp:

Gedeelde cookies over domeinen
RIPE-diensten deelden sessies. XSS in Atlas gaf toegang tot RPKI. Eén gat, alles bloot.

Geen CSRF-blokkade
Geen tokens tegen Cross-Site Request Forgery. Een bezoekje volstond voor wijzigingen.

Makkelijke mute van meldingen
Alerts voor ROA-wijzigingen? Uit te zetten via hetzelfde gat. Blind vliegen.

Verstopte instap
Het lek zat niet in RPKI, maar in DNS-debug-velden. Elk veld is een risico.

De nasleep

Meer dan een blackout:

• Isolatie: Netwerk onbereikbaar, lijkt op storing.
• Chaos: Oorzaak onduidelijk, alerts vaag.
• RIPE Database overname: Andere objecten gekaapt, herstel via handmatige ingreep – dagenlang.
• BGP-hulp: Fake ROAs maken hijacks geloofwaardiger.

Lessen voor infra-beveiliging

Deze keten schreeuwt om actie:

1. Domein-scheiding is key
Cookies niet cross-domain. Per dienst authenticatie.

2. Laag voor laag
XSS mag geen root access geven. CSRF-tokens, CSP, re-auth voor kritiek werk.

3. Phishing-proof ontwerp
Engineers moeten links checken. Bouw dat in.

4. Geen 'veilige' velden
DNS-params of metadata? Behandel als vijandig.

5. Onafhankelijke monitoring
Alerts niet uitschakelbaar door aanvallers.

Wat is gepatcht?

Na 14 maanden disclosure fixte RIPE NCC: XSS in diensten, CSRF overal, cookie-beperkingen, robuuste alerts en input-checks.

Tips voor jouw setup

Beheer je DNS, RPKI of BGP? Check dit:

Session-architectuur audit. Waar werken cookies? XSS-spread?

CSRF testen. Scanners missen nuances.

Auth-niveaus. Step-up voor kritiek: TOTP of token.

Phishing als gegeven. Ontwerp voor die klik.

Alles valideren. Geen shortcuts.

De bittere pil

Zo'n keten sluipt voorbij reviews. Het mixt DNS, web en BGP-kennis, met keuzes die apart oké zijn maar samen dodelijk. Routing verdient beter dan webapp-security. Automatisering maakt het urgenter.

Eén klik. 80% down. Dagen herstel. Nu gefixt, maar check je zwakke schakels – ze zitten vaak uit zicht.