60-62-Redes-P24.
qxd 9/5/05 11:20 Page 60
LEANDRO F. REOX
.hck ESPECIALISTA EN REDES Y SEGURIDAD
lmet5on@fibertel.com.ar
« BURLANDO FIREWALLS Y PROXYS
HTTP TUNNELLING
os que trabajamos en IT siempre
L nos hemos preocupado, como
administradores de una red, de
diagramar e implementar una correcta po-
lítica de seguridad, donde la AAA (Autho-
rization, Authentication & Accounting) sea
respetada y correctamente aplicada. Hasta
hace un tiempo, HTTP (HyperText Transfer
Protocol) era un protocolo trivial, del cual
no nos preocupábamos demasiado, pero
con la llegada de worms, spyware polimór-
fico y software “mutante”, adaptables a
“colarse” por cuanto puerto se encuentre
abierto (incluyendo el TCP 80), se hizo un
punto y aparte. Se comenzó una nueva era
en la que filtrar sólo en Capa 3 no era su-
ficiente (recordemos que, según el modelo
OSI expuesto en POWERUSR #20, la Capa 3
corresponde a la capa de red donde ocurre
el direccionamiento). Evidentemente, ten-
dríamos que enfrentarnos con nuevas téc-
nicas de evasión y, por qué no, de intru-
sión. Pero así como evolucionan las técni-
cas de intrusión, también lo hacen las de
detección, muchas veces, de manera
proactiva (las menos), y otras muchas más,
de manera reactiva (casi todas, cuando el
pánico cae sobre la tierra y un worm apo-
calíptico infecta más del 80% de las má-
quinas hogareñas y servidores corporativos
alrededor del mundo). Sí, lo sé: la frase
anterior suena un tanto extremista. Pero,
para todos los que sufrimos por tener que
hacer desinfecciones masivas de Blaster y
Sasser, es más real que la realidad misma.
Pero dejemos el llanto aparte y los recuer-
dos de horas extra de trabajo, parcheo y
reinstalaciones, para centrarnos en el mo-
tivo de este artículo: el HTTP Tunnelling.
BASES DEL HTTP TUNNELLING
El HTTP Tunnelling se basa en una es-
tructura cliente-servidor, en la que el
cliente es el que tendríamos instalado re-
sidente en la PC con la cual quisiéramos
burlar las limitaciones de un firewall o
un proxy, y el servidor es el que se en-
cargaría de forwardear los paquetes al
destino de nuestro requerimiento y de
devolvérnoslos a través del túnel que te-
nemos creado por HTTP contra él.
60
HOY VEREMOS LAS FORMAS DE USO ALTERNATIVAS, NON-SANCTAS E
INOCENTES DE ESTE PROTOCOLO, A TRAVES DE LA CONSTRUCCION DE
TUNELES, DONDE SE ENCAPSULAN EL RESTO DE LOS PROTOCOLOS
FILTRADOS POR LAS PROTECCIONES MAS COMUNES, PRESENTES EN
LA MAYORIA DE LAS EMPRESAS. ¿USTED REALMENTE CREE QUE ESTA
AUDITANDO A LOS USUARIOS DE SU RED? PIENSELO DOS VECES.
FIGURA 1
RED PRIVADA
Usuarios finales con cliente de HTTP tunnelling
instalado trafican evadiendo el firewall
Router
Los servers de HTTP tunnelling
reciben la data de los clientes
y la redirigen
HTTP Proxy INTERNET
Firewall
Router
Ahora los servidores de aplicativos y webs inaccesibles son visibles
PODEMOS OBSERVAR COMO TRABAJA HTTP TUNNELLING PUENTEANDO
LOS FIREWALLS O PROXYS Y ENVIANDO EL TRAFICO A TRAVES DEL
SERVER DE HTTP-TUNNEL, QUE LO REDIRIGE Y ENTREGA A LOS
SERVERS ANTES INACCESIBLES.
Las tecnologías de túnel no son na- Veamos un ejemplo de dos tipos de
da novedoso; todos conocemos IPsec conexiones: una estándar, con SSL,
y los túneles SSH, pero imaginemos y otra conectada a un HTTP túnel
aprovechar el poder de un puerto en server, como puede ser http_host.
el cual se basa la vida de una em- En una conexión estándar SSL, en
presa conectada a Internet, que ope- el log se vería algo así:
ra y realiza transacciones online (co-
mo es HTTP), y utilizarlo para armar YYYY-MM-DD HH:MM:SS
un túnel. No sólo estaríamos burlan- EL_NOMBRE_DE_NUESTRA_PC CONNECT
do las protecciones de un firewall o Servidor remoto_ direccion:Puerto remoto
proxy, sino que también estaríamos
encriptando lo que enviamos. Su- Se pone en evidencia qué servidor
pongamos que estamos haciendo estamos usando y de qué manera el
“by-pass” de un proxy Microsoft: el tráfico se transfiere “como es”. El
administrador no tiene oportunidad administrador puede volcarlo a tex-
de descubrirnos, ya que el log que to plano y leerlo.
ve en él no le dirá mucho. Conectándose a un servidor de
POWERUSR
 60-62-Redes-P24.qxd 9/5/05
