Postura de segurança do ambiente de DevOps

Com um aumento de ataques cibernéticos a sistemas de gerenciamento de código-fonte e pipelines de integração contínua/entrega contínua, proteger as plataformas de DevOps contra a ampla gama de ameaças identificadas na Matriz de Ameaças de DevOps é crucial. Esses ataques cibernéticos podem permitir a injeção de código, o escalonamento de privilégios e a exfiltração de dados, potencialmente levando a um impacto extenso.

A gestão de postura de DevOps é uma funcionalidade do Microsoft Defender for Cloud que:

• Fornece informações sobre a postura de segurança de todo o ciclo de vida da cadeia de suprimentos de software.
• Utiliza scanners avançados para avaliações aprofundadas.
• Abrange vários recursos, desde organizações, pipelines e repositórios.
• Permite que os clientes reduzam sua superfície de ataque descobrindo e agindo de acordo com as recomendações fornecidas.

Scanners de DevOps

Para fornecer resultados, a gestão de postura de DevOps utiliza scanners de DevOps para identificar fraquezas no gerenciamento de código-fonte e pipelines de integração contínua/entrega contínua, realizando verificações nas configurações de segurança e controles de acesso.

Os scanners de DevOps e GitHub do Azure são usados internamente na Microsoft para identificar riscos associados aos recursos de DevOps, reduzindo a superfície de ataque e fortalecendo os sistemas de DevOps corporativos.

Depois que um ambiente de DevOps é conectado, o Defender for Cloud configura automaticamente esses scanners para realizar verificações recorrentes a cada 24 horas em vários recursos de DevOps, incluindo:

• Compilações
  
• Ficheiros Seguros
• Grupos de variáveis
• Conexões de serviço
• Organizações
• Repositórios

Redução de riscos da matriz de ameaças de DevOps

O gerenciamento de postura de DevOps auxilia as organizações a descobrir e corrigir configurações incorretas prejudiciais na plataforma DevOps. Isso leva a um ambiente de DevOps resiliente e de confiança zero, que é fortalecido contra uma série de ameaças definidas na matriz de ameaças de DevOps. Os principais controlos de gestão postural incluem:

• Acesso secreto com escopo: minimize a exposição de informações confidenciais e reduza o risco de acesso não autorizado, vazamentos de dados e movimentos laterais, garantindo que cada pipeline tenha acesso apenas aos segredos essenciais para sua função.
  
• Restrição de corredores auto-hospedados e permissões altas: impeça execuções não autorizadas e possíveis escaladas, evitando corredores auto-hospedados e garantindo que as permissões de pipeline sejam somente leitura.
  
• Proteção aprimorada de ramificação: mantenha a integridade do código aplicando regras de proteção de ramificação e evitando injeções de código mal-intencionado.
  
• Permissões otimizadas e repositórios seguros: reduza o risco de acesso não autorizado, modificações rastreando permissões básicas mínimas e habilitando a proteção secreta por push para repositórios.
  

Matriz de ameaças de DevOps

Nosso objetivo para desenvolver a matriz de ameaças para DevOps é construir uma base de conhecimento abrangente que os defensores possam usar para acompanhar e construir defesas contra técnicas de ataque relevantes. Usando o framework MITRE ATT&CK como base, coletamos técnicas e vetores de ataque associados a ambientes DevOps e criamos uma matriz dedicada aos métodos de ataque DevOps.

Vale a pena notar que as táticas nesta matriz devem ser olhadas da perspetiva do DevOps. Por exemplo, as técnicas de execução em uma máquina virtual que executa o sistema operacional Windows ou Linux são diferentes da execução em um pipeline de DevOps. No caso do Linux, execução significa executar código no sistema operacional. Quando falamos de ambientes DevOps, isso significa executar código no pipeline ou recursos de DevOps. Além de usar essa matriz de ameaças para categorizar ataques e métodos de defesa correspondentes, os defensores podem trabalhar ao lado de equipes vermelhas para testar continuamente suposições e encontrar novas técnicas de ataque em potencial.

MITRE ATT&CK Definido

A matriz MITRE ATT&CK é uma base de conhecimento acessível ao público para compreender as várias táticas e técnicas usadas pelos atacantes durante um ciberataque.

A base de conhecimento está organizada em várias categorias: pré-ataque, acesso inicial, execução, persistência, escalonamento de privilégios, evasão de defesa, acesso a credenciais, descoberta, movimento lateral, coleta, exfiltração e comando e controle.

As táticas (T) representam o "porquê" de uma técnica ou subtécnica ATT&CK. É o objetivo tático do adversário: a razão para realizar uma ação. Por exemplo, um adversário pode querer obter acesso a credenciais.

