Las vulnerabilidades de las nubes públicas y cómo protegerlas

Al igual que la infraestructura de nube local, las nubes públicas también están expuestas a la explotación de sus vulnerabilidades de software, a los ataques tipo poisoning (envenenamiento) del repositorio de actualización, a la explotación de las conexiones de red y al compromiso de la información de la cuenta.

Creer que los proveedores de servicios en la nube deberían encargarse de la protección del software o que las nubes públicas se han diseñado para ser completamente seguras, por lo que no requieren protección adicional, serían suposiciones totalmente incorrectas.

Al menos así lo ha considerado Andrey Pozhogin, gerente senior de Marketing de Producto (Hybrid Cloud Security de Kaspersky), en una entrada de blog publicada recientemente.

El experto ha recordado que muchas empresas utilizan ambientes basados en la nube que consisten en recursos de nubes públicas y nubes privadas locales, lo cual se conoce como nube híbrida.

“Sin embargo, en términos de ciberseguridad, las empresas tienden a centrarse más en la protección de los ambientes virtualizados o físicos, por lo que descuidan la parte de la infraestructura que se encuentra en las nubes públicas”.

A su juicio, se debe prestar mayor atención a las vulnerabilidades de la nube pública por ciertos aspectos que ha querido detallar. En principio, ha dicho que el RDP (Remote Desktop Protocol o Protocolo de Escritorio Remoto), por defecto, se encuentra en instancias como Amazon y que no está diseñado para ser compatible con la autentificación de dos factores (2FA).

Señaló que el RDP se ha convertido en el objetivo de diferentes herramientas de ataque por fuerza bruta y que algunos de estos se centran en varios de los nombres de usuario por defecto más frecuentes (como Administrador) e intentan adivinarlo miles de veces.

Otros, por su parte, intentan dar con el nombre de inicio de sesión único del administrador mediante los apellidos y las contraseñas más frecuentes. En este sentido, ha apuntado que los algoritmos de los ataques por fuerza bruta pueden limitar o aleatorizar el número de intentos, con pausas entre conjuntos de ataques, con el fin de evadir la detección automática.

Para Pozhogin, otro método es el ataque por fuerza bruta de las contraseñas de las credenciales de inicio de sesión del usuario de SSH (Secure Shell o Cubierta Segura), que a menudo se encuentra programado en las instancias de AWS.

Secure Shell es el nombre de un protocolo y del programa que lo implementa que permite el acceso remoto a un servidor, por medio de un canal seguro, en el que toda la información está cifrada.

“Los servicios SSH se enfrentan todo el tiempo a intentos similares de ataque por fuerza bruta y, a pesar de que SSH ofrece mayor protección que RDP (por ejemplo, la autenticación de doble factor), un servicio configurado a la ligera puede proporcionar acceso inmediato a un ciberdelincuente muy persistente”.

De acuerdo a lo planteado por el ejecutivo de Kaspersky, los ataques por fuerza bruta contra SSH y RDP constituyen hasta el 12% del total de ataques que han sufrido los honeypots (sistema trampa o señuelo) de IdC de Kaspersky durante la primera mitad del 2019.

Vulnerabilidades de las nubes públicas

Andrey Pozhogin ha insistido en que las nubes públicas o el software de terceros pueden, y de hecho lo hacen, exponer a sus usuarios a las vulnerabilidades. De hecho, ha ofrecido un par de ejemplos de cómo una vulnerabilidad en el software de terceros le ofrece a un atacante la oportunidad de ejecutar un código en la propia instancia.

El primer caso ocurrió el 3 de junio del 2019 cuando se descubrió una vulnerabilidad en Exim, un famoso servidor de correo electrónico que normalmente se implementaba en las nubes públicas.

“La vulnerabilidad permitía la ejecución de código remoto. Si el servidor se ejecutaba con privilegios root, como suele ser, el código malicioso que se introducía en el servidor se ejecutaría con privilegios root. Otra vulnerabilidad de Exim, identificada en el 2019, también permitía la ejecución de código remoto con privilegios root”.

Otro ejemplo es el hackeo que en 2016 sufrió el sitio web oficial de Linux Mint, lo que provocó la alteración de las distribuciones para incluir malware con una puerta trasera IRC con funcionalidad DDOS (Ataque de Denegación de Servicio Distribuido).

En este caso, ha explicado que el malware también pudo usarse para introducir cargas nocivas en las máquinas infectadas. “Otros casos referidos involucraban a los módulos node.js maliciosos, contenedores infectados en el Docker Hub, entre otros”.

Con estos ejemplos ha puntualizado los ciberdelincuentes pueden ser muy ingeniosos a la hora de encontrar puntos de acceso a la infraestructura, especialmente cuando hay muchas infraestructuras, todas parecidas y con problemas similares, y creen que son seguras por defecto.

Entonces, proteger los sistemas operativos en las instancias de nube y máquinas virtuales sería el primer paso para reducir y gestionar el riesgo de modo más efectivo.

“Evidentemente, no basta con una protección básica de antivirus y antimalware. Las mejores prácticas de la industria indican que todos los sistemas operativos de una infraestructura necesitan una protección integral y de múltiples capas; una recomendación que también hacen los proveedores de servicios de nube pública”.

Ante esta problemática, Pozhogin ha recordado el surgimiento la solución de seguridad Kaspersky Hybrid Cloud Security, que protege varios tipos de cargas de trabajo en distintas plataformas mediante el uso de múltiples capas de tecnologías de seguridad.

Kaspersky Hybrid Cloud Security incluye el reforzamiento del sistema, la prevención de exploits, la supervisión de la integridad de archivos, un bloqueador de ataques de red antimalware estático y basado en comportamiento, entre otros beneficios.