O Google divulgou o relatório de horizonte de ameaças de abril de 2023, que mostrou vários métodos usados pelos agentes de ameaças para escapar dos sistemas de segurança.
Equipe de ação de segurança cibernética do Google (GCAT) e a Mandiant pesquisaram uma lista de técnicas e métodos usados pelos agentes de ameaças durante o período para penetrar nos ambientes e outras atividades maliciosas.
Arquivos ZIP criptografados hospedados na nuvem evitando detecção
As observações da Mandiant durante o quarto trimestre de 2022 mostraram uma técnica em que os agentes de ameaças armazenavam arquivos maliciosos no Google Drive como arquivos ZIP criptografados para evitar a detecção.
Uma campanha de malware também distribuiu malware URSNIF, um bot bancário e software de intrusão hospedando o binário URSNIF no Google Drive.
Os agentes de ameaças usam e-mails de phishing para atrair as vítimas para que baixem os arquivos ZIP maliciosos protegidos por senha, que então instalarão o malware na máquina da vítima.
O quarto trimestre de 2022 também mostrou outra expansão desta técnica onde Malware DICELOADER foi distribuído, que tinha múltiplas finalidades.
Nessa técnica, a Mandiant observou que o link do Google Drive no e-mail de phishing continha um arquivo LNK.
Quando este arquivo for baixado, ele instalará um Instalador Zoom MSI, um Trojan que eventualmente leva a uma infecção DICELOADER.
Vários outros atores de ameaças usaram essa técnica para finalidades diferentes em vários outros casos.
Desafios e soluções do cliente ao aplicar patches de segurança no Google Kubernetes Engine
Kubernetes tem sido um ótimo recurso para clientes de nuvem devido à sua disponibilidade, flexibilidade e segurança.
No entanto, até mesmo o Kubernetes precisa de patches rotineiramente, o que instala segurança e correções de bugs.
De acordo com o Google relatóriosos dados de 2021-2022 mostraram a maior parte do Motor Kubernetes do Google (GKE) os clientes atrasaram a aplicação de patches devido ao medo de que “a correção pudesse afetar as operações de produção”.
Este atraso na aplicação de patches de segurança pode, por vezes, resultar em vulnerabilidades que os agentes de ameaças podem explorar ao longo do tempo.
Muitas opções estão disponíveis para manter a aplicação de patches de segurança e a continuidade dos negócios, que também podem ser combinadas com serviços de verificação e notificação para encontrar vulnerabilidades.
Houve muitos motivos dos clientes do GKE para atrasar a aplicação de patches de segurança, pois,
- A manutenção da sessão dos clientes (sessões fixadas) será encerrada.
- Os clientes baseados em aplicativos de IA/ML estavam preocupados com a possibilidade de cargas de trabalho não salvas serem perdidas durante a atividade de patch e reinicialização.
- Alguns clientes estavam preocupados que a aplicação de patches pudesse trazer alterações inesperadas na API, afetando a funcionalidade de seus aplicativos.
- Clientes de nós grandes levarão mais tempo para corrigir, criando uma postura de segurança fraca.
Soluções para equilibrar disponibilidade e patches de segurança no GKE
- Escolha atualizações de canais apropriados e relevantes (rápido, regular e estável) para os aplicativos
- Usar manutenção windows para patch com duração adequada.
- Ter exclusão de manutenção windows para evitar atualizações durante alguns casos especiais.
- Configurar um orçamento de interrupção de pod é preferível para aplicativos de clientes baseados em manutenção de sessão.
- A configuração de clusters regionais em vez de clusters zonais é recomendada para disponibilidade da carga de trabalho.
- Ter um painel de postura de segurança traz muitos resultados.
- O uso de vários serviços de notificação proporcionará conscientização de segurança adicional para aplicação de patches.
O fruto mais fácil: chaves de conta de serviço vazadas e o impacto em sua organização
O vazamento de credenciais de contas de serviço tem sido a maior ameaça para organizações com infraestruturas baseadas em nuvem.
De acordo com as principais ameaças à computação em nuvem durante 2022 pela CSA (Cloud Security Alliance), 42% dos incidentes foram incidentes importantes vazados.
O gerenciamento de identidade, credenciais, acesso e chaves é extremamente importante para sistemas baseados em nuvem, pois as chaves podem ter acesso a informações confidenciais.
A maioria deles ocorreu devido à criação de novas contas ou aos desenvolvedores testarem seu código em um repositório público, levando ao vazamento de credenciais de contas de serviço.
O Google declarou: “Em 42% dos incidentes críticos vazados detectados pelos nossos sistemas de abuso, os clientes não tomaram medidas depois que o Google tentou entrar em contato com o proprietário do projeto, portanto a chave permaneceu vulnerável a abusos.
Embora existam muitos casos de novas contas ou desenvolvedores testando códigos que expõem chaves de contas de serviço, nossas equipes observaram comprometimentos distribuídos em diversos tamanhos e maturidades de organizações”.
Atacantes mudando táticas para ocultar chamadas de API
Os agentes de ameaças que obtêm essas credenciais de contas de serviço vazadas têm usado diversas técnicas de evasão de defesa para ocultar a origem de suas chamadas de API.
A maioria dos invasores usa nós Tor, proxies abertos e outras instâncias de nuvem comprometidas ou provedores de serviços em nuvem para chamadas de API anônimas.
Muitas vezes, os invasores não têm conhecimento da capacidade da credencial de serviço e, portanto, dependem de ferramentas de automação para aumentar o nível de utilização de recursos, resultando no encerramento da instância.
Os invasores que obtiverem conhecimento da credencial descoberta podem causar danos extremos à infraestrutura, dependendo das permissões da credencial.
A pesquisa de dados sobre as funções IAM de chaves de contas de serviço comprometidas corresponde aos dados a seguir.
- 67.6% de chaves tinham funções básicas do IAM
- 23.5% tinha funções de proprietário
- 44.1% tinha funções de editor
Outro relatório da Unidade 42 de Pesquisa de Ameaças à Nuvem de Palo Alto afirmou: “99% dos usuários, funções, serviços e recursos da nuvem receberam permissões excessivas.”
Credenciais codificadas verificadas em repositórios de código
O vazamento de credenciais em um repositório público/privado se origina quando um desenvolvedor baixa uma chave de conta de serviço (normalmente um par de chaves pública/privada RSA) e a utiliza para verificar o código em um repositório de código privado, deixando-o lá por muito tempo.
Os casos em que esses repositórios privados se tornam públicos são quando a exposição dessas chaves se torna predominante.
Os atores da ameaça lançam redes dentro dos repositórios para encontrar essas chaves, consideradas frutos mais fáceis de alcançar.
De acordo com o relatório Threat Horizon de janeiro de 2023, Jenkins, o software de automação de TI, foi o mais visado.
Isso ocorreu porque chaves e outras credenciais foram encontradas no commit de uma organização junto com logs de CI/CD que exibiam essas chaves quando eram enviadas como argumentos de linha de comando.
Infelizmente, isso passou despercebido por muito tempo. De acordo com o relatório de violação de custo de dados de 2022 da IBM, 19% das violações foram devidas a credenciais comprometidas ou roubadas e levaram o tempo mais longo, quase 243 dias, para serem detectadas.
Outra instância em que um desenvolvedor digitalizou o índice de pacotes Python (PyPi) revelou 53 chaves AWS legítimas e válidas.
O fato é que Amazon eles próprios tinham uma chave vazada, e a chave ativa mais antiga encontrada na varredura data de 10 anos.
Mitigações
- A necessidade de uma conta de serviço deve ser validada
- O desenvolvimento local pode usar credenciais de conta pessoal para autenticação
- Mantenha um inventário de chaves e audite-as regularmente
- Ter uma convenção de nomenclatura para contas de serviço pode ser útil
- Monitore registros de auditoria e identifique comportamento malicioso
- É recomendável ter políticas para desabilitar contas não utilizadas há algum tempo.
