BlogWonderHowTo

Cómo: usar el reenvío de puertos locales SSH para pivotar en redes restringidas

SSH es una herramienta poderosa con más usos que simplemente iniciar sesión en un servidor. Este protocolo, que significa Secure Shell, proporciona reenvío X11, reenvío de puertos, transferencia segura de archivos y más. El uso del reenvío de puertos SSH en un host comprometido con acceso a una red restringida puede permitir que un atacante acceda a hosts dentro de la red restringida o pivote en la red.

En este artículo, veremos una de las opciones de reenvío de puertos SSH, el reenvío de puertos locales. Dado que esto puede ser algo confuso, primero me gustaría hablar un poco sobre la idea del reenvío de puertos.

Por qué es importante el reenvío de puertos

Cuando pensamos en el reenvío de puertos, generalmente lo pensamos en términos de un enrutador. Con una configuración de Internet doméstica típica, el enrutador está conectado a la WAN (red de área amplia) y tendrá una dirección IP asignada por el ISP (proveedor de servicios de Internet). En el otro lado del enrutador, tiene su LAN (red de área local). Generalmente, el enrutador asigna direcciones IP a los hosts dentro de la LAN.

En la mayoría de las configuraciones domésticas, el enrutador también actúa como un cortafuegos, lo que permite TCP conexiones y matando conexiones entrantes. Si desea acceder a un servicio en una máquina dentro de su red local, tendrá que configurar el enrutador para reenviar las conexiones en ese puerto a su máquina. Esto significa que la totalidad de Internet tendría acceso a ese servicio en su red interna (o local). El enrutador tomará el tráfico entrante destinado a su servicio y lo reenviará directamente a su máquina.

Ahora, ampliemos esto un poco. Digamos que la red es un poco más grande. Podríamos tener una red Wi-Fi para que la use el público y otra red para que la use el personal. Todos los hosts estarían conectados a una puerta de enlace y segmentados por la red. Como en el ejemplo de nuestro hogar, tenemos una conexión WAN, excepto que esta vez tenemos dos LAN. El enrutador evita que el tráfico de la red pública acceda a la red del personal.

Cuando el reenvío de puertos SSH es útil

Si tiene el control administrativo del enrutador, puede configurarlo para que reenvíe el tráfico a la red del personal. Pero, ¿y si no tienes control administrativo? Tal vez tenga una cuenta de usuario de bajo nivel y pueda SSH, pero no puede acceder al panel de administración y no puede modificar ninguna de las configuraciones.

Aquí es donde entra en juego el reenvío de puertos SSH; podemos usarlo para reenviar nuestro tráfico a una red a la que normalmente no podríamos acceder, pivotando así hacia la red. Esto no solo funciona en enrutadores, funciona en cualquier nodo con SSH habilitado y acceso a dos o más redes internas.

Echemos un vistazo a esto en acción

En un escenario, estamos conectados a un público red perimetral (zona desmilitarizada o DMZ) en una universidad local. A través de la enumeración, hemos descubierto que el firewall ejecuta SSH con credenciales extremadamente débiles. Venimos de la DMZ y nuestro objetivo es la intranet. Lo único que se interpone en nuestro camino es el firewall, al que podemos iniciar sesión a través de SSH, pero nuestra cuenta capturada no tiene los privilegios suficientes para cambiar ninguna configuración.

El firewall protege la intranet (los hosts del personal de la universidad, el objetivo) del tráfico malicioso externo, pero permite que ambas redes accedan a Internet. No podemos conectarnos a los hosts en la LAN desde la DMZ, y basándonos en la facilidad de acceso al firewall, sospecho que los hosts en la LAN son increíblemente suaves. Las credenciales débiles combinadas con una gran cantidad de administradores que no tratan sus redes internas como hostiles significa que la seguridad en los hosts dentro de la LAN debería ser casi nula.

Imagen de Pbroks13 /Wikimedia Commons

Dado que es una red de personal interna, probablemente contenga o tenga acceso a bastante información confidencial. Si estamos realizando una prueba de penetración como un sombrero blanco, queremos poder poner esa información confidencial en un informe. Si somos sombreros negros o grises, podríamos estar buscando exfiltrar, cambiar o eliminar esos datos. La pregunta es ¿cómo accedemos?

Para acceder a la red interna, tendremos que complicarnos y entrar en ella, ya que no podemos conectarnos directamente a ella. Aquí es donde el reenvío de puertos SSH resulta útil.

Paso 1: la configuración

En esta situación, tenemos tres máquinas: nuestra máquina atacante, el firewall y un host dentro de la red interna. En un compromiso real, generalmente habrá más de una máquina en la red interna, pero para fines de aprendizaje, todo lo que necesitamos es una máquina.

Mi máquina atacante está en la red 192.168.1.0/24, que representa la red DMZ. Se puede acceder al cortafuegos como puerta de enlace desde la DMZ en la misma red. También es accesible como puerta de enlace desde la red interna, que se encuentra en el rango 192.168.56.0/24. Estas direcciones se representan mediante CIDR notación.

Nuestra red.

El objetivo aquí es poder descubrir y atacar hosts dentro de la red interna desde la red DMZ. Dado que no podemos simplemente conectarnos directamente a un host dentro de la red interna, usaremos el servicio SSH del firewall DMZ para redirigir nuestro tráfico a la red interna.

Muchos principiantes no conocen el conjunto completo de funciones de SSH. Sin un pivote en la red interna, un atacante dependería totalmente del conjunto de herramientas contenido en el firewall comprometido. Lo que probablemente sea extremadamente limitado. A veces obtendrás Nmap si tienes suerte. Un ataque podría llevarse a cabo de esta manera, pero es mucho más fácil trabajar con un conjunto de herramientas grande como el que se incluye en Kali Linux. Herramientas como Metasploit realmente pueden facilitar las cosas.

