Während sich die DeFi-Protokolle im Ethereum-Ökosystem weiter erwärmen, werden in CipherTrace immer mehr Exploits und Angriffsvektoren sichtbar. In der vergangenen Woche, am 28. Dezember 2020, wurde der Schildabbauvertrag von Cover Protocol, Blacksmith, ausgenutzt. Hacker nutzten einen Fehler im Bergbauvertrag, um eine unendliche Menge an COVER-Token zu prägen und mehr als 4.4 Millionen US-Dollar aus dem Projekt zu ziehen.
Deckungsprotokoll freigegeben In ihrem gestrigen Post-Mortem wurde festgestellt, dass der Fehler, der Devs nicht bekannt war, seit der erstmaligen Bereitstellung des Blacksmith-Vertrags aufgetreten war, was die Bedeutung gründlicher Sicherheitsüberprüfungen und Pentesting von hervorhebt Smart ContractsWas sind intelligente Verträge? Ein intelligenter Vertrag ist ein Computerprofi… Mehr.
Eine Zeitleiste der unendlichen Prägung
Die Zeitleiste des ersten Angreifers
- Neuer Balancer Liquiditätspool war hinzugefügt zum Blacksmith.sol Vertrag.
- Angreifer Ablagerungen 1,326,879.99 BPT-Token in den Blacksmith.sol-Vertrag.
- Der gleiche Angreifer dann wird ausgeführt den Exploit durch Abheben von Geldern aus dem Vertrag.
- Der Angreifer konnte fortsetzen Prämien prägen und Geld abheben in Höhe von rund 4.4 Mio. USD.
In einer interessanten Wendung der Ereignisse nutzten angebliche „weiße Hacker“, die mit Grap Finance in Verbindung stehen, den Fehler auch, um COVER-Token im Wert von etwa 4 Mio. USD zu prägen. Grap Finance gab die Mittel schließlich an das Cover Protocol zurück.
Zeitplan für das externe Konto von Grap Finance Deployer (EOA)
- Neuer Liquiditätspool war genehmigt für den Liquiditätsabbau.
- Grap Finance Deployer EOA hinterlegt 15,255.55 BPT (DAI / Basis) über den Blacksmith.sol-Vertrag in den Pool on Cover.
- Etwa vier Minuten später waren die Mittel zurückgezogen on Cover belässt 1 Wei im EOA-Guthaben des Grap Finance Deployer.
- Ein anderer externer Benutzer zog sich zurück Der größte Teil ihres Saldos stammte ungefähr zur gleichen Zeit aus dem Blacksmith.sol-Vertrag, der Grap Finance mit der gesamten Liquidität für den DAI / Basis-Pool des Blacksmith.sol-Vertrags führte.
- Grap Finance-Bereitsteller hinterlegt zurück 15,255.55 BPT (DAI / Basis) in den Pool.
- Dann Grap Finance Deployer aus aller Welt die Belohnungen und aufgrund des Exploits 40,796,131,214,802,500,000.21 COVER.
- Nach einigem Verbrennen der geprägten Token, Grap Finance Deployer sendet zurück Ether to Cover Angabe "Pass das nächste Mal auf deine eigene Scheiße auf."
Wie man unendliche Token prägt - Eine technische Analyse
Hintergrund
Dieser Exploit führt uns zurück zu den Grundlagen der Programmiersprache Solidity, die für die Implementierung intelligenter Verträge in Ethereum verwendet wird. Sobald diese Verträge kompiliert sind, kann die Ethereum Virtual Machine (EVM) die Anweisungen (dh Opcodes) verstehen, die zum Ausführen verschiedener Funktionen und zum Manipulieren von Speicher und Speicher verwendet werden. Das EVM verfügt über drei verschiedene Bereiche, in denen Daten gespeichert werden können: Speicher, Speicher und der Stapel. Das Verständnis dieser Bereiche ist wichtig, um zu verstehen, wie der Fehler ausgenutzt wurde.
Ähnlich wie bei einem Arbeitsspeicher (RAM) auf einem Computergerät ist der „ErinnerungDas Schlüsselwort ”in Solidity ordnet Speicher für eine bestimmte Variable zu. In diesem Fall ist diese Variable auf eine bestimmte Funktion beschränkt. Der Speicher wird gelöscht, sobald die Funktion ausgeführt wurde, kann jedoch verbleiben, wenn der Inhalt dieses Speichers vor der Rückkehr der Funktion in den Speicher verschoben wird.
Das "LagerungMit dem Schlüsselwort "Solidity" können Variablen als Zeiger auf die Speicherung von Daten in Zuordnungen oder Datenstrukturen fungieren. Speicherdaten bleiben zwischen Funktionsaufrufen und Transaktionen bestehen. Unter der Haube ist Speicher im Wesentlichen ein Schlüsselwertspeicher, der 256-Bit-Wörter 256-Bit-Wörtern zuordnet.
Beachten Sie, dass das EVM keine Registermaschine, sondern eine Stapelmaschine ist. Daher werden alle Berechnungen in einem aufgerufenen Datenbereich ausgeführt der Stapel. Der Stapel hat eine maximale Kapazität von 1024 Elementen, aber nur die oberen 16 sind leicht zugänglich, wodurch das oberste Element gegen eines der 16 Elemente darunter und mehr ausgetauscht werden kann.
Der Bug
Hacker nutzten Blacksmith.sol von Cover Protocol - einen Shield Mining-Vertrag, mit dem Staker in den Token des jeweiligen Projekts oder Pools wie CLAIM- und NOCLAIM-Token innerhalb von Cover Protocol belohnt werden können.
Um den Fehler besser zu verstehen, schauen wir uns zunächst die Öffentlichkeit an Schwimmbäder Variable, die eine Zuordnung ist (dh Speicherung von Daten):
At Linie 118sehen wir, dass der Vertrag die Pooldaten über das Schlüsselwort "memory" im Speicher zwischenspeichert.
Dann weiter Linie 121Der Vertrag aktualisiert den im Speicher befindlichen Pool als updatePool (Adresse _lpToken) Funktion verwendet ein Pool Speicher Pool variabel.
Wenn Sie jedoch weiter unten in die Einzahlung (Adresse _lpToken, uint256 _amount) Funktion verwendet es das gleiche Pool Variable aus Zeile 118, die innerhalb der Funktion für Berechnungen für gespeichert wurde pool.accRewardsPerToken. Zu diesem Zeitpunkt ist die Pool Variable wurde aus dem kopiert Schwimmbäder Mapping und wurde im Speicher gespeichert.
Infolgedessen werden alle am Pool Variable innerhalb der Einzahlung (Adresse _lpToken, uint256 _amount) Funktion wird die nicht ändern Schwimmbäder Zuordnung im On-Chain-Speicher des Vertrags, da Variablen, die das Schlüsselwort "memory" verwenden, nur innerhalb der Funktion selbst erfasst werden. Von dort aktualisiert der Vertrag die pool.accRewardsPerToken innerhalb der updatePool (Adresse _lpToken) Funktion, die Speicher verwendet. Also jetzt, innerhalb der updatePool (Adresse _lpToken) Funktion der pool.accRewardsPerToken das aktualisiert wird stark erhöht, da es technisch ein neuer Pool war und nicht mit dem verbunden ist Pool in Erinnerung.
Nach dieser Sicherheitsanfälligkeit und dem Missbrauch zwischen Speicher und Speicher wird die mineral.rewardWriteoff innerhalb der Einzahlung (Adresse _lpToken, uint256 _amount) Funktion ist falsch berechnet und verwendet die falsche pool.accRewardsPerToken, da wir uns noch innerhalb der Einzahlungsfunktion befinden, die eine zwischengespeicherte Speicherinstanz von verarbeitet Pool.
Zusätzlich zur Einzahlungsfunktion kann jeder, wie z. B. Grap Finance, eine verrückte Menge geprägter Token erhalten, wenn er die Einzahlungsfunktion ausführt ClaimRewards (Adresse _lpToken) Funktion. Diese Funktion, die verwendet wird, um ihre Belohnungen zu erhalten, ruft schließlich auf _claimCoverRewards (Poolspeicherpool, Miner Memory Miner) die verweist auf die mineral.rewardWriteoff das haben wir oben hervorgehoben. Da diese Variable viel kleiner als die tatsächliche ist pool.accRewardsPerTokenführt der Vertrag dazu, dass eine Fülle von Token geprägt wird.
Key Take Away
CipherTrace hofft, dass dieser Hintergrund des ausgenutzten Fehlers die Bedeutung gründlicher Sicherheitsüberprüfungen und der Prüfung intelligenter Verträge aufzeigt BlockchainEine Blockchain - die Technologie, die Bitcoin und anderen… Mehr man wählt zu implementieren. Während Grap Finance die durch den Exploit erhaltenen Mittel zurückgab, konnte der ursprüngliche Hacker immer noch über 4 Mio. USD aus dem DeFi-Protokoll abziehen, und der Wert des COVER-Tokens ist seitdem um fast 99% gesunken.
Quelle: https://ciphertrace.com/infinite-minting-exploit-nets-attacker-4-4m/