viernes, 14 de octubre de 2011

Cross Site Tracing

Cross Site Tracing

# Introduccion a HTTP.

A esta altura, y si estas leyendo esto creo suponer que tus conocimientos en lo que respecta a HTTP son 'intermedios' sabes como se maneja y funciona una web, y nociones sobre XSS -cross site scripting- (tengo un pequeño paper de introduccion a xss y derivados en http://confused.vndv.com/?p=32) sino es asi, bueno, hare una breve introduccion pero te recomiendo que leas un manual dedicado a estos temas especificos ya que no es el fin de este paper.

Para empezar HTTP significa Hyper-Text Transfer Protocol.Este -protocolo de transferencia de hipertexto- es el protocolo comunmente usado para todo tipo de transferencias o transacciones Webs.

Este protocolo se basa en un esquema denominado 'peticion-respuesta', es quien se encarga de mantener a los clientes conectados a los servidores, transferir datos entre ambos, como tambien las conexiones proxy.

Algo basico que hay que saber es que a un navegante como podriamos ser nosotros, cuando se conecta a una web como la de Google, se lo conoce al cliente como User-Agent. Aclaro esto porque es un vocablo muy utilizado en la jerga de programacion, y de hacking. A la informacion que se transmite entre servers y clientes, se lo conoce como RECURSOS y es identificada mediante un tipo de URI como el localizador URL. (para mas informacion wikipedia.org).
Una URL esta formado por 4 factores comunes, un protocolo, un nombre de la web/host/ip, un directorio y archivos.

# METODOS HTTP.

HTTP permite entre otras cosas, realizar diferentes metodos y acciones en un Servidor. Con el objetivo de brindar soporte a todas las personas que implementan esta tecnologia y testean aplicaciones HTTP.

Cuando una computadora "X" intenta ingresar a Google.com por ejemplo, realiza una peticion para poder visualizar la informacion remota, mediante un metodo y varios mas que se pueden acoplar para interactuar con la informacion. Veamos los distintos Metodos:

GET ------->  De los mas utilizados.
POST ------->  De los mas utilizados.
HEAD
TRACE
PUT
DELETE
CONNECT
OPTIONS


Como podemos ver disponemos, de bastantes metodos para interactuar con la informacion. Pero los mas comunes son GET y POST.
Estos dos metodos nos permiten acceder a la informacion que nos expone un servidor web mediante el ya explicado HTTP.

# GET => El metodo get se utiliza para introducir parametros de una solicitud HTTP mediante un navegador a un servidor web. Este metodo coloca parametros en la url generalmente separados por un "&", por ejemplo veamos el siguiente ejemplo una busqueda a Google sobre mi web:

http://www.google.com.ar/search?hl=es&q=confused.vndv.com&btnG=Buscar&meta=

Vemos como enfatice las "&".

# POST => El metodo post permite enviar datos de una forma diferente al metodo GET. Su envio es mas 'oculto' por asi decirlo ya que no figura en la URL de la barra de direcciones del navegador a simple vista de todos. Sino que lo hace mediante el CUERPO.

# METODOS QUE IMPLICAN RIESGO PARA LA SEGURIDAD


En esta seccion del paper, voy a nombrar los metodos mas importantes a mi modo de ver dps de describir GET y POST, que pueden llegar a permitir un riesgo en nuestro servidor. Veamos...

# PUT => Este metodo es el que permite el uploading de archivos a un servidor web.
Un atacante podria explotar este metodo realizando uploads de troyanos, o archivos de tipo malware. Generalmente esos son la finalidad del ataque.

# CONNECT => Este metodo generalmente es usado para realizar conexiones, por ejemplo una como SSL entre un cliente y un site https.
Un atacante podria usar un site como proxy.

# DELETE => Este metodo permite ELIMINAR archivos en el servidor web. Un atacante podria realizar desde la eliminacion de archivos vitales, como del site web o index.

# TRACE => Este metodo realiza la depuracion de las entradas de los Usuarios.
Y no hace mas que otra cosa que devolver cualquier cadena que es enviada al servidor web.

<----- Bien creo yo que estos son los mas 'peligrosos' y deberiamos dependiendo de nuestra posicion y labor de la web, deshabilitarlos.Claro que si realmente necesitamos utilizarlos, tendriamos que elaborar un tipo de contencion ante un mal uso, configurarlo bien y asegurarlos a usuarios permisivos. ---->

# PRUEBA DE METODOS

Ok, lo primero es intentar chequear que tipo de metodos son aceptados en alguna web, por respeto hacia terceros voy a omitir la 'web' con un 'www.objetivo.com' en su reemplazo.
# Requisitos -> Telnet / Netcat.

$> Probando que metodos tiene disponible un site mediante OPTIONS / HTTP/1.0

confused@opk:~$ nc
www.objetivo.com 80
OPTIONS / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 20 Jul 2009 18:35:35 GMT
Server: Apache/2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.2.9
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Length: 0
Connection: close
Content-Type: text/html


Como vemos acepta los siguientes metodos -> get, head, post, options, trace.
Como este paper se refiere a metodos http y a cross site tracing, vamos a basarnos en el metodo TRACE.
# Localizando posibles XST potenciales

El metodo TRACE, puede ser una navaja de doble filo. Comunmente esta tecnica es usada para el fin de reemplazar o robar credenciales a un sistema meidante (cookies) Veamos..

$> Verificando que el TRACE es permitido en el objetivo.

confused@opk:~$ nc www.objetivo.com 80
TRACE / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 20 Jul 2009 18:58:39 GMT
Server: Apache/2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.2.9
Connection: close
Content-Type: message/http

TRACE / HTTP/1.0


Bien la respuesta es "OK!" esto significa que la presencia del TRACE es correcta, que previamente nos habia indicado OPTIONS pero por las dudas quisimos asegurarnos.

# ELABORANDO UNA IDEA DE ATAQUE

Bien vamos a analizar esto, supongamos que siempre nos loguiamos a un foro, donde tenemos nuestra cookies habilitadas.
Ahora imaginemos que si enviamos una peticion TRACE via nuestro querido navegador y dicho navegador logicamente tiene esa cookie a ese portal de internet o foro. Bueno pues la cookie seria incrustada en las cabeceras de la peticion hecha por nosotros y seran por lo tanto devueltas por la respuesta del TRACE, donde para finalizar podremos acceder a ella mediante javascript y enviarla a donde queramos, como una web que trabaje de receptora de cookies, previamente montada.

Aunque hay un problema debido a que el navegador solamente puede iniciar una conexion a un objetivo donde se encuentre el script malicioso.

<---- Para que un navegador realize una peticion TRACE tenemos que tener algunos conocimientos sobre objetos de control de ActiveX.
Como este paper no trata de aprender eso y se supone que tienen nociones basicas almenos, seguiremos ---->
<---- En Mozilla Firefox, tenemos el control XMLDOM y en IE tenemos el XHR. Son interfaces creadas para realizar peticiones HTTP y HTTPS a servidores webs ---->


Volviendo con el problema que teniamos, lo mas comun es que los hackers logren inyectar codigo javascript en alguna parte de la web victima, como si hariamos un XSS, el script estará programado con la peticion TRACE. Claro que para esto tambien tendriamos que disponer que la web esa sea vulnerable a XSS verdad?.

Otra forma un poco mas sofisticada seria la de CREAR UNA WEB, donde el que nos visita, 'la victima' ingrese y mediante algun tipo de explotacion a nivel navegador para que se realice una conexion al sitio con la peticion TRACE y nos revele la cookie que intentamos robar.


\\nota

copy paste de: http://foro.el-hacker.com/f55/intro-cross-site-tracing-metodos-http-144807/

cuando no puedes superar lo perfecto, mejor no intentar mejorarlo  y dejarlo como está xD.

agradecimientos a: confusedmind

No hay comentarios:

Publicar un comentario