.

.
Mostrando entradas con la etiqueta aplicaciones web. Mostrar todas las entradas
Mostrando entradas con la etiqueta aplicaciones web. Mostrar todas las entradas

martes, 20 de agosto de 2019

Entendiendo el Cross Site Scripting (XSS) - Parte 2/2


Después de introducirnos en el XSS en la entrada anterior, en entender como se produce, que tipos podemos encontrar y como tratar de evitarlo, en este artículo veremos diferentes tipos de inyección de XSS, herramientas que podemos utilizar y algunos link de referencia.

HERRAMIENTAS:

Dentro del mundo XSS, encontraremos diversas herramientas que ayudaran en diferentes funciones, ya sea desde la detección, hasta la explotación de las mismas. Ahora simplemente nombraré algunas de ellas, pero os animo a que tiréis de buscador y probéis otras diferentes opciones:

  • Xenotix:
OWASP Xenotix XSS Exploit Framework es un marco avanzado de detección y explotación de vulnerabilidades Cross Site Scripting (XSS). Proporciona resultados de escaneo de cero falsos positivos con su exclusivo escáner integrado de Triple Browser Engine (Trident, WebKit y Gecko). Se afirma que tiene la segunda mayor carga útil XSS del mundo de más de 1500 cargas útiles XSS distintivas para la detección efectiva de vulnerabilidades XSS y el desvío WAF. Se incorpora con un módulo de recopilación de información rico en funciones para el reconocimiento de objetivos. El Exploit Framework incluye módulos de explotación XSS altamente ofensivos para pruebas de penetración y creación de prueba de concepto.
La encontramos para sistemas operativos Windows y como característica especial podemos afirmar que produce muy pocos falsos positivos.


Página oficial OWASP: https://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework

https://github.com/ajinabraham/OWASP-Xenotix-XSS-Exploit-Framework#owasp-xenotix-xss-exploit-framework

  • BeEF:

Browser Exploitation Framework. Es una herramienta de prueba de penetración que se centra en el navegador web.
BeEF permite al pentester evaluar la seguridad real de un entorno objetivo mediante el uso de vectores de ataque del lado del cliente. 

Podemos encontrar esta herramienta instalada por defecto en Kali Linux.



  • BruteXSS:


BruteXSS es una herramienta muy potente y rápida, que se utiliza para forzar parámetros por medio de fuerza bruta. El BruteXSS inyecta múltiples cargas útiles que obtiene de una lista de palabras específica y las ejecuta sobre los parámetros indicados, escaneando si alguno de los parámetros es vulnerable a la vulnerabilidad XSS. 


  1. Soporta peticiones GET y POST.
  2. Fuerza bruta de parámetros XSS.
  3. Escaneo vulnerabilidades XSS.
  4. Se puede incluir una lista de palabras personalizada
  5. Interfaz de usuario amigable.
https://github.com/shawarkhanethicalhacker/BruteXSS-1


  • XSSer:
Cross Site "Scripter" es un marco automático para detectar, explotar y reportar vulnerabilidades XSS en aplicaciones basadas en la web.

  1. Viene instalada por defecto en Kali Linux.
  2. Soporta peticiones GET y POST.
  3. Permite diferentes tipos de inyecciones (XST, XSS, XSA, XSR, DOM, DCP, Induced...).

https://sourceforge.net/projects/xsser/


EJEMPLOS DE INYECCIONES: 

Algunos de los ejemplos de inyección que se pueden realizar en una aplicación web vulnerable a XSS:

<script>alert('XSS');</script> (Alert)
<script>prompt('XSS')</script> (Para sacar un prompt)
<svg onload=prompt('XSS')> (Para sacar un prompt)
<script>alert(document.cookie)</script> (Para sacar cookie de sesión)
<script>alert(document.domain)</script> (Para sacar la IP de la WEB)
<script>for(;;)alert("bucle");</script> (Denegación de servicio)
<img src=foo.png onerror=alert(/XSS/) /> (Inyección en objeto IMG de HTML)
<BODY onload=alert("XSS")> (Inyectando objeto BODY de HTML)


REFERENCIAS: 


miércoles, 14 de agosto de 2019

Entendiendo el Cross Site Scripting (XSS) - Parte 1/2


