miércoles, abril 06, 2016

Tunelizar conexiones con Proxychains

El concepto de tunelizar y saltar entre máquinas puede parecer, en algunas ocasiones complejo. Esto no es así, tal y como se verá en este artículo. Además, proporciona cierto anonimato, lo cual podría ser utilizado por un atacante para preservar la dirección IP desde la que está trabajando. Pero esto también puede ser bueno para un pentester en caso de que este conectado desde una dirección que esté bloqueada y necesite saltar el bloqueo. Vamos a ver cómo se puede pivotar tunelizando conexiones y saltando entre máquinas.

Figura 1: Tunelizar conexiones con proxychains

El concepto de pivoting entre máquinas también viene asociado a esto y es que si proponemos un escenario de pentesting en el que:
Máquina A no tiene conectividad con la máquina C: Hay un firewall que nos bloquea.
Máquina B si tiene conectividad con la máquina C.
Túnel de A a C, pasando por B: Si logramos acceso a la máquina B, podremos utilizarla para desde la máquina A pasar por la máquina B y lograr conectividad con la C.
Figura 2: Esquema del escenario. La máquina del atacante está bloqueada.

El esquema representa el escenario anterior. Por alguna razón no tenemos conectividad con la máquina que queremos auditar / atacar, pero encontramos una máquina que tiene permiso para conectar con el objetivo. Utilizaremos una forma de pivotar nuestras peticiones.

¿Cómo logro acceso a la máquina pivote?

Esto es un debate siempre en los cursos, hay muchas formas, y es que habrá que auditarla y conseguir acceso a esa máquina. Generalmente, mediante el aprovechamiento de una vulnerabilidad en la máquina intermedia utilizando algún exploit. Existen otras formas menos directas como es el robo de alguna credencial de dicha máquina o, incluso, la realización de fuerza bruta en busca de alguna debilidad. Sea como sea partimos de que tenemos control sobre dicha máquina.

Utilizaremos conexiones SSH para acceder a la máquina con las siguientes opciones:
El parámetro –N: Le decimos a la máquina remota que no ejecute ningún comando a través de la sesión abierta de SSH.
El parámetro –f: Deja la conexión SSH en background una vez nos autenticamos.
El parámetro –D: Crea un túnel para realizar port-forwarding. Este es el parámetro dónde se está creando el servidor SOCKS. El puerto que se queda abierto en nuestra máquina es el que se indica con el parámetro –D, por ejemplo utilizaremos 1080. Todo lo que enviemos desde nuestra máquina al puerto 1080 será redirigido hacia el túnel SOCKS que estamos creando.
Preparando el pivote

La instrucción que se ejecuta es ssh –NfD [puerto a la escucha en local] [user ssh]@[ip]. Como se puede ver en la imagen, la dirección IP del primer pivote acaba X.X.9.95. Este es un detalle para más adelante.

Figura 3: Configuración de ssh en la máquina pivote

Tras autenticarnos tenemos la conexión y el túnel montado entre nuestro puerto 1080 y una máquina remota. Utilizaremos proxychains para pasar por la máquina intermedia. Editando el fichero de configuración que se encuentra en /etc/proxychains.conf tenemos que tener en cuenta la dirección IP a la que enviar el tráfico, en este caso será nuestro propio localhost y el puerto a la escucha, en este caso el 1080.

Hay que recalcar que este tipo de acciones se pueden hacer con pivotes, por ejemplo, obtenidos con Metasploit y aprovecharnos del potencial de un Meterpreter a través de varios saltos, pero eso será cuestión de otro artículo.

Figura 4: Configuración de proxychains.conf

En la imagen anterior se ve la configuración de proxychains. La que ahora mismo está preparada es la del puerto 1080. Utilizaremos proxychains para sacar el tráfico por la conexión. La sintaxis es sencilla en un terminal podemos escribir proxychains [nombre programa] y la aplicación sacará su tráfico por el túnel montado.

Para hacer un ejemplo rápido ejecutamos en Kali Linux el comando proxychains iceweasel. Al navegar a un sitio de consulta de dirección IP pública veremos que acaba en 9.95, por lo que es la dirección IP de la máquina pivote.

Figura 5: Navegando a través de la máquina pivote

Si desde Iceweasel intentamos abrir una conexión HTTP con otra máquina y en esa máquina tenemos acceso podríamos ver con tcpdump una captura de red y ver la dirección IP origen. El resultado es igual, la dirección IP origen es la que acaba en 9.95, por lo que volvemos a ver que el receptor de las peticiones ve como emisor a otra dirección IP.

Figura 6: Tráfico capturado por tcpdump a través del máquina pivote

De este modo, el caso del bloqueo del firewall quedaría resuelto, si la dirección IP acabada en 9.95 tiene permiso.

Metiendo más saltos: Chain++

Meter más máquinas en la conexión es sencillo con proxychains. Simplemente tenemos que añadir al fichero de proxychains.conf una nueva dirección IP, la cual seguirá siendo nuestro localhost de nuevo, y un nuevo puerto. Es importante que los puertos no coincidan, por lo que ahora utilizaremos el 1081.

Figura 7: Añadiendo otro salto en proxychains.conf

Abriendo una conexión SSH entre la máquina pivote 1 y pivote 2, será proxychains el que hará que el tráfico pase primero al privote 1, luego al pivote 2 y posteriormente llegue al destino. En la siguiente imagen se puede ver un ejemplo claro y sencillo de ello. Utilizando el programa curl pedimos el recurso al dominio ip.appspot.com, el cual sencillamente te da la dirección IP que hace la solicitud.

Cuando hacemos la petición sin proxychains vemos que nos proporcionan una dirección IP X.X.9.148, mientras que cuando utilizamos proxychains obtenemos una dirección IP X.X.6.9, la cual no es la que teníamos antes (que se quedó siendo el primer pivote). Ahora en el destino obtenemos que el tráfico viene de la dirección IP del segundo pivote.

Figura 8: petición curl vía proxychains a ip.appspot.com

Como se ha podido ver es fácil encadenar máquinas y pivotes para sacar tráfico de forma anónima o utilizar las cadenas para bypassear mecanismos de seguridad en una auditoría. Esto se puede juntar con Metasploit y obtener un gran potencial de la mano de un Meterpreter en una post-explotación, pero como dije anteriormente: queda para otro artículo.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell

8 comentarios:

Anónimo dijo...

Muchas gracias por la info Pablo! y muy bien esplicado, lo he entendido hasta yo! :p

Saludos!

Anónimo dijo...

explicado* ñ.ñ

Anónimo dijo...
Este comentario ha sido eliminado por el autor.
Unknown dijo...

Muy buen artículo, la explicación es muy clara. Sería genial si pudieras armar algo similar, fácilmente portable, para entornos Windows.

Unknown dijo...

Muy buen artículo, la explicación es muy clara. Sería genial si pudieras armar algo similar, fácilmente portable, para entornos Windows.

Jaime Chiquita dijo...

Gracias por compartires :-)
Pablo como mi padre me dice: Quando un hombre sabe el explica de modo sencilo.
Voy a intentar obtener el libro.

Unknown dijo...

Sencillo artículo pero explica con claridad lo que quiere expresar!

Enhorabuena!

CubaRed dijo...

Esta bueno el articulo, tambien se puede usar el desproxy para traer el puerto 443, ahora mi duda, como podemos protegernos de que no puedan hacer eso en una red empresarial, es decir que a travez del proxy no puedan hacer un tunnel ssh por 443

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares