Banner 1

Mostrando entradas con la etiqueta xss. Mostrar todas las entradas
Mostrando entradas con la etiqueta xss. Mostrar todas las entradas

Bypass del filtro XSS de Chrome con nombres de variable y caracteres especiales (También afecta blogger xD)

Publicado por Unknown en 9:44 viernes, 21 de noviembre de 2014 Etiquetas: , , 0 comentarios
A pesar de que el tique asignado siga privado y sin resolver a día de hoy, el equipo de Chrome me ha dado permiso para hacer público este fallo que descubrí a finales de marzo. Generalmente, los fallos que permiten bypassear el XSSAuditor de Chrome son calificados por su equipo técnico con un nivel de severidad nulo respecto a la seguridad del navegador, ya que consideran que la brecha se encuentra realmente en la página vulnerable. Tal como indicaron en el hilo de comentarios de la incidencia:

"We generally treat XSSAuditor bypasses as security non-issues, as the fault is in the server, not is ourselves."

Uno de los puntos de inyección olvidados en muchas ocasiones es el nombre de las variables en una petición web:
http://www.webvulnerable.com?coche=rojo&barco=negro

    <html>
    <body>
            <ul>
                    <li>El color escogido para el coche es: rojo</li>
                    <li>El color escogido para el barco es: negro</li>
            </ul>
    </body>
    </html>

Mientras puede que te hayas vuelto loco probando ataques sin éxito en los valores "rojo" y "negro", quizá puedas ver la luz inyectando sobre los nombres de variable:
http://www.webvulnerable.com?coche=rojo&barco=negro

    <html>
    <body>
            <ul>
                    <li>El color escogido para el coche<script>alert('XSS')</script>es: rojo</li>
                    <li>El color escogido para el barco es: negro<script>alert('XSS2')</script></li>
            </ul>
    </body>
    </html>

El filtro XSS de Chrome, en principio, no debería tener problemas para parar estos ataques. Sin embargo, cuando se da este tipo de vulnerabilidad, los servidores pueden hacer ciertas transformaciones por su cuenta. En concreto, contra un servidor PHP, si introducimos uno de los siguientes caracteres en una cadena del nombre de la variable, será transformado automáticamente a un guión bajo "_":
"espacio", "[", "+", "."

El filtro de Chrome no esperará este cambio y será bypasseado. Como prueba de concepto, preparé una página con un sencillo código en el lado del servidor:

            echo "
      "
    ;
            $keyArray = array_keys($_GET);
            foreach ($keyArray as &$key) {
                    echo "
  1. You have defined the variable: $key
    2. ";
            }
            echo "
";
?>

Podéis testear el bypass pulsando en el siguiente enlace:

Se puede comprobar que otros filtros XSS como el de NoScript para Firefox o el filtro por defecto de Internet Explorer sí protegen correctamente en este escenario.

Es interesante recordar que, actualmente, esta no es la única manera de burlar el filtro de Chrome en su última versión. También podemos hacerlo explotando estratégicamente más de una variable vulnerable, como  pudimos ver en este artículo, con el método descubierto por Nick Nikiforakis. En este último caso, el tique asignado fue resuelto con un "WontFix", lo que quiere decir que ni está arreglado, ni se piensa arreglar en el futuro. Una vez más, esta técnica es tratada correctamente por NoScript e Internet Explorer.

Esperemos que el equipo de Chrome no adopte como norma general restar importancia a estos casos de vulnerabilidades que son relativamente "poco comunes", ya que su acumulación podría generar un "cheat sheet" bastante molesto, y que lo dejara en mal lugar respecto a la competencia.
¡Saludos!
NOTA:  SI LO HAN NOTADO, BLOGGER TAMBIEN SUFRE POR ESTA BYPASS :), MOSTRANDO CUANDO CARGA LA PAGINA EL ALERT XSS PERO EL POST SUFRE UN MALFORMACIÓN, PARA VER COMO FUNCIONA TODO CORRECTAMENTE PUEDEN VISITAR LA FUENTE.
Fuente: http://www.lachisterablanca.com/2013/06/bypass-del-filtro-xss-de-chrome-con.html

JQuery Validation: Un bug XSS en la demo de validación

