Vaak ontstaan dit soort problemen niet doordat men aan het proberen is een aanval te doen, maar doordat iemand
geprobeerd heeft iets te blocken of anders te routen en daarbij een fout gemaakt heeft. Bijvoorbeeld een land wil
heel youtube blocken en wil dat realiseren door in hun eigen routers alle routes naar youtube om te zetten naar een
blackhole route, maar door een foutje maken ze er een router naar henzelf van en lekken ze deze informatie naar
buiten. Dat is althans wat er in het verleden al een paar keer is voorgekomen.

In dit geval had men wellicht een alternatieve verbinding die men wilde gebruiken voor alle verkeer naar CDN's en
heeft men die fout gemaakt, waarna dus "de hele wereld" verkeer naar die CDN's via hun verbinding ging routeren.

Je moet er niet bij voorbaat vanuit gaan dat dit is om dat verkeer te kunnen afluisteren. Het is gewoon een fout die
je als BGP beheerder heel makkelijk kunt maken en die daarom nog wel eens voorkomt. Als je dit wilt gebruiken om
af te luisteren dan is het natuurlijk niet handig om meteen een groot aantal netwerken te gaan omleiden, want daarmee
maak je de kans dat iemand het ontdekt veel groter. Zeker ook door die "moderne lapmiddelen" zoals RPKI die men
heeft ingevoerd om het allemaal iets beter onder controle te houden.

Natuurlijk zouden de certificaat uitgevers wel wat meer kunnen doen om dit theoretische scenario te vermijden, bijv
via een CAA record altijd een mail sturen als er een nieuw certificaat uitgegeven wordt. Dan moet je natuurlijk wel
een mailadres gebruiken in een andere omgeving dan die je probeert te beveiligen. En waarschijnlijk zal de stroom
mailtjes die daar dan op binnen komt terwijl alles OK is al snel de aandacht voor "vreemde" uitgiftes doen verslappen
dus daar moet ook een automatische verwerking achter hangen die de uitgiftes matched met de zelf gedane requests.

@Anoniem 12:02: dank voor jouw reactie, maar je stelt mij niet gerust. Het is mij te toevallig allemaal (twee incidenten kort na elkaar - waarbij het tweede samenviel met een "ongelukje" bij RIPE op het moment dat de mederwerkers naar huis waren), en het gaat niet om een enkel adresblokje.

Als je paranoide genoeg bent is niks voldoende. Soit.

Ook ik kan bevestigen dat een hijack een configuratie fout kan zijn - (ja, meestal in combinatie met wat ontbrekende check/filters). 'BGP traffic optimizer appliances' bestaan die feitelijk bewust hijacken - met de bedoeling dat dit binnen het netwerk van de operator blijft' om verkeersstromen te sturen.
Wat dat betreft is het zeker 'normaal' dat dan juist grote CDNs impacted zijn.

De post mortem van RIPE leest duidelijk als een (design) fout, zonder enige indicatie van een hack.
('maar de Russen zagen dat aankomen en stonden klaar om er gebruik van te maken')
Heel veel van de betrokken prefixen waren niet van RIPE - en dus niet impacted door tijdelijk missende rPKI records
('maar de Russsen hebben veel gehijacked om niet te laten zien welke prefix hun doel was' )
Er is geen certificaat uitgifte opgedoken voor dit tijdsframe en prefixen
('zie je wel hoe subtiel de Russen zijn' )

Een betere analyse dan van Job Snijders (echt een van de beste mensen in deze business) ga je niet snel vinden.
https://www.ripe.net/ripe/mail/archives/routing-wg/2020-April/004083.html

