LavaMoat e o Ataque à Cadeia de Suprimentos de Software da Ledger

O que aconteceu?

No dia 14 de dezembro, uma das bibliotecas de software da Ledger, o Ledger Connect Kit, foi alvo de um ataque à cadeia de fornecimento de software.

O comprometimento teria se originado quando um ex-funcionário, que ainda tinha acesso de publicação, foi vítima de um ataque de phishing. Esse ataque comprometeu suas credenciais no npm. O npm, ou Node Package Manager, é uma ferramenta para importar bibliotecas de software de código aberto, amplamente utilizada no setor de desenvolvimento web e também no web3.

Esse ataque permitiu que uma versão maliciosa da biblioteca em questão fosse publicada. Essa biblioteca é incluída de forma atualizada em tempo real por meio de uma Rede de Distribuição de Conteúdo (CDN) em muitos aplicativos web do ecossistema Ethereum. Isso resultou na injeção de código malicioso nesses aplicativos web.

Como evitamos isso? LavaMoat.

LavaMoat é um conjunto de ferramentas criado especificamente para ajudar a resolver os problemas de segurança na cadeia de fornecimento de software que os desenvolvedores de aplicativos web enfrentam.

O LavaMoat oferece proteções contra ataques à cadeia de fornecimento em três pontos diferentes do ciclo de vida do desenvolvimento de software: no momento da instalação das dependências (quando você está importando todas aquelas bibliotecas), no momento do build (quando o aplicativo está sendo preparado para ser servido pela Internet) e em tempo de execução (quando o aplicativo compilado está em funcionamento).

O LavaMoat se destaca por suas proteções em tempo de execução. Existem outras ferramentas que podem ser usadas durante o desenvolvimento, como o snyk.io, que apenas fornece avisos sobre vulnerabilidades conhecidas, ou o socket.dev, que oferece uma análise de código mais abrangente e não aguarda que especialistas reportem descobertas a um banco de dados central. Essas ferramentas de varredura desempenham um papel inestimável, e recomendamos que você use a Integração com o GitHub do socket.dev.

No entanto, elas são incapazes de oferecer qualquer garantia em tempo de execução. Por esse motivo, consideramos insuficiente utilizá-las isoladamente.

As proteções de segurança do LavaMoat derivam de delegar apenas as capacidades especificadas às dependências do seu aplicativo.

O que isso significa? Bem, continue lendo e confira nossa palestra no Devcon 6 para entender mais profundamente como o LavaMoat funciona e como ele é utilizado.

Uma introdução ao Object Capability

Você pode pensar em um sistema como tendo capacidades: coisas que ele pode fazer, como exibir informações, ler dados armazenados localmente ou fazer requisições a outros sistemas, como requisições web a servidores ou requisições de transação a carteiras, e a capacidade de delegar essas capacidades a outros.

Ao delegar uma capacidade, você pode fornecer uma versão limitada ou restrita dela. Isso é conhecido como atenuação.

Esses três componentes formam a base do modelo de segurança object capability. Usando esse modelo, você pode entender quem tem a capacidade de fazer o quê.

Segurança em aplicativos web

Os navegadores fazem um trabalho razoável ao isolar aplicativos em sandbox; ou seja, mantê-los separados e impedindo que interfiram no seu computador ou em outros sites.

No entanto, eles não oferecem blocos de construção robustos para que os desenvolvedores de aplicativos web possam isolar em sandbox partes específicas de seus aplicativos, o que poderia impedir que determinados componentes comprometessem o aplicativo inteiro.

Por esse motivo, ao importar uma biblioteca para o seu aplicativo, você está efetivamente delegando todas as capacidades a essa biblioteca. Isso se torna ainda mais complexo pelo fato de que a maioria das bibliotecas JavaScript não traz apenas seu próprio código, mas uma coleção de bibliotecas escritas por diversos autores.

Especificidades do ataque à Ledger

A biblioteca @ledger/connect-kit-loader é a forma recomendada pela Ledger para integração com seus produtos. Esse pacote é um wrapper simples que carrega a versão mais recente de sua biblioteca a partir de uma CDN.

Embora isso signifique que seu aplicativo sempre terá a versão mais recente da biblioteca, também significa que você está efetivamente delegando o controle do seu aplicativo web à biblioteca loader da Ledger, que por sua vez o delega ao código hospedado na CDN.

Você pode modelar a cadeia de delegação assim:

Aplicativo Web → **@ledger/connect-kit-loader** → jsDelivr CDN → npm → Ledger → ex-funcionário da Ledger → atacante

Mesmo isso é uma simplificação. Ao ampliar um componente, como a CDN jsDeliver, é possível revelar uma complexidade impressionante de serviços adicionais que também fazem parte da cadeia de fornecimento e são potenciais pontos de entrada para o lançamento de um ataque.

Protegendo aplicativos com Object Capability Security

Embora os próprios navegadores não ofereçam muitas ferramentas, como mencionado, para limitar as capacidades de subcomponentes de um aplicativo, a linguagem JavaScript é, na verdade, bem adequada para essa tarefa.

