Postura de segurança do ambiente de DevOps

Concluído

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

O gerenciamento da postura de DevOps é um recurso do Microsoft Defender para Nuvem que:

• Fornece insights sobre a postura de segurança de todo o ciclo de vida da cadeia de fornecimento de software.
• Usa verificadores avançados para oferecer avaliações detalhadas.
• Abrange vários recursos, de organizações e pipelines a repositórios.
• Permite que os clientes reduzam a superfície de ataque descobrindo as recomendações fornecidas e tomando medidas com base nelas.

Verificadores de DevOps

Para fornecer conclusões, o gerenciamento da postura de DevOps usa verificadores de DevOps para identificar os pontos fracos no gerenciamento de código-fonte e nos pipelines de integração contínua/entrega contínua executando verificações em relação às configurações de segurança e aos controles de acesso.

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

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

• Compilações
  
• Arquivos seguros
• Grupos de Variáveis
• Conexões de Serviço
• Organizações
• Repositórios

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

O gerenciamento da postura de DevOps auxilia as organizações na descoberta e na correção de configurações incorretas prejudiciais na plataforma de DevOps. Isso resulta em um ambiente de DevOps resiliente e de confiança zero, que é reforçado em relação a uma série de ameaças definidas na matriz de ameaças de DevOps. Os principais controles de gerenciamento da postura incluem:

• Acesso aos segredos com escopo: minimize a exposição de informações confidenciais e reduza o risco de acesso não autorizado, vazamentos de dados e movimentações laterais, garantindo que cada pipeline tenha acesso apenas aos segredos essenciais à respectiva função.
  
• Restrição de executores auto-hospedados e permissões elevadas: impeça execuções não autorizadas e possíveis elevações, evitando o uso de executores auto-hospedados e garantindo que as permissões de pipeline sejam somente leitura por padrão.
  
• Proteção aprimorada de branch: mantenha a integridade do código impondo regras de proteção de branch e impedindo injeções de código mal-intencionadas.
  
• Permissões otimizadas e repositórios seguros: Reduza o risco de modificações e acesso não autorizados acompanhando permissões base mínimas e habilitando a proteção por push secreta para repositórios.
  

Matriz de ameaça para DevOps

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

Vale a pena observar que as táticas nesta matriz devem ser analisadas da perspectiva 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, a execução significa executar o código no sistema operacional. Quando falamos sobre ambientes de DevOps, isso significa executar código nos recursos de pipeline ou DevOps. Além de usar essa matriz de ameaças para categorizar ataques e métodos de defesa correspondentes, os Defenders podem trabalhar junto com equipes vermelhas para testar continuamente suposições e encontrar novas técnicas de ataque em potencial.

Definido pelo MITRE ATT&CK

A matriz MITRE ATT&CK é uma base de conhecimento publicamente acessível para permitir o entendimento das várias táticas e técnicas usadas por invasores durante um ataque cibernético.

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

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

As Técnicas (T) representam "como" um adversário conclui uma meta tática executando uma ação. Por exemplo, um adversário pode despejar credenciais para obter acesso de credencial.

Conhecimento Geral (CK) na ATT&CK significa conhecimento geral, essencialmente o modus operandi documentado das táticas e técnicas executadas por adversários.

Acesso inicial

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

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

Autenticação de serviço CI (integração contínua) e CD (entrega contínua) – 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 disparar uma execução de pipeline após a criação de uma PR (pull request).

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

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

Execução

A tática de execução se refere a técnicas que podem ser usadas por um adversário mal-intencionado para obter acesso de execução em recursos de 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 executá-las ou o que chamamos de sub-técnicas:

PPE (execução de pipeline envenenado) – 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 de CI/CD do repositório. Há diferentes sub-técnicas para conseguir a execução de código:

• PPE Direto (d-PPE) – casos em que o invasor pode modificar diretamente o arquivo de configuração dentro do repositório. Como o pipeline é disparado 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 serão executados no pipeline.
  
• PPE 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 disparadas. Nesses casos, o invasor pode infectar scripts usados pelo pipeline para executar código, por exemplo, make-files, testar scripts, compilar scripts, etc.
• PPE público – casos em que o pipeline é disparado 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 o 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 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 mal-intencionado é executado. Algumas subtécnicas que podem ser usadas para obter a execução de código incluem:

• Confusão de dependência pública – uma técnica em que o adversário publica pacotes mal-intencionados públicos com o mesmo nome dos pacotes privados. Nesse caso, como a pesquisa de pacotes em mecanismos de controle de pacote normalmente procura primeiro em registros públicos, o pacote mal-intencionado é baixado.
• Sequestro de pacote público (“roubo de repositório”) – 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 – publicar pacotes mal-intencionados com nomes semelhantes em pacotes públicos conhecidos. Dessa forma, um invasor pode confundir os usuários ao baixar o pacote mal-intencionado em vez do desejado.

Comprometimento de recursos do DevOps – pipelines são, na essência, um conjunto de recursos de computação executando agentes de CI/CD, juntamente com outros softwares. Um invasor pode atingir esses recursos explorando uma vulnerabilidade no sistema operacional, no código do agente, em outros softwares instalados nas VMs ou em outros dispositivos na rede para obter acesso ao pipeline.

Controle do registro comum – um invasor pode conseguir controlar um registro usado pela organização, resultando em pacotes ou imagens mal-intencionadas executados pelas VMs de pipeline ou VMs de produção.

Persistência

A tática de persistência consiste em técnicas diferentes 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 por push para o repositório (supondo que o token automático tenha permissões suficientes para fazer isso). Eles podem alcançar a persistência dessa forma usando várias sub-técnicas:

• Alterar/adicionar scripts no código – podemos alterar alguns dos scripts de inicialização ou adicionar novos scripts, para que eles baixem um backdoor/iniciador para o invasor, portanto, sempre 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 por invasores no pipeline antes de continuar com o processo de compilação.
• Alterar a configuração de locais de dependências – usar pacotes controlados por invasores.

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

Modificar imagens no registro – nos casos em que os pipelines tiverem permissões para acessar o registro de imagem (por exemplo, para gravar imagens de volta no registro após a conclusão da compilação), o invasor poderá modificar e plantar imagens mal-intencionadas 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 para o SCM, para o próprio aplicativo, para os recursos de nuvem e muito mais.

Elevação de privilégio

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

Segredos em repositórios privados – aproveitando um mecanismo 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.

Fazer commit/efetuar push para branches protegidos – o pipeline tem acesso ao repositório que pode ser configurado com acesso permissivo, o que pode permitir o envio de código diretamente para branches protegidos, permitindo que um adversário insira código diretamente nos branches importantes sem intervenção da equipe.

Certificados e identidades de serviços de metadados – depois que um invasor estiver em execução em pipelines hospedados na nuvem, o invasor poderá acessar os serviços de metadados de dentro do pipeline e extrair certificados (requer privilégios elevados) e identidades desses serviços.

Acesso de credenciais

As técnicas de acesso à credencial 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 da 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 se refere às técnicas usadas pelos invasores para percorrer recursos diferentes. Em ambientes de CI/CD, isso pode se referir à migração para recursos de implantação, para compilar artefatos e registros ou para novos destinos.

Comprometer artefatos de compilação – como em outros ataques da cadeia de suprimentos, depois que o invasor tiver o controle dos pipelines de CI, eles poderão interferir nos artefatos de compilação. Dessa forma, o código mal-intencionado pode ser injetado nos materiais de compilação antes que ela seja concluída, injetando a funcionalidade mal-intencionada nos artefatos de compilação.

Injeção do registro – se o pipeline estiver configurado com um registro para os artefatos de compilação, o invasor poderá infectar o registro com imagens mal-intencionadas, que posteriormente seriam baixadas e executadas por contêineres usando esse registro.

Difundir para recursos de implantação – se o pipeline estiver configurado com acesso aos 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 de defesa

As técnicas de evasão de defesa podem ser usadas por invasores para ignorar as defesas usadas em um ambiente de DevOps e permitir que os ataques continuem sem serem detectados:

Manipulação de logs de serviço – logs de serviço permitem que os Defenders detectem ataques em seu ambiente. Um invasor em execução dentro de um ambiente (por exemplo, nos pipelines de build) pode alterar os logs para impedir que os Defenders notem o ataque. Isso é semelhante a um invasor que altera os logs de histórico em um computador Linux, impedindo que qualquer observador veja os comandos executados pelo invasor.

Manipulação de compilação – se um invasor não quiser deixar nenhum vestígio no serviço SCM, o invasor poderá alterar o processo de compilação para injetar o código mal-intencionado. Isso pode ser feito de várias maneiras:

• Alterando o código em tempo real – alterando o código antes do início do processo de compilação, sem alterá-lo no repositório e deixando vestígios nele.
  
• Compilador adulterado – alterar o compilador no ambiente de compilação para introduzir o código mal-intencionado sem deixar nenhum vestígio antes do início desse processo.

Reconfigurar proteções de branch – ferramentas de proteção do branch permitem que uma organização configure etapas antes que um PR/commit seja aprovado em um branch. Depois que um invasor tiver permissões de administrador, ele poderá alterar essas configurações e introduzir código no branch sem nenhuma intervenção do usuário.

Impacto

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

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

Criptomineração – os recursos de computação podem ser usados para criptomineração controlada por um adversário.

DoS (Negação de Serviço) local – depois que o invasor estiver em execução nos pipelines de CI, o invasor 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.) poderia excluir permanentemente os recursos para obter negação de serviços.

Exfiltração

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

Clonar repositórios privados – depois que os invasores tiverem acesso aos pipelines de CI, eles também terão acesso aos repositórios privados (por exemplo, o GITHUB_TOKEN pode ser usado no GitHub) e, portanto, podem clonar e acessar o código, obtendo assim acesso ao IP privado.

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

Exfiltrar dados de recursos de produção – em 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 explorar esse acesso para exfiltrar dados de produção.

Recomendações de gerenciamento da postura de DevOps

Quando os verificadores de DevOps descobrem desvios das melhores práticas de segurança em sistemas de gerenciamento de código-fonte e em pipelines de integração contínua/entrega contínua, o Defender para Nuvem gera recomendações precisas e acionáveis. Essas recomendações trazem os seguintes benefícios:

• Visibilidade aprimorada: obtenha insights abrangentes sobre a postura de segurança dos ambientes de DevOps, garantindo uma ampla compreensão das vulnerabilidades existentes. Identifique regras de proteção de branch ausentes, riscos de elevação de privilégio e conexões não seguras para evitar ataques.
  
• Ação baseada em prioridade: filtre os resultados por gravidade para gastar recursos e esforços com mais eficiência, resolvendo as vulnerabilidades mais críticas primeiro.
• Redução da superfície de ataque: resolva as lacunas de segurança realçadas para minimizar consideravelmente as superfícies de ataque vulneráveis, reforçando as defesas contra possíveis ameaças.
• Notificações em tempo real: capacidade de integração a automações de fluxo de trabalho para receber alertas imediatos quando as configurações seguras forem alteradas, permitindo a ação imediata e garantindo a conformidade prolongada com os protocolos de segurança.