Je had de URL al, maar het is de meest relevante.
Ook relevant is het feit dat rPKI validatie niet real time tegen een RIPE of andere DB gaat, maar tegen een interne provider snapshot die meer of minder vaak gerefreshed wordt.
(zie ook https://www.ripe.net/ripe/mail/archives/routing-wg/2020-April/004087.html) .

Dat geeft een hoop mitsen en maren hoe en wanneer je kunt profiteren als hijacker.
En uiteindelijk - rPKI is nog lang niet zo universeel als het idealiter zou zijn - je moet dit niet lezen als een plotseling gat in een perfect dichtgetimmerde setup.

Precies, dat is wat ik bedoel. Stel, je hebt 2 opstelpunten, onderling verbonden met een snelle verbinding.
Opstelpunt 1 heeft een snelle verbinding naar internet, opstelpunt 2 heeft een langzamere verbinding (beiden met BGP
peering naar andere providers). Nu is je internetverbinding bij opstelpunt 2 aan het vollopen, en wat analyse leert dat
er heel veel verkeer is van een paar netwerken (die CDN's).
Nu kan een slimme netwerkoperator op het idee komen om de klanten van opstelpunt 2 die naar die netwerken willen
niet direct op opstelpunt 2 naar buiten te routeren maar dit verkeer over de eigen link naar opstelpunt 1 te sturen en
daar het internet op.
Het duurt niet lang voor ie erachter komt dat dit niet werkt omdat het alleen het uitgaand verkeer beinvloedt en het
retour verkeer (wat de verbinding verstopte) gewoon langs hetzelfde pad blijft lopen. Dan gaat ie experimenteren en
rommelen en als ie niet uitkijkt komt ie op het punt dat een van de opstelpunten routes adverteert naar die CDN's
(je zou precies het omgekeerde moeten doen) en dan krijg je "een BGP hijack".
Helemaal niet kwaadwillend dus, alleen onhandig.

Dit betwijfel ik. Er zijn verschillende validatie methoden, en ik ga er even vanuit dat je het nu hebt over een http validatie. In dat geval zal er eerst een transactie tussen aanvrager en letsencrypt plaatsvinden via https. Na deze transactie heeft de aanvrager een token wat hij in z'n webserver moet plaatsen zodat dit ter validatie opgevraagd kan worden.
Die validatie zal (omdat het http is) geMITMt kunnen worden, en dan zijn er twee mogelijkheden:
1) De validatie slaagt alsnog (omdat de MITM partij het juiste token heeft kunnen doorgeven)
2) De validatie slaagt niet (het opvragen van het token is om wat voor reden dan ook mislukt)
Als de validatie slaagt is er niets aan de hand want het certificaat gaat alsnog naar de originele aanvrager, niet naar de MITM partij. De MITM partij is niets wijzer geworden. Als de validatie niet slaagt is er ook niets aan de hand, er wordt geen certificaat afgegeven en er zal later een nieuwe poging gedaan worden.
Zie ook: https://tools.ietf.org/html/rfc8555#section-8.3

Ik denk dat je het niet begrepen hebt. In dit scenario is "de aanvrager" en "de MITM partij" dezelfde partij, die wordt
dus weldegelijk wat wijzer van die aanvraag. Alleen zou Letsencrypt de moeite kunnen doen om nog via een ander
pad een melding te doen, bijvoorbeeld een mailtje "we hebben je certificaat verlengd" naar een mail adres wat in DNS
verkregen wordt, bijvoorbeeld uit een CAA record. Dat moet dan niet postmaster@domein zijn want wellicht werkt die
MITM ook wel voor dat soort mail (afhankelijk van hoe die gehost is), maar bijv jouwnaam@gmail.com waarbij je er
dan vanuit gaat dat die aanvaller niet ook gmail onder controle heeft.
Als de aanvaller DNS onder controle heeft kan ie dat mail adres veranderen maar dan kan ie een certificaat aanvragen
zonder die hele MITM kermis en valt het buiten dit onderwerp.

Aan voorlaatste reageerders: ik weet niet zeker of er sprake was van een BGP-hijack c.q. een onbedoelde configuratiefout. Maar als RosTelecom 2x zo'n blunder begaat, "toevallig" voor een enorm aantal domeinen, geloof ik niet meer in toeval. Zie ook opmerking D onderaan deze bijdrage.

Als ik https://letsencrypt.org/how-it-works/ goed begrijp, werkt het als volgt bij http validatie.

