Cadeia de fornecimento de software segura: por que cada link é importante

Este artigo foi originalmente publicado pela Sysdig aqui.

As atividades da cadeia de suprimentos incluem cada etapa da transformação de matérias-primas, componentes e recursos em um produto completo e sua entrega ao cliente final.

Cada etapa pode ser um processo complexo e causar um incidente de segurança.

O que é uma cadeia de suprimentos de software

A cadeia de suprimentos de software é semelhante a outras atividades ou indústrias. Alguns recursos são consumidos , depois transformados , por meio de uma série de etapas e processos , e finalmente fornecidos como produto ou serviço a um cliente.

No software, as matérias-primas são bibliotecas comuns, código, hardware e ferramentas que transformam o código em uma entrega final. Essa entrega pode ser implantada como um aplicativo voltado para o usuário, um serviço (reiniciando com o mesmo loop da cadeia de suprimentos) ou outro artefato de pacote incluído como uma dependência, parte de um produto diferente.

A cadeia pode ser longa e bastante complexa, então vamos tentar um exemplo extremamente simplificado :

Para produzir o “aplicativo web” final para nosso cliente, precisamos transformar (compilar) um código-fonte e consumir informações de serviços de terceiros. O próprio código-fonte depende de bibliotecas externas, que são produzidas a partir de outro código, etc.

O ataque à cadeia de suprimentos de software ocorre quando algum elemento malicioso é introduzido nessa cadeia.

Um ataque bem-sucedido em qualquer link do suprimento pode propagar o código ou componente comprometido downstream, completamente despercebido e causar caos em diferentes estágios.

Na verdade, muitos desses ataques se concentram em comprometer um fornecedor de software, injetando algum malware ou vulnerabilidade em uma etapa intermediária para explorar os clientes finais com consequências fatais.

Como sua empresa ou produto é apenas uma peça na cadeia de suprimentos de software geral, as medidas de segurança relacionadas à cadeia de suprimentos podem ser aplicadas em três pontos diferentes:

1. Entradas: Dependências de biblioteca e pacote, ferramentas de terceiros, software, serviços ou qualquer artefato que você esteja consumindo, seja público ou de um fornecedor privado.
2. Saídas: Garanta a integridade de suas entregas e forneça maneiras de verificar os componentes a jusante.
3. Processos e infraestrutura: proteja sua rede, identidades, credenciais, chaves de assinatura, repositórios e processos.

Explicaremos alguns dos ataques comuns à cadeia de suprimentos , com exemplos recentes, e forneceremos dicas e práticas que você pode aplicar para mitigar os riscos.

O que é um ataque à cadeia de suprimentos

Já demos uma definição da cadeia de suprimentos de software com um exemplo simplificado, falando sobre código, bibliotecas e serviços. Mas vamos nos aprofundar um pouco e colocar o foco no código-fonte:

Aumentar o zoom em qualquer link da cadeia revelará detalhes adicionais:

No exemplo, seu código-fonte ficará em um repositório git privado , que pode fazer parte de sua infraestrutura ou SaaS fornecido por um fornecedor, bem como ferramentas de compilador, registros de imagem de contêiner de base etc.

Algumas dependências são hospedadas em repositórios públicos , como Docker Hub ou Quay.io, e podem ser comprometidas. Além disso, também estamos publicando nosso aplicativo como uma imagem de contêiner em um repositório público.

Alguns dos componentes na cadeia ( blue ) estão sob seu guarda-chuva, como seu repositório git de código-fonte privado , o próprio código do aplicativo e a imagem final binária ou de contêiner que é produzida. Mas muitos outros componentes ou serviços (em verde ) são serviços e recursos públicos, ou fornecidos por outras empresas, totalmente fora de seu controle .

