Beveiligingsoverwegingen gaan boven alle andere overwegingen in software in het algemeen en in blockchain in het bijzonder. Als de beveiliging faalt, doet niets anders er toe. Blockchain bewijst dat gedecentraliseerde, betrouwbare transacties werken, maar veel kwetsbaarheden in de beveiliging van blockchain blijven niettemin bestaan.
Beveiligingsexploitaties bestaan op het ontwerp- en architectonisch niveau, in de coderingsfase en in de operationele fase. En voor het geval je je afvroeg, ja, de blockchain kan worden gehackt.
Beveiligingsproblemen met blockchain – van hier tot in de eeuwigheid
Diamanten zijn voor altijd en slimme contracten blijven bestaan zolang de blockchain waarop ze worden ingezet, wordt gebruikt. Bijgevolg leven alle bugs en kwetsbaarheden in de blockchain-beveiliging ook zolang het contract dat doet.
Meestal biedt elke blockchain zijn eigen programmeertaal om slimme contracten te implementeren. Laten we dat van dichterbij bekijken.
Slimme contracttalen
Blockchain-omgevingen bevatten hun eigen talen voor het ontwikkelen van slimme contracten.
Het Ethereum-platform bevat bijvoorbeeld de taal Solidity om slimme contracten te schrijven. De makers hebben Solidity ontworpen als een complete Turing-taal.
Een volledige Turing-taal stelt de programmeur in wezen in staat om alles te implementeren waartoe het onderliggende systeem in staat is. Bijgevolg geeft dit programmeurs de mogelijkheid om lussen in de code te implementeren, wat mogelijk kwetsbaarheden in de beveiliging van blockchain kan veroorzaken.
Turing volledigheid
Turing complete talen bevatten van nature complexiteit, en complexiteit nodigt uit tot bugs en kwetsbaarheden.
Het Bitcoin-netwerk heeft ook een programmeertaal die het Script noemt. Het script is met opzet niet volledig Turing om de beveiliging te verbeteren.
Hoe minder opties een programmeur krijgt, hoe kleiner de kans dat blockchain-beveiligingslekken het systeem binnendringen.
Om het risico van het vrijgeven van foutieve code in het wild te minimaliseren, moeten programmeurs de veelvoorkomende valkuilen en antipatronen begrijpen die inherent zijn aan slimme contractprogrammering. (Antipatronen vertegenwoordigen slechte programmeerpraktijken).
De DAO-hack: het herintredingsprobleem
De DAO-hack
Het herintredingsprobleem scoort waarschijnlijk het hoogst bij blockchain-beveiligingskwetsbaarheden die programmeurs hebben gecodeerd in slimme contracten. Door herintreding wordt een account leeggemaakt door meerdere uitgaven voor dezelfde transactie. Het gebruik van het verwerken van restituties leent zich voor deze exploit, maar deze fout is van invloed op elke soort transactie als deze niet wordt aangepakt in de ontwerp- en coderingsfase.
In een van de meest beruchte cryptocurrency-aanvallen tot nu toe, maakten hackers van de DAO misbruik van herintreding. Geen enkele organisatorische leider dicteerde hoe de DAO (of gedecentraliseerde autonome organisatie) moest worden geleid, en de DAO stelde voor om gebruikers de mogelijkheid te geven om te stemmen over projecten waarin ze kunnen investeren.
Het haalde in de eerste maand meer dan $ 150 miljoen aan financiering op. Op 17 juni 2016 hebben hackers via de herintredingsfout $ 50 miljoen afgeschreven van de organisatie. De harde vork van Ethereum Classic (ETC) naar Ethereum (ETH) resulteerde in een poging om de problemen op te lossen die deze hack veroorzaakte.
Anti-Pattern Kwetsbaar voor herintreding
Een kwetsbare herintredende logica voor code ziet er als volgt uit:
functie om een betaling te verwerken () {
(1) controleer de geldigheid van de transactie, de ontvanger en het rekeningsaldo;
(2) de transactie verwerken;
(3) de status van het systeem bijwerken om te laten zien dat de transactie is verwerkt;
Op het eerste gezicht ziet de logica er correct en compleet uit, maar de fout zit in de volgorde van stap 2 vóór stap 3.
Terwijl de eerste aanroep van de functie doorgaat met het verwerken van stap 2, kan een andere aanroep voor dezelfde transactie de functie binnengaan. Aangezien de toestandinformatie in de oorspronkelijke toestand blijft en nog niet verwerkt is in stap 3, wordt de tweede oproep uitgecheckt als een geldige transactie om te verwerken.
Bijgevolg besteedt het systeem valuta voor dezelfde verplichting een tweede keer. Hackers haasten meerdere transacties naar de functie voordat de staat correct wordt ingesteld.
Genezen voor herintreding
Deze wijziging van het algoritme corrigeert het bovenstaande probleem:
functie om een betaling te verwerken () {
(1) controleer de geldigheid van de transactie, de ontvanger en het rekeningsaldo;
(2) de status van het systeem bijwerken om te laten zien dat de transactie is verwerkt;
(3) de transactie verwerken;
De code moet rekening houden met alle noodzakelijke afhandeling van uitzonderingen, en het moet ook rekening houden met alle logische afhankelijkheden.
Overloop
Overflow is een andere veelvoorkomende beveiligingsfout waar programmeurs zich bewust van moeten zijn.
Sommige programmeertalen bieden sterke typen en andere bieden zwakke typen. Sterk getypeerde talen weigeren programmeurs toe te staan stringgegevens toe te wijzen aan een numerieke variabele, en zwak getypeerde talen staan dergelijke acties toe.
Sterk getypeerde talen dwingen bereikbeperkingen af. Als een array uit tien elementen bestaat, kunnen programmeurs niet proberen toegang te krijgen tot het elfde element. Zwak getypeerde talen laten dergelijk gedrag toe, maar het resultaat is crashes. Als de maximaal toegestane waarde van een variabele 99 is, en je kent er een waarde van 100 aan toe, kijk dan hoe hij crasht wanneer je hem uitvoert!
Bijgevolg is overflow een exploit die hackers gebruiken. Als een hacker een parameter aan een smart contract invoert die buiten het bereik ligt dat de code kan verwerken, ontstaat er een crash. Zo’n crash voedt meerdere exploits. De crash kan een denial of service-aanval (DDoS-aanval) veroorzaken, en vitale informatie over de interne onderdelen van het systeem komt soms tot uiting in foutmeldingen.
In webapplicaties vullen hackers vaak het geheugen met hun eigen kwaadaardige code, dus wanneer het programma crasht en naar een willekeurige plek in het geheugen gaat, wordt de kwaadaardige code uitgevoerd.
Zwak getypeerde talen bieden kracht en dynamische flexibiliteit, maar ze vereisen ook meer rigoureus ontwerp en testen om te worden gehard tegen aanvallen.
De veelkoppige Hydra
Een groot aantal beveiligingsproblemen plaagt de softwarewereld. Naarmate nieuwe technologie opduikt, verschijnen er nieuwe bedreigingen. Naast de hierboven genoemde exploits, vertegenwoordigen deze opmerkelijke tekortkomingen slechts enkele van de vele andere kwetsbaarheden in de blockchain-beveiliging.
Slechte cryptografie zorgt voor veel hoofdpijn. Cryptografie zorgt voor privacy, en als de privacy breekt, breekt alles. Het IOTA-team maakte de fout om hun eigen cryptografische bibliotheek helemaal opnieuw te schrijven in de eerste versie van hun product. Het probleem dat inherent is aan het rollen van je eigen cryptografie is dat alle complexe software bugs bevat, dus je hebt gegarandeerd buggy-cryptografie.
Gevestigde cryptografische bibliotheken overleven doorlichting door academici en blijken na verloop van tijd betrouwbaar te zijn door het leven in het wild.
In de wereld van portefeuilles moet het genereren van willekeurige getallen echt willekeurig zijn. Vooral in de begintijd van cryptocurrency voldeden sommige wallets niet aan deze vereiste.
Adressen voor cryptovaluta vereisen adressen die uniek moeten zijn. Uniciteit komt van een generator voor willekeurige getallen en de generator voor willekeurige getallen heeft een zaadje nodig om het proces te starten. Als het zaad niet echt willekeurig is, mislukt het systeem.
Een gevolg van slechte willekeur betekent dat hetzelfde adres meerdere keren wordt gemaakt. Stel je het scenario voor waarin een portemonnee adres X toewijst aan persoon A en enige tijd later adres X aan persoon B. Wanneer een betaling naar adres X gaat, gaat het maar naar één persoon. Welke persoon krijgt het geld?
Een ander probleem met slechte willekeur ontstaat wanneer een hacker het algoritme ontdekt dat is gebruikt om het zaad te maken. De hacker regenereert het zaad voor zichzelf en is eigenaar van het systeem.
The Road Goes On Forever and the Party Never Ends
Beveiliging is een nooit eindigende strijd, en zelfs als programmeurs, architecten en testers alle kwetsbaarheden uit de code verwijderen, blijven operationele kwetsbaarheden bestaan.
In een Proof of Work-omgeving wordt de integriteit vernietigd als slechte actoren 51% van het netwerk beheersen. Speltheorie biedt mitigatie voor deze aanval. Een nieuwe cryptocurrency met een klein netwerk stelt het meeste risico aan deze aanval bloot. Maar een aanval van 51% vernietigt de waarde van de valuta, dus aanvallers doen zichzelf gewoon pijn.
Blockchains leven op internet en delen dezelfde blootstelling aan hackers als internet. Stel dat u munten koopt van een beurs op een website. Injectie-aanvallen, cross-site scripting, phishing-aanvallen en alle andere traditionele website-hacks hebben de overhand.
Laatste gedachten
Net zoals programmeurs zich wapenen tegen bugs, moeten programmeurs rekening houden met beveiliging in hun ontwikkeling. Er zijn enkele tools om programmeurs te helpen bij de taak, maar programmeurs moeten eerst hun eigen kwetsbaarheden begrijpen om zich ertegen te beschermen.
De Gedecentraliseerd applicatiebeveiligingsproject (DASP) streeft ernaar een opslagplaats te zijn van informatie en bronnen over blockchain-beveiliging. Ze modelleren zichzelf enigszins op de Open Web Application Security Project (OWASP). De jaarlijkse OWASP Top 10 somt zeker de belangrijkste kwetsbaarheden van webapplicaties op die momenteel bestaan. De DASP Top 10 hoopt de gelijkwaardige bron voor blockchain te bieden.
Niet alle aanvallen zijn van tevoren bekend. Een zero-day exploit definieert een exploit die hackers kennen voordat iemand anders dat weet. Programmeurs moeten dus als aanvallers denken bij het ontwerpen en implementeren van software. Als u de kwetsbaarheden in uw code niet vindt, kunt u verwachten dat een hacker die op zoek is naar winst, ze vindt.