HTTP Tunnelling, como http_host sin
G encriptación, en los logs se vería algo
como lo siguiente:
YYYY-MM-DD HH:MM:SS EL_NOMBRE_DE_NUESTRA_PC
GET direccion_del_tunel_de_http_host:Puerto ? BASURA
ALEATORIA
A simple vista, el administrador no podrá
entender a dónde estamos dirigiéndonos
con nuestra conexión. Sabe que estamos
haciendo un GET a través de un túnel, pero
esa “basura aleatoria” que verá en el log
no es tan basura que digamos, sino que es
nuestra conexión “codificada”. Esto quiere
decir que está codificada para que no pue-
da ser directamente interpretada, pero, con
un buen administrador que tenga tiempo
para entretenerse, este texto puede ser de-
codificado y ser claramente legible.
Acá es donde entra en juego la encripta-
ción, con el fin de que nuestro tráfico a
través de un túnel HTTP no sea visible. Pa-
ra hacer más gráfico lo teórico, en la Fi-
gura 1 podemos apreciar, básicamente, la
forma en que opera HTTP Tunnelling.
FUNCIONALIDADES DE HTTP
TUNNELLING
Como hemos visto a lo largo del artículo,
y si su imaginación les permite volar un
poco mas allá de lo que dijimos, se habrán
dado cuenta de que las aplicaciones de las
técnicas de encapsulado por HTTP Tunne-
lling son diversas, y varían desde una sim-
ple evasión para descargar el video de la
prima de Pablo Hauser desde eMule, hasta
conectar MSN Messenger, realizar video-
conferencias y todo lo que tengamos blo-
queado encapsulando en el puerto 80. Her-
moso, pero no todo es de color de rosa:
obviamente, estas técnicas pueden ser uti-
lizadas para realizar ataques, y bastante
efectivos. De ahora en adelante, vamos a
hacer un resumen de cómo configurar las
aplicaciones más comunes para salir con
un servidor haciendo tunnelling, y de qué
manera suelen realizarse ataques a través
de este tipo de medio.
ATAQUES: UN POCO DE TEORIA
Como todos sabemos, gran cantidad de los
ingresos de las empresas actuales depen-
den de una buena estrategia de marketing.
La Web juega un papel muy importante en
este campo, y es por eso que toda organi-
zación, por más pequeña que sea, siempre
tiene su sitio web, con su webserver. Al
principio de esta nota, decíamos que la
POWERUSR
11:20 Page 61
FIGURA 2
Atacante
INTERNET
PODEMOS OBSERVAR AQUI EL ESQUEMA BASICO PLANTEADO, Y CON EL CUAL VAMOS A
TERMINAR DE EXPLICAR EL METODO DE INTRUSION Y ATAQUE.
evolución y el avance de las técnicas de
intrusión y evasión habían sido enormes,
y que ya no bastaba con los firewalls.
Muchas veces, los sistemas de detección
de intrusos (IDS) se quedaban cortos y
había que utilizar un poco más de defen-
sa activa, con sistemas de prevención de
intrusos (IPS), que toman acciones ba-
sándose en firmas de ataque (como ya
comentamos en ediciones anteriores de
POWERUSR). Entonces, habiendo recalca-
do esto, podemos asegurar que todos los
clientes poseen un esquema básico de fi-
rewalling con salida a Internet a través
de él, o de un proxy y con una DMZ (zo-
na desmilitarizada), donde se encuentran
los servidores de acceso público, como
los webservers. De todos modos, esto se
ve mejor graficado en la Figura 2, donde
podemos ver un webserver publicando
HTTP (TCP 80) y HTTPS (TCP 443), pro-
bablemente, una página que utiliza SSL.
Los administradores de seguridad o de
los dispositivos perimetrales suelen res-
tringir el tráfico entrante y, para evitarse
problemas, no lo hacen con el saliente,
pero esto puede ser un problema más
que grave. Siempre se sugiere hacer una
configuración de doble bastión, donde,
generalmente, un pilar es un firewall, y
el otro, un proxy dando salida y permi-
sos a la LAN. ¿Por qué? Esto es muy
simple: desde el proxy podemos manejar,
de manera más fácil, restricciones para
aplicaciones, todo a layer 7, y dejarle la
función de filtrado de paquetes al fire-
wall de front-end. Además, esto nos pro-
tege del ataque común que veremos a
continuación. Suponiendo el esquema de
restricciones de acceso planteado ante-
riormente, las reglas presentes en el fire-
wall se verían de la siguiente manera:
DMZ Inside
www (80.443) SSH
Windows NT/2000 (TCP/22. TCP/80.
IIS 4.0/5.0 TCP/443)
DNS/SMTP
(TCP/23. TCP/69)
Sun Solaris 2.6
Red Corporativa
inbound:
permit tcp any host WWW eq 80
permit tcp any host WWW eq 443
permit tcp any host DNS/SMTP eq 25
permit udp any host DNS/SMTP eq 53
outbound:
permit ip any any
Acá se definen las políticas entrantes hacia
los servidores en la DMZ, con los servicios
que tiene publicados cada equipo.
inbound:
permit ip host DNS/SMTP host SSH eq 22
permit ip host DNS/SMTP host SSH eq 80
permit ip host DNS/SMTP host SSH eq 443
outbound:
permit ip any any
En ellas definimos permisos entre inter-
faces “trusted” (o seguras y conocidas),
como es el acceso desde el server Sun
que actúa como DNS y SMTP al equipo,
atendiendo SSH, HTTP y HTTPS.
Como vemos, las políticas de salida no es-
tán restringidas, y tenemos permisos para
acceder desde el DNS server hacia el host
con SSH sin problemas. También tenemos
visibilidad del webserver al DNS server, ya
que están en la misma subred (la DMZ).
Pensémoslo de la siguiente manera: has-
ta aquí, nada parece extraño, pero una
simple vulnerabilidad en el webserver
puede convertir nuestra red completa en
un caos y en una fuente de zombies para
ataques remotos de DoS.
EJEMPLO DE ATAQUE
Supongamos que nuestro webserver es
vulnerable a una explotación remota que
le devuelve al atacante una shell de root
o system. ¿Cómo utilizaría el intruso
61
60-62-Redes-P24.qxd 9/5/05 11:20 Page 62

