blog

WPScan es un escaner de vulnerabilidades de tipo caja negra para WordPress, el cual puede ser utilizado para escanear remotamente instalaciones de WordPress con el propósito de encontrar problemas de seguridad

Considerar el hecho de WPScan tiene una licencia dual. Los casos incluyendo comercialización de WPScan requieren una licencia comercial no libre. De lo contrario, WPScan puede ser utilizado sin cargos bajo algunos términos.

El procedimiento de instalación en Samurai-WTF es sencillo. Descargado el archivo, se procede a descomprimirlo o desempaquetarlo, para luego ejecutar los siguientes comandos.

$ sudo apt-get install libcurl4-openssl-dev libxml2 libxml2-dev libxslt1-dev ruby-dev build-essential
$ sudo gem install bundler && bundle install --without test

La primera acción posterior a su instalación implica realizar la actualización de la herramienta.

$ ./wpscan.rb --update

La acción más sencilla para utilizar WPScan implica realizar un conjunto de verificaciones o pruebas “No Intrusivas”.

$ ./wpscan.rb --url 192.168.0.X/ wordpress

Finalizado el proceso es muestrado una gran cantidad de información relevante. Como las tecnologías utilizadas en el lado del servidor, la probable versión de WordPress en funcionamiento, y las vulnerabilidades identificadas desde el número de la versión.

WPScan también puede ser utilizado para realizar un ataque por fuerza bruta utilizando una lista de palabras, esto con el propósito de identificar la contraseña válida de un usuario. El más atractivo de los usuarios será el usuario de nombre “admin”. La opcion “--wordlist” define la lista de palabras a utilizar. La opción “--username” define el usuario a atacar.

$ ./wpscan.rb --url 192.168.0.X/ wordpress --wordlist /home/samurai/Wordlists/10kpasswords.txt --username admin

El siguiente procedimiento permite enumerar los Plugins instalados en WordPress. La razón para obtener este tipo de información, es debido a haberse descubierto diversas vulnerabilidades en estos Plugins. Los resultados exponen la identificación de tres plugins de nombres; “akismet”, mygallery y “wpSS”.

$ ./wpscan.rb --url 192.168.0.X/ wordpress --enumerate p

También es factible de hecho ejecutar todas las opciones de enumeración incluidas en WPScan. Enumeración de nombres de usuarios, plugins, los timthumbs y temas.

$ ./wpscan.rb --url 192.168.0.X/ wordpress --enumerate

WPScan incluye diversas opciones, los cuales permiten definir la utilización de un proxy, realizar una autenticación básica en caso se requerida, definir hilos, definir tiempos máximos de espera para peticiones, entre otras funcionalidades.

Siempre se sugiere verificar manualmente todas los resultados obtenidos por WPScan, para evitar falsos positivos.

Fuentes:

http://wpscan.org/
https://github.com/wpscanteam/wpscan
https://github.com/wpscanteam/wpscan/blob/master/README.md
https://wordpress.org/

GTD-PHP es una implementación basada den web del sistema personal de organización “Getting Things Done” o “Resolver las Cosas”. GTD-PHP es un de las diversas herramientas utilizadas con las soluciones de productividad descritas en el libro “Getting Things Done”.

Para la siguiente demostración se utilizará la versión 0.7 de GTD-PHP incluida en la más reciente versión de OWASP Broken Web Applicación Project.

Configurado Zed Attack Proxy con Firefox, se ejecutan las herramientas de “Spider” y “Active Scan”, para luego analizar los resultados obtenidos en la pestaña de nombre “Alerts”.

Zed Attack Proxy expone cuatro alertas relacionadas a Inyecciones SQL. Uno de los cuales utiliza el método GET y los otros tres utilizan el método POST.

Las verificaciones se realizarán utilizando la herramienta “Sqlmap”. La primera verificación se realiza contra el hallazgo obtenido por Zed Attack Proxy utilizando el método “GET”.