O JavaScript, com algum esforço cuidadoso, permite que você construa Compartments, que limitam o que o código tem permissão de acessar. Veja o esforço da Agoric com o Hardened Javascript para uma implementação de Compartments.

O sistema de segurança de cadeia de fornecimento LavaMoat da MetaMask e o sistema de plugins MetaMask Snaps são ambos construídos sobre Compartments para alcançar o confinamento.

O LavaMoat teria impedido o ataque à cadeia de fornecimento da Ledger?

Perguntar se o LavaMoat teria impedido o ataque é mais ou menos como perguntar se o recurso de parada ao toque de uma serra de mesa ajudaria se você segurasse a serra enquanto pulasse de um penhasco — sim, seus dedos provavelmente continuariam presos à sua mão após o salto.

Em princípio, a forma como o @ledgerhq/connect-kit-loader funciona obriga o desenvolvedor do aplicativo a abrir mão de muitas das melhores práticas de segurança estabelecidas. Mas nem tudo está perdido.

A melhor maneira de deixar o LavaMoat (e outras ferramentas de segurança de cadeia de fornecimento) ajudá-lo seria usar o @ledgerhq/connect-kit diretamente, sem transferir todo o controle para o loader.

O LavaMoat foi projetado para mitigar ataques como o hack da carteira Copay, também conhecido como "o incidente do event-stream", e oferece boa proteção contra ele. Então, como o LavaMoat se sai contra esse ataque diferente?

A resposta é, infelizmente, o velho "depende". O LavaMoat é uma ferramenta para desenvolvedores de aplicativos, não de bibliotecas, devido à forma como ele se integra ao runtime do aplicativo. Isso significa que, embora alguns aplicativos web pudessem ter se protegido com o LavaMoat, aplicativos sem o LavaMoat ainda seriam vulneráveis.

Além disso, o LavaMoat apenas aplica uma política especificada pelos desenvolvedores. Se você especificar uma política insegura, o LavaMoat não será capaz de protegê-lo.

Vamos ver como um aplicativo com LavaMoat poderia ter sido protegido desse ataque.

O LavaMoat usa um arquivo de política para determinar quais capacidades, na forma de APIs globais da plataforma, uma dependência deve receber. Para facilitar isso, você pode fazer com que o LavaMoat analise um pacote e determine automaticamente o que ele parece precisar para funcionar. Isso é conhecido como análise estática.

Embora a análise estática seja um meio imperfeito de entender o que determinado código está tentando fazer, o LavaMoat usa a análise estática apenas por conveniência para ajudá-lo a gerar um arquivo de política. Ele não usa análise estática para aplicar suas políticas em tempo de execução. As políticas geradas são então revisadas, ajustadas e aprovadas pelo desenvolvedor.

Para a pergunta original, uma resposta é: Sim, o LavaMoat pode proteger seu aplicativo e seus usuários de ataques à cadeia de fornecimento, impedindo que pacotes tenham a capacidade de carregar novo código em tempo de execução. Ele pode protegê-lo se você o tiver configurado corretamente e se você usar dependências que não exijam capacidades excessivamente poderosas.

Outra resposta é: Não. Se você tivesse configurado o LavaMoat para permitir que o **@ledgerhq/connect-kit-loader** operasse normalmente e injetasse uma tag de script executando qualquer código que quisesse fora do runtime do LavaMoat, o ataque ainda teria sido bem-sucedido. Isso faz parte do compromisso do LavaMoat entre compatibilidade retroativa e um sistema mais seguro. O LavaMoat é muito flexível para ser maximamente compatível, para que você possa adicioná-lo ao seu aplicativo sem reescrevê-lo do zero. A responsabilidade ainda é do desenvolvedor do aplicativo de definir políticas sensatas e escolher dependências sensatas. O LavaMoat permite que você forneça seletivamente APIs globais do navegador, mas algumas APIs globais simplesmente contêm poder demais para ser concedido com segurança a um pacote de terceiros. Estamos pesquisando diferentes meios de limitar ainda mais esses poderes, mas criar algo que simplesmente funcione para pacotes que não fazem nenhum esforço para limitar seu controle é desafiador.

Um dos recursos do LavaMoat, chamado Scuttling, interferiria tanto no pacote malicioso quanto no original carregado pelo @ledgerhq/connect-kit-loader. O Scuttling remove o acesso a capacidades para código executado fora do sandbox do LavaMoat. Isso impediria que você usasse o inseguro @ledgerhq/connect-kit-loader para começar, e o direcionaria para usar diretamente e, portanto, assumir o controle do processo de atualização do @ledgerhq/connect-kit, garantindo que você mantenha controle total sobre o código executado no seu aplicativo.

Embora o LavaMoat não seja uma solução mágica, ele oferece controle e visibilidade onde você, de outra forma, não teria nenhum. O LavaMoat deve ser apenas uma ferramenta na sua estratégia de segurança.

Veja o que você pode fazer agora mesmo para se defender de um ataque amanhã:

• Adicione o monitor de dependências Socket.dev gratuito (2 min).

• Adicione uma CSP com controle rigoroso de recursos (30 min).

• Adicione o LavaMoat ao seu sistema de build e ao seu bundle do aplicativo (1 hr).