Portanto, um ataque à cadeia de suprimentos de software pode ter como alvo você diretamente ou pode visar qualquer elemento upstream (como dependências externas ou serviços fornecidos), para que você se torne uma vítima, seja sofrendo diretamente o ataque ou tornando-se um fornecedor de recursos comprometidos.

Exemplos de ataques à cadeia de suprimentos

As tendências mostram que os ataques à cadeia de suprimentos estão aumentando a uma taxa exponencial de 4 a 5 vezes por ano, com vários milhares no ano passado, sendo o mais comum relacionado à confusão de dependência ou typosquatting, seguido por injeção de código-fonte malicioso.

Felizmente, nem todo ataque tem um impacto grande o suficiente para aparecer no jornal, mas vamos analisar alguns dos mais relevantes e recentes. Muitos outros exemplos de diferentes tipos de ataques à cadeia de suprimentos também são coletados pelo CNCF em seu Catálogo de Compromissos da Cadeia de Suprimentos .

CodeCov

As credenciais vazadas em uma imagem do Docker do CodeCov permitiram que os invasores modificassem um script bash . Esse script foi baixado e executado por clientes, resultando em credenciais de clientes vazadas e invasores obtendo acesso a seus repositórios git .

Vários clientes como Monday.com , Hashicorp , Twilio ou Confluent foram afetados.

Ventos solares

Os invasores se infiltraram na rede da Solarwinds e conseguiram injetar software malicioso em seu processo de construção. Este malware (relacionado ao APT29 , Nobelium) foi empacotado como parte das atualizações do produto Orion (um sistema de gerenciamento de rede). Como parte do processo de construção, o artefato foi assinado digitalmente e baixado por centenas de clientes.

Uma vez que o malware estava sendo executado nas redes dos clientes, os invasores espionaram e roubaram suas informações.

Este incidente também mostra como um ataque à cadeia de suprimentos pode se propagar e impactar vários clientes: como parte do software Orion comprometido, uma chave privada de certificado TLS para um servidor de e-mail na Mimecast (uma empresa de serviços de segurança cibernética em nuvem) vazou . Isso permitiu que os invasores realizassem um ataque man-in-the-middle no servidor de e-mail e acessassem os e-mails dos clientes.

Talvez nunca saibamos o impacto real do ataque Solarwinds, pois o software comprometido estava em execução por várias semanas ou meses dentro de redes de potencialmente milhares de clientes .

E ainda não está concluído: os invasores por trás do Solarwinds tentaram recentemente replicar ataques semelhantes, mas em diferentes partes da cadeia de suprimentos , como revendedores e outros provedores de serviços de tecnologia que personalizam, implantam e gerenciam serviços em nuvem e outras tecnologias em nome de seus clientes .

Kaseya

É bastante semelhante ao ataque Solarwinds, mas, neste caso, os invasores exploraram uma vulnerabilidade de dia zero nos sistemas Kaseya . Uma vez que assumiram o controle dos sistemas, eles executaram comandos remotos nos sistemas dos clientes usando o VSA, uma ferramenta de gerenciamento e monitoramento remoto.

Apple Xcode e XcodeGhost

Neste ataque, uma versão trojanizada do projeto Xcode legítimo “TabBarInteraction” foi publicada em um repositório público. Os desenvolvedores que usavam a versão falsa do projeto estavam executando inadvertidamente um script em cada compilação do projeto. O script abriu uma conexão com um servidor C2 (comando e controle).

Podemos encontrar outro exemplo em que versões reempacotadas do Xcode, com código malicioso, foram carregadas em serviços chineses de hospedagem de arquivos . Os desenvolvedores que baixaram a versão comprometida desses espelhos acabaram com um arquivo de objeto modificado. O arquivo objeto é vinculado no executável final ao criar aplicativos iOS. Pelo menos dois aplicativos conhecidos chegaram à AppStore oficial da Apple, passando com sucesso na certificação e revisão de código da Apple.

Pacote NPM ua-parser-js

Em 22 de outubro de 2021, os desenvolvedores de um pacote NPM muito comum, ua-parser-js , descobriram que alguns invasores carregaram uma versão comprometida do pacote contendo malware para Linux e Windows e foram capazes de roubar dados (pelo menos senhas e cookies do navegador).

Essa biblioteca ua-parser-js faz parte da cadeia de suprimentos de uma grande lista de softwares e empresas, incluindo o Facebook, para alguns de seus aplicativos voltados para o usuário em milhões de computadores.

Unicode e compiladores de código – Vulnerabilidades invisíveis

Alguns pesquisadores da Universidade de Cambridge afirmam a descoberta de um novo ataque à cadeia de suprimentos visando o código-fonte nas sutilezas dos padrões de codificação de texto, como o Unicode. Da forma como o Unicode funciona, é possível adicionar caracteres especiais aos comentários ou algumas partes do código que fazem a “codificação lógica” do código funcionar em uma ordem diferente da forma como é exibido . Isso possibilita ocultar códigos maliciosos dentro de códigos que parecem corretos para humanos, ignorando os procedimentos de revisão .

Mas antes de entrar em pânico, observe que o problema pode não ser tão novo e invisível, e pode ser evitado estabelecendo confiança nos contribuidores do código e fazendo revisões adequadas.

A proibição da Huawei

Por fim, incluímos este exemplo não como um conhecido ataque à cadeia de suprimentos de software, mas como uma demonstração da importância de confiar nos fornecedores em cada elo da cadeia. Até mesmo a cadeia de suprimentos de hardware pode ser um alvo . Durante anos, o governo dos EUA alertou o mundo e as empresas americanas sobre ameaças de segurança em equipamentos de rede chineses :

Com base nas informações classificadas e não classificadas disponíveis, a Huawei e a ZTE não podem ser confiáveis ​​como livres da influência de estados estrangeiros e, portanto, representam uma ameaça à segurança dos Estados Unidos e de nossos sistemas.

O aviso parece basear-se na falta de informação e na incapacidade de satisfazer algumas preocupações de segurança, e não em evidências reais de qualquer backdoor existente nos sistemas.

Portanto, podemos nunca obter evidências reais, mas a falta de confiança foi tão grave que a Huawei foi proibida em maio de 2019 de fazer negócios com qualquer organização que operasse nos Estados Unidos.

Taxonomia da cadeia de suprimentos (e controvérsia)

Nem todo mundo concorda que um ataque direcionado a qualquer estágio da cadeia de suprimentos de software cai na categoria de “ataque da cadeia de suprimentos”. A Agência da União Europeia para a Cibersegurança (ENISA) no relatório Threat Landscape for Supply Chain Attacks ” propõe uma taxonomia para caracterizar os ataques à cadeia de suprimentos e estruturar sua análise subsequente “:

Mas no mesmo relatório, eles acrescentam:

“Se nenhum cliente for atacado ou nenhum fornecedor for atacado, provavelmente não será um ataque à cadeia de suprimentos”.

Explicitamente, eles mencionam alguns exemplos que não atendem aos requisitos, como:

• Alguns pacotes de invasão de nomes ou seqüestro de marca foram carregados em repositórios públicos porque não comprometeram os pacotes existentes ou os repositórios de software.
• Vulnerabilidades descobertas ou erros não intencionais que não foram usados ​​em ataques conhecidos , porque não são direcionados a um fornecedor ou cliente .
• Versões vulneráveis ​​de software voltadas para o público que permitiam a exfiltração de dados do cliente, mas , nesse caso, o fornecedor não foi comprometido (o ataque foi direcionado a provedores de TI franceses) e as vulnerabilidades não foram intencionais nem criadas especificamente para esse ataque.

Portanto, para alguns incidentes, não há sequer um consenso global se pode ser classificado como um ataque à cadeia de suprimentos ou não.

Protegendo a cadeia de suprimentos de software

Os ataques à cadeia de suprimentos de software estão ampliando a superfície de ataque das empresas, pois sua segurança não depende apenas de procedimentos internos. Agora, eles também precisam garantir que terceiros (incluindo software, hardware, serviços etc.) não sejam uma porta de entrada para invasores que possam afetá-los.

Assim como a segurança tradicional, é impossível proteger tudo, especialmente porque novos tipos de ataques à cadeia de suprimentos de software estão sendo descobertos continuamente. Mas vamos explicar onde você precisa se concentrar em cada uma das camadas para estar o mais protegido possível.

Entradas do seu desenvolvimento de software

Como consumidor de artefatos de software, hardware e serviços de vários provedores, certifique-se de que seus provedores apliquem um alto nível de segurança.

A cadeia de suprimentos de software está se tornando tão crítica que, em maio de 2021, o presidente dos Estados Unidos emitiu uma ordem executiva destinada a melhorar a segurança cibernética do país . Como resultado do pedido, o NIST produziu o guia de Padrões Mínimos Recomendados para Verificação de Fornecedor ou Desenvolvedor (Teste) de Software Sob Ordem Executiva (EO) 14028 , que recomenda padrões mínimos para verificação por fornecedores ou desenvolvedores de software.

Como é impossível alcançar e garantir 100% de segurança, preste atenção também a quaisquer riscos ou incidentes que afetem seus provedores e esteja pronto para tomar medidas corretivas rápidas caso um componente comprometido seja detectado ou relatado.

Desenvolvimento de software na sua empresa

Com relação aos processos de código e desenvolvimento , os mencionados Padrões Mínimos Recomendados para Verificação de Fornecedor ou Desenvolvedor (Teste) de Software sob Ordem Executiva (EO) 14028 incluem o seguinte conjunto de técnicas como os requisitos mínimos de segurança para o ciclo de vida de desenvolvimento de software . Certifique-se de não perder nenhum deles:

• Aplique a modelagem de ameaças para identificar alvos de teste importantes ou potencialmente negligenciados.
• Testes automatizados.
• Análise baseada em código (estática), usando um scanner de código e revisão de segredos codificados.
• Análise dinâmica, com verificações e proteções integradas, testes de caixa preta e difusa, scanner de aplicativos da web, etc.
• Aplique verificações semelhantes ao software incluído (dependências de terceiros).
• Corrija bugs críticos o mais rápido possível.

Com a infraestrutura como código (IaC) , as ameaças na cadeia de suprimentos de software agora potencialmente visam não apenas software e aplicativos, mas também a infraestrutura subjacente. Os mesmos princípios de verificação de software devem ser aplicados à implantação e gerenciamento de infraestrutura como código, deslocando a segurança para a esquerda.

Mas a segurança deve ser difundida em todos os estágios de desenvolvimento e em toda a cultura e práticas da empresa . Proteger o código e o processo de desenvolvimento claramente não é suficiente, conforme descrito por várias pesquisas e guias da organização:

• O guia Defending Against Software Supply Chain Attacks da Cybersecurity and Infrastructure Security Agency considera que o Ciclo de Vida da Cadeia de Fornecimento de Software tem seis fases em que “os softwares estão em risco de introdução maliciosa ou inadvertida de vulnerabilidades “: Design, Desenvolvimento e produção, Distribuição, Aquisição e implantação, manutenção, descarte
• A Cloud Native Computing Foundation (CNCF) mantém um documento vivo e mantido pela comunidade: o Software Supply Chain Security Paper . Este documento visa contribuir para a comunidade com uma série de práticas recomendadas, opções de ferramentas e considerações de design que podem reduzir a probabilidade e o impacto geral de um ataque bem-sucedido à cadeia de suprimentos .
• O CNCF, Linux Foundation, VMware, Intel, Google e outros também estão trabalhando no SLSA – Supply-chain Levels for Software Artifacts , uma estrutura de segurança e uma linguagem comum para aumentar os níveis de segurança de software e integridade da cadeia de suprimentos para qualquer pessoa que trabalhe com o software. Cada nível fornece um grau crescente de confiança, uma maneira de dizer que o software não foi adulterado e pode ser rastreado com segurança até sua origem.