http: // 192.168.0.X/gtd-php/editChecklistItem.php?checklistItemId=5

Sqlmap ha detectado como vulnerable el parámetro de nombre “chekcklistItemId”. La opción “-b” se utiliza para capturar los banners del DBMS o Sistema Gestor de Base de Datos.

$ sqlmap -u "http: //192.168.0.X/gtd-php/editChecklistItem.php?checklistItemId=5" -b

Los siguientes hallazgos encontrados por ZAP utilizan el método POST. Esto requiere la definición de otras opciones al utilizar la herramienta Sqlmap.

http:// 192.168.0.33/gtd-php/listItems.php?type=r

Sqlmap muestra una advertencia indicando la probable inyección del parámetro “contextId”. Pero al finalizar las pruebas Sqlmap expone la no posibilidad de realizar una inyección.”--method” fuerza a utilizar un método HTTP definido. “--data” define la cadena de datos a enviar a través del método POST. “-p” define el parámetro a evaluar.

$ sqlmap -u "http: //192.168.0.X/gtd-php/listItems.php" --method POST --data="contextId=4-2&submit=Filter&categoryId=1&timeId=1" -p "contextId"

En el siguiente hallazgo, aunque los resultados de ZAP exponen la utilización del método POST, el parámetro inyectable de nombre “type” se ubica en la URL.

http:// 192.168.0.X/gtd-php/listItems.php?type=r+AND+1%3D1+--+

En primera instancia Sqlmap indica la posibilidad de inyectar el parámetro de nombre “type”, pero al finalizar las pruebas indica la no posibilidad de hacerlo.

$ sqlmap -u "http://192.168.0.X/gtd-php/listItems.php?type=r" -b

El hallazgo final también se reporta utilizando el método POST, pero el parámetro vulnerable de nombre “tcId” se ubica en la URL.

http: //192.168.0.X/gtd-php/updateTimeContext.php?tcId=4-2

En este hallazgo Sqlmap reporta la improbabilidad de inyectar el parámetro de nombre “tcId”.

$ sqlmap -u "http: //192.168.0.X/gtd-php/updateTimeContext.php?tcId=4" -b

Fuentes:

http://www.gtd-php.com/
https://code.google.com/p/zaproxy/
http://sourceforge.net/projects/owaspbwa/
https://www.owasp.org/index.php/SQL_Injection
http://sourceforge.net/p/owaspbwa/tickets/?limit=999&sort=_severity+asc
http://sqlmap.org/

GTD-PHP es una implementación basada en web del sistema personal de organización “Getting Things Done” o “Resolver las Cosas”. GTD-PHP es un de las diversas herramientas utilizadas con las soluciones de productividad descritas en el libro “Getting Things Done”. La idea básica detrás de este libro es ser más productivo cuando se tiene la mente clara.

Para la siguiente demostración se utilizará la versión 0.7 de GTD-PHP incluida en la más reciente versión de OWASP Broken Web Applicación Project.

Configurado Zed Attack Proxy con Firefox, se ejecutan las herramientas de “Spider” y “Active Scan”, para luego analizar los resultados obtenidos en la pestaña de nombre “Alerts”.

Zed Attack Proxy expone seis alertas relacionadas a Cross Site Scripting (XSS) Relejados. Cinco de los cuales utilizan el método GET y uno utilizan el método POST.

Se procede a verificar manualmente cada uno de estos hallazgos.

http: //192.168.0.X/gtd-php/checklistReport.php?checklistId=1&checklistTitle=%3C%2Fh1%3E%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E%3Ch1%3E

En el siguiente hallazgo se muestra el campo donde es factible explotar un XSS Reflejado.

http: //192.168.0.X/gtd-php/editChecklist.php?checklistId=1&checklistTitle=%3C%2Fh2%3E%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E%3Ch2%3E

