Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
[3.2] OWASP
3
TEMA
Vulnerabilidades web
TEMA 3 – Esquema
Introducción DVWA BurpSuite Authentication bypass
• ¿Qué es? • Introducción • Herramientas de
Fuerza bruta
• ¿Qué busca? • Instalación la suite
CSRF
2
Referencia directa insegura a
objetos
WebGoat
SQLMap
• Introducción Configuraciones inseguras
• Instalación
Hydra
Inyección
Tamper Data
Redirecciones y reenvíos
Gestión de sesión
Ideas clave
Para estudiar este tema lee las Ideas clave que se exponen a continuación.
En la actualidad, casi todo está relacionado con Internet y las aplicaciones y servicios
web que proporciona, ya sea para ver el correo o para hacer compras online. Pero hay
datos sensibles y debe haber una seguridad en todos estos servicios y aplicaciones.
En este tercer tema se hablará de las vulnerabilidades web más importantes, de las
diferentes herramientas que tenemos para encontrarlas y explotarlas y de diferentes
plataformas de aprendizaje para el alumno.
Tamper Data, un plugin muy útil que realiza la función de captura y modificación de
peticiones HTTP.
Estas vulnerabilidades son: Authentication bypass, fuerza bruta, Cross Site Request
Forgery (CSRF), ejecución maliciosa de ficheros local (LFI) y remota (RFI), Cross Site
Scripting (XSS), configuraciones inseguras, referencia directa insegura a objetos,
inyección (de comandos y SQL), redirecciones y reenvíos, subida de archivos sin
restricción, gestión de sesiones, almacenamiento criptográfico inseguro y protección
insuficiente en la capa de transporte.
3.2. OWASP
Los documentos con más éxito de OWASP son OWASP Testing Guide y OWASP Top
10. El primero, que ya va por su versión 4, consiste en una guía práctica y teórica para
realizar pentesting a aplicaciones web; el segundo consiste en una recopilación de las
vulnerabilidades más frecuentes que nos podemos encontrar en las aplicaciones web,
así como su funcionamiento, impacto y formas de evitarlas.
Nos vamos a fijar en los top 10 de los años 2010 y 2013 (este último es el más actual) y
veremos cómo han cambiado en estos años. En los próximos apartados veremos más a
fondo los diferentes tipos de vulnerabilidades.
Para poder realizar algunos ejemplos y poder practicar las vulnerabilidades que iremos
viendo será necesario un entorno que simule una aplicación web real. No es
conveniente hacerlo con sitios web reales ya que podemos causar verdaderos problemas
a los sitios y hacerlo sin consentimiento de los administradores del sitio es ilegal.
1. DVWA
Su interfaz es la siguiente:
Vamos a explicar cómo realizar su instalación en nuestra máquina Kali Linux, pero se
podría hacer en cualquier sistema operativo. Para realizar la instalación será necesario
tener un servidor, una base de datos y PHP ya instalado (ya que DVWA está basado en
este lenguaje).
2. Mutillidae
Mutillidae contiene varios tipos de vulnerabilidades más que DVWA y posee dos niveles
de sugerencias o consejos (Tips) para ayudar al usuario a explotarlas. Incluye todas las
vulnerabilidades vistas en el OWASP Top 10 (tanto de 2010 como de 2013).
El código fuente de las páginas y los scripts estás comentado para permitir al usuario
ver cómo funcionan las defensas y vulnerabilidades.
3. WebGoat
WebGoat está escrito en Java y se puede instalar en cualquier máquina que tenga una
máquina virtual de Java, por lo que funciona sobre cualquier sistema operativo (Linux,
Windows, Mac OS X...).
La plataforma además incluye información acerca de las cookies y los parámetros que
se envían y gestionan.
Una vez descargado ejecutaremos el siguiente comando cada vez que queramos utilizar
la plataforma, pues no necesita instalación ni ejecutar ningún servidor o base de datos
extra, ya lo hace todo el archivo jar: java -jar WebGoat-6.0.1-war-exec.jar.
3.4. Herramientas
Antes de comenzar a ver los diferentes tipos de vulnerabilidades web vamos a ver más a
fondo algunas herramientas diseñadas especialmente para el análisis y explotación de
aplicaciones y servicios web. Estas herramientas facilitarán enormemente la búsqueda
de vulnerabilidades y la automatización de la explotación.
1. BurpSuite
Para usarlo será necesario establecer en el navegador que vamos a utilizar un proxy, en
este caso lo vamos a explicar para Iceweasel (Firefox) el navegador por defecto en Kali.
Además quitaremos que no se pueda usar un proxy en localhost (puesto por defecto).
Por defecto BurpSuite utiliza el puerto 8080, pero si lo queremos modificar podemos ir
a Proxy > Options y ahí lo cambiaremos. Podemos ver un ejemplo de captura a
WebGoat con este proxy:
Nota: no olvidar desactivar el proxy en las opciones del navegador al cerrar BurpSuite,
ya que no funcionará, porque todas las peticiones las mandará al puerto proxy y no
habrá ninguna aplicación para reenviarlas.
Para utilizarlo elegiremos una captura hecha con el proxy y con clic derecho o pulsando
Action, seleccionaremos «Send to Spider».
Otra de las herramientas y una de las más potentes de la suite es Intruder, con la que
podremos realizar ataques sobre aplicaciones web automatizados. Nos
permitirá generar peticiones HTTP maliciosas y detectar y explotar vulnerabilidades
como inyección SQL, XSS, manipulación de parámetros o ataques por fuerza bruta.
La siguiente herramienta, el Repeater, será muy simple. Nos permitirá coger una
petición realizada y reenviarla tantas veces queramos modificando manualmente los
parámetros.
2. OWASP-ZAP
El puerto por defecto será de nuevo el 8080. Aunque no tengamos activa la captura
de peticiones y respuestas, todos los sitios web que visitemos mientras utilicemos el
proxy quedarán guardadas en el mapa de sitios de OWASP-ZAP.
Capturar peticiones
y/o respuestas
Proxy de OWASP-ZAP.
En el reporte nos aparece el código malicioso que podemos introducir para comprobar
el resultado de escaneo:
Un spider o araña, que intenta indexar y capturar las URL de una página
para hacer un mapa completo del sitio web. Una forma que tiene de hacerlo
es ver el código HTML y buscar todas las direcciones del mismo dominio para
redirigir y repetir. Tiene dos tipos de spider, uno tradicional y otro para sitios web
AJAX. Para utilizarlo simplemente daremos clic derecho en un sitio guardado en la
pestaña de sitios y seleccionaremos Atacar > Spider «tipo», donde «tipo» podrá ser
el sitio entero o una URL específica.
3. SQLMap
sqlmap --url="http://www.paginaweb.com/injeccion?=id=1"
4. Hydra
Los ataques por fuerza bruta intentan adivinar las credenciales de autenticación para
ganar acceso al sistema. Es una manera simple y segura de conseguir un resultado, pero
tiene dos grandes desventajas:
El tiempo que puede tardar en probar todas las combinaciones posibles de usuario y
contraseña.
El ruido que causa, pues genera mucho tráfico (pudiendo provocar denegaciones de
servicio con estas herramientas de ataque por fuerza bruta).
Para utilizar la herramienta lo haremos por consola. Por ejemplo, si queremos realizar
un ataque por fuerza bruta para obtener las credenciales para conectarnos por SSH a
una máquina con la IP 192.168.1.30 utilizando una lista para usuarios y otra lista para
contraseñas:
Figura 20. Uso de Hydra para conectarnos a una máquina por ssh.
5. Tamper Data
Tamper Data no es una aplicación como las anteriores que hemos visto, sino que es un
plugin para el navegador (en concreto para Firefox y derivados), pero es una
herramienta muy útil, sencilla y rápida.
Cuando hablamos de BurpSuite vimos que traía una herramienta de Proxy, pues
Tamper Data realiza esa misma función, pero al ser un plugin del navegador nos
permite no tener que modificar las conexiones para establecer manualmente un proxy.
1. Authentication Bypass
Muchas páginas web requieren algún tipo de autenticación para acceder a zonas
restringidas o información privada, normalmente con un nombre de usuario y
contraseña. Cuando una página web permite la introducción de un usuario o
contraseña lo hace mediante peticiones GET o POST. Para realizar estas peticiones se
deben rellenar ciertos campos donde introducir las credenciales.
URL’s mal restringidas. Un error muy básico que comete un gran número de
desarrolladores es crear un mecanismo de autentificación para un servicio web,
pidiendo usuario y contraseña en una página de login y, posteriormente, dar acceso
al resto de páginas del servidor sin realizar otra comprobación.
El problema con esto reside en que si obtenemos una URL de la zona «privada»
podríamos acceder a ella sin autenticarnos, ya que no comprobará si lo hemos hecho
previamente.
Un ejemplo puede darse en las URL’s de un banco. Tenemos una cuenta en un banco
y nos conectamos a su página web para consultar nuestro saldo y realizar
transacciones. Nos pide usuario y contraseña para acceder a nuestra cuenta y vemos
que la URL es: https://www.mibanco.es/user/getAccount. Pero si las URL no
estuvieran bien configuradas podríamos acceder a otras zonas de la página web que
deberían ser privadas cambiando /user/ por otra cosa, como /admin/, /manager/,
/administrator/…
Ofuscar las URL. Algunos servidores web tienen listas de páginas que están
restringidas y que necesitan de autentificación para acceder a ellas. Pero podría
haber URL’s que no estén en la lista de páginas restringidas que apunten a dichas
páginas.
La consulta solo analizará hasta el usuario, ya que para el resto creará una tabla
temporal que dará un error, aunque esto no nos afectará. Como el usuario existe y
solo hay una entrada en la base de datos, nos identificará como este usuario y
podremos saltarnos la autentificación sin necesidad de introducir contraseña.
La forma más fácil para evitar estos fallos es utilizar funciones que comprueben los
parámetros antes de pasárselos a las consultas, como en los niveles medio y alto de
DVWA de fuerza bruta.
2. Fuerza bruta
¿Qué ocurre si el servidor comprueba correctamente las entradas de texto del usuario?
Podemos ver en los niveles medio y difícil como en el código fuente realiza
comprobaciones para evitar las comillas (‘ ’) o los slashes ( \ ).
La única forma que nos queda será comprobar todas las posibles combinaciones
de usuario – contraseña. Normalmente esta es una tarea muy tediosa, por lo que se
recurren a diccionarios (archivos de texto con gran cantidad de palabras que se suelen
utilizar como usuario o contraseña). A este tipo de ataque se le llama de fuerza bruta.
Para ver un ejemplo nos fijamos de nuevo en la página DVWA, en la pestaña de Brute
Force. En este caso usaremos la dificultad medium.
Vamos a utilizar la técnica de fuerza bruta para poder obtener el nombre de usuario y la
contraseña. Para ello utilizaremos la herramienta BurpSuite y su pestaña de Intruder.
Pasos:
En primer lugar pondremos el navegador en modo proxy por el puerto 8080 como
ya se ha explicado.
En este caso se ha usado una pequeña lista con combinaciones que se conoce de
antemano que funcionarán, para ahorrar tiempo, pero en un entorno real será
necesario probar uno o varios diccionarios completos.
Figura 32. Resultados obtenidos, a la derecha están marcados los mensajes que coinciden con el patrón
anterior
Nota: a veces para mejorar la efectividad de los ataques de fuerza bruta por diccionario,
es conveniente crear nuestro propio diccionario. Para ello nosotros usaremos la
herramienta Crunch ya incluida en Kali Linux.
Esta herramienta nos permite utilizar patrones para generar grandes listas de palabras
que podremos utilizar como diccionarios. Nos permite elegir la longitud que queremos
que tengan las palabras generadas (mínima y máxima). Para ver todas las opciones de
esta herramienta escribiremos en consola:
crunch --help
Si por ejemplo conocemos que las contraseñas de alguna organización se generan con 3
letras y 4 números podremos generar un diccionario con todas las combinaciones
posibles para poder usar luego herramientas como Hydra o BurpSuite para atacar por
fuerza bruta.
CSRF es tan peligroso como la aplicación web que se ataque, si fuera un banco, un
atacante podría hacer transferencias desde la cuenta de la víctima, cerrar una cuenta
bancaria, etc.
El gran problema con este tipo de vulnerabilidades es que es muy difícil seguir la pista
hasta el atacante, ya que la IP que realiza la petición a la aplicación web vulnerable es la
de la víctima (como si fuera una operación lícita).
<img src="https://www.facebook.com/pages/PaginaParaLikes/?=like">
La víctima que tiene abierta una sesión en Facebook visita la página web del
atacante, al hacerlo descarga la imagen y el navegador ejecuta el código oculto.
Si la sesión de la víctima no ha caducado, Facebook tomará la petición como legítima
(ya que la cookie de sesión no ha caducado, el navegador y la IP son los de la víctima,
etc.) y realizará la acción del atacante sin el conocimiento de la víctima.
Deben cumplirse varias condiciones para que pueda darse a cabo este tipo de ataque:
Esta medida, por ejemplo, se usa para evitar acceder a páginas de forma directa, es
decir, sin pasar por páginas de registro.
El atacante debe encontrar alguna forma (HTML) o URL que realice la acción que
desee (como hacer likes, transferir dinero o cambiar una contraseña).
El atacante deberá conocer el valor Victima (que podría ser un nombre, una cuenta o
un identificador de cliente) para poder realizar la operación.
El atacante debe asegurarse que la víctima accede a la página con el código malicioso
cuando tiene una sesión abierta en el sitio objetivo.
127.0.0.1/dvwa/vulnerabilities/csrf/?password_new=pass&password_conf=pass&Ch
ange=Change#
Para el ejemplo, primero con el nivel bajo, crearemos una pequeña página web con una
imagen que referencie a la URL maliciosa y la guardaremos en la carpeta
/var/www/falso.
El segundo ejemplo, con el nivel intermedio, será similar. En este caso crearemos una
página con un enlace que nos redireccionará a la página de DVWA y cambiará la
contraseña.
http://www.pagina_vulnerable.com/index.php?page=plantilla.html
Nota: en muchos casos no funcionará, ya que servidores como Apache, por defecto,
tienen un parámetro que evita que se pueda realizar esta llamada a otras páginas web.
Para desactivarlo (en el caso de Kali Linux) deberemos ir al fichero:
/etc/php5/apache2/php.ini
En caso de no usar Kali Linux y Apache2 como servidor, deberemos buscar el archivo
php.ini del que usemos y modificar el mismo parámetro.
Nuestro objetivo será ejecutar una webshell en la página vulnerable, así que crearemos
una (o la descargaremos). En nuestro caso hemos copiado el código fuente de la
webshell desde pastebin.com y hemos creado el archivo c99.txt en la carpeta falsa de
nuestro servidor (para simular una página web ajena al servidor).
http://pastebin.com/JK2AaELL
A continuación se explicarán los dos tipos de inclusión de ficheros que hay: remota y
local.
Consiste en llamar desde la página web a un fichero que está situado en otro
servidor. El fichero al que queramos llamar no debe acabar en .php, ya que este tipo
de fichero se ejecuta en el servidor en el que esté; por ello lo hemos llamado c99.txt.
Esta webshell será solo de lectura, pero podremos obtener mucha información del
servidor, así como descargar el código fuente de las páginas.
En este caso consiste en llamar desde la página web a un fichero local, es decir, que
ya esté en el servidor (en cualquier lugar de este) y ejecutarlo. Por ejemplo si ya
hemos conseguido subir una webshell al servidor por algún método, podremos
llamarlo utilizando su ruta absoluta o relativa.
Podemos ver un ejemplo con el nivel medio de DVWA. En este nivel la página
comprueba antes de hacer el include(), pues no permite la introducción de «http» o
«https» para poder hacer una inclusión remota (aunque podríamos llamar a un
archivo de un servidor ftp, ya que no lo bloquea).
También hay otra forma para realizar esta inclusión local sin necesidad de tener el
archivo de la webshell cargado en la máquina del servidor. Para ello usaremos el
esquema URL «data» (disponible a partir de PHP 5.2).
Un ejemplo del funcionamiento es: ?page=data:, <?php echo "Prueba de data"; ?>
Nosotros lo que queremos es ejecutar comandos como si fuera una shell, así que
llamaremos a una de forma local con la llamada system().
Se puede ver que el segundo tipo de XSS es muy peligroso, ya que, si algún sitio web
que reciba millones de visitas al día es vulnerable a un XSS almacenado se podrían
comprometer todas las máquinas para cualquier fin: robo de datos, botnets, etc.
XSS Reflejado
En el nivel fácil vemos que no realiza comprobación alguna del texto que
introduzcamos.
?name=</pre><script>javascript:alert("XSS!!");</script>
</pre><img src=http://www.fasebonus.net/wp-content/uploads/2013/02/hacker-02.jpg>
Existen muchas técnicas para saltarnos este tipo de controles mediante listas negras de
palabras o expresiones. Un par de ejemplos pueden ser:
Usar mayúsculas:
?name=<SCRIPT>javascript:alert("XSS!!")</script>
?name=<scrip<script>t>javascript:alert("XSS!!")</script>
Hay muchas más formas de evadir estos filtros, como otras combinaciones o codificar
las URL.
XSS Almacenado
Nos encontramos con un libro de visitas en el cual podemos introducir texto en dos
campos. Si nos fijamos y comenzamos a poner caracteres en ellos veremos que el
primero solo acepta 10 y el segundo 50.
Podemos introducir de nuevo el código que queramos, ya sea para generar una alerta,
inyectar una foto, redirigir a otra página… pero a diferencia del caso anterior, se
quedará guardado y siempre que carguemos la página el código se ejecutará.
Para el ejemplo vamos a ver el nivel bajo e intentaremos hacer que la página nos
redireccione a otra que queramos, es decir, que siempre que accedamos a la pestaña
XSS Stored nos redireccionará a otra página. Para ello usaremos:
El número indica el tiempo que tardará en refrescar la página y la URL a qué página
deberá redireccionar.
Cuando queramos insertar el código en el mensaje veremos que no entra todo, por lo
que deberemos usar Tamper Data.
Nota: para eliminar las entradas del libro de visitas que hayamos creado será necesario
resetear la base de datos de la página.
Filtrar las salidas convirtiendo el texto o datos que podrían contener scripts
maliciosos a un formato codificado:
o ‘<’ y ‘>’ -> ‘<’ y ‘>’
o ‘(’ y ‘)’ -> ‘(’ y ‘)’
o ‘#’ y ‘&’ -> ‘#’ y ‘&’
Utilizar validación de entrada mediante una lista blanca y no una lista negra.
Podemos ver que usando una lista negra, en el ejemplo de XSS Reflejado filtrando
por <script>, somos capaces de saltárnoslo.
Tenemos una cuenta en la página online de un banco y al conectarnos nos aparece una
URL como esta:
http://www.mibanco.com/usuario/cuentas.php?cuenta=1234
Si ahora cambiamos el parámetro cuenta de la URL, por ejemplo por 1235, esta
vulnerabilidad nos permitiría acceder a la página del banco de la persona que tenga la
cuenta 1235, así como realizar acciones en ella.
http://www.mibanco.com/descarga.php?dir=nomina&file=123123.pdf
Podríamos cambiar el valor de estos parámetros «dir» y «file» y acceder a archivos del
servidor.
http://www.mibanco.com/descarga.php?dir=../../../etc&file=passwd
Como se puede ver, no se está haciendo ningún tipo de inyección como en el caso de
XSS; simplemente estamos modificando el parámetro a buscar, por lo que filtrar
parámetros y usar listas blancas no serviría. Para evitar este tipo de vulnerabilidad
podemos:
Eliminar la referencia al objeto.
Sustituir la referencia por un valor temporal de referencia (1, 2, 3, 4…). Aunque
implicaría implementar algún mapa de referencia que permita traducir de uno a
otro.
7. Configuraciones inseguras
Una mala configuración puede tener todo tipo de consecuencias: revelar directorios,
datos de conexión, credenciales, información de la base de datos, modificar ficheros…
Instalación de puertas traseras debido a la falta de parches.
Explotación de XSS debido a falta de parches de seguridad.
Acceso no autorizado a cuentas por defecto.
8. Inyección
La inyección consiste en manipular las entradas de una aplicación para mandar texto
de una forma concreta y que los intérpretes de órdenes lo tomen como comandos y los
ejecuten. Los intérpretes más comunes son SQL, shell del sistema operativo, LDAP,
XPath…
Vamos a ver en profundidad dos tipos de inyecciones en particular, las más usuales, la
inyección de comandos en shell y la inyección SQL.
Inyección de comandos
A veces las páginas web utilizan llamadas a programas en el mismo servidor para
permitir ejecutar al usuario diversas tareas o servicios, como las típicas páginas que
permiten hacer ping a una dirección IP. Pero, ¿qué ocurre si estas páginas no
comprueban la entrada de texto antes de realizar la llamada?
El nivel bajo no realiza comprobación alguna del texto que se introduce por pantalla,
por lo que podríamos usar símbolos de consola para ejecutar una sentencia detrás de
otra como ‘;’ (Linux) o ‘&&’ (Windows).
En el caso del nivel intermedio la página cuenta con un par de restricciones que son:
eliminar los ‘;’ y ‘&&’ que encuentre en el texto introducido. Pero podremos seguir
ejecutando texto a través de las tuberías en Linux ‘|’ o el OR en Windows ‘||’.
No solo los servicios que hacen ping pueden ser vulnerables. Cualquier función que
realice una llamada a algún programa dentro del servidor del estilo cmd(), shell_exec()
o system() y permita al usuario introducir valores dentro, podría serlo.
Inyección SQL
Casi la totalidad de las aplicaciones web en Internet poseen una base de datos, ya sea
para almacenar las credenciales de acceso como para guardar información del
contenido de las páginas. Para acceder a estas bases de datos es necesario un lenguaje
específico para realizar las consultas, así como un intérprete que entienda las consultas
y nos devuelva un resultado. El lenguaje más común de todos, en el ámbito de
aplicaciones web, es SQL y la base de datos más común es MySQL, por eso este tipo de
inyección es la más común.
Nos encontraremos ante una inyección clásica si nos muestra estos errores y ante
una inyección a ciegas (Blind SQL injection) si solo nos muestra información cuando
realizamos una consulta correcta y hay información que mostrar (no es lo mismo hacer
correctamente una consulta pero que una tabla o columna no existan, que hacer mal la
consulta directamente).
Para ambos tipos de SQL injection usaremos como ejemplo la plataforma DVWA, en las
pestañas SQL Injection y SQL Injection (Blind), en las que será vulnerable tanto el nivel
bajo como el nivel medio. En ambas solo dispondremos de un campo de texto.
Nosotros podremos cambiar el parámetro id, por lo que podemos realizar varios test
para comprobar la explotación de la base de datos y averiguar más cosas sobre ella.
El test positivo nos deberá devolver un resultado, mientras que el negativo no debería
devolver nada. Con ello comprobamos si estamos ante un caso de inyección clásica o a
ciegas.
En este caso podemos ver que la respuesta devuelve un error para 3 columnas, por lo
que tendrá 2 (hemos visto en el código fuente que es así, «first name» y «last name»).
Para obtener la versión de la base de datos (podemos ver como se utilizan 2 columnas,
una para la versión y otra siempre con un ‘1’ para que sea correcta la consulta):
Ahora veremos el nivel medio e intentaremos sacar más información, como el nombre
de la base de datos o el nombre de sus atributos. En este caso vemos que la entrada de
texto está un poco más saneada y no permite utilizar algunos símbolos como las
comillas simples.
Figura 60. Nos da error porque el servidor codifica las comillas dobles.
Para solucionarlo tendremos que introducir un valor válido en id, es decir, un número
entero.
Deberíamos repetir los pasos del ejemplo anterior para obtener de nuevo las columnas,
aunque en este caso siguen siendo 2.
El primer paso para obtener toda la información de una base de datos será obtener su
nombre:
El nombre de la base de datos será «dvwa». Para intentar obtener las tablas de esta
base de datos, probaremos accediendo al esquema por defecto de las tablas de las bases
de datos MySQL «information_schema.tables». La consulta sería así:
Pero obtendremos un error ya que no podemos utilizar las comillas en las consultas por
el saneamiento de la entrada de texto. Así que tendremos que obtener el esquema de
todas las tablas de la base de datos, en lugar de solo la que nos interesa y buscar
después la que nos interesa.
Encontramos que tiene dos tablas: guestbook (que podemos suponer que será la que
usa como libro de visitas para la pestaña de XSS almacenado) y users (que podemos
suponer que será donde guarda la información de los usuarios).
1 or NombrePrueba = z
Donde NombrePrueba será el nombre de la columna que pensamos que puede existir
en la base de datos. Podremos encontrar dos tipos de respuesta por parte de la base de
datos, que exista el nombre o que no:
NO EXISTE EXISTE
Una vez descubiertas las columnas, realizamos la consulta final para obtener la
información que queremos.
Ahora vamos a ver un poco blind SQL injection. El problema que nos ocasiona es que
no podremos ver los errores como hemos hecho con la inyección clásica. Aunque
podremos realizar las mismas acciones pero con algunos matices:
Hay que suponer que realizamos correctamente las consultas y cuando no nos
devuelve nada es porque algo a lo que hemos hecho referencia en la consulta no
existe.
Podemos hacer consultas de tal manera que devuelva valores booleanos. Si por
ejemplo no nos dice la versión de la base datos podemos preguntar carácter a
carácter.
1 -> Correcto
0 -> Incorrecto
A la hora de descubrir las tablas y las columnas podemos utilizar de nuevo los
esquemas por defecto, pero podemos codificar en hexadecimal los nombres en lugar
de ponerlos entre comillas (también lo podemos hacer en las inyecciones clásicas).
dvwa = 0x64767761
users = 0x7573657273
Las técnicas para realizar consultas SQL más importantes (algunas de ellas ya las
hemos estado usando) son:
o UNION query-based. Realizar consultas concatenando con la expresión
UNION (la que hemos estado usando).
o Error-based. Cuando no podemos utilizar técnicas como UNION se puede
intentar provocar errores y enviarnos el resultado del error.
o Out-of-Band. Similar al anterior pero intentando enviar todo, tanto errores
como resultados.
o Boolean-based. Se realiza una consulta que devuelve un valor booleano,
utilizando expresiones como LENGTH, ASCII o SUBSTRING.
o Time-based. Esta técnica consiste en enviar una consulta inyectada con la
condición a true y monitorizar el tiempo que tarda un servidor en responder. Si
hay algún retraso, se puede asumir que el resultado de una consulta condicional
es verdadero.
Como ya hemos visto, disponemos de una herramienta para realizar inyecciones SQL,
tanto clásicas como blind: esta es sqlmap, disponible en Kali Linux. Vamos a hacer una
prueba de nuevo con la plataforma DVWA y esta herramienta para sacar las bases de
datos y las tablas de estas.
Al ejecutarlo nos dirá que nos ha redirigido a la página de login, por lo que tendremos
que utilizar una cookie de la sesión que tengamos abierta.
sqlmap --url=“http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#”
--cookie=“security=medium; PHPSESSID=8k2kj7a9454b18lbojv87jc7d6” --dbs
sqlmap --url=“http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#”
--cookie=“security=medium; PHPSESSID=8k2kj7a9454b18lbojv87jc7d6” --schema
--exclude-sysdbs
Para evitar las vulnerabilidades de inyección (tanto las de inyección de comandos como
las de SQL) hay algunas recomendaciones:
Evitar utilizar un intérprete, en los casos que sea posible.
Utilizar una interfaz que implemente variables vinculadas (bind).
o Sentencias preparadas.
o Procedimientos almacenados.
o Las variables vinculadas permiten al intérprete distinguir entre código y datos.
Codificar todas las entradas antes de que lleguen al intérprete, quitando símbolos
que puedan afectar a una consulta.
Validar todas las entradas que provengan del usuario mediante una lista blanca, es
decir, denegar todo por defecto y definir los casos que sí son válidos.
Depurar los privilegios del usuario con el que se accede a la base de datos.
Solamente permitir la lectura de las tablas necesarias (sobretodo restringir el acceso
a las tablas con los esquemas por defecto que hemos visto).
Desactivar la escritura donde sea posible.
Deshabilitar la conexión remota a la base de datos (o filtrarla mediante IP) para que
un atacante no se pueda conectar remotamente.
9. Redirecciones y reenvíos
Muchos sitios web utilizan parámetros de redirección en sus URL; esto se suele
utilizar para redirigir a un usuario a otra página tras realizar una operación.
En muchos casos se utiliza la ingeniería social para conseguir que la víctima abra el
enlace, ya sea por email, foros, chats…
Para un ejemplo podemos suponer un escenario en el que la página de PayPal, cada vez
que haces Log out de tu cuenta te reenvía de nuevo a la página de login de la forma:
https://www.paypal.es?dest=www.paypal.es/login.php
https://www.paypal.es?dest=www.paypalFalso.es/login.php
La URL inicial corresponde con la página oficial por lo que un usuario descuidado
podría fácilmente caer en el intento de phishing.
Subir archivos representa un riesgo para las aplicaciones. Muchos ataques contra
aplicaciones web consisten en dos fases, la primera es conseguir algún código en el
sistema a atacar y la segunda encontrar una manera de ejecutar ese código. Con la
subida de archivos se ayuda a un atacante a conseguir la primera fase.
Hay dos tipos de problemas con la subida de archivos. El primero son los metadatos de
archivos, como el path o el nombre. Estos podrían modificarse al realizarse la petición
de envío HTTP con proxys como Tamper Data, pudiendo subir archivos no permitidos
o sobrescribiendo archivos críticos del servidor. El segundo tipo de problema es el
tamaño del archivo o su contenido. De nuevo se podría modificar con un proxy
permitiendo la subida de archivos maliciosos.
Nota: para que pueda funcionar la subida de archivos es necesario dar permisos 777 a la
carpeta /var/www/dvwa/hackable/uploads con chmod.
En el nivel bajo vamos a insertar subir una webshell como la c99, ya que no tiene
protección alguna contra ningún tipo de archivo. Pero al intentarlo vemos que no nos
deja, así que vamos a probar utilizar Tamper Data para ver qué ocurre.
Vemos que tiene un tamaño máximo de archivo, así que vamos a probar modificarlo.
Ahora si nos dejará subir la webshell y podremos acceder a ella (¡y con permisos de
escritura!):
<?php
$cmd=$_GET[“cmd”];
system($cmd);
?>
También nos dará error, pues la aplicación comprueba el tipo de archivo que se sube,
permitiendo solo aquellos que sean del tipo «image/jpeg».
Recordamos que en la plataforma DVWA si mirábamos con Tamper Data las peticiones
encontrábamos el identificador de la sesión así como la configuración de seguridad:
http://www.ejemplo.com/index...?session_name=sessionid
Normalmente un atacante tiene los mismos privilegios que la víctima a la que usurpa la
identidad, pero puede darse casos en los que la víctima tenga más privilegios y permita
al atacante escalar privilegios o iniciar nuevos vectores de ataque.
http://www.foro.com?SESSID=1234
El usuario hace clic en algún enlace y le llevará a una página maliciosa. En ella, el
administrador de la web podrá ver los logs de las peticiones HTTP y verá en el
campo referer de esta, la URL anterior. El atacante entonces podrá suplantar la
identidad de la víctima utilizando su mismo identificador.
Session fixation. Un atacante realiza una petición de login a una aplicación web y el
sitio web le devuelve un identificador de sesión para que se conecte. En lugar de
introducir sus credenciales, el atacante envía a la víctima a la página de login, con el
identificador de sesión que se le dio al atacante, para que esta introduzca sus
credenciales. Una vez la víctima se haya autentificado, un atacante podrá
suplantarla, pues posee el mismo identificador.
Cifrar los datos se ha vuelto relativamente sencillo para los desarrolladores, ya que la
mayoría de las plataformas lo integran, pero aun así es común ver fallos en su
implementación (o incluso que no se implemente):
Almacenaje inseguro o incorrecto de contraseñas, certificados, claves, etc.
Uso de algoritmos inadecuados (débiles, obsoletos, vulnerables…).
Utilizar una semilla insuficientemente aleatoria para vectores de inicialización.
Intentar desarrollar un sistema de cifrado propio.
Un atacante para romper cifrados débiles o vulnerables puede usar rainbow tables
(tablas con las posibles combinaciones de contraseña-hash de algún algoritmo de
cifrado débil, como MD5 o SHA) o páginas que tengan una base de datos de
contraseñas rotas como:
http://www.md5decrypter.co.uk
Se pueden ver los siguientes artículos para saber más sobre estas técnicas:
http://www.elladodelmal.com/2015/03/bar-mitzvah-nuevo-ataque-ssltls-te-roba.html
http://www.elladodelmal.com/2015/03/ataques-smack-sobre-tls-skip-tls-freak.html
La principal solución para evitar este tipo de fallos es utilizar TLS (actualmente la
última versión es la 1.2) para transmitir toda la información o al menos la información
sensible.
Lo + recomendado
Lecciones magistrales
No dejes de leer…
El siguiente documento pretende mostrar la forma de securizar una red local para uso
doméstico.
SQL Injection
+ Información
A fondo
XSS
Gestión de sesiones
Webgrafía
Owasp
Página web donde encontramos más información del proyecto Owasp y otros
documentos.
Mutillidae
Acunetix
Bibliografía
Actividades
Para ello, se deberán usar tanto técnicas de explotación manual como herramientas
automáticas, por ejemplo, SQLMap.
El alumno deberá explicar y razonar debidamente los pasos dados para la realización de
cada uno de los apartados indicados a continuación.
Apartado 1:
Apartado 2:
Test
7. El ataque que obliga al navegador de una víctima autentificada a enviar una petición
HTTP falsificada es una vulnerabilidad que se conoce con el nombre de:
A. XSS reflejado.
B. CSRF.
C. Session Hijacking.
D. Redirecciones y reenvíos.