La L en Linux significa Movimiento Lateral

Esta entrada de blog no pretende servir de guía para la piratería informática de Linux, sino informar a los defensores de redes sobre las amenazas potenciales que pueden afectar a sus redes.

La mayoría de los protocolos que trataremos en esta publicación, si no todos, no están disponibles de serie, sino que deben configurarse de forma específica para lograr el movimiento lateral. No proporcionaremos guías para abusar de los protocolos tratados en esta publicación.

Esperamos concienciar sobre otros protocolos que se pueden configurar de tal manera que puedan servir como un elemento vulnerable del que se aprovechen los atacantes. Un hacker decidido puede encontrar, encontrará y abusará de los protocolos cubiertos en esta publicación sin que le informemos de ello; queremos que los equipos azules estén preparados para ello.

Para ayudar más a los defensores, nos hemos asociado con nuestro equipo de Infection Monkey. Infection Monkey es una plataforma de código abierto para ataques y vulneraciones automáticas que comprueba la red frente a muchas técnicas comunes de propagación de redes y movimientos laterales. 

El equipo de desarrollo utilizó los resultados de nuestra investigación y los incorporó como una nueva técnica de explotación dentro de la herramienta. Los defensores pueden utilizar Infection Monkey para probar su red contra algunas de las técnicas de ejecución remota mencionadas en esta publicación.

(Nota: Esta sección trata sobre el método que utilizamos para encontrar objetivos de movimiento lateral interesantes. Si no está interesado en la metodología y prefiere saltar directamente a la acción, no dude en saltar a los protocolos que permiten la ejecución inmediata de código).

Puesto que estamos buscando protocolos y servicios de movimiento lateral, podemos considerar tanto el aspecto del sistema operativo como el aspecto de la red al buscar posibles candidatos; es decir, podemos buscar los procesos más comunes en equipos Linux, o en los puertos de escucha más comunes. No debemos descuidar uno a favor del otro ya que puede haber diferentes implementaciones del mismo protocolo (nombre de proceso diferente, mismo puerto) o un único proceso con múltiples puertos o puertos cambiantes (como puertos efímeros en RPC).

Cuando analizamos los principales puertos utilizados en la comunicación con equipos Linux, vimos que SSH (puerto 22) dominaba la lista, pero también había otros candidatos prometedores para la investigación: FTP (puerto 21), SNMP (puerto 161) y RPC de Sun (puerto 111). 

También hay unos pocos puertos que estaban manejados por sshd (el proceso daemon SSH) aunque no tienen nada que ver con SSH. Suponemos que se utilizan en túneles SSH y, por lo tanto, están fuera de nuestro ámbito de investigación. 

Tomemos, por ejemplo, los puertos 135 y 5985, utilizados en Windows para RPC y WinRM, respectivamente. No esperamos esos puertos en los equipos Linux, especialmente cuando sshd escucha en ellos. Es más probable que se haya abierto un túnel SSH en un equipo Linux disponible externamente para permitir el acceso a equipos internos. Dado que los túneles SSH solo redirigen el tráfico a otro destinatario, no importan demasiado al considerar el movimiento lateral hacia el host del túnel.

Entre nuestros hallazgos, surgieron dos procesos interesantes para su consideración: xinetd y rpcbind. No son viables como objetivos de movimiento lateral, ya que no ofrecen muchas capacidades; se utilizan principalmente para operaciones de búsqueda a fin de asignar comunicaciones y puertos a otros procesos. En su lugar, podemos utilizarlos para encontrar otros servicios interesantes.

xinetd (y su predecesor, inetd) se utiliza para controlar y gestionar daemons. Si observamos la lista predeterminada de daemons que gestiona, podemos encontrar a rexec, así como a rlogin y rsh, todo parte del conjunto de comandos r de Berkeley. También podemos encontrar varios daemons FTP, VNC y Telnet.

rpcbind es el proceso del asignador de puertos RPC para RPC de Sun. Los servidores RPC se registran con el asignador de puertos y los clientes pueden consultarlo para encontrar el puerto efímero del servidor. A diferencia de MS-RPC, RPC de Sun utiliza números de programa para identificar servidores RPC específicos y a aquellos que se registran con la Autoridad de Números Asignados de Internet (IANA). Si observamos los programas registrados, podemos ver algunos nombres interesantes, como rexec y NFS.

El 24 % de los equipos Linux probados

Independientemente de las capacidades integradas de SNMP, también es un objetivo de los atacantes, con algunos atacantes que utilizan vulnerabilidades en las implementaciones de SNMP en enrutadores y dispositivos IoT para vulnerar las redes. El abuso de SNMP ha llegado al punto en que la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) de EE. UU. publicó un asesoramiento sobre el protocolo.

Para ayudar a hacer pruebas contra esta amenaza, nos hemos asociado con nuestro equipo de Infection Monkey para desarrollar un complemento de explotación para el complemento EXTEND remoto de SNMP. La ejecución de Infection Monkey le permitirá ver el aspecto que tendría este ataque en su entorno y verificará si su estrategia de seguridad es suficiente para refutar el ataque. El ataque SNMP está disponible en la última versión de Infection Monkey, v2.2.1.

El 10 % de los entornos Linux probados

No, no estamos hablando de RDP específicamente, el protocolo de escritorio remoto propio de Microsoft (pero aparecerá, no se preocupe). Existen otros protocolos de escritorio remoto que se pueden ejecutar en equipos Linux. Son mucho menos comunes que en los entornos Windows, ya que están diseñados para compartir escritorios gráficos y la mayoría de los servidores Linux se instalan sin ningún entorno de escritorio. 

Sin embargo, vimos esos protocolos utilizados en algunas redes, por lo que elaboraron la lista y se incluyen aquí:

• El sistema X Window es un sistema de ventanas de escritorio disponible para Unix, y también puede escuchar conexiones remotas. Utiliza los puertos TCP 6000+ (comienza con el puerto 6000, pero el número de puerto aumenta posteriormente para cada servidor de escritorio que se ejecute).

• VNC se basa en el protocolo Remote Framebuffer (RFB) y utiliza los puertos TCP 5900+ (de forma similar a X, el número de puerto aumenta con cada servidor de escritorio en ejecución).

• Xrdp es una implementación del protocolo RDP de Microsoft que se puede utilizar en equipos que no sean Windows. Como implementación de RDP, utiliza el puerto 3389.

Algunos de los protocolos de escritorio remoto son más seguros que otros, pero los atacantes pueden abusar de todos potencialmente. También hay múltiples implementaciones de los protocolos en Linux, por lo que incluimos aquí los números de puerto en lugar de los nombres de programa.

El 4 % de los entornos Linux probados

Como SSH y rlogin, Telnet es también un protocolo para la consola y el control remotos. También es poco seguro y no cifrado, de forma similar a rlogin, y vulnerable a ataques de interceptación o de sniffing de paquetes. Solo lo hemos visto en aproximadamente el 4 % de las redes que examinamos, pero significa que todavía está en uso y podría afectar a su red. El protocolo utiliza el puerto TCP 23 o 2323.

El 1 % de los entornos Linux probados

Los comandos r de Berkeley son un conjunto de programas que permiten operaciones remotas entre equipos de la red. Originalmente desarrollados como parte de BSD, han sido reemplazados en gran medida por SSH, principalmente debido a las preocupaciones de seguridad de esos protocolos (sin cifrado y con una autenticación mínima o inexistente). 

Sin embargo, hemos visto algunos de los daemons del conjunto aquí y allá, así que es demasiado pronto para descartarlos por completo. Hay tres daemons que nos gustaría poner en el centro de atención:

1. rexec: proporciona la ejecución remota de comandos; utiliza el puerto TCP 512

2. rlogin: proporciona el inicio de sesión y consola remotos; utiliza el puerto TCP 513

3. rsh: similar a rexec, pero no requiere autenticación; utiliza el puerto TCP 514

Incluso si no se permiten directamente el control o la ejecución remotos, tener la capacidad de transferir archivos al equipo de destino puede resultar útil para el desarrollo de ataques. Echemos un vistazo, por ejemplo, a la técnica común de movimiento lateral (y herramienta) PsExec, aunque esté basada en Windows.

En primer lugar, copia su binario de servicio en el equipo de destino a través de SMB y solo entonces consigue que el servicio se ejecute comunicándose con el gestor de servicios de forma remota. Por eso creemos que es importante asignar también las distintas formas en que las herramientas y los binarios de los atacantes se pueden colocar en los equipos de destino. También hemos teorizado algunos métodos de abusar de la transferencia de herramientas para lograr la ejecución remota, que trataremos más adelante en esta publicación.

El 31 % de los entornos Linux probados

El protocolo de transferencia de archivos (FTP) es uno de los protocolos más clásicos (fue el primer protocolo de capa de aplicación enseñado en la clase de redes). Utilizado para la transferencia de archivos, es un protocolo basado en texto que no es seguro, ya que utiliza texto no cifrado.

El 20 % de los entornos Linux probados

El 18 % de los entornos Linux probados

El sistema de archivos de red (NFS) es otra forma de crear servidores de archivos. Está construido sobre RPC de Sun (puerto TCP 111). Hay muchas funciones RPC que podemos ver, pero no encontramos una manera inmediata de obtener la ejecución remota de comandos a través de ella.

El 16 % de los entornos Linux probados

rsync es una utilidad para la transferencia de archivos y la sincronización entre equipos de la red. Se puede ejecutar como un servicio o un daemon, y puede servir archivos a través de su protocolo dedicado (puerto TCP 873), rsh o SSH.

Podemos discutir la transferencia de archivos todo lo que queramos, pero no es muy útil a menos que los atacantes puedan ejecutar los archivos transferidos de alguna manera. Además de engañar al usuario para que ejecute el archivo por sí mismo, hemos pensado en dos opciones para lograr la ejecución: ambas requieren algún tipo de configuración incorrecta o una relajación (grave) de la configuración de seguridad.

Hay muchas ubicaciones legítimas en el sistema de archivos Linux que se pueden utilizar para instalar la persistencia, pero para el movimiento lateral nos centraremos en /etc/cron.hourly. Si un atacante puede cargar un archivo allí, con permisos de ejecución, simplemente se ejecutaría en la siguiente hora de ronda, logrando así el largo y codiciado movimiento lateral.

Pero, para ello, un atacante necesitaría permisos sudo o root, que no son fáciles de conseguir. Lamentablemente, es posible configurar servidores de archivos de una manera no segura, lo que permitiría esta situación exacta (consulte rsync, por ejemplo). ¿Por qué alguien configuraría esos servicios con tan poca seguridad? Porque es cómodo y les hace la vida más fácil. Por favor, no sea ese alguien: Protéjase.

Un escenario mucho más plausible, en lugar de acceder a /etc, sería el acceso remoto a una carpeta raíz web de un servidor web activo. En ese caso, debería ser posible cargar un shell web personalizado y utilizarlo para ejecutar comandos remotos. Hay muchos ejemplos de web shells disponibles online, por lo que los atacantes ni siquiera tienen que innovar en nada.

Otro aspecto que se está volviendo cada vez más popular en los últimos años son los contenedores. En nuestra investigación, hemos visto varias instancias de programas contenedores escuchando y aceptando conexiones, y parece que también está permitido por diseño. Si los atacantes pueden acceder a un gestor de contenedores remoto, pueden cargar su propia imagen maliciosa y utilizarla para propagarse más dentro de la red.

Ahora que hemos cubierto posibles formas de que los atacantes accedan a los equipos, es hora de hablar sobre cómo mantenerlos fuera.

Como ya hemos mencionado, ninguno de los protocolos que hemos comentado aquí viene instalado y configurado con Linux de serie. Alguien debe instalarlos específicamente. Como tal, la primera orden del día sería tener una buena visibilidad de lo que está funcionando y comunicándose (o escuchando la comunicación) en la red, como escribió Sun Tsu, "Si no conoces ni al enemigo ni a ti mismo, sucumbirás en cada batalla".

Una vez que haya realizado un inventario de su red e identificado uno de los servicios que se describen aquí, el siguiente paso es comprobar la configuración de esos servicios. Por ejemplo, un agente SNMP actualizado que esté configurado para utilizar SNMPv3 con autenticación Kerberos está perfectamente bien. ¿Un SNMPv2 con una cadena de comunidad que se adivina fácilmente? No tanto.

Otros protocolos o servicios pueden ser reemplazados por protocolos más nuevos y más seguros, como el uso de SSH en lugar del conjunto de comandos r o Telnet. Algunos protocolos, como FTP o rsync, también se pueden encapsular a través de SSH, para el beneficio adicional del cifrado que proporciona SSH. Ni que decir tiene que: tendrá que asegurarse de que SSH también está configurado correctamente, con PKI o contraseñas seguras que no sean fácilmente pirateables.