El siguiente resultado se trataría de un falso positivo, pues aunque el script insertado por ZAP para realizar la prueba es devuelto en el cuerpo de la respuesta, el mensaje versa sobre un error en la consulta SQL. Este resultado podría indicar la posibilidad de realizar una Inyección SQL en lugar de un tema relacionado a un Cross Site Scripting.

http: //192.168.0.X/gtd-php/editChecklistItem.php?checklistItemId=%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E

En el siguiente hallazgo se muestra el campo donde es factible explotar un XSS Reflejado.

http://192.168.0.X/gtd-php/editList.php?listTitle=%3C%2Fh2%3E%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E%3Ch2%3E&listId=1

http: //192.168.0.X/gtd-php/listReport.php?listTitle=%3C%2Fh1%3E%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E%3Ch1%3E&listId=1

El último de las XSS Reflejados detectados por ZAP utiliza el método POST. El nombre del parámetro vulnerable es: “completedProj%5B%5D”

http: //192.168.0.X/gtd-php/processProjectUpdate.php

Para realizar esta verificación manual se utiliza la funcionalidad de Interceptación de Zed Attack Proxy, para modificar el valor del parámetro vulnerable.

El script insertado se ha ejecutado correctamente.

Fuentes:

http://www.gtd-php.com/
http://sourceforge.net/projects/owaspbwa/
https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29
http://sourceforge.net/p/owaspbwa/tickets/?limit=999&sort=_severity+asc

Estos formularios son ejemplos de la utilización de Mono para ejecutar páginas ASP.NET. Mono es una plataforma de software diseñada para permitir a los desarrolladores crear fácilmente aplicaciones inter plataformas. Mono es una implementación open source del framework .NET de Microsoft basado en los estándares para C# y Common Language Runtime.

Para la siguiente demostración se utiliza la versión incluida en la más reciente versión de OWASP Broken Web Applicación Project.

Se ejecuta Zed Attack Proxy configurado con Firefox, para luego proceder a navegar la Aplicación Web vulnerable.

Se ingresa primero a la página simple ASP.NET la cual es vulnerable a un Cross Site Scripting Reflejado. Ingresado el nombre se procede a hacer clic en el botón de nombre “Submit”.

Zed Attack Proxy es capaz de encontrar este XSS Relejado mediante un Escaneo Activo. Donde el parámetro de nombre “name” es vulnerable.

Se realiza una prueba manual para verificar este hallazgo, insertando un sencillo código.

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

El resultado es exitoso y es factible explotar satisfactoriamente un XSS Reflejado.

Se procede a ingresar a la página sencilla en ASP.NET la cual esta protegida por validación de peticiones ASP.NET.

Al realizar la misma prueba manual anteriormente realizada para insertar un script, se obtiene un mensaje del servidor en la aplicación “/mono”. El cual versa sobre un valor “Request.QueryString” potencialmente peligroso, el cual ha sido detectado desde el cliente.

A modo de ejemplo se procederá a utilizar la herramienta para realizar “Fuzzing”, la cual permitirá intentar diferentes “payloads” o cargas útiles relacionadas con XSS.

Seleccionar el valor enviado con el parámetro de nombre “name”. Hacer clic derecho y luego seleccionar la opción “Fuzz...”

Hacer clic en el botón de nombre “Payloads”. Luego clic en el botón de nombre “Add”. Seleccionar "File" en la opción “Type”. Para luego seleccionar utilizando el botón “Select...” el archivo conteniendo los “Payloads” XSS a evaluar. En esta caso particular el archivo de nombre “xss-rsnake.txt”.

Se procede a hacer clic en el botón de nombre “Add”. Luego en el botón “Ok”. Y finalmente clic en el botón de nombre “Start Fuzzer” para iniciar el proceso.

Según los resultados del Fuzzer, existen tres payloads con los cuales se ha podido explotar un XSS Reflejado.

