Lo más probable es que la misma palabra 'Linux' evoque imágenes de seguridad casi impenetrable. Sin embargo, los sistemas informáticos basados ​​en Linux y las aplicaciones que se ejecutan en ellos están cada vez más en la mira de los actores maliciosos. De hecho, en los últimos años se han descubierto varias campañas maliciosas que afectan a los sistemas Linux, incluidas redes de bots formadas por miles de servidores Linux. Estas crecientes amenazas han desafiado la creencia extendida de que Linux está más o menos a salvo de los problemas que afectan a otros sistemas operativos, particularmente a Windows.

Desafortunadamente, muchos administradores de sistemas Linux carecen del conocimiento necesario para contrarrestar las amenazas que enfrentan sus infraestructuras. Para ayudar a cambiar eso, Marc-Etienne dirigirá un taller en la próxima Conferencia RSA 2020, titulado Hunting Linux Malware for Fun and Flags, que brindará a los profesionales de TI una excelente oportunidad para enfrentarse al malware para Linux en un entorno controlado .

Antes de su taller y presentación, aprovechamos la oportunidad para preguntarle a Marc-Etienne sus opiniones sobre la seguridad en Linux.

Has dedicado años buscando malware que se infiltra en servidores basados ​​en Linux. ¿Nos podría dar primero un panorama general del escenario actual del malware dirigido a Linux?

El panorama del malware dirigido a Linux para el 2020 es bastante similar a lo que hemos visto en los últimos años. Sabemos que Ebury, el backdoor OpenSSH utilizado en Operación Windigo, todavía siendo actualizando y utilizando de manera activa en 2020. Se vieron nuevas muestras durante el último mes. Hace unos años, también hubo un incremento en el malware para Linux que apuntaba principalmente a routers y otros periféricos basados ​​en Linux, por ejemplo, Mirai y todas sus variantes, así como Moosse . Escuchamos menos sobre estas amenazas últimamente y espero que sea porque los proveedores de servicios de Internet (ISP, por sus siglas en inglés) y los vendedores han hecho un mejor trabajo a la hora de proteger estos dispositivos y están evitando exponer el acceso a la administración remota con contraseñas predeterminadas.

Todavía tenemos que encontrar una campaña tan sofisticada como lo fue Operación Windigo la cual documentamos hace más de cinco años. Pero esto no significa que no haya una. ¿Quizás los actores maliciosos están haciendo las cosas mejor para permanecer lejos del radar?

¿Cuáles son las principales amenazas que enfrentan los servidores Linux?

Las amenazas dependen principalmente de los servicios prestados por los servidores. Por ejemplo, si un sitio web popular se ve comprometido, podría ser utilizado para redirigir tráfico, realizar un ataque de watering hole para comprometer a quienes visitan el sitio o para robar datos de formularios enviados . También estamos observando mucho spam siendo enviado por lo que parecen ser servidores comprometidos. Algo que estamos viendo más ahora que hace unos años es la distribución mineros de criptomonedas. Es una manera simple de monetizar una botnet de Linux sin interferir demasiado con los servicios de host legítimo.

¿Qué ha cambiado desde que analizaste por primera vez malware para Linux?

Estamos viendo más grupos realizando ataques dirigidos que incluyen malware para Linux en su arsenal. Esto va más allá de las habituales campañas de crimeware que estuvimos observando con el objetivo de obtener ganancias financieras. Por ejemplo, se descubrió el año pasado que el Grupo Winnti, conocido tanto por sus campañas con fines de espionaje y también financieros, tiene variantes para Linux de sus backdoors. Esto fue revelado por Kaspersky durante la SAS y analizado por Chronicle unas semanas después. Otros buenos ejemplos son Xagent, el backdoor multiplataforma del grupo Sednit, y Kamino, un backdoor OpenSSH utilizado por Carbanak.

Algunas de las campañas que ayudó a descubrir habían permanecido bajo el radar durante años. ¿Por qué? ¿Crees que esto también puede estar cambiando?

Es difícil decir si hay más campañas que debajo del radar, porque todavía no conocemos lo que desconocemos. Lo que quiero decir es que es muy probable que existan múltiples botnets de Linux que aún no están documentadas. ¿Cuántas? ¿Más o menos que antes? Esas son preguntas difíciles de responder sin métricas.

¿Cómo la falta de telemetría con respecto al malware de Linux dificulta su trabajo?

Solo un pequeño porcentaje de usuarios instala productos de seguridad en sistemas Linux. Esto significa que es difícil determinar la prevalencia de una amenaza para Linux: ¿los números son bajos porque los tamaños de las muestras son pequeños o es porque esta amenaza es poco común? Este no es un problema del proveedor: existe una tendencia general a tratar los sistemas Linux de manera diferente, a veces por buenas razones, pero creo que la mayoría de las veces por malas razones.

