Porque os pipelines de DevOps estão sob ataque e como revidar

O NotPetya provou a eficácia de um ataque à cadeia de suprimentos de software, e os invasores estão atacando mais agora

Author Photo
4:30 pm - 23 de fevereiro de 2022

Em meados de 2017, invasores patrocinados pelo Estado russo instalaram um worm malicioso em um pacote de software financeiro ucraniano. Quando as empresas atualizaram seu software, foram infestadas. O worm NotPetya se espalhou rapidamente, causando bilhões de dólares em danos ao redor do mundo. A Casa Branca o chamou de “o ataque cibernético mais destrutivo e caro da história”.

Três anos depois, invasores ligados à Rússia sequestraram o processo de atualização de software de outro software corporativo, o conjunto de ferramentas de monitoramento de rede Orion, da SolarWinds. Mais uma vez, o impacto foi generalizado.

“Ter acesso aos pipelines de desenvolvimento de software dá a eles a chance de alcançar a infraestrutura de rede e obter acesso à propriedade intelectual”, diz Viktor Gazdag, Consultor Sênior de Segurança do NCC Group, uma empresa global de consultoria em segurança cibernética.

Ataques em pipelines de DevOps estão aumentando

Pode ser tentador dizer que ataques como esse são isolados e dependem de invasores altamente motivados e qualificados. Na verdade, o pipeline de DevOps se tornou um alvo popular não apenas para atores estatais, mas também para gangues criminosas.

De acordo com um estudo divulgado no mês passado pela Argon, uma empresa da Aqua Security, os ataques à cadeia de suprimentos de software cresceram mais de 300% em relação a 2020. As táticas comuns incluem plantar código malicioso em pacotes populares de código aberto ou explorar vulnerabilidades que já existem, comprometendo as ferramentas de pipeline de CI/CD e aproveitando as credenciais codificadas e outras configurações incorretas e problemas de segurança. O canal de componentes de código aberto foi um alvo particularmente popular.

Os ataques à cadeia de suprimentos de software de código aberto aumentaram 650% no ano passado em comparação com 2020, de acordo com um estudo da Sonatype, divulgado em setembro. A superfície de ataque é vasta. Mais de 37 milhões de componentes e pacotes estão nos quatro principais ecossistemas de código aberto, de acordo com a Sonatype. Os downloads de software de código aberto atingiram 2,2 trilhões no ano passado, um aumento de 73% em relação a 2020.

Porque os pipelines de DevOps são vulneráveis

Os desenvolvedores de software geralmente têm altos níveis de permissão e privilégios de acesso, diz Gazdag. Se o software que está sendo produzido é projetado para consumo externo, o impacto pode ser dramaticamente maior. “Os invasores também têm a oportunidade de se firmar na aplicação final”, diz ele.

Portanto, os pipelines de DevOps devem ter níveis mais altos de segurança. Em vez disso, eles têm muitas práticas de segurança fracas e infraestrutura e credenciais expostas. “Se você usar o Shodan e pesquisar por [ferramenta de desenvolvimento] ‘Jenkins’, poderá ver muita infraestrutura do Jenkins disponível e acessível na Internet”, diz GazDag.

Muitas vezes, a infraestrutura de CI/CD não recebe o mesmo nível de atenção que outras áreas da empresa, diz Gazdag. Com práticas modernas de desenvolvimento, a situação está piorando.

“À medida que as organizações migram para o DevOps, há uma tendência de relaxar alguns dos controles que temos em relação ao desenvolvimento”, diz Dale Gardner, Analista do Gartner. “Queremos ser flexíveis e todo o método DevOps é tentar liberar o código rapidamente. Limites e controles atrapalham isso”.

Tipos de ataques em pipelines de DevOps

De acordo com David Wheeler, Diretor de Segurança da Cadeia de Suprimentos de Código Aberto da Linux Foundation, os três tipos mais comuns de ataques são dependency confusion, typosquatting e injeção de código malicioso.

