Protocolos de administración remota de Linux
Last updated
Last updated
En el mundo de las distribuciones Linux, existen muchas maneras de administrar servidores de forma remota. Por ejemplo, imaginemos que estamos en una de varias ubicaciones y uno de nuestros empleados, que acaba de visitar a un cliente en otra ciudad, necesita nuestra ayuda debido a un error que no puede resolver. En la mayoría de los casos, solucionar problemas de forma eficiente parecerá difícil por teléfono, por lo que es beneficioso saber cómo acceder al sistema remoto para administrarlo.
Estas aplicaciones y servicios se encuentran en casi todos los servidores de la red pública. Esto ahorra tiempo, ya que no es necesario estar físicamente en el servidor y el entorno de trabajo se mantiene igual. Estos protocolos y aplicaciones para la gestión remota de sistemas son un objetivo prometedor por estas razones. Si la configuración es incorrecta, nosotros, como expertos en pruebas de penetración, podemos incluso acceder rápidamente al sistema remoto. Por lo tanto, es importante familiarizarse con los protocolos, servidores y aplicaciones más importantes para este fin.
( SSH) permite que dos ordenadores establezcan una conexión cifrada 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 confidenciales. El servidor SSH también puede configurarse para permitir conexiones únicamente de clientes específicos. Una ventaja de SSH es que el protocolo funciona en todos los sistemas operativos comunes. Al ser originalmente una aplicación Unix, también se implementa de forma nativa en todas las distribuciones de Linux y macOS. SSH también se puede usar en Windows, siempre que se instale un programa adecuado. El conocido servidor ( OpenSSH) en distribuciones de Linux es una bifurcación de código abierto del SSHservidor original y comercial de SSH Communication Security. Por consiguiente, 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 cuanto a cifrado, velocidad, estabilidad y seguridad. Por ejemplo, SSH-1es vulnerable a MITMataques, a diferencia de SSH-2.
Imaginemos que queremos administrar un host remoto. Esto se puede hacer mediante la línea de comandos o la interfaz gráfica de usuario. Además, también podemos usar el protocolo SSH para enviar comandos al sistema deseado, transferir archivos o realizar redireccionamiento de puertos. Por lo tanto, necesitamos conectarnos a él mediante el protocolo SSH y autenticarnos. En total, OpenSSH ofrece seis métodos de autenticación diferentes:
Autenticación de contraseña
Autenticación de clave pública
Autenticación basada en host
Autenticación del teclado
Autenticación de desafío-respuesta
Autenticación GSSAPI
Analizaremos con más detalle uno de los métodos de autenticación más utilizados. Además, podemos aprender más sobre otros métodos de autenticación, entre otros.
En un primer paso, el servidor y el cliente SSH se autentican mutuamente. El servidor envía un certificado al cliente para verificar que es el servidor correcto. Solo al establecerse el contacto existe el riesgo de que un tercero se interponga entre ambos participantes e intercepte la conexión. Dado que el certificado también está cifrado, es infalible. Una vez que el cliente conoce el certificado correcto, nadie más puede intentar contactar a través del servidor correspondiente.
Tras la autenticación del servidor, el cliente también debe demostrar al servidor que tiene autorización de acceso. No obstante, el servidor SSH ya posee el valor hash cifrado de la contraseña establecida para el usuario deseado. Por lo tanto, los usuarios deben introducir la contraseña cada vez que inician sesión en otro servidor. Por este motivo, una 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 el ordenador del usuario y se protege con una frase de contraseña más larga que una contraseña convencional. La clave privada se almacena exclusivamente en nuestro ordenador y siempre permanece secreta. Si queremos establecer una conexión SSH, primero introducimos la frase de contraseña y, de este modo, accedemos 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 la envía. El cliente, a su vez, descifra el problema con su propia clave privada, envía la solución e informa al servidor de que puede establecer una conexión legítima. Durante una sesión, los usuarios solo necesitan introducir la contraseña una vez para conectarse a cualquier número de servidores. Al finalizar la sesión, los usuarios cierran sesión en sus equipos locales, lo que garantiza que ningún tercero que tenga acceso físico al equipo local pueda conectarse al servidor.
A pesar de que el protocolo SSH es uno de los más seguros disponibles actualmente, algunas configuraciones incorrectas pueden hacer que el servidor SSH sea vulnerable a ataques fáciles de ejecutar. Analicemos las siguientes configuraciones:
Configuración
Descripción
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
Utiliza una versión obsoleta de cifrado.
X11Forwarding yes
Permite el reenvío X11 para aplicaciones GUI.
AllowTcpForwarding yes
Permite el reenvío de puertos TCP.
PermitTunnel
Permite la tunelización.
DebianBanner yes
Muestra un banner específico al iniciar sesió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.
Durante nuestras pruebas de penetración, podemos encontrar varios banners para el servidor SSH. Por defecto, los banners empiezan con la versión del protocolo aplicable y luego con la versión del propio servidor. Por ejemplo, con [nombre del servidor SSH-1.99-OpenSSH_3.9p1], sabemos que podemos usar las versiones de protocolo SSH-1 y SSH-2, y estamos trabajando con la versión 3.9p1 del servidor OpenSSH. Por otro lado, con un banner con [nombre del servidor] SSH-2.0-OpenSSH_8.2p1, estamos trabajando con la versión 8.2p1 de OpenSSH, que solo acepta la versión SSH-2.
Hagamos un breve análisis de huellas. Vemos que Rsync está en uso mediante el protocolo 31.
A continuación podemos probar un poco el servicio para ver a qué podemos acceder.
Los R-Services son un conjunto de servicios alojados para permitir el acceso remoto o la emisión de comandos entre hosts Unix a través de TCP/IP. Inicialmente desarrollados por el Grupo de Investigación de Sistemas Informáticos ( CSRG) de la Universidad de California, Berkeley, r-servicesfueron el estándar de facto para el acceso remoto entre sistemas operativos Unix hasta que fueron reemplazados por los SSHprotocolos y comandos Secure Shell ( ) debido a sus vulnerabilidades de seguridad inherentes. Al igual que telnet, los R-Services transmiten información del cliente al servidor (y viceversa) a través de la red sin cifrar, lo que permite a los atacantes interceptar el tráfico de red (contraseñas, información de inicio de sesión, etc.) mediante ataques de intermediario ( MITM).
R-servicesAbarcan los puertos 512, 513, y 514y solo son accesibles mediante un conjunto de programas conocido 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, los encontramos ocasionalmente durante nuestras pruebas de penetración internas, por lo que conviene comprender cómo abordarlos.
rcp ( remote copy)
rexec ( remote execution)
rlogin ( remote login)
rsh ( remote shell)
rstat
tiempo de interrupción
rwho ( remote who)
Cada comando tiene su funcionalidad; sin embargo, solo cubriremos los más utilizados r-commands. La siguiente tabla ofrece un resumen rápido de los comandos más utilizados, incluyendo el daemon de servicio con el que interactúan, el puerto y el método de transporte a través del cual se puede acceder, y una breve descripción de cada uno.
Dominio
Demonio de servicio
Puerto
Protocolo de transporte
Descripción
rcp
rshd
514
TCP
Copiar un archivo o directorio bidireccionalmente del sistema local al sistema remoto (o viceversa) o de un sistema remoto a otro. Funciona como el cpcomando en Linux, pero proporciona no warning to the user for overwriting existing files on a system.
rsh
rshd
514
TCP
Abre un shell en una máquina remota sin iniciar sesión. La validación se basa en las entradas de confianza de los archivos /etc/hosts.equivy ..rhosts
rexec
rexecd
512
TCP
Permite al usuario ejecutar comandos de shell en una máquina remota. Requiere autenticación mediante usernameun passwordsocket de red no cifrado. La autenticación se invalida mediante las entradas de confianza en los archivos /etc/hosts.equivy .rhosts.
rlogin
rlogind
513
TCP
Permite a un usuario iniciar sesión en un host remoto a través de la red. Funciona de forma similar, telnetpero solo se puede conectar a hosts tipo Unix. La autenticación se invalida mediante las entradas de confianza en los archivos /etc/hosts.equivy .rhosts.
El archivo /etc/hosts.equiv contiene una lista de hosts de confianza y se utiliza para otorgar acceso a otros sistemas de 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.
Ahora que tenemos un conocimiento básico de r-commands, hagamos un seguimiento rápido utilizando Nmappara determinar si todos los puertos necesarios están abiertos.
Nota: El hosts.equivarchivo se reconoce como la configuración global con respecto a todos los usuarios de un sistema, mientras que .rhostsproporciona una configuración por usuario.
Como podemos ver en este ejemplo, ambos archivos siguen la sintaxis específica de los pares <username> <ip address>`or` <username> <hostname>. Además, el +modificador puede usarse dentro de estos archivos como comodín para especificar cualquier cosa. En este ejemplo, el +modificador permite a cualquier usuario externo acceder a los comandos `r` desde la htb-studentcuenta 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 ejecutar código. Ahora que comprendemos cómo podemos abusar de las configuraciones incorrectas en estos archivos, intentemos iniciar sesión en un host objetivo usando rlogin.
Hemos iniciado sesión correctamente con la htb-studentcuenta en el host remoto debido a las configuraciones incorrectas en el .rhostsarchivo. Una vez iniciada la sesión, también podemos abusar del rwhocomando para listar todas las sesiones interactivas en la red local enviando solicitudes al puerto UDP 513.
A partir de esta información, podemos ver que el htb-studentusuario está actualmente autenticado en el workstn01host, mientras que el rootusuario está autenticado en el web01host. Podemos aprovechar esto al identificar posibles nombres de usuario para futuros ataques a hosts en la red. Sin embargo, el rwhodemonio difunde periódicamente información sobre los usuarios conectados, por lo que podría ser útil supervisar el tráfico de red.
Para proporcionar información adicional junto con [nombre de usuario] rwho, podemos ejecutar el ruserscomando. Esto nos proporcionará un registro más detallado de todos los usuarios conectados a la red, incluyendo información como el nombre de usuario, el nombre de host de la máquina a la que se accede, el TTY al que el usuario ha iniciado sesión, la fecha y hora de inicio de sesión, el tiempo transcurrido desde que el usuario escribió y el host remoto desde el que inició sesión (si corresponde).
Como podemos ver, los servicios R se usan con menos frecuencia hoy en día debido a sus vulnerabilidades de seguridad inherentes y a la disponibilidad de protocolos más seguros como SSH. Para ser un profesional integral en seguridad de la información, es necesario tener un conocimiento amplio y profundo de diversos sistemas, aplicaciones, protocolos, etc. Por lo tanto, guarde este conocimiento sobre los servicios R, ya que nunca se sabe cuándo puede encontrarse con ellos.
Permitir la autenticación de contraseñas nos permite forzar la búsqueda de posibles contraseñas en un nombre de usuario conocido. Existen diversos métodos para adivinar las contraseñas de los usuarios. Para ello, patternsse suelen emplear métodos específicos para mutar las contraseñas más comunes y, curiosamente, corregirlas. Esto se debe a que los humanos somos perezosos y no queremos recordar contraseñas complejas. Por lo tanto, creamos contraseñas fáciles de recordar, lo que lleva a que, por ejemplo, solo se añadan números o caracteres al final. Creyendo que la contraseña es segura, utilizamos los patrones mencionados para adivinar con precisión dichos ajustes. Sin embargo, existen algunas instrucciones y
Una de las herramientas que podemos usar para identificar el servidor SSH es . Esta herramienta verifica la configuración del cliente y del servidor, y muestra información general, así como los algoritmos de cifrado que aún utilizan el cliente y el servidor. Por supuesto, esto podría explotarse posteriormente atacando el servidor o el cliente a nivel críptico.
Lo primero que vemos en las primeras líneas del resultado es el banner que revela la versión del servidor OpenSSH. Las versiones anteriores presentaban vulnerabilidades, como , que permitían al atacante realizar una intervención de intermediario (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 suele proporcionar información importante, como los métodos de autenticación que puede utilizar el servidor.
es una herramienta rápida y eficiente para copiar archivos local y remotamente. Permite copiar archivos localmente en una máquina y desde/hacia hosts remotos. Es muy versátil y reconocido 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. Esto se logra enviando únicamente las diferencias entre los archivos de origen y la versión anterior que reside en el servidor de destino. Se utiliza a menudo para copias de seguridad y duplicación. Encuentra los archivos que deben transferirse examinando los archivos que han cambiado de tamaño o la fecha de su última modificación. Por defecto, utiliza el puerto 873y puede configurarse para usar SSH para transferencias seguras de archivos, apoyándose en una conexión de servidor SSH establecida.
Esta explica algunas de las formas en que se puede abusar de Rsync, especialmente al listar el contenido de una carpeta compartida en un servidor objetivo y recuperar archivos. Esto a veces puede hacerse sin autenticación. En otras ocasiones, necesitaremos credenciales. Si encuentra credenciales durante una prueba de penetración y se encuentra con Rsync en un host interno (o externo), siempre conviene comprobar si se reutilizan las contraseñas, ya que podría extraer archivos confidenciales que podrían utilizarse para obtener acceso remoto al objetivo.
En el resultado anterior, podemos ver algunos archivos interesantes que merece la pena descargar 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 -e sshbandera, o -e "ssh -p2222"si se usa un puerto no estándar para SSH. Esta es útil para comprender la sintaxis para usar Rsync sobre SSH.
La suite consta de los siguientes programas:
La principal preocupación de r-services, y una de las principales razones por las que SSHse introdujo para reemplazarlo, son los problemas inherentes al control de acceso de estos protocolos. Los servicios R se basan en información confiable enviada desde el cliente remoto al equipo host en el que intentan autenticarse. De forma predeterminada, estos servicios utilizan para la autenticación de usuarios en un sistema remoto; sin embargo, también omiten esta autenticación mediante los archivos /etc/hosts.equivy .rhostsdel sistema. Los archivos hosts.equivy .rhostscontienen una lista de hosts ( IPso Hostnames) y usuarios que están trustedjunto al host local cuando se intenta conectar mediante r-commands. Las entradas de cualquiera de los archivos pueden tener un aspecto similar al siguiente: