A BTCVN4 está com uma sensação nada boa.
Em 31/8, o Injective sofreu um exploit que causou danos de cerca de 4,9 milhões de USD. Inicialmente, o incidente foi descrito como um ataque direcionado a algumas aplicações de Binary Options no ecossistema.
No entanto, um relatório de análise de 3/9 levanta um problema ainda mais sério:
👉 A vulnerabilidade pode ter interagido com módulos nativos/core do próprio Injective, em vez de estar apenas em um aplicativo externo de Binary Options.
E é a este ponto que os titulares de INJ precisam prestar atenção especial.
1. Colisão de ID de mercado: o ponto de partida da exploração.
De acordo com a análise on-chain, o atacante explorou uma vulnerabilidade relacionada à forma como a Injective gera o ID de mercado.
O ID de mercado é formado a partir de vários campos de dados, tais como:
• Tipo Oracle
• Ticker
• Citação do valor
• Símbolo do oráculo
• Fornecedor Oracle
O problema reside na forma como esses campos são agrupados sem um mecanismo de separação/comprimento suficientemente claro.
Teoricamente, isso poderia criar a seguinte situação:
Duas configurações de mercado diferentes → geram o mesmo ID de mercado.
Os atacantes exploraram essa capacidade para criar mercados de opções binárias com estrutura especial e, em seguida, interagiram com a lógica de liquidação/reembolso.
Relatos sugerem que o atacante criou aproximadamente 299 mercados em cerca de 19 horas e, por fim, retirou cerca de US$ 4,9 milhões.
2. Mas a questão mais importante é: onde reside a culpa?
Esta é a parte que merece destaque.
A Injetive afirmou que:
• O consenso não é comprometido
• O INJ nativo não é afetado
• O INJ estacado continua seguro
• O problema afeta apenas determinados aplicativos que usam opções binárias.
Esta é uma boa notícia para os portadores de INJ.
Mas algumas análises independentes sugerem que a história é mais complexa.
Segundo o pesquisador Earthling Paddy, a vulnerabilidade está relacionada aos módulos nativos de câmbio e seguro da Injective.
Em outras palavras:
As opções binárias podem ser a "porta de entrada" usada por um atacante, mas a lógica explorada reside em camadas mais profundas dos módulos do protocolo.
Essa é uma diferença extremamente importante.
Se a vulnerabilidade estiver contida em um único contrato inteligente/aplicativo, o escopo do risco é relativamente restrito.
Mas se o aplicativo puder acionar lógica incorreta dentro dos módulos de protocolo nativos, então o problema se torna:
O ataque ocorre na camada de aplicação, mas a superfície de ataque está na camada de protocolo.
🔴 3. A evidência mais notável: correções de emergência na lógica principal
Um dos detalhes que mais chamou a atenção da BTCVN4 foi a atualização de emergência:
v1.20.3-safeharbor.1
Esta versão está sendo implementada na rede principal da Injective como parte de um processo de resolução de problemas.
De acordo com relatórios analíticos, a atualização implementou mudanças notáveis, tais como:
✅ Adicione um cheque de valor nominal ao fundo de seguro.
✅ Desative a liquidação de opções binárias na rede principal.
Vale ressaltar que essas mudanças estão dentro do código principal do blockchain.
Portanto, surge a seguinte questão lógica:
Se o problema reside inteiramente em um aplicativo externo de Opções Binárias, por que uma correção emergencial precisaria solucionar a lógica na camada de protocolo/núcleo?
Isso ainda não é evidência suficiente para concluir que o consenso injetivo ou o INJ nativo foram comprometidos.
Mas é um indício suficientemente forte de que não devemos simplesmente descartar o incidente como "um aplicativo externo hackeado".
4. A corrente representa realmente uma "parada" ou apenas uma melhoria emergencial?
Este também é um ponto de discórdia.
A Injective descreve o evento como uma atualização acelerada da rede, ao mesmo tempo que afirma que a blockchain e o consenso permanecem seguros.
No entanto, dados on-chain analisados por alguns pesquisadores mostram que houve aproximadamente 3 horas e 42 minutos sem que um novo bloco aparecesse durante o período em que os validadores estavam implementando a atualização de emergência.
Alguns validadores chegaram a ser presos por não concluírem a atualização dentro do prazo estipulado.
Portanto, tecnicamente, existe uma diferença entre:
“O consenso foi comprometido” e “a produção de blocos foi interrompida para implantar uma correção de emergência”.
Essas duas coisas não são a mesma coisa.
Atualmente, os dados corroboram a conclusão de que o consenso não foi comprometido pelo atacante, mas a rede sofreu interrupções significativas durante a resposta ao incidente.
5. O que JÁ sabemos?
Atualmente, existem alguns pontos que são relativamente claros:
1️⃣ Aproximadamente US$ 4,9 milhões foram desviados.
2️⃣ Attacker đã sử dụng market-ID collision trong Binary Options settlement logic.
3️⃣ De acordo com relatos publicados, acredita-se que aproximadamente 1.980 ETH foram transferidos para o Ethereum e permanecem no endereço associado ao incidente.
4️⃣ A Injective lançou a versão de emergência v1.20.3-safeharbor.1.
5️⃣ A liquidação de opções binárias foi desativada na rede principal.
6️⃣ A lógica dos fundos de seguros agora inclui cheques com denominações diferentes.
7️⃣ A declaração injetiva confirma o consenso, e o INJ nativo e os ativos em staking não estão sujeitos a comprometimento.
Esses pontos indicam que a exploração foi contida relativamente rápido e o dano não se propagou para um ataque à camada de consenso.
6. Mas que perguntas permanecem sem resposta?
Esta é a parte que a BTCVN4 acredita que os detentores de INJ precisam monitorar de perto.
❓ O que exatamente é um caminho de ataque?
❓ Com quais módulos houve interação de colisão com o Market-ID?
❓ Por que um bug originado em Opções Binárias exige a correção da lógica central do protocolo?
❓ Qual foi o prejuízo total final?
❓ Quem é realmente o responsável pelo déficit de aproximadamente US$ 4,9 milhões?
❓ O dinheiro desviado pode ser recuperado?
❓ Existem outras variações da mesma classe de vulnerabilidade?
❓ Existem outros módulos nativos que utilizam lógica de ID de mercado semelhante e que precisam ser auditados?
E, mais importante ainda:
O Injective verificou toda a superfície de ataque dos módulos nativos ou bloqueou apenas o vetor de opções binárias?
Uma análise técnica completa seria crucial para responder a essas perguntas.
Os relatórios atuais indicam que a Injective ainda não divulgou um documento técnico completo de análise pós-mortem, descrevendo todo o processo de execução e a alocação de danos.
7. Então, como os titulares de INJ devem entender essa situação?
Na minha opinião, é muito cedo para concluir que a Injective sofreu um "comprometimento fundamental".
Porque atualmente não existem evidências que sugiram que:
O consenso está sob o controle do atacante.
A moeda Native INJ foi cunhada ilegalmente.
O dispositivo INJ foi roubado.
O conjunto de validadores foi comprometido por um atacante.
Mas, ao mesmo tempo, o incidente não deve ser encarado com leviandade.
Porque, se os relatos de colisão de ID de mercado e interação com o módulo principal forem confirmados na análise posterior, a natureza do incidente seria significativamente mais grave do que um contrato inteligente de Opções Binárias com defeito.
Isso mostrará:
Uma aplicação pode acionar lógica perigosa localizada em módulos de protocolo nativos.
É um problema na arquitetura de segurança do protocolo, e não simplesmente um bug em um único aplicativo descentralizado (dApp).
A PERSPECTIVA DE BTCVN4
Acredito que atualmente existem duas camadas de informação que precisam ser separadas:
1º andar – Boas notícias:
O injetor conteve com sucesso a vulnerabilidade, o consenso não foi comprometido com base nas informações disponíveis, e o INJ nativo e o staking permaneceram protegidos.
Nível 2 – Riscos a monitorar:
Se as colisões de ID de mercado realmente se originam ou podem afetar módulos nativos de corretoras/seguros, então precisamos saber a extensão dessa classe de vulnerabilidade.
É isso que, em última análise, determina o nível de risco a longo prazo da lesão.
Portanto, na minha opinião:
👉 Não espalhe o medo de que a injeção tenha parado de funcionar.
Mas também:
👉 Não tire conclusões precipitadas de que "são apenas opções binárias e, portanto, não têm relação com o protocolo".
Nenhum desses extremos é preciso.
O que mais esperamos neste momento não é um tweet para tranquilizar o mercado.
Em vez disso, é:
Uma análise técnica completa após a morte.
Se a verificação pós-mortem demonstrar que a vulnerabilidade se limita às Opções Binárias e que os módulos relacionados foram totalmente auditados, o risco será significativamente reduzido.
Por outro lado, se forem encontradas colisões de ID de mercado ou lógica semelhante em vários outros módulos nativos, isso poderá se tornar um grande problema para a tese de longo prazo do INJ.
Os titulares de INJ devem prestar atenção especial a quatro pontos nos próximos dias:
Análise técnica oficial pós-exposição.
Foram detectadas outras vulnerabilidades nos módulos nativos de câmbio/seguros?
Os aproximadamente US$ 4,9 milhões serão recuperados ou permanecerão na carteira do atacante?
Os validadores, as exchanges e o ecossistema da Injective voltarão a operar normalmente?
Este não é o momento para entrar em pânico. Mas certamente é um momento para aumentar a vigilância.
BTCVN4 deseja-lhe boa sorte.
