The Ledger Attack: drenando criptocarteiras de hardware

The Ledger Attack: drenando criptocarteiras de hardware

Esta postagem analisa o ataque ao Ledger como um exemplo de como um spear phishing levou a um ataque à cadeia de suprimentos de software (SSC) na ferramenta de kit de conexão de software usada pelas carteiras de hardware da empresa, permitindo ao ator drenar dinheiro no valor de pelo menos US$ 600,000. 

Este ataque ocorreu no final de um ano repleto de incidentes na cadeia de abastecimento. Neste post analisamos o ataque, seu impacto, como foi tratado e quais lições puderam ser extraídas.

Ledger e seus usuários de carteiras de hardware são alvos óbvios para os cibercriminosos. Os drenadores de carteiras estavam atacando usuários do Ledger por meio de tentativas de phishing nos front-ends dos aplicativos de criptografia, e os criminosos precisam saber as coordenadas dos usuários para conduzir as campanhas de phishing. Ledger tinha um violação de dados até julho de 2023 além de fazer parte Roubo de dados de setembro de 2020 em seu e-commerce Shopify, um incidente de grande impacto. A postagem “Atualização: Esforços para proteger seus dados e processar os spammers”mostra a profundidade dessas violações.

A Ledger precisa levar a segurança a sério (é uma parte fundamental do seu negócio), com um laboratório de pesquisa interno (manter) manuseio certificação de segurança do dispositivo, um recompensa bug programa boletins de segurança e modelagem de ameaças. Até agora tudo bem …

Como foi feito o ataque

Ledger detectou uma exploração usando o Ledger Kit de conexão DApp na quinta-feira, 14 de dezembro de 2023. Essa exploração injetou código malicioso em aplicativos descentralizados (DApps) baseados em Ethereum que usavam o Ledger Connect Kit, enganando os usuários para que assinassem transações que esgotassem suas carteiras. 

A exploração foi rapidamente detectada e uma resolução foi implementada logo depois. Nesse ínterim, um baixo volume de usuários caiu no ataque e assinou transações que esgotaram suas carteiras.

O ataque começou quando um ex-funcionário da Ledger foi vítima de um ataque de phishing que obteve acesso à sua conta NPM por meio do token de sessão. Os invasores publicaram versões maliciosas do  @ledgerhq/connect-kit (1.1.5, 1.1.6 e 1.1.7, agora aposentado). Os invasores podem executar código arbitrário com o mesmo nível de permissões do aplicativo de carteira: os invasores podem drenar imediatamente os fundos dos usuários sem interação, distribuir vários links de phishing para enganar os usuários ou explorar o pânico dos usuários, convencendo-os a transferir ativos para um novo endereço , resultando em perda de ativos devido ao download de uma carteira falsa.

Front-ends de carteira (dApps) normalmente usavam o carregador de kit de conexão pacote do Ledger para carregar o Connect Kit em tempo de execução a partir de um CDN JavaScript (jsDelivr). Infelizmente, o URL https://cdn.jsdelivr.net/npm/@ledgerhq/connect-kit@1 não estava fixando a versão exata (1.1.4 na época), então quando as versões maliciosas eram carregadas, elas eram veiculadas (e armazenadas em cache) pelo CDN. E nenhuma soma de verificação foi usada para garantir que o recurso baixado do CDN era realmente o esperado (que deveria ser usado ao distribuir código de um CDN). Este esquema baseado em soma de verificação é denominado Integridade de sub-recursos (SRI).

O código injetado provavelmente manipulou dados de transações, enganando os usuários e fazendo-os confirmar pagamentos manipulados. Por exemplo, um usuário que aprova um pagamento simbólico para ativar a funcionalidade de um aplicativo pode ter visto uma aprovação de pagamento para o endereço do hacker. Não importa quão segura seja a carteira de hardware, o dinheiro foi drenado. 

Descoberta e Investigação