Para simular esta configuración, configuré una máquina virtual dentro del host comprometido con un adaptador de solo host. Esto hace que la víctima no sea enrutable por el tráfico en mi red DMZ. Si desea probar esto en casa, simplemente cree una máquina virtual Linux con SSH habilitado en VirtualBox y configure el adaptador de red para solo host. El sistema operativo del host deberá tener SSH habilitado y necesitará otra máquina para acceder al servicio SSH del sistema operativo del host.

Cuando toda la configuración esté hecha, deberíamos tener una configuración que se ve así:

¿Qué sucede cuando la máquina atacante intenta hacer ping a la máquina invitada? No podemos enrutar el tráfico a la máquina víctima, pero podemos acceder a la máquina host a través de SSH, y eso es todo lo que necesitamos.

Aquí, vemos que el host atacante no puede enrutar a la red vboxnet0.

Paso 2: recopilación de información

Antes de que pueda pivotar correctamente en la red, probablemente sea una buena idea echar un vistazo a lo que tengo acceso a través del firewall. Abro una terminal e inicio sesión con SSH escribiendo lo siguiente, reemplazando victima maquina con la dirección IP de la computadora víctima a la que tenemos acceso.

usuario ssh @ victimmachine

No publiqué el resultado completo de ifconfig aquí ya que mi máquina tiene bastantes interfaces y el resultado completo sería confuso. Desde que configuré estas redes, conozco la interfaz a la que nos dirigimos. Si se tratara de una prueba de penetración real, parte de la enumeración posterior de hosts es recopilar interfaces conectadas, por si acaso hay un pivote disponible allí. Si hay varias interfaces de red conectadas, debería poder cambiar a cualquiera de esas redes.

Paso 3: reenvío de puertos locales

Usando nuestra conexión SSH al firewall, se recomienda hacer un poco de reconocimiento de red. Querrá descubrir qué hosts están activos dentro de la red interna. Si tiene suerte, Nmap se instalará en el firewall comprometido; de lo contrario, es posible que deba recurrir a un enfoque manual. El enfoque manual sería escribir un script bash de barrido de ping (que no detectará máquinas con ping bloqueado). Para este ejemplo, solo hay una máquina ejecutándose en la red y el puerto 80 (HTTP) está abierto.

Las aplicaciones web suelen ser un excelente vector de ataque. Dependiendo del propietario del proceso, una aplicación web podría devolver un shell de privilegios bajos hasta un shell de administración. Excepto que tengo información limitada. Sé que hay un servidor web ejecutándose en el host de la red interna, pero no sé qué es.

Para obtener más información sobre esta aplicación web, configuraré un puerto local hacia la aplicación usando el siguiente comando.

ssh -L 8080: internalTarget: 80 usuario @ comprometisedMachine

El -L La opción especifica que las conexiones al puerto TCP dado en el host local se reenviarán al host y al puerto dados en el lado remoto. Esto nos permite acceder a la red interna a través del firewall comprometido.

En nuestro caso. la red interna es cualquier cosa detrás de la interfaz vboxnet0. Más técnicamente, este comando crea un túnel SSH usando su puerto local 8080 para conectarse a la máquina de destino interna a través del firewall. SSH escuchará en el puerto localhost 8080 para cualquier conexión. Cuando recibe una conexión, tuneliza los datos a un servidor SSH, en este caso, nuestro firewall comprometido. El firewall comprometido luego se conecta al servidor de destino y al puerto devolviendo los datos a través de nuestro túnel SSH.

Al ejecutar este comando, obtiene una conexión SSH interactiva estándar al firewall, así como un reenvío de puertos. Si no desea el shell, puede cambiar el argumento en su comando a -NTL. El norte El argumento le dice a SSH que no ejecute un comando remoto, y el T El argumento le dice a SSH que desactive la asignación de pseudo-terminal.

Utilizando un simple comando SSH, hemos pasado a una red interna que normalmente no sería accesible para nosotros. Esto nos permite usar nuestro propio conjunto de herramientas en lugar de depender del host inicialmente comprometido para tener lo que necesitamos.

Por supuesto, no estamos limitados a reenviar HTTP. Podemos reenviar cualquier puerto de la máquina interna, incluido SSH, siempre que sepamos el puerto del servicio que estamos intentando reenviar.

Es tan fácil como cambiar un número de puerto en nuestro comando SSH. A continuación, reenviamos el servicio SSH en la máquina víctima a nuestro puerto local 8080. Esto nos permitiría usar SSH de fuerza bruta o probar las credenciales para iniciar sesión si las tenemos.

ssh -L 8080: internalTarget: 22 usuario @ comprometisedMachine

El reenvío de puertos locales es una excelente manera de pivotar en redes internas. También es una excelente manera de eludir las restricciones de red, como un bloqueo en el tráfico web a Null Byte. Algunas redes, por ejemplo, pueden estar bloqueadas para permitir que solo el tráfico salga a través de unos pocos puertos limitados. Como beneficio adicional, todo el tráfico que generamos desde el host local al servidor SSH está encriptado.

En el próximo artículo, veremos el reenvío de puertos remotos. Es similar a lo que estamos haciendo con el reenvío de puertos locales, pero como siempre con el redireccionamiento del tráfico, es un trabalenguas. Así que asegúrese de estar atento a esa guía en el futuro.

Como siempre, preguntas o comentarios puedes contactarme en Twitter. @ 0xBarrow.

Imagen de portada y capturas de pantalla de Barrow / Null Byte

Publicaciones relacionadas

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Botón volver arriba
Cerrar