Een openbare beveiligingsproef met ruim $2.000 aan
Bitcoin hield nog geen dag stand. Deelnemer KillaBoi kreeg na 19,28 uur code uitgevoerd op de kwetsbare PHP-server en wist daar een privésleutel uit te lezen.
Alleen hoorde die sleutel niet bij het bitcoinadres waarop de prijzenpot stond. Daarmee eindigde Steal My Bitcoin met twee verschillende uitkomsten: de server was technisch gekraakt, maar de buitgemaakte sleutel gaf geen controle over het gepubliceerde prijsadres.
Challenge eindigt na 19,28 uur
De organisator bevestigt de overwinning op de
officiële website van Steal My Bitcoin.
De geregistreerde eindtijd is 25 oktober 2026 om 15.47 UTC. In Nederland was het toen 16.47 uur.
De challenge had op dat moment 0,02511679
BTC als prijzenpot.
De website waardeerde die hoeveelheid tijdens de overwinning op ongeveer $2.021.
Na afloop verscheen de melding dat er geen bitcoin meer op de challengeserver stond en dat KillaBoi als winnaar werd erkend.
Doel was juist om de server te breken
Steal My Bitcoin was geen gewone website die zonder toestemming werd aangevallen.
De server was bewust als beveiligingsuitdaging ingericht.
Deelnemers mochten proberen binnen te komen en de opgeslagen walletsleutel te bemachtigen.
De bitcoin vormde de beloning voor wie daarin slaagde.
Dat onderscheid is belangrijk. Het ging om toegestane beveiligingstests op een speciaal daarvoor beschikbaar gestelde server.
De uitkomst zegt daarom niets over een ongeautoriseerde aanval op het
Bitcoin-netwerk.
Server draaide kwetsbare PHP-versie
KillaBoi beschrijft zijn aanpak in een openbaar
technisch verslag op GitHub.
De server draaide PHP 8.4.26.
De onderzoeker gebruikte fouten uit de zogenoemde PHP2Shell-problematiek om eerst informatie uit het geheugen van het PHP-proces te verkrijgen.
Die informatie hielp hem bepalen waar relevante onderdelen van het proces in het geheugen stonden.
Daarna wist hij zijn eigen code binnen hetzelfde proces te laten uitvoeren.
Het resultaat was toegang tot een commando waarmee de challenge een privésleutel teruggaf.
Een geheugenfout werd uiteindelijk code-uitvoering
De aanval draaide om verkeerd achtergebleven toestand in het geheugen nadat PHP tegen zijn geheugenlimiet liep.
KillaBoi wist daar eerst geheugenadressen uit af te leiden.
Met die adressen kon hij vervolgens een tweede stap voorbereiden waarmee PHP uiteindelijk een systeemfunctie uitvoerde.
Dat leverde bewijs op dat hij daadwerkelijk code binnen het serverproces kon laten draaien.
Zijn nieuwe demonstratie controleert dat bijvoorbeeld met een unieke marker en informatie over het draaiende proces.
De oorspronkelijke live-run leverde daarnaast de walletsleutel terug die de challenge op de server had geplaatst.
Zelfde PHP-versie betekent niet automatisch zelfde aanval
Het verslag bevat daarbij een belangrijke beperking.
KillaBoi schrijft dat zijn techniek sterk afhangt van de precieze softwarebuild en serveropstelling.
Zelfs twee systemen die allebei PHP 8.4.26 tonen, kunnen intern anders zijn opgebouwd.
Geheugenadressen, binaries en het aantal actieve processen kunnen verschillen.
Een exploit die tegen één specifieke testomgeving werkt, is daardoor niet automatisch rechtstreeks toepasbaar op iedere website met dezelfde versienaam.
Dat maakt de challenge een bewijs voor deze serveropstelling, geen bewijs dat iedere PHP-site identiek kan worden overgenomen.
Bitcoin zelf werd niet gekraakt
De titel van de uitdaging kan makkelijk tot een verkeerde conclusie leiden.
KillaBoi brak niet de cryptografie van Bitcoin.
Hij raadde geen privésleutel door de
blockchain aan te vallen.
De zwakke plek zat in de webserver waarop een privésleutel was opgeslagen.
Dat is een totaal ander beveiligingsmodel.
Wanneer een server een geldige privésleutel kan lezen, kan iemand die de server volledig overneemt mogelijk dezelfde sleutel uitlezen.
De bescherming van de coins is dan slechts zo sterk als de omgeving waarin het geheim wordt bewaard.
Gevonden privésleutel hoorde bij verkeerde wallet
Daar kreeg de challenge onverwacht een administratieve fout bovenop.
De sleutel die KillaBoi via de server terugkreeg, was volgens zijn verslag technisch een geldige WIF.
WIF staat voor Wallet Import Format, een manier om een Bitcoin-privésleutel als tekst te coderen.
Maar een geldige WIF zegt alleen dat de sleutel correct is opgebouwd.
Hij zegt niet bij welk bitcoinadres die sleutel hoort.
KillaBoi controleerde dat afzonderlijk.
De gevonden sleutel leverde niet het adres op dat op de challengewebsite als prijzenpot stond.
Organisator erkende fout volgens onderzoeker
Volgens KillaBoi lag die mismatch aan de kant van de organisator.
Hij schrijft dat de fout per e-mail werd erkend.
Beveiligingsonderzoeker LiveOverflow meldde eveneens publiek dat de challenge technisch was opgelost, maar dat de verkeerde sleutel op de server stond.
De challengewebsite heeft KillaBoi desondanks als winnaar aangemerkt.
Daarmee werd kennelijk gekeken naar de technische opdracht: de server binnendringen en de geplaatste geheime sleutel bereiken.
Niet uitsluitend naar de vraag of die sleutel de gepubliceerde bitcoin direct kon uitgeven.
Serverovername en bitcoinuitgave zijn twee bewijzen
Die scheiding is belangrijk.
Bewijs één is dat iemand eigen code binnen het kwetsbare PHP-proces kon uitvoeren.
Bewijs twee zou zijn dat de verkregen privésleutel daadwerkelijk controle gaf over de
wallet met de prijzenpot.
Het eerste is volgens de challenge en het technische verslag gelukt.
Het tweede volgde niet uit de sleutel die tijdens de oorspronkelijke aanval werd teruggegeven.
Een technisch correcte privésleutel en de juiste privésleutel voor een specifiek adres zijn twee verschillende dingen.
Verslag benoemt zelf ontbrekende gegevens
KillaBoi probeert in zijn publicatie ook duidelijk te maken waar het bewijs ophoudt.
Tijdens de oorspronkelijke live-aanval werd niet de volledige uitgaande HTTP-request vastgelegd.
Ook ontbreken de complete antwoordheaders van die run.
De onderzoeker heeft de aanval later in een lokale testomgeving opnieuw opgebouwd en reproduceerbaar gemaakt.
Dat versterkt de technische verklaring.
Het verandert de reconstructie alleen niet in een volledige opname van ieder netwerkpakket dat tijdens de winnende poging werkelijk over de lijn ging.
Live-run leverde wel sterke aanwijzingen voor code-uitvoering
Wat van die live-poging wél werd vastgelegd, sluit volgens het verslag goed aan op de latere demonstratie.
De server meldde PHP 8.4.26.
De twee fasen voor het uitlezen van geheugeninformatie gaven de verwachte afwijkende cookies terug.
De laatste aanvraag leverde vervolgens een HTTP-respons met een geldige WIF.
KillaBoi noemt dat samen een sterke aanwijzing dat zijn commando werkelijk binnen het PHP-proces werd uitgevoerd.
De organisator kwam tot dezelfde praktische conclusie en erkende de overwinning.
Een privésleutel op een webserver blijft het echte risico
De challenge was bewust zo ingericht dat een servercompromis uiteindelijk bij een walletsleutel kon uitkomen.
In een echte productieomgeving zou dat juist een ontwerp zijn dat zoveel mogelijk moet worden vermeden.
Wie een privésleutel leesbaar opslaat in een proces dat vanaf internet bereikbaar is, koppelt het cryptorisico rechtstreeks aan de beveiliging van die server.
Wordt de machine overgenomen, dan kan ook het geheim blootstaan.
Hardwarematige opslag, gescheiden ondertekening en minimale toegang kunnen die koppeling verkleinen.
De blockchain hoeft daarvoor zelf geen fout te bevatten.
De proef bewijst vooral wat één lek kan doorgeven
Steal My Bitcoin begon als een eenvoudige vraag: kan iemand via het nieuwe PHP-lek bij de bitcoin komen?
Na 19,28 uur was het technische antwoord grotendeels duidelijk.
KillaBoi kreeg code uitgevoerd en bereikte het geheim dat de server hem moest geven.
Alleen zat achter dat geheim niet de wallet die de website had beloofd.
Daardoor eindigt de challenge bijna ironisch.
De PHP-beveiliging werd gebroken zoals bedoeld. De laatste stap naar de prijzenpot liep stuk op een verkeerde sleutel die de organisator zelf had geplaatst.