Linux RMP
En el mundo de las distribuciones de Linux, hay muchas maneras de gestionar los servidores de forma remota. Por ejemplo, imaginemos que estamos en una de muchas ubicaciones y uno de nuestros empleados, que acaba de ir a ver a un cliente en otra ciudad, necesita nuestra ayuda debido a un error que no puede resolver. Solucionar problemas de manera eficiente será difícil en la mayoría de los casos mediante una llamada telefónica, por lo que es beneficioso saber cómo iniciar sesión en el sistema remoto para gestionarlo.
Estas aplicaciones y servicios se pueden encontrar en casi todos los servidores de la red pública. Ahorra tiempo, ya que no necesitamos estar físicamente presentes en el servidor, y el entorno de trabajo sigue siendo el mismo. Por estas razones, estos protocolos y aplicaciones para la gestión de sistemas remotos son un objetivo interesante. Si la configuración es incorrecta, nosotros, como pentesters, podemos incluso ganar acceso rápidamente al sistema remoto. Por lo tanto, debemos familiarizarnos con los protocolos, servidores y aplicaciones más importantes para este propósito.
SSH
Secure Shell (SSH) permite que dos computadoras establezcan una conexión encriptada y directa 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 lo tanto, datos sensibles. El servidor SSH también se puede configurar para permitir conexiones solo desde clientes específicos. Una ventaja de SSH es que el protocolo funciona en todos los sistemas operativos comunes. Dado que es una aplicación originalmente de Unix, también está implementada de manera nativa en todas las distribuciones de Linux y macOS. SSH también se puede usar en Windows, siempre que instalemos un programa apropiado. El conocido OpenBSD SSH (OpenSSH) server en distribuciones de Linux es un fork de código abierto del servidor SSH original y comercial de SSH Communication Security. En consecuencia, existen dos protocolos en competencia: SSH-1 y SSH-2.
SSH-2, también conocido como SSH versión 2, es un protocolo más avanzado que SSH versión 1 en términos de 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 gestionar un host remoto. Esto se puede hacer a través de la línea de comandos o la interfaz gráfica. Además, también podemos usar el protocolo SSH para enviar comandos al sistema deseado, transferir archivos o hacer port forwarding. Por lo tanto, necesitamos conectarnos a él utilizando el protocolo SSH y autenticarnos en él. En total, OpenSSH tiene seis métodos de autenticación diferentes:
- Autenticación por contraseña
- Public-key authentication
- Host-based authentication
- Keyboard authentication
- Challenge-response authentication
- GSSAPI authentication
Echaremos un vistazo más de cerca y discutiremos uno de los métodos de autenticación más comúnmente utilizados. Además, podemos aprender más sobre los otros métodos de autenticación aquí, entre otros.
Public Key Authentication
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. Solo cuando el contacto se establece por primera vez hay riesgo de que un tercero se interponga entre los dos participantes y, por lo tanto, intercepte la conexión. Dado que el certificado en sí también está encriptado, no se puede imitar. Una vez que el cliente conoce el certificado correcto, nadie más puede fingir hacer contacto a través del servidor correspondiente.
Después de la autenticación del servidor, sin embargo, el cliente también debe demostrar al servidor que tiene autorización de acceso. Sin embargo, el servidor SSH ya posee el valor hash encriptado de la contraseña establecida para el usuario deseado. Como resultado, los usuarios tienen que ingresar la contraseña cada vez que inician sesión en otro servidor durante la misma sesión. Por esta razón, una opción alternativa para la autenticación del lado del cliente es el uso de un par de claves pública y privada.
La clave privada se crea individualmente para la propia computadora del usuario y se asegura 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 nuestra propia computadora 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, desencripta el problema con su propia clave privada, envía la solución de vuelta y, por lo tanto, 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, asegurando que ningún tercero que gane acceso físico a la máquina local pueda conectarse al servidor.
Default Configuration
El archivo sshd_config, responsable del servidor OpenSSH, tiene solo algunas de las configuraciones configuradas por defecto. Sin embargo, la configuración predeterminada incluye X11 forwarding, que contenía una vulnerabilidad de inyección de comandos en la versión 7.2p1 de OpenSSH en 2016. No obstante, no necesitamos una GUI para gestionar nuestros servidores.
Default Configuration
cat /etc/ssh/sshd_config | grep -v "#" | sed -r '/^\s*$/d'
Include /etc/ssh/sshd_config.d/*.conf
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
La mayoría de las configuraciones en este archivo de configuración están comentadas y requieren configuración manual.
Dangerous Settings
A pesar de que el protocolo SSH es uno de los más seguros disponibles hoy en día, algunas configuraciones incorrectas aún pueden hacer que el servidor SSH sea vulnerable a ataques fáciles de ejecutar. Echemos un vistazo a las siguientes configuraciones:
| Setting | Description |
|---|---|
PasswordAuthentication yes |
Permite la autenticación basada en contraseña. |
PermitEmptyPasswords yes |
Permite el uso de contraseñas vacías. |
PermitRootLogin yes |
Permite iniciar sesión como usuario root. |
Protocol 1 |
Usa una versión obsoleta de cifrado. |
X11Forwarding yes |
Permite X11 forwarding para aplicaciones GUI. |
AllowTcpForwarding yes |
Permite el reenvío de puertos TCP. |
PermitTunnel |
Permite el tunneling. |
DebianBanner yes |
Muestra un banner específico al iniciar sesión. |
Permitir la autenticación por contraseña nos permite realizar un ataque de fuerza bruta a un nombre de usuario conocido para posibles contraseñas. Se pueden usar muchos métodos diferentes para adivinar las contraseñas de los usuarios. Para este propósito, generalmente se usan patterns específicos para mutar las contraseñas más comúnmente usadas y, alarmantemente, adivinarlas correctamente. Esto se debe a que nosotros, los humanos, somos perezosos y no queremos recordar contraseñas complejas y complicadas. Por lo tanto, creamos contraseñas que podemos recordar fácilmente, y esto lleva al hecho de que, por ejemplo, solo se agregan números o caracteres al final de la contraseña. Creyendo que la contraseña es segura, se usan los patrones mencionados para adivinar precisamente tales "ajustes" de estas contraseñas. Sin embargo, se pueden utilizar algunas instrucciones y hardening guides para endurecer nuestros servidores SSH.
Footprinting the Service
Una de las herramientas que podemos usar para fingerprint el servidor SSH es ssh-audit. Revisa la configuración del lado del cliente y del servidor y muestra información general y qué algoritmos de cifrado todavía son utilizados por el cliente y el servidor. Por supuesto, esto podría ser explotado atacando al servidor o al cliente a nivel criptográfico más adelante.
SSH-Audit
git clone https://github.com/jtesta/ssh-audit.git && cd ssh-audit
./ssh-audit.py 10.129.14.132
# general
(gen) banner: SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.3
(gen) software: OpenSSH 8.2p1
(gen) compatibility: OpenSSH 7.4+, Dropbear SSH 2018.76+
(gen) compression: enabled (zlib@openssh.com)
# key exchange algorithms
(kex) curve25519-sha256 -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
(kex) curve25519-sha256@libssh.org -- [info] available since OpenSSH 6.5, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp256 -- [fail] using weak elliptic curves
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp384 -- [fail] using weak elliptic curves
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp521 -- [fail] using weak elliptic curves
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) diffie-hellman-group-exchange-sha256 (2048-bit) -- [info] available since OpenSSH 4.4
(kex) diffie-hellman-group16-sha512 -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group18-sha512 -- [info] available since OpenSSH 7.3
(kex) diffie-hellman-group14-sha256 -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
# host-key algorithms
(key) rsa-sha2-512 (3072-bit) -- [info] available since OpenSSH 7.2
(key) rsa-sha2-256 (3072-bit) -- [info] available since OpenSSH 7.2
(key) ssh-rsa (3072-bit) -- [fail] using weak hashing algorithm
`- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28
`- [info] a future deprecation notice has been issued in OpenSSH 8.2: https://www.openssh.com/txt/release-8.2
(key) ecdsa-sha2-nistp256 -- [fail] using weak elliptic curves
`- [warn] using weak random number generator could reveal the key
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(key) ssh-ed25519 -- [info] available since OpenSSH 6.5
...SNIP...
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ían al atacante la capacidad de 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 también puede proporcionar información importante, como qué métodos de autenticación puede usar el servidor.
Change Authentication Method
ssh -v cry0l1t3@10.129.14.132
OpenSSH_8.2p1 Ubuntu-4ubuntu0.3, OpenSSL 1.1.1f 31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
...SNIP...
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Para ataques de fuerza bruta potenciales, podemos especificar el método de autenticación con la opción del cliente SSH PreferredAuthentications.
ssh -v cry0l1t3@10.129.14.132 -o PreferredAuthentications=password
OpenSSH_8.2p1 Ubuntu-4ubuntu0.3, OpenSSL 1.1.1f 31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
...SNIP...
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
cry0l1t3@10.129.14.132's password:
Incluso con este servicio obvio y seguro, recomendamos configurar nuestro propio servidor OpenSSH en nuestra VM, experimentando con él y familiarizándonos con las diferentes configuraciones y opciones.
Podemos encontrar 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 de 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 tratando con una versión 8.2p1 de OpenSSH que solo acepta la versión del protocolo SSH-2.
Rsync
Rsync es una herramienta rápida y eficiente para copiar archivos localmente y remotamente. Puede ser utilizada para copiar archivos localmente en una máquina determinada y hacia/desde hosts remotos. Es altamente versátil y conocida por su algoritmo de transferencia delta. Este algoritmo reduce la cantidad de datos transmitidos por la red cuando ya existe una versión del archivo en el host de destino. Lo hace enviando solo las diferencias entre los archivos fuente y la versión anterior de los archivos que residen en el servidor de destino. A menudo se utiliza para copias de seguridad y mirroring. Encuentra archivos que necesitan ser transferidos mirando los archivos que han cambiado en tamaño o la última vez que fueron modificados. Por defecto, usa el puerto 873 y se puede configurar para usar SSH para transferencias de archivos seguras aprovechando una conexión de servidor SSH establecida.
Esta guía cubre algunas de las formas en que Rsync puede ser abusado, sobre todo enumerando el contenido de una carpeta compartida en un servidor objetivo y recuperando archivos. Esto a veces se puede hacer sin autenticación. Otras veces necesitaremos credenciales. Si encontramos credenciales durante una prueba de penetración y nos encontramos con Rsync en un host interno (o externo), siempre vale la pena verificar la reutilización de contraseñas, ya que podríamos descargar algunos archivos sensibles que podrían ser utilizados para obtener acceso remoto al objetivo.
Hagamos un poco de footprinting rápido. Podemos ver que Rsync está en uso utilizando el protocolo 31.
Scanning for Rsync
sudo nmap -sV -p 873 127.0.0.1
Starting Nmap 7.92 ( https://nmap.org ) at 2022-09-19 09:31 EDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0058s latency).
PORT STATE SERVICE VERSION
873/tcp open rsync (protocol version 31)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1.13 seconds
Probing for Accessible Shares
A continuación, podemos sondear el servicio un poco para ver a qué podemos acceder.
nc -nv 127.0.0.1 873
(UNKNOWN) [127.0.0.1] 873 (rsync) open
@RSYNCD: 31.0
@RSYNCD: 31.0
#list
dev Dev Tools
@RSYNCD: EXIT
Enumerating an Open Share
Aquí podemos ver un share llamado dev, y podemos enumerarlo más a fondo.
rsync -av --list-only rsync://127.0.0.1/dev
receiving incremental file list
drwxr-xr-x 48 2022/09/19 09:43:10 .
-rw-r--r-- 0 2022/09/19 09:34:50 build.sh
-rw-r--r-- 0 2022/09/19 09:36:02 secrets.yaml
drwx------ 54 2022/09/19 09:43:10 .ssh
sent 25 bytes received 221 bytes 492.00 bytes/sec
total size is 0 speedup is 0.00
En el resultado anterior, podemos ver algunos archivos interesantes que podrían valer la pena descargar para investigar más. También podemos ver que un directorio que probablemente contiene claves SSH es accesible. 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 está utilizando un puerto no estándar para SSH. Esta guía es útil para entender la sintaxis para usar Rsync sobre SSH.
R-Services
R-Services son una suite de servicios alojados para habilitar el acceso remoto o emitir comandos entre hosts Unix a través de TCP/IP. Inicialmente desarrollados por el Computer Systems Research Group (CSRG) en la Universidad de California, Berkeley, r-services eran el estándar de facto para el acceso remoto entre sistemas operativos Unix hasta que fueron reemplazados por los protocolos y comandos de Secure Shell (SSH) debido a fallos de seguridad inherentes incorporados en ellos. Al igual que telnet, r-services transmiten información del cliente al servidor (y viceversa) a través de la red en un formato no encriptado, lo que permite a los atacantes interceptar el tráfico de red (contraseñas, información de inicio de sesión, etc.) realizando ataques de man-in-the-middle (MITM).
R-services abarcan los puertos 512, 513 y 514 y solo son accesibles a través de una suite de programas conocidos como r-commands. Son más comúnmente utilizados por sistemas operativos comerciales como Solaris, HP-UX y AIX. Aunque son menos comunes hoy en día, los encontramos 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 consiste en 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 r-commands más comúnmente abusados. La tabla a continuación proporcionará una visión general rápida de los comandos más frecuentemente abusados, incluyendo el daemon de servicio con el que interactúan, sobre qué puerto y método de transporte se pueden acceder, y una breve descripción de cada uno.
| Command | Service Daemon | Port | Transport Protocol | Description |
|---|---|---|---|---|
rcp |
rshd |
514 | TCP | Copia un archivo o directorio bidireccionalmente desde el sistema local al sistema remoto (o viceversa) o de un sistema remoto a otro. Funciona como el comando cp en Linux pero proporciona sin advertencia al usuario para sobrescribir archivos existentes en un sistema. |
rsh |
rshd |
514 | TCP | Abre un shell en una máquina remota sin un procedimiento de inicio de sesión. Se basa en las entradas confiables en los archivos /etc/hosts.equiv y .rhosts para la validación. |
rexec |
rexecd |
512 | TCP | Permite a un usuario ejecutar comandos shell en una máquina remota. Requiere autenticación mediante el uso de un username y password a través de un socket de red no encriptado. La autenticación se anula mediante las entradas confiables en los archivos /etc/hosts.equiv y .rhosts. |
rlogin |
rlogind |
513 | TCP | Permite a un usuario iniciar sesión en un host remoto a través de la red. Funciona de manera similar a telnet pero solo puede conectarse a hosts similares a Unix. La autenticación se anula mediante las entradas confiables en los archivos /etc/hosts.equiv y .rhosts. |
El archivo /etc/hosts.equiv contiene una lista de hosts confiables y se usa para otorgar acceso a otros sistemas en la red. Cuando los usuarios en uno de estos hosts intentan acceder al sistema, se les concede automáticamente acceso sin más autenticación.
/etc/hosts.equiv
cat /etc/hosts.equiv
# <hostname> <local username>
pwnbox cry0l1t3
Ahora que tenemos una comprensión básica de r-commands, hagamos un poco de footprinting rápido usando Nmap para determinar si todos los puertos necesarios están abiertos.
Scanning for R-Services
sudo nmap -sV -p 512,513,514 10.0.17.2
Starting Nmap 7.80 ( https://nmap.org ) at 2022-12-02 15:02 EST
Nmap scan report for 10.0.17.2
Host is up (0.11s latency).
PORT STATE SERVICE VERSION
512/tcp open exec?
513/tcp open login?
514/tcp open tcpwrapped
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 145.54 seconds
Access Control & Trusted Relationships
La principal preocupación por r-services, y una de las principales razones por las que se introdujo SSH para reemplazarlo, son los problemas inherentes relacionados con el control de acceso para estos protocolos. R-services se basan en la información confiable enviada desde el cliente remoto a la máquina host a la que intentan autenticarse. Por defecto, estos servicios utilizan Pluggable Authentication Modules (PAM) para la autenticación de usuarios en un sistema remoto; sin embargo, también omiten esta autenticación mediante el uso de los archivos /etc/hosts.equiv y .rhosts en el sistema. Los archivos hosts.equiv y .rhosts contienen una lista de hosts (IPs o Hostnames) y usuarios que son confiables por el host local cuando se realiza un intento de conexión utilizando r-commands. Las entradas en cualquiera de los archivos pueden aparecer como lo siguiente:
Nota: El archivo hosts.equiv se reconoce como la configuración global con respecto a todos los usuarios en un sistema, mientras que .rhosts proporciona una configuración por usuario.
Sample .rhosts File
cat .rhosts
htb-student 10.0.17.5
+ 10.0.17.10
+ +
Como podemos ver en este ejemplo, ambos archivos siguen la sintaxis específica de <username> <ip address> o <username> <hostname> pares. Además, el modificador + se puede usar dentro de estos archivos como un wildcard para especificar cualquier cosa. En este ejemplo, el modificador + permite a cualquier usuario externo acceder a r-commands desde la cuenta de usuario htb-student 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 ejecución de código. Ahora que entendemos cómo podemos potencialmente abusar de configuraciones incorrectas en estos archivos, intentemos iniciar sesión en un host objetivo utilizando rlogin.
Logging in Using Rlogin
rlogin 10.0.17.2 -l htb-student
Last login: Fri Dec 2 16:11:21 from localhost
[htb-student@localhost ~]$
Hemos iniciado sesión correctamente bajo la cuenta htb-student en el host remoto debido a las configuraciones incorrectas en el archivo .rhosts. Una vez que iniciamos sesión correctamente, también podemos abusar del comando rwho para listar todas las sesiones interactivas en la red local enviando solicitudes al puerto UDP 513.
Listing Authenticated Users Using Rwho
rwho
root web01:pts/0 Dec 2 21:34
htb-student workstn01:tty1 Dec 2 19:57 2:25
A partir de esta información, podemos ver que el usuario htb-student está autenticado actualmente en el host workstn01, mientras que el usuario root está autenticado en el host web01. Podemos usar esto a nuestro favor cuando estemos buscando posibles nombres de usuario para usar durante futuros ataques a hosts en la red. Sin embargo, el daemon rwho transmite periódicamente información sobre los usuarios que han iniciado sesión, por lo que podría ser beneficioso monitorear el tráfico de red.
Listing Authenticated Users Using Rusers
Para proporcionar información adicional junto con rwho, podemos emitir el comando rusers. Esto nos dará una cuenta más detallada de todos los usuarios que han iniciado sesión en la red, incluyendo información como el nombre de usuario, el nombre del host de la máquina a la que se ha accedido, TTY en la que el usuario ha iniciado sesión, la fecha y hora en que el usuario inició sesión, la cantidad de tiempo desde que el usuario escribió en el teclado y el host remoto desde el cual iniciaron sesión (si es aplicable).
rusers -al 10.0.17.5
htb-student 10.0.17.5:console Dec 2 19:57 2:25
Como podemos ver, los R-services son menos utilizados hoy en día debido a sus fallos de seguridad inherentes y la disponibilidad de protocolos más seguros como SSH. Para ser un profesional de seguridad de la información bien redondeado, debemos tener un conocimiento amplio y profundo de muchos sistemas, aplicaciones, protocolos, etc. Así que guarda este conocimiento sobre los R-services porque nunca se sabe cuándo podrías encontrarlos.
Final Thoughts
Los servicios de gestión remota pueden proporcionarnos un tesoro de datos y a menudo ser abusados para el acceso no autorizado a través de credenciales débiles/predeterminadas o la reutilización de contraseñas. Siempre debemos sondear estos servicios para obtener tanta información como sea posible y no dejar ninguna piedra sin remover, especialmente cuando hemos compilado una lista de credenciales de otras partes de la red objetivo.