- Dezember 2023, unser Überwachungssystem hat eine Reihe von bösartigen Aktivitäten entdeckt, die auf Telcoin abzielten. Wir haben das Telcoin-Team bei der Identifizierung der Grundursache unterstützt, die in der unsachgemäßen Initialisierung von Wallet-Verträgen lag und aus Inkonsistenzen zwischen der tatsächlichen Implementierung der Wallet und ihrem entsprechenden Proxy resultierte. Dieser Bericht zielt darauf ab, eine gründliche Analyse zu liefern, um den Vorfall vollständig zu verstehen.
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 Designmustern abstrahiert werden: CloneFactory, Cloneable Proxy und Beacon Proxy, die im folgenden Diagramm dargestellt sind.
0x1: Schwachstellenanalyse
Die Schwachstelle beruht auf der unsachgemäßen Initialisierung von Wallet-Verträgen, die auf eine Diskrepanz zwischen der tatsächlichen Implementierung der Wallet und ihrem entsprechenden Proxy zurückzuführen ist. Insbesondere während des Initialisierungsprozesses hat der Proxy den Speicherplatz 0 in einen Nicht-Null-Zustand initialisiert, indem er in die niederwertigsten Bits des Speicherorts geschrieben hat. Anschließend hat der Wallet-Code ebenfalls in Speicherplatz 0 geschrieben und dabei den Anfangswert des Proxys in den niederwertigsten Bits überschrieben. Dieses Problem ist nicht das Ergebnis einer inhärenten Schwachstelle in einem der Smart Contracts, sondern vielmehr der Wechselwirkung zwischen beiden.
Im Folgenden werden wir die Details anhand der unten stehenden Transaktionsverfolgung erläutern:
Insbesondere in 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 durch die Funktion Wallet.initialize() im Speicher vorgenommenen Änderungen 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 ist wie folgt umrissen:
Da weder der Proxy noch die ERC1967Upgrade-Verträge Speicher Variablen haben, wird Speicherplatz 0 stattdessen von zwei Speicher Variablen – _initialized und _initializing – genutzt, die beide vom Initializable-Vertrag geerbt wurden.
Betrachten wir nun den Wallet-Vertrag. Innerhalb der Funktion Wallet.initialize() ist ersichtlich, dass Speicherplatz 0xaa als Initialisierungsflag dient. Dies wird durch den folgenden Codeausschnitt in den Zeilen 3-4 und 11-12 unterstrichen:
Beachten Sie, dass Speicherplatz 0 für _state zugewiesen ist, der die nächsten 32 Bytes ab dem Funktionsselektor aus den calldata speichert, wie in Zeile 21 angegeben. Weitere detaillierte Informationen finden Sie im Kommentar am Anfang des Wallet-Vertrags:
Es gibt eine erkennbare Diskrepanz bei der Nutzung von Speicherplatz 0: Der CloneableProxy:Proxy-Vertrag interpretiert ihn als Initialisierungsflag, während die Funktion Wallet:initialize() ihn als Zustand der Wallet behandelt.
Infolgedessen werden nach dem Initialisierungsprozess die zwei niederwertigsten Bytes von Speicherplatz 0 auf Null zurückgesetzt. Dies setzt sowohl _initialized als auch _initializing effektiv auf Null. Infolgedessen wird der CloneableProxy:Proxy-Vertrag anfällig für eine Reinitialisierung über die initialize()-Funktion, da der Schutz des initializer-Modifikators umgangen werden kann.
Offensichtlich hängt das Ausnutzungspotenzial vom Zustand der Wallet ab. Sobald dieser auf einen Nicht-Null-Wert aktualisiert ist, verhindert der Zustand der Wallet jede weitere Reinitialisierung dieses Vertrags. Nach der Initialisierung steigt die Wahrscheinlichkeit, dass die zwei niederwertigsten Bytes von Speicherplatz 0 nicht null sind, da der Wallet-Zustand mit jeder Transaktion aktualisiert wird, was die Wallet effektiv immun gegen eine Reinitialisierung macht. Dies erklärt, warum die Mehrheit der anfälligen Wallets wenig oder 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 damit fort, die im CloneableProxy:Proxy-Vertrag enthaltenen Vermögenswerte zu übertragen, wie unten detailliert beschrieben:
Es ist bemerkenswert, dass mehrere anfällige Verträge in einer einzigen Transaktion kompromittiert wurden, wobei der Angreifer diese Strategie wiederholt ausführte.
0x3: Zusammenfassung der Angriffe
Wir haben insgesamt 4.958 Angriffe beobachtet, die von sechs verschiedenen Konten ausgeführt wurden, wie folgt:
0x4: Fehlerbehebung und Empfehlungen
Unsere Untersuchung hat ergeben, dass das Kernproblem in der inkonsistenten Nutzung des Speicherplatzes 0 liegt, was die Möglichkeit der Reinitialisierung anfälliger Verträge zur Folge hat. Offensichtlich beinhaltet die Fehlerbehebung ein sorgfältiges Management von Speicherzuweisungen.
Aus diesem Vorfall haben wir mehrere wichtige Erkenntnisse gewonnen:
-
Seien Sie äußerst vorsichtig beim Manipulieren von Speicherplätzen mit Inline-Assembly, da Fehler zu erheblichen Schwachstellen führen können.
-
Überwachen Sie den Status von Verträgen sorgfältig. Die Fähigkeit, schnell zu reagieren, hängt von rechtzeitigen Warnmeldungen ab.
-
Implementieren Sie einen Pausierungsmechanismus in Verträgen, um die sofortige Aussetzung von Aktivitäten zu ermöglichen, wenn ein Kompromittierung festgestellt wird.
Darüber hinaus unterstreicht die Tatsache, dass dieser Vorfall mehrere Angriffstransaktionen gegen verschiedene Wallet-Verträge umfasste, die dringende Notwendigkeit von Bedrohungsüberwachungs- und Angriffsschutzlösungen wie Phalcon. Solche Werkzeuge sind unerlässlich, um zukünftige Risiken zu mindern und vor potenziellen Verlusten zu schützen.
0x5: Zeitplan der Ereignisse
09:23 Uhr PST, 25. Dezember: Unser System hat die erste bösartige Transaktion im Polygon-Netzwerk erkannt:
10:28 Uhr PST, 25. Dezember: Das Telcoin-Support-Team berichtete den Vorfall im internen Kommunikationskanal.
10:32 - 10:37 Uhr PST, 25. Dezember: Telcoin-Teammitglieder benachrichtigten die Telcoin Discord-Community und erstellten einen Notfallanruf mit allen relevanten Schlüsselteammitgliedern.
10:45 Uhr PST, 25. Dezember: Eine Web Application Firewall-Regel wurde implementiert, um allen Zugriff auf die Telcoin-Infrastruktur zu beschränken.
11:02 Uhr PST, 25. Dezember: Das Telcoin-Team nahm Gespräche mit Seal 911 auf.
11:11 Uhr PST, 25. Dezember: Ein Kriegsraum wurde vom Telcoin-Team und anderen Sicherheitsexperten eingerichtet, um die Grundursache zu ermitteln und mögliche Lösungen zur Abwehr des Angriffs zu diskutieren.
13:14 Uhr PST, 25. Dezember: Das Telcoin-Team gab über X (Twitter) eine öffentliche Warnung an die Nutzer heraus:
15:39 Uhr PST, 25. Dezember: Telcoin kontaktierte Chainalysis & Slowmist, um bei der Untersuchung der gestohlenen Gelder zu helfen, indem sie eine Untersuchung durchführten, bei der die gestohlenen Wallets und Adressen gekennzeichnet und diese Informationen an Börsen weitergegeben wurden.
22:35 Uhr PST, 25. Dezember: Auf Einladung des Telcoin-Teams schlossen wir uns dem Kriegsraum an und teilten unsere Analyse mit, um die Grundursache zu ermitteln.
23:00 Uhr PST, 25. Dezember bis 02:06 Uhr PST, 26. Dezember: Nach Identifizierung der Grundursache entwickelte das Telcoin-Team erfolgreich eine Minderungsstrategie, indem es den Exploit auf sichere und kontrollierte Weise replizierte. Dieser Prozess beinhaltete die Reinitialisierung der Wallet-Proxys, um sie an einen neuen, sicher implementierten Beacon anzupassen. Da dieser Exploit eine einmalige Gelegenheit war, kann Telcoin die Wallet-Konfigurationen proaktiv aktualisieren und somit die Fähigkeit des Angreifers, diese Schwachstellen weiter auszunutzen, einschränken.
02:07 Uhr PST, 26. Dezember bis 02:14 Uhr PST, 26. Dezember: Das Telcoin-Team implementierte den Minderungs-Prozess über alle nicht zuvor kompromittierten Wallets, um eine umfassende Abdeckung zu gewährleisten. Für eine schnelle und effiziente Bereitstellung wurde der Prozess in Batches innerhalb eines streng definierten Zeitfensters durchgeführt. Telcoin begann dann mit der Vorbereitung und internen Prüfung des Behebungsplans für eine vollständige Wiederherstellung aller betroffenen Wallets und eine dauerhafte Behebung für alle Wallets.
16:52 Uhr PST, 26. Dezember: Telcoin und unser Team nahmen Diskussionen zu folgenden Themen auf:
- Übersicht über den Vorfall
- Zeitplan der Ereignisse: Chronologische Darstellung der Entwicklung 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 an der Erstellung des Post-Mortem-Berichts und der Prüfung der Behebungsmaßnahmen.
-
Januar 2024: Der Entwurf des Post-Mortem wurde vorgelegt.
-
Januar 2024: Unsere Prüfungsergebnisse, einschließlich der identifizierten Probleme und Empfehlungen, wurden präsentiert.
-
bis 10. Januar 2024: Wir arbeiteten mit dem Telcoin-Team zusammen, um das Post-Mortem abzuschließen und die Korrekturen zu überprüfen.
Es ist auch erwähnenswert, dass Telcoin vom 25. Dezember bis zum heutigen Datum aktiv und in enger Zusammenarbeit mit Blockchain-Ermittlungsfirmen und Strafverfolgungsbehörden in Bezug auf den Vorfall tätig war.
Über BlockSec
BlockSec ist ein wegweisendes Unternehmen für Blockchain-Sicherheit, das 2021 von einer Gruppe weltweit anerkannter Sicherheitsexperten gegründet wurde. Das Unternehmen hat sich der Verbesserung der Sicherheit und Benutzerfreundlichkeit für die aufstrebende Web3-Welt verschrieben, um deren Massenadoption zu ermöglichen. Zu diesem Zweck bietet BlockSec Dienstleistungen für die Sicherheitsprüfung von Smart Contracts und EVM-Ketten, die Phalcon-Plattform für die Sicherheitsentwicklung und proaktive Bedrohungserkennung, die MetaSleuth-Plattform für die Nachverfolgung 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 angesehene Kunden wie MetaMask, Uniswap Foundation, Compound, Forta und PancakeSwap betreut und in zwei Finanzierungsrunden von namhaften Investoren wie Matrix Partners, Vitalbridge Capital und Fenbushi Capital zweistellige Millionenbeträge erhalten.
Website: https://blocksec.com/