Publicado por Unknown en 9:22 Etiquetas: , 0 comentarios
JQuery Validation es un plugin que permite validar el contenido de los formularios. Para que la gente aprenda a utilizarlos, las librerías se distribuyen con un conjunto de pequeñas pruebas de concepto que enseñan a utilizar las diferentes opciones de validación. Pues bien, si no parcheas JQuery Validation o eliminas esas demos, estás poniendo en riesgo la seguridad de tu plataforma, ya que tiene un XSS reflejado en una de ellas, tal y como se puede ver en la este artículo.
Figura 1: Elimina el XSS de la demo de JQuery Validation
Las demos de las librerías se encuentran dentro de una carpeta llamada demo de la ruta de instalación de JQuery Validation. Es fácil localizar sitios en Internet con este componente, ya que la ruta de la web suele ser jquery-validation más la versión concreta de las librerías.
Figura 2: Demos en una instalación de JQuery Validation
Dentro de esas demos, hay unas para validación por AJAX de los valores del captcha que puedes encontrar dentro de la ruta %jquery-validation-path%/demo/captcha/index.php. Al invocar esa URL en un sitio con las demos del componetne activadas aparecerá este pequeño formulario.
Figura 3: Demo de validación de Captcha por AJAX en JQuery Validation
Pues bien, el investigador Sijmen Ruwhof ha publicado que en ese fichero exacto hay un bug de XSS reflejado que hace años que no querían arreglar en el proyecto, pero por suerte, después del ruido generado con su publicación han arreglado. El bug se encuentra en la generación de un enlace que utiliza la ruta que del fichero.
Figura 4: Código vulnerable en la demo
Un atacante puede inyectar algo tan sencillo como cerrar el hipervínculo y abrir una sección de código Script para lanzar cualquier código.
Figura 5: En amarillo la inyección necesaria en el exploit

Cuando se crea el enlace en la respuesta se ejecuta el Script al quedar el código como sigue.
Figura 6: Código resultante con ejecución de script
Al final, el tener los ficheros de demo publicados en una web en producción es el fallo de seguridad en sí, y deberías simplemente quitarlos. Si no lo quitas, puedes actualizar el componente que el desarrollador del plugin JQuery Validation ya lo ha arreglado. Él no fue quién introdujo el bug, sino el creador de la demostración pero si tienes este fichero sin parchear alguien podría hacer un ataque de hijacking para robar las cookies de la sesión de usuario.
Figura 7: Explotación de bug de XSS Reflejado en demo de JQuery Validation
Por supuesto, si las cookies de sesión de tu web están bien definidas con valores HTTP-Only, Secure, con la zona de aplicación restringida a los directorios concretos y no para todo el sitio, si tienes correctamente forzado el uso de filtros Anti-XSS en las variables de X-XSS-Protection y/o has configurado unas Content Security Policies para evitar la inserción en medio del código de comandos Script, entonces el impacto sería menor. En cualquier caso, tengas el framework que tengas, si usas JQuery Validation mi recomendación es que actualices a la última versión y luego quites todas las demos.
 
Gran entrada del maligno.
 
Fuente: http://www.elladodelmal.com/2014/11/jquery-validation-un-bug-xss-en-la-demo.html

XSS con Double URL Encode

Publicado por Unknown en 19:54 domingo, 9 de noviembre de 2014 Etiquetas: , 0 comentarios
Este resumen no está disponible. Haz clic en este enlace para ver la entrada.

Cross Site Scripting (XSS) y Vectores de Evasion

Publicado por Unknown en 13:05 viernes, 1 de agosto de 2014 Etiquetas: , 0 comentarios

Cross Site Scripting (XSS) y Vectores de Evasion

Bueno Antes que Nada este es solo un modelo de las posibilidades que brinda esta vulnerabilidad
recomiendo utilizar Firefox ya que Chrome tiene un bloqueo de Pop-up que nos va a impedir explotar comodamente el fallo


A tener en Cuenta:

Existe 2 tipos de XSS (Cross Site Scripting) ambos se basan en la ejecucion de codigo JavaScript sin que el ClientSide este pendiente de que esto va a suceder.


Reflected:

Son Aquellos producidos por un reflejo del Vector ingresado en el codigo html, por ej: Impresion de la Busqueda en una Web


Stored:

Son Aquellos Cuyo Vector ingresado queda registrado y/o impreso directamente en el contenido html de la Web Afectada.

Un Ej de esto seria un comentario de Moderacion que se guarda en una base de datos de gestion web por un Panel de Administracion, para darle el visto bueno.

