La importancia de SELinux para proteger una web

Deshabilitar esta herramienta sigue siendo un error frecuente. SELinux es una gran ayuda para hacer hardening

¿Hasta qué punto puede ser importante SELinux? ¿Te imaginas estar en esta situación? «Lunes, 8 de la mañana. Enciendes el ordenador y te dispones a autenticarte en la página web de la empresa para publicar una nueva entrada en el blog… Pero en lugar del panel de login, en tu navegador se muestra el mensaje de error 503: Servicio no disponible. Te entra la inseguridad de siempre: ¡Me han hackeado!

¿Y ahora qué hago? Rápidamente descuelgas el teléfono y llamas a tu informático. Este confirma que no ha necesitado hacer cambios en el servidor desde hace años, pero que hará algunas comprobaciones.

Tras una hora, llama el informático para comentar la situación. Ha accedido a través de SSH a la máquina sin problema y ha visto que hay un programa que consume toda la CPU del servidor. La cuestión es que cada vez que lo borra, vuelve a abrirse él solo tras un rato y no sabe quitarlo. Tampoco funciona reiniciar.

Te informa de que no se puede restaurar una copia de seguridad porque hace tiempo que dejaron de funcionar por falta de espacio, así que necesita ayuda para la desinfección. Tampoco sabe decir desde cuándo está la web así».

Este caso es más frecuente de lo que se piensa en la actualidad. No se actualiza el software de una máquina expuesta a Internet, no se comprueban los backups y cuando falla algo, el impacto puede suponer la pérdida completa de la información.

Así que tras una llamada dan acceso a una copia del disco duro del servidor el cual analizamos de forma estática sin llegar a encenderlo para identificar dónde está la persistencia del virus.

Análisis de la infección

Empezamos a revisar los scripts de arranque del sistema hasta que llegamos al archivo .bashrc del usuario root. En el mismo parece que se han añadido unas líneas que descargan un script para instalar un programa de minado de Bitcoins y guardar persistencia también en cron.

Una vez desofuscado y revisado el script, es posible realizar una completa desinfección borrando todos los archivos a los que se referencia desde el mismo.

Para asegurarnos, de todas formas, hacemos uso de herramientas como rkhunter o ClamAV con el fin de identificar cualquier otro script malicioso que pudiese haber quedado en el sistema.

Lo único que queda pendiente es identificar la vía de entrada. Una revisión de las reglas de firewall inicial desvela que solamente estaban expuestos hacia internet los puertos de web, lo cual acota bastante las posibilidades.

La aplicación publicada es un Drupal con versión 8.5.10, afectado por una vulnerabilidad (código CVE-2019-6340). Esta vulnerabilidad permite a un usuario malintencionado ejecutar comandos del sistema haciendo uso de la funcionalidad API REST.

Procedemos a revisar la configuración de la aplicación web y confirmamos que se estaba ejecutando como un usuario sin privilegios. Pero los archivos de log revelan una gran cantidad de intentos de login seguidos en un espacio temporal corto. Por desgracia, acababan en un login como root satisfactorio.

Para comprobar la fortaleza de la contraseña ponemos a crackear la contraseñas cifrada almacenada en el fichero «/etc/shadow». En cuestión de segundos comprobamos que se trataba de una clave de acceso común. En las recomendaciones de mejora, de cara a evitar este problema otra vez, podrían incluirse los siguientes puntos:

• Actualizar de forma periódica la aplicación web.
• Desplegar soluciones WAF (Web Application Firewall) delante del servidor para protegerlo contra ataques.
• Instalar un software de monitorización o protección del endpoint que recoja los logs del servidor y permita identificar comportamientos no comunes.
• Realizar una auditoría web de seguridad de forma periódica contratando a un agente externo.
• Proteger la aplicación web con un sistema MAC (Mandatory Access Control) como AppArmor o SELinux.

El sistema de control de acceso obligatorio

Y esta última recomendación es en la que queremos hacer hincapié . En caso de explotación de un zero-day, es probable que las actualizaciones y las firmas de un WAF no sean suficientes.

Además, el ataque podría no ser detectado en una etapa temprana en función de su sofisticación, las reglas y las acciones llevadas a cabo. Por estas razones se hace imposible a priori bloquear todos los ataques.

Un sistema MAC consta de una serie de reglas que definen qué permisos tiene cada proceso, como a qué archivos puede acceder o si puede abrir conexiones de red hacia otros servicios del propio servidor.

Los sistemas MAC más extendidos son AppArmor, incluido con Ubuntu Server o derivados, y SELinux, preinstalado en RedHat o derivados.

En el caso de SELinux, muchas guías para instalación de software en RedHat o CentOS tienen un primer paso en su índice titulado «Deshabilitar SELinux». Esto se debe a que se trata de un sistema que, si no se configura correctamente, impide la conexión del servidor web con la base de datos o incluso la lectura de los archivos que se quieren servir hacia internet.

Por ello hay fabricantes que, en la guía oficial de instalación de su solución de software, incluyen este paso.

Si SELinux hubiese estado habilitado y configurado en el escenario inicial, la ejecución de código remoto habría seguido existiendo. La diferencia habría sido que los atacantes no habrían podido lanzar el proceso para elevar privilegios, o ni siquiera les habría sido posible lanzar conexiones de red hacia el exterior.

El despliegue del agente de minado de Bitcoins que consumía toda la CPU se habría hecho más complicado y probablemente, pese a tener una versión de software vulnerable, no hubiese habido intrusión.

Descubre nuestro trabajo y nuestros servicios de ciberseguridad en www.tarlogic.com/es/

En TarlogicTeo y en TarlogicMadrid.