In het voorbeeld hieronder ga ik uit van een webserver "example.com" met IP-adres 2.2.2.2. Ook ga ik ervan uit dat de aanvraag steeds plaatsvindt vanaf dat IP-adres 2.2.2.2. Gebruikelijk is het immers om de certificaat-aanvragende client op de betreffende webserver zelf te draaien, zodat automatische vervanging van het certificaat (elke 3 maanden) mogelijk is (zie bijv. https://certbot.eff.org/docs/install.html#about-certbot).

Je moet een account aanmaken op basis van een zelf-gegenereerd asymmetrisch sleutelpaar (dit is niet het sleutelpaar waarvan de public key in het certificaat wordt opgenomen). Als ik het goed begrijp is dit nodig om de aanrvager aan de feitelijke webserver te koppelen in de situatie dat je de certificaat-aanvraag vanaf een ander systeem indient dan de webserver. Ik verneem het graag als bijv. deze aanname van mij onjuist of onvolledig is.

Stap 1: maak account-keypair en vraag certificaat aan
De aanvrager genereert een asymmetrisch sleutelpaar voor een account bij LE (Let's Encrypt) en vraagt een https servercertificaat aan voor "example.com" bij Let's Encrypt. Hierbij sla ik even over dat de aanvrager daarvoor een DNS lookup moet doen voor de juiste LE server, ik gaan ervan uit dat dit werkt zoals verwacht. Die aanvraag vindt dan plaats als volgt, met rechts van het midden de routering van IP netwerkpakketjes via Internet ("8390" en "ed89" heb ik overgenomen uit de voorbeelden in https://letsencrypt.org/how-it-works/; advies: kijk eerst daar):
In bovenstaand plaatje heeft AS4 (Autonomous System number) naar AS5 geadverteerd dat de kortste route naar de LE server via hem (AS4 dus) loopt. Op zijn beurt heeft AS3 dat aan AS4 geadverteerd, AS2 aan AS3 en AS1 aan AS2. Dit zorgt ervoor dat IP netwerkpakketjes vanaf de aanvrager de LE server bereiken.

Hoewel routes op Internet asymmetrisch kunnen zijn (en zelfs kunnen veranderen tijdens verbindingen) ga ik ervan uit dat de omgekeerde weg precies dezelfde is en blijft. AS2 heeft dus naar AS1 geadverteerd dat de kortste route naar 2.2.2.2 via hem loopt; op zijn beurt heeft AS3 dat aan AS2 geadverteerd, AS4 aan AS3 en AS5 aan AS4.

Nb. hoewel hierbij sprake is van een https verbinding, is de enige die zich betrouwbaar authenticeert de LE server. De aanvrager heeft welliswaar een asymmetrisch sleutelpaar, maar helemaal niemand bevestigt van wie dat sleutelpaar is, dat is dus geen absolute authenticatie (je kunt er, bij volgende transacties, wel mee aantonen dat het om hetzelfde account gaat).

Stap 2: LE vraagt IP-adres van example.com op
LE vraagt middels een DNS "A" lookup op wat het IP-adres is van example.com. Hierbij ga ik ervan uit dat 1.1.1.1 een authoritative DNS server is voor example.com. Ik ga ervan uit dat het DNS account niet gekaapt is en de route tussen LE en de DNS-server verloopt en niemand "onderweg" de DNS-vraag en/of -antwoord manipuleert:

Stap 3: LE maakt http verbinding met 2.2.2.2 en vraagt eerder verstrekt bewijs op
Nu heeft 2.2.2.2 bewezen dat:
1) example.com daadwerkelijk IP-adres 2.2.2.2 heeft, en
2) dat de aanvrager iets gesigneerd kan schrijven in http://example.com/8390/.

Stap 4: Genereer CSR, LE ondertekent dit en verstrekt het resulterende certificaat
De aanvrager genereert een nieuw asymmetrisch sleutelpaar en een CSR (Certificate Signing Request), feitelijk een certificaat dat nog niet is ondertekend door een Certificate Authority (zoals Let's Encrypt). Ik weet niet precies hoe dit proces verloopt, maar ik vermoed dat dit CSR tijdelijk ondertekend wordt met de private key van het account om nep-aanvragen te voorkomen. Hierna vult LE het CSR aan met zaken als verloopdatum, OCSP URL etc. en ondertekent het, waarmee het een geldig certificaat wordt voor example.com - en vrijelijk kan worden verspreid - o.a. naar de bedoelde webserver.

So far, so good.

Stap 5: BGP-hijack: aanvaller maakt eigen account-keypair en vraagt certificaat aan
Nu gaan we uit van de situatie dat er een BGP hijack plaatsvindt en IP-verkeer van AS2 niet meer wordt uitgewisseld met AS3, maar met AS11:
Hier heeft de FAKE aanvrager een nieuw account-sleutelpaar gegenereerd, waarmee hij een certificaataanvraag doet.

Stap 6: LE vraagt IP-adres van example.com op
Ik ga ervan uit dat hier niets is veranderd, zie het plaatje onder stap 2.

Stap 7: LE maakt http verbinding met 2.2.2.2 en vraagt eerder verstrekt bewijs op

Stap 8: Genereer CSR, LE ondertekent dit en verstrekt het resulterende certificaat
Nu heeft LE dus een certificaat voor een FAKE webserver gesigneerd.

Opmerkingen
A) In theorie zou LE kunnen weigeren om certificaten voor example.com te verstrekken aan iemand met een ander account (lees: ander sleutelpaar). Echter, zodra jouw legitieme account-private key gecompromitteerd raakt of kwijtraakt (na een HDD crash zonder back-up), zou je een probleem hebben. Uit https://letsencrypt.org/docs/revoking/#using-a-different-authorized-account maak ik op dat je te allen tijde kunt bewijzen dat jij een certificaat voor example.com mag aanvragen. En als jij dat mag, dan mag een aanvaller dat dus ook!

B) Het feit dat je net zo kansloos bent zodra een aanvaller schrijftoegang krijgt tot de DNS-records van example.com (en 2.2.2.2 wijzigt in het IP-adres van een server in zijn bezit), is aanvullend bewijs dat die aanvaller niet in het bezit hoeft te zijn van jouw account-private key (zie https://www.security.nl/posting/593796/Aanvallers+wijzigen+wereldwijd+dns-instellingen+domeinen).

C) De BGP-hijack zou ook betrekking kunnen hebben op de DNS-request (plaatje in stap 2). DNSSEC helpt dat voorkomen, maar is nog lang niet overal in gebruik. Mogelijk onder andere daarom doet LE sinds kort vanaf meerdere locaties op Internet deze DNS-requests (zie https://letsencrypt.org/2020/02/19/multi-perspective-validation.html). Een vergelijkbaar mechanisme bestaat er bij mijn weten niet voor stap 3 (om stap 7 te bemoeilijken).

D) Na het verkrijgen van het certificaat kan de hele wereld op de fake example.com uitkomen - totdat de routering is hersteld. Daarna hebben eventuele aanvallers nog steeds een geldig certificaat + private key voor example.com in hun bezit, dat ze als MitM in elk geval "lokaal" kunnen inzetten (maar wellicht ook gericht, buiten hun "jurisdictie"). Bijvoorbeeld voor het onderscheppen van verkeer tussen hun eigen klanten en de echte example.com - de droom van elke dictatoriale regering. "Toevallig" is RosTelecom een overheidsbedrijf...