Diferentes usuários começaram a postar mensagens no X (também conhecido como Twitter) informando que o front-end do Zapper “foi sequestrado”. O crédito vai para Mathew Lilley, o CTO do cryptotrader Sushi, que primeiro alertou em um Twitter pós que um “conector web3 comumente usado” foi comprometido. Mais tarde ele apontou para LedgerHQ/kit de conexão como a biblioteca comprometida, e fez uma primeira avaliação, um pouco bruscamente:

O usuário 0xViva abriu um ticket no repositório do projeto GitHub: [URGENTE] Este repositório utiliza uma versão maliciosa do pacote npm @ledgerhq/connect-kit, 1.1.7.

Em 15 de dezembro de 2023, o formulário de segurança blockchain SlowMost publicou um postagem de análise fornecendo detalhes completos das versões maliciosas. 

A carteira de hardware Ledger não foi comprometida, apenas o Ledger Connect Kit. No entanto, como muitas aplicações utilizam essa biblioteca, como SushiSwap, Zapper, MetalSwap, Harvest Finance, Revoke.cash, etc., o alcance do impacto foi significativo. De acordo com bittrace.io, algumas vítimas, em pânico, tentaram transferir ativos para um novo endereço, mas baixaram um aplicativo de carteira falso! 

No mesmo dia, Jameson Lopp com precisão twittou sobre as falhas que permitiram o sucesso do ataque:

Como o incidente foi tratado

O CEO da Ledger, Pascal Gauthier, postou no mesmo dia do ataque um carta de divulgação dando mais detalhes sobre o incidente, o que é definitivamente bom: esconder a cabeça na areia como um avestruz é a pior maneira de lidar com qualquer incidente de segurança cibernética. 

A estrutura da carta é interessante: ela prontamente reconheceu a existência de versões maliciosas da biblioteca que drenavam dinheiro, o que é bom (negar a realidade é um absurdo):

“Hoje experimentamos uma exploração no Ledger Connect Kit, uma biblioteca Javascript que implementa um botão que permite aos usuários conectar seu dispositivo Ledger a DApps (sites conectados à carteira) de terceiros.

Essa exploração foi o resultado de um ex-funcionário ser vítima de um ataque de phishing, que permitiu que um malfeitor carregasse um arquivo malicioso no NPMJS da Ledger (um gerenciador de pacotes para código Javascript compartilhado entre aplicativos).

Trabalhamos rapidamente, juntamente com nosso parceiro WalletConnect, para resolver a exploração, atualizando o NPMJS para remover e desativar o código malicioso 40 minutos após a descoberta. Este é um bom exemplo de como a indústria trabalha rapidamente em conjunto para enfrentar os desafios de segurança.” 

O que? Um ex-funcionário com direitos de publicação não teve suas credenciais no NPM revogadas?

O CEO seguiu enumerando os controles de segurança em vigor, mas insinuando que algo estava fraco com o acesso do NPM:

“Agora, gostaria de abordar por que isso aconteceu, como melhoraremos nossas práticas de segurança para mitigar esse risco específico no futuro e compartilhar nossa recomendação à indústria, para que possamos ser mais fortes juntos.

O método da standard a prática na Ledger é que nenhuma pessoa pode implementar código sem revisão por várias partes. Temos fortes controles de acesso, revisões internas e assinaturas múltiplas de código quando se trata da maioria das partes do nosso desenvolvimento. Esse é o caso em 99% dos nossos sistemas internos. Qualquer funcionário que deixe a empresa tem seu acesso revogado de todos os sistemas Ledger.

Este foi um infeliz incidente isolado. É um lembrete de que a segurança não é estática e que a Ledger deve melhorar continuamente os nossos sistemas e processos de segurança. Nesta área, a Ledger implementará controles de segurança mais fortes, conectando nosso build pipeline que implementa rigorosamente software supply chain security para o canal de distribuição NPM."

Bem, parecia que a conta NPM com permissão para publicar novas versões da biblioteca tinha controles de segurança menos rigorosos do que outras partes de sua infraestrutura de software. Incidente isolado devido a má sorte?

O final da carta é mais standard seção de engajamento com as autoridades, “declaração sob controle” e desculpas:

“Ledger se envolveu com as autoridades e está fazendo tudo o que pode para ajudar no desenrolar desta investigação. A Ledger apoiará os usuários afetados para ajudar a encontrar esse malfeitor, levá-los à justiça, rastrear os fundos e trabalhar com as autoridades para ajudar a recuperar os ativos roubados do hacker. Lamentamos profundamente os acontecimentos que ocorreram hoje para os indivíduos afetados. 

A situação está agora sob controle e a ameaça passou. Compreendemos o pânico que isso causou à comunidade e ao ecossistema em geral.”

A carta anexa um cronograma, o que é muito bom para os usuários entenderem como o incidente foi descoberto, quais ações específicas de contenção e remediação foram tomadas e como os danos aos usuários afetados serão recuperados/compensados. Esta é a parte mais específica da moeda:

“Esta manhã, CET, um ex-funcionário da Ledger foi vítima de um ataque de phishing que obteve acesso à sua conta NPMJS. O invasor publicou uma versão maliciosa do Ledger Connect Kit (afetando as versões 1.1.5, 1.1.6 e 1.1.7). O código malicioso usou um projeto WalletConnect desonesto para redirecionar fundos para uma carteira de hacker. As equipes de tecnologia e segurança da Ledger foram alertadas e uma correção foi implantada 40 minutos após a Ledger tomar conhecimento. O arquivo malicioso permaneceu ativo por cerca de 5 horas, mas acreditamos que o período em que os fundos foram drenados foi limitado a um período inferior a duas horas. Ledger coordenou com WalletConnect que rapidamente desativou o projeto desonesto. O Ledger Connect Kit versão 1.1.8 genuíno e verificado agora está se propagando e é seguro para uso.

Para construtores que estão desenvolvendo e interagindo com o código do Ledger Connect Kit: a equipe de desenvolvimento do kit de conexão no projeto NPM agora é somente leitura e não pode enviar diretamente o pacote NPM por motivos de segurança. Alternamos internamente os segredos para publicação no GitHub do Ledger. Desenvolvedores, verifiquem novamente se estão usando a versão mais recente, 1.1.8.

Ledger, junto com Wallet Connect e nossos parceiros relataram o endereço da carteira do malfeitor. O endereço agora está visível em Chainalysis. Tether congelou o USDT do malfeitor.”

De acordo com isso, a contenção foi rápida, pois o projeto desonesto WalletConnect para redirecionar fundos foi desativado imediatamente. Mas mesmo com isso, algumas carteiras foram esgotadas.

Consequências: como a indústria reagiu

Alguns usuários expressaram raiva de Ledger por não ter conseguido evitar o comprometimento, enquanto outros alertaram contra os perigos de depender de bibliotecas de terceiros.

A indústria de segurança cibernética tem um nicho na cibercoin. São bem conhecidas campanhas de drenagem de carteiras, que utilizam principalmente sites de phishing para enganar os usuários finais. O negócio SaaS usual (Scam-as-a-Service) tem atores especializados para esgotar a carteira, como o fornecedor de golpes Escorredor Infernal qual anunciou a parada das operações em novembro de 2023. De qualquer forma, esta parece ser uma bandeira falsa, de acordo com a atividade recente vista em Dune's @scamsniffer. O esquema que eles seguem foi explicado nesta postagem do Grupo-IB:

Fluxo de trabalho do Inferno Drainer. Fonte: Adeus Inferno Drainer? (…), pelo Grupo-IB.
The Ledger Attack: drenando criptocarteiras de hardware

Alguns analistas deram dicas sobre o que não tornou o ataque possível. Esse comentário do usuário brianddk no ticket no repositório do projeto nos dá insights sobre a causa raiz: 

The Ledger Attack: drenando criptocarteiras de hardware

A comentário de outro usuário, HenryQW, apontou para a segunda coisa que tornou as versões maliciosas capazes de se propagar via CDN:

É muito cedo para ver iniciativas de longo prazo para tornar os front-ends de carteiras criptográficas mais robustos contra ataques de phishing. Parece que exigir a adesão a uma standard semelhante ao que o PA-DSS O que faz para fornecedores de software de aplicativos de pagamento pode ser bem-vindo na indústria de criptografia.