El XSS o “Cross-site Scripting”, es una de las vulnerabilidades que siempre se encuentran, en el TOP 10 de las más explotadas en cuanto a lo que aplicaciones web se refiere. *(Puesto número 3 en el TOP10 de OWASP).

Esta vulnerabilidad, permite a un atacante la ejecución de código del lado del cliente (navegador), siempre y cuando la aplicación web sea vulnerable a XSS.


A rasgos generales: se aprovecha de la validación incorrecta en los campos de entrada de datos de la aplicación (Ej: Formularios).

Permite la inyección de código JavaScript y similares, que además es interpretado por el servidor y por consiguiente, altera el normal funcionamiento de la aplicación.

En caso de que el ataque tenga éxito, permitirá a los atacantes robar contraseñas y otra información sensible, redirigir a los usuarios a web maliciosas, robar sesiones de usuario, suplantar identidad del usuario atacado, entre otras.


La explotación de un XSS puede causar: 
  • Redirección a sitios no legítimos (páginas falsas), con la intención de engañar a la víctima.
  • Secuestro de sesión de las cuentas de las víctimas, para escalar privilegios y acceder a los sistemas.
  • Instalación de malware en el sistema victima.
  • Ejecución de exploits en el servidor.
  • Provocar un mal funcionamiento de los sistemas vulnerados.
  • Denegación de Servicio (DoS).

Ejemplo básico de XSS:

XSS funciona debido a que no se validan los datos que se publican desde un campo de entrada, lo que provoca que en cualquier secuencia de comandos en el campo de entrada, con ciertas características pueda aprovechar dichas vulnerabilidades.

De esta manera, por ejemplo, un atacante podría acceder a una web vulnerable a XSS y a través de su formulario de contacto, podría preparar un ataque en el cual inyectara código en alguno de los campos de dicho formulario


Todo empieza, por ejemplo, con una página que permita insertar comentarios o contenido, por parte de los usuarios. Esto puede producirse en cualquier tipo de formulario, comentarios de contenido, etc.

Si en cualquiera de estos cuadros de texto, un atacante, en vez de introducir los datos que pida el formulario, introdujera: <script>alert('Comentario')</script>, (lenguaje en JavaScript) y al enviar saltara un pop-up, nos encontraríamos ante una aplicación vulnerable a XSS. 


Tipos de XSS:

Hay que tener en cuenta, que este tipo de vulnerabilidad puede ser darse de diferentes formas:
  • XSS Reflejado.
  • XSS Almacenado.
  • XSS Basado en DOM.

A continuación, haré una breve explicación de cada una:

  • XSS Reflejado: También conocido como indirecto o no persistente, es el más habitual de los XSS. Es temporal, ya que solo se ejecuta al enviar la petición una vez a nivel navegador. Bastante común en páginas web dinámicas y aplicaciones de correo. Las posibles consecuencias: Robo de cookies, secuestro de navegador, phising, cambio del contenido y estructura de la aplicación web, instalación de software malicioso en el sistema. 
  • Almacenado: También conocido como directo o persistente, perdura en el servidor, ya que al ejecutarlo por primera vez se almacena en la base de datos de la aplicación web. Cada vez que se cargue la página web, se ejecutará nuevamente y se mostrará la inyección a los usuarios de la misma. Las posibles consecuencias: Además de las indicadas en el XSS Reflejado, captura de información de las aplicaciones, defacement de app, escaneo de puertos de las víctimas, ejecución de exploits, denegación de servicio. 
  • Basado en DOM: Es un XSS local y persistente, que esta basado en modificar el entorno DOM* del navegador, debido a su mal uso. Este tipo de XSS se ejecuta del lado del cliente, afecta a páginas estáticas, siendo un ejemplo de elementos vulnerables: document.location / document.URL / etc. Las consecuencias son similares a las presentes en los XSS reflejado y almacenado. *(Para los que no estén al día sobre DOM, nos referimos al Modelo de Objetos del Documento (DOM), el cual es una interfaz de programación de aplicaciones (API) para documentos validos HTML. Define la estructura lógica de los documentos y el modo en que se accede y manipulan).

¿Como identificar XSS?:

