Vulnerabilidades de seguridad · MISTIC

Práctica 2
Vulnerabilidades de Seguridad - Otoño 2016

Presentación
Práctica 2 de vulnerabilidades de seguridad sobre vulnerabilidades en aplicaciones web. Una vez
resueltos los ejercicios, recordad hacer las siguientes comprobaciones:

¿Lo he hecho?

La solución se tiene que entregar al registro de evaluación continuada en un único

archivo en formato pdf. No se admite ninguno otro formato (doc, docx, odt, zip, raro, □
tar.gz, ...).

Todas las páginas tienen que estar numeradas y tienen que contener el nombre y
los apellidos. □
La fecha tope de entrega es el 9 de Diciembre de 2016 (a las 24 horas UTC/GMT
+1 horas). □
Esta actividad se puede resolver, con la nota máxima, de forma relativamente breve.
En ningún caso la extensión de la solución tiene que superar las 10 páginas con □
fuente medida mínima 10pt (incluido el texto en las figuras) con interlineado simple.
Por favor, limitad el uso de las capturas de pantalla para cuando sean estrictamente
necesarias y mirad que no ocupen demasiado espacio en las páginas.

Razonad la respuesta a todos los ejercicios e indicad todos los pasos que habéis
realizado para obtener la solución. Las respuestas sin justificación, que sean una □
copia de una fuente de información y/o que no contengan las referencias utilizadas,
no recibirán ninguna puntuación.

© Este documento té copyright. Por favor, absteneos de difundirlo a terceras personas sin una
autorización por escrito.

1
Vulnerabilidades de seguridad · MISTIC

Contexto
Nos encontramos en un ejemplo de tablero de mensajes web donde todo el mundo puede ver los
mensajes que se cuelgan, pero sólo los usuarios autorizados pueden añadir o modificar los mensajes.
Como curiosidad, los usuarios autorizados a modificar los mensajes, lo pueden hacer de forma
general, sin restringirse sólo a los mensajes de los que son autores. Eso sí, entonces pasan a ser los
nuevos autores del mensaje.
Esta aplicación web presenta varias vulnerabilidades que se estudian a continuación.

Configuración
La web sobre la que trata este ejercicio se puede encontrar al archivo "web.tar.gz" que os podéis
descargar del enlace http://deic.uab.cat/~asanchezc/web.tar.gz. Para hacerla funcionar, a pesar de
que es totalmente opcional, se puede usar un servidor web apache con php y sqlite3. A
Debian/Ubuntu los paquetes a instalar son: sqlite3, php5-sqlite, php5, y apache2. Por Windows u
OSX, es recomienda usar XAMPP.
Los archivos dentro de “web.tar.gz” están separados entre los que son accesibles a través del servidor
web y los que no lo son (todos son accesibles por el servidor web, pero no todos los sirve en Internet).
Los archivos que hay en la raíz son accesibles y los que están en la carpeta “private” no lo son.
Podéis comprobar que efectivamente el fichero que os descargáis corresponde con el enunciado de
esta práctica validando el hash MD5: c51de49ee300707d7c42c49b63aa4d4c.

Pregunta 1: SQL Injection

La página no permite enviar mensajes a usuarios no autenticados, un formulario nos exige que
introduzcamos un usuario y contraseña válidos. Lo primero que haremos es comprobar que este
formulario es vulnerable a una SQL Injection y aprovecharlo para saltarnos esta protección.
a) Dad un ejemplo de combinación de usuario y contraseña que siempre pase la validación de este
formulario.
Nota: si uno de los dos campos está vacío, a pesar de que se puede hacer login, no podréis utilizar
las otras funcionalidades de la aplicación web, puesto que el sistema lo notará más adelante.

Escribo los valores...

En los campos...
Del formulario de la página...

Con la SQL Injection del apartado anterior, podemos editar y publicar mensajes en nombre del usuario
'manolo' (es la primera entrada a la tabla de usuarios). Para prepararnos para suplantar a otro
usuario, necesitamos descubrir el nombre de los campos al que se guardan los nombres de usuario y
las palabras de paso a la base de datos. Por eso nos hemos descargado un diccionario que contiene
posibles nombres para estos campos:
usr passwd
user password
username pass
name psswrd
usrname passw
[…] [...]

2
Vulnerabilidades de seguridad · MISTIC

b) Dad un ataque que, utilizando este diccionario, nos permita obtener el nombre de este campo.

Explicación del ataque:

Campo de usuario:
Campo de contraseña:

Ahora que ya sabemos el nombre del campo donde se guarda el nombre de usuario, estamos
preparados para descubrir el nombre de usuario y la palabra de paso de otro usuario. Para hacerlo, es
útil saber que la base de datos utilizada es de tipo SQLite3.
c) Dad un ataque que nos permita obtener la combinación de usuario y palabra de paso de algún
usuario diferente de 'manolo'.

