Am 25. Dezember 2023 erkannte unser Überwachungssystem eine Reihe bösartiger Aktivitäten, die auf Telcoin abzielten. Wir unterstützten das Telcoin-Team bei der Identifizierung der Grundursache als unsachgemäße Initialisierung von Wallet-Verträgen, die aus Inkonsistenzen zwischen der tatsächlichen Implementierung des Wallets und seinem entsprechenden Proxy resultierte. Dieser Bericht zielt darauf ab, eine gründliche Analyse zur vollständigen Erfassung des Vorfalls bereitzustellen.
0x0: Grundlegendes Design
Bevor die Schwachstelle untersucht wird, ist es wichtig, zunächst die Beziehungen zwischen den beteiligten Smart Contracts zu verstehen. Im Wesentlichen können diese in einer Kombination aus drei Entwurfsmustern abstrahiert werden: CloneFactory, Cloneable Proxy und Beacon Proxy-Muster, die im folgenden Diagramm dargestellt sind.
0x1: Schwachstellenanalyse
Die Schwachstelle ergibt sich aus der unsachgemäßen Initialisierung von Wallet-Verträgen, die auf eine Diskrepanz zwischen der tatsächlichen Implementierung des Wallets und seinem entsprechenden Proxy zurückzuführen ist. Insbesondere während des Initialisierungsprozesses initialisierte der Proxy den Speicher-Slot 0 in einen Nicht-Null-Zustand, indem er in die niederwertigsten Bits des Speicherortes schrieb. Anschließend schrieb auch der Wallet-Code in den Speicher-Slot 0 und überschrieb dabei den Anfangswert des Proxy in den niederwertigsten Bits. Dieses Problem ist kein Ergebnis einer inhärenten Schwachstelle in einem der Smart Contracts, sondern vielmehr der Interaktion zwischen beiden.
Im Folgenden werden wir die Details anhand der unten angegebenen Transaktionsübersicht erläutern:
Insbesondere innerhalb der Funktion CloneableProxy:Proxy.initialize() gibt es einen delegatecall, der die Funktion Wallet.initialize() aufruft. Dieser Aufruf erfolgt über einen delegatecall an die Funktion CloneableProxy:Implementation.initialize(). Infolgedessen werden alle Änderungen am Speicher, die von der Funktion Wallet.initialize() vorgenommen werden, im Speicher des CloneableProxy:Proxy-Vertrags widergespiegelt.
Um die Auswirkungen vollständig zu verstehen, ist es notwendig, das Speicherlayout des CloneableProxy:Proxy-Vertrags zu untersuchen. Die Definition dieses Vertrags wird wie folgt umrissen:
Da weder der Proxy noch die ERC1967Upgrade-Verträge Speicher-Variablen haben, wird Slot 0 stattdessen von zwei Speicher-Variablen verwendet – _initialized und _initializing –, die beide vom Initializable-Vertrag geerbt werden.
Betrachten wir nun den Wallet-Vertrag. Innerhalb der Funktion Wallet.initialize() ist offensichtlich, dass Slot 0xaa als Initialisierungsflag dient. Dies wird durch den folgenden Code-Schnipsel in den Zeilen 3–4 und 11–12 unterstrichen:
Beachten Sie, dass Slot 0 für _state zugewiesen ist, der die nächsten 32 Bytes nach dem Funktionsselektor aus den Calldata speichert, wie in Zeile 21 angegeben. Für weitere detaillierte Informationen siehe den Kommentar am Anfang des Wallet-Vertrags:
Es gibt eine erkennbare Diskrepanz bei der Verwendung von Slot 0: Der CloneableProxy:Proxy-Vertrag interpretiert ihn als Initialisierungsflag, während die Funktion Wallet:initialize() ihn als den Zustand des Wallets behandelt.
Folglich werden nach dem Initialisierungsprozess die beiden niederwertigsten Bytes von Slot 0 auf Null zurückgesetzt. Dies setzt sowohl _initialized als auch _initializing effektiv auf Null. Infolgedessen wird der CloneableProxy:Proxy-Vertrag für eine erneute Initialisierung über die initialize()-Funktion anfällig, da der Schutz des Initializer-Modifikators umgangen werden kann.
Offensichtlich hängt das Potenzial zur Ausnutzung vom Zustand des Wallets ab. Sobald der Zustand des Wallets auf einen Nicht-Null-Wert aktualisiert ist, verhindert dies jede weitere Reinitialisierung dieses Vertrags. Nach der Initialisierung, da der Zustand des Wallets bei jeder Transaktion aktualisiert wird, steigt die Wahrscheinlichkeit, dass die beiden niederwertigsten Bytes von Slot 0 nicht Null sind, was das Wallet effektiv vor einer Reinitialisierung schützt. Dies erklärt, warum die Mehrheit der anfälligen Wallets wenig oder gar keine Transaktionshistorie hatte und somit dem Angriff ausgesetzt war.
0x2: Angriffsanalyse
Der Angreifer begann mit der Reinitialisierung des anfälligen CloneableProxy:Proxy-Vertrags, um die Adresse des Beacon-Vertrags zu ändern. Anschließend fuhr der Angreifer mit der Übertragung der im CloneableProxy:Proxy-Vertrag enthaltenen Vermögenswerte fort, wie unten detailliert beschrieben:
Es ist erwähnenswert, dass mehrere anfällige Verträge in einer einzigen Transaktion kompromittiert wurden, wobei der Angreifer diese Strategie wiederholt anwendete.
0x3: Zusammenfassung der Angriffe
Wir beobachteten insgesamt 4.958 Angriffe, die von sechs verschiedenen Konten ausgeführt wurden, wie folgt:
0x4: Behebung und Empfehlungen
Unsere Untersuchung hat ergeben, dass das Kernproblem auf der inkonsistenten Nutzung des Speicher-Slots 0 beruht, was zur Möglichkeit der Reinitialisierung anfälliger Verträge führt. Offensichtlich beinhaltet die Behebung eine sorgfältige Verwaltung der Speicherzuweisungen.
Aus diesem Vorfall haben wir mehrere wichtige Erkenntnisse gewonnen:
-
Extreme Vorsicht ist geboten, wenn Speicher-Slots mit Inline-Assembly manipuliert werden, da Fehler zu erheblichen Schwachstellen führen können.
-
Behalten Sie die Überwachung des Vertragsstatus bei. Die Fähigkeit, schnell zu reagieren, hängt von rechtzeitigen Benachrichtigungen ab.
-
Implementieren Sie einen Pausierungsmechanismus in Verträgen, um eine sofortige Aussetzung von Aktivitäten zu ermöglichen, wenn eine Kompromittierung erkannt wird.
Darüber hinaus unterstreicht die Tatsache, dass dieser Vorfall mehrere Angriffstransaktionen gegen verschiedene Wallet-Verträge umfasste, den dringenden Bedarf an Bedrohungsüberwachungs- und Angriffsblockierungslösungen wie Phalcon. Solche Werkzeuge sind unerlässlich, um zukünftige Risiken zu mindern und sich vor potenziellen Verlusten zu schützen.
0x5: Zeitplan der Ereignisse
09:23 Uhr PST, 25. Dezember: Unser System erkannte die erste bösartige Transaktion im Polygon-Netzwerk:
10:28 Uhr PST, 25. Dezember: Das Telcoin-Supportteam meldete den Vorfall im internen Kommunikationskanal.
10:32 – 10:37 Uhr PST, 25. Dezember: Telcoin-Teammitglieder benachrichtigten die Telcoin-Discord-Community und riefen eine Notfallkonferenz mit allen relevanten Schlüsselteammitgliedern ein.
10:45 Uhr PST, 25. Dezember: Eine Web Application Firewall-Regel wurde implementiert, um den gesamten Zugriff auf die Telcoin-Infrastruktur einzuschränken.
11:02 Uhr PST, 25. Dezember: Das Telcoin-Team leitete Gespräche mit Seal 911 ein.
11:11 Uhr PST, 25. Dezember: Ein Kriegszimmer wurde vom Telcoin-Team und anderen Sicherheitsexperten eingerichtet, um die Ursache des Problems zu ermitteln und mögliche Lösungen zur Blockierung des Angriffs zu erörtern.
13:14 Uhr PST, 25. Dezember: Das Telcoin-Team gab eine öffentliche Warnung an die Nutzer über X (Twitter) heraus:
15:39 Uhr PST, 25. Dezember: Telcoin kontaktierte Chainalysis & Slowmist, um bei der Untersuchung der gestohlenen Gelder zu helfen, indem sie die gestohlenen Wallets und Adressen identifizierten und diese Informationen mit den Börsen teilten.
22:35 Uhr PST, 25. Dezember: Auf Einladung des Telcoin-Teams traten wir dem Kriegszimmer bei und teilten unsere Analyse zur Ermittlung der Grundursache mit.
23:00 Uhr PST, 25. Dezember bis 02:06 Uhr PST, 26. Dezember: Nach der Ermittlung der Grundursache entwickelte das Telcoin-Team erfolgreich eine Abhilfestrategie, indem es den Exploit auf sichere und kontrollierte Weise reproduzierte. Dieser Prozess beinhaltete die Reinitialisierung der Wallet-Proxies, um sie mit einem neuen, sicher implementierten Beacon abzugleichen. Da dieser Exploit eine einmalige Gelegenheit war, kann Telcoin die Wallet-Konfigurationen präventiv aktualisieren und somit die Fähigkeit des Angreifers, diese Schwachstellen weiter auszunutzen, deaktivieren.
02:07 Uhr PST, 26. Dezember bis 02:14 Uhr PST, 26. Dezember: Das Telcoin-Team implementierte den Abhilfeprozess für alle zuvor nicht kompromittierten Wallets, um eine umfassende Abdeckung zu gewährleisten. Für eine schnelle und effiziente Bereitstellung wurde der Prozess in Stapeln innerhalb eines eng definierten Zeitfensters durchgeführt. Telcoin begann dann mit der Vorbereitung und internen Prüfung des Behebungsplans zur vollständigen Wiederherstellung aller betroffenen Wallets und einer permanenten Lösung für alle Wallets.
16:52 Uhr PST, 26. Dezember: Telcoin und unser Team begannen Diskussionen über die folgenden Themen:
- Überblick über den Vorfall
- Zeitplan der Ereignisse: Eine chronologische Darstellung des Vorfalls.
- Analyse der Grundursache: Eine detaillierte Analyse der zugrunde liegenden Ursachen des Vorfalls.
- Empfehlungen zur Verbesserung
- Code-Audit
12:27 Uhr PST, 29. Dezember: Nach mehreren Diskussionsrunden begannen wir mit dem Telcoin-Team zusammenzuarbeiten, um den Post-Mortem-Bericht zu entwerfen und die Abhilfemaßnahmen zu prüfen.
-
Januar 2024: Der Entwurf des Post-Mortem wurde vorgelegt.
-
Januar 2024: Unsere Prüfungsergebnisse, einschließlich der identifizierten Probleme und Empfehlungen, wurden präsentiert.
-
Januar bis 10. Januar 2024: Wir arbeiteten mit dem Telcoin-Team zusammen, um das Post-Mortem zu finalisieren und die Behebungsmaßnahmen zu überprüfen.
Es ist auch erwähnenswert, dass Telcoin seit dem 25. Dezember bis heute aktiv in enger Zusammenarbeit mit Blockchain-Untersuchungsfirmen und Strafverfolgungsbehörden in Bezug auf den Vorfall tätig ist.
Über BlockSec
BlockSec ist ein wegweisendes Blockchain-Sicherheitsunternehmen, das 2021 von einer Gruppe weltweit renommierter Sicherheitsexperten gegründet wurde. Das Unternehmen engagiert sich für die Verbesserung der Sicherheit und Benutzerfreundlichkeit für die aufstrebende Web3-Welt, um deren Massenadoption zu erleichtern. Zu diesem Zweck bietet BlockSec Dienstleistungen für die Prüfung von Smart Contracts und EVM-Ketten, die Phalcon-Plattform für die proaktive Entwicklung von Sicherheitsmaßnahmen und die Blockierung von Bedrohungen, die MetaSleuth-Plattform für die Verfolgung und Untersuchung von Geldern sowie die MetaDock-Erweiterung für Web3-Entwickler, die effizient im Krypto-Bereich surfen.
Bis heute hat das Unternehmen über 300 geschätzte Kunden wie MetaMask, Uniswap Foundation, Compound, Forta und PancakeSwap betreut und im Rahmen von zwei Finanzierungsrunden zweistellige Millionenbeträge von führenden Investoren wie Matrix Partners, Vitalbridge Capital und Fenbushi Capital erhalten.
Website: https://blocksec.com/
