Een kwetsbaarheid met hoge ernst in de Electrum Bitcoin-portemonnee is verholpen in versie 4.8.3, nadat aanvallers een manier hadden gevonden om het replace-by-fee-mechanisme van Bitcoin te misbruiken om ondertekende transacties te stelen. Electrum-ontwikkelaar SomberNight maakte het probleem bekend in een beveiligingsadvies van 24 oktober, waarin werd gesteld dat sommige servers de aanval in het wild uitvoerden. Twee gebruikers meldden incidenten; één verloor geld.

De aanval heeft de handtekening van de eigenaar nodig

Een kwaadaardige server kan op zichzelf niets van iemands Bitcoin uitgeven. De vervalste transactie die het plaatst, bevat ongeldige handtekeningen, waardoor het netwerk deze zou afwijzen. Wat de aanvaller nodig heeft, is een geldige handtekening van de eigenaar van de portemonnee, en de valstrik is zo ontworpen om die te verkrijgen via een fee-verhoging.

Replace-by-fee (RBF) versnelt een lopende Bitcoin-betaling door deze te vervangen door een nieuwe versie met een hogere fee. Voor de gebruiker voelt dit als het aanpassen van een instelling. Voor het netwerk is het een geheel nieuwe transactie, en door deze te ondertekenen worden alle bestemmingen en bedragen erin geautoriseerd. Als de transactie die wordt "gebumpt" al is gewijzigd, keurt de nieuwe handtekening de gewijzigde versie goed.

Het aas is een betaling die vast lijkt te zitten. In het geval waarbij een gebruiker geld verloor, bouwde de server de vervalsing met een fee van nul, wat volgens ontwikkelaars bedoeld was om een fee-verhoging uit te lokken. Een transactie zonder fee blijft onbevestigd, en het verhogen van de fee is de standaardreactie.

Hoe een kwaadaardige server de val zette

Electrum is een light wallet: de software downloadt en verifieert niet zelf de hele blockchain. Volgens de documentatie verbindt de portemonnee zich doorgaans met ongeveer tien servers, maar is ze afhankelijk van één hoofdserver voor de transactiegeschiedenis en het uitzenden van transacties. De andere servers leveren vooral blockheaders en fee-schattingen. Het advies merkt op dat het vertrouwen in de hoofdserver voor onbevestigde transacties deel uitmaakt van het gedocumenteerde ontwerp Electrum. Wat nieuw is, is een praktische methode om dat vertrouwen in diefstal om te zetten. Die afweging is de context van de aanval: het uitbesteden van verificatie maakt een light wallet licht, maar het betekent ook dat de geschiedenis die een gebruiker ziet slechts zo betrouwbaar is als de hoofdserver die deze levert — en vóór 4.8.3 kon een uitgaand item met ongeldige handtekeningen in die geschiedenis verschijnen alsof het echt was.

Tot de ondertekeningsstap is er niets verloren. Een geldige digitale handtekening kan de verkeerde betaling autoriseren als de transactie die wordt aangeboden om te ondertekenen is gewijzigd — en precies dat levert de fee bump.

Wat de twee slachtoffers zagen

Het eerste rapport kwam op 11 oktober van gebruiker dannydeezy. De betaling werd verstuurd vanuit een 2-van-3 multisignature-portemonnee, beveiligd door twee Trezor-hardwareapparaten, waarbij 31 inputs in één output werden samengevoegd. De gebruiker controleerde de bestemming op beide Trezors en zond de transactie toen uit. Daarna toonde Electrums geschiedenis het volledige bedrag dat onbevestigd naar een onbekend adres ging, waarna het item veranderde in "Local." Er bereikte niets de mempool.

De vervalsing was zorgvuldig opgebouwd. Deze gebruikte dezelfde inputs en kopieerde de handtekeninggegevens van de echte transactie byte voor byte, zodat alle 62 handtekeningen overeenkwamen met de echte betaling en geen enkele met de vervalsing. Bijna alles werd gestuurd naar een adres eindigend op "GyQ3" — dezelfde vier tekens als de echte bestemming — en een klein bedrag ging terug naar een eigen adres van de portemonnee, in navolging van een normaal wisselgeld-output. De fee was vrijwel nul. Omdat de gebruiker niet opnieuw ondertekende, bleef de echte transactie geldig en onuitgezonden, en ging er geen geld verloren.

Ontwikkelaars identificeerden de fee-bump-route pas nadat een tweede gebruiker, Raju-K12, op 18 oktober meldde geld te hebben verloren na het verhogen van de fee op een vervalste transactie. Het bedrag werd niet bekendgemaakt.

• 11 okt: Eerste privérapport, zonder de fee-bump-kant
• 18 okt: Tweede rapport, na verlies door een fee bump
• 23 okt: Versie 4.8.3 getagd met de fix
• 24 okt: Binaire bestanden uitgebracht en advies gepubliceerd

Wat 4.8.3 oplost — en wat niet

De fix zorgt ervoor dat Electrum handtekeningen verifieert bij elke onbevestigde transactie die munten uitgeeft vanaf eigen adressen van de portemonnee, voordat deze aan de geschiedenis wordt toegevoegd. Een vervalste uitgaande betaling met ongeldige handtekeningen wordt nu afgewezen in plaats van weergegeven, wat deze aanvalsroute sluit.

De controle is bewust beperkt. Inkomende onbevestigde transacties worden nog steeds niet gevalideerd, en het advies legt uit waarom: Electrum heeft geen volledige consensus-engine, en het controleren van andermans inputs zou betekenen dat hun onbevestigde bovenliggende transacties moeten teruggevolgd tot aan reeds gemijnde transacties. Bevestigde transacties waren al geverifieerd via simplified payment verification, die ze controleert aan de hand van blockheaders.

Gebruikers die alleen verbinding maken met servers die ze vertrouwen, zoals hun eigen server, waren niet getroffen. Die uitzondering geldt niet voor de openbare server die een portemonnee toevallig als hoofdverbinding kiest.

Voordat u weer iets ondertekent

1. Update naar 4.8.3. Download de versie van de officiële website van Electrum en verifieer de handtekening van het bestand volgens de instructies aldaar.
2. Controleer het volledige adres. Vergelijk het met de oorspronkelijke factuur of het betalingsverzoek, niet met de portemonnee-geschiedenis — precies die geschiedenis beheerst de aanvaller.
3. Bevestig op het apparaatscherm. Controleer bedragen en fee bij elke nieuwe handtekening. Trezors RBF-gids en verzendgids vragen gebruikers beide om de bijgewerkte gegevens op het apparaat te verifiëren.
4. Vastgelopen of gewijzigd? Stop. Zoek de oorspronkelijke transactie-ID op via een onafhankelijke block explorer voordat u iets bumpte. In het eerste rapport had de echte betaling het netwerk nooit bereikt.

Wie nog niet kan updaten, vindt in het advies een alternatief: controleer bij het ondertekenen van elke transactie — fee bump of niet — of de uitvoeradressen en bedragen precies aan de verwachtingen voldoen. Versies ouder dan 4.8.3 voeren de nieuwe handtekeningcontrole niet uit, dus voor wie nog een oudere release gebruikt, is die handmatige verificatie de enige bescherming tegen deze route. De patch sluit deze specifieke route, maar Electrum blijft afhankelijk van de hoofdserver voor onbevestigde gegevens, dus het scherm waarop een betaling wordt goedgekeurd blijft de laatste controle.

Dit artikel is uitsluitend bedoeld ter informatie en vormt geen financieel of beleggingsadvies.

Bron: Coindoo