Para identificar una vulnerabilidad de "cross site" en primera instancia, debemos de pensar en algunas de las causas que producen que esta vulnerabilidad este presente en una aplicación web, como son un mal filtrado de datos o no validación de entradas de datos en la aplicación (permite la introducción de todo tipo de valores, aunque no sea necesario).

Para ello, en apartados de la web destinados a la entrada de datos, como son formularios, paneles de acceso e identificación de usuarios, etc., se puede probar la introducción de comandos, como: <script>alert('XSS')</script>.

También se puede probar simplemente si la aplicación valida en estos campos de entrada, la introducción de caracteres especiales, como: /, < >, ".

Para asegurar del todo, que no se puedan ejecutar script en estos campos de entrada de datos, no deberían de permitirse la introducción de ciertos tipos de palabras, como: script, alert, src, etc.


¿Contramedidas?:

De la mano del punto anterior, vendrían las contramedidas y aspectos a tener en cuenta para evitar ser vulnerables a XSS, ya que los puntos que identifican un XSS son los que se deben evitar.
Para ello, se deben de tomar algunas como las siguientes medidas:


  • Validación de datos (en todos los campos de entrada, tanto del lado del cliente como del servidor). Solo se permitirán valores esperados y adecuados a lo que se está pidiendo (formato, longitud, etc.). Por ejemplo, no tiene sentido que en un campo de un formulario, en el que se esta pidiendo el nombre o apellido de una persona, se puedan introducir números o caracteres.
  • Sanitización de datos en los campos de entrada (Solo se permitirá texto plano, a nivel de que no se interprete o ejecute ningún tipo de comando).
  • Creación de listas (blancas y negras) para restringir los datos esperados. De esta manera, palabras como "script", estarán totalmente prohibidas y no serán aceptadas.
  • Evitar que el sistema ejecute código, al menos el proveniente de sitios concretos, como formularios. 
  • Hacer que las cadenas de entrada de datos, se conviertan en alfanuméricas, al igual que los datos introducidos por los usuarios se conviertan a sus equivalentes en HTML.
Todas estas medidas pueden tomarse desde el lado del servidor.

Hasta ahora hemos hablado de las medidas a tomar desde el lado del servidor, a la hora de securizar la aplicación, si queremos mantenernos seguros si nos encontramos en el lado del usuario, algunas de las cosas que tenemos que observar son las siguientes:


  • Como siempre y como una de las normas fundamentales en cuanto a mantener la seguridad al máximo se refiere, es primordial tener actualizado a la versión más actual todo el software del equipo: aplicaciones, sistema operativo, navegadores, etc.
  • Ante todo ser conscientes de lo que hacemos y de como navegamos, ojo con enlaces sospechosos, urls acortadas, links que no sabemos donde nos redirigen, etc.
  • Algo muy importante y que en una primera instancia no encontramos entre los consejos habituales, es que debemos de ser muy conscientes del estado de nuestro navegador, como lo tenemos configurado, etc. Por ejemplo, debemos de tener mucho cuidado con que complementos tenemos instalados y evitar o al menos controlar los que permitan la ejecución de scripts de manera automática.




  • Aunque parece evidente, siempre hay que nombrar que tener una solución de seguridad instalada en el equipo, que evite la ejecución de malware, siempre será un punto a nuestro favor.


martes, 20 de noviembre de 2018

Dirsearch - Fuerza bruta a directorios


Dirsearch es un escáner de directorios para aplicaciones web (diseñado en Python), que ayudara a un hacker ético a búscar información de un sitio web, haciendo fuerza bruta sobre la estructura del mismo (directorios y archivos).

Dirsearch es una sustituta perfecta a la herramienta DirBuster de OWASP, ya que cumple la misma función.

Es compatible con sistemas operativos Linux, Windows y macOS.


La herramienta puede descargarse desde:
https://github.com/maurosoria/dirsearch

Es importante tener en cuenta que la herramienta está desarrollada en Python, por lo que es indispensable tener instalado Python 3 en el equipo:
https://www.python.org/downloads/

Como se ha comentado, dirsearch emplea fuerza bruta, para lo que utiliza por defecto una base de datos incluida, con más de 6600 palabras.
Además de esto y como en todas las herramientas que utilizan fuerza bruta, se pueden utilizar diccionarios prediseñados, por nosotros mismos u otros y el éxito dependerá en parte en las dimensiones y la calidad de los mismos.

