HTTP Tunneling (Avanzado!)

[Virus.h]

Holaz!!  
Bueno gente se me dio de postear este tema por que me parece muy interesante.
Y bueno queria compartir un poco de mis conocimientos  
  
Empesemos!!

                      HTTP Tunneling  
                               Burlando FireWall y ProxY

Hasta hace un tiempito HTTP ( Hyper Text Transfer Protocol ) era un protocolo trivial, del cual no nos
preocupabamos demaciado, pero con la llegada de nuevos Virus, SpyWare Polimorfico y software Mutante,
adaptables a colarse por cuanto purto abierto encuentren ( incluyendo el TCP 80 ), se hizo un punto y
aparte.
Se comenzo una nueva era dodne filtrar solo la Capa 3 no es suficionete.

(La capa 3 corresponde a la capa de red donde ocurre el direccionamien to)

Evidentemente, tendremos que enfrentarnos con nuevas tecnicas de evacion, y por que no de Intrucion.Pero
asi como evolucionan estas tecnicas, tambien lo hizop la Deteccion, muchas veces de manera Proactiva (las menos)
Y otras ,mas de manera Reactiva.

       BASES DE HTTP Tunneling
HTTP Tunneling se basa en una estructura de Cliente-Servidor, en la que el ckliente es el que tendrian
instalado residente en la computadora con la cual quisieramos burlar las limitaciones de un FireWall o Proxy,
Y el servidor es quien se encargaria de enviar nustros paquetes  al destinode nuestro requerimientos y de
devolvernoslos por el tunel que tenemos creado en HTTP contra el.

Las tecnologias del tunel no son nada novedosas: todos conocemos el IPsec y lso tuneles SSH, pero
imaginemos combinar el poder de un puertoen el cual se basa la vida de una empresa conectada a internet,
que opera y realisa transacciones on-line (como es HTTP) y utilizarlo para armar un Tunel. No solo estariamos
burlando las limitaciones de un FireWall o Proxy, sino  tambien que estariamos encriptando lo que enviamos.
Supongamos que estamos haciendo "by-pass" de un proxy de Microsoft: el administrador no tiene oportunidad
de descubrirnos, ay que el Log que el ve no le dira mucho.

          Veamos un ejemplo de dos conexiones: una estandar, con SSL, y otra conectada a HTTP tunel server,
   como puede ser http_host.
         En una conexion  estandar SSL,  en el Log se veria algo asi:

             YYYY-MM-DD HH:MM:SS
        EL_NOMBRE_DE_NUESTRA_COMPU' CONECT
     servidor remoto_ direcion
     :puerto remoto

Se pone en evidencia que el servidor que estamos usando y de que manera le trafico se transfiere
"como es".El administrador puede volcarlo al texto plano y leerlo.
        
         Conectandose a un servidor de HTTP Tunneling, como http_host sin encriptacion, en los Logs
   se veria algo como lo siguiente:

             YYYY-MM-DD HH:MM:SS
        EL_NOMBRE_DE_NUESTRA_COMPU GET
      direccion_del_tunel_http_host:puerto?
                 BASURA ALEATORIA

Asimple vista, el administrador no podria entender a dondo estamos dirigiendonos con nuestra conexion
Sabe que estaos asiendo un GET a traves de un tunel, peroe sa "Basura aleatoria", que vera en el log no
es tan basura que digamos, sino que es nuestra conexion codificada. Esto quiere decir que esta codificada
para que no pueda ser directamente interpretada, Pero, con un administrador con conocimineto y tiempo
para entretenerse, este texto puede ser deocdificado y ser claramente Legible.

  FUNCIONALIDADES DE HTTP Tunneling

Las aplicaciones de las tecnicas de encapsulado por HTTP Tunneling, son diversas, y varian de una simple
evacion para descargar un video de paris hilton desnuda por eMule, ata conectar MSN Messengar, realizar
orgias en vivo con 10 personas y todo lo que tengamos bloqueado encapsulado en el puerto 80.
Hermoso pero no todo es de color rosa:Oviamente estas tecnicas puieden ser utilizadas para realizar ataques
muy efectivos.

Los administradore s de seguridad o de los dispositivos perimetrales suelen restringir el trafico entrante y para
evitarse problemas, no lo hacen con el saliente, pero esto puede ser un problema mas granve. Siempre se
sugiere hacer una configuracion de doble bastion, donde generalmente un pilar es el FireWall y otro es sel proxy,
dando salidas y permisos LAN,¿Por que? Esto es muy simple: desde un proxy podemos manejar de manera mas facil,
restricciones para aplicaciones, todo a Layer 7, y dejarle toda la funcion de filtrado de paquetes al FireWall de
front-end, Ademas esto nos proteje de los ataques que veremos a continuacion.


Como ven las politicas de salida no estan restringidas, y tenemos permisos para acceder desde DNS server hacia
host con SSH sin problemas. Tambien tenemos visibilidad del WebServer al DNS server, ya que estan en la sub-red
(la DMZ).

Pensemoslo de la siguiente manera:  hasta aqui, nada parece extraño, pero una simple Vulnerabilidad en el WebServer
puede convertir una vulnerabilidad en un verdadero Caos y en una fuente de Zombies para ataques DoS.



                                                        EJEMPLO DE ATAQUE
  Supongamso que nuesto WebServer es vulnerable a expotacion remota que le devuelve
  al atacamnte un Shell de Root o System, ¿Como utilizaria el atacante tecnicas de HTTP Tunneling
  vulnerar oro host de la red? Para copmenzar y ya que rotularemos al WebServer de WINDOWS,
  montaria un servidor de HTTP Tunneling, una varsion precompilada como el HTS, y se aprovecharia
  de las relaciones de confinza entre WWW y el DNS/SMPT, de la siguiente manera:

                            hts.exe -F (PUERTO ORIGEN)DESTINO):(PUERTO DESTINO)
  
Al correr esto, el server WWW vulnerado estamos levantando un servidor HTTP Tunneling, para que
escuche un puerto valido y accesible para nosotros desde internet ( en este caso el, 80 ) y que, como
destino sea el server DNS/STMP por vulnerar el puerto destino TCP 23 (en este ejemplo, queremos obtener
una sesion TelNet). El comando correcto completo se veria asi:


                   hts.exe   -F 80 SERVER_DNS/STMP:23
Ya tenemos el server listo, solo falat preparar la maquina cliente, lo que hacemos de la siguiente manera:

                                      htc  -F (PUERTO ORIGEN)(DESTINO):(PUERTO DESTINO)

Completamos la sintaxis con un ejemplo-.

                      htc .F 6000 webserver:80

 Con esto, el intruso, al conectarse de una red local al puerto configurado como origen en el Cliente de HTTP
 Tunneling (TCP 6000), reenviara su requerimiento, de forma encapsulada, al HTTP al server destino (webserver)
 en el puerto que configuramos para escuchar (TCP 80). Este, al llgar al paquete, desencapsulara ria el
 requerimiento y lo reenviaria al host por vulnerar, configurado como puerto destino en el HTS (DNS/STMP), al
 puerto puerto destino al que quisieramos acceder(TCP 23). De esta manera, se obtendria una sesion de Telnet que luego se podria Brute Forcear para obtener acceso al server DNS/STMP


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Y eso es todo muchismas gracias por leerlo espero que allan sacado algo bueno!
Dejen sus respuestas criticas o bienaventuranz as!!

Saludos!!!

[v]irus