Der vorherige Artikel, From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing, legte dar, warum Blockchain-Penetrationstests notwendig sind. Dieser Artikel widmet sich nun der Frage, was sie eigentlich sind, und untersucht die Definitionen und Grenzen von Blockchain-Penetrationstests genauer.
Es gibt keine weithin anerkannte formale Definition von Blockchain-Penetrationstests, und viele vorgeschlagene Definitionen vermischen diese mit anderen Schutzmaßnahmen, sodass Begriffe wie Audit, Scan und Bug Bounty manchmal als Teil von Penetrationstests eingeordnet werden, obwohl jeder von ihnen ein anderes Ziel verfolgt. Das erschwert es zu erkennen, was ein bestimmter Auftrag tatsächlich validiert hat. Unser Ausgangspunkt, der sich aus der Praxis in Wissenschaft und Industrie ableitet, ist bewusst einfach gehalten: Blockchain-Penetrationstests sind, wie der Name schon sagt, Penetrationstests – eine seit Jahrzehnten etablierte Disziplin – angewandt auf das Web3-Ökosystem, durchgeführt als gegnerische Bewertung des Gesamtsystems gegen eine laufende Web3-Umgebung. Man beginnt bei dieser bekannten Disziplin und fragt dann, was Web3 zum Bedrohungsmodell und zu dem von Testern geforderten Urteilsvermögen hinzufügt.
Blockchain-Penetrationstests sind eine gegnerische, praxisnahe Bewertung eines laufenden Systems, die innerhalb einer vereinbarten Umgebung und festgelegter Einsatzregeln durchgeführt wird, um ausnutzbare Pfade und Kontrollketten zu validieren. Sie ergänzen Sicherheitsaudits auf Code-Ebene und können auch unabhängig davon beauftragt werden [1].
Sie suchen nach Pfaden statt nach isolierten Schwachstellen und arbeiten unter expliziter Autorisierung, festgelegtem Umfang, Zugriffsannahmen und Sicherheitsvorgaben. Dieser Artikel beantwortet drei Fragen: Was Blockchain-Penetrationstests sind, was sie validieren können – insbesondere über die Nachweise hinaus, die ein Audit üblicherweise liefert – und wie ein Institut auf hoher Ebene damit beginnen kann.
Was Web3 hinzufügt: das Bedrohungsmodell im Umgang mit Geld
Web3 behält die traditionellen Angriffsflächen für Penetrationstests bei: Cloud-Infrastruktur, Websites, APIs, Identitäten, privilegierte Zugriffe, Anbieter und Betriebswerkzeuge. Statt dieses Bedrohungsmodell durch ein rein blockchain-bezogenes zu ersetzen, erweitert es dieses auf Systeme, in denen dieselben Einstiegspunkte direkt zu Aktionen führen können, die Werte autorisieren, verbuchen oder bewegen.
Drei Merkmale prägen diese Erweiterung.
-
Erstens sind digitale Vermögenswerte direkt übertragbar. Ein Angreifer, der den richtigen Transaktions- oder Auszahlungspfad erreicht, kann möglicherweise Werte bewegen, ohne dieselben Storno- und Abstimmungsmechanismen zu durchlaufen, die im traditionellen Zahlungsverkehr verwendet werden.
-
Zweitens ist das Signieren häufig eine geldbewegende Handlung. Eine kryptografisch gültige Signatur beweist, dass ein Schlüssel eine Nutzlast autorisiert hat; sie beweist für sich genommen nicht, dass ein Betreiber das richtige Ziel gesehen, die Transaktion verstanden oder die vorgesehene Genehmigungsrichtlinie befolgt hat.
-
Drittens: Wenn ein Institut eigene Smart Contracts einsetzt – was mit zunehmend reichhaltiger On-Chain-Funktionalität in Produkten immer üblicher wird – sind diese Contracts öffentlich aufrufbar und komponierbar. Externe Nutzer und andere Contracts können sie in Abfolgen aufrufen, die das Institut nicht kontrolliert. Sicherheit hängt daher nicht nur von jeder einzelnen Komponente ab, sondern auch davon, wie Identitäten, Anwendungen, Richtlinien, Signatursysteme, Buchhaltungslogik und Contracts zusammenwirken.
Wir modellieren die daraus resultierende Angriffsfläche als eine Geldverarbeitungskette – die Off-Chain-Kontrollen für Signaturabsicht, Genehmigung und Fondslogik, die zu On-Chain-Transaktionen führen (und zunehmend zu den eigenen bereitgestellten Contracts des Instituts) – zusammen mit den Cloud-, Web-, API- und Identitätsebenen, die diese Schritte unterstützen [1]. Ein Angreifer kann mit einem gewöhnlichen Einstiegspunkt beginnen und über mehrere Kontrollen hinweg vorrücken: das zur Signatur präsentierte Objekt manipulieren, einen privilegierten Arbeitsablauf erreichen, eine Autorisierungslücke ausnutzen oder bewirken, dass die Fondslogik einen unbeabsichtigten Zustandsübergang akzeptiert.
Die entscheidende Kompositionslücke ist die Übergabe zwischen Off-Chain und On-Chain: ob Identitäts-, Schnittstellen-, Genehmigungs-, Signatur- und Fondslogik-Kontrollen die beabsichtigte Handlung bewahren, wenn sie zu einer On-Chain-Transaktion wird. Nicht jeder Angriff durchläuft die gesamte Kette. Entscheidend ist, dass das Sicherungsziel ebenenübergreifend ist: Kontrollen, die isoliert betrachtet solide erscheinen, können sich dennoch zu einem ausnutzbaren Pfad durch das laufende Geldverarbeitungssystem verbinden.
Was Blockchain-Penetrationstests leisten
Blockchain-Penetrationstests verwandeln diese Kompositionslücke in Nachweise. Innerhalb des autorisierten Umfangs und der vereinbarten Regeln übersetzen Tester ebenenübergreifende Annahmen in Angriffsszenarien, führen diese Szenarien gegen die laufende Umgebung aus und stellen fest, ob sie einen reproduzierbaren Pfad und eine konkrete Auswirkung erzeugen. Das Ergebnis verbindet den Pfad mit unterstützenden Nachweisen, Schweregrad, Empfehlungen zur Behebung und einer Nachtestung vereinbarter Korrekturen – statt bei einer Liste unverbundener Schwachstellen stehen zu bleiben.
Ihr Unterscheidungsmerkmal ist das spezialisierte Sicherheitsurteil im Bereich Web3, nicht ein einzigartiges Werkzeugset. Tester müssen Verwahrung, Transaktionsabsicht, Genehmigungsrichtlinien, Auszahlungsabläufe, Fondsbuchhaltung und On-Chain-Transaktionsverhalten (einschließlich bereitgestellter Contracts) interpretieren und dabei Nachweise aus herkömmlichen Cloud-, Web-, API-, Identitäts- und privilegierten Zugriffsflächen miteinander verknüpfen. Werkzeuge können bei der Entdeckung oder Validierung unterstützen, aber das fachkundige Urteil entscheidet darüber, ob die beobachteten Bedingungen einen glaubwürdigen geldbewegenden Pfad bilden.
Die Bewertung ist methodisch, evidenzbasiert und zeitpunktbezogen. Ihre Schlussfolgerungen gelten für die geprüften Systeme, Versionen, Konfigurationen, Zugriffsannahmen und Bedingungen. Potenzielle Pfade werden untersucht; bestätigte ausnutzbare Pfade werden mit reproduzierbaren Nachweisen dokumentiert.
Bitte beachten Sie, dass systematische Arbeit über die vereinbarte Angriffsfläche hinweg nicht garantieren kann, dass jede Schwachstelle oder jeder Angriffspfad entdeckt wird, und dass ein verantwortungsvoll durchgeführter Auftrag nicht garantiert, dass Tester einen erfolgreichen Einbruch erzielen.
Innerhalb einer institutionellen Web3-Umgebung erstreckt sich dieser Prozess von Szenario zu Nachweis über fünf miteinander verbundene Fähigkeiten – die testbaren Oberflächen derselben Geldverarbeitungskette. Sie umfassen die Infrastruktur, die die Kette unterstützt, ihre drei Off-Chain-Kontrollen sowie die On-Chain-Transaktionen, an die übergeben wird; sie sind miteinander verbunden, da ein einzelner Pfad mehrere davon durchqueren kann:
-
Produktionsumgebung und Automatisierungsbetrieb: Tester validieren, ob Zugriffs-, Bereitstellungs-, Geheimnis- oder Betriebskontrollen zu einer geldbewegenden Aktion verkettet werden können, und erzeugen Nachweise, die den operativen Einstiegspunkt mit seiner erreichbaren Auswirkung verknüpfen.
-
Web- und dApp-Frontends, Autorisierung und Signaturabsicht: Tester validieren, ob die einem Nutzer oder Betreiber präsentierte Transaktion von der letztlich autorisierten Handlung abweichen kann, und dokumentieren den manipulierten Ablauf sowie das resultierende signierte oder eingereichte Verhalten.
-
Signatur-, Genehmigungs- und Auszahlungsautorisierungsketten: Tester validieren, ob Identitäten, Rollen, Richtlinienprüfungen oder Genehmigungsschritte umgangen oder kombiniert werden können, und dokumentieren die Abfolge sowie die dadurch ermöglichte unautorisierte Handlung.
-
Geschäftslogik der Fonds: Tester validieren, ob Guthaben, Limits, Abstimmungen, Auszahlungsregeln oder Zustandsübergänge unbeabsichtigte Bedingungen akzeptieren, und erfassen einen reproduzierbaren Pfad mit geschäftlicher Auswirkung, statt lediglich einen technischen Defekt.
-
On-Chain-Transaktionen und bereitgestellte Contracts: Tester validieren, wie sich die On-Chain-Interaktionen des Instituts unter gegnerischen Laufzeitbedingungen verhalten; wo das Institut eigene Contracts bereitgestellt hat, prüfen sie das Laufzeitverhalten dieser Contracts und bewahren Nachweise auf Transaktionsebene für das beobachtete Ergebnis. Die Sicherstellung auf Code-Ebene bleibt Aufgabe des entsprechenden Code Audit.
Part 4: Web3 Attack Surfaces: A Penetration Testing Overview bildet diese Oberflächen und ihre Verbindungen ab, ohne das Kernziel zu verändern: festzustellen, ob Bedingungen in der vereinbarten laufenden Umgebung zu einer reproduzierbaren Auswirkung verkettet werden können.
Wo es neben anderen Sicherungsmaßnahmen einzuordnen ist
Der klarste Vergleich erfolgt anhand des Sicherungsziels: der Entscheidung, die die Arbeit unterstützen soll, und der Nachweise, die sie voraussichtlich liefern wird. Wie die folgende Abbildung zeigt, können sich Methoden überschneiden, Disziplinen können zusammenarbeiten, und keine sinnvolle Abgrenzung beruht darauf, so zu tun, als sei ein Team ausschließlich statisch und ein anderes ausschließlich dynamisch. Dasselbe Ziel – ein bereitgestellter Contract, eine Cloud- oder RPC-Oberfläche, ein Signatursystem – kann in den Zuständigkeitsbereich mehrerer dieser Disziplinen fallen; der Unterschied liegt im jeweils betonten Sicherungsziel, nicht in einem exklusiven Anspruch auf das System.
Penetrationstests und Code-Audit
Ein Code Audit – die benannte Form des Audits auf Code-Ebene – schafft in erster Linie Sicherheit im Code (einschließlich Design, Architektur und Protokollannahmen). Es kombiniert fachkundige Überprüfung mit Erkennungswerkzeugen, kann dynamische Techniken einbeziehen und erstellt einen unterzeichneten Bericht gemäß dem vereinbarten Prüfumfang. Bei Contracts, Chains, Bridges, Rollups, Wallets oder anderen Implementierungen untersucht das Audit, ob Design und Code die beabsichtigten Sicherheitseigenschaften erfüllen.
Penetrationstests stellen in erster Linie fest, ob reale Bedingungen über eine vereinbarte, laufende institutionelle Umgebung hinweg zu einer reproduzierbaren Auswirkung verkettet werden können. Sie folgen dem Zusammenspiel zwischen bereitgestellten Anwendungen, Identitäten, Konfigurationen, Arbeitsabläufen, Geschäftslogik, Signatursystemen und Contract-Aufrufen und erfassen dann die Nachweise, die zur Reproduktion und Behebung des Pfads erforderlich sind.
Dies ist ein Unterschied in Zielsetzung und Nachweisführung, kein Ausschlusskriterium für Fähigkeiten. Auditoren können Tests durchführen, Komponenten fuzzen und Laufzeitverhalten untersuchen; Penetrationstester können Konfigurationen, Anwendungslogik und Implementierungsdetails prüfen, um einen Pfad zu verstehen. Die Methoden können sich überschneiden, und die Teams können zusammenarbeiten. Die Leistungen ergänzen sich, ersetzen einander aber nicht: ein Audit allein liefert in der Regel nicht diesen institutionsweiten Laufzeit-Ausnutzbarkeitsnachweis, während Penetrationstests die Sicherstellung auf Code-Ebene in Bezug auf Implementierungs- und Protokolleigenschaften, die von einem Audit abgedeckt werden, nicht ersetzen.
Das gegnerische Verhalten eines Contracts in einem live-institutionellen Pfad kann daher in den Bereich von Penetrationstests fallen, während die Sicherstellung des Contract-Codes selbst zum entsprechenden Code Audit geleitet wird.
Scanning, Bug Bounties und spezialisierte Tests
Vulnerability Scanning bietet automatisierte Breite über bekannte Signaturen, exponierte Dienste, fehlende Patches und häufige Konfigurationsprobleme. Es unterstützt wiederholbare Sichtbarkeit und kann zur Aufklärung beitragen, während Penetrationstests fachkundige Tiefe hinzufügen und feststellen, ob Bedingungen zu einem bedeutsamen Pfad verkettet werden können.
Ein Bug Bounty lädt unabhängige Forscher ein, geeignete Erkenntnisse gemäß veröffentlichten Regeln zu melden. Sein fortlaufendes, crowdsourced Modell kann Randphänomene aufdecken, während ein Penetrationstest-Auftrag einem Team zuweist, eine vereinbarte Umgebung methodisch zu untersuchen und konsolidierte Nachweise, Schweregrade, Empfehlungen zur Behebung und Nachtestung zu liefern. Die beiden Modelle ergänzen sich, und keines garantiert vollständige Entdeckung.
So ist beispielsweise BlockSecs Blockchain Security Testing ein Schwesterprogramm, kein übergeordnetes oder untergeordnetes Programm von Penetrationstests. Es nutzt spezialisierte Engines – einschließlich Differential Testing, Fuzzing, privater Bereitstellung, groß angelegter RPC-Denial-of-Service-Tests sowie Node- oder Cluster-Infrastrukturtests – um die Implementierungskorrektheit und Widerstandsfähigkeit maßgeschneiderter Infrastruktur zu validieren [2]. Blockchain-Penetrationstests konzentrieren sich auf institutionsweite, ebenenübergreifende Pfade durch das laufende Geldverarbeitungssystem. Anwendungs-Hosting und Anwendungs-CI/CD gehören zur Angriffsfläche von Penetrationstests; Node- und Cluster-Infrastruktur sowie groß angelegte RPC-Resilienz gehören zu Blockchain Security Testing. Eine Architektur kann beides benötigen.
Auch verwandte Ziele erfordern eine präzise Zuordnung. Die Sicherstellung des Contract-Codes gehört zum entsprechenden Code Audit. Die kryptografische Korrektheit von Schlüsselverwahrungsimplementierungen, einschließlich MPC-, TSS- und TEE-Designs, gehört zu Wallet Security Audit. Zahlungsseitige agentenbasierte Systeme gehören zu Agentic Payment Security [1]. Penetrationstests können dennoch den umgebenden Signaturworkflow, operative Agenten oder Anwendungspfad untersuchen, wenn dies Teil des vereinbarten institutionellen Umfangs ist.
| Sicherungsziel | Passender Ansatz |
|---|---|
| Validieren, ob ausnutzbare Pfade die Anwendungen, Identitäten, Genehmigungskontrollen, Fondslogik und On-Chain-Transaktionen (einschließlich bereitgestellter Contracts) eines laufenden Instituts durchqueren | Blockchain Penetration Testing |
| Bewertung von Code, Design, Architektur oder Protokollannahmen | Code Audit |
| Bewertung der kryptografischen Korrektheit in einer MPC-, TSS-, TEE- oder Schlüsselverwahrungsimplementierung | Wallet Security Audit |
| Validierung der Implementierungskorrektheit und Widerstandsfähigkeit maßgeschneiderter Node-, Cluster-, EVM-, Datenbank-, MPT- oder groß angelegter RPC-Infrastruktur | Blockchain Security Testing |
| Aufrechterhaltung breiter, automatisierter Sichtbarkeit bekannter Signaturen und Konfigurationsprobleme | Vulnerability Scanning |
| Einladung zu fortlaufender, anreizgetriebener Forschung über eine veröffentlichte geeignete Oberfläche | Bug Bounty |
| Bewertung zahlungsseitiger agentenbasierter Systeme und ihrer Sicherheitsannahmen | Agentic Payment Security |
Dies ist ein Leitfaden zur Zuordnung, keine Abfolge. Ein einzelnes System kann mehrere Sicherungsziele erzeugen und somit eine koordinierte Reihe von Bewertungen rechtfertigen; die Bezeichnungen schließen einander nicht aus.
Je nach Rechtsraum und Institutstyp können Tests eine regulatorische Anforderung oder eine aufsichtsrechtliche Erwartung darstellen, und manche Regelwerke verlangen einen unabhängigen Dritten; Part 1 erläutert diese Unterschiede [3]. Die regulatorische Anwendbarkeit sollte mit Rechtsberatern abgeklärt werden.
Wie man beginnt
Vor der Entscheidung können wir mit den folgenden drei Fragen beginnen: Welche Systeme bewegen Gelder? Welche Sicherungsnachweise liegen bereits vor? Welche Kontrollkette wurde noch nicht gegnerisch validiert? Die Antworten identifizieren die Sicherungslücke, ohne vorschnell einen Dienst namentlich auszuwählen.
Ein Scoping-Gespräch kann dann Ziel, Zugriffsannahmen, Schutzmaßnahmen und erwartete Ergebnisse aufeinander abstimmen. Part 3: Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testing behandelt die Autorisierung, Sicherheit und Koordination, die für die Durchführung des Auftrags erforderlich sind [4].
Wenn Sie bereit sind, hier tätig zu werden, klären Sie Ihre Sicherungslücke mit BlockSec, um Ziel, Nachweise und Schutzmaßnahmen vor Testbeginn abzustimmen.
Setzen Sie fort mit den Leitfäden zu Angriffsflächen:
Ebenfalls in dieser Reihe, demnächst erscheinend:
- Part 5: Authorization and Signing Security: Web, dApps, and
- Part 6: Cloud and CI/CD Security: Automated Operations Attack Surfaces
- Part 7: Treasury Control-Plane Security: Signing and Withdrawal Approvals
- Part 8: Exchange Ledger Security: Theft Paths and Data-Plane Logic
Die Blockchain Penetration Testing pillar page bietet die Sicht auf Ebene des Gesamtauftrags.
Referenzen
Nummeriert in der Reihenfolge ihres ersten Auftretens.
