Kako ubežati pametnim pogodbam pred napadi ponovnega vstopa?

Čas branja: 6 min

Če si podrobneje ogledamo največje kriptovalute in osupljive številke, ki so jih izgubili, bi bili globoko zakoreninjeni zaradi napak v kodiranju.

Eden takšnih pogostih pojavov varnostne ranljivosti je napad ponovnega vstopa. Vendar pa uničujoč učinek, ki ga povzroči napačno ravnanje ponovnega vstopa, morda ne zveni tako preprosto kot začetek samega napada.

Kljub temu, da je težava znana in dobro oglaševana, je pojav hrošča ponovnega vstopa v pametnih pogodbah vedno neizogiben. 

Kako pogosto so hekerji v preteklih letih izkoristili ranljivost ponovnega vstopa? Kako deluje? Kako preprečiti, da bi pametne pogodbe izgubile sredstva zaradi napak pri ponovnem vstopu? Poiščite odgovore na ta vprašanja v tem blogu.

Torej, kmalu se spomnimo največjih napadov ponovnega vstopa v spomin. 

Nekaj ​​najbolj zloglasnih vdorov za ponovni vstop v realnem času 

Napadi ponovnega vstopa, ki so povzročili najbolj uničujoče učinke na projekte, so na koncu povzročili enega od teh dveh ali celo oba. 

• Popolnoma izčrpajte eter iz pametnih pogodb
• Hekerji se prikradejo v kodo pametne pogodbe

Zdaj lahko opazimo nekaj primerov napadov ponovnega vstopa in njihov učinek. 

Junij 2016: DAO napad – 3.54 milijona ali 150 milijonov dolarjev etra

april 2020: Vdor v Uniswap/Lendf.Me – 25 milijonov $

Lahko 2021: Vdor v BurgerSwap – 7.2 milijona $

2021. avgust: Vdor v CREAM FINANCE – 18.8 milijona $

marec 2022: Ola Finance – 3.6 milijona dolarjev

julij 2022: Protokol OMNI – 1.43 milijona USD

Kristalno jasno je, da napadi ponovnega vstopa nikoli niso šli iz mode. Poglobimo se v to v naslednjih odlomkih. 

Pregled napadov ponovnega vstopa

Kot iz imena "Reentrancy", ki pomeni "ponovno vstopanje znova in znova." Napad ponovnega vstopa vključuje dve pogodbi: pogodbo žrtve in pogodbo napadalca. 

Pogodba napadalca izkorišča ranljivost ponovnega vstopa v pogodbi žrtve. Za dosego tega uporablja funkcijo umika. 

Napadalčeva pogodba pokliče funkcijo dviga, da izčrpa sredstva iz žrtvine pogodbe s ponavljajočimi se klici, preden se posodobi stanje v žrtvi pogodbi. Pogodba žrtve bo preverila stanje, poslala sredstva in posodobila stanje. 

Toda v časovnem okviru pošiljanja sredstev in posodabljanja stanja v pogodbi, napadalec izvede neprekinjen poziv za dvig sredstev. Posledično se stanje v pogodbi žrtve ne posodobi, dokler napadalčeva pogodba ne izčrpa vseh sredstev.

Resnost in stroški izkoriščanja ponovnega vstopa opozarjajo na nujno potrebo po izvajanju revizije pametnih pogodb da bi izključili možnost spregledanja takšnih napak. 

Ilustrativni pogled napada ponovnega vstopa

Oglejmo si koncept napada ponovnega vstopa iz spodnje poenostavljene ilustracije. 

Tu sta dve pogodbi: ranljiva pogodba in pogodba Heker

Hekerska pogodba poziva k odstopu od ranljive pogodbe. Ob prejemu klica ranljiva pogodba preveri sredstva v hekerski pogodbi in nato sredstva nakaže hekerju. 

Heker prejme sredstva in izvede nadomestno funkcijo, ki znova pokliče v ranljivo pogodbo, še preden se posodobi stanje v ranljivi pogodbi. Tako heker s ponavljanjem iste operacije popolnoma umakne sredstva iz ranljive pogodbe. 

Značilnosti nadomestne funkcije, ki jo uporablja napadalec 

• Zunanje so klicne. Ni jih mogoče priklicati iz pogodbe, v kateri so napisani
• Neimenovana funkcija
• Nadomestna funkcija v sebi ne vključuje poljubne logike
• Nadomestna vrednost se sproži, ko je ETH poslan v pametno pogodbo, ki jo obdaja, in ni deklarirana nobena funkcija receive().

