Fundo
Funcionários da Celer Network declararam em 18 de agosto que entre 3h45 e 6h, horário de Pequim, certos usuários do cBridge foram direcionados para contratos inteligentes maliciosos. Inicialmente, a interface front-end do cBridge foi suspeita de ter sido comprometida por um ataque de DNS.
Completamente diferente dos incidentes anteriores de hacking de pontes entre cadeias, como Nomad, Wormhole, Ronin, Harmony, etc., este ataque não foi causado por bugs em contratos inteligentes e protocolos entre cadeias ou pela intrusão de servidores relacionados, e pelo cross-chain. os ativos da cadeia bloqueados no cBridge também foram mantidos em segurança. Neste ataque, os hackers visaram diretamente a infraestrutura subjacente na arquitetura da Internet fora do sistema Celer e permitiram que usuários de cadeia cruzada acessassem uma interface de usuário front-end de “phishing” dentro de um período de tempo, enganando o protocolo de roteamento subjacente da Internet ( BGP).A rede Celer conseguiu limitar os danos devido à sua pronta resposta.Isso porque a equipe da Rede Celer possui um sistema de monitoramento 24 horas. A equipe de atendimento ao cliente conseguiu identificar o problema e alertar a comunidade em tempo hábil. A equipe da Celer Network capacitou a equipe de segurança do SlowMist para responder a esta emergência e conduzir uma investigação aprofundada.
Processo de Análise
A equipe da Celer Network inicialmente suspeitou de um ataque DNS e, após nos comunicarmos com eles, pudemos aprender mais sobre o nome de domínio em questão: cbridge-prod2.celer.network. Descobrimos que o navegador não relatou erro de certificado durante o ataque. Portanto, nossa investigação começou abordando primeiro a possibilidade de ataque ao DNS. (Agradecimentos especiais a @greysign1 por nos ajudar a verificar rapidamente a possibilidade de ataque DNS)
Começamos revisando as informações relevantes do certificado:
O certificado parece ter sido alterado inesperadamente, onde o certificado original emitido pela Let’s Encrypt foi substituído por um certificado falsificado emitido pela GoGetSSL.
GoGetSSL pode emitir um certificado gratuito de 90 dias:
Análise do Certificado 1: https://crt.sh/?id=7356185959
Um erro de verificação de CRL aparece no certificado no seguinte momento:
Análise do Certificado 2: https://crt.sh/?id=7356185959
Este certificado também apresenta um erro de verificação de CRL nos seguintes momentos:
Após examinar o endereço IP, o certificado, bem como outras informações associadas ao Certificado 1, descobrimos que o endereço IP vinculado a este certificado era 44.235.216.69.
O endereço IP do Certificado 2 não conseguiu consultar o endereço IP correspondente ao Certificado 2, o que pode dever-se à curta duração do ataque e à falha do motor de busca na Internet na recolha de informações relevantes.
Como resultado, concentramos nossa análise nos dados de resolução IP para o domínio cbridge-prod2.celer.network:
O endereço IP, 44.235.216.69, foi associado a cbridge-prod2.celer.network por um longo período de tempo.
Aqui está a questão: o fato de este endereço IP, 44.235.216.69, ter sido associado a cbridge-prod2.celer.network por um longo período de tempo, prova que ele pertencia ao servidor oficial da Celer Network. Isso também foi confirmado com a equipe da Celer Network. Então, por que havia um certificado falsificado associado a este IP?
Então começamos a investigar o AS de 44.235.216.69 e descobrimos que o AS correspondente a este IP era incomum.
AS16509 anuncia bogons:：
Examinando os bogons, podemos determinar que esse geralmente é o caso quando um invasor falsifica um endereço IP para realizar um ataque: https://networkdirection.net/articles/routingandswitching/bgp-bogonsandmartians/ https://forum .networklessons.com/t/what-are-bogons/6333
Como o AS em 44.235.216.69 apresentava anomalias, primeiro suspeitamos que o problema era com o BGP, por isso entramos em contato com a rede Celer para obter o endereço IP do invasor: 54.84.236.100. Descobrimos que AS14618, onde está localizado o endereço IP, também tinha uma exceção. (AS14618 também anuncia bogons)
Coincidentemente, o upstream do AS14618 era o AS16509 (AS16509 também é o AS onde 44.235.216.69 está localizado). Isso nos alertou sobre a possibilidade de um ataque BGP.
Nossa investigação revelou que o IP: 54.84.236.100 foi sinalizado como malicioso.
Coletamos informações relevantes sobre o IP: 54.84.236.100 de nossa comunidade e encontramos uma menção desse endereço IP relacionado a outro incidente de ataque BGP que ocorreu em 2014. No entanto, como esse incidente ocorreu há muito tempo, pode não ser mais relevante.
Em seguida, continuamos nossa investigação seguindo os registros deixados por este ataque BGP:
O rastreamento do registro BGP para o IP de ataque: 54.84.236.100 revelou que a rota não está mais disponível.
Continuamos rastreando os rastreamentos do roteador BGP para o IP do Celer: 44.235.216.69 e conseguimos encontrar a rota correta.
Em seguida, verificamos o log de alterações do nó BGP: Horário de Pequim: 18/08/2022 2h48 - 18/08/2022 7h48 UTC+8
Em 18/08/2022, descobriu-se que o período entre 2h48 e 7h48 BST tinha um grande número de adições e exclusões de nós de registros de alteração.
Continuamos monitorando o log de alterações do AS e descobrimos que AS14618 anteriormente tinha a informação de roteamento 44.235.216.0/24, mas o caminho foi alterado para Retirado, provando que:
44.235.216.0/24 em AS14618 costumava ser o caminho ideal
Agora 44.235.216.0/24 em AS14618 não é mais o caminho ideal; é retirado.
(Quando ocorre um ataque BGP, o invasor publicará um caminho ideal para direcionar o tráfego para seu próprio servidor)
Para obter dados mais precisos, usamos o seguinte bgplay para verificar as mudanças nos caminhos relacionados a 44.235.216.69 no momento do ataque.
No dia 17/08/2022, podemos observar que no período entre 19:19:23 +UTC e 23:19:23 +UTC, houve uma flutuação significativa nas informações dos caminhos de roteamento BGP.
Essa mudança se reflete no direcionamento do tráfego de 44.235.216.0/24 para AS14618, onde o tráfego de 44.235.216.0/24 sai pelo AS16509 após o ataque.
Como resultado, estamos considerando que este incidente é provavelmente um evento de ataque BGP, onde o AS14618 parece ser um nó sob o controle do invasor (o roteador do AS14618 pode ter problemas de segurança e pode ser explorado pelos invasores), com o ataque com duração aproximada de 4 horas.
O invasor conseguiu vincular o Certificado 1 (certificado falso) ao IP da Celer Network: 44.235.216.69 porque o invasor tinha um servidor malicioso com o mesmo IP. Como o gogetssl oferece suporte a http para autenticação, eles podem apenas inserir o texto fornecido pelo gogetssl no servidor malicioso. Portanto, possibilitando vincular o Certificado 1 direcionando o tráfego para o servidor malicioso com o mesmo IP através de ataque BGP. Como resultado, o navegador foi alertado sobre o erro de certificado.
Determinamos que o AS14618 era controlado pelo invasor pelos seguintes motivos.
O invasor primeiro direcionou o tráfego de 44.235.216.69 para AS14618 e encaminhou 44.235.216.69 de volta para AS16509 após o ataque.
IP de ataque: 54.84.236.100 também está dentro do AS14618.
Após o ataque, AS14618 foi retirado para 44.235.216.69.
Para responder a esta pergunta: O fato deste endereço IP, 44.235.216.69, ter sido associado a cbridge-prod2.celer.network por um longo período de tempo, prova que ele pertencia ao servidor oficial da Celer Network. Isso também foi confirmado com a equipe da Celer Network. Então, por que havia um certificado falsificado associado a este IP?
Se você usar o protocolo HTTPS para comunicação, não poderá criptografar/descriptografar os dados (incluindo os dados de comunicação cliente/servidor) sem obter a chave privada do certificado. Portanto, para garantir que o certificado está correto e poder realizar o ataque man-in-the-middle, o invasor precisa religar o certificado aplicado na autoridade ao servidor malicioso com o mesmo IP 44.235.216.69. Isso permite que o invasor descriptografe os dados do cliente e insira o código malicioso nos dados do pacote de resposta.
Conclusão da análise
Investigamos esse ataque em colaboração com a equipe da Celer Network. Apesar de se tratar de uma tentativa sofisticada de ataque BGP à rede Celer, com o invasor preparando tudo, desde o momento do ataque, falsificação de certificado, controle de AS e outras operações.
Em última análise, reconhecemos que muitos projetos já estão cientes dos riscos associados aos ataques de ataque BGP e tomaram as precauções adequadas. No entanto, muitos ainda desconhecem, principalmente quando se trata de modificações no caminho da rede induzidas por alterações no AS. Sem medidas adequadas de preparação e resposta, existe um risco considerável de novos ataques por parte do mesmo ou de outros atacantes. Portanto, pedimos que as organizações, os ISPs e os provedores de hospedagem de servidores reconheçam esses riscos e coordenem estratégias defensivas para evitar que incidentes semelhantes ocorram novamente. E, como sempre, se precisar de ajuda, entre em contato com a equipe de segurança do SlowMist.
Anexo
Gráfico DNS cbridge-prod2.celer.network:
