O Que É um Ataque no Estilo SolarWinds? Envenenando o Build Para Alcançar Todos
Um ataque no estilo SolarWinds compromete o pipeline de build para injetar um backdoor em atualizações de software legitimamente assinadas, que então alcançam cada cliente como código confiável.
O incidente SolarWinds de 2020 remodelou como a indústria pensa sobre segurança de supply chain. Os atacantes não invadiram os clientes diretamente; eles comprometeram o pipeline de build de um fornecedor confiável e inseriram um backdoor no software durante o build. Como a atualização resultante era assinada e distribuída por canais normais, milhares de organizações instalaram o backdoor como uma atualização confiável.
A anatomia do ataque
- Os atacantes ganharam acesso ao ambiente de build do fornecedor.
- Eles injetaram código malicioso durante o build, não no código-fonte.
- O artifact adulterado foi assinado e liberado como legítimo.
- Os clientes instalaram a atualização envenenada por atualizações normais.
Por que foi tão eficaz
O código malicioso nunca apareceu no repositório de código-fonte, então a revisão de código não o pegaria. Ele foi inserido entre o código-fonte e o artifact, no build. E como o artifact final estava devidamente assinado, toda verificação downstream que confiava na assinatura confiava no backdoor também.
A lição: confie no build, não só no código-fonte
Não basta verificar o código-fonte; você precisa verificar que o artifact foi construído a partir daquele código-fonte por um processo não adulterado. Essa é exatamente a lacuna que procedência e attestation fecham: elas permitem provar que o binário corresponde ao código-fonte e que o build não foi subvertido.
Defesas que o endereçam
Procedência assinada amarra o artifact ao seu código-fonte e build reais. Builds reproduzíveis permitem que partes independentes confirmem que o mesmo código-fonte gera o mesmo binário. Ambientes de build endurecidos e isolados tornam a injeção de código no meio do build muito mais difícil. O framework SLSA foi moldado exatamente por essa ameaça.
Protegendo o ambiente de build
Uma defesa central é tornar o próprio ambiente de build difícil de comprometer e evidente à adulteração. Runners isolados e efêmeros (como o Latchkey) dão a cada build um ambiente novo e contido, encolhendo a infraestrutura de build persistente e privilegiada que um atacante no estilo SolarWinds precisa subverter.
Principais conclusões
- Um ataque no estilo SolarWinds injeta um backdoor durante o build, não no código-fonte.
- Um artifact adulterado mas devidamente assinado contorna a revisão de código e a confiança na assinatura.
- Procedência, builds reproduzíveis e ambientes de build endurecidos são as defesas.