jakiro
Quelle: Sharkteam
Am 30. Januar 2024 wurde MIM_SPELL durch Blitzdarlehen angegriffen.
Sharkteam führte so bald wie möglich eine technische Analyse des Vorfalls durch und fasste die Mittel der Sicherheitsvorkehrungen zusammen.
1. Analyse der Transaktionsanalyse
Angriffsadresse:
0x87f585809ce79ae39A5FA0C7C96D0D159EB678C9
Angriffsvertrag:
0xE1091D17473B049CCCD65C54F71677DA85B77A45
0x13AF445F81B0DECA5DCB2BE6C691F545C95912
0xe59B54A9E37AB69F6E9312A9B3F7253EE184E5A
Vertrag angegriffen werden:
0x7259e152103756e1616a77ae982353c3751a6a90
Angriffstransaktion:
0x26a83db7e288838dd9fee6fb7314ae58dcc6aee9A20BF224C386FF5E80F7E4CF2
0xDB4616B89AD82062787A4E924D520639791302476484B9A6ECA5126F79B6D8777
Angriffsprozess:
1. Der Angreifer (0x87F58580) hat 300.000 MIM -Token durch Blitzdarlehen geliehen.
2. Senden Sie dann 2.40.000 MIM -Token an den angegriffenen Vertrag (0x7259e1520) für den nächsten Schritt, um die Kreditaufnahme von Benutzern zurückzuzahlen.
3. Der Angreifer (0x87F58580) bezeichnete dann die Rückzahlungsfunktion, um die Ausleihe anderer Benutzer zurückzuzahlen, und bezeichnete dann die Rückzahlungsfunktion, um die Ausleihe anderer Benutzer in der Reihenfolge zurückzuzahlen.
V.
5. Nachfolgender Angreifer (0x87F58580) ruft die Abzugsfunktion der Kreditfunktion auf und DEGENBOX -Vertrag entlehnt 5000047 MIM -Token.
6. Der Angreifer (0x87F58580) gab die Blitzdarlehensfunktion zurück und wandelte 4400.000 MIM -Token in 1807 ETH um, und diese Transaktion erzielte einen Gewinn von etwa 450 W.
Zweitens Analyse der Verwundbarkeit
Die Essenz des Angriffs ist, dass die Genauigkeit der Kreditvariablen berechnet wird, so dass der Anteil der wichtigsten elastischen und basischen Werte von Schlüsselvariablen unausgeglichen ist, was zu Problemen bei der Berechnung der Anzahl der Hypotheken und Kreditaufnahmen führt und schließlich MIM -Token entlehnt wird.
Die Ausleihefunktion und die Rückzahlungsfunktion im angegriffenen Vertrag (0x7259e1520) verwenden die Aufwärtsmethode, um die beiden Variablen von Elastiz und Basis zu berechnen.
Der Angreifer (0x87F58580) hat zuerst die elastischen Variablen und Basisvariablen auf 0 und 97 gesetzt, indem Sie andere Benutzerausleihen zurückzahlen.
Anschließend werden die Ausleihefunktion und die Rückzahlungsfunktion kontinuierlich aufgerufen und der Parameterbetrag 1. Wenn die Ausleihefunktion zuerst die Ausleihefunktion aufruft, wird die oben genannte Logik ausgeführt und an die Funktion hinzufügen, wenn elastic = 0 ist.Dies führt zu GLASTIC = 1, Basis = 98.
Der Angreifer (0x87F58580) ruft dann die Ausleihefunktion auf und übergab in 1. Da elastic = 1 sonst eine Logik ausführt, beträgt der berechnete Returnwert 98. Bei der Rückkehr zur Funktion add add, elastic = 2, beträgt die Basisvariable 196.
Zu diesem Zeitpunkt rief der Angreifer (0x87F58580) die Rückzahlungsfunktion an und übergab in 1. Da elastic = 2 die else -Logik ausgeführt wird, führt dies zu dem berechneten Rückgabewert 1, sodass bei der Rückkehr zur Subfunktion die Elastizität der Elastizität zurückkehrt. Variable Änderung zurück 1 und die Basisvariable ist 195.
Es ist ersichtlich, dass die elastischen Variablen nach dem Erleben der Ausleihen-Repay-Schleife unverändert bleiben und die Basisvariable fast verdoppelt wird. Schließlich elastisch machen = 0 Basis = 120080183810681886665215049728.
Wenn der Anteil zwischen elastischen und Basisvariablen ein ernstes Ungleichgewicht ist, kann der Angreifer (0x87F58580) mit etwas Hypothek hinzugefügt werden, um eine große Anzahl von MIM -Token durch die Einschränkungen des Lösungsmittelmodifikators auszuleihen.
3. Sicherheitsvorschlag
Als Reaktion auf diesen Angriff sollten wir die folgenden Vorsichtsmaßnahmen während des Entwicklungsprozesses einhalten:
1. Bei der Berechnung der relevanten Logik der Entwicklungsgenauigkeit berücksichtigen Sie sorgfältig die Genauigkeit und die gesamte Situation.
2. Bevor das Projekt gestartet wird, muss ein professionelles Audit -Team von Dritt -Party -Audit intelligente Vertragsprüfungen durchführen.
