Muitas empresas já utilizam um ambiente cloud composto de recursos de nuvens privadas locais e públicas – uma nuvem híbrida. No entanto, quando se trata de cibersegurança, as empresas tendem a se concentrar mais na proteção de ambientes físicos ou virtualizados, prestando muito menos atenção à parte de sua infraestrutura que reside em nuvens públicas. Algumas companhias, inclusive, têm certeza de que os provedores devem ser responsáveis pela proteção. Outras pensam que as nuvens públicas são seguras por padrão, concebidas assim, e, portanto, não exigem proteção adicional. Mas essas duas hipóteses são errôneas: as públicas são propensas à exploração de vulnerabilidades de software, ataques tipo “poisoning” das atualizações, exploração de conexão de rede e comprometimento de informações da conta quanto o restante de sua infraestrutura. E aqui está o porquê.

Vulnerabilidades do RDP e SSH
Por padrão, o RDP está ativado nas instâncias da Amazon e não oferece suporte padrão à autenticação de dois fatores. O RDP se tornou o alvo de muitas ferramentas diferentes para ataques de força bruta. Alguns deles se concentram em vários nomes de usuário padrão mais comuns (como “Administrador”) e fazem milhares de tentativas de acesso. Outros tentam adivinhar o nome de login exclusivo do administrador usando sobrenomes e senhas comuns. Os algoritmos de força bruta podem limitar e randomizar o número de tentativas, com um tempo limite entre os conjuntos de tentativas, para evitar a detecção automatizada. É interessante destacar que o método de ataque é forçar a senha com força bruta para o logon do usuário do SSM, geralmente programado nas instâncias da AWS.

Semelhantes tentativas de ataques de força bruta têm como alvo os serviços SSH o tempo todo e, embora o SSH ofereça maior proteção que o RDP (por exemplo, autenticação de dois fatores), um serviço configurado de forma descuidada pode prontamente fornecer acesso a um cibercriminoso muito persistente. Os ataques de força bruta no SSH e no RDP representaram 12% de todos os ataques aos honeypots da idC da Kaspersky durante o primeiro semestre de 2019.

Vulnerabilidades em software de terceiros
Nuvens públicas podem expor você a vulnerabilidades (e, de fato, o fazem). Aqui estão alguns exemplos de como uma vulnerabilidade em software de terceiros oferece a um invasor a chance de executar código na própria instância.

Em 3 de junho de 2019, uma vulnerabilidade foi descoberta no Exim, um servidor de e-mail popular comumente instalado em nuvens públicas. A vulnerabilidade permitiu a execução remota de código. Se o servidor fosse executado como root, como é mais comum, o código maligno introduzido no servidor seria executado com privilégios de root. Outra vulnerabilidade do Exim, identificada em julho de 2019, também permitiu a execução remota de código como root.

Outro exemplo é o hack de 2016 do site oficial do Linux Mint, que resultou na alteração das distribuições para incluir malware incorporando uma backdoor de IRC com funcionalidade DDOS. O malware também pode ser usado para soltar cargas maliciosas em máquinas infectadas. Outros casos relatados envolveram módulos node.js maliciosos, contêineres infectados no Docker Hub e muito mais.

Como reduzir o risco
Os cibercriminosos podem ser muito engenhosos quando se trata de encontrar pontos de entrada em infraestruturas, especialmente onde existem muitas dessas infraestruturas, todas muito semelhantes e com problemas comuns, e todas convenientemente consideradas altamente seguras por padrão. Para reduzir e gerenciar o risco com muito mais eficiência, proteja os sistemas operacionais nas instâncias da nuvem e nas máquinas virtuais. A proteção básica antivírus e antimalware claramente não é suficiente. As práticas recomendadas do setor determinam que todo sistema operacional em uma infraestrutura precisa de proteção abrangente e multicamada, uma boa prática indicada também pelos provedores de nuvens públicas.

Fonte: Kaspersky