Este artigo foi compilado e traduzido pela BlockWeeks
A plataforma Ostium foi explorada por um atacante, resultando no roubo de aproximadamente US$ 24 milhões em USDC, envolvendo oito transações. O atacante, ao deter simultaneamente as chaves de assinatura dos oráculos autorizados e o papel de PriceUpKeep keeper, submeteu relatórios de preços assinados corretamente para datas futuras, e repetidamente abriu e fechou pares de negociação, criando lucros falsos sem qualquer exposição real ao mercado.
O ataque ocorreu em oito transações, com cada fundo transferido para a mesma carteira 0x321Df1…8bfD9, sendo a maior transferência única uma operação cíclica de abertura e fechamento de posições executada em um lote atômico. A Ostium opera na Arbitrum, permitindo que os usuários negociem derivativos na forma de contratos a termo que rastreiam o preço do ativo subjacente, mas sem entrega do ativo subjacente ou data de vencimento fixa.
O problema decorre de como o sistema de oráculos da Ostium autoriza os dados de preço. O validador recebe o relatório de preço, deriva a identidade do assinante a partir da assinatura e verifica se o assinante está na lista autorizada. Ele apenas valida a identidade do assinante, não a precisão do preço em si. O atacante, detendo simultaneamente as chaves de assinatura dos oráculos autorizados e o papel registrado de PriceUpKeep keeper (responsável por executar ordens pendentes), usou essa combinação para submeter relatórios de preços assinados corretamente para datas futuras, e então repetidamente abriu e fechou pares de negociação que se protegiam mutuamente. Isso permitiu que eles gerassem lucros comerciais do ponto de vista do sistema, sem qualquer exposição real ao mercado.
O incidente da Ostium é um dos vários exploits significativos em nível de aplicação este ano, incluindo os casos da Drift e do rsETH da KelpDAO. Um tema comum é que os contratos inteligentes e sua lógica permanecem robustos, e os atacantes visam principalmente a infraestrutura operacional e a confiança humana — no caso da Ostium, credenciais de assinante adulteradas; no caso da Drift, uma tomada de controle administrativo pré-assinada por engenharia social; e no caso da KelpDAO, infraestrutura RPC envenenada.
Após esses exploits de alto perfil, alguns pedem salvaguardas em nível de aplicação sobre os fundos dos usuários, como restrições de retirada, para dissuadir atores maliciosos e limitar perdas quando ocorrem exploits. Tais sugestões devem ser resistidas.
Restringir retiradas introduziria um risco direto de censura em nível de aplicação. Uma vez que um protocolo possa unilateralmente atrasar ou restringir depósitos ou retiradas de usuários, o conceito de autocustódia nesse nível de aplicação não seria mais absoluto, mas condicional. Nesse caso, quem decide a disponibilidade e o uso dos fundos é a aplicação, não o usuário. Essa prática também borraria a linha entre atacantes e usuários comuns, pois as salvaguardas projetadas para impedir ataques inevitavelmente se aplicariam a todos os usuários da aplicação.
O risco do "efeito de ladeira escorregadia" agrava ainda mais esse problema. Uma vez que um protocolo tenha a capacidade técnica de restringir ou congelar depósitos/retiradas, essa capacidade se tornaria um precedente. Reguladores poderiam citar isso como evidência de que essas aplicações já possuem as ferramentas para cumprir ordens de congelamento, portas de KYC ou outros requisitos, e portanto também deveriam ser obrigadas a fazê-lo. Salvaguardas construídas para impedir ataques podem se tornar um gancho que puxa os protocolos para obrigações que eles não poderiam assumir de outra forma.
Além disso, participantes inocentes do mercado também seriam incentivados a contornar o atrito causado por tais medidas. Por exemplo, usuários restritos que buscam maneiras de sair da exposição econômica geralmente significam o surgimento de um objeto de reivindicação negociável para preencher a lacuna (como tokens de recibo, IOUs, substitutos embrulhados de criptomoedas). Essa reivindicação em si se torna uma nova dependência, com seu próprio perfil de risco — no nível de mercado (âncoras que podem quebrar, descontos que se ampliam durante pânicos) e no nível técnico (novos contratos, novos oráculos, novas entidades exploráveis independentes da aplicação). Salvaguardas destinadas a conter um ponto único de falha acabam exacerbando a fragilidade que tentam prevenir.
Tal conteúdo não significa que os protocolos não devam fortalecer o que realmente falhou (como gerenciamento de chaves de assinatura, redundância de validadores). Mas a maneira de corrigir fraquezas na infraestrutura operacional e na confiança humana é fortalecendo esses aspectos, não adicionando controle arbitrário sobre os fundos dos usuários, o que enfraqueceria a proposta de valor central da coisa que está sendo protegida.