E agora, lições aprendidas!

É incrível como uma carteira de hardware, o epítome da segurança criptográfica, foi violado simplesmente granulando o acesso às credenciais do NPM de um "ex-funcionário" da Ledger (provavelmente nome de usuário/senha sem proteção 2FA ou token de acesso). Este incidente serve como um lembrete contundente de que, quando você está sob pressão, sua infraestrutura de software precisa ser protegida com o mesmo cuidado que seus produtos de software ou hardware.

A maioria dos ataques à cadeia de suprimentos de software começa comprometendo uma conta interna (geralmente para um desenvolvedor ou engenheiro de devops). Os invasores então se movem lateralmente para violar sistemas internos na infraestrutura de software, como CI/CD sistema ou as ferramentas de implantação, ou conseguem adicionar lógica maliciosa aos repositórios de código-fonte, o que pode ser detectado se o tratamento adequado de alterações com proteção de ramificação e revisões de código estiver em vigor. Mas os invasores não precisam ir tão fundo quando o alvo é uma biblioteca popular publicada em um registro público, especialmente se eles puderem obter acesso para publicar (escrever) credenciais. E foi isso que aconteceu neste ataque. 

Autenticação 2FA, especificamente usando elementos robustos como chaves de segurança, limita o risco com operações interativas. Para CI/CD pipelines, tokens de acesso com acesso limitado armazenados como um CI/CD segredo é o caminho usual a seguir (e o token de acesso não deve vazar). Infelizmente, parece que o funcionário não tinha um conjunto 2FA robusto. O NPM permite organizações para aplicar 2FA (mas isso é opcional, não o padrão), que provavelmente é o que o Ledger deveria ter. E não se esqueça de adicionar apropriado revogação de credenciais procedimentos para ex-funcionários, especialmente com acesso a recursos tão críticos quanto o escopo NPM de propriedade da organização.

Fixação de versão para dependências com versões revisadas é uma prática que mitiga a propagação de dependências maliciosas. No contexto do incidente Ledger, as versões da biblioteca que o carregador de kit de conexão retirado do CDN deveria ter sido fixado e “não confie em tudo o que o CDN lança”. Tendo uma verificação de soma de verificação por exemplo, via SRI (ou mesmo um esquema de assinatura digital que também autentica a fonte) deve ser usado ao extrair de uma CDN para carregamento dinâmico de código.  

O resto é uma história.

Para as campanhas de phishing mais convencionais direcionadas aos usuários de carteiras, a questão é: O que faz os usuários caírem em armadilhas armadas por criminosos e confirmarem transações que nunca pretenderam realizar? Os sites de phishing neste domínio são bem projetados e convincentes, imitando marcas populares de criptografia; e eles também oferecem tokens grátis, cunhar NFTs e outras recompensas. Evitar que os usuários caiam nessas armadilhas é um problema que busca solução.

E para não esquecer o relacionado criptografia ataques, uma ameaça mais geral, onde os adversários assumem o controle de infraestruturas em nuvem para operar mineradores de criptomoedas, muitas vezes para moedas de privacidade como Monero XMR e Zcash, com históricos de transações ocultos. O Cryptojacking é relevante porque pode afetar QUALQUER organização e, embora o lucro para o invasor possa ser baixo, o custo para a vítima pode ser grande (Sysdig mencionado em este relatório que são necessários US$ 53 em custo para a organização vítima para cada US$ 1 extraído para o invasor).

Referências

Explore os recursos do Xygeni!
Assista ao nosso vídeo de demonstração
sca-tools-software-composição-análise-ferramentas
Priorize, corrija e proteja seus riscos de software
você recebe uma avaliação gratuita de 7 dias da nossa licença Business Edition e pode aproveitar alguns dos recursos avançados da plataforma SecurityScorecard.
Não é necessário cartão de crédito

Proteja seu desenvolvimento e entrega de software

com o Suíte de Produtos da Xygeni