Zum Inhalt springen

Risiken bei Eigentümern und Wiederherstellung von Smart Accounts

Prüfen Sie, wer ein Smart Account kontrollieren kann, wie die Wiederherstellung den Eigentümer ändert, welche Verzögerungen und Abbruchrechte gelten und ob Module oder Upgrades verborgene Übernahmepfade schaffen.

Aktualisiert

Nur zu Bildungszwecken; keine Anlage-, Rechts- oder Sicherheitsberatung. Ein Fehler bei Wiederherstellung oder Konfiguration kann die Kontrolle über ein Smart Account übertragen oder es dauerhaft sperren.

Direkte Antwort

Ein Smart Account wird von der für dieses Konto bereitgestellten Autorisierungslogik kontrolliert, nicht unbedingt von einem einzigen privaten Schlüssel. Ein Eigentümer oder Validator kann gewöhnliche Vorgänge genehmigen, während ein Wächter, Wiederherstellungsmodul, Executor oder Upgrade-Administrator einen separaten Pfad besitzen kann, der den Eigentümer ersetzt oder Transaktionen ausführt.

Wiederherstellung senkt die Wahrscheinlichkeit, dass ein verlorener Schlüssel das Konto unbrauchbar macht, fügt aber eine weitere Angriffsfläche für Übernahmen hinzu. Prüfen Sie jeden Pfad, der Ausführungen autorisieren, Validatoren oder Eigentümer ändern, Module installieren, Code aktualisieren oder eine Wiederherstellung abbrechen und abschließen kann. Oberflächenbezeichnungen wie „Eigentümer“ und „Wächter“ belegen nicht die tatsächliche Vertragsberechtigung.

Halten Sie das Ergebnis in einer Berechtigungstabelle fest: genaue On-Chain-Adresse, Rolle, aufrufbare Aktion, Schwellenwert, Verzögerung, Abbruchberechtigung, Ablauf, Ausgabenbereich, Upgrade-Berechtigung und unabhängige Kontrolldomäne. Prüfen Sie die Tabelle nach jeder Konfigurationsänderung und auf jeder Chain, auf der das Konto existiert.

Funktionsweise

  1. Konto und Code identifizieren. Prüfen Sie Chain-ID und Kontoadresse und bestimmen Sie dann Implementierung, Proxy oder Beacon, Factory und Version. Lesen Sie bei einem ERC-1967-Proxy die Implementierungs-, Beacon- und Administrator-Slots, statt einem Oberflächenhinweis zu vertrauen.
  2. Autorisierungspfade erfassen. Lesen Sie Eigentümer und Schwellenwerte, ERC-4337-Validatoren, ERC-7579-Validatoren, Executors, Hooks und Fallback-Handler, Safe-ähnliche Module und Guards, Sitzungsschlüssel, Wiederherstellungsverträge sowie jeden Notfall- oder Upgrade-Administrator. Ein Executor oder Safe-Modul kann ohne den normalen Eigentümerschwellenwert ausführen.
  3. Zustandsmaschine der Wiederherstellung entschlüsseln. Bestimmen Sie, wer einen Ersatz-Eigentümer benennen kann, wie Wächterzustimmungen gezählt werden, ob Zustimmungen ablaufen, wann die Verzögerung beginnt, wer abbrechen und wer abschließen kann und was bei ersetzter oder wiederholter Wiederherstellung geschieht. Nehmen Sie nicht an, dass alle Verträge für „soziale Wiederherstellung“ dieselbe Reihenfolge nutzen.
  4. Unabhängigkeit und Verfügbarkeit testen. Verschiedene Adressen sind nicht unabhängig, wenn ein Gerät, eine Person, ein Cloud-Konto, ein Passwort-Tresor, ein Verwahrer oder Administrator sie kontrolliert. Bestätigen Sie, dass der Schwellenwert nach einem erwarteten Ausfall noch erreichbar ist, ohne einer Kontrolldomäne genügend Macht zur Übernahme zu geben.
  5. Konfigurationsberechtigung prüfen. Bestimmen Sie, wer Wächter, Validatoren, Executors, Hooks, Module oder Fallback-Handler hinzufügen oder entfernen, Schwellenwert oder Verzögerung ändern, den Abbruch aussetzen oder Konto- und Wiederherstellungscode aktualisieren kann. Eine Zeitsperre ist nur nützlich, wenn kein anderer Rolle Verzögerung und Abbruchpfad umgehen kann.
  6. Überwachen und verifizieren. Abonnieren oder prüfen Sie unabhängig Änderungen an Wiederherstellung, Eigentümern, Modulen, Schwellenwert, Implementierung und Administrator. Entschlüsseln Sie nach jedem Vorgang die Transaktion und prüfen Sie auf der richtigen Chain Belege, Ereignisse, Speicher und die endgültige Eigentümermenge; eine Erfolgsmeldung der Oberfläche reicht nicht aus.

Durchgerechnetes Beispiel

Angenommen, ein Konto hat Eigentümer O und die drei Wächter G1, G2 und G3. Beliebige 2-of-3 Wächter können den neuen Eigentümer N vorschlagen; dann beginnt eine Verzögerung von 24-hour; O kann während der Verzögerung abbrechen; und nach ihrem Ablauf kann jeder abschließen. Das Wiederherstellungsmodul kann die Funktion zum Eigentümerwechsel aufrufen, ohne dass O die letzte Transaktion genehmigt.