As técnicas (T) representam "como" um adversário atinge um objetivo tático ao executar uma ação. Por exemplo, um adversário pode despejar credenciais para obter acesso a credenciais.

Common Knowledge (CK) em ATT&CK significa conhecimento comum, essencialmente o modus operandi documentado de táticas e técnicas executadas por adversários.

Acesso inicial

A tática de acesso inicial refere-se a técnicas que um invasor pode usar para obter acesso aos recursos de DevOps – repositórios, pipelines e dependências. As seguintes técnicas podem ser uma condição prévia para as próximas etapas:

Autenticação de Gerenciamento de Código-Fonte (SCM) – Acesso por meio de um método de autenticação ao gerenciamento de código-fonte da organização. Pode ser um token de acesso pessoal (PAT), uma chave SSH ou qualquer outra credencial de autenticação permitida. Um exemplo de um método que um invasor pode usar para alcançar essa técnica é usar um ataque de phishing contra uma organização.

Autenticação de serviço de Integração Contínua (CI) e Entrega Contínua (CD) – Semelhante à autenticação SCM, um invasor pode aproveitar a autenticação para o serviço CI/CD para atacar o DevOps da organização.

Repositórios públicos da organização – Acesso aos repositórios públicos da organização configurados com recursos de CI/CD. Dependendo da configuração da organização, esses repositórios podem ter a capacidade de acionar uma execução de pipeline após a criação de uma solicitação pull (PR).

Comprometimento do ponto de extremidade – Usando um compromisso existente, um invasor pode aproveitar a estação de trabalho do desenvolvedor comprometido, obtendo assim acesso ao SCM, ao registro ou a qualquer outro recurso da organização ao qual o desenvolvedor tenha acesso.

Webhooks configurados – Quando uma organização tem um webhook configurado, um invasor pode usá-lo como um método de acesso inicial à rede da organização usando o próprio SCM para disparar solicitações nessa rede. Isso pode conceder ao invasor acesso a serviços que não devem ser expostos publicamente ou que estão executando versões de software antigas e vulneráveis dentro da rede privada.

Execução

A tática de execução refere-se a técnicas que podem ser usadas por um adversário mal-intencionado para obter acesso para executar recursos do pipeline – o próprio pipeline ou os recursos de implantação. Algumas das técnicas nesta seção contêm explicações sobre as diferentes maneiras de realizá-las, ou o que chamamos de subtécnicas:

Execução de pipeline envenenado (PPE) – Refere-se a uma técnica em que um invasor pode injetar código no repositório de uma organização, resultando na execução de código no sistema CI/CD do repositório. Existem diferentes subtécnicas para alcançar a execução de código:

• Direct PPE (d-PPE) – Casos em que o invasor pode modificar diretamente o arquivo de configuração dentro do repositório. Como o pipeline é acionado por um novo PR e executado de acordo com o arquivo de configuração – o invasor pode injetar comandos mal-intencionados no arquivo de configuração, e esses comandos são executados no pipeline.
  
• EPI indireto (i-PPE) – Casos em que o invasor não pode alterar diretamente os arquivos de configuração, ou que essas alterações não são levadas em conta quando acionadas. Nesses casos, o invasor pode infetar scripts usados pelo pipeline para executar código, por exemplo, make-files, scripts de teste, scripts de construção, etc.
• EPI público – Casos em que o pipeline é acionado por um projeto de código aberto. Nesses casos, o invasor pode usar d-PPE ou i-PPE no repositório público para infectar a pipeline.

Adulteração de dependência – Refere-se a uma técnica em que um invasor pode executar código no ambiente de DevOps ou no ambiente de produção injetando código mal-intencionado nas dependências de um repositório. Assim, quando a dependência é baixada, o código malicioso é executado. Algumas subtécnicas que podem ser usadas para alcançar a execução de código incluem:

• Confusão de dependência pública – Uma técnica em que o adversário publica pacotes maliciosos públicos com o mesmo nome dos pacotes privados. Nesse caso, como a pesquisa de pacotes em mecanismos de controle de pacotes normalmente procura em registros públicos primeiro, o pacote mal-intencionado é baixado.
• Sequestro de pacote público ("repo-jacking") – Sequestrar um pacote público assumindo o controle da conta do mantenedor, por exemplo, explorando o recurso de renomeação de usuário do GitHub.
• Typosquatting – Publicação de pacotes maliciosos com nomes semelhantes aos pacotes públicos conhecidos. Desta forma, um invasor pode confundir os usuários para baixar o pacote mal-intencionado em vez do desejado.

Comprometimento de recursos de DevOps – Os pipelines são, no núcleo, um conjunto de recursos computacionais que executam os agentes de CI/CD, juntamente com outros softwares. Um invasor pode direcionar esses recursos explorando uma vulnerabilidade no sistema operacional, o código do agente, outro software instalado nas VMs ou outros dispositivos na rede para obter acesso ao pipeline.

Controle do registro comum – Um invasor pode obter o controle de um registro usado pela organização, resultando em imagens maliciosas ou pacotes executados pelas VMs de pipeline ou VMs de produção.

Persistência

A tática de persistência consiste em diferentes técnicas que um invasor pode usar para manter o acesso a um ambiente de vítima:

Alterações no repositório – Os adversários podem usar os tokens automáticos de dentro do pipeline para acessar e enviar código para o repositório (assumindo que o token automático tenha permissões suficientes para fazê-lo). Eles podem alcançar a persistência desta forma usando várias subtécnicas:

• Alterar/adicionar scripts no código – podemos alterar alguns dos scripts de inicialização/adicionar novos scripts, para que eles baixem um backdoor/starter para o invasor, então cada vez que o pipeline estiver executando esses scripts, o código do invasor também será executado.
  
• Alterar a configuração do pipeline – podemos adicionar novas etapas no pipeline para baixar um script controlado pelo invasor para o pipeline antes de continuar com o processo de compilação.
• Altere a configuração para locais de dependências – para usar pacotes controlados por invasores.

Injetar em artefatos – alguns ambientes de CI têm a funcionalidade de criar artefatos a serem compartilhados entre diferentes execuções de pipeline. Por exemplo, no GitHub, podemos armazenar artefatos e baixá-los usando uma ação do GitHub da configuração do pipeline.

Modificar imagens no registro – Nos casos em que os pipelines têm permissões para acessar o registro de imagem (por exemplo, para gravar imagens de volta no registro depois que a compilação é feita), o invasor pode modificar e plantar imagens maliciosas no registro, que continuariam a ser executadas pelos contêineres do usuário.

Criar credenciais de serviço – Um adversário mal-intencionado pode aproveitar o acesso que já tem no ambiente e criar novas credenciais para uso caso o método de acesso inicial seja perdido. Isso pode ser feito criando um token de acesso ao SCM, ao próprio aplicativo, aos recursos de nuvem e muito mais.

Escalonamento de privilégios

As técnicas de escalonamento de privilégios são usadas por um invasor para elevar os privilégios no ambiente da vítima, ganhando privilégios mais altos para recursos já comprometidos:

Segredos em repositórios privados – Aproveitando um método de acesso inicial já adquirido, um invasor pode verificar repositórios privados em busca de segredos ocultos. As chances de encontrar segredos ocultos em um repositório privado são maiores do que em um repositório público, pois, do ponto de vista do desenvolvedor, isso é inacessível de fora da organização.

Commit/push para ramificações protegidas – O pipeline tem acesso ao repositório que pode ser configurado com acesso permissivo, o que pode permitir enviar código diretamente para ramificações protegidas, permitindo que um adversário injete código diretamente nas ramificações importantes sem intervenção da equipe.

Certificados e identidades de serviços de metadados – Quando um invasor estiver executando pipelines hospedados na nuvem, ele poderá acessar os serviços de metadados de dentro do pipeline e extrair certificados (requer altos privilégios) e identidades desses serviços.

Acesso a credenciais

As técnicas de acesso a credenciais são usadas por um invasor para roubar credenciais:

Credenciais do usuário – Nos casos em que o cliente requer acesso a serviços externos do pipeline de CI (por exemplo, um banco de dados externo), essas credenciais residem dentro do pipeline (podem ser definidas por segredos de CI, variáveis de ambiente, etc.) e podem ser acessíveis ao adversário.

Credenciais de serviço – Há casos em que o invasor pode encontrar credenciais de serviço, como SPN (nomes de entidade de serviço), tokens SAS (assinatura de acesso compartilhado) e muito mais, que podem permitir o acesso a outros serviços diretamente do pipeline.

Movimento lateral

A tática de movimento lateral refere-se a técnicas usadas por atacantes para se mover através de diferentes recursos. Em ambientes de CI/CD, isso pode se referir à mudança para recursos de implantação, para criar artefatos e registros ou para novos destinos.

Comprometer artefatos de construção – Como em outros ataques à cadeia de suprimentos, uma vez que o invasor tenha o controle dos pipelines de CI, eles podem interferir nos artefatos de construção. Desta forma, o código malicioso pode ser injetado nos materiais de construção antes da construção ser feita, injetando assim a funcionalidade maliciosa nos artefatos de construção.

Injeção de registro – Se o pipeline estiver configurado com um registro para os artefatos de compilação, o invasor pode infetar o registro com imagens maliciosas, que mais tarde seriam baixadas e executadas por contêineres usando esse registro.

Espalhar para recursos de implantação – Se o pipeline estiver configurado com acesso a recursos de implantação, o invasor terá o mesmo acesso a esses recursos, permitindo que o invasor se espalhe. Isso pode resultar em execução de código, exfiltração de dados e muito mais, dependendo das permissões concedidas aos pipelines.

Evasão das defesas

As técnicas de evasão de defesa podem ser usadas por atacantes para contornar as defesas usadas em um ambiente de DevOps e permitir que os ataques continuem sob o radar:

Manipulação de logs de serviço – Os logs de serviço permitem que os defensores detetem ataques em seu ambiente. Um invasor operando dentro de um ambiente (por exemplo, nos pipelines de compilação) pode alterar os logs para impedir que os defensores observem o ataque. Isso é semelhante a um invasor alterar os logs de histórico em uma máquina Linux, impedindo que qualquer observador veja os comandos executados pelo invasor.

Manipulação de compilação – se um invasor deseja não deixar vestígios no serviço SCM, o invasor pode alterar o processo de compilação para injetar o código mal-intencionado. Isto pode ser feito de várias formas:

• Alterar o código em tempo real – Alterar o código antes do processo de compilação começar, sem alterá-lo no repositório e deixar vestígios nele.
  
• Compilador adulterado – Alterar o compilador no ambiente de compilação para introduzir o código malicioso sem deixar vestígios antes do início do processo.

Reconfigurar proteções de ramificação – As ferramentas de proteção de ramificação permitem que uma organização configure etapas antes que um PR/commit seja aprovado em uma ramificação. Quando um invasor tem permissões de administrador, ele pode alterar essas configurações e introduzir código na ramificação sem qualquer intervenção do usuário.

Impacto

A tática de impacto refere-se às técnicas que um invasor pode usar para explorar o acesso aos recursos de CI/CD para fins maliciosos, e não como mais uma etapa no ataque, pois essas técnicas podem ser barulhentas e fáceis de detetar:

Negação de Serviço Distribuída (DDoS) – Um adversário pode usar os recursos de computação aos quais obteve acesso para executar ataques distribuídos de negação de serviços (DDoS) em alvos externos.

Mineração de criptomoedas – Os recursos de computação podem ser usados para mineração de criptomoedas controlada por um adversário.

Negação de serviço local (DoS) – Quando o invasor estiver em execução nos pipelines de CI, ele poderá executar um ataque de serviço de negação desses pipelines aos clientes desligando agentes, reinicializando ou sobrecarregando as VMs.

Exclusão de recursos – Um invasor com acesso a recursos (recursos de nuvem, repositórios, etc.) pode excluir permanentemente os recursos para obter negação de serviços.

Exfiltração

A tática de exfiltração refere-se a diferentes técnicas que podem ser usadas por um invasor para exfiltrar dados confidenciais do ambiente da vítima:

Clone repositórios privados – Uma vez que os invasores têm acesso a pipelines de CI, eles também ganham acesso aos repositórios privados (por exemplo, o GITHUB_TOKEN pode ser usado no GitHub) e, portanto, podem clonar e acessar o código, ganhando assim acesso ao IP privado.

Logs de pipeline – Um adversário pode acessar os logs de execução do pipeline, visualizar o histórico de acesso, as etapas de construção, etc. Esses logs podem conter informações confidenciais sobre a compilação, a implantação e, em alguns casos, até mesmo credenciais para serviços, contas de usuário e muito mais.

Exfiltre dados de recursos de produção – Nos casos em que os pipelines podem acessar os recursos de produção, os invasores também terão acesso a esses recursos. Portanto, eles podem abusar desse acesso para exfiltrar dados de produção.

Recomendações de gerenciamento de postura de DevOps

Quando os scanners de DevOps descobrem desvios das práticas recomendadas de segurança em sistemas de gerenciamento de código-fonte e pipelines de integração contínua/entrega contínua, o Defender for Cloud emite recomendações precisas e acionáveis. Estas recomendações têm os seguintes benefícios:

• Visibilidade aprimorada: obtenha informações abrangentes sobre a postura de segurança dos ambientes de DevOps, garantindo uma compreensão completa de quaisquer vulnerabilidades existentes. Identifique regras de proteção de ramificação ausentes, riscos de escalonamento de privilégios e conexões inseguras para evitar ataques.
  
• Ação baseada em prioridades: filtre os resultados por gravidade para gastar recursos e esforços de forma mais eficaz, abordando primeiro as vulnerabilidades mais críticas.
• Redução da superfície de ataque: resolva as lacunas de segurança destacadas para minimizar significativamente as superfícies de ataque vulneráveis, fortalecendo assim as defesas contra ameaças potenciais.
• Notificações em tempo real: Capacidade de integração com automações de fluxo de trabalho para receber alertas imediatos quando as configurações seguras são alteradas, permitindo uma ação rápida e garantindo o cumprimento sustentado dos protocolos de segurança.