#6 Incidente do Protocolo Cork: Duas Falhas Independentes se Combinam em uma Devastadora Cadeia de Exploração

Em 28 de maio de 2025, o Protocolo Cork na Ethereum foi explorado [1], resultando em aproximadamente $12 milhões em perdas. A causa raiz foi uma combinação de manipulação de preço HIYA (Historical Implied Yield Average) no momento de expiração e controle de acesso ausente em um callback de hook do Uniswap v4. Como os prêmios de risco do HIYA crescem exponencialmente à medida que o tempo até o vencimento se aproxima de zero, swaps realizados nas fases finais inflaram o HIYA e fizeram com que mercados recém-inicializados subprecificassem severamente os Cover Tokens. Ao mesmo tempo, CorkHook.beforeSwap não tinha autenticação de msg.sender, permitindo chamadas arbitrárias com parâmetros manipulados. Ao explorar ambas as falhas, o atacante extraiu ~3.760e18 CT e DS e os resgatou por wstETH, drenando as reservas do protocolo.

0x1 Contexto

0x1.1 Tokenômica

O Protocolo Cork [2] introduz um novo primitivo para risco tokenizado, funcionando como uma camada de risco programável para ativos onchain, como tokens de vault, stablecoins com rendimento e tokens de liquid (re)staking. O componente fundamental é o Cork Pool, que é o mecanismo em torno do qual os mercados são construídos. Cada Cork Pool é construído em torno de um par de ativos: Redemption Asset (RA) e Pegged Asset (PA).

O Cork Pool recebe depósitos de Redemption Asset, que são bloqueados. Em troca, dois tokens são cunhados e devolvidos ao depositante: Depeg Swap (DS) e Cover Token (CT). Antes da data de expiração definida, 1 DS + 1 CT/PA pode ser trocado de volta por 1 RA; após a expiração, 1 CT pode ser resgatado proporcionalmente pelo RA + PA restantes no pool.

$$PA+DS=RAPA\; +\; DS\; =\; RA$$

$$CT+DS=RACT\; +\; DS\; =\; RA$$

0x1.2 Implementação do Contrato

Tanto DS quanto CT são negociáveis. Os usuários podem negociar CT e RA usando NormalSwap com base em uma curva AMM personalizada por meio do CorkHook, enquanto DS e RA são negociados usando FlashSwap via Router e CorkHook.

NormalSwap [Curva AMM personalizada]:

$$x^{1-t}{y}^t=kx^\{1-t\}\; y^\{t\}\; =\; k$$

FlashSwap [FlashSwapRouter.swapDsforRa]: Este mecanismo é central para o exploit. O atacante posteriormente aciona este caminho por meio de uma chamada direta e não autenticada ao beforeSwap (Seção 0x2.2).

1. O comprador transfere RA para o Router.

2. Na primeira chamada beforeSwap, o Router calcula a quantidade de DS a ser trocada. Se necessário, ele toma emprestado RA e CT do pool Uniswap v4, converte o CT emprestado e o DS do protocolo em RA, mantém o RA necessário e devolve o RA emprestado ao pool Uniswap.

3. Na segunda chamada beforeSwap, o Router decompõe RA em CT e DS via depositPsm, transfere todo o DS para o usuário, reembolsa o CT emprestado ao pool Uniswap e restitui qualquer CT excedente ao comprador.

Distribuição de Fundos Após a Emissão:

$$RA+CT:AMMRA+CT:\; AMM$$

$$DS:RouterDS:\; Router$$

0x1.3 Mecanismo de Precificação para Nova Emissão

O protocolo emprega o HIYA (Historical Implied Yield Average), calculado como a soma cumulativa do volume ($v_{T}v\_T$) × prêmio de risco ($r_{T}r\_T$), que serve para medir prêmios de risco e ajustar os preços de inicialização após a expiração. Se o HIYA for alto, o protocolo assume maior risco de depeg, resultando em uma precificação inicial de CT mais baixa.

$CumulativeHIYA={\sum }_T{r}_T{v}_{T}Cumulative\backslash \; HIYA\; =\; \backslash sum\_T\; r\_T\; v\_T$

O cálculo do prêmio de risco ($r_{T}r\_T$) consiste em dois componentes: preços altos de CT correlacionam-se com valores baixos de rt (o que é intuitivo), e o tempo de expiração T tem um efeito de amplificação exponencial. Perto da expiração, T se aproxima de zero, fazendo com que o expoente $1\mathrm{/}T1/T$ cresça rapidamente. Isso amplifica até pequenas variações no preço do CT em grandes valores de prêmio de risco.

$$r_T=(F\mathrm{/}{p}_T{)}^{1\mathrm{/}T}-1r\_T\; =\; (F\; /\; p\_T)^\{1/T\}\; -\; 1$$

• $FF$ é 1

• $P_{T}P\_T$ é o preço do CT

• $TT$ é o tempo até o vencimento normalizado entre 1-0

