Ataques à Cadeia de Abastecimento: 9 Exemplos e Defesa

Title etiqueta: Exemplos de Ataques à Cadeia de Abastecimento: O Guia Completo (2013–2024) Meta descrição: Saiba o que são ataques à cadeia de abastecimento e explore 9 exemplos importantes desde o SolarWinds ao XZ Utils, com mecanismos de ataque, dados de impacto financeiro e estratégias de defesa.

O que é um choque de oferta e o que isso significa para a cibersegurança

O ataque cibernético mais dispendioso da história registada não começou com um pirata informático a invadir uma rede governamental. Começou com uma atualização de software. Um programa de contabilidade utilizado por milhares de empresas na Ucrânia forneceu discretamente código malicioso que se Spread pelas redes corporativas globais em horas, causando, em última análise, danos estimados em 10 mil milhões de dólares. Esse ataque, o NotPetya, é um dos nove principais exemplos de ataques à cadeia de abastecimento que este guia aborda na íntegra, com o autor, o mecanismo e o impacto financeiro documentado para cada um.

Compreender estes incidentes começa com um conceito da economia: o choque de oferta. Um choque de oferta é uma interrupção súbita e inesperada no fornecimento de um produto ou serviço que se propaga a todos os que dependem dele. Os exemplos clássicos são os embargos de petróleo e os desastres naturais. Estes eventos têm origem num ponto único de uma rede de abastecimento, mas causam danos em cascata a milhares de consumidores a jusante que não tiveram qualquer papel na interrupção original.

Os ataques à cadeia de abastecimento de cibersegurança operam como uma forma de choque de abastecimento digital. Um atacante compromete um fornecedor de software de confiança ou um componente de hardware a montante, e o dano propaga-se automaticamente para todas as organizações que instalam esse software, confiam nesse fornecedor ou dependem desse componente. A vítima não fez nada de errado. As suas próprias defesas foram contornadas por completo. O ataque explorou a cadeia de abastecimento, não o alvo. Tal como um embargo petrolífero pode paralisar indústrias que nunca tocaram numa refinaria, uma atualização de software comprometida pode devastar organizações que nunca interagiram com o atacante.

Este guia abrange a visão completa: o que são ataques à cadeia de abastecimento, como funcionam mecanicamente, todos os principais incidentes nomeados de 2013 a 2024 com dados de impacto quantificados, quem os realiza e porquê, e o que as organizações e os programadores podem fazer para reduzir a exposição.

O que é um ataque à cadeia de abastecimento?

Um ataque à cadeia de abastecimento é um ciberataque que compromete uma organização indiretamente, visando um fornecedor Terceiro de confiança, um componente de software ou um elemento de hardware na cadeia de abastecimento dessa organização. Os atacantes inserem código malicioso ou portas de trás (backdoors) em software ou hardware legítimo a montante, de modo a que as vítimas introduzam a ameaça involuntariamente através de processos rotineiros de atualização ou aquisição. Os controlos de segurança da própria vítima são contornados porque o ataque provém de uma fonte de confiança.

Uma cadeia de fornecimento de software abrange todos os componentes, bibliotecas e processos envolvidos na criação e entrega de um produto de software. Isto inclui dependências de código de terceiros, bibliotecas de código aberto, infraestrutura de compilação, servidores de atualização e firmware de hardware. Qualquer um destes elementos pode servir como um ponto de entrada.

A principal diferença entre um ataque à cadeia de abastecimento e um ciberataque direto é o local onde o atacante ataca. Num ataque direto, o atacante visa os próprios sistemas, aplicações ou utilizadores da vítima e deve superar os controlos de segurança dessa organização. Num ataque à cadeia de abastecimento, o atacante visa um fornecedor em que a vítima já confia, contornando inteiramente esses controlos. Um único fornecedor comprometido pode expor simultaneamente milhares de organizações a jusante.

Uma violação de dados é um resultado, não um método de ataque. Os ataques à cadeia de abastecimento podem causar violações de dados, mas nem todas as violações de dados envolvem comprometimentos da cadeia de abastecimento. Nem todos os ataques à cadeia de abastecimento resultam também em roubo de dados: o NotPetya causou destruição em vez de exfiltração de dados.

--- ## Como Funcionam os Ataques à Cadeia de Abastecimento

Os ataques à cadeia de abastecimento seguem um padrão consistente: os atacantes comprometem um fornecedor de confiança em vez de visar diretamente a organização vítima. O ataque é entregue através dos canais normais de distribuição de software, atualizações ou aquisição de hardware.

O Ciclo de Vida do Ataque: Passo a Passo

1. O atacante identifica um fornecedor de confiança ou componente de software utilizado pelo alvo
2. O atacante obtém acesso ao sistema de compilação, repositório de código ou servidor de atualizações do fornecedor
3. Código malicioso é inserido em software ou hardware legítimo antes da distribuição
4. O fornecedor distribui o produto comprometido através dos seus canais normais e de confiança
5. A organização alvo instala a atualização ou implementa o componente, introduzindo assim a ameaça
6. O atacante utiliza o ponto de entrada estabelecido para movimento lateral, espionagem ou cargas destrutivas

Taxonomia de Vetores de Ataque

Atualizações de Software com Cavalos de Troia

Uma atualização trojanizada é particularmente perigosa porque contorna quase todos os controlos de segurança padrão. A atualização chega de um fornecedor em que a organização já confia, possui um certificado digital legítimo de assinatura de código, passa pelas análises antivírus e de segurança de endpoints, e o utilizador instala-a voluntariamente como parte da manutenção de rotina. Ninguém na organização alvo fez nada de errado.

Um comprometimento do sistema de compilação visa o processo de compilação automatizada que transforma o código fonte em software executável. Um atacante obtém acesso ao ambiente de compilação de um fornecedor e insere código malicioso durante a compilação. O pacote de software resultante parece idêntico à versão legítima. Um pipeline CI/CD (Integração Contínua/Implementação Contínua) comprometido nesta fase propagará código malicioso em todas as versões de software subsequentes, mesmo que o código fonte original permaneça limpo. É por isso que mesmo uma auditoria de código minuciosa do repositório fonte não revelaria o ataque.

Pense nisto desta forma: imagine um fornecedor farmacêutico a substituir discretamente um medicamento legítimo por uma versão contaminada antes do envio. O hospital que o recebe e administra não fez nada de errado. O ataque explorou a cadeia de abastecimento, não o hospital.

SolarWinds, CCleaner e ASUS ShadowHammer seguiram todos este padrão. Em cada caso, os atacantes comprometeram a infraestrutura de compilação do fornecedor em vez das organizações alvo diretamente.

Ataques a registos de pacotes de código aberto

Os registos públicos de pacotes são algumas das superfícies de ataque mais ativas na cadeia de abastecimento de software. Isto inclui npm para JavaScript, PyPI para Python, RubyGems para Ruby, NuGet para .NET e Maven para Java. Só o registo npm aloja mais de dois milhões de pacotes. Um único pacote popular comprometido pode propagar código malicioso em milhões de aplicações.

Três padrões de ataque distintos visam este ecossistema. No typosquatting, um atacante regista um pacote com um nome quase idêntico ao de um pacote legítimo Popular (por exemplo, lodahs em vez de lodash), na esperança de apanhar programadores desatentos. Na dependency confusion, o atacante utiliza exatamente o mesmo nome de um pacote interno privado de uma organização visada num registo público. Os sistemas de compilação que verificam os registos públicos antes dos privados descarregarão a versão maliciosa automaticamente. Na malicious package injection, um pacote legítimo é comprometido após a publicação, seja através do roubo de credenciais do mantenedor ou através de engenharia social do projeto.

A confusão de dependências foi demonstrada publicamente pela primeira vez em grande escala em 2021 pelo investigador de segurança Alex Birsan, que obteve com sucesso a execução de código nos canais de compilação da Apple, Microsoft, PayPal e de outras 35 grandes empresas utilizando esta técnica. O ataque funcionou não devido a um erro, mas sim à forma como os gestores de pacotes resolvem conflitos de nomes entre registos públicos e privados.

Sobre o Log4Shell: O Log4Shell (CVE-2021-44228), a vulnerabilidade crítica descoberta em dezembro de 2021 na biblioteca de registo Java Apache Log4j, é frequentemente descrito como um ataque à cadeia de abastecimento. Não foi. O Log4Shell foi uma vulnerabilidade de software não intencional. Nenhum atacante o inseriu na base de código do Log4j. A confusão surge porque a presença do Log4j como dependência em milhares de produtos de software tornou a identificação de todos os sistemas afetados semelhante a um problema de auditoria da cadeia de abastecimento. O modelo de ameaça é diferente: os ataques à cadeia de abastecimento envolvem código malicioso inserido intencionalmente por um atacante, enquanto o Log4Shell foi uma falha acidental que os atacantes exploraram mais tarde.

Compromisso de MSP e Movimentação Lateral

Um Provedor de Serviços Geridos (MSP) é uma empresa que faz a gestão remota da infraestrutura de TI, segurança e sistemas de uma organização cliente. Os MSPs são comummente utilizados por pequenas e médias empresas que não possuem equipas de TI internas. Comprometer um MSP concede aos atacantes acesso administrativo simultâneo a todos os clientes desse MSP, tornando os MSPs vetores de ataque multiplicadores de força com um alcance desproporcional a jusante. O Aviso AA22-131A da CISA alerta especificamente os MSPs de que estes são alvos de alta prioridade.

Uma vez dentro de qualquer rede, através de uma atualização trojanizada ou dependência comprometida, os atacantes utilizam tipicamente técnicas de movimento lateral. Estas técnicas exploram credenciais legítimas e caminhos de acesso à rede para efetuar um pivô a partir do sistema inicialmente comprometido para alvos mais sensíveis. No ataque SolarWinds, o APT29 utilizou a backdoor SUNBURST como ponto de entrada inicial, movendo-se depois lateralmente para sistemas de email e repositórios de dados sensíveis em várias agências governamentais.

Principais Exemplos de Ataques à Cadeia de Abastecimento

A tabela seguinte resume os exemplos mais significativos de ataques à cadeia de abastecimento de 2013 a 2024, organizados por interveniente, vetor e impacto documentado.

Violação de Dados da Target (2013)

Target (2013) — um grupo criminoso obteve acesso à rede de pontos de venda da Target ao comprometer inicialmente a Fazio Mechanical Services, um empreiteiro de AVAC e refrigeração de Terceiros que detinha credenciais de rede para acesso remoto aos sistemas da Target.

A violação da Target é o exemplo mais antigo amplamente estudado do padrão de ataque da cadeia de abastecimento. Os atacantes não contornaram as defesas de perímetro da Target diretamente. Obtiveram credenciais de um pequeno fornecedor de AVAC, usaram essas credenciais para aceder à rede da Target através de uma via de acesso legítima e, em seguida, moveram-se lateralmente para os sistemas de ponto de venda que processavam dados de cartões de pagamento.

O resultado foi o roubo de dados de cartões de pagamento de aproximadamente 40 milhões de clientes e de dados pessoais de aproximadamente 110 milhões. Os custos totais da Target resultantes da violação excederam os 200 milhões de dólares estimados em acordos, honorários jurídicos e remediação. O ataque estabeleceu o modelo que ataques posteriores refinaram: comprometer um fornecedor de confiança com acesso ao alvo real e, em seguida, utilizar esse acesso como ponto de entrada. As investigações do Serviço Secreto dos EUA e do Departamento de Justiça confirmaram a via do fornecedor Terceiros como o vetor de entrada.

Ataque à Cadeia de Abastecimento SolarWinds (2020)

SolarWinds (2020) — O APT29 (Cozy Bear), atribuído ao Serviço de Informações Externas (SVR) da Rússia, comprometeu o processo de compilação da plataforma de monitorização de TI Orion, inserindo o backdoor SUNBURST numa atualização de software de rotina descarregada por aproximadamente 18.000 clientes da SolarWinds.

A SolarWinds é amplamente considerada o ciberataque à cadeia de abastecimento mais significativo da história registada. O Orion era uma plataforma de monitorização de TI amplamente implementada, utilizada por agências governamentais dos EUA e grandes corporações. Os atacantes inseriram o backdoor SUNBURST no pipeline de compilação do software, o que significa que o código malicioso foi compilado diretamente no pacote de atualização legítimo do Orion, assinado com certificados válidos da SolarWinds e distribuído através de canais oficiais de atualização.

Entre as aproximadamente 18.000 organizações que descarregaram a atualização com o trojan, os atacantes selecionaram alvos de alto valor para exploração secundária. Estes incluíram os Departamentos do Tesouro, do Comércio, da Segurança Interna e de Estado dos EUA, bem como a Microsoft, a FireEye e outras grandes empresas tecnológicas. A intrusão passou despercebida durante aproximadamente nove meses antes de a FireEye a descobrir enquanto investigava uma anomalia nos seus próprios sistemas.

O APT29 utilizou o ponto de apoio SUNBURST como um ponto de acesso inicial, deslocando-se depois lateralmente através de redes comprometidas para aceder a sistemas de e-mail e comunicações sensíveis. A operação foi avaliada como uma campanha de espionagem em vez de um ataque destrutivo. A resposta do governo dos EUA, coordenada através do Aviso da CISA AA20-352A,), incluiu diretivas de emergência que afetaram todas as agências civis federais.

NotPetya (2017)

NotPetya (2017) — Sandworm, atribuído à inteligência militar GRU da Rússia (Unidade 74455), injetou código malicioso numa atualização de software para M.E.Doc, uma aplicação de contabilidade ucraniana utilizada por uma grande porção das empresas a operar na Ucrânia.

O NotPetya não era ransomware. Exibia uma nota de resgate, mas isso era um disfarce. O código sobrescreveu o Master Boot Record (MBR) de sistemas infetados e tornou-os permanentemente irrecuperáveis. Era um wiper destrutivo concebido para causar o máximo de dano, sem um mecanismo de pagamento real. A aparência semelhante a um resgate foi concebida para obscurecer a atribuição durante a resposta inicial.

O ponto de entrada inicial da infeção foi a atualização do M.E.Doc, mas o NotPetya propagou-se rapidamente para além da Ucrânia através da exploração EternalBlue e propagação em rede, tornando-se uma catástrofe global em poucas horas. Danos totais foram estimados em aproximadamente 10 mil milhões de dólares a nível mundial, tornando-o o ciberataque mais destrutivo da história em termos de impacto financeiro. Vítimas nomeadas incluem o gigante do transporte marítimo Maersk (aproximadamente 300 milhões de dólares em danos; a empresa teve de reinstalar 45.000 PCs e 4.000 servidores do zero), o fabricante farmacêutico Merck, FedEx/TNT Express, e a Mondelez International. Muitas destas organizações não tinham qualquer ligação direta com a Ucrânia e foram vítimas colaterais alcançadas através da conectividade de rede global.

O ataque está documentado detalhadamente na investigação retrospetiva da Wired) e é atribuído ao Sandworm pelos Estados Unidos, Reino Unido e Austrália. O Sandworm é distinto do APT29/Cozy Bear: operam sob diferentes agências de inteligência russas (GRU vs. SVR) com mandatos operacionais distintos.

Ataque Kaseya VSA (2021)

Kaseya VSA (2021) — REvil, um grupo cibercriminoso de ransomware como serviço sem afiliação a estados-nação, explorou uma vulnerabilidade de dia zero no Kaseya VSA para enviar atualizações maliciosas aos clientes MSP simultaneamente.

Kaseya VSA é uma plataforma de monitorização e gestão remota amplamente utilizada por Provedores de Serviços Geridos. REvil, um grupo criminoso com motivação financeira, identificou a superfície de ataque dos MSP e explorou-a em larga escala. Ao comprometer a plataforma VSA, a REvil conseguiu enviar atualizações maliciosas, que pareciam ter origem no MSP de confiança, para todas as organizações clientes a jusante, de uma só vez.

O resultado: cerca de 60 MSPs foram comprometidos e, através deles, aproximadamente 1.500 empresas a jusante foram atingidas por ransomware (malware que encripta os dados de uma vítima e exige pagamento pela chave de desencriptação). A REvil exigiu 70 milhões de dólares em Bitcoin por um desencriptador universal. O ataque ilustrou a lógica do multiplicador de força do direcionamento a MSPs com particular clareza: uma Plataforma comprometida atingiu centenas de organizações numa única operação. Aviso CISA AA21-200B) fornece a análise técnica completa.

Ataque à Cadeia de Abastecimento Codecov (2021)

Codecov (2021) — um atacante não identificado adulterou o script Codecov Bash Uploader, uma ferramenta de relatório de cobertura de código incorporada nos pipelines de CI/CD de milhares de organizações, e utilizou-o para exfiltrar variáveis de ambiente, incluindo credenciais e tokens de API.

O Codecov é um serviço de análise de cobertura de código utilizado por equipas de desenvolvimento de software para monitorizar a cobertura de testes. O atacante modificou o script Bash Uploader que as organizações descarregam e executam como parte dos seus processos de build automatizados. Uma vez que o script era executado dentro do ambiente de CI/CD, tinha acesso direto a variáveis de ambiente contendo credenciais, tokens e chaves de acesso a repositórios.

A violação permaneceu indetetada por aproximadamente dois meses antes de a Codecov a descobrir em abril de 2021. Entre as organizações afetadas estavam a Twilio, a HashiCorp e a Confluent, que revelaram que credenciais tinham sido expostas. O ataque demonstrou um vetor de cadeia de abastecimento específico de CI/CD: em vez de comprometer o produto de software final, os atacantes visaram as ferramentas que as organizações utilizam para construir e testar software. Este ataque situa-se na intersecção do comprometimento do pipeline de compilação e do roubo de credenciais, representando um padrão distinto dos vetores de distribuição de atualizações utilizados no SolarWinds e no CCleaner.

Ataque à Cadeia de Abastecimento do CCleaner (2017)

CCleaner (2017) — o grupo AXIOM, atribuído a hacking patrocinado pelo estado chinês, comprometeu o ambiente de compilação da Piriform (a programadora do CCleaner) e inseriu o malware Floxif no instalador legítimo do CCleaner distribuído através de canais oficiais.

O CCleaner é um utilitário de otimização de PC Popular com milhões de utilizadores domésticos e empresariais. O ataque demonstrou que os comprometimentos da cadeia de abastecimento não se limitam a software empresarial. Aproximadamente 2,27 milhões de utilizadores descarregaram a versão infetada com o trojan antes de o comprometimento ser detetado.

O ataque teve uma segunda fase: uma carga útil direcionada foi pré-configurada para ativar apenas em sistemas pertencentes a aproximadamente 40 empresas de alta tecnologia, incluindo Cisco, Intel, Samsung e Sony. Para a vasta maioria dos utilizadores afetados, o malware recolheu dados passivamente. Para as empresas de tecnologia visadas, representou uma intrusão séria em redes sensíveis. A análise da Cisco Talos) da infraestrutura de comando e controlo do CCleaner forneceu a primeira análise técnica completa do ataque.

ASUS ShadowHammer (2019)

ASUS ShadowHammer (2019) — o grupo BARIUM, atribuído a ciberataques patrocinados pelo Estado chinês, comprometeu a utilidade Live Update da ASUS e distribuiu uma versão com backdoor assinada com certificados digitais legítimos da ASUS através de servidores de atualização oficiais da ASUS.

Este ataque demonstrou uma implicação significativa para a confiança digital: certificados de assinatura de código legítimos não podem ser considerados prova de integridade de software caso a própria infraestrutura de assinatura tenha sido comprometida. A atualização trojanizada da ASUS continha certificados válidos da ASUS e foi distribuída através do mecanismo oficial de atualizações da ASUS, passando em todas as verificações de Verificação padrão. Aproximadamente 500.000 utilizadores da ASUS receberam a atualização com backdoor.

Os atacantes não estavam interessados em todos os 500.000 utilizadores. O payload malicioso estava pré-configurado para ser ativado apenas em sistemas com aproximadamente 600 endereços MAC específicos, o que indica a existência de informações prévias sobre os alvos específicos. A campanha foi descoberta e documentada pela equipa de investigação da Kaspersky (Securelist) em 2019.

Os ataques à cadeia de abastecimento de hardware e firmware geram uma preocupação particular: as modificações efetuadas ao nível do firmware persistem após reinstalações do sistema operativo e permanecem invisíveis para as ferramentas de segurança baseadas em software.

Ataque à Cadeia de Abastecimento da 3CX (2023)

3CX (2023) — O Grupo Lazarus, atribuído ao Gabinete Geral de Reconhecimento da Coreia do Norte (RGB), executou o primeiro ataque de cadeia de abastecimento sobre cadeia de abastecimento confirmado publicamente, alcançando o ambiente de compilação da 3CX através de uma violação prévia da cadeia de abastecimento do software Trading Technologies.

O computador pessoal de um funcionário da 3CX foi comprometido através de um instalador infetado com um trojan para o X_TRADER da Trading Technologies, uma plataforma de negociação financeira. Esse instalador da Trading Technologies tinha sido, ele próprio, comprometido na sua cadeia de abastecimento pelo Lazarus Group numa operação anterior. A máquina comprometida do funcionário deu aos atacantes acesso ao ambiente de compilação da 3CX, que utilizaram para inserir malware na 3CX Desktop App, uma plataforma de comunicações VoIP utilizada por mais de 600.000 empresas e 12 milhões de utilizadores diários em todo o mundo.

O ataque visou desproporcionalmente empresas do setor financeiro. Como a violação da 3CX foi, por si só, a consequência a jusante de um ataque anterior à cadeia de abastecimento, este é o primeiro caso confirmado de um ataque à cadeia de abastecimento a desencadear um segundo ataque à cadeia de abastecimento. A implicação prática: as organizações precisam agora de considerar não só se os seus fornecedores diretos são seguros, mas também se os fornecedores dos seus fornecedores foram comprometidos. A análise técnica completa está documentada em análise de incidente da Mandiant.

Backdoor XZ Utils (2024)

XZ Utils (2024) — operando sob a identidade fabricada "Jia Tan", no que os investigadores de segurança avaliam ter sido uma operação de um estado-nação com base em indicadores comportamentais, sem atribuição pública definitiva confirmada, um interveniente desconhecido passou aproximadamente dois anos a infiltrar-se no projeto de código aberto XZ Utils antes de inserir uma porta dos fundos (backdoor) visando a autenticação SSH em sistemas Linux.

O XZ Utils é uma biblioteca de compressão de dados que corre como infraestrutura invisível em milhões de servidores Linux. Não é uma aplicação voltada para o utilizador, mas sim o tipo de software fundamental do qual outros softwares dependem silenciosamente. Um atacante operando como "Jia Tan" começou a contribuir com código legítimo e de alta qualidade para o projeto XZ Utils em 2022, construindo credibilidade e, eventualmente, obtendo privilégios de commit através de um envolvimento contínuo com o mantenedor do projeto.

No início de 2024, "Jia Tan" inseriu um backdoor nas versões 5.6.0 e 5.6.1 do XZ Utils. O backdoor foi concebido para comprometer a autenticação SSH em distribuições Linux afetadas, dando potencialmente ao atacante acesso remoto a qualquer servidor a executar a versão afetada da biblioteca. O SSH é o principal protocolo de administração remota para servidores Linux em todo o mundo, tornando o potencial âmbito de impacto substancial.

A backdoor foi detetada antes da sua implementação generalizada por Andres Freund, um engenheiro da Microsoft que detetou um consumo invulgar da CPU e uma degradação do desempenho do SSH durante o trabalho de rotina e rastreou a origem. A sua descoberta, publicada em março de 2024, evitou um comprometimento da cadeia de abastecimento que poderia ter afetado milhões de servidores. O aviso da OpenSSF (CVE-2024-3094) fornece o relato técnico completo.

Porque são tão perigosos os ataques à cadeia de abastecimento

Os ataques à cadeia de abastecimento são difíceis de detetar e parar porque exploram a confiança que as organizações depositam nos seus fornecedores de software, e não as vulnerabilidades nos sistemas próprios das organizações. Quatro fatores agravam o desafio da deteção.

O software malicioso provém de uma fonte fidedigna: um fornecedor cujos certificados, domínios e infraestrutura de atualização a organização visada já autorizou. As atualizações com cavalos de Troia transportam frequentemente certificados de assinatura de código digital válidos emitidos para o fornecedor legítimo, pelo que a verificação do certificado é concluída sem problemas. As ferramentas de antivírus e de deteção de endpoints podem não sinalizar software assinado por um fornecedor fidedigno e fornecido através de canais oficiais. Os atacantes sofisticados também atrasam deliberadamente as operações ativas após o acesso inicial para evitar acionar a deteção de anomalias. O APT29 operou dentro das redes comprometidas da SolarWinds durante aproximadamente nove meses antes da deteção, um tempo de permanência (dwell time) que ilustra quão longo pode ser o intervalo entre o comprometimento e a descoberta.

Os ataques à cadeia de abastecimento aumentaram em frequência e sofisticação ao longo da última década. Os relatórios do Panorama de Ameaças da ENISA documentam uma tendência ascendente sustentada, com os ataques à cadeia de abastecimento identificados como uma categoria de ameaça de topo para os setores de infraestruturas críticas. A escalada é visível no registo histórico: o comprometimento do CCleaner em 2017 afetou 2,27 milhões de utilizadores; a operação SolarWinds em 2020 comprometeu mais de 100 agências governamentais dos EUA; o quase-acidente do XZ Utils em 2024 visou a infraestrutura central do Linux utilizada por milhões de servidores a nível global. A ambição do ataque cresceu substancialmente a cada ciclo.

As consequências financeiras correspondem a essa escala. O NotPetya causou danos globais estimados em 10 mil milhões de dólares, com a Maersk a reportar, sozinha, aproximadamente 300 milhões de dólares. O ataque à Kaseya gerou um pedido de resgate de 70 milhões de dólares abrangendo 1500 empresas afetadas. A resposta do governo dos EUA ao SolarWinds custou centenas de milhões em remediação e investimento em segurança reforçada. Organizações governamentais e do setor público (SolarWinds), empresas de serviços financeiros (3CX), empresas de tecnologia (alvos de segunda fase do CCleaner) e operadores de infraestruturas críticas em todos os setores prioritários designados pela CISA foram todos visados. Nenhuma indústria que dependa de software de Terceiros ou de serviços geridos permaneceu fora do âmbito.

Quem Realiza Ataques à Cadeia de Abastecimento

Os ataques à cadeia de abastecimento são conduzidos por duas categorias distintas de agentes de ameaça: grupos de Ameaça Persistente Avançada (APT) de estados-nação e organizações criminosas com motivação financeira.

Uma Ameaça Persistente Avançada (APT) refere-se a um ator de ameaça sofisticado e bem-resourced, tipicamente uma agência de inteligência de um estado-nação ou unidade cibernética militar, que conduz campanhas de intrusão direcionadas e de longa duração com objetivos estratégicos específicos. As APTs preferem ataques à cadeia de abastecimento, pois uma única compromisso a montante fornece acesso simultâneo a centenas ou milhares de alvos de alto valor, maximizando o retorno de inteligência de uma única operação, minimizando assim o risco de deteção. A atribuição da atividade de APT é probabilística, baseada em indicadores forenses, incluindo sobreposições de código, padrões de infraestrutura e temporização operacional, em vez de provas diretas.

Os grupos de estados-nação atribuídos a ataques documentados à cadeia de abastecimento incluem: APT29 (Cozy Bear), atribuído ao Serviço de Inteligência Estrangeira (SVR) da Rússia, que conduziu a operação SolarWinds; Sandworm, atribuído à inteligência militar (GRU) da Rússia, que conduziu o NotPetya através do M.E.Doc; Lazarus Group, atribuído ao Gabinete Geral de Reconhecimento da Coreia do Norte, que conduziu o ataque 3CX; o grupo BARIUM, atribuído a operações patrocinadas pelo estado chinês, que conduziu o ASUS ShadowHammer; e o grupo AXIOM, também atribuído a operações patrocinadas pelo estado chinês, que conduziu o ataque CCleaner. O BARIUM e o AXIOM são grupos distintos, apesar de ambos terem atribuição chinesa.

Nem todos os ataques à cadeia de abastecimento são operações de Estados-nação. O ataque ao Kaseya VSA foi conduzido pelo REvil, uma organização cibercriminosa de língua russa que opera como ransomware-as-a-service, sem qualquer afiliação a Estados-nação. Grupos criminosos com motivações financeiras adotaram técnicas de cadeia de abastecimento porque comprometer um único MSP (Prestador de Serviços Geridos) distribui ransomware para centenas de organizações clientes numa única operação, aumentando drasticamente o retorno em comparação com o ataque a vítimas individuais.

Como Defender Contra Ataques à Cadeia de Suprimentos

A defesa contra ataques à cadeia de abastecimento exige que o seu programa de segurança se estenda para além dos seus próprios sistemas, abrangendo os fornecedores, os componentes de software e a infraestrutura de que a sua organização depende. O objetivo não é construir um perímetro perfeito, mas sim reduzir o raio de explosão quando um fornecedor de confiança é comprometido.

Lista de Verificação de Defesa Empresarial e Organizacional

• Implemente uma política de Lista de Materiais de Software (SBOM) para todo o software que a sua organização adquire ou desenvolve, de modo a poder identificar os componentes afetados quando um comprometimento da cadeia de abastecimento é divulgado
• Audite as práticas de segurança de fornecedores Terceiros antes da aquisição e anualmente, utilizando questionários normalizados alinhados com a norma NIST SP 800-161r1
• Exija que os fornecedores forneçam SBOMs atuais para todos os produtos de software que entrem no seu ambiente, como parte do seu processo de aquisição e contratação
• Aplique princípios de arquitetura zero trust: aplique o acesso com privilégios mínimos para todo o software e serviços, implemente a microssegmentação de rede para conter movimentos laterais e verifique continuamente em vez de confiar na localização da rede
• Monitorize comportamentos anómalos em software de fornecedores fidedignos, pois os desvios de comportamento em relação a bases de referência conhecidas podem indicar uma atualização comprometida, mesmo quando as assinaturas são válidas
• Reveja as certificações de segurança de fornecedores (SOC 2 Tipo II, ISO 27001) e inclua requisitos de segurança explícitos e obrigações de notificação de falhas de segurança nos contratos com fornecedores
• Siga as orientações de segurança da cadeia de abastecimento da CISA) e implemente o quadro NIST SP 800-161r1 (C-SCRM) para alargar a sua gestão de riscos a fornecedores Terceiros
• Mantenha um plano de resposta a incidentes que cubra explicitamente comprometimentos de software de terceiros, incluindo procedimentos para o isolamento de emergência de software afetado em todo o seu ambiente

O que é uma Lista de Materiais de Software (SBOM)?

Uma Software Bill of Materials (SBOM) é um inventário legível por máquina de todos os componentes, bibliotecas e dependências incluídos num produto de software. A analogia funcional é um rótulo nutricional para software: onde um rótulo nutricional lista ingredientes e quantidades, um SBOM lista todas as bibliotecas de código aberto, componentes de Terceiros e dependências diretas utilizadas na criação de uma aplicação, juntamente com números de versão e informações de licenciamento.

Uma SBOM é importante para a segurança da cadeia de fornecimento porque responde à pergunta que as organizações têm dificuldade em responder durante um incidente: "Estamos afetados?" Quando o caso SolarWinds foi divulgado, as organizações sem um inventário de software tiveram de auditar manualmente todos os sistemas para determinar se executavam o Orion. As organizações com SBOMs atuais puderam consultar o seu inventário diretamente. A mesma lógica aplicou-se durante o "quase-acidente" com o XZ Utils: saber quais servidores executavam qual versão da biblioteca fez a diferença entre horas de tempo de resposta e semanas de incerteza.

Ordem Executiva 14028 sobre a Melhoria da Cibersegurança da Nação (assinada em maio de 2021, em resposta direta ao ataque à SolarWinds) determinou que os fornecedores de software que vendem ao governo federal dos EUA forneçam SBOMs. A CISA publicou orientações para a implementação de SBOM tanto para produtores como para consumidores. Ferramentas como SPDX, CycloneDX e Syft podem gerar SBOMs automaticamente a partir da maioria das bases de código e imagens de contentores.

Arquitetura Zero Trust e Defesa da Cadeia de Abastecimento

A arquitetura zero trust reduz os danos que um ataque à cadeia de abastecimento pode causar ao aplicar o princípio de "nunca confiar, verificar sempre" a todos os pedidos de acesso, incluindo pedidos de software que pareçam provir de fornecedores fidedignos. Os ataques à cadeia de abastecimento têm sucesso especificamente ao explorarem a confiança implícita. O modelo zero trust remove essa confiança implícita da equação.

Os três controlos mais diretamente relevantes para a defesa da cadeia de abastecimento são: acesso com privilégio mínimo (limitando o que qualquer software comprometido pode aceder dentro da sua rede, de modo que uma atualização com backdoor não consiga aceder a sistemas para além do seu âmbito legítimo); microssegmentação de rede (contendo o movimento lateral para que um atacante que obtenha uma cabeça de ponte inicial não consiga propagar-se livremente); e monitorização comportamental contínua (detetando atividade anómala de software confiável, mesmo quando a entrada inicial contornou a deteção baseada em assinaturas).

