Anlisis del Ataque a Aplicaciones Web

CSRF

Aucay Barros Pablo Andrs

Noviembre 2016.
Universidad de Cuenca
Facultad de Ingeniera
Escuela de Sistemas
Anlisis y Peritaje de Dispositivos Electrnicos

Tabla de contenidos
1. Introduccin

2. Fundamentos del ataque escogido.

3. Anlisis de una aplicacin de entrenamiento.

4. Descripcin de los procesos realizados para el ataque escogido.

4.1. Instalacin de la aplicacin.
4.1.1. Servidor local
4.1.2. Instalacin y configuracin de la aplicacin.
4.2. Seleccin del nivel de dificultad.
4.3. Ataque en nivel de dificultad low.

5
5
5
6
8
9

5. Mtodos de mitigacin del ataque:

5.1. Enfoque: desarrollador de una aplicacin web.
5.2. Enfoque: usuarios de una aplicacin web.

13
13
13

6. Conclusiones.

15

7. Referencias.

15

1. Introduccin
A lo largo de la existencia del hombre se han dado diversos avances, dentro de ellos
estn los avances tecnolgicos que han permitido un mejor desarrollo y por tanto una vida
ms simple, sin embargo aunque lo anteriormente dicho es cierto, nada quita que con cada
avance que se ha dado siempre se ha generado un problema nuevo. Y pues bien dentro de
todos estos avances y desarrollos tecnolgicos vemos inmerso el internet y junto a este las
aplicaciones Web. Y como antes ya lo mencione este avance tecnolgico tambin viene
incorporado con sus problemas, problemas que a lo largo de este trabajo iremos viendo de
poco a poco y ms especficamente la vulnerabilidad CSRF.
Dentro de las vulnerabilidades de una pgina o aplicacin web podemos encontrar
varias, para este caso me referir a las mencionadas en el TOP 10 del 2013 del OWASP.
OWASP es un proyecto abierto de seguridad en aplicaciones Web. Se puede decir que es una
comunidad abierta dedicada a habilitar a las organizaciones para desarrollar, comprar y
mantener aplicaciones confiables.
Dentro del TOP 10 del 2013 del OWASP se encuentran las siguientes
vulnerabilidades:
1. Injection. (Puede ser tanto inyeccion SQL, OS y LDAP, esta se produce
cuando se envan datos no autorizados como parte de un comando, una
sentencia, o consulta).
2. Broken Authentication and Session Management. (Se puede producir cuando
la aplicacin no tiene implementada correctamente la autenticacin y la
gestin de sesiones, permitiendo as al atacante comprometer contraseas,
claves, o tokens de sesin).
3. Cross-Site Scripting (XSS). (Puede ocurrir cuando una aplicacin toma datos
poco o nada confiables y los enva a un navegador web sin una validacin
adecuada. Esta vulnerabilidad permite al atacante ejecutar scripts en el
navegador que al mismo tiempo puede secuestrar sesiones de usuarios, para
afectar al sitio web o redirigir a los usuarios a sitios maliciosos).
4. Insecure Direct Object References. (Puede suceder cuando un desarrollador
expone una referencia a un objeto de implementacin interna, puede ser un
directorio o clave de una base de datos. Los atacantes pueden utilizar estas
referencias para acceder a datos no autorizados).
5. Security Misconfiguration. (Esta vulnerabilidad se da por no tener una buena
configuracin ya sea del servidor web, servidor de bases de datos, o la
plataforma. )
6. Sensitive Data Exposure. (Esta vulnerabilidad es explotada, cuando datos
sensibles como tarjetas de crdito, CI, DNI, no son protegidos adecuadamente.
El/los atacantes pueden robar o modificar estos datos, para hacer suplantacin
identidad, robo de dinero, etc.)