Al Ingresar por ej un Script del tipo no lo veriamos ejecutarce porq este esta pendiente de moderacion,
el Administrador al Ingresar al Panel de Moderacion este comentario se ejecutaria al momento de Moderar el Comentario. (Situacion Ideal)

Esto se puede utilizar para robar Cookies para luego lograr logearnos como ese Usuario.


Desarrollo:
En Fin Ambos Ataques se diferencian unicamente en el alcanse que poseen, XSS Reflected requiere un poco de ingenieria social para lograr nuestro Objetico

Hoy Vamos a Tomar como ejempo a http://www.napsix.com/ que posee un fallo de XSS Reflected que reportado numerosas veces sin tener respuestas ni ver Correccion del Bug.


Comencemos:

Abrimos en Nuestro Navegador http://www.napsix.com/ y vemos un flamante campo de Busqueda, interesado en ver que sucede ingreso un Vector de Busqueda.

Vector de Busqueda: >AQUI<

Inspeccionamos Elementos con Chrome y buscamos dentro del Codigo html la palabra AQUI




Vemos que no produce ningun tipo de Evacion ni Filtrado ante los caracteres ">" ni "<" esto da pie a pensar que vulnerable sin siquiera tener
que evadir con Double Encode.


Analicemos:



lo que intentaremos lograr es sacar nuestro Vector de Ataque fuera del input, como podemos ver la propiedad Value abre y cierra con doble comilla
intentaremos cerrar value, luego cerrar el input, injectar el vector y comentar el resto del codigo html


Escapando de la propiedad Value:

Para lograr esto en nuestro vector inyectaremos unas comillas dobles (")

esto quedara de la siguiente manera:



como podemos ver queda por demas al final de la etiqueta un " antes del cierre >


Escapando del Input:

Ahora escaparemos del input, la logica de lo que vemos dice q se cierra con un ">" pero con un conocimiento minimo de html sabremos que las etiquetas input se cierran con /> aunque el inspector de Elementos de Chrome diga lo contrario.

Inyectaremos como Vector ("/>)

y nos quedara de la siguiente manera:

(">)

Como vemos queda de mas al final de nuestro input "> esto producira un error de sintaxis por lo que deseamos eliminar esto ultimo
y lo vamos a lograr comentando el resto del codigo html

Por lo que agregaremos un

NOTA: revisar la fuente porque blogger daña los códigos.

Fuente: http://hdbreaker96.blogspot.com/2013/04/cross-site-scripting-xss-y-vectores-de.html

[Xss Shell] Video + Tutorial

Publicado por Unknown en 13:24 martes, 29 de julio de 2014 Etiquetas: , 0 comentarios
XSS Shell es un poderoso backdoor XSS que permite obtener de forma interactiva el control de un cross-site scripting (XSS) en una aplicación web. Demuestra el poder real y el daño de los ataques de cross-site scripting.

QUE ES UNA SHELL XSS?

XSS Shell es un potente backdoor XSS y un administrador de zombis. Este concepto fue presentado primero por XSS-proxy (http://xss-proxy.sourceforge.net/). Normalmente, en ataques XSS el atacante tiene una oportunidad, en forma interactiva XSS Shell puede enviar peticiones y obtener respuestas de la víctima, tu puedes poner el backdoor en la página.

Puedes robar la autentificación básica, puedes saltarse restricciones de IP en los paneles de administración, puedes realizar un DDoS en algunos sistemas con una vulnerabilidad XSS permanente, etc... posibilidades de ataque son ilimitados con buenas ideas. Básicamente esta herramienta demuestra que se puede hacer más cosas con XSS.

CARACTERISTICAS

XSS Shell tiene varias características para tener acceso a toda víctima. También puede simplemente añadir sus propios comandos.

La mayoría de las características se pueden habilitar o deshabilitar desde la configuración o pueden ser ajustado desde el código fuente.

Características:


  • Páginas de regeneración
  • Keylogger
  • Mouse Logger (click points + DOM actual)

Incorporado en los comandos:


  • Obtener datos con Keylogger.
  • Obtener la página actual (obtener DOM actual / como una captura de pantalla).
  • Obtener Cookie.
  • Ejecutar JavaScript suministrado (eval).
  • Obtener Portapapeles (sólo para IE).
  • Obtener dirección IP interna (sólo Firefox + JVM ).
  • Revisar las víctimas que visitaron el historial de URL.
  • DDoS.
  • Forzar la caída del navegador de la víctima.


INSTALACIÓN

XSS Shell utiliza ASP + base de datos MS Access como backend, pero puedes simplemente ponerlo en cualquier otra solución de servidor. Sólo tiene que seguir con el protocolo de comunicación simple.

Instalar la interfaz de administración:

  1. Copiar "xssshell" carpeta en su servidor web
  2. Copiar "db" a un lugar seguro (por debajo de la raíz)
  3. Configurar "ruta de acceso base de datos" de "xssshell/db.asp"
  4. Modificar fuertemente codificados la contraseña en db.asp [contraseña por defecto es: w00t] 
  5. Ahora usted puedes tener acceso a la interfaz de administración de algo como http://[YOURHOST]/xssshell/

Configurar XSS Shell para la comunicación:

  1. Abrir xssshell.asp
  2. Elegir la variable "SERVER"  a la carpeta donde se encuentra XSSShell. i.e: "http://[YOURHOST]/xssshell/";
  3. Asegúrese de revisar "ME", "Conexión", "COMMANDS_URL" variables. Si ha cambiado los nombres de archivo, nombres de carpetas o algún tipo de configuración diferente que necesita modificarlos.
Ahora abra su interfaz de administración desde el navegador. Para probarlo, basta con modificar "sample_victim/default.asp" código fuente y reemplazar "http://attacker:81/release/xssshell.js" URL con su propia URL del tipo XSS Shell. Abrir "sample_victim" carpeta en cualquier otro navegador y puede ser subido a otro servidor.
Ahora debería poder ver un zombi en la interfaz de administración. Sólo tiene que escribir algo de texto en el área "parámetros" y haga clic en "alert ()". Usted debe ver un mensaje de alerta en el navegador de la víctima.


Video De Una Xss Shell Funcionando:






Link directo: https://www.youtube.com/watch?v=vgrxDZVApdI

 Descargar XSS Shell v0.3.9:
http://www.portcullis-security.com/tools/free/XSSShell039.zip
o
http://ferruh.mavituna.com/xssshell/download/xssshellv039.zip


Vía: http://0verflow.diosdelared.com/
Fuente: http://www.darknet.org.uk/

Temas Relacionados:
[BeEFYPROXY] Interceptar el trafico WEB (MITM)
[BeEF] Tutorial

Fuente: http://www.blackploit.com/2010/09/xss-shell-video-tutorial.html

XSSF - Cross Site Scripting Framework.

Publicado por Unknown en 6:15 lunes, 28 de abril de 2014 Etiquetas: , , 0 comentarios

Bueno en esta ocasión vengo a compartirles una herramienta que en realidad me parece muy interesante y creo que las personas que les gusta el tema de explotación de vulnerabilidades Cross Site Scripting también les va a fascinar.



El Cross-Site Scripting Framework (XSSF) es una herramienta de seguridad diseñada para convertir la tarea de explotación de vulnerabilidades XSS en un trabajo mucho más fácil. El proyecto XSSF pretende demostrar los grandes peligros reales de las vulnerabilidades XSS.

 XSSF permite la creación de un canal de comunicación con el navegador específica (de una vulnerabilidad XSS) con el fin de realizar nuevos ataques. Los usuarios son libres de seleccionar los módulos existentes (un módulo = un ataque) con el fin de orientar los navegadores específicos.


Nota :  Este proyecto es creado exclusivamente para la educación, pruebas de penetración y con fines de investigación legítimos.


XSSF proporciona una API muy bien documentada, lo que facilita el desarrollo de módulos y ataques. Además, su integración en el Metasploit Framework permite a los usuarios tener una mejor perspectivo de los crítico que puede llegar a ser una vulnerabilidad Cross Site Scripting.

La  explotación de un fallo XSS dentro del navegador de la víctima podría ser la de mirar la página web en el navegador del atacante, utilizando la sesión de la víctima conectada. En la mayoría de los casos, simplemente robar la cookie víctima será suficiente para realizar esta acción. 

Sin embargo, en pocos casos (intranet, red Herramientas portales, etc), la cookie no será útil para un atacante externo. Es por eso que XSSF túnnel fue creado para ayudar al atacante a ayudar a la navegación atacante en dominio afectado utilizando la sesión de la víctima.
Instalación y Ejeucicón en Metasploit.
Procedemos con abrir una consola y vamos a iniciar con una actualización de los repositorios de metasploit.


A continuación nos vamos a dirigir a una carpeta especifica.
En la siguiente linea vamos a exportar la herramienta a nuestro repositorio de metasploit para su posterior uso.
Después de terminar la exportación, vamos a cerrar la consola (si gustamos), y procedemos a abrir nuestro metasploit.
Una vez que dispongamos de nuestro metasploit vamos a cargar nuestra herramienta con la siguiente linea.
Y listo ya podemos disponer de todas las cualidades de nuestra herramienta XSSF.





Para poder observar todas las opciones que nos proporciona XSSF, procedemos a introducir help xssf.



=====================
Descripción de Comandos.
=====================


    xssf_active_victims                 Muestra víctimas activas.
    xssf_add_auto_attack             Añade un nuevo ataque automatizado (lanzado de forma automática en la conexión de la víctima).
    xssf_auto_attacks                   Muestra XSSF ataques automatizados.
    xssf_banner Prints                  Marco XSS bandera !
    xssf_clean_victims                  Limpia víctimas en la base de datos ( eliminar ataques de espera).
    xssf_exploit                             Lanza e introduce un módulo (que se ejecuta en uno de sus procesos ) en una víctima determinada.
    xssf_information                     Muestra información sobre una víctima determinada.
    Muestra xssf_log                   registro con un ID dado.
    xssf_logs                                 Muestra los registros sobre una víctima determinada.
    xssf_remove_auto_attack     Elimina un ataque automatizado.
    xssf_remove_victims             Elimina las víctimas en la base de datos.
    xssf_restore_state                 Restaura el estado XSSF (víctimas , registros , etc) a partir del archivo de entrada.
    xssf_save_state                     Guarda estatales XSSF (víctimas , registros , etc) en el archivo de salida.
    xssf_servers                          Muestra todos los servidores de ataque utilizados.
    xssf_tunnel                            Nos proporciona un túnel entre agresor y víctima.
    xssf_urls                                 Enumera las direcciones URL's disponibles útiles proporcionadas por XSSF.
    xssf_victims                           Muestra todas las víctimas




 A continuación les compartiré un video en la cual se puede observar detalladamente los grandes riesgos que conlleva la explotación de vulnerabilidades Cross Site Scripting.





Ante todo quiero agradecer a Code.google por haberme podido brindar toda la información acerca de esta valiosa herramienta. Bueno espero que esta poca información les sea de gran utilidad al lector y les de una nueva visión acerca de las vulnerabilidades XSS. Nos vemos y será hasta la próxima.

Fuente: http://antisec-security.blogspot.com/2014/04/xssf-cross-site-scripting-framework.html

Cross-site scripting - XSS

Publicado por Unknown en 13:51 viernes, 27 de diciembre de 2013 Etiquetas: , , 0 comentarios


Cross-site scripting Es un error típico de algunas paginas web ya que crea otro portal donde la web es afectada por una explotación " XSS" puede ser modificado en otro plano de web  por medio de script
peligrosos en Html.

Existen dos tipos de XSS

Directa - ( llamada también persistente) Es un tipo de xss que permite insertar los codigos html que permitan insertar "

XSS a travez de ERROR!

Publicado por Unknown en 19:37 martes, 13 de noviembre de 2012 Etiquetas: , , 0 comentarios
null
No todos los errores del tipo mysql, mssql, postgresql, sqlite3, funciones como include(), main(), require(), require_once() , errores en scripts VBscripts, etc, tienen que ser suceptibles a rfi, lfi, sqli, etc. Hay ciertas ocaciones en que este tipo de mensajes no pueden ser aprovechados de manera satisfactoria, pero a travez del error se podria inyectar codigo javascript en el index.

Miremos un ejemplo de una web que al parecer es vulnerable a sqli.
Como podemos divisar en el mensaje que nos devuelve la DB salta la cadena que acabo de inyectar en el parametro vulnerable.
Probemos a ver si logramos ponerla en negrita
Efectivamente inyectamos codigo html, a ver que pasa con un alert?.
bien, vemos en que otro tipo de error podemos incrustar un XSS.
En la siguiente web tenemos una posible lfi.
Probemos nuevamente de meter un alert donde se alla la cadena que nos devuelve el error.
Como vemos todo error por parte del servidor que nos devuelva la cadena que introducimos en el parametro puede ser aprovechado para inyectar de manera reflejada un XSS, con o sin evasivas! ojala les haya servido!
Bytes!

Fuente:http://underterminal.nixiweb.com
Suscribirse a: Entradas (Atom)
Powered by Bad Robot
Helped by Blackubay