Einleitung
Der Blockchain-Sektor hat sich ganz darauf konzentriert, Schwachstellen im Code von Smart Contracts zu finden. Die Entwicklungsteams investieren in Audits, Bug-Bounty-Wettbewerbe, Fuzzing-Tools und formale Verifizierungstechniken, weil sie glauben, dass die Sicherheit gewährleistet ist, wenn alle Fehler im endgültigen Code gefunden werden.
Diese Methode ist wichtig, berücksichtigt aber nicht eine der erschreckendsten Tatsachen, die 2024 ans Licht gekommen sind. Der katastrophalste Angriffsweg, der derzeit Kryptowährungsprotokolle heimsucht, sind nicht komplexe Exploit-Ketten oder versteckte Code-Schwachstellen. Vielmehr handelt es sich um eine wesentlich tiefgreifendere und noch weniger diskutierte Bedrohung, die die Bedrohungslandschaft in den letzten Jahren dominiert hat.
Die Gefährdung durch private Schlüssel bestimmt die Bedrohungslandschaft
Eine Studie aus dem Jahr 2024 liefert alarmierende Zahlen, die eine Neudefinition unseres Ansatzes zur Blockchain-Sicherheit erforderlich machen. Der Anteil aller im Laufe des Jahres gestohlenen Kryptowährungsgelder, die über einen privaten Schlüssel kompromittiert wurden, beträgt 43,8 % und ist damit bei weitem die erfolgreichste Art von Angriff.
Schwachstellen in der architektonischen Zugriffskontrolle werden von den traditionellen Blockchain-Prüfungsgesellschaften normalerweise nicht als formelle Feststellungen gemeldet, und konkurrierende Prüfungsplattformen halten Leute davon ab, solche systemischen Probleme einzureichen.
Diese fokussierte Denkweise steht im krassen Gegensatz zu den Best Practices von Sicherheitsaudits in anderen Branchen, wo Privilegieneskalation und die Gestaltung der Zugriffskontrolle zentrale Themen sind, die schon früh im Entwicklungszyklus berücksichtigt werden müssen, zu einem Zeitpunkt, an dem es oft schon zu spät ist, die Gesamtnatur der Zugriffskontrollprobleme des Systems zu ändern.
Um die Auswirkungen von Designentscheidungen auf die Anfälligkeit für Angriffe auf private Schlüssel zu verstehen, schau dir mal dieses theoretische Protokoll für überbesicherte Kredite an. Allerdings braucht man privilegierten Zugriff auf solche Systeme, um ein paar wichtige Vorgänge durchzuführen:
- Auflistung und Streichung von unterstützten Assets
- Risikoparameter und Zinssätze einstellen
- Protokollgebührenerhebung
- Notfallpausen und Smart-Contract-Entwicklung-Upgrades
Diese definieren die allgemeine Widerstandsfähigkeit eines solchen Protokolls gegenüber der Kompromittierung privater Schlüssel.
Stufe 1: Vollständige Offenlegung mit Einzelpunktkontrolle
Die niedrigste Stufe ist die, bei der der Entwickler ein einziges, von außen kontrolliertes Konto mit vollen Administratorrechten für alle Protokollfunktionen hat. Diese Architektur ist die anfälligste Konfiguration, bei der die Kompromittierung eines privaten Schlüssels Angreifern sofortigen und vollständigen Zugriff auf das System verschafft, das möglicherweise in Form von Software-Wallets existiert, die fest mit dem Internet verbunden sind.
Die Gefahr des Verrats ist riesig und die Auswirkungen sind echt schlimm und direkt.
Stufe 2: Einfaches Risikomanagement durch verteilte Schlüssel
Der nächste Schritt ist, die Verwaltungsrechte in die Multi-Signatur-Wallet zu übertragen, die die Zustimmung mehrerer Schlüsselinhaber braucht, um das Upgrade durchzuführen. Das kann zwar nur die Gefahr einer Kompromittierung verringern und nicht das Ausmaß der möglichen Schäden am Protokoll begrenzen, ist aber dennoch eine Verbesserung.
Das ist in puncto Sicherheit viel besser als eine Einzelschlüsselkontrolle, da für eine Protokollübernahme nicht mehr der Zugriff auf einen einzigen Signaturschlüssel erforderlich ist. Trotzdem gibt es trotz dieser Verbesserung immer noch hohe Risiken:
- Schnelligkeit ist super wichtig, weil böswillige Aktionen starten könnten, bevor die Sicherheitsmaßnahmen greifen.
- Auch wenn Fehlerquellen auf verschiedene Schlüssel verteilt sind, bleibt die Kontrollstruktur zentralisiert
- Selbst gut gesicherte Multi-Signatur-Systeme können durch fortgeschrittene Social-Engineering-Techniken geknackt werden.
Stufe 3: Besserer Schutz durch Zeit- und Rollentrennung
Die dramatischen Verbesserungen in Sachen Reife erfordern die Durchsetzung von zwei wichtigen Kontrollmechanismen: Zeitsperren und das Prinzip der geringsten Privilegien.
Timelocks sorgen für eine Verzögerung zwischen der Genehmigung und der Ausführung einer Transaktion, was Zeit gibt, die Transaktion zu überprüfen und auf Zwischenfälle zu reagieren. Das Prinzip der geringsten Privilegien besteht darin, Rollen und Verantwortlichkeiten zu trennen, sodass jede Rolle nur die geringsten Berechtigungen erhält, die zur Erfüllung einer bestimmten Rolle erforderlich sind.
Diese Stufe befasst sich mit grundlegenden Mängeln einfacherer Methoden:
- Sofortige Ausführung ist nicht erlaubt.
- Teilen der Kontrolle zwischen mehreren Spezialisierungen
- Schafft Zeit für Sicherheitsteams, um unerwartete Transaktionen zu überprüfen
- Ermöglicht proaktives Handeln statt nur Schadensbegrenzung
Stufe 4: Höchste Sicherheitsstufe
Die höchste Reifegradstufe basiert auf der vollständigen Abschaffung administrativer Maßnahmen und ist die radikalste Form des Bekenntnisses zur Idee der Dezentralisierung und Minimierung von Vertrauen. Eine solche Strategie schließt die Zugriffskontrolle als Teil des Bedrohungsmodells des Protokolls kategorisch aus.
Um dieses Niveau zu erreichen, sind ganz andere Ansätze als bei allen anderen Niveaus nötig:
- Die Aktualisierbarkeit von Verträgen muss abgeschafft werden – Smart Contracts werden komplett unveränderlich
- Die Auflistung von Vermögenswerten wird genehmigungsfrei – eigenständige Märkte werden unabhängig voneinander eingesetzt
- Risikoparameter sind fest verankert – keine administrative Verwaltung möglich
- Notfallmaßnahmen sind nicht möglich - Systeme können nach der Implementierung nicht mehr angepasst werden.
Bei überbesicherten Kreditsystemen müssen ein paar wichtige Punkte beachtet werden:
- Neue Funktionen werden in komplett anderen Bereitstellungen mit manueller Benutzermigration eingesetzt.
- Märkte, die als eigenständige Protokollinstanzen für bestimmte Vermögenswerte gebildet werden
- Risikoparameter folgen algorithmischen Richtlinien oder festen Bereitstellungseinstellungen
Diese Zahl ist fünfmal höher als bei allen anderen bekannten Angriffsarten, aber das Blockchain-Sicherheitsökosystem ist größtenteils noch nicht bereit, mit einer solchen Bedrohung umzugehen.
Sichere dein Protokoll noch heute
Warte nicht auf Kompromisse. Sorg jetzt für ordentliche Zugriffskontrollen.
Rahmenwerk zur Rollentrennung
| Rollentyp | Verantwortlichkeiten | Sicherheitsanforderungen | Dauer der Zeitsperre |
|---|---|---|---|
| Kernsystem | Vertragsaktualisierungen | Hohe Multisig-Schwellenwerte | Lange Verzögerungen |
| Vorgänge | Einrichtung des täglichen Protokolls | Moderate Sicherheitsanforderungen | Mittlere Verzögerungen |
| Pause Guardian | Aussetzung des Notfallprotokolls | Sofortige Handlungsfähigkeit | Keine Verzögerung |
| Abbrechen Guardian | Böswillige Genehmigungen widerrufen | Befugnis zur schnellen Reaktion | Keine Verzögerung |
Sicherheitsteams können jetzt aktiv eingreifen, anstatt nur auf Schäden zu reagieren, wenn sie schon passiert sind. Das bringt aber neue Risiken mit sich, wie zum Beispiel mögliche Fehler in Rollenverwaltungssystemen.
Auch wenn dieses Design-Paradigma null Zugriffskontrollrisiken hat, bringt es große Nachteile mit sich, darunter die Unmöglichkeit von Notfallmaßnahmen und hohe Vorabkosten für die Überprüfung.
Von Anfang an robuste Systeme aufbauen
Die Schwachstelle des privaten Schlüssels, die für fast die Hälfte aller Kryptowährungsdiebstähle im Jahr 2024 verantwortlich ist, ist ein Problem, das man nicht ignorieren kann, weil die Entscheidungen zur Zugriffskontrolle schon am Anfang des Designprozesses getroffen wurden. Auch wenn die herkömmliche Identifizierung von Schwachstellen immer noch wichtig ist, müssen die grundlegenden Designentscheidungen viel früher im Entwicklungszyklus berücksichtigt werden.
Maßnahmen, die in der Praxis zur Verbesserung der Sicherheit ergriffen werden können, sind unter anderem:
- Mach eine ehrliche Analyse, wie ausgereift das aktuelle Protokoll ist.
- Implementierung von Timelock-Verträgen für Verwaltungsfunktionen
- Angemessene Überwachungssysteme für risikoreiche Verwaltungsmodi
- Zuordnung privilegierter Funktionen und Aufteilung in logische Rollen
- Wende das Prinzip der geringsten Privilegien an.
- Identifizierung von Designelementen, die für unveränderliche Muster geeignet sind
Entwickler können innovative und robuste Protokolle erstellen, indem sie Reifegrad-Frameworks verstehen und bewusst Designmuster wählen, die keine Abhängigkeit von Vertrauen erfordern oder Kompromisse zulassen.
Dafür muss man schon in den ersten Phasen der Entwicklung in die operative Widerstandsfähigkeit investieren und sicherstellen, dass die Protokolle nicht nur gegen technische Angriffe, sondern auch gegen menschliche Faktoren geschützt sind, die private Schlüssel so anfällig machen.