Para ilustrar a amplificação: se CT é negociado a $p_T=0,95p\_T\; =\; 0,95$ (um desconto de 5%), o prêmio de risco em $T=0,5T\; =\; 0,5$ (metade do caminho até a expiração) é:

$$r_{0.5}=(1\mathrm{/}0.95{)}^{1\mathrm{/}0.5}-1=(1.053{)}^2-1\approx 0.108r\_\{0.5\}\; =\; (1/0.95)^\{1/0.5\}\; -\; 1\; =\; (1.053)^\{2\}\; -\; 1\; \backslash approx\; 0.108$$

Em $T=0,01T\; =\; 0,01$ (perto da expiração), o mesmo preço de CT produz:

$$r_{0.01}=(1\mathrm{/}0.95{)}^{1\mathrm{/}0.01}-1=(1.053{)}^{100}-1\approx 167r\_\{0.01\}\; =\; (1/0.95)^\{1/0.01\}\; -\; 1\; =\; (1.053)^\{100\}\; -\; 1\; \backslash approx\; 167$$

O mesmo desconto de 5% no CT gera um prêmio de risco ~1.500x maior perto da expiração. Essa sensibilidade exponencial é o vetor de manipulação: um swap executado pouco antes da expiração infla o HIYA de forma desproporcional, distorcendo o preço de inicialização do próximo mercado.

0x2 Análise de Vulnerabilidade

O mercado afetado envolve os seguintes tokens:

Para maior clareza, o restante deste relatório se refere aos tokens por seus papéis abstratos (RA, DS, CT) em vez de seus nomes concretos, exceto quando a distinção for relevante.

O atacante extraiu tanto DS quanto CT do AMM e do Router usando dois métodos distintos. Como DS + CT podem ser resgatados por RA, obter ambos permite a extração direta de lucro. O ataque consiste em dois componentes.

0x2.1 Extração de Cover Token: Manipulação do HIYA Levando a Preços de Inicialização de Mercado Artificialmente Baixos

Quando um período de mercado expira, o protocolo inicializa o próximo período usando accumulatedHIYA do período anterior para definir a proporção de preço CT/RA no AMM. Um HIYA mais alto sinaliza maior risco percebido de depeg, o que se traduz em um preço inicial de CT mais baixo.

Como o HIYA é atualizado a cada swap e incorpora prêmios de risco (Seção 0x1.3), e como os prêmios de risco crescem exponencialmente quando $T\to 0T\; \backslash to\; 0$, swaps executados pouco antes da expiração inflam o accumulatedHIYA em ordens de magnitude. O atacante explorou isso chamando SwapRaForDs() perto da expiração, gerando um grande prêmio de risco que se acumulou no HIYA.

Quando o novo período de mercado foi subsequentemente inicializado, o protocolo leu o HIYA inflado, interpretou-o como risco extremo de depeg e definiu o preço inicial de CT no AMM muito abaixo de seu valor justo. O atacante então trocou RA por CT nesse preço distorcido, adquirindo uma grande posição em CT de forma barata.

0x2.2 Extração de Depeg Swap: Controle de Acesso Ausente em CorkHook.beforeSwap

No design padrão de hooks do Uniswap v4, beforeSwap é chamado exclusivamente pelo PoolManager durante um swap. A implementação do Cork não aplicou essa restrição:

// Ausente: require(msg.sender == address(poolManager));
function beforeSwap(
    address sender,
    PoolKey calldata key,
    IPoolManager.SwapParams calldata params,
    bytes calldata hookData
) external override returns (bytes4, BeforeSwapDelta, uint24) {
    ...
}

Sem essa verificação, qualquer contrato externo pode chamar beforeSwap diretamente com hookData arbitrário. Quando hookData é não vazio, a função entra no caminho de execução do FlashSwap (Seção 0x1.2), que decompõe RA em CT e DS via depositPsm. O atacante explorou isso invocando beforeSwap diretamente com hookData manipulado que especificava os tokens de um mercado falso, fazendo com que o protocolo decompusesse tokens e transferisse os resultados para o atacante.

0x2.3 Como as Duas Falhas se Combinam

Nenhuma vulnerabilidade sozinha é suficiente para extrair os $12 milhões completos.

A manipulação do HIYA dá ao atacante CT barato, mas o CT sozinho não pode ser resgatado por RA. A fórmula de resgate requer ambos os tokens: CT + DS = RA. O atacante ainda precisa de uma forma de obter DS.

O controle de acesso ausente em beforeSwap fornece esse caminho. Ao chamar beforeSwap diretamente com hookData manipulado, o atacante pode acionar o caminho de decomposição do FlashSwap com parâmetros arbitrários. Para obter DS real por esse caminho, o atacante implanta um mercado falso que designa o DS real como seu RA, e então chama beforeSwap para decompor esse "RA" (DS real) em CT falso e DS falso, que podem ser trocados de volta por DS real por meio do mercado falso.

Com tanto CT (da manipulação do HIYA) quanto DS (da chamada não autenticada ao beforeSwap via mercado falso) em mãos, o atacante os resgata 1:1 por RA (wstETH).

