Para comenzar la prctica sobre COMPARATIVA DE SCANNERS

AUTOMTICOS DE VULNERABILIDADES se recomienda la lectura previa del

siguiente documento de WASC:
http://projects.webappsec.org/w/page/13246985/Web%20Application
%20Firewall%20Evaluation%20Criteria
Los SCANNERS automticos de VULNERABILIDADES son herramientas de
test de caja negra para realizar un test de penetracin. Los informes que
arrojan con deteccin de vulnerabilidades hay que revisarlos para
comprobar la veracidad de las detecciones ya que no son perfectas.
Funcionan inyectando cadenas en campos de entrada que pueden constituir
un cierto tipo de ataque y despus analizan la respuesta para evaluar si
existe una vulnerabilidad en la aplicacin.
Para realizar la comparativa, se utiliza la aplicacin WAVSEP
http://code.google.com/p/wavsep/ ) como benchmark diseada para tal fin.

A vulnerable web application designed to help assessing the features, quality and
accuracy of web application vulnerability scanners. This evaluation platform contains a
collection of unique vulnerable web pages that can be used to test the various properties
of web application scanners.

Por un lado, se compone de casos de test diseados cada uno con una
vulnerabilidad concreta como SQLI por ejemplo. Se trata de identificar para
los casos que se pide (NO TODOS) SI LAS HERRAMIENTAS LAS DETECTAN.
Una vulnerabilidad detectada cuando realmente existe es un VERDADERO
POSITIVO.
Por otro lado, WAVSEP tiene tambin casos de test para FALSOS
POSITIVOS, que son versiones de algunos de los casos de test con las
vulnerabilidades corregidas, es decir, no tienen vulnerabilidades. Un caso de
test de FALSO POSITIVO con una vulnerabilidad de SQLI CORREGIDA no
debera ser detectada por las herramientas, si la herramienta da una alerta
de SQLI est errando en la deteccin y por tanto es un FALSO POSITIVO.
De esta forma podemos medir la eficacia de un SCANNER y comparar con
otro en cuanto a detecciones correctas (VERDADEROS POSITIVOS) y a
detecciones incorrectas (FALSOS POSITIVOS)

INSTALACIN DE SOFTWARE.

1.1.

INSTALAR WAVSEP 1.5

Requiere la instalacin previa de JRE ((Java Runtime Environment) es una mquina

virtual de Java y su funcin es hacer de intermediario entre una aplicacin programada en Java
y el sistema operativo que se est usando. De este modo, cualquier aplicacin puede funcionar
en cualquier sistema operativo que disponga del JRE) , APACHE TOMCAT 6.X y

MYSQL 5.5.X
Hay que seguir las instrucciones de instalacin de WAVSEP (Wavsep Google
Project) desde http://code.google.com/p/wavsep/ , que requiere la
instalacin previa de especficas versiones de APACHE TOMCAT y de MYSQL.
La aplicacin WAVSEP est en http://sourceforge.net/projects/wavsep/files/?
source=navbar