Cada vez que se descubre un nuevo malware dirigido a Linux los usuarios de Linux parecen sorprendidos y tienden a negar el problema. ¿Crees que Linux es más seguro que los otros sistemas operativos?

Mucha gente piensa en Linux como un sistema operativo con una seguridad superior en comparación con todos los demás. En 2020, no creo que esto sea algo que podamos afirmar. Tanto Microsoft como Apple han puesto mucho esfuerzo en asegurar sus plataformas. Por ejemplo, las firmas de código embebidas en archivos ejecutables y respetando las firmas válidas para funcionalidades clave tanto del sistema como de controladores de dispositivo es algo que ha estado disponible en Windows y macOS durante años, mientras que en Linux todavía no está muy extendido. No digo que Linux sea inseguro, sino que, al igual que las otras plataformas, tiene sus puntos fuertes y débiles y, desde luego, no debe considerarse a prueba de balas.

¿Aparte del código malicioso, hay algo que distinga al malware para Linux del código malicioso que apunta a otros sistemas operativos? ¿Algo que se destaque en términos de sigilo, ofuscación, persistencia ...?

En comparación con el malware para Windows, el malware que apunta a Linux tiende a ser menos ofuscado y más fácil de analizar. La ofuscación a menudo se agrega para evadir la detección por productos de seguridad. Como a menudo no hay productos de seguridad que evadir, los atacantes omiten este paso innecesario. No estoy diciendo que todo el malware de Linux sea fácil de analizar y que ninguno esté ofuscado; estoy diciendo que este es el escenario promedio.

Cuando un servidor Linux se ve comprometido, la persistencia del malware no es un problema tan grande como lo puede ser en otros sistemas. Los servidores tienden a tener tiempos de actividad muy altos y los reinicios son mucho menos frecuentes que en las computadoras de escritorio o portátiles. Como resultado, en general, el malware para Linux tiende a carecer de mecanismos de persistencia.

¿Cuáles son los vectores de ataque más comunes para comprometer servidores Linux?

Creo que las vulnerabilidades en las aplicaciones web siguen siendo uno de los vectores de ataque más comunes para comprometer a los servidores Linux. Sin embargo, hemos visto vulnerabilidades reveladas en los últimos años en servicios que son muy populares, como el servidor de correo Exim (CVE-2019-10149). La explotación de esta vulnerabilidad fue bastante fácil y vimos muchos intentos de usarla para propagar malware justo después de que se revelara.

¿Cuáles son las mejores formas de prevenir tales infiltraciones?

Sé que puede sonar como un disco rayado, pero mantener el software actualizado sigue siendo una de las recomendaciones clave. Para los servidores de producción que ejecutan una distribución de Linux con soporte a largo plazo es preferible asegurarse la disponibilidad de parches de seguridad sin tener que actualizar el sistema operativo completo y arriesgarse a romper los servicios de producción.

Habilitar el doble factor de autenticación (2FA, por sus siglas en inglés) en SSH también es una buena recomendación, especialmente si se puede acceder al sistema desde Internet. El doble factor de autenticación protegerá el servidor si se roban o reutilizan las credenciales.

Para evitar pasar de un servicio a otro, aislar los servicios también es una buena práctica. Por ejemplo, alojar un blog que no recibe mantenimiento en el mismo sistema que un sitio web en el que se procesan transacciones financieras representa un riesgo, ya que comprometer el blog puede derivar en que se comprometa el sitio web en el que se realizan transacciones.

Hace cinco años, usted dijo que la falta de conocimiento forense de Linux es el principal problema para los administradores de sistemas. ¿Ha cambiado esto?

Creo que esto sigue siendo un problema, pero la causa de esto también es la falta de tiempo asignado para asegurar los sistemas, en comparación con el desarrollo de otros nuevos. Del mismo modo, el esfuerzo dedicado a capacitar al personal interno sobre seguridad a menudo es mínimo. No es nada nuevo que la seguridad sea vista como un gasto. Este no es un problema específico de Linux. Sin embargo, ese gasto de repente parecería útil si ocurre un incidente.

Pasemos ahora nuestra atención a su próximo taller en la RSA. ¿Nos darías un vistazo de tus actividades allí?

Será mi primera vez en la RSA. Espero presentar algunos contenidos técnicos en forma de taller práctico y una presentación el jueves durante el evento.

El taller estará abierto durante la semana completa de la RSA y solo se requiere tener una computadora con un navegador web, el cliente OpenVPN y un cliente SSH. La idea es recrear una situación real: el servidor es comprometido de manera activa mediante un servicio vulnerable, el malware se comunica con un servidor de C&C, etc. Visítenos en el stand de ESET para obtener acceso al taller.

Mi presentación resumirá varias de las herramientas de Linux comúnmente disponibles para investigar una brecha. Es importante comprender qué datos y metadatos están disponibles y cómo consultarlos y analizarlos. Explicaré cómo estas herramientas fueron útiles en incidentes reales en los que hemos trabajado.

Gracias, Marc-Etienne!