Algunas de las características y funcionalidades de Dirbuster son:
  • Permite la configuración de múltiples extensiones de archivos (.php, .html, .asp, etc).
  • Genera reportes en formato JSON o en texto plano.
  • Reconoce automáticamente páginas inválidas y falsos positivos.
  • Uso aleatorio de varios User-Agent para evitar bloqueos.
  • Soporte para proxy HTTP.
  • Retraso entre peticiones para evadir bloqueos y sistemas de seguridad.

Comando base:

# python3 disearch.py -u (url) -e (target extensions)

  • Opciones:
  -h, --help            show this help message and exit

  Mandatory:
    -u URL, --url=URL   URL target
    -L URLLIST, --url-list=URLLIST
                        URL list target
    -e EXTENSIONS, --extensions=EXTENSIONS
                        Extension list separated by comma (Example: php,asp)


  Dictionary Settings:
    -w WORDLIST, --wordlist=WORDLIST
    -l, --lowercase    
    -f, --force-extensions
                        Force extensions for every wordlist entry (like in
                        DirBuster)


General Settings:
    -s DELAY, --delay=DELAY
                        Delay between requests (float number)
    -r, --recursive     Bruteforce recursively
    --suppress-empty, --suppress-empty
    --scan-subdir=SCANSUBDIRS, --scan-subdirs=SCANSUBDIRS
                        Scan subdirectories of the given -u|--url (separated
                        by comma)
    --exclude-subdir=EXCLUDESUBDIRS, --exclude-subdirs=EXCLUDESUBDIRS
                        Exclude the following subdirectories during recursive
                        scan (separated by comma)
    -t THREADSCOUNT, --threads=THREADSCOUNT
                        Number of Threads
    -x EXCLUDESTATUSCODES, --exclude-status=EXCLUDESTATUSCODES
                        Exclude status code, separated by comma (example: 301,
                        500)
    -c COOKIE, --cookie=COOKIE
    --ua=USERAGENT, --user-agent=USERAGENT
    -F, --follow-redirects
    -H HEADERS, --header=HEADERS
                        Headers to add (example: --header "Referer:
                        example.com" --header "User-Agent: IE"
    --random-agents, --random-user-agents


  Connection Settings:
    --timeout=TIMEOUT   Connection timeout
    --ip=IP             Resolve name to IP address
    --proxy=HTTPPROXY, --http-proxy=HTTPPROXY
                        Http Proxy (example: localhost:8080
    --max-retries=MAXRETRIES
    -b, --request-by-hostname
                        By default dirsearch will request by IP for speed.
                        This forces requests by hostname


  Reports:
    --simple-report=SIMPLEOUTPUTFILE
                        Only found paths
    --plain-text-report=PLAINTEXTOUTPUTFILE
                        Found paths with status codes
    --json-report=JSONOUTPUTFILE





# python3 dirsearch.py -u https://k-oox.blogspot.com/ -e txt,php,html -x 404

( -u = URL Target / -e = Extensiones / -x = Estados excluidos )







Tras finalizar el escaneo, se generará de manera automática un archivo del escaneo realizado, en la carpeta "reports, archivado y ordenado por target y fecha.

Se puede abrir con cualquier editor de texto.



lunes, 20 de junio de 2016

Auditando con OWASP ZAP en OS X


Dentro del análisis de aplicaciones web, la entrada de hoy está dedicada a OWASP ZAP (Zed Attack Proxy), una de las herramientas más potentes del proyecto OWASP.

Aunque el apunte de "...con OS X" en el título de la entrada realmente es irrelevante, ya que la herramienta a utilizar "OWASP ZAP" es igual en todas las plataformas, va dirigido a todos aquellos puristas y defensores de otras plataformas y en la línea de anteriores entradas, recordando de que con OS X o macOS Sierra (próximamente), se puede hacer exactamente hacking con todas las posibilidades.

OWASP ZAP, está disponible para multiples plataformas en (compatible incluso con Raspberry Pi):
Descarga: https://github.com/zaproxy/zaproxy/wiki/Downloads



Para Mac, se descarga un formato .dmg que gracias a la tecnología Mac ni si quiera hay que pasar un proceso de instalación, ya que tras abrirlo no tendremos más que arrastrar el icono de ZAP a la carpeta Aplicaciones.


 Es una herramienta con unas características y/o funciones muy parecidas a Burpsuite. Algunas de ellas:
  • Análisis de peticiones cliente/servidor.
  • Localización de recursos.
  • Análisis varios (Automáticos, pasivos, de sistemas de autenticación).
  • Posibilidad de lanzar varios ataques a la vez.
  • Uso de SSL dinámicos.
  • Uso de plugins adicionales.
  • Soporte de uso de DNI electrónico, certificados digitales, etc.
  • Configuración de reglas.
Para empezar con escaneo automático de OWASP ZAP, solo tenemos que introducir la URL objetivo que queramos analizar.
En el caso de este escaneo de ejemplo, voy a utilizar unas direcciones que ya hemos visto en anteriores entradas, que la organización de Acunetix nos facilita como webs vulnerables, para realizar las pruebas, pero que en este caso nos sirven para lo que vamos a realizar.

- http://testphp.vulnweb.com
- http://testasp.vulnweb.com
- http://testaspnet.vulnweb.com
- http://testhtml5.vulnweb.com

Yo en mi caso, voy a utilizar - http://testaspnet.vulnweb.com.


Una vez tengamos la URL, damos a iniciar y el proceso empezará a correr y como suele pasar en todo escaneo, la duración será directamente proporcinal a la densidad y complegidad de la web a analizar.



En esta entrada me limitaré a explicar la herramienta y cada uno de sus apartados, para que el usuario tenga una mayor comprensión de ella y en siguientes entradas, pasaremos a realizar acciones de mayor complegidad.

Comovemos en la parte inferior, podemos ver como el proceso de análisis se divide en varios apartados:

Spider (la araña) nos muestra como la herramienta va analizando los diferentes archivos y directorios en busqueda de vulnerabilidades.











En "Escaneo Activo", se pueden ver en proceso directo, todas las peticiones que se van enviando "POST" ...














Si seleccionamos cualquiera de ellas, en la parte superior derecha de la ventana podremos estudiar o analizar, la petición que ha realizado la herramienta y la respuesta recibida por el sistema...




























Algo muy interesante que nos ofrece OWASP ZAP es presenciar en directo el tipo y progreso de ataques que está realizando, dandonos la posibilidad de presenciar pruebas concretas. Esto mediante el "Show scan progress details".

Como vemos en la siguiente captura de pantalla, entre otros:
- Escaneos de directorio transversal.
- Inclusión de archivos.
- XSS.
- Inyecciones.
- Buffer overflow.


Una vez terminado el escaneo vamos a pasar a la parte más importante, ver las vulnerabilidades que se han encontrado en la URL a analizar.
Para ello vamos al botón "Alertas" caracterizado con el icono de una banderita roja o anaranjada.
Aquí vamos a encontrar como en cualquier otro escaner de vulnerabilidades, las encontradas, clasificadas según su gravedad.



En este caso vemos que ZAP ha encontrado dos vulnerabilidades de alto riesgo (caracterizadas en color rojo).  De "Cross-site Scripting" y una de "inyección SQL".
23 de riesgo medio (color naranja) y otras tantas de bajo riesgo (color amarillo).
Si seleccionamos cualquiera de ellas, a la derecha del cuadro podemos ver la descripción completa de la vulnerabilidad, una posible solucción ofrecida por la herramienta y enlaces de referencia por si queremos documentarnos al respecto.

Finalmente, para procesos de auditoría ZAP nos da la posibilidad de guardar un reporte de vulnerabilidades en diferentes formatos.




domingo, 17 de abril de 2016

SQLMAP - Inyecciones automáticas de SQL

Esta tarde le ha tocado el turno de ser testeada a la herramienta "sqlmap".

Sqlmap es una herramienta perfecta para la realización de pruebas de penetración y muy util a la hora de ayudarnos a la hora de estar intentando detectar y explotar errores de inyección de SQL, además de facilitarnos el proceso de acceso a bases de datos. 

Como reza el titular en su web oficial, Sqlmap puede definirse como "la inyección automática de SQL y adquisición de base de datos pública".
En dicha web oficial podemos descargar la herramienta y tener acceso a documentación, etc.:
http://sqlmap.org/

Para probar la herramienta, lo primero que nos hace falta es una web en php y para que podamos ver algo vistoso, en este caso que sea vulnerable.
Sin complicarme la vida busco webs en php antiguas, abandonadas y por consiguiente desactualizadas, todo esto es igual a: Vulnerables.

Tenemos aquí esta web inmobiliaria, que parece no ser actualizada desde 2012 y tiene pinta de muy accesible: http://www.hidalhousing.net/pages/portada.php

Accedo a su pestaña de noticias para encontrar lo que estoy buscando:
http://www.hidalhousing.net/pages/amplianoti.php?id=22

Podemos ver que tiene un id de referencia. Si le añado al final un par de comillas ('')....



"ERROR"
Nos sirve para nuestro cometido por tanto.

Abrimos "Sqlmap". Como he dicho antes lo puedes descargar en: 
http://sqlmap.org/  o si utilizas Kali Linux como haré yo, ahí lo tienes disponible en el apartado de aplicaciones web.


Lo primero es intentar sacar las bases de datos, para si lo conseguimos luego trabajar directamente sobre ellas.
De es esta manera, le indicamos el comando sql y la url sobre la que queremos trabajar.

# sqlmap -u http://www.hidalhousing.net/pages/amplianoti.php?id=22



















Aquí vemos los resultados, obtenemos una serie de bases de datos.

Para este ejemplo voy a utilizar la primera:
Sql103544_1

# sqlmap -u http://www.hidalhousing.net/pages/amplianoti.php?id=22 -D Sql103544_1 --tables

Vamos a introducir el comando anterior, pero esta vez especificamos además de (-D) el nombre de la base de datos conseguida y añadimos (--tables) para que nos consiga las tablas de esta base de datos.


Ya tenemos sacadas las tablas. Como se puede ver a conseguido 96 tablas de la base de datos.
A partir de aquí ya todo es armarse de paciencia e ir buscando de donde podemos ir rebañando datos.

Efectivamente a parte de muchos datos interesante, podemos conseguir algunos concretos que nos faciliten seguir indagando como datos de usuario, que en el mejor de los casos consiguiendo credenciales podremos llegar a logearnos.

La formula seguiría siendo la misma:
( sqlmap -u http://www.hidalhousing.net/pages/amplianoti.php?id=22 -D Sql103544_1 ) en este caso añadiriamos al final la (-T) de tables y el nombre de la tabla en que queremos seguir trabajando de las 96 obtenidas en este caso, más el comando (--columns) . Algo así:

# sqlmap -u http://www.hidalhousing.net/pages/amplianoti.php?id=22 -D Sql103544_1 -T usuarios --columns























Como se puede ver, de la tabla usuarios hemos conseguido:

Clave, id, nombre y permisos.
Ahora podría acceder como este usuario sin problema a esta base de datos.
Y así sucesivamente iremos accediendo a más datos. El caso es que la web a sido totalmente vulnerada.

Con: # sqlmap -u http://www.hidalhousing.net/pages/amplianoti.php?id=22 -D Sql103544_1 --dump


















Con esto me despido por hoy.

Un saludo y happy hacking ;)

viernes, 15 de abril de 2016

Acunetix - Escaner de vulnerabilidades Web

En la entrada de hoy vamos a echar un vistazo a un potente escaner de vulnerabilidades de aplicaciones web "Acunetix".

Al igual que muchas veces utilizamos herramientas más específicas, a la hora de buscar un resultado concreto, con los escáneres de vulnerabilidades, gracias a su compendio de herramientas variadas y especializadas encontramos agujeros de seguridad que desconociamos, en este caso en aplicaciones web.

Es muy importante el uso de estos escáneres con asiduidad periódica, ya que cualquier vulnerabilidad que aparezca puede suponernos un susto y un problema, si es encontrado por algún atacante antes que por nosotros.

Acunetix, al igual que la mayoría de los escáneres de vulnerabilidades, nos ayuda a mejorar la seguridad de nuestro sistema, además de encontrando los puntos débiles (SQL Injection, Cross Site Scripting, desactualizaciones del sistema, passwords débiles, etc.) haciendonos una serie de sugerencias para evitarlas o soluccionarlas.

En su web oficial: http://www.acunetix.com/ , podemos dercargar una versión de prueba (de 14 días), que aunque tiene ciertas limitaciones (por ejemplo no nos genera informes), nos podemos hacer una idea de como funciona y los servicios que ofrece.

Una vez instalado, lo arrancamos ...


De entrada nos mostrará esto:




















Acunetix en un primer momento nos dará como vemos en esta ventana emergente, la opción de bajo una serie de opciones a rellenar, realizar un análisis de forma automática.
























































Si vamos rrellanando los datos que se nos piden, adaptandolos a los parámetros adecuados a nuestra busqueda, comenzará el análisis que hemos programado.

Si queremos configurar el análisis de forma manual, solo tenemos que cancelar esta ventana emergente y proceder a la elección de la herramienta a utilizar y configurarla adecuadamente a nuestro gusto.
Estas herramientas las veremos facilmente situadas en la columna izquierda de Acunetix.





























En esta entrada voy a probar el "Web escaner".
Podemos ver que en la parte superior, hay una barra de URL, en la que podremos introducir la web que queremos escanear.









La organización de Acunetix nos facilita una serie de URLs de webs vulnerables, para realizar las pruebas:

- http://testphp.vulnweb.com
- http://testasp.vulnweb.com
- http://testaspnet.vulnweb.com
- http://testhtml5.vulnweb.com

Podeís utilizar cualquiera de estas para realizar los análisis y escaneos.
En este caso, yo voy a utilizar:
- http://testhtml5.vulnweb.com

La introduzco en "Start URL" y doy a comenzar.

El escaneo empieza y podemos ver como instantaneamente empezamos  a tener los primeros resultados, aunque la realización del escaneo completo suele tardar bastante tiempo, dependiendo la complejidad de la web.





























En el centro de la pantalla podemos ver los errores que el escaner va encontrando en la web.
Se encarga de diferenciar la gravedad del error encontrado, de vulnerabilidad muy grave, a leve.
Esta diferenciación, nos la va señalando con colores, siendo el rojo el de mayor gravedad, amarillo gravedad media y verde leve.

 
En la columna de la derecha, si pinchamos una de los resultados en concreto, se nos especificará en que consta esta vulnerabilidad, que peligro supone, y nos aconseja como podríamos soluccionarla.


En la web que estamos analizando - http://testhtml5.vulnweb.com - el escaner como podemos observar, ha encontrado por el momento: Un Cross site scripting, XML injection, vulnerabilidades en HTML, de Javascript library, etc...

Vamos a seleccionar la de Cross site scripting, a ver que nos indica Acunetix.


Vamos a fijarnos en los detalles.



Vemos los detalles del ataque realizado por acunetix, el impacto de las vulnerabilidades, etc.
Haciendo un correcto uso de esta información, y bajo los consejos que nos ofrece la herramienta, deberemos de poner solucciones a los problemas detectados.


De la misma manera, si vamos seleccionando las demás vulnerabilidades encontradas, cada una tendrá sus especificaciones técnicas concretas.








miércoles, 30 de marzo de 2016

Burp Suite - Auditando tráfico en un Smartphone (Parte 2)

Una vez tenemos configurados Smartphone y Burp Suite vamos a empezar a realizar la práctica.

Dejamos abierto Burp Suite en su pestaña "Proxy"/"Opciones"
Dentro de la pestaña "Proxy" dejamos opciones y pulsamos la primera pestaña "Intercept".

 

 Aquí iremos viendo las peticiones de paquetes de datos que hace nuestro terminal de telefono o tablet y aparte de analizarlos podremos darles paso con el botón "Forward" a que lleguen y se carguen en nuestro Smartphone o cortar la comunicación simplemente con el botón "Drop".

Toda web o aplicación bien protegida no nos mostrará la comunicación al detectar un proxy intermedio no seguro, o si nos ofrece algo será algo no relevante o debidamente encriptado.

Debido a esto y con el sentido de poder mostrar algo visible, he elegido una web, también disponible en app, española llamada "Comuniame" que podemos definir como una especie de juego a tiempo real (simulador) de la liga española, que no está bien protegido y que nos dará mucho juego para el ejemplo, ya que permite transacciones de dinero no real, fichajes de jugadores, etc., y por tanto tiene mucho transito de datos.

Con Burp Suite abierto en mi ordenador, abro dicha web o aplicación el mi Iphone.


Si nos fijamos en Burp Suite, ya estará interceptando tráfico.
Habrá momentos en que la web/aplicación no termina de cargar en el Smartphone. Si nos fijamos en Burp Suite, el botón "Forward" estará iluminado en naranja, cada vez que lo pulsemos estaremós dejando pasar ese paquete de datos y así vamos viendo y estudiando las diferentes peticiones y dejando que cargen en el movil, si no pulsamos hasta que "Forward" deje de iluminarse en repetidas ocasiones, no dejaremos de pasar todos los datos y por tanto no terminarán de cargarse nunca en Smartphone, llegando en muchos casos a dar un error por retardo de información.

Como vemos, lo primero que nos encontramos en la App, es un identificador en el que iniciar sesión.
Yo ya he creado una cuenta con anterioridad con la intención de realizar la prueba, así que pulso que "Ya tengo cuenta" y paso a identificarme.


Introduzco usuario y contraseña.
Si en Burp Suite hemos ido pulsando "Forward" y no tenemos ningun paquete de datos pendiente, al pulsar "Iniciar Sesión" en la App mandará un paquete con la identificación de usuario que pasará por nuestro proxy.


















Está información sería la petición, y como podemos ver entre todos los datos enviados, ahí tenemos en la última línea, email y password.
Si esto fuese captado por una tercera persona, podría acceder a nuestra cuenta, ya que posee nuestras credenciales.
Como podemos ver, si pulsamos "Forward" los datos siguen su curso y la app validará el acceso.



Igual que podemos visualizar los datos, también podemos modificarlos a nuestras anchas.
Dentro de la App, en los pequeños simbolos que vemos en la parte superior hay uno que son dos flechitas. Teoricamente si lo pulso y accedo, en ese apartado puedo realizar fichajes de jugadores.
Veo que me salen varios, voy a elegir uno al azar y voy a darle a comprar por el precio que indica.


Según vemos su valor ficticio es "2.350.000". Damos a aceptar.

Vamos a ver que nos ofrece Burp Suite.
 Yo voy a buscar si en algún lugar de toda esta información encuentro algún valor que indique justamente "2350000" o algo así.
Si nos fijamos en la última línea de datos ahí lo tenemos. "amount" : 2350000

Pues bien, voy a intentar modificar este valor. Lo selecciono y voy a cambiarlo por lo que sea.


Ahora para ver que efecto causa en la app si es que causa alguno, pulso "Forward".

Y cual es la sorpresa cuando en la App nos devuelve esto:

Hemos sido capaces de cambiar nuestra puja inicial a través de Burp Suite.
Podemos ver el peligro que esto acarrearía de tratarse de otra app con datos reales, si estuviese igual de protegida que esta y alguien interceptara nuestros datos.

Vemos que podemos cambiar datos, al igual que interceptar información no encriptada.
Salimos de la sesión de la App.
Volvemos a intentar iniar sesión.


Metemos unos valores al azar y son los que nos muestra Burp Suite.


Si pulsamos "Forward" la app nos denegará el acceso, ya que las credenciales son falsas y no validas.
Pero si no pulsamos "Forward", solo tendremos que cambiar los valores de la última línea (email y password) por los capturados con anterioridad y ahora si pulsamos el resultado cambiará por completo.

Hemos conseguido acceder.

Para finalizar, vamos a ver un breve ejemplo con una App que a pesar de ser bastante más segura que la anterior y no ofrecer información a priori, como es "Waze" la App de navegación...


En el único paquete que es capaz de captar nuestro Burp Suite, que sería el primero, un paquete de información de aplicación sin ninguna importancia ni relevancia para nuestra integridad (a priori) comete un fallo escapandosele un dato.




Como podemos ver en la línea resaltada, "locatión", se indica una numeración.
Esa numeración, son cordenadas.... la de nuestra ubicación actual.

Si copiamos esta númeración según está y la colocamos en google:




Burp Suite - Auditando tráfico en un Smartphone (Parte 1)