getURL("javascript:alert('XSS')"
a="get";
\";alert('XSS');//

Al realizar una verificación manual de estos Payloads ninguno de ellos es satisfactorio. Esto se trataría de falsos positivos, pues ZAP indica la existencia de XSS, pero al realizar la verificación manual; aunque se incluye el “Payload” en la respuesta desde la aplicación web; estos "scripts" no son ejecutados por el navegador web.

Una prueba adicional utilizando la herramienta de Fuzzing incluida en ZAP, sería evaluar diferentes tipos de codificación para los caracteres enviados en los parámetros de las peticiones.

Fuentes:

http://sourceforge.net/projects/owaspbwa/
https://code.google.com/p/owaspbwa/wiki/UserGuide
https://github.com/zaproxy/zaproxy
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
http://sourceforge.net/p/owaspbwa/tickets/?limit=999&sort=_severity+asc

Estos simples formularios ilustran las diferentes maneras en las cuales se puede implementar la validación de entradas en aplicaciones Apache Struts.

Apache Struts es un framework MVC libre y open-source para crear aplicaciones web en Java elegantes y modernas. Favoreciendo la convención sobre la configuración, es ampliable utilizando una arquitectura de plugins, y se entrega con plugins soportando REST, AJAX y JSON.

Para la siguiente demostración se utilizará la versión de Mandiant Struts Forms incluida en la más reciente versión de OWASP Broken web Applicación Project.

Se ejecuta Zed Attack Proxy configurado con Firefox, para luego proceder a navegar la Aplicación Web vulnerable.

Se inicia la demostración utilizando el primer enlace de la lista. La cual es una versión del formulario vulnerable a Cross-Site Scripting Reflejado. Se procede a realizar una prueba manual utilizando un ejemplo clásico con la función “alert”.

En Zed Attack Proxy se puede visualizar el cuerpo de la respuesta devuelta por la Aplicación Web vulnerable el cual contiene el script de prueba insertado.

<script>alert('XSS!')</script>

Se procede a realizar una evaluación sobre la segunda versión del formulario, la cual utilizar una lista negra incompleta de validación de entradas para prevenir etiquetas “&#x3Cscript>”, pero sigue siendo vulnerable a tipos más sofisticados de Cross-Site Scripting Reflejado.

Se realiza la misma prueba utilizada en la versión anterior, y el mensaje devuelto por la aplicación indica una entrada inválida.

Entonces mediante una inferencia simple, si la etiqueta “&#x3Cscript>” está filtrada no se debe utilizar. Una alternativa será utilizar la etiqueta “&#x3Cimg src>” y la función de nombre “onmouseover”.

<IMG SRC=# onmouseover="alert('XSS!')">

Se visualiza la respuesta devuelta por la Aplicación Web utilizando ZAP, la cual incluye el código insertado.

La tercera y cuarta versión del formulario utilizan Struts ValidatorForm para implementar una lista blanca en el lado del servidor y adicionalmente en el lado del cliente respectivamente.

Fuentes:

http://sourceforge.net/projects/owaspbwa/
https://code.google.com/p/owaspbwa/source/browse/trunk/var/lib/tomcat6/…
http://struts.apache.org/
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

El Proyecto OWASP Vicnum es una colección de aplicaciones web hechas intencionalmente vulnerables. Estas aplicaciones web vulnerables son útiles para demostrar las vulnerabilidades web más comunes como inyecciones SQL, Cross-Site Scripting (XSS) y temas en la gestión de la sesión.

Siendo una pequeña aplicación web sin ningún framework complejo, las aplicaciones Vicnum pueden ser fácilmente invocados y adaptados a requerimientos específicos. Por ejemplo si una aplicación vulnerable de prueba es necesaria para evaluar un escaner de seguridad web o un firewall de aplicación web, se podría desear controlar la aplicación web objetivo para ver lo encontrado por el escaner y lo factible de ser protegido por el firewall.

Para la siguiente demostración se utilizará Vicnum en una máquina real y Samurai-WTF. Se procede a configurar Zed Attack Proxy con Firefox para luego ingresar a Vicnum.

Ingresar al juego para adivinar un número.

Ingresar un nombre y hacer clic en el botón de nombre “PLAY”.

A continuación se debe tratar de adivinar el número de tres dígitos seleccionado aleatoriamente por la computadora. Se ingresa un número para luego hacer clic en el botón de nombre “GUESS”.

El juego continúa proporcionando pistas para tratar de adivinar el número.

En Zed Attack Proxy se analizan los datos enviados hacia la Aplicación Web. El parámetro de nombre “userguess” almacena el número enviado por el usuario, el parámetro de nombre “player” almacena el nombre del usuario. Prestar atención en el parámetro de nombre “VIEWSTATE”.

Los símbolos %0D y %0A representan CR (Carriege return) y LF (Line feed) respectivamente. Para los cuatro símbolos previos se utiliza la herramienta de Codificación/ Decodificación y Hashing incluida en Zed Attack Proxy.

Dado el juego consiste en adivinar un número, la decodificación en Base64 tiene un mejor significado. Se procede entonces a intentar este número como el “correcto” para el juego.

Es correcto. El número ha sido adivinado en el segundo intento. Esto a razón de almacenar la información del estado a través del cliente en un campo oculto del formulario de nombre “VIEWSTATE”.

Este mismo procedimiento de análisis, puede se aplicado para el juego donde se debe intentar adivinar una palabra de cinco letras generada aleatoriamente por la Aplicación Web.

Fuentes:

https://www.owasp.org/index.php/Category:OWASP_Vicnum_Project
http://vicnum.ciphertechs.com/
http://sourceforge.net/projects/owaspbwa/
http://sourceforge.net/p/owaspbwa/tickets/?limit=999&sort=_severity+asc

El Proyecto OWASP Vicnum es una colección de aplicaciones web hechas intencionalmente vulnerables. Estas aplicaciones web vulnerables son útiles para demostrar las vulnerabilidades web más comunes como inyecciones SQL, Cross-Site Scripting (XSS) y temas en la gestión de la sesión.

Siendo una pequeña aplicación web sin ningún framework complejo, las aplicaciones Vicnum pueden ser fácilmente invocados y adaptados a requerimientos específicos. Por ejemplo si una aplicación vulnerable de prueba es necesaria para evaluar un escaner de seguridad web o un firewall de aplicación web, se podría desear controlar la aplicación web objetivo para ver lo encontrado por el escaner y lo factible de ser protegido por el firewall.

Para la siguiente demostración se utilizará Vicnum en una máquina real y Samurai-WTF. Se procede a configurar Zed Attack Proxy con Firefox para luego ingresar a Vicnum.

Según los resultados obtenidos de realizar un escaneo activo utilizando Zed Attack Proxy, se obtienen cuatro temas relacionados con Inyecciones SQL.

Todas las inyecciones SQL encontradas utilizan el método POST. Para evaluar estos hallazgos es factible utilizar la funcionalidad de interceptación de ZAP. Ícono con una esfera de color verde ubicado en el panel superior (Set break on all request and responses).

Primero se ingresa un valor normal en el campo en evaluación.

Se modifica el valor “aloha” ingresado previamente, por la prueba pertinente para intentar detectar una Inyección SQL.

Anotar como el texto de prueba es mostrado en la página devuelta por la Aplicación Web. Esto puede tratarse de un falso positivo, qunque altamente propenso a un Cross-Site Scripting (XSS) Reflejado.

Se procede a verificar manualmente la segunda Inyección SQL identificada por Zed Attack Proxy.

Se escribe una comilla simple en el campo utilizado para buscar jugadores dentro de la Aplicación Web. La respuesta devuelta muestra un mensaje de error en la consulta SQL realizada. Se exponen nombres de columnas como “name”, “guess”, “count”, “tod” y el nombre de la tabla “guessnumresults”.

La consulta extrae información de cuatro columnas, por lo tanto es factible unir la consulta original utilizando la sentencia “UNION”, e iniciar a capturar información diversa como el nombre de usuario utilizado, el nombre de usuario del sistema, nombre de la base de datos y versión del servidor de base de datos. Toda esta información puede ser obtenida directamente utilizando el navegador web.

Este mismo procedimiento puede ser realizado para verificar las restantes Inyecciones SQL identificadas por Zed Attack Proxy.

Fuentes:

https://www.owasp.org/index.php/Category:OWASP_Vicnum_Project
http://vicnum.ciphertechs.com/
https://www.owasp.org/index.php/Testing_for_SQL_Injection_%28OTG-INPVAL…
http://sourceforge.net/projects/owaspbwa/
http://sourceforge.net/p/owaspbwa/tickets/?limit=999&sort=_severity+asc
http://pentestmonkey.net/cheat-sheet/sql-injection/mysql-sql-injection-…

El Proyecto OWASP Vicnum es una colección de aplicaciones web hechas intencionalmente vulnerables. Estas aplicaciones web vulnerables son útiles para demostrar las vulnerabilidades web más comunes como inyecciones SQL, Cross-Site Scripting (XSS) y temas en la gestión de la sesión.

Siendo una pequeña aplicación web sin ningún framework complejo, las aplicaciones Vicnum pueden ser fácilmente invocados y adaptados a requerimientos específicos. Por ejemplo, si una aplicación vulnerable de prueba es necesaria para evaluar un escaner de seguridad web o un firewall de aplicación web, se podría desear controlar la aplicación web objetivo para ver lo encontrado por el escaner y lo factible de ser protegido por el firewall.

Para la siguiente demostración se utilizará Vicnum en una máquina real y Samurai-WTF. Se procede a configurar Zed Attack Proxy con Firefox para luego ingresar hacia Vicnum.

Según los resultados obtenidos al realizar un escaneo activo utilizando Zed Attack Proxy se obtienen siete temas relacionados con Cross-Site Scripting (XSS) Reflejados.

Se verifica el primer XSS encontrado utilizando el método GET. Esto puede ser realizado utilizando la opción “Open URL in Browser” de Zed Attack Proxy.

Para los XSS encontrados utilizando el método POST es factible utilizar la funcionalidad de interceptación de ZAP . Ícono con una esfera de color verde ubicado en el panel superior (Set break on all request and responses).

Interceptada la petición dirigida hacia la aplicación web, se modifica el valor de la variable de nombre “player” con el código script a insertar codificado en URL. Luego se desactivan las peticiones. De regreso al navegador web se visualiza la ejecución del código script insertado en la aplicación web.

El procedimiento detallado puede ser utilizado para verificar todas las URLs donde se han encontrado parámetros vulnerables a XSS utilizando el método POST

http: //IP_Objetivo/cgi-bin/guessnum1.pl
http: //IP_Objetivo cgi-bin/jotto1.pl
http: //IP_Objetivo/cgi-bin/jotto2.pl
http: //IP_Objetivo/guessnum5.php
http: //IP_Objetivo/unionguessnum.php
http: //IP_Objetivo/unionjotto.php

Fuentes:

https://www.owasp.org/index.php/Category:OWASP_Vicnum_Project
http://vicnum.ciphertechs.com/
https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_script…
http://sourceforge.net/projects/owaspbwa/
http://sourceforge.net/p/owaspbwa/tickets/?limit=999&sort=_severity+asc

Para implementar diversas funcionalidades en las aplicaciones web se necesita utilizar el concepto de una sesión. En el caso del registro o registro de ingreso (login) hacia una aplicación web, su inexistencia requeriría al usuario reingresar las credenciales de acceso para cada página de la aplicación web. Por lo tanto, después de la autenticación del usuario una única vez, la aplicación crea una sesión para este y trata todas las peticiones correspondientes a la sesión como provenientes desde el usuario.

La manera más sencilla de implementar sesiones es entregar a cada usuario un token o identificador único de sesión. Luego en cada petición subsecuente hacia la aplicación, el usuario enviará nuevamente este token, permitiendo a la aplicación determinar con cuales secuencias de peticiones anteriores se relaciona la petición actual.

No todas las aplicaciones web utilizan sesiones, frecuentemente se encontrarán dos alternativas posibles.

Autenticación HTTP

Las Aplicaciones Web utilizan diversas tecnologías basadas en la autenticación HTTP (Basic, digest, NTLM), las cuales evitan la necesidad de utilizar sesiones. Con la autenticación HTTP, el componente del cliente interactúa directamente con el mecanismo de autenticación mediante el navegador web utilizando las cabeceras HTTP, y no mediante un código específico de la aplicación contenido dentro de cada página individual.

Después de ingresadas las credenciales en el recuadro de diálogo del navegador web, el navegador envía nuevamente estas credenciales con cada petición subsecuente hacia el mismo servidor. Esto es equivalente a una aplicación utilizando una autenticación basada en un formulario HTML y colocar el formulario de login en cada página de la aplicación, requiriendo a los usuarios volver a autenticarse a si mismos con cada acción realizada.

Por lo tanto, cuando una autenticación HTTP es utilizada, es posible para una aplicación web volver a identificar al usuario entre diversas peticiones sin utilizar sesiones. Sin embargo, la autenticación HTTP raramente es utilizada en aplicaciones en Internet.

Para las siguientes demostraciones se utiliza Zed Attack Proxy configurado con Firefox.

Se ingresa a una Aplicación Web la cual utiliza una Autenticación Básica.

Se visualiza la respuesta devuelta desde la Aplicación Web. La cual indica al navegador web a presentar un recuadro de diálogo solicitando credenciales de acceso válidas.

Se ingresan las credenciales correctas. Anotar el campo “Authorization:” donde se incluye la contraseña codificada en Base64.

Ahora se procede a ingresar a una Aplicación Web utilizando la Autenticación “Digest”.

En la respuesta devuelta por la aplicación web anotar el campo “WWW-Authenticate:”

Ingresadas las credenciales correctas, se visualiza los datos enviados hacia la Aplicación Web. En este tipo de autenticación no se envían las credenciales codificadas o cifradas directamente.

Estados sin Sesión

Algunas aplicaciones no entregan tokens de sesión para gestionar el estado de la interacción del usuario con la aplicación web. En lugar de esto transmiten todos los datos requeridos para gestionar el estado mediante el cliente, usualmente en una cookie o un campo oculto de formulario. Este mecanismo utiliza un estado sin sesión como el ViewState de ASP.NET lo hace.

Para asegurar este tipo de mecanismo, los datos transmitidos mediante el cliente deben ser adecuadamente protegidos. Esto implica construir agrupaciones binarias conteniendo toda la información del estado y cifrando o firmando esto utilizando un algoritmo reconocido. Se debe incluir suficiente contexto dentro de los datos para prevenir por parte de un atacante la recolección de un objeto de estado en una ubicación dentro de la aplicación web y enviarlo nuevamente hacia otra ubicación para causar un comportamiento indeseable.

Para la siguiente demostración se utilizará la Aplicación Web de nombre WebGoat.NET incluida dentro de OWASP Broken Web Applications Project.

Anotar el campo de nombre “__VIEWSTATE” incluido dentro del cuerpo devuelto en la respuesta de la Aplicación Web.

La decodificación del "ViewState" se puede realizar utilizando Python. Entre los datos decodificados se puede observar también un texto “Session” y el mismo valor contenido en la Cookie de nombre “ASP.NET_SessionId”.

Fuentes:

http://tools.ietf.org/html/rfc2617
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
http://test.webdav.org/
https://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Project
https://docs.python.org/2/library/base64.html

Uno de los primeros pasos en cualquier ataque basado en red es identificar los potenciales objetivos. Y se debe enumerar al detalle información sobre los sistemas y redes, como el sistema operativo, service pack, aplicación o servicio, versión, nivel de parche, puerto, etc.

La mayoría de escaners de vulnerabilidades y herramientas para pruebas de penetración utilizan las cabeceras como un método principal para identificar potenciales vulnerabilidades. Si los atacantes pueden fácilmente encontrar el sistema operativo y su versión, pueden más fácilmente identificar vulnerabilidades en los sistemas e iniciar el proceso de encontrar una manera viable de ingreso. Además, algunas herramientas automáticas de pruebas de penetración tienen código de explotación el cual puede automáticamente explotar el sistema basándose en la versión y plataforma en funcionamiento identificada.

Para la siguiente demostración se utilizará Kali Linux y una máquina virtual basada en GNU/Linux De-Ice 1.100.

Se realizar un escaneo de puertos TCP SYN utilizando la herramienta unicornscan. La opción “-mT” define un escaneo de puertos comparable a la opción “-sS” de la herramienta Nmap. La opción “-Iv” muestra los resultandos en cuanto los encuentra, además de generar mayor verbosidad. El “:a” define el escaneo hacia los 65535 puertos de la dirección IP.

# unicornscan -mT -Iv 192.168.0.100:a

Se procede a realizar una Captura del Banner o “Banner Grabbing” para cada puerto descubierto en estado abierto.

Puerto TCP/21. Las respuestas recibidas desde el puerto 21 utilizando netcat y un cliente ftp, no proporcionan información sobre la versión del servicio.

Puerto TCP/22: La respuesta recibida desde el puerto 22 utilizando un cliente ssh detallan un servicio OpenSSH 4.3, con una versión del protocolo 1.99.

Puerto TCP/25: La respuesta recibida desde el puerto 25 utilizando netcat, expone un servicio SMTP ejecutando un Sendmail 8.13.7/8.13.7.

Puerto TCP/80: La respuesta recibida desde el puerto 80 utilizando netcat, en primera instancia no expone ningún dato relevante, razón por la cual se hace necesario interactuar con el servicio enviando el método “HEAD” solicitando el recurso “/” utilizando la versión 1.0 del protocolo HTTP. Esto expone la utilización de un servidor Apache/2.0.55 (Unix) y PHP/5.1.2.

Puerto TCP/110: La respuesta recibida desde el puerto 110 utilizando netcat, permite inferir un servicio POP3, pero no expone información sobre la versión del servicio. La causa de esto puede ser una configuración realizada para no mostrar estos datos.

Puerto TCP/143: La respuesta recibida desde el puerto 143 utilizando netcat, expone un servicio IMAP, adicionalmente se expone la información IMAP4rev1 2004.357 y sus capacidades. Una búsqueda en Google con esta información expuesta permite inferir la posible utilización de WU-IMAP.

A modo de demostración y para corroborar la información obtenida manualmente, se procede a realizar un escaneo de versiones contra los puertos abiertos descubiertos utilizando nmap.

# nmap -n -Pn -sV -p21,22,25,80,110,143 192.168.0.100

Los resultados obtenidos utilizando la herramienta nmap son casi idénticos a los obtenidos de manera manual. El procedimiento siguiente será buscar información relevante sobre vulnerabilidades o temas de seguridad asociados con los servicios y versiones descubiertas, con el propósito de explotarlas o aprovecharse de estas.

Fuentes:

https://www.kali.org/
https://www.vulnhub.com/entry/de-ice-s1100,8/
http://unicornscan.org/
https://nvd.nist.gov/