Kubernetes e contêineres são tão comuns hoje em dia que a NSA/CISA também lançou um Kubernetes Hardening Guidance , destacando “Riscos da cadeia de suprimentos” como uma das três fontes de comprometimentos e propondo as seguintes medidas de proteção e mitigações:

• Analise contêineres e pods em busca de vulnerabilidades ou configurações incorretas.
• Execute contêineres e pods com o mínimo de privilégios possível.
• Use a separação de rede para controlar a quantidade de danos que um comprometimento pode causar.
• Use firewalls para limitar conectividade de rede desnecessária e criptografia para proteger a confidencialidade.
• Use autenticação e autorização fortes para limitar o acesso de usuários e administradores, bem como para limitar a superfície de ataque.
• Use a auditoria de log para que os administradores possam monitorar a atividade e ser alertados sobre possíveis atividades maliciosas.
• Revise periodicamente todas as configurações do Kubernetes e use verificações de vulnerabilidade para ajudar a garantir que os riscos sejam considerados adequadamente e que os patches de segurança sejam aplicados.

Seu software é a entrada para outras empresas ou usuários

Tudo o que você aplicar ao escolher seus melhores fornecedores com alto nível de confiança será aplicado à sua empresa ao atuar como fornecedor de outras empresas ou para usuários finais. Mesmo que você implemente corretamente a segurança em cada etapa e processo do ciclo de vida de sua cadeia de suprimentos de software, ainda será necessário manifestá-la e adicionar medidas específicas aos artefatos entregues.

• Forneça evidências de conformidade regulatória e certificações de segurança em sua organização que se apliquem à cadeia de suprimentos de software.
• Adicione uma lista de materiais de software (SBOM) como forma de rastrear dependências e fontes de comprometimento de terceiros em seu software.
• Inclua assinaturas digitais para evitar adulterações e verifique a origem de seus artefatos.
• Use canais de distribuição seguros, comunicações criptografadas e infraestrutura confiável de hospedagem ou armazenamento.

Conclusão

Os ataques à cadeia de suprimentos de software não são realmente algo recente. Ken Thompson, após receber o Turing Award com Dennis Ritchie em 1984, escreveu este discurso sobre a importância da confiança nos provedores de [código] . Ele mostra como uma versão trojanizada do binário do compilador produz versões modificadas do comando “login” Unix com um backdoor.

“Até que ponto se deve confiar em uma declaração de que um programa está livre de cavalos de Tróia? Talvez seja mais importante confiar nas pessoas que escreveram o software.”

Mas a complexidade cada vez maior de software, infraestrutura e dependências, e a taxa de crescimento de ataques direcionados à cadeia de suprimentos, estão deixando indústrias e organizações cada vez mais preocupadas com sua segurança.

Neste ponto, você já percebeu que a cadeia de suprimentos de software é uma rede muito complexa de peças interconectadas e heterogêneas, desde código e bibliotecas até componentes de hardware. Portanto, a abordagem para proteger cada peça e link é muito diferente e não pode ser coberta como um todo. Mas, seja você um fornecedor ou um consumidor (ou ambos), você precisa focar em proteger seus processos e estabelecer conexões fortes com fornecedores confiáveis ​​e verificados . Porque mesmo que você aplique as melhores práticas de segurança e coloque todos os esforços em seu próprio código, infraestrutura, etc., você ainda depende de componentes de terceiros completamente fora de seu controle. E a segurança da cadeia de fornecimento de software depende de cada elo individual.

Autoria,Fonte: Álvaro Iradier, Sysdig.