Usuario...
Contraseña...
Descripción del ataque...

Pregunta 2: XSS
En vista de los problemas de seguridad que habéis encontrado, empezáis a sospechar que esta
aplicación quizás es vulnerable a XSS (Cross Site Scripting).
a) Para comprobarlo, en primer lugar tratad de modificar un de vuestros mensajes para que, al pulsar
el botón "Send", veais el mensaje "Hola mundo!" fuera de la caja de texto, justo encima del botón
"Send".

Introduzco el mensaje...
En el formulario de la página...

Para ver si el problema es de XSS y no sólo aparece a la hora de editar el mensaje, sino que el listado
de mensajes también es vulnerable, crearemos un mensaje que muestre un alert de Javascript
siempre que alguien consulte el listado de mensajes (list_messages.php).
b) Dad un mensaje que muestre un “alert” al consultar el listado de mensajes.

Introduzco el mensaje...
En el formulario de la página...

c) ¿Por qué dice "&" cuando miráis un link (como el que aparece a la portada de esta aplicación
pidiendo que realices un donativo) con parámetros GET dentro de código html si en realidad el link es
sólo con "&" ?
Explicación...

3
Vulnerabilidades de seguridad · MISTIC

d) Explicad cuál es el problema en las dos páginas afectadas, y cómo lo arreglaríais.

Páginas afectadas...
¿Cuál es el problema?
Sustituyo el código de la/las líneas...
Por el siguiente código...

Pregunta 3: XSRF
Ahora que ya sabemos que podemos realizar un ataque XSS, lo queremos aprovechar para realizar y
XSRF y conseguir que que todos los usuarios que consulten la lista de mensajes (list_messages.php)
hagan un click a la dirección que hemos preparado: http://web.pagos/donate.php?
receiver=attacker&amount=100, mediante la cual, harán una donación de 100€ al usuario 'attacker'
de la famosa plataforma de pagos online 'web.pagos'.
a) Dad un mensaje que sirva a vuestros propósitos sin levantar ninguna sospecha entre los usuarios
que consulten la lista de mensajes.

Introduzco el mensaje...
Al formulario de la página...

Pero 'web.pagos' sólo gestiona pagos y donaciones entre usuarios registrados, puesto que,
evidentemente, le tiene que restar los 100€ a la cuenta de algún usuario para poder añadirlos a
nuestra cuenta.
b) Explicad qué condición se tendrá que cumplir por que se efectúen las donaciones de los usuarios
que visualicen el mensaje del apartado anterior.

Condición a cumplir...

En esta aplicación de ejemplo, el usuario y la contraseña se guardan en claro en una cookie. Esto
presenta un problema grave de seguridad, puesto que cualquiera que pueda leer estas cookies
obtendrá los datos directamente. Esto se haría colgando un mensaje con código XSS que mediante
javascript lea las cookies y después las enviara a un tercer servidor.
c) Combinando lo que habéis realizado en los apartados a) de esta pregunta, y el b) de la pregunta
anterior, dad un mensaje que envíe la cookie de cada usuario que consulte el listado de mensajes a
un tercer servidor sin que el usuario se dé cuenta.

Introduzco el mensaje...
Al formulario de la página...

d) Si 'web.pagos' modifica la página 'donate.php' para que reciba los parámetros a través de POST,
¿quedaría blindada contra este tipo de ataques? En caso negativo, explicad qué tipo de recurso
tendríais que utilizar para realizar un ataque equivalente al del apartado a).

¿Queda blindada?
Contraejemplo (si es necesario)...

4
Vulnerabilidades de seguridad · MISTIC

Nota: Propiedad intelectual

A menudo es inevitable hacer uso de recursos creados por terceras personas. Es por lo
tanto comprensible hacerlo en el marco de una práctica, siempre y esto se documente
claramente y no suponga plagio en la práctica.

Por lo tanto, al presentar una práctica que haga uso de recursos ajenos, se tiene que
presentar junto con ella un documento en que se detallen todos ellos, especificando el
nombre de cada recurso, su autor, el lugar donde se obtuvo y su estatus legal: si la obra
está protegida por el copyright o se acoge a alguna otra licencia de uso (Creative
Commons, licencia GNU, GPL ...). El estudiante tendrá que asegurarse que la licencia
que sea no impide específicamente suyo uso en el marco de la práctica. En caso de no
encontrar la información correspondiente tendrá que asumir que la obra está protegida
por el copyright.

Nota: esto se refiere al copyright del documento que entregáis al registro de evaluación
continua y no al copyright de las herramientas que podáis haber usado. Por ejemplo, al
usar una imagen en la respuesta de un ejercicio tenéis que seguir el que aquí se indica,
pero por el contrario, si usáis el sistema operativo Debian para resolver el enunciado,
entonces no es necesario.