0
0
Enquanto a CircleCI continua investigando o incidente de segurança que afeta sua plataforma de integração contínua e entrega contínua (CI/CD), os defensores corporativos também devem procurar sinais de atividades maliciosas em aplicativos de terceiros integrados à CircleCI.
Em sua divulgação de 4 de janeiro , a CircleCI instou os usuários a alternar todos os segredos armazenados na plataforma e a verificar os logs internos em busca de sinais de “acesso não autorizado” a partir de 21 de dezembro de 2022. Como as empresas integram o software como serviço ( SaaS) e outros provedores de nuvem, os defensores também devem procurar por sinais de comportamento malicioso nesses ambientes.
Etapa 1: alterar segredos
A primeira etapa é alterar todas as senhas, segredos, tokens de acesso, variáveis de ambiente e pares de chaves público-privadas porque os invasores podem tê-los roubado. Quando as organizações integram a CircleCI com outros provedores SaaS e de nuvem, elas fornecem à CircleCI esses tokens e segredos de autenticação. A violação do CircleCI significa que a própria plataforma está comprometida, assim como todas as plataformas SaaS e provedores de nuvem integrados ao CircleCI porque essas credenciais agora estão expostas.
A CircleCI está oferecendo um script CircleCI-Env-Inspector para exportar uma lista formatada em JSON dos nomes dos segredos de CI que precisam ser alterados. A lista não conteria os valores dos segredos, disse a CircleCI.
Para executar este script, clone o repositório e execute o arquivo run.sh.
Em atualizações subsequentes, a CircleCI disse que invalidou os tokens da API do projeto usados pelos projetos e que alternou todos os tokens GitHub OAuth em nome dos clientes. A Amazon Web Services está alertando os clientes por e-mail com listas de tokens potencialmente afetados (linha de assunto: [Ação necessária] Alerta de segurança CircleCI para girar chaves de acesso. ) que os clientes devem alterar.
Para organizações que usam o TruffleHog, o recurso de verificação de log mostra todas as senhas ou chaves de API que podem ter sido registradas acidentalmente. Execute o TruffleHog com os seguintes sinalizadores:
trufflehog circleci –token=<token>
Etapa 2: verifique o CircleCI quanto a atividades suspeitas
A CircleCI disponibilizou logs de auditoria de autoatendimento para todos os clientes, incluindo clientes gratuitos, por meio da interface do usuário da plataforma. Os clientes podem consultar até 30 dias de dados e têm 30 dias para baixar os logs resultantes. A documentação do CircleCI descreve como usar os logs.
Os logs fornecem informações sobre as ações tomadas, por qual ator, em qual alvo e a que horas, de acordo com um guia de caça de ameaças da Mitiga . Procure entradas de log indicando ações realizadas por um usuário do CircleCI durante o período entre 21 de dezembro de 2022 e quando os segredos foram alterados e atualizados. As ações nas quais os invasores podem estar interessados são aquelas para obter acesso ( user.logged_in ) e manter a persistência ( project.ssh_key.create , project.api_token.create , user.create ).
Etapa 3: procure atores maliciosos em aplicativos de terceiros
O impacto da violação vai além do CircleCI, pois inclui aplicativos de terceiros integrados à plataforma de desenvolvimento, como GitHub, Amazon Web Services (AWS), Google Cloud Platform (GCP) e Microsoft Azure. Os defensores corporativos precisam procurar sinais de atividade maliciosa em cada um dos aplicativos SaaS integrados e provedores de nuvem.
Para GitHub: CircleCI autentica no GitHub via PAT, uma chave SSH ou chaves privadas e públicas geradas localmente. Os defensores devem verificar o log de segurança do GitHub em busca de atividades suspeitas do GitHub – como git.clone (copiar o repositório), git.fetch e git.pull (diferentes formas de obter o código do repositório) – originadas de usuários do CircleCI, de acordo com a ameaça da Mitiga guia de caça. Os logs de auditoria do GitHub fornecem informações sobre as ações executadas, quem executou a ação e quando ela foi executada. Verifique os logs de auditoria do GitHub contendo localização_do_ator e procure por conexões e operações anormais originadas de novos endereços IP.
Para AWS: observe as ações de eventos de gerenciamento de API nos logs de atividades de gerenciamento do AWS CloudTrail. Pesquise eventos que o usuário do CircleCI não deve executar, como ações de reconhecimento suspeitas (por exemplo, ListBuckets GetCallerIdentitiy ), eventos AccessDenied e atividades originadas de endereços IP desconhecidos e UserAgents programáticos (como boto3 e CURL ).
Para GCP: revise os registros de auditoria do Cloud – registros de auditoria de atividades do administrador, registros de auditoria de acesso a dados e registros de auditoria de política negada – por meio do console do Google Cloud (Logs Explorer), do Google Cloud CLI ou da API Logging. Verifique quais recursos a conta de serviço usada com o CircleCI tem permissões.
A chamada da API:
searchAllIamPolicies
Na linha de comando:
gcloud asset search-all-iam-policies
Procure por anormalidades, como um registro de gravidade de erro, carimbos de data/hora estranhos ou sub-redes IP incomuns, a Mitiga recomenda em seu guia.
Para o Azure: revise os erros e padrões de entrada nos logs de entrada do Azure Active Directory e verifique se há anormalidades, como a data da entrada e o endereço IP de origem. O log de atividades do Azure Monitor é um log de plataforma no Azure que fornece informações sobre eventos de nível de assinatura, como quando um recurso é modificado ou uma máquina virtual é iniciada. Uma coisa a procurar nesse log é se há ações listadas diferentes daquelas que a conta de serviço normalmente executa.
“Caçar ações maliciosas feitas por ferramentas de CI/CD comprometidas em sua organização não é trivial, porque seu escopo vai além dessa ferramenta de CI/CD e afeta outras plataformas SaaS integradas a ela”, escreveu a equipe de Mitiga no guia.
FONTE: DARK READING