O dependency confusion, também conhecido como “namespace confusion”, ocorre quando um invasor descobre os nomes de pacotes de software corporativos proprietários e cria pacotes de código aberto com os mesmos nomes e datas de lançamento posteriores. Certas ferramentas de pipeline tentam baixar automaticamente a versão mais recente de um pacote de software e acabam obtendo aquela com a carga maliciosa.

Typosquatting é quando um invasor cria um pacote de software de código aberto com um nome quase idêntico ao real, esperando que um programador cometa um erro de digitação e use a biblioteca errada.

A injeção de código é onde os invasores adicionam código malicioso a um projeto de código aberto legítimo. Eles podem fazer isso roubando as credenciais de um mantenedor do projeto e fazendo o upload do código em seu nome, oferecendo-se para trabalhar no projeto por conta própria ou adulterando ferramentas de desenvolvedor de código aberto.

Vulnerabilidades em componentes de código aberto

Depois, há a questão das vulnerabilidades conhecidas em componentes de código aberto – vulnerabilidades que os invasores são rápidos em explorar. Em abril, a empresa de testes de segurança de aplicativos Synopsys revisou o código de mais de 1.500 projetos de software corporativo, tanto internos quanto comerciais, e descobriu que 98% deles continham algum código-fonte aberto. Para um aplicativo médio, 75% da base de código era de código aberto.

Aqui está a parte assustadora: Na análise da Synopsys, 84% das bases de código tinham pelo menos uma vulnerabilidade. Isso foi antes da vulnerabilidade do Log4J vir à tona, que pesquisadores de segurança chamaram de exploração Java mais perigosa em anos. Além disso, 91% dos componentes de código aberto usados não sofreram manutenção nos últimos dois anos.

Mais de 28.000 novas vulnerabilidades foram divulgadas em 2021, um recorde, de acordo com um relatório divulgado este mês pela Risk Based Security, da Flashpoint. Desses, mais de 4.000 eram exploráveis remotamente, com uma exploração pública e informações de solução documentadas.

A vulnerabilidade do Log4j foi particularmente perigosa, superando todas as outras em impacto, segundo o relatório. A biblioteca foi encontrada em mais de 6.200 outros produtos de software, e o número de recomendações de fornecedores continua aumentando.

Como proteger pipelines de desenvolvimento de software

O que as empresas devem fazer para proteger seus pipelines de desenvolvimento de software? Começa com educação e treinamento para os desenvolvedores, instituindo as melhores práticas, como autenticação de dois fatores e revisões de código, e instalando ferramentas de monitoramento para sinalizar atividades suspeitas.

Tudo começa com os desenvolvedores

No provedor de serviços gerenciados Ensono, David Gochenaur, Diretor Sênior de Segurança Cibernética, diz que tanto os desenvolvedores internos quanto as lojas de software de terceiros precisam de supervisão quando se trata da segurança do processo de desenvolvimento e implantação de código. Os dois grupos de desenvolvedores precisam ser abordados de maneiras diferentes.

A Ensono não vende software, mas precisa de software personalizado para executar seus portais de clientes. A segurança desses portais é de suma importância. “Gerenciamos sistemas para muitos clientes e coletamos dados sobre o status desses sistemas e os colocamos em um portal”, diz Gochenaur.

Isso significa que as ferramentas da Ensono têm acesso a esses sistemas do cliente, o que torna a Ensono um alvo de alto valor para os invasores. “Como há tantos clientes, você quer ter certeza de que o cliente A não pode acessar os dados do cliente B”, diz Gochenaur.

As apostas são altas, diz Gochenaur. “Alguns de nossos clientes são muito sensíveis do ponto de vista da segurança nacional e da privacidade”, diz ele. Portanto, o primeiro desafio é ser muito rigoroso quando se trata de avaliar fornecedores. “Você tem que conhecê-los muito bem”, diz ele. “O incidente da SolarWinds é um bom exemplo e há muitos outros exemplos de terceiros que não se protegeram muito bem e foram usados como pontos de entrada para agentes de ameaças”.