0x3 Análise do Ataque

O ataque se desdobra em três transações, cada uma correspondendo a uma fase: inflar o HIYA, adquirir CT barato e extrair DS para completar o par de resgate.

0x3.1 Preparação: Inflando o HIYA

Nesta transação, o atacante chamou SwapRaForDs() pouco antes da expiração do mercado. Como $TT$ estava perto de zero, este swap gerou um prêmio de risco desproporcionalmente grande (Seção 0x1.3), inflando o accumulatedHIYA.

O que o atacante possui após esta fase: DS do swap (usado posteriormente na Fase 0x3.3) e um accumulatedHIYA inflado armazenado na blockchain.

0x3.2 Inicialização: Adquirindo CT Barato

Nesta transação, o novo período de mercado foi inicializado. O protocolo leu o accumulatedHIYA inflado e definiu uma proporção de preço CT/RA distorcida no AMM, precificando CT muito abaixo do valor justo. O atacante então trocou ~0,000003e18 RA por 3.760e18 CT a esse preço deflacionado.

O que o atacante possui após esta fase: uma grande posição em CT (adquirida de forma barata via preço de inicialização manipulado).

0x3.3 Extração: Obtendo DS via Mercado Falso

Esta fase usa a vulnerabilidade de controle de acesso (Seção 0x2.2) para extrair DS, completando o par CT + DS necessário para o resgate de RA. A técnica central é um mercado falso que trata o DS real como seu ativo de resgate:

As etapas principais da transação do ataque:

1. O atacante primeiro trocou RA por DS no mercado legítimo.

   O que o atacante possui: DS real.

2. O atacante implantou e inicializou o mercado falso, designando o DS real como RA falso.

   

3. O atacante invocou beforeSwap diretamente (explorando o controle de acesso ausente) com hookData não vazio, acionando o caminho de execução do FlashSwap contra o mercado falso. Dentro do hookData, o atacante especificou paymentToken como CT falso, fazendo com que o protocolo executasse a lógica de decomposição de RA contra o mercado falso.

   

4. O protocolo decompôs todo o RA falso (ou seja, DS real) em CT falso e DS falso. Toda a porção de DS falso foi transferida para o atacante, e a porção de CT falso (menos um paymentAmount mínimo) foi reembolsada.

   O que o atacante possui: 3.761e18 CT falso + 3.761e18 DS falso (ambos derivados do DS real).

5. O atacante trocou CT falso e DS falso de volta para RA falso dentro do mercado falso, recuperando o DS real.

   O que o atacante possui: 3.761e18 DS real (recuperado).

6. O atacante combinou o DS recuperado com o CT obtido na Seção 0x3.2 para resgatar RA (wstETH), completando a extração do lucro.

   O que o atacante possui: lucro de 3.760e18 RA (wstETH) (ou seja, $12M).

Resumo

Este incidente combinou duas falhas independentes, nenhuma delas suficiente por conta própria, em uma única cadeia de exploit que drenou $12 milhões do protocolo.

• Prêmio de risco exponencial perto da expiração. A fórmula de precificação do HIYA amplifica os prêmios de risco à medida que o tempo até o vencimento se aproxima de zero, tornando os swaps nas fases finais um vetor de manipulação para os preços de reinicialização do mercado.
• Validação de remetente ausente nos callbacks de hook. CorkHook.beforeSwap não verificava se msg.sender era o PoolManager, permitindo invocação direta com parâmetros arbitrários e possibilitando ao atacante falsificar o caminho de execução do FlashSwap.
• Interação entre módulos como ponto cego. O design econômico (precificação baseada em HIYA) e a lacuna de controle de acesso (callback de hook não autenticado) residiam em módulos separados. Sua interação criou um caminho explorável que análises de módulo único dificilmente detectariam.

Referência

1. https://www.cork.tech/blog/post-mortem

2. https://docs.cork.tech/core-concepts/cork-pool

Sobre a BlockSec

A BlockSec é uma provedora completa de segurança em blockchain e conformidade em criptomoedas. Desenvolvemos produtos e serviços que ajudam nossos clientes a realizar auditorias de código (incluindo contratos inteligentes, blockchain e carteiras), interceptar ataques em tempo real, analisar incidentes, rastrear fundos ilícitos e cumprir obrigações de AML/CFT, ao longo de todo o ciclo de vida de protocolos e plataformas.

A BlockSec publicou múltiplos artigos de segurança em blockchain em conferências de prestígio, reportou vários ataques de dia zero em aplicações DeFi, bloqueou múltiplos hacks para resgatar mais de 20 milhões de dólares e protegeu bilhões em criptomoedas.

• Site oficial: https://blocksec.com/

• Conta oficial no Twitter: https://twitter.com/BlockSecTeam

• 🔗 Serviço de Auditoria BlockSec : Envie uma solicitação

• 🔗 Phalcon Security APP: Agende uma demonstração

• 🔗 Phalcon Compliance