Kraken Security Labs, ons deskundige team van beveiligingsonderzoekers, geïdentificeerde kwetsbaarheden in de Safepal S1 hardware wallet. Hoewel we niet in staat waren om cryptocurrency uit de portemonnee te stelen, demonstreren we bepaalde zwakheden die toekomstige compromissen mogelijk maken.
Bij Kraken proberen we aanvallen te ontdekken voordat ze plaatsvinden. Na ontdekking hebben we de volledige details van deze kwetsbaarheden op 18 november 2020 aan het Safepal-team bekendgemaakt.
Het verbeteren van de beveiliging van technologieën waar we allemaal van genieten, is een belangrijk proces om de digitale activa-industrie te laten groeien en geloven dat bewustwording en educatie een essentieel onderdeel zijn van die missie.
Ineffectieve sabotagedetectie
Uit onze tests bleek dat de sabotagedetectie van Safepal op zijn best niet effectief was. Volgens de Safepal documentatie: “Binnen S1 is er ingebed met mechanismen voor zelfvernietiging en gegevensverwijdering. Zodra er een software of fysieke aanval is gedetecteerd door meerdere sensoren, zal de portemonnee een zelfverdedigingsmechanisme starten, het zelfvernietigingsmechanisme zal de privésleutel en alle portefeuillegegevens wissen, waardoor de hacker geen gevoelige gegevens krijgt, waardoor uw activa verkeerde handen. " We ontdekten dat het apparaat zou stoppen met opstarten als we het uit elkaar haalden, maar dat we het apparaat opnieuw konden inschakelen door een enkele pin opnieuw aan te sluiten en dat de inhoud van het apparaat niet werd gewist. Verdere tests en communicatie met Safepal hebben uitgewezen dat de portemonnee alleen gegevens zal wissen als (a) het apparaat is ingeschakeld en (b) wanneer de eerder genoemde enkele pin langer dan 10 seconden is losgekoppeld. Bij diefstal lijkt het onwaarschijnlijk dat een gemotiveerde aanvaller dit alarm zou laten afgaan.
Schendingen van open source-licenties
De portemonnee bevat de GPLv2-licentie U-Boot en Linux Kernel. Het gebruik van deze GPL-gelicentieerde componenten vereist dat Safepal de broncode voor hun product distribueert, zodat gebruikers de code die op het apparaat van de gebruiker wordt uitgevoerd, kunnen inspecteren en wijzigen. We hebben de broncode opgevraagd bij Safepal, maar ze weigerden deze te verstrekken, wat betekent dat Safepal de GPL-licenties schendt. Overtredingen zoals deze hebben geleid tot rechtszaken en we hebben Safepal aangespoord om hun broncode bekend te maken. Safepal heeft firmware V1.0.24 uitgebracht op https://www.safepal.io/upgrade om dit probleem op te lossen.
Aanval downgraden
We gebruikten een flash-programmeur om een eerdere firmware terug te flashen, die niet door het apparaat werd gedetecteerd. Voorkomen dat een aanvaller de firmware downgradet naar een eerdere versie, is essentieel om de beveiliging te waarborgen, omdat het downgraden naar bijvoorbeeld een kwetsbare versie van een firmware voorkomt.
Verder onderzoek
Bovendien hebben we vastgesteld dat de sterk gemodificeerde versie van U-Boot, die doorgaans alleen beveiligd opstarten ondersteunt via "FIT-images" of het eigen veilige opstartproces van de SoC, versleuteld en verduisterd was. We presenteren enkele bevindingen met betrekking tot U-Boot, maar we hebben onze beoordeling in de tijd beperkt vanwege de obfuscatie. Onze ervaring is dat de applicatieprocessors die communiceren met het beveiligde element consequent het zwakke punt zijn in hardwareportefeuilles voor cryptocurrency, en de SafePal S1 is niet anders. Het lijkt erop dat Safepal belangrijke versluieringstechnieken in hun product heeft ontwikkeld of hergebruikt, wat effectief was in het vertragen van ons onderzoek, maar het is niet duidelijk, vanwege deze verduistering en het gebrek aan transparantie van hun GPL-broncode, of de SafePal S1 heeft echt een gevalideerde veilige opstartketen of niet.
We stellen het op prijs dat Safepal op deze zorgen reageert. We raden u aan om hun reactie te bekijken op https://blog.safepal.io/our-response-to-the-security-findings-from-kraken-security-labs.
De SafePal S1 is een cryptocurrency hardware wallet die embedded Linux draait met een systeem op een chip (SoC). Als gevolg hiervan verschilt de architectuur van deze portemonnee van de op microcontrollers gebaseerde die het populairst zijn (bijv. Trezor- en Ledger-wallets). De uitdaging bij het beveiligen van een ingebed op Linux gebaseerd systeem is hoe het opstartproces te beveiligen, aangezien de meeste, maar niet alle, voor Linux geschikte microprocessors externe flash-opslag en externe RAM nodig hebben. Bovendien, hoewel Linux misschien wel een van de meest gebruikte besturingssystemen is, wordt het niet in een veilige staat geleverd, waardoor Safepal een oplossing moet kopen of zelf verharding moet toevoegen.
Hardwareanalyse op hoog niveau
De hardware van de SafePal verschilt aanzienlijk van andere gangbare wallets zoals de Ledger Nano S / X of de Trezor One / T: beide zijn gebaseerd op microcontrollers, maar de SafePal is gebaseerd op een volledige System-on-a-Chip met Linux . We hebben de hardwarerevisie S1P_Ver03 getest.
De hoofdprocessor van het apparaat is gemarkeerd als "SafePal S1", maar de onderliggende processor is hoogstwaarschijnlijk een Allwinner-processor. Dit werd bepaald door de pin-out van de Safepal S1 (in pin-out) te matchen met de Allwinner i3-processor ( https://dn.odroid.com/obsolete/Allwinner_i3_Datasheet_V1.0.pdf Het meest opvallende is dat deze processor geen geïntegreerde flitser heeft, in plaats daarvan start het apparaat op met een externe flashchip, een Zbit Semiconductor ZB25VQ64. Bovendien bevindt zich een tweede SOIC-8-chip op het bord, waarvan wordt aangenomen dat deze het beveiligde element is. Helaas konden we de verkoper niet achterhalen op de chipmarkering.
Bevinding 1: Omzeiling van sabotagedetectie
Volgens de Safepal documentatie: “Binnen S1 is er ingebed met zelfvernietigings- en gegevensverwijderende mechanismen. Zodra er een software of fysieke aanval is gedetecteerd door meerdere sensoren, zal de portemonnee een zelfverdedigingsmechanisme starten, het zelfvernietigingsmechanisme zal de privésleutel en alle portefeuillegegevens wissen, waardoor de hacker geen gevoelige gegevens krijgt, waardoor uw activa verkeerde handen. "
Het sabotagedetectiesysteem werd in meerdere stappen geanalyseerd:
-
Case openen
Eerst werd getest of het openen van de SafePal-portemonnee, zowel met behulp van destructieve als niet-destructieve methoden, een sabotage zou veroorzaken. Het openen van de behuizing van de S1 veroorzaakte geen sabotagegebeurtenis of stopte de werking van de S1.
-
Verwijdering van RF-afscherming
De SafePal-processor, flitser, secure element en PMIC worden afgeschermd door een RF-can. Het RF-blikje wordt op zijn plaats gehouden met behulp van meerdere clips rond het blik, en niet volledig vastgesoldeerd. Dit maakt niet-destructieve verwijdering zeer eenvoudig met een kleine platte schroevendraaier. Het verwijderen van de RF kan ertoe leiden dat het apparaat niet meer succesvol opstart. Door metingen uit te voeren, werd vastgesteld dat de RF-canclip rechtsboven niet met aarde was verbonden zoals de andere clips. Door de clip opnieuw met aarde te verbinden, met behulp van een stuk draad van 4 mm om de clip te verbinden met een blootliggende grondplaat ernaast, kon de sabotage-gebeurtenis worden onderdrukt en werkte de SafePal-portemonnee weer. Met name vond er geen reset van het apparaat plaats en bleven de oude inloggegevens (pincode enz.) Geldig.
Er konden geen andere maatregelen voor sabotagedetectie worden gevonden.
oppotten
Zowel de flash-chip als het secure element zijn gepot met een onbekende compound. Door het echter met een warmtepistool te verwarmen, werd de oppotmassa broos. De verbinding kan vervolgens worden weggeschraapt met een kleine platte schroevendraaier, zonder enig onderdeel van het apparaat te breken. Dit geeft directe toegang tot de SPI-pinnen voor verder onderzoek.
Flash dumpen
Nadat het type flash-chip was vastgesteld door de markering te lezen, werd een poging gedaan om de flash-in-systeem te dumpen met behulp van flashrom. Omdat de chip op het moment van schrijven niet door flashrom werd ondersteund, moest ondersteuning op maat in flashrom worden geïmplementeerd. Hierdoor kon een volledige flashdump worden verzameld.
Tijdens verdere analyse werd vastgesteld dat de eerste 0x8000 bytes van de flitser zijn ingesteld op alleen-lezen met behulp van de OTP-beveiligingsfuncties van de flashchip, terwijl de rest van de flashchip zowel leesbaar als beschrijfbaar is.
Flash-inhoudsanalyse
Beginnend bij de 5e byte van het flashgeheugen, kon de tekenreeks "eGON.BT0" worden gevonden. Verder onderzoek heeft uitgewezen dat dit een veel voorkomende header is voor een beginnende bootloader op Allwinner-apparaten: https://linux-sunxi.org/EGON
Bevinding 2: GPL-overtredingen
Beginnend bij adres 0x40000 werd een Android-opstartimage, inclusief een Linux-kernel, gevonden, wat aangeeft dat het apparaat Linux draait. Aangezien er geen GPL-melding is gedaan of gevonden, duidt dit op een GPL-schending. Verdere verzoeken rechtstreeks aan SafePal leverden geen resultaten op.
Op adres 0x2A0000 werd een SquashFS-bestandssysteem gevonden, en het uitpakken ervan onthulde een volledig Linux rootbestandssysteem, inclusief opnieuw meerdere GPL-gelicentieerde tools.
Op adres 0x740000 werd een JFFS2-bestandssysteem geïdentificeerd met configuratiegegevens inclusief transactieadressen binnen een sqlite3-database.
Bovendien zijn een JPEG-opstartlogo en de JPEG-afbeelding van het afsluitlogo gevonden.
Pogingen tot Flash-wijziging
Er zijn meerdere pogingen gedaan om de inhoud van de flash-chip te wijzigen:
- Er werd vastgesteld dat de Linux-kernel, het SquashFS-bestandssysteem en het opstartlogo aanpasbaar waren. Een wijziging leidde er echter toe dat het apparaat weigerde op te starten.
- De inhoud van het JFFS2-bestandssysteem en het uitschakellogo konden worden gewijzigd zonder dat het apparaat niet meer opstartbaar was, maar wijzigingen aan het uitschakellogo werden niet weerspiegeld bij het daadwerkelijke afsluiten.
- Aanpassing van de eerste trap-bootloader was niet mogelijk vanwege de eerder genoemde beveiligingsbits die in de flash-chip waren ingesteld.
Flash-herwerking
Het is waarschijnlijk mogelijk om code-uitvoering op het apparaat te krijgen door de hoofdflashchip te vervangen. Omdat de inhoud identiek blijft, is dit niet detecteerbaar door het apparaat. Om code-uitvoering te krijgen, moeten meerdere controles reverse-engineered en verduidelijkt worden. Hoewel mogelijk, is dit vooral tijdrovend, vooral gezien de complexiteit van de U-Boot-obfuscatieketen, en daarom is het niet gedaan als onderdeel van deze audit.
Firmware upgrade
Het firmware-upgradeproces in het binaire bestand wallet_update is geanalyseerd en reverse-engineered. Firmware-upgrades kunnen worden gedownload van de SafePal-website na het invoeren van een serienummer, maar er werd vastgesteld dat de firmware-update identiek is voor identieke hardwarerevisies, zodat er geen personalisatie van de upgrade plaatsvindt. Alle apparaten zijn ontvangen met firmwareversie v.1.0.17, die op dat moment de laatste was. De firmware-upgrade is te vinden op https://www.safepal.io/fw/S1F/v1.0.17/upgrade.bin
Er werd ook vastgesteld dat de firmware-upgrade gecodeerd is en dat wijzigingen aan de binaire firmware ervoor zorgen dat het upgradeproces mislukt.
Tijdens de analyse van het wallet_update-binaire bestand werd ontdekt dat het binaire bestand is verduisterd met behulp van veel XOR-ed-gegevens. Door wallet_update binair te patchen was het mogelijk om het in qemu-user-mode uit te voeren, waardoor de firmware-upgrade op een regulier systeem kon worden gedecodeerd.
Er werd ook vastgesteld dat de firmware-upgrade, na een succesvolle decodering, een zogenaamd ECDSA-handtekeningcontrole op de firmware uitvoert. De implementatie lijkt erg op trezor-crypto, maar er kon geen bevestiging (vereist door de licentie van trezor-crypto) worden gevonden, dus dit kon niet volledig worden gevalideerd.
Oplossing 3: downgrade-aanval
Voorkomen dat een aanvaller de firmware downgradet naar een eerdere versie, is essentieel om de beveiliging te waarborgen, omdat het downgraden naar bijvoorbeeld een kwetsbare versie van een firmware voorkomt.
Tijdens deze audit is v1.0.18 van de SafePal Firmware uitgebracht. Een portemonnee is geüpgraded naar die firmware, opgestart en getest. Nadat werd gecontroleerd of de firmware-upgrade succesvol was, werd een flash-programmeur gebruikt om de vorige v1.0.17-firmware terug te flashen. Door deze downgrade bleef het apparaat volledig functioneel, de downgrade werd niet gedetecteerd door de firmware en de portemonnee bleef regelmatig werken, wat duidt op kwetsbaarheid voor downgrade-aanvallen.
Opstartproces
Eerste fase bootloader
De meeste Allwinner-apparaten gebruiken U-Boot als bootloader in de tweede fase, maar U-Boot is niet gevonden op het flash-systeem. In plaats daarvan werden verwijzingen naar "XBOOT" en "XTAB" gevonden in de flash, hoewel dit niet overeenkwam met een bekende bootloader, zoals https://github.com/xboot/xboot.
Aangezien het apparaat Linux draait en dat de opstartconfiguratie ergens moet plaatsvinden, werd de eerste fase bootloader reverse-engineered met Ghidra. Het bleek dat deze eerste fase bootloader veel verduistering gebruikt om strings en sleutelmateriaal te verdoezelen, en uiteindelijk werd ontdekt dat de eerste fase bootloader een tweede fase bootloader decodeert. Om de decodering en validatie van deze tweede fase bootloader te begrijpen, werd de volledige bootloader geëmuleerd met behulp van de Unicorn Engine-emulator, waardoor volledige decodering van de tweede fase bootloader mogelijk was. De eerste fase bootloader bleek ook een ECDSA handtekening van de tweede fase bootloader te valideren.
Bootloader van de tweede staat
Een snelle analyse van de bootloader van de tweede fase onthulde onmiddellijk dat het een aangepaste U-Boot-bootloader is. Aangezien U-Boot een licentie heeft onder de GNU Public License en er geen GPL-melding of broncode kon worden gevonden, vormt dit een GPL-schending.
Er werd vastgesteld dat U-Boot was aangepast met bepaalde versluieringen en decoderingsmethoden.
Applicatie-analyse
Twee binaire bestanden, 'portemonnee' en 'wallet_update' werden hersteld van het uitgepakte squashfs-bestandssysteem. portemonnee is de belangrijkste portemonnee-applicatie, terwijl portemonnee_update implementeert het firmware-upgradeproces.
Een time-of-check to time-of-use (TOCTTOU) probleem is gevonden in de firmware upgrade check van de wallet binary. De wallet_update-functionaliteit voert echter een tweede controle uit die niet kon worden omzeild. Er wordt ook een derde controle uitgevoerd op elke opstartprocedure, die zelfs mislukt als de softwarevergrendelingen worden omzeild.
Configuratie en database-analyse
Op het JFFS2-bestandssysteem bevinden zich twee configuratiebestanden: wallet.cfg en wallet.db.
Wallet.cfg bevat configuratie-items zoals of de portefeuille al is ingesteld en de naam van de portefeuille. Het bleek dat deze configuratie vrijelijk kan worden gewijzigd, waardoor een aanvaller configuratie-items zoals de portefeuillenaam vrij kan wijzigen.
De wallet.db is een op sqlite3 gebaseerde database die informatie bevat over de transacties, geconfigureerde munten en adressen in de portemonnee. Het aanpassen van de database leidt ertoe dat de wallet-applicatie niet werkt (de SafePal zal alleen een zwart scherm tonen). Het is onduidelijk of dit komt door een SQLite-incompatibiliteit (de versie die op de portemonnee wordt gebruikt is 3.7.11 uit 2012) of vanwege een aanvullende onbekende bescherming.
Database-analyse
Omdat de database privé-informatie bevat (adressen en transacties), is er geprobeerd om adressen van het apparaat te herstellen. Door het binaire bestand van de portemonnee te analyseren, werd ontdekt dat de adressen die in de database zijn opgeslagen, zijn gecodeerd met AES, waarbij de sleutel is afgeleid van verschillende statische bronnen en van wat wordt verondersteld dat het invoer van beveiligde elementen is.
Bepaalde wijzigingen leiden er ook toe dat het apparaat de gebruiker vraagt om de portefeuille opnieuw in te stellen, maar het apparaat opnieuw flitst met een niet-gemodificeerde flash-afbeelding hersteld volledige werking van de portefeuille. Dit kan duiden op inefficiënte methoden voor sabotagedetectie en respons.