Isso inclui empresas de desenvolvimento de software externas. “Quando usamos terceirizados, nós os examinamos muito para garantir que eles tenham processos e controles em vigor para garantir que tudo o que estamos recebendo deles seja seguro”, diz Gochenaur. Isso inclui revisar seus procedimentos de teste e os controles de segurança que eles têm em seu ambiente de desenvolvimento. “E incluímos penalidades por defeitos nos contratos”, acrescenta.

Então, para os próprios desenvolvedores da empresa, o maior problema é não usar repositórios de código publicamente acessíveis “porque qualquer coisa pode estar lá fora”, diz Gochenaur. “Pode haver um código que parece incrível. Provavelmente é incrível por muitas razões. Ele faz coisas incríveis para você, mas permite que os agentes de ameaças acessem o que quer que esteja acontecendo”.

Os desenvolvedores podem estar tomando muitas outras medidas para ajudá-los a produzir um código mais seguro, diz Gochenaur. Uma estratégia que ajudou a fornecer treinamento e motivação de segurança é executar testes de penetração por terceiros e por equipes internas. “Fará uma enorme diferença na qualidade do produto que é desenvolvido”, diz ele.
Na verdade, quando Gochenaur está executando pen-tests no software da empresa, os desenvolvedores sempre pediram para participar dos testes e observar os hackers de chapéu branco fazendo seu trabalho. “Eles queriam entender o que estavam fazendo e aprender com as vulnerabilidades que os pen-testers encontraram”, diz ele. “Isso deu aos desenvolvedores uma maneira diferente de pensar. Agora, quando eu trago um terceirizado, este é um dos meus requisitos – que as equipes técnicas possam olhar por cima dos ombros e ver o que está acontecendo e aprender com eles”.

Use ferramentas e controles adequados

Para ajudar os desenvolvedores da empresa a tomar boas decisões e mantê-los seguros, a Ensono tem vários controles de segurança implementados. Por exemplo, a autenticação multifator ajuda a impedir que pessoas de fora acessem o pipeline de DevOps. A empresa usa bibliotecas de código privadas para que os desenvolvedores possam escolher um código que já foi revisado e aprovado.

A Ensono também possui equipes dedicadas a corrigir sistemas, para garantir que tudo o que é implantado esteja atual e atualizado. “Verificamos todo o nosso ambiente regularmente em busca de vulnerabilidades”, diz Gochenaur.

As empresas podem fazer outras coisas para ajudar a bloquear seu pipeline de desenvolvimento que muitas vezes são perdidos, diz Venky Chennapragada, Arquiteto de DevOps da Capgemini Americas. Por exemplo, as empresas devem ter pipelines separados para o ambiente de preparação de não produção e para a produção – e para limitar as pessoas que têm acesso a ambos os sistemas. Para bloquear ainda mais o acesso, as empresas devem usar sistemas de gerenciamento de acesso de nível empresarial, como Active Directory ou LDAP.

Muitas empresas têm um banco de dados de usuários separado para as equipes de desenvolvimento de software ou usam ferramentas integradas de gerenciamento de usuários. É mais fácil ter um sistema separado.

“Se eu estiver integrando com o Active Directory ou LDAP, haverá uma auditoria de segurança”, diz Chennapragada. “Alguns engenheiros podem querer ignorar a auditoria de segurança porque não instalaram as coisas corretamente”.

O acesso baseado em função é outro controle com o qual os desenvolvedores podem se irritar. “É sempre fácil dar acesso total e não ter que criar grupos de usuários e funções”, diz Chennapragada, “mas é uma prática ruim”.

Finalmente, Chennapragada recomenda que as organizações rastreiem cuidadosamente todos os componentes que entram em seu software, especialmente as bibliotecas de código aberto. “Os desenvolvedores tendem a incluir código-fonte aberto em seus softwares e isso pode conter bugs e vulnerabilidades de segurança”, diz ele.

