Gewinne:
- Fähigkeit, gängige Schwachstellenmuster wie Wiedereintritt, Zugriffskontrolle, Oracle-Manipulation und Front-Running zu erkennen und sie mit einem statischen Analysetool + künstlicher Intelligenz + Mensch zu scannen
- Fähigkeit, zwischen KI-Stärken bei der Erklärung der Tool-Ausgabe und der Priorisierung von Fehlalarmen und Schwächen in MEV und Geschäftslogik zu unterscheiden
- Beachten Sie, dass es sich bei einem „sauberen Scan“ nicht um ein Sicherheitszertifikat handelt, sondern dass der Scan lediglich eine Kontrollebene darstellt
Die ganzheitliche Disziplin der Wirtschaftsprüfung haben wir in der vorherigen Einheit kennengelernt. In dieser Einheit konzentrieren wir uns auf ein eher technisches Thema: Schwachstellenscan – die systematische Suche nach bekannten Schwachstellenmustern im Code. Hier nutzen wir KI zusammen mit statischen Analysetools als Assistent, der bekannte Schwachstellenmuster scannt und beschreibt. Das Ziel: die häufigsten Schwachstellen im Detail kennenzulernen und zu unterscheiden, wo KI zuverlässig ist und wo sie beim Scannen unzureichend ist.
Statisches und dynamisches Scannen
Beim Scannen gibt es zwei Arten. Statische Analyse – Untersuchen des Codes, ohne ihn auszuführen: Tools wie Slither und Mythril scannen den Vertragscode und kennzeichnen bekannte Muster. Dynamische/symbolische Analyse (Ausführen des Codes mit verschiedenen Eingaben oder mathematische Untersuchung): Fuzzing (Bombardierung mit zufälligen Eingaben) und symbolische Ausführung (Untersuchung aller möglichen Pfade) fallen in diese Gruppe.
KI ersetzt diese Tools nicht, sondern ergänzt sie: Wenn das Fahrzeug eine Warnung ausgibt, erklärt die KI die Warnung im Klartext; KI kann Sie daran erinnern, wenn das Werkzeug ein Muster übersieht; Aber die KI allein kann nicht garantieren, wie viel sie scannt. Der richtige Workflow: Werkzeug + KI + Mensch.
Tipp: Geben Sie der KI die Ausgabe eines statischen Analysetools (z. B. Slither-Bericht) und fragen Sie: „Erklären Sie jede Warnung im Klartext, welche echten Risiken darstellen und welche Fehlalarme sein könnten.“ fragen. KI ist von unschätzbarem Wert, wenn es darum geht, die Rohausgabe von Werkzeugen für den Menschen verständlich und priorisierbar zu machen.
Die häufigsten Schwachstellenmuster
1. Wiedereintritt. Wenn eine Funktion einen externen Vertrag aufruft, ohne seinen Status zu aktualisieren, kann der aufgerufene Vertrag zurückgehen, dieselbe Funktion erneut auslösen und das Geld mehrmals abheben. Lösung: Checks-Effects-Interactions-Reihenfolge und Wiedereintrittsschutz.
2. Mangelnde Zugangskontrolle. Eine kritische Funktion (Entzug, Entzug, Upgrade) wird versehentlich öffentlich gemacht. Es ist einer der häufigsten und teuersten Fehler.
3. Oracle-Manipulation. Die blinde Abhängigkeit des Vertrags von einer externen Preisquelle (Orakel). Der Angreifer manipuliert sofort den Preis und täuscht das Protokoll. Lösung: Zeitgewichteter Durchschnittspreis (TWAP), mehrere Quellen.
4. Ganzzahlüberlauf/-unterschreitung. Wenn eine Zahl den maximal zulässigen Wert überschreitet und zum Anfang zurückkehrt. Modern Solidity fängt das meiste davon automatisch ab, aber das Risiko bleibt im Low-Level-(Assembler-)Code.
5. An vorderster Front. Transaktionen erscheinen im öffentlichen Pool (Mempool), bevor sie bestätigt werden; Der Angreifer kann Ihre Transaktion sehen und seine eigene Transaktion davor einfügen. MEV (Maximal Extractable Value – der aus der Transaktionssequenz extrahierte Wert) ist der allgemeine Name dieses Subjekts.
6. Denial of Service (DoS). Eine Schleife wird zu teuer und macht die Funktion unbrauchbar, oder eine Abhängigkeit von einer Adresse wird gesperrt.
7. Upgrade-Risiken. Speicherkollision und Autoritätsmissbrauch in aktualisierbaren Verträgen.
Verletzlichkeit
KI-Scanning-Vertrauen
Warum
Wiedereintritt
hoch
Bekanntes, klares Muster
Zugangskontrolle
hoch
Schimmel kann gescannt werden
Ganzzahlige Operationen
hoch
Standardsteuerung
Oracle-Manipulation
mittel
Erfordert Kontext
Frontrunning/MEV
Mittel-Niedrig
Protokollspezifisch
Fehler in der Geschäftslogik
niedrig
Authentisch, kontextbezogen
Schwache Eingabeaufforderung / Starke Eingabeaufforderung
Schwache Eingabeaufforderung:
Gibt es eine Lücke in diesem Code?
Kraftvolle Aufforderung:
Ihre Rolle: Assistent für Sicherheitskontrollen. Durchsuchen Sie den Vertrag unten nach den folgenden bekannten Mustern und geben Sie jeweils „gefährdet/nicht/unsicher“ an: Wiedereintritt, Zugriffskontrolle, Ganzzahloperationen, Oracle-Abhängigkeit, Front-Running, DoS, Upgrade-Sicherheit. Verknüpfen Sie jede Feststellung mit der entsprechenden Zeile und erklären Sie, warum ein Risiko besteht. Hierbei handelt es sich um Hypothesen, die mit einem statischen Analysetool und einem Prüfer ÜBERPRÜFT WERDEN. Beachten Sie, dass es zu Fehlalarmen kommen kann.
Vier kopierbare Vorlagen
1) Beschreibung der Werkzeugausgabe:
Unten finden Sie den Bericht eines statischen Analysetools (Slither). Erklären Sie jede Warnung im Klartext: Was bedeutet sie, handelt es sich um ein echtes Risiko oder ein mögliches Fehlalarm, welche Priorität sollte sie haben? Treffen Sie keine feste Entscheidung; Priorisieren Sie die Bestätigung durch den Prüfer.
2) Wiedereintrittsorientiertes Screening:
In diesem Vertrag finden Sie alle Funktionen, die externe Aufrufe durchführen. Überprüfen Sie, ob die Reihenfolge „Checks-Effects-Interactions“ für jeden von ihnen eingehalten wird und ob es einen Wiedereintrittsschutz gibt. Zeigen Sie die riskanten mit einer Linie an. Markieren Sie, wenn Sie sich nicht sicher sind; Generieren von Exploit-Code.
3) Zugangskontrollkarte:
Listen Sie alle externen/öffentlichen Funktionen in diesem Vertrag auf und geben Sie für jede an, „wer anrufen kann“ (jeder/Eigentümer/Rolle). Führen Sie kritische Vorgänge durch (Abheben, Drucken, Upgraden) und markieren Sie diejenigen mit schwacher Zugriffskontrolle. Präsentieren Sie es mit einer Tabelle.
4) Falsch-positive Eliminierung:
Überlegen Sie, warum diese Scanwarnung möglicherweise kein WIRKLICHES Risiko darstellt (falsch positiv): Welcher Kontext oder welche Codebedingung würde diese Warnung ungültig machen? Aber sagen Sie nicht: „Es gibt absolut kein Problem“; Listen Sie die Punkte auf, die einer Bestätigung bedürfen.
Drei Minikoffer (in Zahlen)
Fall 1 – Fahrzeug + KI verdoppelte die Effizienz. Ein Team führte Slither für ein Projekt mit 12 Verträgen durch und erhielt 140 Warnungen. Nachdem wir die Warnungen von der KI erklären und priorisieren ließen, stellte sich heraus, dass 95 der 140 Warnungen falsch positiv waren; Das Team konzentrierte sich auf 45 echte Kandidaten. Die Triage-Zeit verringerte sich von 2 Tagen auf 5 Stunden. Lektion: KI ist wirkungsvoll darin, die Fahrzeugleistung zu humanisieren.
Fall 2 – KI hat MEV gekapert. In einem DEX-Vertrag (dezentraler Austausch) stellte die KI fest, dass die Standardmuster sauber waren, konnte jedoch keine vordergründige Schwachstelle erkennen; weil dies spezifisch für die Reihenfolge der Operationen des Protokolls war. Menschlicher Auditor und Simulation erfasst. Lektion: Protokollspezifische Risiken wie MEV/Front-Running sind die Schwachstelle der KI.
Fall 3 – Es wurde vermieden, Zeit mit einem falschen Positivergebnis zu verschwenden. Dem Team blieb ein unnötiges Umschreiben erspart, als die KI erklärte, dass eine Wiedereintrittswarnung tatsächlich ein Fehlalarm war (die Funktion war bereits geschützt). Aber das Team bestätigte es dennoch mit einem einzigen Test. Lektion: KI priorisiert; Die Bestätigung kommt wiederum durch das Testen.
Grenzen des Scannens
Der Scan findet bekannte Muster. Weder das Tool noch die KI können garantiert eine neue, einzigartige oder protokollspezifische Schwachstelle erkennen. Daher ist das Screening Teil des Audits; nicht er selbst. Die Vorstellung, dass „der Scan sauber und damit sicher ist“, ist eines der gefährlichsten Missverständnisse in diesem Bereich. Beim Ausbaggern werden die niedrig hängenden Früchte eingesammelt; Für tiefgreifende und einzigartige Risiken sind menschliches Fachwissen, Tests, Fuzzing und formelle Prüfungen unerlässlich.
Achtung: Ein „sauberer“ Bericht eines Scan-Tools oder einer KI ist kein Sicherheitszertifikat. Dies so darzustellen – insbesondere gegenüber Anlegern – ist irreführend und unethisch.
Häufige Fehler
- Ersetzen Sie die Inspektion durch ein Screening. Beim Scannen handelt es sich um eine Ebene, nicht um das Ganze.
- KI ohne Tools nutzen. Statische Analyse + KI + menschliche Arbeit zusammenarbeiten.
- Fehlalarme ohne Bestätigung eliminieren. Jeder Bildschirm wird getestet/von Menschen verifiziert.
- Umgehen protokollspezifischer Risiken (MEV) durch den Einsatz von KI. Die Schwachstelle der KI.
- Denken Sie an „sauberer Scan“ = „sicher“. Es kann das Unbekannte nicht finden.
- Generieren von Exploit-Code. Nur eine defensive Risikobeschreibung ist legitim.
Zusammenfassend
- Der Schwachstellenscan sucht nach bekannten Schwachstellenmustern mit Fahrzeug + KI + Mensch.
- KI ist leistungsstark bei der Erklärung und Priorisierung der Ausgabe statischer Analysetools.
- Zuverlässig in klaren Mustern wie Wiedereintritt und Zugriffskontrolle; Schwach in MEV und Geschäftslogik.
- Selbst die Eliminierung falsch positiver Ergebnisse erfordert eine Bestätigung.
- Ein „sauberer Scan“ ist kein Sicherheitszertifikat; Es ist kein Ersatz für eine Aufsicht.
Anwendungsaufgabe
Führen Sie ein statisches Analysetool für einen Mustervertrag aus (falls möglich) oder suchen Sie nach einem vorgefertigten Slither-Bericht. Wenden Sie die Eingabeaufforderung „Tool-Ausgabebeschreibung“ auf die KI an. Bewerten Sie, ob die KI: (1) Warnungen korrekt erklärt, (2) bei der Unterscheidung zwischen Fehlalarmen sinnvoll ist und (3) ein protokollspezifisches Risiko übersieht. Füllen Sie die Spalten „Fahrzeug gefunden / KI erklärt / Mensch bestätigt“ in einer Tabelle aus.
Checkliste
- [ ] Ich habe die Schraffur als Ebene des Steuerelements positioniert.
- [ ] Ich habe ein statisches Analysetool + KI + Mensch zusammen verwendet.
- [ ] Ich habe Kategorie für Kategorie nach bekannten Mustern gesucht.
- [ ] Ich habe Fehlalarme mit Bestätigung eliminiert.
- [ ] Ich habe mich in schwachen Bereichen wie MEV/Geschäftslogik auf Menschen verlassen.
- [ ] Ich habe keine „saubere Reinigung“ als Zusicherung angeboten.
- [ ] Ich habe nur zu Verteidigungszwecken gearbeitet; Ich habe keine Exploits erstellt.