Zero trust é uma filosofia de segurança e um modelo de arquitetura, não um produto de software para compra. As principais referências de autoridade são o CISA Zero Trust Maturity Model e o NIST SP 800-207.

Checklist de Defesa para Developer e DevOps

Os programadores e engenheiros DevOps têm controlo direto sobre as superfícies de ataque mais visadas em ataques à cadeia de fornecimento de código aberto. Estas ações reduzem a exposição do seu pipeline:

• Fixar e bloquear as versões das dependências em todos os manifestos de pacotes (package-lock.json, requirements.txt, Gemfile.lock) para que uma versão maliciosa recém-publicada não possa ser automaticamente descarregada na próxima compilação
• Configure o seu sistema de compilação para preferir registos privados em detrimento dos públicos e reserve todos os namespaces de pacotes internos em registos públicos para prevenir ataques de confusão de dependências
• Execute a análise automatizada de dependências em cada compilação utilizando ferramentas como Dependabot, OWASP Dependency-Check ou Snyk para sinalizar pacotes conhecidos por serem vulneráveis ou suspeitos antes de chegarem à produção
• Gere um SBOM para cada lançamento utilizando CycloneDX ou Syft, e armazene-o juntamente com os seus artefactos de compilação para que tenha um inventário de componentes auditável para cada versão implementada
• Exija commits assinados e aplique regras de proteção de ramos no seu pipeline de compilação principal para prevenir a entrada de código não autorizado no processo de compilação
• Audite pacotes de Terceiros antes de os adicionar: verifique o histórico de publicações do mantenedor, contagem de downloads, atividade do repositório e se o pacote foi recentemente transferido para um novo proprietário

Segurança da Cadeia de Abastecimento: Requisitos Regulamentares e de Conformidade

Vários quadros regulamentares importantes exigem agora explicitamente que as organizações abordem os riscos de segurança da cadeia de abastecimento como parte das suas obrigações de cibersegurança. Estes requisitos passaram de orientações a mandatos, em grande parte como resultado do ataque à SolarWinds.

Quadro Regulamentar dos EUA

Nos Estados Unidos, o principal gatilho regulatório foi a Ordem Executiva 14028 sobre a Melhoria da Cibersegurança Nacional, assinada pelo Presidente Biden em 12 de maio de 2021, em resposta direta ao ataque SolarWinds e ao incidente Kaseya VSA. A OE 14028 determinou que os fornecedores de software que vendem ao governo federal dos EUA devem fornecer uma Lista de Materiais de Software (SBOM) para os seus produtos. Dirigiu o NIST a desenvolver orientações de segurança da cadeia de suprimentos e a CISA a implementar normas SBOM. Esta determinação aplica-se aos fornecedores que abastecem o governo federal. Não exige diretamente SBOMs de todas as organizações do setor privado, embora as normas que gerou tenham sido amplamente adotadas como requisitos de aquisição em contextos empresariais.

A principal referência de normas técnicas é o NIST SP 800-161r1 ("Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations"), que estende as estruturas padrão de gestão de risco de cibersegurança para abranger explicitamente fornecedores Terceiros, vendedores e componentes de software. O C-SCRM (Cyber Supply Chain Risk Management) sob o NIST SP 800-161r1 exige que as organizações realizem avaliações de risco de fornecedores, verifiquem a proveniência do software, exijam SBOMs na aquisição e mantenham planos de resposta a incidentes que considerem comprometimentos de Terceiros. A publicação da CISA "Defending Against Software Supply Chain Attacks" fornece orientação de implementação prática alinhada com os requisitos da EO 14028.

Estrutura Regulamentar da UE

As organizações europeias enfrentam requisitos paralelos ao abrigo de dois quadros. A Diretiva NIS2 (Diretiva sobre Segurança das Redes e da Informação 2) exige que as organizações em setores críticos, incluindo energia, transportes, saúde e infraestruturas digitais, abordem os riscos de segurança da cadeia de abastecimento como parte das suas obrigações obrigatórias de gestão de risco de cibersegurança. O DORA (Regulamento sobre a Resiliência Operacional Digital) aplica-se a entidades do setor financeiro na UE e inclui requisitos detalhados para a gestão do risco de fornecedores de serviços de Terceiros TIC, abordando diretamente os vetores de ataque da cadeia de abastecimento. A ENISA (Agência da União Europeia para a Cibersegurança) serve como a principal fonte autoritativa para as organizações da UE, preenchendo um papel equivalente ao da CISA nos Estados Unidos.

Resumo de Referências Regulamentares

Perguntas Frequentes Sobre Ataques à Cadeia de Abastecimento

O que é um ataque à cadeia de abastecimento?

Um ataque à cadeia de abastecimento visa uma organização indiretamente, comprometendo um fornecedor Terceiros fidedigno, um componente de software ou um elemento de hardware. Os atacantes inserem código malicioso a montante para que as vítimas introduzam a ameaça sem saberem, através de atualizações de software rotineiras ou da aquisição de hardware. Não é necessária qualquer vulnerabilidade nos sistemas da própria vítima. O ataque é bem-sucedido porque chega através de um canal que a vítima já autorizou.

Quais são alguns exemplos de ataques à cadeia de abastecimento?

Os exemplos mais significativos de ataques à cadeia de abastecimento de 2013 a 2024:

• SolarWinds (2020): Backdoor SUNBURST inserido em atualizações da Plataforma Orion; atingiu aproximadamente 18.000 clientes, incluindo mais de 100 agências do governo dos EUA
• NotPetya (2017): Wiper destrutivo entregue através de atualizações do software de contabilidade M.E.Doc; causou um prejuízo estimado em 10 mil milhões de dólares em danos globais
• Kaseya VSA (2021): REvil utilizou uma vulnerabilidade zero-day no VSA para entregar ransomware a mais de 1.500 empresas através de MSPs comprometidos
• XZ Utils (2024): Campanha de engenharia social de dois anos quase inseriu um backdoor SSH na infraestrutura Linux a nível mundial
• CCleaner (2017): Malware Floxif atingiu 2,27 milhões de utilizadores; a segunda fase visou 40 grandes empresas de tecnologia
• ASUS ShadowHammer (2019): Firmware backdoor assinado com certificados válidos da ASUS atingiu 500.000 utilizadores
• 3CX (2023): Primeiro ataque confirmado de cadeia de abastecimento sobre cadeia de abastecimento; atingiu mais de 600.000 empresas através do Grupo Lazarus

Como funciona um ataque à cadeia de abastecimento?

Ataques à cadeia de abastecimento seguem uma sequência repetível:

1. O atacante seleciona um fornecedor de confiança ou uma dependência de software de que o alvo depende
2. O atacante ganha acesso ao ambiente de compilação, ao repositório de código ou à infraestrutura de atualização desse fornecedor
3. Código malicioso é inserido em software legítimo antes de ser distribuído
4. O fornecedor envia o produto comprometido através dos seus canais normais e de confiança
5. O alvo instala a atualização, trazendo a ameaça para dentro do seu próprio perímetro
6. O atacante ativa o ponto de apoio para espionagem, roubo de dados ou cargas úteis destrutivas

Qual é o ataque à cadeia de abastecimento mais famoso?

O ataque à SolarWinds (2020) é amplamente considerado o mais significativo ciberataque da cadeia de abastecimento da história. O APT29, atribuído ao serviço de inteligência russo SVR, inseriu a backdoor SUNBURST nas atualizações do SolarWinds Orion, atingindo aproximadamente 18 000 clientes, incluindo mais de 100 agências governamentais dos EUA. A violação passou despercebida durante aproximadamente nove meses e desencadeou diretamente a Ordem Executiva 14028 para Melhorar a Cibersegurança da Nação.

Porque são os ataques à cadeia de abastecimento tão perigosos?

Os ataques à cadeia de abastecimento apresentam riscos compostos por quatro razões. O software malicioso chega de um fornecedor em que a organização já confia, contornando as defesas de perímetro sem explorar qualquer falha nos sistemas da própria organização alvo. As atualizações Trojanizadas possuem assinaturas digitais válidas, passando nas verificações de certificado. As ferramentas antivírus podem não detetar software assinado e entregue pelo fornecedor. Atacantes sofisticados permanecem dormentes após o acesso inicial para evitar desencadear a deteção de anomalias comportamentais. A operação SolarWinds persistiu detetada durante nove meses. Um fornecedor comprometido pode alcançar milhares de organizações a jusante, escalando o impacto de uma única intrusão muito para além do que os ataques diretos normalmente alcançam.

Os ataques à cadeia de abastecimento estão a aumentar?

Ataques à cadeia de abastecimento aumentaram em frequência e sofisticação ao longo da última década. Os relatórios anuais da ENISA sobre o Cenário de Ameaças documentam os ataques à cadeia de abastecimento como uma categoria de ameaça sustentada e crescente, com o volume de ataques a aumentar ano após ano. A trajetória é visível nos próprios incidentes: desde a violação da Target em 2013, possibilitada por um pequeno empreiteiro de AVAC, à campanha de espionagem SolarWinds de 2020 que afetou o governo dos EUA, ao quase incidente do XZ Utils em 2024 que visou a infraestrutura central do Linux. Grupos criminosos com motivação financeira também adotaram métodos de cadeia de abastecimento, como demonstrou o ataque à Kaseya: uma única Plataforma MSP comprometida alcançou centenas de organizações clientes em horas.

Como podem as organizações defender-se contra ataques à cadeia de abastecimento?

As organizações podem reduzir a sua exposição a ataques na cadeia de abastecimento mediante estas ações:

• Implementar uma política de Software Bill of Materials (SBOM) para manter um inventário completo de componentes de software e identificar sistemas afetados quando for revelada uma violação de segurança
• Exigir que os fornecedores forneçam SBOMs e demonstrem certificações de segurança atuais (SOC 2, ISO 27001) como condições de contratação
• Aplicar princípios de arquitetura zero trust: acesso com privilégios mínimos, microsegmentação de rede e monitorização comportamental contínua
• Monitorizar software de fornecedores fidedignos para anomalias comportamentais, e não apenas indicadores baseados em assinaturas
• Seguir as orientações de segurança da cadeia de abastecimento da CISA e alinhar os processos de avaliação de risco de fornecedores com a norma NIST SP 800-161r1 (C-SCRM)
• Manter um plano de resposta a incidentes que abranja explicitamente comprometimentos de software de Terceiros

Notas de publicação: (1) Implementar o esquema de dados estruturados FAQPage na secção de Perguntas Frequentes e o esquema de Artigo na página completa, para maximizar a elegibilidade para funcionalidades de Perguntas Relacionadas (People Also Ask) e resultados ricos. (2) Citações externas neste artigo ligam para a CISA, NIST, Mandiant, Kaspersky/Securelist, Wired, OpenSSF e Cisco Talos como fontes autoritativas. (3) Ligações internas para conteúdo relacionado de cibersegurança neste site (guias de ataques de ransomware, explicadores de arquitetura de confiança zero, recursos de implementação de SBOM, guias de gestão de risco de fornecedores, visões gerais de atores de ameaças APT) devem ser adicionadas pela equipa de publicação antes da implementação. O índice do site não continha artigos de cibersegurança indexados na altura da escrita, pelo que a colocação de ligações internas requer revisão manual pela equipa editorial.