Bibliotecas externas precisam passar por verificação de segurança e revisões de código, e os desenvolvedores devem se limitar a usar apenas dependências certificadas. Não são apenas as bibliotecas que os desenvolvedores podem querer tirar da internet. Outras ferramentas atraentes incluem variantes e plugins do sistema operacional.

Linux, por exemplo, vem em milhões de sabores diferentes. “Certifique-se de que qualquer versão que eles usam seja reforçada, seja a mais recente e atualizada”, diz Chennapragada. A popular ferramenta de desenvolvimento Jenkins, um servidor de automação de código aberto, vem com uma variedade de plugins. “Existem plugins para tudo”, diz ele, “mas os plugins podem ser muito vulneráveis. As pessoas podem colocar código malicioso no plugin que pode assumir o controle do seu sistema”.

Muitos controles e processos de segurança que estão disponíveis não custam muito e não criam muita sobrecarga, mas exigem algum planejamento ou treinamento cuidadoso, diz Ilia Kolochenko, CEO da fornecedora de segurança cibernética ImmuniWeb. Por exemplo, a AWS oferece controles e ferramentas de segurança integrados que não são caros nem gratuitos, diz ele. “As pessoas não vão atrás deles porque não sabem, não acham que precisam deles, ou é muito difícil explorá-los e aproveitá-los”.

A nuvem facilita a implantação de ferramentas como monitoramento contínuo de segurança e resposta a incidentes, diz ele. “Você pode detectar atividades suspeitas, interrompê-las imediatamente, substituí-las por uma imagem limpa e continuar suas operações sem ficar off-line. A nuvem oferece muitas oportunidades excelentes para automatizar seu monitoramento contínuo de segurança e resposta a incidentes, mas as pessoas não a usam”.

Solicite SBOMs, mas também verifique vulnerabilidades

Muitos na indústria têm pressionado por uma lista de materiais de software (SBOM). Em maio passado, o presidente Biden emitiu uma ordem executiva exigindo SBOMs de fornecedores que fornecem software ao governo federal. Dois dias depois, a Cloud Native Computing Foundation lançou um white paper de práticas recomendadas sugerindo que todos os fornecedores forneçam um SBOM sempre que possível, com links claros e diretos para dependências.

Um SBOM ajudaria as empresas a encontrar instâncias de componentes vulneráveis em seu ambiente. Por exemplo, o Log4j foi corrigido em dezembro, mas, em 11 de fevereiro, 40% de todos os downloads ainda eram da versão vulnerável.

“Se você compra um pão, tem a lista de ingredientes escrita ao lado”, diz Kayne McGladrey, Membro Sênior do IEEE e Estrategista de Segurança Cibernética da Ascent Solutions, empresa de consultoria em tecnologia. “Ter isso para software permite que as organizações tomem decisões de risco informadas”.

A McGladrey espera que os fornecedores de software com visão de futuro comecem a incluir essas listas em seus softwares porque é algo que seus clientes vão querer ver. Ele recomenda que os fornecedores de software dêem um passo adiante e forneçam informações sobre como seu software deve agir e como não deve agir. “Se os fornecedores de software fornecessem uma lista de comportamentos normais para seus softwares, poderíamos dizer: ‘Este software está se comportando de maneira estranha porque está se conectando a servidores que não deveria'”, diz ele.

Se um SBOM se tornar obrigatório, as empresas devem verificar seu software em busca de vulnerabilidades conhecidas e outros possíveis problemas de segurança. Todos os principais softwares de varredura agora procuram pacotes Log4j vulneráveis, diz Ray Kelly, Membro da NTT Application Security, fornecedor de segurança cibernética.

É claro que as empresas não estão usando as ferramentas. “Mesmo que os patches tenham sido lançados por dois meses, as empresas ainda estão usando versões antigas do Log4j”, diz Kelly. “Isso mostra o quanto muitas organizações estão atrasadas quando se trata de proteger o código”.

Newsletter de tecnologia para você

Os melhores conteúdos do IT Forum na sua caixa de entrada.