Mostrando entradas con la etiqueta Análisis de Vulnerabilidades. Mostrar todas las entradas
Mostrando entradas con la etiqueta Análisis de Vulnerabilidades. Mostrar todas las entradas

lunes, 22 de agosto de 2016

Los labs de gf0s

- Reto  GF0S -


Buenas Pentesters: 

Desde fwhibbit os dejamos la guía de la manera en que nosotros hemos realizado el reto CTF que nos ha brindado la oportunidad de hacer a nosotros y gran parte de este mundillo el Admin de  https://gf0s.com/ y desde aquí le felicitamos por esta labor desinteresada y poder practicar online.

Solamente decir que para los que nos estamos iniciando es una muy buena opción y encima en español.



Aquí os dejamos la Guía escrita para que la consultéis por si os quedáis atascados.

Aquí os dejamos la Guía en vídeo realizada por Naivenom.

 

lunes, 25 de julio de 2016

PoC: Evitando filtros anti-XSS

Buenas compañeros,

Esta entrada se va a centrar en cómo evitar filtros para evitar ataques XSS (Cross Site Scripting).

Para ello, se va a tomar como plataforma de pruebas DVWA, ya sabéis para no meterse en líos

Como ya sabéis para instalar DVWA, os montáis la máquina virtual y le metéis la iso de DVWA (https://github.com/nightmare-rg/dvwa-vagrant/tree/master/dvwa-1.0.8)

Vamos a ello!

Seleccionando la opción de XSS reflected y ajustando el nivel de dificultad, tenemos todo listo para empezar:

Nivel low

En el nivel "low" el servidor web no aplica ningún tipo de validación de los parámetros de entrada por lo que introduciendo la típica cadena

<script>alert("XSS")</script> 

visualizamos el alert verificando que es vulnerable.




Una vez que se ha visto que es vulnerable, se examina el código que como se dedujo, no existe ningún mecanismo de validación de entrada:






Recomendaciones:

Para evitar todo tipo de inyección nunca se debe confiar de datos o fuentes externas y validar todo sin suponer nada, por ejemplo, que los datos esperados son los que el usuario va a introducir.

Para ello, se debe validar todos los datos de entrada, escapar o filtrar los datos no permitidos y opcionalmente sanearlos. Sin embargo, el saneamiento de datos es opcional puesto si la aplicación recibe datos que no debería podría rechazarlos y enviar un mensaje de error para que el usuario los introduzca correctamente para ser aceptados.

En este caso, en PHP se tiene una función para filtrar etiquetas no permitidas como /, <, </, script,…. Esta función es script_tags

Otra función útil para escapar los datos de entrada  antes de ser mostrados cuando el código de entrada esperado es HTML es htmlspecialchars.

Del mismo modo, se debería emplear la función trim que elimina caracteres especiales de inicio o final de la cadena sustituyéndolo por espacios en blanco. Por ejemplo, elimina \t\n\r\0/


Nivel medium

Introduciendo el mismo código, ya no se ejecuta, por lo tanto, se puede deducir que se están aplicando mecanismos de validación de los parámetros de entrada.

Por lo tanto, para detectar que keywords está se realiza una batería de pruebas para identificar los posibles parámetros "prohibidos" para de esta manera, poder evitarlos.


Entrada
Salida
script Hello script
<script>
hello
script> Hello script> -- Este es bueno!
<script
hello
<<script>> Hello <> -- Filtra keyword script


Como se observa está filtrando el keyworsd "<script>". Sin embargo, sabiendo que:


<<script>    devuelve    <
    script>       devuelve    <


Ya tenemos la formula de evitar el filtro:


<<script>script>alert("XSS medium")</script>




Análogamente a la reconstrucción del tag de script en función del filtrado, se podría incluir construir el tag de script en partes:

<scr>script>ipt>alert(“XSS DVWA”);</script>






Del mismo modo, a la reconstrucción del tag de script en función del filtrado, se podría incluir espacios en blanco en los < > para saltarse la restricción y ver si el servidor interpreta dicho código y lo ejecuta.

<<script>script>alert(“XSS medium”);</script >




De ahí el fallo que reemplaza justamente esa palabra exacta. Por lo tanto, introduciendo el código:

<script type="text/javascript">alert("XSS medium")</script>
No detecta la cadena <script> exacta y se lo “traga”





Otro intento típico es emplear los tag de script en mayúsculas para verificar si el servidor realiza algún tipo de saneamiento, esto es, una conversión de lso valores introducidos ya sean mayúsculas o minúsculas para su posterior tratamiento y gestión:


<SCRIPT>alert("XSS medium");</SCRIPT>




Una vez vulnerado se mira el código fuente para ver que función emplean para determinar cómo se podría mejorar. 




Observando el código fuente, se aprecia que se está empleando la función str_replace para reemplazar la keyword “<script>” por un espacio en blanco.

Adicionalmente, es más que recomendable revisar el documento de OWASP para explotar XSS (https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet).

Espero que os haya gustado :D

Para cualquier cosa, escribir un comentario y estaré encantado de responder.

Saludos.

NaxHack5

"La mejor defensa es un buen ataque"

domingo, 28 de febrero de 2016

Escaneando like a Sir

Prueba de concepto realizada por @ShargonXL (Twitter)

La POC de hoy es bastante sencillita, y trata de como pasar un Acunetix, en sitios que lo bloquean, o de forma que no se detecte (al menos de forma fácil)

Acunetix envia las siguientes cabeceras de forma automática, ya que ha de hacerse de manera profesional y avisando al cliente.

Versión 8.0 (con la que se realiza esta POC)



 
En la versión 9 envía unas mas como Acunetix-Product , creo recordar.
Según este post, envía también estas, no ha sido mi caso, pero lo suyo es que revisaras primero que cabeceras envía tu versión para poder continuar, y hacerlo a sabiendas, ya que pueden variar.


 Para protegerse, BlueTeam, tan sólo bastaría estas lineas de código php.



Estarías protegido de un ataque (escaneo ejem ejem) normal por acunetix. 
O no? Pues bien, vamos a ponerlo algo mas complicado al BlueTeam
Pues muy sencillo ahora vamos al Acunetix.



y le establecemos un proxy local al puerto que más rabia te de (y no esté en uso).



Abrimos el Fiddler (http://www.telerik.com/fiddler) (i love fiddler) y lo configuramos de forma que escuche peticiones a ese puerto.




Ahora todas las peticiones del Acunetix pasan por nuestro proxy. Le establecemos filtros de borrado de cabeceras.


Y ya puedes escanear, que ¡no será visto! (al menos no enviara dichas cabeceras) :)


Y eso es todo amigos!! 



P.D El autor no se hace responsable del mal uso que se le de a esta PoC, usen siempre estos conocimientos de forma ética y con consentimiento del cliente. 





Google Analytics