■ www.http-tunnel.com: Software comercial, con servers propios online. Hay un cliente y un servidor versión freeware, pero con límite de KB/s transferidos.
Links Es un desarrollo muy maduro, y uno de los más nombrados y conocidos.
■ www.hopster.com: Este software también es pago. Ofrece máxima compatibilidad con sistemas operativos Windows, pero con límite de transferencia en las
versiones freeware (2 KB/s).
■ www.nocrew.org/software/httptunnel.html: La maravillosa versión freeware bajo licencia GPL es la utilizada en todos los ejemplos del artículo.
■ www.bypass.cc: Otra buena alternativa. También la versión freeware está limitada en el ancho de banda. De todos modos, las membresías no son muy caras
y se puede pagar mediante PayPal.
■ https://opentools.dev.java.net/contentswitch/modules/httptunnel/HTTPTunnel.html: Un excelente proyecto Open Source de la gente de Java.NET, muy bien
documentado. Está en etapa de maduración, pero es muy recomendable.

técnicas de HTTP Tunnelling para vulne-
rar otro host de la red?
Para comenzar, y ya que rotulamos al
webserver como un servidor Windows,
montaría un servidor de HTTP Tunnelling,
una versión precompilada como el HTS, y
se aprovecharía de las relaciones de con-
fianza entre el server WWW y el
DNS/SMTP, de la siguiente manera:
hts.exe -F (PUERTO ORIGEN) (DESTINO):(PUERTO DESTINO)
Al correr esto, en el server WWW vulne-
rado estamos levantando un servidor de
HTTP Tunnelling para que escuche en un
puerto válido accesible para nosotros
desde Internet (en este caso, el 80) y que,
como destino, sea el server DNS/SMTP a
vulnerar a puerto destino TCP 23 (en es-
te ejemplo, queremos obtener una sesión
de Telnet). El comando completo correcto
se vería así:
hts.exe -F 80 SERVER_DNS/SMTP:23
Ya tiene el server listo; sólo le falta pre-
parar su máquina cliente, que lo hace de
la siguiente manera:
htc -F (PUERTO ORIGEN) (DESTINO):(PUERTO DESTINO)
Completemos la sintaxis con un ejemplo:
htc -F 6000 webserver:80
FIGURA 3
2 hts- F 80 DNS/SMTP:23
htc- F 1025 www:80
3 CONCLUSIONES
INTERNET
1 bien generados y sumados a la encriptación, son di-
Atacante
LA RED LE PERTENECE COMPLETAMENTE AL ATACANTE, Y EL TRAFICO SIGUE SIENDO
A TRAVES DE PUERTOS VALIDOS, EXPLOTANDO RELACIONES DE CONFIANZA ENTRE
SERVERS DES REDES PROTEGIDAS POR EL FIREWALL DEL CLIENTE.
62
Con esto, el atacante, al co-
nectarse de manera local al
puerto seteado como origen
en el cliente de HTTP Tunne-
lling (TCP 6000), forwardearía
su requerimiento, en forma
encapsulada, a través de
HTTP al server destino (web-
server), en el puerto destino
que seteamos para escuchar
en el server (TCP 80). Este, al
llegar el paquete, desencapsu-
laría el requerimiento y lo
reenviaría al host por vulne-
rar, seteado como server des-
tino en el HTS (DNS/SMTP),
al puerto destino al que que-
ríamos acceder (TCP 23). De
esta manera, se obtendría una
sesión de Telnet que luego
podría intentar “bruteforcear”
para obtener acceso al server
DNS/SMTP.
MEJORAR EL ATAQUE
Ahora bien, si paramos la pelo-
ta y vemos lo que se acaba de
hacer, también podría utilizarse
esta técnica para redireccionar
al puerto de Finger (TCP 79)
para enumerar usuarios y, así,
realizar un “bruteforce” con
más información y con 90% de
probabilidades de éxito.
DMZ Inside
www (80.443) SSH
Windows NT/2000 (TCP/22. TCP/80.
IIS 4.0/5.0 TCP/443)
4 5
Puertos 80,
6 22, 443
permitidos de
DNS/SMTP manera
(TCP/23. TCP/79) entrante solo
Sun Solaris 2.6 desde la DMZ
a la LAN
Red Corporativa
Tranquilamente y con confianza, el atacante se siente
el rey del “bruteforcing” y está cargado con una lista
en un TXT de 30 MB donde hay más contraseñas que
nombres en el padrón de votantes, con lo cual gana
acceso de root al server DNS/SMTP. Una vez más,
puede utilizar la técnica para tratar de acceder al ser-
ver SSH en la red LAN del cliente y, como pueden
ver, ya tiene control de cada punto en cada sector de
esa red. En pocas palabras, la red del cliente es suya,
como podemos apreciar en la Figura 3.
Se habrán dado cuenta de que los alcances de esta
técnica son los que logren imaginar. Todo esto se
habría evitado si los servers no hubieran tenido sa-
lida completa y si el control de acceso a Internet se
hubiese diagramado de manera correcta.
APLICACIONES MAS “INOCENTES”
Aunque les sea difícil pensarlo, no todo en HTTP
Tunnelling se aplica con malas intenciones.
Algunos usos son más inocentes, y otros, hasta
muy beneficiosos.
La mayoría de los mortales emplea los túneles para
usar aplicaciones como mensajeros o P2P que están
bloqueados por su proxy o firewall local. Todos se
estarán preguntando cómo hacerlo. Es muy fácil: tal
como explicamos antes, el túnel actúa como un
proxy Socks local, para poder encapsular el tráfico
hacia un server remoto que será el encargado de re-
solver todo por nosotros. Por ende, para configurar
nuestros programas, debemos encontrar las opciones
de proxy Socks 4 o 5, y asignarles como server “lo-
calhost” y el puerto al que hayamos puesto a escu-
char nuestro cliente de HTTP Tunnelling. Hecho esto,
ya podemos descargar música, chatear con amigos y
realizar videoconferencias, cuando antes sólo tenía-
mos salida para navegar. Un verdadero éxito, ¿no?
También existe una manera de aplicar esta técnica
del lado del auditor, para realizar un buen testeo de
políticas de seguridad perimetral en un Data Pene-
tration Testing, y probar las capacidades de los IDS
e IPS que el cliente tiene en su red.
Los túneles HTTP son un medio muy poderoso para
el usuario y para el atacante, pero un gran dolor de
cabeza para los administradores de redes, ya que,
fíciles de detectar y de mitigar.
Mi recomendación es utilizar protecciones en Capa 7,
analizar y diagramar de manera correcta las políti-
cas de acceso a Internet (no sólo las de servicios en-
trantes), controlar quién y cómo accede a puertos
comunes, y bloquear la sentencia CONNECT para el
protocolo web. Sin embargo, hay que advertir que
esto último puede traer problemas con conexiones
seguras https; por ende, lo mejor es auditar los logs
de manera intensiva; aunque sea costoso, es un obs-
táculo más para saltar, factor que puede desanimar
a muchos y, así, evitar problemas. ■
POWERUSR