0 
0 As violações na nuvem são inevitáveis.
É a realidade em que vivemos. Os últimos anos demonstraram que as violações ocorrem, não importa o quanto as organizações de segurança implementem. O aumento da complexidade das organizações – onde um único erro ou vulnerabilidade pode levar a um comprometimento – juntamente com o aumento da motivação, sofisticação e dedicação dos invasores, significa que as violações vieram para ficar. Ao mesmo tempo, as organizações estão migrando para a nuvem , fazendo com que os invasores mudem o foco para aumentar rapidamente seus ataques em ambientes de nuvem.
Embora isso signifique que as violações na nuvem são inevitáveis , isso não significa que não podemos fazer nada a respeito. Ao entender melhor os ataques à nuvem, as organizações podem se preparar melhor para eles. Então, esperançosamente, eles podem conter e responder a ataques mais rapidamente, reduzindo seu impacto e evitando uma crise.
Esta série de duas partes explorará os ataques do mundo real que desvendam, investigam e compartilham insights sobre as maneiras práticas pelas quais as organizações podem responder a ataques na nuvem no cenário de ameaças atual.
Hack do SaaS Marketplace leva a uma grande violação
Nos últimos anos, as plataformas de software como serviço (SaaS) vêm substituindo os aplicativos corporativos tradicionais, tornando mais fácil para as organizações adotá-los e gerenciá-los. Parte do valor que essas plataformas fornecem é a capacidade de integração e expansão rápida , suportando as crescentes demandas dos usuários por mais funcionalidade. Aprimorando ainda mais suas plataformas, os fornecedores de SaaS estão criando um mercado para permitir que fornecedores terceirizados adicionem funcionalidade e integração para seus usuários. Esses marketplaces, no entanto, podem apresentar riscos substanciais de terceiros, como pode ser visto no cenário a seguir.
Depois que uma empresa foi notificada pelo GitHub sobre um risco potencial, o GitHub não forneceu nenhum indicador específico de acesso não autorizado. Em vez disso, o GitHub forneceu apenas um aviso genérico de que o DeepSource , um dos aplicativos que a empresa usava anteriormente no mercado, foi violado , tornando difícil entender se a organização foi afetada ou não. Uma revisão inicial feita pela empresa de seus logs do GitHub não ajudou, pois não conseguiu ver nenhum acesso ao seu código pelo DeepSource.
A razão para isso era bastante simples – e está no centro de quantos marketplaces SaaS operam. Alguns meses antes da violação, um dos desenvolvedores da empresa experimentou o aplicativo DeepSource, no qual o desenvolvedor concedeu ao DeepSource acesso ao código com seu nome de usuário. Quando os invasores usaram o acesso do DeepSource para baixar todo o repositório de código, o que apareceu nos logs foi um pull request com o nome de um usuário legítimo. O único indicador de que era malicioso foi a identificação de um endereço IP irregular, que acabou sendo vinculado a outros ataques conhecidos.
Nesse ponto, ficou claro que todo o repositório de código havia sido roubado e uma resposta completa era necessária para conter e recuperar a violação. Como na maioria dos casos de vazamento de código, a preocupação imediata foi o acesso a segredos (senhas/chaves) no código. Embora geralmente seja uma má prática ter segredos codificados no código, ainda é uma prática comum por muitos – e neste caso não foi diferente. Ao identificar os segredos relevantes no código, os próximos passos dos invasores – que, como esperado, começaram a acessar parte da infraestrutura da Amazon Web Services (AWS) – foram previstos. Ao identificá-los rapidamente, a empresa conseguiu bloquear o acesso a todos os recursos relevantes, conter a violação e se recuperar antes que mais danos pudessem ser causados.
Cryptominer injetado em um modelo de máquina virtual
E se alguém pudesse minerar criptomoedas às custas de outra pessoa? Essa ideia está no centro de muitos ataques de criptomineração que vemos hoje, onde os invasores assumem os recursos da nuvem e , em seguida, executam criptomineradores neles coletando criptomoedas enquanto a organização hackeada paga as contas de computação em nuvem por isso.
Em um incidente recente, uma empresa identificou arquivos desconhecidos em 18 máquinas AWS EC2 que estavam executando na nuvem. Olhando para os arquivos, ficou claro que eles foram vítimas da campanha de criptomineração TeamTNT Watchdog em andamento. Inicialmente, não estava claro como os invasores conseguiram infectar tantas instâncias do EC2, mas à medida que a investigação se desenrolava, ficou claro que, em vez de atacar máquinas individuais, os invasores visavam a imagem de máquina da Amazon ( AMI) usado para criar cada máquina. Durante a criação da imagem original, houve um curto período de tempo em que um serviço foi desconfigurado, permitindo o acesso remoto. O TeamTNT usou ferramentas automáticas para escanear a rede, identificá-la e imediatamente colocar os mineradores lá, que foram duplicados para cada nova máquina criada.
Isso destaca outro padrão de ataque comum: implantar criptomineradores em AMIs publicamente disponíveis por meio do mercado da Amazon.
Conforme demonstrado por esses casos, os ataques à nuvem vieram para ficar. Eles são diferentes do que estamos acostumados a observar, então é hora de se preparar melhor para a chegada deles . Fique atento à parte dois, onde vamos mergulhar no ransomware na nuvem e como evitá-lo.
A segunda parte deste artigo está agendada para quinta-feira, 1º de setembro, às 10 horas do leste.
FONTE: DARK READING