7. Missing Function Level Access Control (Se puede dar cuando no se hacen las
validaciones de control de acceso en el servidor. Si las solicitudes no son
verificadas los atacantes pueden hacer solicitudes para acceder a x
funcionalidad sin autorizacin.)
8. Cross-Site Request Forgery (CSRF) (Este es el nuestro, aqu al igual que los
anteriores daremos una breve explicacin pero ms adelante se lo ver con
ms profundidad. Este ataque trata de obligar a un usuario vctima a enviar
una solicitud HTTP falsa desde un navegador donde tiene iniciada su sesin,
para as generar peticiones no consentidas directamente pero que el servidor
las considera legtimas de la vctima )
9. Using Known Vulnerable Components. (Esta vulnerabilidad es explotable
cuando se tienen componentes que se ejecutan con plenos privilegios, y estos
son vulnerables)
10. Unvalidated Redirects and Forwards. (Esta vulnerabilidad es explotada cuando
desde una pgina web o aplicacin web se redirecciona hacia otra pgina, esto
deja el libre acceso a hacer una redireccin a un pgina no autntica donde el
usuario ser vctima de phishing o algn malware)

2. Fundamentos del ataque escogido.

Antes vimos a breves rasgos lo que es CSRF (Cross-site request forgery) que en
espaol significa falsificacin de peticin en sitios cruzados, ahora podemos decir que
CSRF es un tipo exploit en el cual comando que no tienen autorizacin son transmitidos por
un usuario en el el cual el sitio web confa. Si intentamos asemejarlo con algo de la vida
diaria es lo mismo que tomaramos el celular de un amigo y enviamos un mensaje su hermana
diciendo que su mam est enferma. La hermana de nuestro amigo al leer el mensaje pensar
que la noticia que acaba de recibir es cierta, puesto que el mensaje le est llegando desde el
celular de su hermano, pero lo que ella no sabe es que todo fue un invento de nosotros que
solamente tomamos el celular de su hermano.
Entonces podemos decir que esta vulnerabilidad se puede dar cuando un sitio o
aplicacin web permite a un usuario autenticado realizar acciones consideradas sensibles
sin la debida comprobacin, regresando al caso planteado, una vez recibido el mensaje, la
hermana de nuestro amigo tiene dos opciones, tomar acciones pensando que su mam est
enferma, o llamar a su hermano para confirmar la noticia, en caso de tomar la primera accin
tal vez ella luego se de cuenta que todo fue un engao y luego le reclame al hermano por la
broma que l no hizo, pero igual ser tarde y la broma fue hecha, si toma la segunda accin
de llamar inmediatamente al hermano se dar cuenta en seguida que todo fue una broma
entonces no pasar nada. De igual manera si el servidor no realiza la comprobacin este
asumir que el usuario es quien est realizando la accin y por lo tanto le permitir al
atacante hacer todo lo que se le permita hacer al usuario dentro de la pgina web.

3. Anlisis de una aplicacin de entrenamiento.

La aplicacin de entrenamiento que se ha escogido para la realizacin de este trabajo
es DVWA que en sus siglas en ingls significa Damn Vulnerable Web App, y esta
aplicacin no se ha escogido solo por que incluye la vulnerabilidad CSRF, sino porque
gracias a la manera en la que est programada esta app nos permite realizar diferentes
pruebas dentro de los diferentes campos de entrenamiento que viene incluido.
Adems DVWA en su versin 1.9 cuenta con 4 niveles de seguridad/dificultad para
cada uno de sus diferentes apartados: low, medium, high, y impossible que pueden ser
fcilmente cambiados directamente desde su interfaz grfica. En cada vulnerabilidad de
acuerdo al nivel seleccionado cambia su cdigo haciendo ms o menos difcil realizar un
ataque.
DVWA en su versin 1.9 nos permite el anlisis de cdigo vulnerable a los siguientes
aques:
1. Brute Force
2. Command Injection
3. CSRF (Cross Site Request Forgery)
4. File Inclusion
5. File Upload
6. Insecure CAPTCHA
7. SQL Injection
8. SQL Injection (Blind)
9. XSS (Reflected)
10. XSS (Stored)

4. Descripcin de los procesos realizados para el ataque escogido.

4.1. Instalacin de la aplicacin.
Antes de empezar con los procesos realizados, se indicar como se instal la
aplicacin.
4.1.1. Servidor local
Para poder instalar la aplicacin lo primero que debemos tener es un servidor apache
y una base de datos sql. En mi caso tengo en Windows 10 un servidor xampp en su versin
5.6.24, como podemos observar en la figura 1.

Figura 1. Servidor local.

4.1.2. Instalacin y configuracin de la aplicacin.
Nos descargamos la aplicacin que viene en
http://www.dvwa.co.uk/, podemos ver el archivo en la figura 2.

un

.zip

de

la

pgina

Figura 2. Archivo .zip de la aplicacin.

Descomprimimos el .zip y copiamos toda la carpeta a nuestro servidor
local(../xampp/htdocs).

Figura 3. Copia en el servidor local.

Ahora nos creamos una base de datos con el nombre dvwa, como se ve en la figura
4, si se desea se puede crear un usuario con los respectivos permisos para el control de la base
de datos, en este caso utilizaremos root.

Figura 4. Base de datos.

Luego de hacer lo anterior se modifica el archivo de configuracin del dvwa, este
archivo se encuentra en ../xampp/htdocs/dvwa/config/config.inc. Aqu configuramos la
ubicacin de la base de datos, el nombre, y el usuario por el que nos vamos a conectar con la
aplicacin, en este caso es el localhost, con el nombre de la base de datos que creamos
anteriormente dvwa, y el usuario root.

Figura 5. Archivo configuracin dvwa.

Finalmente abrimos un navegador en este caso Mozilla Firefox con la direccin
localhost/dvwa y se nos debe presentar una pantalla como vemos en la figura 6. Estando

all debemos hacer clic en el botn que dice Create/Reset Database, al dar clic en ese botn
la aplicacin configura(crea las tablas con los campos necesarios para su funcionamiento) la
base de datos para poder ejecutarse con normalidad.

Figura 6. Primera pantalla dvwa.

Si hemos hecho todo correcto ahora podemos acceder al login de la aplicacin. Para
acceder utilizamos el usuario admin con la contrasea password.

Figura 7. Login de la aplicacin.

4.2. Seleccin del nivel de dificultad.
Una vez dentro de la aplicacin de entrenamiento con el usuario admin, podemos
elegir el nivel de dificultad en la opcin DVWA Security, esta aplicacin tiene cuatro niveles

de seguridad/dificultad como ya lo mencionamos antes (Low, Medium, High, Imposible),

siendo low donde la aplicacin es ms vulnerable, e Imposible donde tiene una alta seguridad
siendo muy difcil vulnerarla.

Figura 8. Niveles de dificultad.

En esta prctica solo trataremos los niveles Low, Medium, y High yendo en ese orden.
4.3. Ataque en nivel de dificultad low.
Antes de ver cmo funciona el ataque en su nivel ms simple revisaremos con que
entorno nos encontraremos en la aplicacin de entrenamiento. En la parte izquierda podemos
encontrar un men, en el cual debemos seleccionar la opcin CSRF, adems debajo de ese
men podemos observar el nombre de usuario con el que estamos conectados, y el nivel de
seguridad de la aplicacin, en este caso low, anteriormente en el punto 6.2 vimos como
cambiar el nivel de seguridad.

Figura 9. CSRF en la aplicacin.

Como podemos ver en la figura 9 en la aplicacin atacaremos a un formulario en cual
se utiliza para cambiar la contrasea de un usuario. A continuacin cambiaremos el la
contrasea y veremos lo que pasa.

Figura 10. Cambio de clave.

Si vemos la figura 10 al cambiar de clave nos muestra un mensaje en cual dice
Password Changed, adems podemos ver en la URL del sitio que se agreg lo marcado con
rojo ?password_new=1234&password_conf=1234&Change=Change#. si vemos tenemos
dos campos password_new= 1234 y password_conf=1234.

Figura 11. Llegada del formulario a php para el cambio de clave.