Analiza ponovnega vstopnega napada s tehničnega vidika 

Vzemimo vzorec pogodbe in razumemo, kako pride do napada ponovnega vstopa.

Zlonamerna pogodba

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();
    }


}

To je napadalčeva pogodba, v kateri napadalec položi 2ETH. Napadalec pokliče funkcijo umika v ranljivi pogodbi. Ko so sredstva prejeta iz ranljive pogodbe, se sproži nadomestna funkcija. 

Nadomestni vir nato izvede funkcijo dviga in črpa sklad iz ranljive pogodbe. Ta cikel se nadaljuje, dokler niso popolnoma izčrpana sredstva iz ranljive pogodbe.

Ranljiva pogodba

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;
    }


}

Ranljiva pogodba ima 30 ETH. V tem primeru funkcija reject() pošlje zahtevani znesek napadalcu. Ker se stanje ne posodablja, se žetoni večkrat prenesejo na napadalca. 

Vrste napadov ponovnega vstopa

• Ponovni vstop z eno samo funkcijo 

function withdraw() external {
   uint256 amount = balances[msg.sender];
   require(msg.sender.call.value(amount)());
   balances[msg.sender] = 0;
}

msg.sender.call.value(amount)() prenese sredstva, potem pa nadomestna funkcija pogodbenega napadalca znova pokliče reject(), preden se stanje [msg.sender] = 0 posodobi.

• Ponovni vstop med funkcijami

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;
}

Ponovni vstop med funkcijami je veliko bolj zapleten za prepoznavanje. Razlika tukaj je v tem, da nadomestna funkcija kliče prenos, za razliko od ponovnega vstopa z eno funkcijo, kjer kliče odvzem.

Preprečevanje vnovičnih napadov

Vzorec preverjanja-učinki-interakcije: Vzorec preverjanja-učinki-interakcije pomaga pri strukturiranju funkcij. 

Program mora biti kodiran tako, da najprej preveri pogoje. Ko so preverjanja opravljena, je treba razrešiti vplive na stanje pogodb, nato pa je mogoče priklicati zunanje funkcije. 

function withdraw() external {
   uint256 amount = balances[msg.sender];
   balances[msg.sender] = 0;
   require(msg.sender.call.value(amount)());
}

Tukaj prepisana koda sledi vzorcu preverjanje-učinki-interakcije. Tu se stanje pred zunanjim klicem postavi na nič. 

Uporaba modifikatorja

Modifikator noReentrant, uporabljen za funkcijo, zagotavlja, da ni klicev za ponovni vstop. 

contract ReEntrancyGuard {
    bool internal locked;

    modifier noReentrant() {
        require(!locked, "No re-entrancy");
        locked = true;
        _;
        locked = false;
    }
}

Na koncu

Najučinkovitejši korak je, da se odločite za revizije pametnih pogodb pri vodilnem varnostnem podjetju, kot je QuillAudits, pri čemer revizorji pozorno spremljajo strukturo kode in preverjajo, kako deluje rezervna funkcija. Na podlagi preučenih vzorcev so podana priporočila za prestrukturiranje kode, če se zdi, da obstaja ranljivo vedenje. 

Varnost sredstev je zagotovljena tik preden postane žrtev kakršne koli izgube. 

Pogosta vprašanja

Kaj je napad ponovnega vstopa?

Napad ponovnega vstopa se zgodi, ko funkcija v ranljivi pogodbi pokliče nezaupljivo pogodbo. Nezaupanja vredna pogodba bo napadalčeva pogodba, ki izvaja rekurzivne klice ranljive pogodbe, dokler se sredstva popolnoma ne izčrpajo. 

Kaj je ponovni vstop?

Dejanje ponovnega vnosa pomeni prekinitev izvajanja kode in zagon postopka znova, kar je znano tudi kot ponovni vnos.

Kaj je zaščita pred vstopom?

Zaščita pred ponovnim vstopom uporablja modifikator, ki preprečuje ponavljajoče se klice funkcije. Preberite zgornji spletni dnevnik, če želite poiskati primer za zaščito pred ponovnim vstopom.

Kateri so nekateri napadi na pametne pogodbe?

Pametne pogodbe so izpostavljene številnim ranljivostim, kot so ponovni vstop, odvisnost od časovnega žiga, aritmetični prelivi, napadi DoS itd. Zato je revizija nujna, da se zagotovi, da ni napak, ki bi porušile logiko pogodbe.

69 Ogledov