Fruto de los últimos tests de penetración que hemos realizado me gustaría compartir con nuestros lectores una herramienta que he desarrollado “Quick-and-dirty” en Python para entornos donde un cortafuegos está bloqueando el tráfico de inicio de conexión TCP de salida a Internet, pero no el UDP. El escenario propuesto se trata de un clásico caso de post explotación donde hemos conseguido ejecutar código como root en una máquina Linux del segmento de usuarios o de DMZ. El problema es que no podemos iniciar conexión de un terminal (telnet, ssh, vnc…) hacia nuestra máquina remota, ni tampoco dado que no hay NAT, desde el atacante al servidor comprometido. Pero gracias al “hábil” administrador del Firewall el tráfico UDP está permitido de salida.
En este momento es donde entra en acción nuestra herramienta, la cual ejecutada en el entorno conquistado, mapeará todos sus puertos TCP al interfaz localhost de la máquina del atacante. Es decir, para conectar a un servicio TCP de la víctima protegido por el Cortafuegos, el atacante tan solo tendrá que conectar a un determinado puerto de su propia interfaz localhost. Toda la comunicación entre el equipo comprometido y el de la víctima, se realizará mediante paquetes UDP, obteniendo un resultado de transformación TCP2UDP. Al comenzar a remitir paquetes de este tipo desde la red interna de la víctima hacia el atacante, el Firewall actualizará su registro interno de “conexiones” UDP abiertas, dejando pasar el paquete de inicio de comunicación hacia el entorno comprometido, debido a la capacidad “conectionless” del protocolo UDP.
La herramienta hace uso de las aplicaciones “packit”, para mantener la comunicación cliente-servidor abierta y la gran “socat”, para la redirección de puertos sin utilizar “fifos”. La gran desventaja de esta herramienta tcp2udp es que todavía no trabaja en entornos Windows (próxima versión en curso). Ésta nos puede ser útil si por ejemplo la ejecución de código remota se ha realizado a través de una vulnerabilidad en una web, o necesitamos mapear servicios internos de la máquina al exterior. Espero os sea útil como lo fue para mí, happy hacking!
Pueden descargar la herramienta desde este enlace: tcp2udp.tar.gz
Muy muy chulo. Acabo de probarlo con una Ubuntu 10.10 y ha funcionado perfectamente.
Felicidades!!!!
Thankius!
Acabo de probarla y funciona bien en una Debian 5.
Buena herramienta y esperemos que siga evolucionando con lo que hay en el TODO.
Tengo una duda de una cosa
como el mapeo de TCP a UDP debe hacerse en la petición y en la repuesta, entiendo que la herramienta debe ejecutarse tanto en el cliente ( atacante ) y el servidor ( víctima ) ¿no?
@Jose María si. En el tar.gz puedes ver que hay una aplicación para cada máquina.
Muy chula la herramienta ;D
Muy buena herramienta Roberto. Estoy con Josemi, esperamos que siga evolucionando.
Saludos
Gracias Maite hay algunas cosillas como TODO pendientes. Sl2
Hola,
Un trabajo estupendo, estoy deseando probarlo en un par de entornos controlados. También tengo una duda: ¿El hecho de que UDP no sea orientado a conexión es decisivo para que la herramienta funcione? Es decir, si UDP fuera como TCP y sus conexiones salientes estuvieran permitidas ¿Habría algún impedimento técnico? Es que por muchas vueltas que le doy , no lo veo (he dormido poco esta noche jeje). Lo pregunto debido a que en el articulo pareces dar a entender que el hecho de UDP no sea orientado a conexión es algo decisivo.
Gracias y enhorabuena!!
Hola pj, gracias por tus comentarios, efectivamente el hecho de que UDP sea no orientado a conexión y la forma que tienen los cortafuegos de gestionar este tipo de tráfico posibilita su funcionamiento. Comentarte que también se podría hacer con otros protocolos como por ejemplo icmp (existen pruebas de concepto por la red ;)).
Saludos.
Hola ramado, primero gracias por la rápida respuesta.
No sé si ya es abusar, pero me gustaría saber el porqué… Le estoy dando vueltas y no doy con ello.
Hasta donde yo sé, los firewalls “modernos” tratan como stateful tanto UDP como TCP. Aunque tampoco sé si esto afectaría al funcionamiento de la herramienta, ya que desde luego no es lo mismo que el firewall guarde una tabla de sesiones (aunque sean UDP), que el hecho de que el protocolo no sea orientado a sesión.
Un saludo!
Dado que UDP no es orinetado a conexión no utiliza en su cabecera ninguna información al respecto como lo hace TCP con el número de secuencia y acuse de recibo (http://webs.ono.com/alfonn/images/Cabecera-TCP.jpg). La única información que provee es puerto origen, destino, checksum, tamaño y payload (http://www.flu-project.com/wp-content/uploads/15.jpg). Por lo tanto los firewalls que funcionan con cache stateful pueden identificar una sesión TCP mediante el número de secuencia. Es decir que un paquete determinado pertenece a un par de hosts (uno detrás del NAT y otro en una red externa) que han establecido una conexión, actuando sobre ellos
A(red interna)—–NAT—>B(en internet)
Ahora en UDP ¿cómo puede el firewall saber que un paquete que va de B:PuertoY –> A:PuertoX es legitimo de una “conexión” ya establecida si no ha identificado previamente un paquete SYN como en TCP? Pues simplemente si en una ventana temporal ha visto que se ha enviado un paquete de A:PuertoX –> B:PuertoY. Por lo tanto si conseguimos desde la red interna enviar paquetes UDP spoofeados con una frecuencia mayor a la ventana temporal podemos dejar abierto un “canal” al cual nos podremos conectar pese a que el puerto este cerrado en el firewall, ya que este lo interpretará como un tráfico que se ha originado desde el host interno.
Pegale un vistazo a “transversing nats” en google y te aportarán más información.
Saludos.
Había dado por sentado que el tráfico UDP saliente de la herramienta lo tirábamos por algún puerto usualmente permitido (DNS) y no había caído en lo de spoofear “sesiones” existentes.
Muchas gracias por la explicación ramado, ahora me parece aún más útil la herramienta :D