Adems si vemos el script de php podemos ver que simplemente por el mtodo get
toma el password nuevo y el de confirmacin, y al comprobar que sean iguales manda a
insertar el nuevo password en el usuario que est activo en ese momento
Entonces podemos decir que fcilmente podemos modificar el password sin la
necesidad de crear un script o acceder al formulario, por ejemplo si accedemos al siguiente
URL:
http://localhost/dvwa/vulnerabilities/csrf/?
password_new=cambioURL&password_conf=cambioURL&Change=Change#, el password
1234 se cambiara por cambioURL, es decir si tuviramos una persona que ha ingresado
con su nombre de usuario y contrasea en la aplicacin y diera clic en este link(abriera en el
navegador donde esta hecho el login), su contrasea cambiara a cambioURL, a
continuacin el figura 12 podemos ver la ejecucin de esta accin.

Figura 12. Cambio de clave por URL.

Si observamos la figura 12, al igual que cuando introducimos la informacin en el
formulario la aplicacin web nos mostr el mensaje Password Changed. Ahora si
revisamos el password en la base de datos. En la figura 13 podemos ver el password del
usuario admin, pero este password est cifrado con md5.

Figura 13. Vista del password en la base de datos.

Para poder visualizar el password descifrado utilizare la pgina
http://www.md5decrypt.org/,
la
cual
al
ingresar
el
password
f53a1c17ab8dfa08d1cd05d865aa56ed de admin nos devuelve cambioURL como
podemos observar en la figura 14.

Figura 14. Password descifrado.

Ahora que hemos comprobado que se puede cambiar as, tambin podemos crear el
siguiente cdigo html para cambiar el password.

5. Mtodos de mitigacin del ataque:

5.1. Enfoque: desarrollador de una aplicacin web.
De este lado de la aplicacin tenemos que tener en cuenta primero que la aplicacin
100% segura es solo un ideal, ya que se depende mucho tambin del usuario final, pero no
debemos dejar toda esa carga solo en l, por lo tanto debemos hacer que el no tenga que
preocuparme mucho por su seguridad, ya que por lo general el usuario final no tiene ni la
minima idea de los riesgos que corre al estar inmerso en el mundo del internet.
Por lo dicho anteriormente se recomienda, al momento de cambiar una contrasea
siempre pedir junto con la nueva la reescritura de la misma, y adems de la actual. Tambin
para cualquier tipo de accin utilizar un token para la verificacin de cada accin del
cliente(usuario final), se puede utilizar palabras secretas para la generacin tokens.
5.2. Enfoque: usuarios de una aplicacin web.
Para el usuario final de la aplicacin web, la primera y ms grande recomendacin es
no acceder a cualquier link que se le pueda presentar, ya sea un link desde una red social, el
correo electrnico, o cualquier pgina web, ya que este link puede contener un acceso hacia
algn formulario trampa, simplemente ser un link directo para alguna pgina vulnerable
donde este tenga una cuenta abierta.

Adems tampoco navegar en pginas web de dudosa procedencia, puesto que las
mismas pueden tener formularios que nos redireccionan al cambio de contrasea de la cuenta.

6. Conclusiones.
Una vez realizado el trabajo y habiendo investigado en general sobre los ataques
puedo concluir que una aplicacin web 100% segura no puede existir, siempre se est
susceptible a cualquier vulnerabilidad, pero si la aplicacin se la construye a conciencia con
ciertas recomendaciones, y una vez terminada realizando las debidas pruebas, esta puede
llegar a ser suficientemente segura.
Pero no todo est del lado del desarrollador, tambin si el usuario final que es un actor
importante dentro de la seguridad del sitio/aplicacin web, ya que el mismo tiene que estar
seguro de que un sitio es seguro para poder ingresar en l, adems de no ingresar en cualquier
link que le pongan o le pasen.

7. Referencias.
OWASP, 11nov 2014 , https://www.owasp.org/index.php/Sobre_OWASP
OWASP
Top
10,
14
sep
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

2016,