XRPL dicht fout die in één transactie extra XRP kon maken
Een rekenfout in de XRP Ledger kon besteedbare XRP uit het niets creëren. Niet via gestolen private keys of een gehackte wallet, maar via één speciaal opgebouwde betaling langs honderden handelsaanbiedingen.
De fout is al op 25 september gerepareerd in xrpld 3.4.1. Pas op 9 oktober maakten XRPL-ontwikkelaars de technische details openbaar. Volgens het rapport is geen bewijs gevonden dat de kwetsbaarheid op een publiek netwerk is misbruikt.
Eén verkeerde optelling was genoeg
De fout zat diep in de betalingsengine van de XRP Ledger.
Een betaling kan via een orderboek meerdere aanbiedingen tegelijk verwerken. De software telt dan op hoeveel XRP de betalende partij uiteindelijk verschuldigd is.
Daar ging het mis.
Bij honderden speciaal opgebouwde aanbiedingen kon die optelling groter worden dan een 64-bits teller aankon. Het getal sloeg vervolgens om en begon opnieuw bij een veel lagere waarde.
De verkopers kregen wel ieder hun volledige XRP-bedrag bijgeschreven. De betalende account werd alleen belast voor het veel kleinere, omgeslagen totaal.
Het verschil bestond daarvoor niet.
Of simpeler: de boekhouding schreef aan de ene kant meer XRP bij dan zij aan de andere kant weghaalde.
Extra XRP was daarna gewoon besteedbaar
Dat maakt deze fout zwaarder dan alleen een verkeerd weergegeven saldo.
De onderzoekers reproduceerden de kwetsbaarheid op een lokale server. De nieuw ontstane XRP kon daarna in een volgende transactie worden uitgegeven.
Volgens de disclosure had een aanvaller in theorie zelfs XRP kunnen creëren ver boven de bedoelde totale voorraad.
Daar stond opvallend weinig startgeld tegenover. De aanval vergde vooral honderden accounts en handelsaanbiedingen. De benodigde reserves en transactiekosten lagen volgens XRPL slechts rond enkele honderden XRP.
Het was wel een aanval die bewust moest worden geconstrueerd.
Normale betalingen of handelsorders konden de bug niet zomaar raken. De bedragen en prijzen moesten specifiek worden opgebouwd om de teller te laten omslaan.
Ook de veiligheidscontrole maakte dezelfde fout
Hier wordt het pijnlijk.
De XRP Ledger had al een controle die juist moest voorkomen dat een transactie nieuwe XRP creëerde. Alleen gebruikte die controle dezelfde soort berekening.
Daardoor kon ook de beveiligingsoverzichtelling omslaan.
De hoofdrekening gaf dus een verkeerd resultaat. De controle rekende vervolgens op vrijwel dezelfde manier en concludeerde dat alles klopte.
Dat is precies waarom onafhankelijke controles belangrijk zijn. Een tweede check helpt weinig wanneer hij dezelfde fout opnieuw uitvoert.
Bug zat mogelijk al sinds 2015 in de code
Volgens het officiële rapport zat het probleem waarschijnlijk al in de betalingsengine sinds die in 2015 werd geschreven.
Dat betekent niet dat er sinds 2015 extra XRP rondloopt.
XRPL zegt geen bewijs te hebben gevonden dat de fout op Mainnet of een ander publiek netwerk daadwerkelijk is uitgebuit. Het rapport maakt dus een harde scheiding tussen wat technisch mogelijk was en wat aantoonbaar is gebeurd.
De vondst kwam via het bug-bountyprogramma. RippleX reproduceerde de aanval op 22 september en verhoogde de beoordeling daarna naar kritiek.
Patch ging bewust snel naar validators
De ontwikkelaars kozen voor een ongebruikelijk snelle route.
De oplossing werd rechtstreeks in xrpld 3.4.1 opgenomen in plaats van eerst via het normale amendmentproces te lopen. Dat gebeurde omdat het risico van openbaar bekende exploitcode volgens de betrokken partijen zwaarder woog dan het risico van een snelle softwarewissel.
De noodrelease verscheen op 25 september. Serverbeheerders kregen toen het dringende advies direct te upgraden.
De volledige broncode van de reparatie werd aanvankelijk bewust niet gepubliceerd. Eerst moest genoeg van het netwerk beschermd zijn.
Volgens XRPL draaide op de releasedag meer dan 80% van de validators op de standaardlijst al op versie 3.4.1 of nieuwer.
Pas bij de disclosure van 9 oktober kwamen de technische details en de code volledig naar buiten.
Dit was geen wallet-hack
Voor XRP-houders is dat onderscheid belangrijk.
De kwetsbaarheid gaf een aanvaller geen toegang tot private keys. Er werden geen wallets opengebroken en het rapport beschrijft geen manier om rechtstreeks XRP uit een bestaand account te stelen.
Het probleem zat in de regels waarmee servers transacties op de blockchain verwerkten.
Een kwaadwillende partij had daarmee nieuwe XRP kunnen laten ontstaan en die daarna naar gewone accounts of exchanges kunnen sturen.
Dat is een heel ander risico. Geen diefstal uit een bestaande pot, maar een fout in de teller zelf.
Openbaarmaking is het nieuws, niet een nieuwe aanval
De datum van 9 oktober kan daardoor makkelijk verkeerd worden gelezen.
De kwetsbaarheid werd die dag niet ontdekt. Er vond ook geen bevestigde aanval plaats.
De onderzoeker meldde de fout op 22 september. XRPL bevestigde hem dezelfde dag. Drie dagen later stond de oplossing al in versie 3.4.1.
Op 9 oktober kregen buitenstaanders voor het eerst het volledige verhaal te zien.
De dreiging zat dus weken geleden in de code. Het nieuws van vandaag is dat we nu weten hoe dicht een rekenfout bij de geldkraan van XRP kon komen.
Stop met te veel betalen voor je crypto. Bij de Amsterdamse exchange Finst handel je tegen de laagste tarieven van Nederland, zonder verborgen kosten.
👀 Bekijk Finst nu ›Let op: Beleggen in crypto brengt risico’s met zich mee. Handel alleen met geld dat u kunt missen.
Ga verder met lezen
Dit vind je misschien ook leuk
Laat mensen jouw mening weten
Lees ook
Populair Nieuws
Loading