Ik weet niet helemaal zeker of het allemaal klopt en voldoende volledig is (in elk geval is het lang ;-) wat ik schrijf. Als je denkt van niet, leer ik graag waarom en wat ik fout heb aan de hand van steekhoudende reacties (aan onderbuikgevoelens en niet onderbouwde aannames heeft niemand iets).

Erik, goed verhaal en als dit volledig waar is zou dat inderdaad betekenen dat iemand met een MITM een certificaat voor iemand anders zou kunnen aanvragen. Er is 1 punt waar ik over twijfel:
Ik vraag me af of dit kan. Volgens mij is het domein waarvoor ik een certificaat heb aangevraagd gekoppeld aan mijn account. Dit zou volgens mij betekenen dat:
1) Dit zou kunnen werken voor een domein waarvoor nog nooit een certificaat is aangevraagd
2) Dit niet meer werkt voor domeinen waarvoor een aanvraag is geweest
In dat geval zou het betekenen dat je je beveiliging kan verbeteren door een certificaat aan te vragen voor jouw domeinen, ongeacht of je daadwerkelijk iets met het certificaat gaat doen :-)
Of het daadwerkelijk zo werkt is ongetwijfeld terug te vinden in code van de server-side van LE (https://github.com/letsencrypt/boulder), ik heb zelf nu even geen tijd om de code in te duiken.