0
0
Nate Warfield, CTO da Prevaliion, discute as principais preocupações de segurança para aqueles que adotam máquinas virtuais, armazenamento em nuvem pública e estratégias de nuvem para trabalho remoto.
As redes em nuvem fizeram mais para mudar a computação como a conhecemos do que qualquer outra inovação nos últimos 15 anos. Permitiu que pequenas empresas implantassem rapidamente uma presença on-line, grandes empresas escalassem à medida que a demanda diminui e flui e, em um mundo pós-COVID, fornece a base para uma força de trabalho remota.
Essa conveniência, no entanto, não veio sem seu próprio conjunto de desafios, e a corrida para “mover para a nuvem” frequentemente deixou as organizações e seus usuários com um conjunto totalmente novo de desafios de segurança e problemas de privacidade de dados.
Os mercados em nuvem estão repletos de imagens de máquina virtual (VM) pré-construídas contendo vulnerabilidades não corrigidas, configurações de firewall excessivamente permissivas e até mesmo mineiros de malware e moedas. Os provedores de nuvem não adotam uma posição proativa em relação ao monitoramento de violações/compromissos e, em muitos casos, nem sequer transmitem notificações aos seus clientes que receberam de pesquisadores externos.
As implantações na nuvem também são uma enorme fonte de vazamentos de dados (baldes S3, bancos de dados abertos/servidores NoSQL), e provedores de dados de terceiros executados na nuvem continuam sendo uma fonte de vazamentos de dados de organizações seguras.
A segurança é fundamental para as empresas que constroem e mantêm as principais nuvens como Azure, AWS, Google Cloud Platform (GCP) e outras – a Microsoft, por exemplo, tem um processo extremamente bem desenvolvido para proteger sua camada de hipervisor. Mas, devido à natureza de fornecer soluções de infraestrutura/plataforma/software como serviço (IaaS/PaaS/SaaS), uma grande parte do trabalho é deixada para o cliente.
O Problema com VMs Pré-Construídas e Pré-Instaladas
Mercados ou galerias em nuvem são os repositórios de VMs pré-construídas disponíveis para os clientes implantarem. Embora os provedores de nuvem ofereçam métodos para os clientes fazerem upload de suas próprias imagens de VM para facilitar a implantação e o dimensionamento automático, muitas pessoas preferem a conveniência de usar uma imagem pré-construída.
Embora convenientes, essas imagens são frequentemente desatualizadas ou implantadas com configurações de firewall excessivamente permissivas, o que pode abrir a VM para ataque imediatamente após a inicialização. Outra tendência preocupante tem sido a introdução de imagens de VM que são pré-instaladas com mineiros de malware ou criptomoedas – como foi visto com o Docker Hub.
Embora perigosos, esses ataques são apenas a ponta do iceberg em termos de potencial malicioso. Um invasor devidamente motivado poderia, em teoria, desenvolver uma imagem de VM que, após um período de tempo pré-determinado, liga para os operadores de malware e estabelece uma conexão de comando e controle (C2).
As principais nuvens, como AWS e Azure, provisionam automaticamente IPs internos para serem acessíveis apenas às máquinas virtuais que fornecem detalhes da assinatura sob a qual a VM é executada. No entanto, essas informações podem ser coletadas pelo malware ou descobertas por operadores maliciosos na própria máquina.
Além disso, com o aumento das implantações de nuvem híbrida e VPNs ponto a ponto conectando ambientes de nuvem à rede local de um cliente, uma cabeça de praia em uma VM de nuvem pode facilmente se tornar um caminho para o coração da rede de uma organização.
Estes são problemas não triviais para os provedores de nuvem resolverem. Embora os provedores verifiquem imagens de VM em busca de malware antes de disponibilizá-las, como visto com soluções antivírus, esses tipos de varredura capturam apenas código malicioso conhecido e não são uma defesa abrangente. Um simples trabalho cron em uma VM Linux ou tarefa agendada no Windows poderia facilmente baixar cargas úteis secundárias dias ou semanas após o provisionamento.
Agravando esse risco estão nuvens como a AWS, que permitem que qualquer usuário compartilhe uma imagem de VM no mercado. Usar esses tipos de VMs é semelhante ao risco representado pelas lojas de aplicativos móveis, mas com consequências empresariais.
Falta de Proteção e Notificação do Cliente
Um problema fundamental hoje é que os provedores de nuvem não estão adotando uma posição proativa em relação ao monitoramento de violações/compromissos e, em muitos casos, não transmitem notificações aos seus clientes que chegam de pesquisadores externos.
Embora seja verdade que os provedores de nuvem não podem ser responsáveis por todas as decisões de segurança tomadas por seus clientes, sua abordagem está focada principalmente na venda de ferramentas de segurança adicionais – e relatos de VMs violadas descobertos por pesquisadores de segurança externos (e até mesmo funcionários do provedor de nuvem) são frequentemente descartados como inacionáveis.
Isso leva a situações em que centenas, às vezes milhares de VMs ficam comprometidas em campanhas de ataque coordenadas e permanecem violadas por semanas ou mais se o cliente não perceber imediatamente.
Um bom exemplo disso é uma campanha de ataque contínuo contra bancos de dados NoSQL protegidos incorretamente, que começou no final de 2016 e continua até hoje.
Pesquisas que realizei contra essa tendência de ataque mostraram que muitos clientes foram colocados em risco devido a configurações de firewall padrão excessivamente permissivas na VM, juntamente com o NoSQL sendo ativado em interfaces de rede voltadas para a Internet e uma falta padrão de autenticação. Encontrei quase 8.000 VMs na nuvem Azure da Microsoft entre 2016-2019 que foram comprometidas.
Na maioria dos casos, os clientes não estavam cientes de que haviam sido expostos à internet ou que um compromisso havia ocorrido – e esses eram apenas nos casos limitados em que as notificações dos clientes foram enviadas. Os ataques não se limitaram ao Azure, é claro, e globalmente havia mais de 100.000 VMs afetadas por ataques contra CassandraDB, Elasticsearch, MongoDB e Redis.
Riscos de Vazamento de Dados
Além do risco de comprometimento, bancos de dados NoSQL não seguros têm sido a fonte de inúmeros vazamentos de dados e problemas de privacidade. A Microsoft expôs acidentalmente 250 milhões de registros de clientes por meio de uma instância Elasticsearch incorretamente segura no final de 2019, e esses problemas continuam a ocorrer em todo o mundo em uma cadência regular.
Os buckets S3 da Amazon eram tão comumente deixados inseguros que os mecanismos de pesquisa foram desenvolvidos para permitir que caçadores de recompensas de bugs (e, inadvertidamente, atores maliciosos) pesquisassem em instâncias S3 expostas por dados valiosos, informações de identificação pessoal (PII), registros financeiros, backups de bancos de dados, credenciais e registros de cartão de crédito. As informações de saúde são outro conjunto de dados comumente exposto, assim como contas de mídia social e dados de publicidade coletados por empresas de armazenamento de dados.
Agregadores de dados terceirizados e empresas de publicidade também são frequentemente a causa de vazamentos de dados de organizações que podem ter políticas rígidas sobre segurança de dados, criptografia em repouso, acesso privilegiado e exposição restrita da Internet a arquivos confidenciais. Somente em 2020, 36 bilhões de registros foram expostos nos três primeiros trimestres.
Melhor Segurança É Essencial
Tudo isso não quer dizer que a rede em nuvem seja inerentemente insegura, mas à medida que o mundo muda para um ambiente de nuvem centrado na nuvem e híbrido, particularmente para forças de trabalho remotas, as organizações precisam reconhecer que sua estratégia, políticas, controles e processos de segurança na nuvem devem ser tão robustos quanto em um ambiente clássico no local. Eles não podem presumir que, como um gigante da tecnologia de Seattle, Redmond ou Bay Area administra sua nuvem, qualquer segurança adicional é incorporada.
Os provedores de nuvem também devem adotar uma abordagem muito mais agressiva e proativa para proteger seus clientes, notificá-los de violações e isolar máquinas virtuais dentro de assinaturas quando o compromisso for detectado.
Existem serviços de monitoramento de terceiros que oferecem detecção em tempo real de varredura automatizada que ocorre na Internet e outros que oferecem detecção em tempo real de beacons de malware emitidos de nuvens, que os provedores são resistentes a utilizar. Alguns dados recentes sobre quatro dos maiores provedores de nuvem (Azure, AWS, Rackspace e Oracle Cloud) mostram um grande número de beacons de malware sendo emitidos em um período de 180 dias. A nuvem Azure da Microsoft foi a pior com 1,4 bilhão de beacons, seguida pela AWS com 793 milhões, Rackspace com 598 milhões e Oracle aparentemente muito melhor com “apenas” 1,4 milhão de beacons.
Se o grande delta é resultado de tamanhos de clientes muito diferentes ou diferenças significativas na postura de segurança é impossível de determinar, mas serve para sublinhar o fato de que os clientes em nuvem estão sendo comprometidos em grande número, e essas infecções não são abordadas.
Ao alavancar sistemas externos em relação aos seus bancos de dados internos de endereços de assinante para IP, os provedores de nuvem podem estar entregando notificações aos clientes em minutos ou horas após o compromisso, dando às organizações o tempo necessário para responder, detectar e expulsar atacantes antes que seja tarde demais.
FONTE: THREATPOST