Die Bezeichnungen deuten eine verteilte Wiederherstellung an, doch G1 und G2 sind Anwendungen mit Sicherung im selben Cloud-Konto. Ein kompromittierter Cloud-Zugang gibt einem Angreifer effektiv den Schwellenwert 2-of-3. Er schlägt N vor; scheitern Überwachung oder Abbruch 24 hours lang, überträgt der Abschluss die Kontrolle, obwohl der private Schlüssel von O nie gestohlen wurde.

Die Prüfung kennzeichnet G1 und G2 deshalb als eine Kontrolldomäne, verifiziert Adresse und Code des Wiederherstellungsmoduls, testet den Abbruch von einem nicht kompromittierten Gerät, bestätigt das Ereignis, das die Verzögerung startet, und prüft, ob ein Upgrade-Administrator das Modul sofort ersetzen kann. Eine echte Wiederherstellung des vermögenshaltenden Kontos erfolgt nur, wenn die Implementierung einen dokumentierten und sicher umkehrbaren Testablauf bietet.

Risiken und Kontrollen

  • Korrelierte Wächter: Verwenden Sie wirklich unabhängige Geräte, Zugangsdaten, Personen oder Verwahrer; testen Sie Kontakt- und Wiederherstellungsabläufe, ohne Seed-Phrasen zusammenzuführen.
  • Übermächtiges Modul oder Executor: Prüfen Sie installierten Code und den genauen aufrufbaren Umfang. Entfernen Sie ungenutzte Module über den dokumentierten Pfad und verifizieren Sie die Entfernung on-chain.
  • Schwacher Schwellenwert: Bewerten Sie Übernahmeschutz und Verfügbarkeit. Ein höherer nomineller Wert hilft nicht, wenn Unterzeichner eine Kontrolldomäne teilen; ein unerreichbarer Wert kann das Konto sperren.
  • Fehlende oder umgehbare Verzögerung: Prüfen Sie on-chain die Verzögerung, das auslösende Ereignis, wer sie verkürzen kann und jeden Pfad für einen sofortigen Eigentümerwechsel.
  • Wirkungsloser Abbruch: Üben Sie Erkennung und Abbruch, halten Sie bei Bedarf natives Gas und einen unabhängigen Übermittlungspfad bereit und prüfen Sie, ob der Abbruch selbst den alten Eigentümer, ein Quorum oder eine andere Rolle verlangt.
  • Übernahme durch Upgrade: Überwachen Sie Änderungen an Implementierung, Beacon und Administrator. Behandeln Sie einen Administrator, der ohne Verzögerung aktualisieren kann, so, als könne er jede dokumentierte Wiederherstellungsregel ändern.
  • Bösartige oder veraltete Oberfläche: Prüfen Sie unabhängig Chain, Konto, Modul, vorgeschlagenen Eigentümer, Schwellenwert, Verzögerung und Transaktions-calldata. Geben Sie einem „Wiederherstellungsdienst“ niemals Seed-Phrase oder privaten Schlüssel.
  • Falscher Abschluss: Prüfen Sie nach Abbruch oder Abschluss Beleg und endgültigen Speicherzustand. Verifizieren Sie, dass gewünschte Eigentümer und Module aktiv sind und der unerwünschte Vorschlag nicht mehr ausführbar ist.

Erscheint eine unautorisierte Wiederherstellung, stoppen Sie das Signieren nicht zugehöriger Anfragen und sichern Sie Vorschlags-ID, Transaktions-Hash, calldata, Block, Moduladresse und aktuellen Zustand. Verifizieren Sie die Warnung von einem nicht kompromittierten Gerät über einen unabhängigen RPC, nutzen Sie den dokumentierten Abbruchpfad, falls er noch verfügbar ist, und überwachen Sie Abschluss, Upgrades, Moduländerungen und Vermögensübertragungen. Könnte die Kontrolle bereits verloren sein, folgen Sie einem vorab erstellten Notfallplan und nutzen Sie nur authentifizierte Projekt- oder Verwahrkontakte; eine improvisierte Übertragung kann vorweggenommen werden oder das Ziel offenlegen.

Häufige Irrtümer

  • „Nur der Eigentümer kann Vermögenswerte bewegen.“ Validatoren, Executors, Module, Wiederherstellungsverträge oder aktualisierter Code können weitere Ausführungspfade bieten.
  • „Drei Wächter sind drei unabhängige Parteien.“ Der Vertrag zählt gültige Zustimmungen von Adressen; gemeinsame Geräte, Sicherungen oder Administratoren erkennt er nicht.
  • „Eine Verzögerung von 24-hour garantiert Reaktionszeit.“ Überwachung, nutzbare Abbruchberechtigung, Gas und Aufnahme der Transaktion sind ebenfalls nötig; ein anderer privilegierter Pfad kann die Verzögerung umgehen.
  • „Das Entfernen eines Wächters beendet seinen Zugriff.“ Prüfen Sie die endgültige On-Chain-Konfiguration und andere Rollen, Module, Sitzungsschlüssel und offene Wiederherstellungen dieser Partei.
  • „Der Support kann jedes Smart Account wiederherstellen.“ Nur on-chain codierte oder zuvor konfigurierte Berechtigungen können ein selbstverwahrtes Konto ändern. Ohne gültigen Eigentümer- oder Wiederherstellungspfad kann der Zugang dauerhaft verloren sein.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...