(@) Use a JRE/JDK that was installed using an offline installation (the online installation caused
unknown bugs for some users).
(1) Download & install Apache Tomcat 6.x
(2) Download & install MySQL Community Server 5.5.x (Remember to enable remote root
access if not in the same station as wavsep, and to choose a root password that you
remember).
(3) Copy the wavsep.war file into the tomcat webapps directory (Usually "C:\Program
Files\Apache Software Foundation\Tomcat 6.0\webapps" - Windows 32/64 Installer)
(4) Restart the application server
(5) On WinXP, as long as you are using a high privileged user - you can skip this phase, on
Win7, make sure you run the tomcat server with administrative privileges (right click on and
execute),and on Ubuntu Linux, run the following commands:
sudo mkdir /var/lib/tomcat6/db
sudo chown tomcat6:tomcat6 /var/lib/tomcat6/db/
(6) Initiate the install script at: http://localhost:8080/wavsep/wavsep-install/install.jsp
(7) Provide the database host, port and root credentials to the installation script, in additional to
customizable wavsep database user credentials.
(8) Access the application at: http://localhost:8080/wavsep/

1.2.

INSTALAR IRONWASP

http://ironwasp.org/
1.3.

INSTALAR ZAP

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

1.4. SCANNERS DE VULNERABILIDADES PARA APLICACIONES WEB

(DYNAMIC ANALYSIS SECURITY TOOLS (DAST))

Son herramientas del tipo de caja negra y sirven para descubrir las
vulnerabilidades de una aplicacin web efectuando un test de penetracin.
Para ello siguen dos fases:
1. SPIDERING o CRAWLING. En esta fase llevan a cabo un
descubrimiento de la estructura del sitio web, directorios, URL,s, etc.
2. ANLISIS. Realizan el envo de peticiones maliciosas (con algn
PAYLOAD o cadena maligna) a la aplicacin, para ver si puede
constituir un intento de ataque analizando las respuestas que reciben
del servidor.

Los

scanners

automticos

tienen

sus

limitaciones

pueden

detectar un conjunto de vulnerabilidades debido a su naturaleza.

Por ejemplo, son capaces de detectar importantes vulnerabilidades como:

XSS.
SQLI.
PATH TRANSVERSAL.
COMMAND INJECTION.
DEFECTOS DE CONFIGURACIN.
PROBLEMAS RELACIONADOS CON JAVASCRIPT.
FILE INCLUSION.
XPATH INJECTION.
HTTP RESPONSE SPLITING.

Debido a que realizan un anlisis sintctico de las respuestas que

reciben, no pueden comprender la semntica de varios parmetros
en su conjunto que pueden esconder un intento de ataque. Por tanto,
tienen dificultad en detectar otras como:

Violacin de CONTROLES DE ACCESO.

Vulnerabilidades de DISEO.
SECUESTRO DE SESIONES.
INFORMATION LEAKAGE.
Como la mayora de las herramientas de anlisis seguridad, no son
perfectas y pueden tener falsos negativos (vulnerabilidades no
detectadas cuando realmente existen) y falsos positivos (vulnerabilidades
detectadas cuando realmente no existen).
En esta actividad vamos a intentar aprender a utilizar estas herramientas
para hacer scanners automticos e intentar medir su eficacia utilizando el
banco de pruebas WAVSEP contabilizando el nmero de verdaderos
positivos (detecciones correctas) y de falsos positivos (falsas alarmas).

NOTA: En los sitios web de las herramientas

existen tutoriales para aprender cmo se
configuran y utilizan estas herramientas.
1.5.

TEST DE DETECCIN DE VULNERABILIDADES:

Cada TEST CASE est diseado para probar una determinado vulnerabilidad.
Hay que comprobar si las herramientas seleccionadas son capaces de
detectar la vulnerabilidad para la cual el TEST CASE ha sido diseado y
contabilizar el nmero total de detecciones correctas. Es decir. Si el TEST
CASE N1 est diseado con una vulnerabilidad SQLI, hay que comprobar
que las herramientas la detectan, sin tener en cuenta detecciones otras
vulnerabilidades distintas de SQLI en este TEST CASE N1.
Ejecutar cada una de las herramientas para realizar scanners automticos
sobre los grupos de test cases solicitados y analizar los resultados para los
siguientes TEST CASES. (No tener en cuenta otras alertas aparte la
especficamente diseada para cada TEST CASE):

Reflected XSS: primeros 15 test cases (8 GET, 7 POST).

Blind SQL Injection: primeros 15 test cases (8 GET, 7 POST).
Passive Information Disclosure/Session Vulnerabilities 3 test cases.
Path transversal: primeros 10 test cases (5 GET, 5 POST).
Remote file inclusion: primeros 10 test cases (5 GET, 5 POST).
Unvalidated Redirect: primeros 10 test cases (5 GET, 5 POST)

Hay que contabilizar el nmero de verdaderos positivos para cada tipo de

vulnerabilidad.

1.6.

TEST DE FALSOS POSITIVOS

En cada uno TEST CASES, las herramientas no deberan detectar la

vulnerabilidad para la que est diseado. En un TEST CASE para SQLI,
no existe tal vulnerabilidad porque la consulta no permite
inyeccin. Si la herramienta detecta SQLI es un falso positivo y hay
que contabilizar la falsa alarma. (No tener en cuenta otras alertas
aparte la especficamente diseada para cada TEST CASE):
Ejecutar cada una de las herramientas para realizar scanners automticos
sobre los grupos de test cases solicitados y analizar los resultados para los
siguientes TEST CASES DE FALSOS POSITIVOS:

7 different categories of false positive Reflected XSS vulnerabilities

(GET & POST ).
10 different categories of false positive SQL Injection vulnerabilities
(GET & POST)

8 different categories of false positive path traversal/LFI vulnerabilities (GET & POST)

6 different categories of false positive (xss via) remote file inclusion vulnerabilities (GET
& POST)

9 different categories of false positive unvalidated redirect vulnerabilities (GET & POST)

Hay que contabilizar el nmero de falsos positivos para cada tipo de

vulnerabilidad.

2. MEMORIA
La memoria debe contener los resultados de los scanner efectuados sobre
los casos de test especificados:
-

TABLAS (una para cada tipo de vulnerabilidad con cada uno de los
casos de test) con resultados de DETECCIN (verdaderos positivos)
de los scanner realizados con cada una de las 2 herramientas,
expresando en una fila final el porcentaje de detecciones de cada tipo
de vulnerabilidad.

TABLAS (una para cada tipo de vulnerabilidad con cada uno de los
casos de test) con resultados de los test de FALSOS POSITIVOS de los
scanner realizados con cada una de las 2 herramientas, expresando
en una fila final el porcentaje de falsos positivos de cada tipo de
vulnerabilidad.

TABLA
COMPARATIVA
DE
RESULTADOS
DE
LAS
HERRAMIENTAS CON PORCENTAJES DE DETECCIONES
FALSOS POSITIVOS DE CADA VULNERABILIDAD

2
Y

TABLA CON EXPRESIN DEL PORCENTAJE DE DETECCIONES Y

FALSOS POSITIVOS TOTALES TENIENDO EN CUENTA TODAS
LAS
VULNERABILIDADES
A
LA
VEZ
CON
LAS
DOS
HERRAMIENTAS (puede ir pegada a la anterior

- Explicacin, con un TEST CASE CONCRETO,

de cmo se detecta una vulnerabilidad con
cada una de las herramientas y como se
comprueba con la herramienta que la
deteccin
es
REALMENTE
una
vulnerabilidad.
-

Comentarios y razonamientos COMPARATIVOS sobre las herramientas

que estimis oportunos, desde puntos de vista como:
-

2.1.

USABILIDAD.
FUNCIONALIDADES Y POSIBILIDADES.
PRESENTACIN.
DOCUMENTACIN Y AYUDA.
CALIDAD DE INFORMES.
COBERTURA DE VULNERABILIDADES (TIPOS DE
VULNERABILIDADES QUE PUEDEN DETECTAR)
EFICACIA en cuanto a verdaderos y falsos positivos.
IMPRESIN GENERAL PERSONAL a MODO DE CONCLUSIN
...

ESTRUCTURA DE LA MEMORIA (15 pginas mximo)

No son necesarios pantallazos, puesto que se tienen que

entregar los informes generados de los scanner efectuados con
cada herramienta.
-

INDICE
INTRODUCCIN
RESULTADOS
ANALISIS (usabilidad, funcionalidad, )
CONLUSIONES
REFERENCIAS

3. ENTREGABLE

LA FALTA DE ALGUNO DE ESTOS DOS

REQUISITOS NO SER POSIBLE
SUPERAR LA ACTIVIDAD

1.

GENERAR y ENVIAR INFORMES DE LOS SCANNERS

REALIZADOS CON CADA HERRAMIENTA SOBRE WAVSEP.

2. INFORME
ANEXO RECOMENDACIONES GENERALES
Se tienen que realizar scanners automticos.
Se recomienda realizar scanner separados por URL que agrupan las mismas
categoras de vulnerabilidades. Ejemplo:
http://localhost:8080/wavsep/active/SInjection-Detection-EvaluationPOST-500Error/index.jsp
Luego se atiende solo a los resultados relativos a los TEST CASES que se
piden.
Estas herramientas primero ejecutan una tarea de CRAWLING para descubrir
el contenido de la aplicacin objetivo.
Estudiar las opciones de configuracin, para adaptar los SCANNER de la
forma ms conveniente.

ANEXO IRONWASP (ejemplo con versin de 2013)

Se realiza SCAN AUTOMTICO de un apartado de SQLI (POST) como ejemplo

con todas las opciones por defecto:
http://localhost:8080/wavsep/active/SInjection-Detection-EvaluationPOST-500Error/index.jsp

Todava no ha acabado, pero ya ha encontrado 26 SQLI,s.

IMPORTANTE RECORDAR: LOS TEST CASES ESTN DISEADOS CON UNA
VULNERABILIDAD CONCRETA (HAY QUE CONTABILIZAR LOS QUE ENCUENTRA LA
HERRAMIENTA), LOS TEST CASES DE FALSOS POSITIVOS NO TIENEN
VULNERABILIDAD (HAY QUE CONTABLIZAR LAS FALSAS ALARMAS).
Cmo se comprueba cada SQLI? Se selecciona el primer SQLI (+++10) del
men de navegacin y se obtiene el tipo de vulnerabilidad encontrada y su
descripcin para cada TRIGGER (3 en total), que son los intentos de prueba que
hace la herramienta con un test case determinado. Como ves es un POST con
expresin del TEST CASE donde se ha detectado:
http://localhost:8080/wavsep/active/SInjection-Detection-Evaluation-POST-500Error/Case03InjectionInCalc-String-BooleanExploit-WithErrors.jsp HTTP/1.1
Host: localhost:8080
Hay que comprobar que se ha detectado (O NO) SQLI en cada TEST CASE diseado
con una vulnerabilidad de SQLI y contabilizar las detecciones para los casos pedidos
en la prctica. Se pueden ver las cabeceras REQUEST y RESPONSE y la descripcin
de lo que ha pasado en cada triger.
En un teste de pruebas con una aplicacin real, no para pruebas como WAVSEP, no
sabramos si la deteccin es verdadera o falso positivo. Habra que comprobar, con
ayuda de la herramienta cada vulnerabilidad, reconstruyendo la peticin tal y como
se envi al servidor durante el test y observar si se lleva a cabo el ataque con el
PAYLOAD (cadena maliciosa, maligna, etc.) utilizado, a'+'a en el ejemplo siguiente.
En este caso podemos decir que la herramienta ha detectado
correctamente el SQLI que contiene el test case:
http://localhost:8080/wavsep/active/SInjection-Detection-Evaluation-POST-500Error/Case03InjectionInCalc-String-BooleanExploit-WithErrors.jsp
Se puede ver en el ejemplo que el payload es a'+'a

ANEXO ZAP

Revisar para familiarizase con la herramienta, las opciones de ANLISIS en Analizar y Herramientas (opciones). La ayuda de la
herramienta est bastante bien.

Se presenta un scanner de XSS en WAVSEP con ZAP:

Se observa para una ALERTA CONCRETA seleccionada:

-

La respuesta del servidor.

Informacin del parmetro de la peticin alimentado con <SCRIPT
SCRIPT> que da lugar a la materializacin de un ataque XSS
aprovechando la vulnerabilidad.
Como el TEST CASE est diseado con una vulnerabilidad XSS y la
herramienta la detecta se contabilizara. NO SE HAN DE TENER EN
CUENTA OTRAS ALERTAS DISTINTAS de XSS para contabilizar.

NOTA:
** Existen 3 tipos de Pruebas de Penetracion :
Pruebas de Penetracion de Caja Negra: Donde los pentesters
o analistas de seguridad no tienen conocimiento del
funcionamiento interno del sistema, y trabaja con la informacin
que puede conseguir por sus propios medios, igual que lo podra
hacer un delincuente informtico.
Pruebas de Penetracion de Caja Blanca: En este tipo de
pruebas los pentesters o analistas de seguridad tienen total
conocimiento del funcionamiento interno del sistema, y trabaja
con informacin que puede tener acceso uno o varios empleados
dentro de la organizacin.
Pruebas de Penetracion de Caja Gris: Donde los pentesters o
analistas de seguridad pueden tener conocimiento sobre algunos
aspectos del funcionamiento del sistema y de otros no.