💻Protocolos de Administración Remota - Linux
Introducción
En el mundo de las distribuciones de Linux, existen muchas formas de administrar los servidores de forma remota. Por ejemplo, imaginemos que estamos en una de muchas ubicaciones y uno de nuestros empleados que acaba de acudir a un cliente en otra ciudad necesita nuestra ayuda debido a un error que no puede solucionar. En la mayoría de los casos, la resolución de problemas eficiente parecerá difícil a través de una llamada telefónica, por lo que es beneficioso si sabemos cómo iniciar sesión en el sistema remoto para administrarlo.
Estas aplicaciones y servicios se pueden encontrar en casi todos los servidores de la red pública. Ahorra tiempo ya que no tenemos que estar físicamente presentes en el servidor y el entorno de trabajo sigue teniendo el mismo aspecto. Estos protocolos y aplicaciones para la gestión remota de sistemas son un objetivo interesante por estos motivos. Si la configuración es incorrecta, nosotros, como probadores de penetración, podemos incluso acceder rápidamente al sistema remoto. Por tanto, conviene que nos familiaricemos con los protocolos, servidores y aplicaciones más importantes para este fin.
SSH
Secure Shell ( SSH) permite que dos computadoras establezcan una conexión directa y cifrada dentro de una red posiblemente insegura en el puerto estándar TCP 22. Esto es necesario para evitar que terceros intercepten el flujo de datos y, por tanto, intercepten datos confidenciales. El servidor SSH también se puede configurar para permitir solo conexiones de clientes específicos. Una ventaja de SSH es que el protocolo se ejecuta en todos los sistemas operativos comunes.
Dado que originalmente es una aplicación Unix, también se implementa de forma nativa en todas las distribuciones de Linux y MacOS. SSH también se puede utilizar en Windows, siempre que instalemos un programa adecuado. El conocido servidor OpenBSD SSH ( OpenSSH) en distribuciones de Linux es una bifurcación de código abierto del servidor SSH original y comercial de SSH Communication Security. En consecuencia, existen dos protocolos en competencia: SSH-1y SSH-2.
SSH-2, también conocido como SSH versión 2, es un protocolo más avanzado que SSH versión 1 en cifrado, velocidad, estabilidad y seguridad. Por ejemplo, SSH-1 es vulnerable a ataques MITM, mientras que SSH-2 no lo es.
Podemos imaginar que queremos administrar un host remoto. Esto se puede hacer a través de la línea de comando o GUI. Además, también podemos utilizar el protocolo SSH para enviar comandos al sistema deseado, transferir archivos o reenviar puertos. Por lo tanto, debemos conectarnos mediante el protocolo SSH y autenticarnos en él. En total, OpenSSH tiene seis métodos de autenticación diferentes:
Password authenticationPublic-key authenticationHost-based authenticationKeyboard authenticationChallenge-response authenticationGSSAPI authentication
Examinaremos más de cerca y analizaremos uno de los métodos de autenticación más utilizados. Además, podemos aprender más sobre los otros métodos de autenticación aquí entre otros.
Autenticación de clave pública
En un primer paso, el servidor SSH y el cliente se autentican entre sí. El servidor envía un certificado al cliente para verificar que es el servidor correcto. Sólo cuando se establece el contacto por primera vez existe el riesgo de que un tercero se interponga entre los dos participantes e intercepte así la conexión. Dado que el certificado en sí también está cifrado, no se puede imitar. Una vez que el cliente conoce el certificado correcto, nadie más puede pretender establecer contacto a través del servidor correspondiente.
Sin embargo, después de la autenticación del servidor, el cliente también debe demostrar al servidor que tiene autorización de acceso. Sin embargo, el servidor SSH ya posee el valor hash cifrado de la contraseña establecida para el usuario deseado. Como resultado, los usuarios deben ingresar la contraseña cada vez que inician sesión en otro servidor durante la misma sesión. Por este motivo, una opción alternativa para la autenticación del lado del cliente es el uso de un par de claves públicas y privadas.
La clave privada se crea individualmente para la computadora del usuario y se protege con una frase de contraseña que debe ser más larga que una contraseña típica. La clave privada se almacena exclusivamente en nuestro propio ordenador y siempre permanece secreta. Si queremos establecer una conexión SSH, primero ingresamos la frase de contraseña y así abrimos el acceso a la clave privada.
Las claves públicas también se almacenan en el servidor. El servidor crea un problema criptográfico con la clave pública del cliente y se lo envía al cliente. El cliente, a su vez, descifra el problema con su propia clave privada, devuelve la solución y así informa al servidor que puede establecer una conexión legítima. Durante una sesión, los usuarios solo necesitan ingresar la frase de contraseña una vez para conectarse a cualquier número de servidores. Al final de la sesión, los usuarios cierran la sesión de sus máquinas locales, lo que garantiza que ningún tercero que obtenga acceso físico a la máquina local pueda conectarse al servidor.
Configuración predeterminada
El archivo sshd_config , responsable del servidor OpenSSH, tiene solo algunas de las configuraciones configuradas de forma predeterminada. Sin embargo, la configuración predeterminada incluye el reenvío X11, que contenía una vulnerabilidad de inyección de comandos en la versión 7.2p1 de OpenSSH en 2016. Sin embargo, no necesitamos una GUI para administrar nuestros servidores.
La mayoría de las configuraciones en este archivo de configuración están comentadas y requieren configuración manual.
Configuraciones peligrosas
A pesar de que el protocolo SSH es uno de los protocolos más seguros disponibles en la actualidad, algunas configuraciones erróneas aún pueden hacer que el servidor SSH sea vulnerable a ataques fáciles de ejecutar. Echemos un vistazo a las siguientes configuraciones:
Los patrones de autorización password authentication nos permite forzar por fuerza bruta un nombre de usuario conocido para posibles contraseñas. Se pueden utilizar muchos métodos diferentes para adivinar las contraseñas de los usuarios. Para ello se especificanse suelen utilizar para mutar las contraseñas más utilizadas y, aterradoramente, corregirlas. Esto se debe a que los humanos somos vagos y no queremos recordar contraseñas complejas y complicadas. Por lo tanto, creamos contraseñas que podemos recordar fácilmente, y esto lleva a que, por ejemplo, se agreguen números o caracteres solo al final de la contraseña. Creyendo que la contraseña es segura, los patrones mencionados se utilizan para adivinar precisamente tales "ajustes" de estas contraseñas. Sin embargo, se pueden utilizar algunas instrucciones y guías de refuerzo para reforzar nuestros servidores SSH.
Enumeración del servicio
Una de las herramientas que podemos utilizar para tomar huellas dactilares del servidor SSH es ssh-audit . Comprueba la configuración del lado del cliente y del servidor y muestra información general y qué algoritmos de cifrado todavía utilizan el cliente y el servidor. Por supuesto, esto podría explotarse atacando al servidor o al cliente a un nivel críptico más adelante.
SSH Audit
Lo primero que podemos ver en las primeras líneas del resultado es el banner que revela la versión del servidor OpenSSH. Las versiones anteriores tenían algunas vulnerabilidades, como CVE-2020-14145 , que permitía al atacante la capacidad de realizar Man-In-The-Middle y atacar el intento de conexión inicial. El resultado detallado de la configuración de la conexión con el servidor OpenSSH a menudo también puede proporcionar información importante, como qué métodos de autenticación puede utilizar el servidor.
Cambiar método de autenticación
Para posibles ataques de fuerza bruta, podemos especificar el método de autenticación con la opción de cliente SSH PreferredAuthentications.
Incluso con este servicio obvio y seguro, recomendamos configurar nuestro propio servidor OpenSSH en nuestra VM, experimentar con él y familiarizarnos con las diferentes configuraciones y opciones.
Es posible que nos encontremos con varios banners para el servidor SSH durante nuestras pruebas de penetración. De forma predeterminada, los banners comienzan con la versión del protocolo que se puede aplicar y luego la versión del propio servidor. Por ejemplo, con SSH-1.99-OpenSSH_3.9p1, sabemos que podemos usar ambas versiones del protocolo SSH-1 y SSH-2, y estamos tratando con la versión 3.9p1 del servidor OpenSSH. Por otro lado, para un banner con SSH-2.0-OpenSSH_8.2p1, estamos ante una versión OpenSSH 8.2p1 que sólo acepta la versión del protocolo SSH-2.
Rsync
Rsync es una herramienta rápida y eficiente para copiar archivos de forma local y remota. Se puede utilizar para copiar archivos localmente en una máquina determinada y hacia/desde hosts remotos. Es muy versátil y conocido por su algoritmo de transferencia delta. Este algoritmo reduce la cantidad de datos transmitidos a través de la red cuando ya existe una versión del archivo en el host de destino. Para ello, envía solo las diferencias entre los archivos de origen y la versión anterior de los archivos que residen en el servidor de destino. A menudo se utiliza para copias de seguridad y duplicación. Encuentra archivos que deben transferirse observando los archivos que han cambiado de tamaño o la hora de la última modificación. De forma predeterminada, utiliza un puerto 873y se puede configurar para usar SSH para transferencias seguras de archivos al utilizar una conexión de servidor SSH establecida.
Esta guía cubre algunas de las formas en que se puede abusar de Rsync, en particular enumerando el contenido de una carpeta compartida en un servidor de destino y recuperando archivos. A veces esto se puede hacer sin autenticación. Otras veces necesitaremos credenciales. Si encuentra credenciales durante un pentest y ejecuta Rsync en un host interno (o externo), siempre vale la pena verificar la reutilización de la contraseña, ya que es posible que pueda extraer algunos archivos confidenciales que podrían usarse para obtener acceso remoto a el objetivo.
Hagamos un poco de enumeración rápida. Podemos ver que Rsync está en uso usando el protocolo 31.
Buscando Rsync
Probando servicios accesibles
A continuación podemos probar un poco el servicio para ver a qué podemos acceder.
Enumerar un recurso compartido abierto
En el resultado anterior, podemos ver algunos archivos interesantes que pueden valer la pena consultar para investigar más a fondo. También podemos ver que se puede acceder a un directorio que probablemente contenga claves SSH. Desde aquí, podríamos sincronizar todos los archivos con nuestro host de ataque con el comando rsync -av rsync://127.0.0.1/dev. Si Rsync está configurado para usar SSH para transferir archivos, podríamos modificar nuestros comandos para incluir la flag -e ssh, o -e "ssh -p2222"si se usa un puerto no estándar para SSH. Esta guía es útil para comprender la sintaxis para usar Rsync sobre SSH.
R-Services
Los R-Services son un conjunto de servicios alojados para permitir el acceso remoto o emitir comandos entre hosts Unix a través de TCP/IP. Desarrollados inicialmente por el Computer Systems Research Group ( CSRG) de la Universidad de California, Berkeley, r-services fueron el estándar de facto para el acceso remoto entre sistemas operativos Unix hasta que fueron reemplazados por los protocolos SSH y comandos Secure Shell ( ) debido a fallas de seguridad inherentes incorporadas. a ellos. Al igual que telnet, los R-Services transmiten información del cliente al servidor (y viceversa) a través de la red en un formato no cifrado, lo que permite a los atacantes interceptar el tráfico de la red (contraseñas, información de inicio de sesión, etc.) mediante la realización de operaciones man-in-. ataques del medio ( MITM).
Los R-services abarcan los puertos 512, 513y 514solo se puede acceder a ellos a través de un conjunto de programas conocidos como r-commands. Se utilizan con mayor frecuencia en sistemas operativos comerciales como Solaris, HP-UX y AIX. Aunque son menos comunes hoy en día, nos topamos con ellos de vez en cuando durante nuestras pruebas de penetración internas, por lo que vale la pena entender cómo abordarlos.
La suite R-commands consta de los siguientes programas:
rcp (
remote copy)rexec (
remote execution)rlogin (
remote login)rsh (
remote shell)rstat
ruptime
rwho (
remote who)
Cada comando tiene su funcionalidad prevista; sin embargo, solo cubriremos los más comúnmente abusados r-commands. La siguiente tabla proporcionará una descripción general rápida de los comandos de los que se abusa con más frecuencia, incluido el demonio de servicio con el que interactúan, a qué puerto y método de transporte se puede acceder y una breve descripción de cada uno.
El archivo /etc/hosts.equiv contiene una lista de hosts confiables y se utiliza para otorgar acceso a otros sistemas en la red. Cuando los usuarios de uno de estos hosts intentan acceder al sistema, se les concede acceso automáticamente sin necesidad de autenticación adicional.
/etc/hosts.equiv
Ahora que tenemos un conocimiento básico de r-commands, hagamos una enumeración rápida usando Nmap para determinar si todos los puertos necesarios están abiertos.
Escaneo en busca de R-Services
Control de acceso y relaciones de confianza
La principal preocupación de r-services, y una de las principales razones por SSHlas que se introdujo para reemplazarlo, son los problemas inherentes relacionados con el control de acceso a estos protocolos. Los servicios R se basan en información confiable enviada desde el cliente remoto a la máquina host en la que intentan autenticarse.
De forma predeterminada, estos servicios utilizan módulos de autenticación conectables (PAM) para la autenticación del usuario en un sistema remoto; sin embargo, también omiten esta autenticación mediante el uso de archivos /etc/hosts.equivy .rhostsen el sistema. Los archivos hosts.equivy .rhostscontienen una lista de hosts ( IPso Hostnames) y usuarios que se encuentran trustedjunto al host local cuando se realiza un intento de conexión mediante r-commands. Las entradas en cualquiera de los archivos pueden tener el siguiente aspecto:
Nota: El archivo hosts.equivse reconoce como la configuración global de todos los usuarios de un sistema, mientras que .rhostsproporciona una configuración por usuario.
Archivo .rhosts de muestra
Como podemos ver en este ejemplo, ambos archivos siguen la sintaxis específica de <username> <ip address>o <username> <hostname> . Además, el modificador + se puede utilizar dentro de estos archivos como comodín para especificar cualquier cosa. En este ejemplo, el modificador + permite que cualquier usuario externo acceda a los comandos r desde la cuenta htb-student de usuario a través del host con la dirección IP 10.0.17.10.
Las configuraciones incorrectas en cualquiera de estos archivos pueden permitir que un atacante se autentique como otro usuario sin credenciales, con el potencial de obtener la ejecución del código. Ahora que entendemos cómo podemos potencialmente abusar de las configuraciones erróneas en estos archivos, intentemos iniciar sesión en un host de destino usando rlogin.
Iniciar sesión usando Rlogin
Hemos iniciado sesión correctamente con la cuenta htb-student en el host remoto debido a configuraciones erróneas en el archivo .rhosts. Una vez que hayamos iniciado sesión correctamente, también podemos abusar del comando rwho para enumerar todas las sesiones interactivas en la red local enviando solicitudes al puerto UDP 513.
Listado de usuarios autenticados mediante Rwho
A partir de esta información, podemos ver que el usuario htb-studentestá actualmente autenticado en el host workstn01, mientras que el usuario root está autenticado en el host. web01 Podemos usar esto a nuestro favor al buscar posibles nombres de usuario para usar durante futuros ataques a hosts en la red. Sin embargo, el demonio rwho transmite periódicamente información sobre los usuarios que han iniciado sesión, por lo que podría resultar beneficioso observar el tráfico de la red.
Listado de usuarios autenticados que utilizan Rusers
Para proporcionar información adicional junto con rwho, podemos emitir el comando rusers. Esto nos brindará una cuenta más detallada de todos los usuarios que iniciaron sesión en la red, incluida información como el nombre de usuario, el nombre de host de la máquina a la que se accede, el TTY en el que el usuario inició sesión, la fecha y hora en que el usuario inició sesión, el cantidad de tiempo desde que el usuario escribió en el teclado y el host remoto desde el que inició sesión (si corresponde).
Como podemos ver, los servicios R se utilizan con menos frecuencia hoy en día debido a sus fallos de seguridad inherentes y a la disponibilidad de protocolos más seguros como SSH. Para ser un profesional completo de seguridad de la información, debemos tener un conocimiento amplio y profundo de muchos sistemas, aplicaciones, protocolos, etc. Por lo tanto, guarde este conocimiento sobre los servicios R porque nunca se sabe cuándo puede encontrarlos.
Reflexiones finales
Los servicios de gestión remota pueden proporcionarnos un tesoro de datos y, a menudo, se puede abusar de ellos para acceder sin autorización a través de credenciales débiles o predeterminadas o de la reutilización de contraseñas. Siempre debemos investigar estos servicios para obtener toda la información que podamos recopilar y no dejar piedra sin remover, especialmente cuando hemos compilado una lista de credenciales de otras partes de la red de destino.
Última actualización
