Patrones de ataque

Comenzamos esta semana a analizar los patrones de ataque más comunes

en la actualidad. ¿A qué nos referimos con el concepto de patrón de
ataque?

Ya hemos comentado que el trabajo del hacker es en muchos casos

artesanal y que es difícil encontrar dos ataques exactamente iguales, ya
que materializar una amenaza para un activo o para otro, incluso muy
similar, puede implicar diferencias de matiz muy importantes, dependiendo
de una gran cantidad de factores.

A pesar de esto, puede intentar categorizar los ataques haciendo un

análisis de ejemplos reales, intentando comprender cómo se explotan las
vulnerabilidades y debilidades conocidas y extrayendo los aspectos
comunes a estos ataques agrupándolos por patrones. La idea es tener algo
similar a los patrones de diseño de software pero en una vertiente
"destructiva" en lugar de "constructiva". Y así aprender del enemigo,
comprendiendo el problema desde la perspectiva del atacante, para poder
mejorar el nivel de seguridad de las organizaciones.

Estos patrones de ataque son muy útiles en todo el ciclo de vida de un

sistema, desde su diseño y despliegue, pasando por su posterior
configuración, testeo, operación y auditoría. Además, son una herramienta
muy valiosa para la concienciación y formación en ciberseguridad y para
la definición de políticas de seguridad, ya que nos proporcionan una
nomenclatura única y admitida por toda la comunidad.
La ciberseguridad en el contexto actual se basa en conocer al enemigo
(patrones de ataque) y a uno mismo (análisis, auditoría, identificación).

Igual que existe una lista o bases de datos de vulnerabilidades, que permite
a todos los profesionales y herramientas trabajar con los mismos códigos
y nomenclatura (por ejemplo, el CVE que estudiasteis con Isaac la semana
pasada), existe una lista o base de datos de patrones de ataque (también
de MITRE), el CAPEC (Common Attack Pattern Enumeration and
Classification). Debido a que muchas de las vulnerabilidades conocidas
comparten los mismos patrones de ataque, es una base de datos de menor
tamaño (en su última versión contiene cerca de 500 registros, es decir, 500
patrones de ataque diferentes) y que no añade nuevos registros con tanta
frecuencia.

En la siguiente figura puedes observar la entrada en CAPEC para el primer

patrón de ataque que vamos a estudiar esta semana, el de Man in the
Middle.
Ejemplo de descripción de un patrón de ataque en CAPEC.

Como puedes observar, para cada patrón de ataque se realiza una

descripción resumida, se proporciona su flujo de ejecución (etapas del
ataque y pasos realizados en cada una de ellas), las condiciones que deben
cumplirse para que el ataque sea efectivo, el impacto potencial del ataque,
la probabilidad de que este ataque sea efectivo, los métodos utilizados en
el ataque (si se basa en otros, en ciertas herramientas, etc.), ejemplos y/o
demostraciones, el nivel de conocimientos que el atacante necesita, los
recursos y herramientas necesarios, las soluciones, defensas, controles y
contramedidas propuestas para su mitigación, las consecuencias del
ataque para la disponibilidad, integridad, confidencialidad, etc., el vector
de ataque, el payload, la manera en la que se inyecta y el impacto de su
activación, las vulnerabilidades y debilidades (con su código CWE y CVE)
que permiten su realización, otros patrones de ataque registrados en
CAPEC y relacionados con él, los principios de seguridad afectados, los
posibles resultados que el atacante consigue, el contexto técnico afectado
(hardware, sistema operativo, aplicación, etc.), referencias externas y un
histórico en la propia base de datos.

Te recomendamos que dediques un buen rato a navegar por algunos

patrones para que te acostumbres a manejar esta base de datos y el tipo
de información que proporciona:

Puedes utilizar el buscador para localizar patrones de ataque mediante

palabras clave.

Puedes buscar por mecanismo o por dominio de ataque gracias al

diccionario de CAPEC (asociado al esquema con el que clasifican los
patrones de ataque).

Comienza a trabajar con CAPEC

Envenenamiento y suplantación ARP

Toda la pila de protocolos TCP/IP se basa en identificadores a diferentes

niveles y en protocolos dinámicos que permiten traducir entre estos
identificadores de manera transparente a los usuarios y aplicaciones.
Principalmente tenemos como identificadores el nombre de dominio (en la
capa de aplicación se trabaja con URLs), la dirección IP (en la capa de red)
y la dirección MAC (en la capa de enlace de datos). Y como protocolos
dinámicos, DNS para traducir de nombre de dominio a dirección IP, y ARP
(Address Resolution Protocol) para traducir de dirección IP a dirección
MAC (por lo menos en IP versión 4, ya analizaremos lo que ocurre con la
versión 6).

Las técnicas de envenenamiento o poisoning se basan en utilizar estos

protocolos dinámicos de manera que el atacante “envenene” la traducción
empleada por la víctima con una traducción falsa. Si comenzamos
entendiendo este envenenamiento al nivel más bajo, el ARP, el atacante se
aprovecha de que este protocolo (como todos los asociados a TCP/IP y a
Internet) se definió para entornos 100% confiables, por lo que no se
“sospecha” de ninguna respuesta de tipo ARP Reply. Recordemos
brevemente el funcionamiento normal del protocolo ARP. Se trata de un
protocolo muy sencillo que permite que equipos con una tarjeta de red
conectados a un segmento de red envíen tramas de solicitud de traducción
(ARP Request) a la dirección de broadcast de la red (la MAC FF FF FF FF
FF FF) con la dirección IP por la que se pregunta. De esta forma, el equipo
que tenga configurada esta dirección IP en la red responderá con una
trama ARP Reply proporcionando su dirección MAC. Cada equipo
mantiene una caché ARP con las traducciones utilizadas recientemente
para reducir las latencia de funcionamiento y ahorrar ancho de banda en la
red. En el ejemplo de la figura el equipo A puede comunicarse con el B y el
C consultando su caché ARP, mientras que para comunicarse con el D
necesita preguntar primero por su dirección MAC.

Funcionamiento correcto de ARP.

Enviando tramas ARP Reply falsas (es decir, contestando con una
dirección MAC cuando que no corresponde realmente con la dirección IP
por la que se preguntaba en el ARP Request), el atacante consigue
envenenar la cachés ARP de su víctima con una traducción falsa. Como se
trata de un protocolo dinámico, estas tramas se tendrán que enviar
periódicamente para mantener el engaño. En algunos casos, si no ha
habido un ARP Request previo, no se procesa ningún ARP Reply que
proporcione una traducción no solicitada. Pero entonces el atacante puede
servirse de una propiedad de ARP que permite que dentro de un ARP
Request se incluya un ARP Reply, que en este caso, sí se procesaría.

Funcionamiento de ARP cuando un atacante realiza un envenenamiento.

En el ejemplo de la figura se puede observar cómo con este tipo de

envenenamiento, el atacante suplanta al equipo D desde el punto de vista
de la víctima. De hecho, los envenenamientos (los engaños con las
traducciones) suelen utilizarse para suplantar una identidad en la capa de
red correspondiente: con el envenenamiento ARP se consigue una
suplantación o spoofing ARP.

Man in the Middle básico

El patrón de ataque típico que se construye sobre un envenenamiento y
suplantación ARP permite interceptar/modificar todas las comunicaciones
entre dos equipos que se encuentren en el mismo segmento de red que el
atacante (o entre un equipo y su puerta de enlace). Este ataque se suele
denominar Man in the Middle (MitM) o Janus. De hecho, aunque es un
ataque muy frecuente a este nivel, si el envenenamiento y suplantación se
producen en una capa superior de la pila de protocolos con el mismo
objetivo, también se suele denominar así el ataque.

Primera fase de un ataque MitM típico: envenenamiento de las dos caché

ARP de las víctimas.

Si te fijas, en la figura se muestra cómo el atacante consigue ubicarse en

medio de las comunicaciones entre los equipos A y B, envenenando sus
dos cachés ARP. De esta manera, suplanta al equipo B desde el punto de
vista de A, y suplanta al equipo A desde el punto de vista de B. Las tramas
ARP Reply con este envenenamiento deben enviarse periódicamente para
que se mantenga el engaño en el tiempo.
Segunda fase de un ataque MitM típico: intercepción/modificación de las
comunicaciones y re-envío.

En la figura se muestra cómo a partir de este envenenamiento doble el

atacante se sitúa en medio de las comunicaciones entre A y B, pudiendo
interceptar (y si entra dentro de sus objetivos, y la integridad de las
comunicaciones no está adecuadamente protegida, modificar) el tráfico
que va de A a B y el que va de B a A. Si el tráfico está cifrado, será necesario
combinar este ataque con uno de crackeo para romper el sistema
criptográfico empleado para proteger las comunicaciones.
Desgraciadamente en redes de área local en las que se confía en el resto
de los equipos, la mayoría de las veces el tráfico va en texto claro. Por eso
es uno de los patrones más utilizados para robar credenciales (usuarios y
contraseñas, que en muchos casos van en claro) y todo tipo de datos e
información. Es un ataque que puede afectar a la confidencialidad, a la
integridad y al control de acceso; en todos los casos con consecuencias
muy severas.

Además, aunque el tráfico por la red y las latencias de las comunicaciones

aumentan debido a este tipo ataque, si el atacante envía periódicamente
las tramas ARP Reply para mantener el envenenamiento y realiza
correctamente los re-envíos para no levantar sospechas, no son grandes
alteraciones y, por lo tanto, son ataques difíciles de detectar.

Por último, cabe destacar que no es un ataque difícil de realizar ya que

existen herramientas que ayudan a llevarlos a cabo de forma automática.
Esencialmente, se necesita un sniffer de red que permita espiar el tráfico.
La mayor parte de estas herramientas incorporan en la actualidad algún
tipo de plugin o módulo que además permita realizar el envenenamiento de
las cachés ARP de las víctimas. Y en algunos casos, hay herramientas que
integran directamente los módulos de crackeo para descifrar el tráfico
interceptado en el caso de que este estuviera encriptado. Si tienes
curiosidad y quieres hacer alguna prueba (siempre en un entorno simulado
y controlado, por favor, nunca hagas estas pruebas en redes corporativas
reales), puedes comenzar con Ettercap, Network Miner y Caín.

¿Cómo podemos protegernos de este tipo de ataques? Lo estudiaréis más

adelante, en las semanas dedicadas a las contramedidas en este MOOC,
pero para que vayáis relacionando conceptos, hay dos medidas
esenciales: la encriptación de las comunicaciones a diferentes niveles
(para proteger la confidencialidad, pero también la integridad de los datos
que se envían) y la autenticación de los extremos de las comunicaciones.

Man in the Middle sin visibilidad

Supongamos ahora que la víctima de ataque no está en el mismo segmento

de red que el atacante, pero sí lo está su puerta de enlace, es decir, el router
que le da acceso a Internet (o a otra red).

En este caso, con un robo de puerto en el router (un ARP poisoning pero
en la CAM o Content Adressable Memory del router), se pueden interceptar
las comunicaciones que vienen de Internet (o de otra red) hacia la víctima.
Lo que no se puede hacer es envenenar la caché ARP de la víctima, por lo
que no se puede suplantar al router desde su punto de vista. Esto implica
que no se pueden hacer re-envíos y por lo tanto, este ataque sólo afecta a
la confidencialidad, en algunos casos al control de acceso y en ningún
caso a la integridad. También se pueden considerar que afecta a la
disponibilidad, ya que la víctima pierde la conectividad con su puerta de
enlace momentáneamente.

La secuencia habitual sería la siguiente:

Paso 1:

Paso 2:

Paso 3:
Paso 4:

Man in the Middle en IP version 6

En ocasiones se asocian los ataques MitM con el protocolo ARP y por lo
tanto con la versión 4 del protocolo IP (ya que IPv6 resuelve la traducción
de direcciones de manera diferente). Pero en entornos en los que convivan
las dos versiones o incluso que funcionen, sólo con IPv6 también pueden
darse este tipo de ataques. La diferencia está en el patrón empleado para
llevar a cabo el ataque, pero sus consecuencias son las mismas. Aquí
tienes cuatro ejemplos muy habituales de patrones que se empleen con
IPv6:

Rogue DHCPv6. En un intento de evitar los problemas de seguridad que la

auto-configuración puede provocar, muchas organizaciones siguen
prefiriendo utilizar DHCP (ahora ya en su versión 6) para controlar la
configuración de direcciones, puertas de enlace y servidores DNS de los
equipos de la red. Pero esto presenta dos problemas. El primero, siguen
utilizándose los mensajes RA (Router Advertisement), por lo que pueden
seguir siendo utilizados de manera maliciosa. El segundo, como ocurría en
las anteriores versiones de DHCP, un atacante puede montar un servidor
DHCP falso que sirva configuraciones maliciosas a sus víctimas o que
modifique a posteriori las que sirvan los servidores DHCP de la
organización. Si por ejemplo configura como puerta de enlace un equipo
controlado por él, podrá llevar a cabo un ataque MitM.

Neighbour Spoofing. En IPv6 se maneja el concepto de "vecinos de red"

mediante el protocolo Neighbour Discovery Protocol (NDP), que no es más
que un subconjunto de mensajes ICMPv6. El funcionamiento normal es que
un equipo envíe un mensaje de Neighbour Solicitation (NS) a una dirección
multicast de la red cuando vaya a comunicarse con un equipo y que el que
tenga esa dirección IPv6 responda al mensaje multicast con un mensaje
unicast de Neighbour Advertisement (NA) con su dirección MAC. El
receptor del mensaje NA almacenará en su caché de vecinos la dirección
IPv6 y la dirección MAC asociada. Un atacante puede envenenar estas
cachés de vecinos para realizar un ataque MitM suplantando a A para B y
a B para A mediante mensajes NA con las traducciones de direcciones
falsas.
ICMPv6 redirect. ICMPv6 permite utilizar mensajes de Redirect para
modificar dinámicamente las tablas de encaminamiento de un equipo, si,
por ejemplo, para llegar a un destino concreto de la red es más rápido ir
por una nueva ruta (por cambios en la topología de red, por congestión,
etc.). Un atacante puede utilizar estos mensajes de manera maliciosa y
provocar que todo el tráfico saliente (o por lo menos el de su víctima) pase
por él, haciendo así un MitM.

SLAAC Attack. La mayor parte de sistemas operativos en la actualidad

están configurados por defecto para dar preferencia al uso de IPv6 sobre
el de IPv4. Y IPv6 está diseñado para auto-configurarse al máximo (incluso
sin apoyarse en DHCP), lo que permite que un router IPv6 utilice mensajes
RA (Router Advertisement) para anunciarse en una red y que otros equipos
se configuren dinámicamente para utilizarlo como puerta de enlace. Un
atacante puede introducir un router malicioso en una red que trabaja con
IPv4 (basta un equipo con dos tarjetas, una de ellas configurada con una
dirección IPv6) para conseguir que el tráfico hacia la red exterior (por lo
menos el de su víctima) pase por él, haciendo así un MitM. En una red que
trabaje con IPv6 este ataque también puede tener éxito, aunque el router
malicioso tendrá que "competir" con los mensajes RA de los routers que
de verdad lo son.

Envenenamiento, suplantación y MitM en capas superiores

Como ya hemos mencionado, los ataques de envenenamiento,

suplantación y Man in the Middle se pueden dar a niveles superiores que
el de la capa de enlace. Existen muchas variedades de ataques en estas
capas superiores, vamos a ver a continuación tres ejemplos de patrón de
ataque que se pueden utilizar para que la víctima acabe visitando un
servidor que suplanta a uno de su confianza y que sin embargo, está
controlado por el atacante.
Estos patrones que acabas de estudiar en el vídeo también se utilizan muy
a menudo para robar credenciales (usuarios y contraseñas, que en muchos
casos van en claro) y todo tipo de datos e información, simplemente
consiguen estos objetivos en un nivel superior que los construidos sobre
ARP. Son ataques que pueden afectar a la confidencialidad, a la integridad
y al control de acceso, en todos los casos con consecuencias muy severas.
De nuevo hay que mencionar que son ataques difíciles de detectar para la
víctima, aunque en este caso son mucho más sofisticados y por lo tanto,
más difíciles de automatizar (por lo menos con herramientas sencillas), por
lo que exigen un nivel de conocimientos mayor por parte del atacante.
¿Cómo podrían mitigarse? Como estudiaréis más adelante en el MOOC, de
nuevo son esenciales los protocolos de comunicaciones seguras a
diferentes niveles y la autenticación de los extremos de la comunicación.

Secuestros de sesión

En los patrones de ataque estudiados al principio de esta semana el

objetivo principal era suplantar a un equipo en alguna capa de la pila de
protocolos TCP/IP para poder realizar un robo de credenciales y/o de
información. ¿Qué ocurre si un atacante tiene estos objetivos pero no es
capaz de construir un ataque de spoofing como los que hemos visto?
Siempre puede recurrir a otro patrón denominado secuestro de sesión. En
este caso, el atacante no puede iniciar la sesión cuando él quiera, ya que
no puede realizar un robo de credenciales completo, sino que tiene que
esperar a que su víctima inicie la sesión, y cuando ésta ya esté establecida,
secuestrarla. Veamos los ejemplos más típicos.

Como has podido observar en el vídeo, con este patrón de ataque el

atacante puede afectar a la confidencialidad, a la integridad y a la
disponibilidad (ya que la víctima pierde su sesión en algunos casos). Esta
pérdida de disponibilidad hace que el ataque sea algo más sencillo que
detectar que en el caso de otros patrones, pero con cierta habilidad el
atacante puede dificultar esta detección, por ejemplo, forzando re-
sincronizaciones de la conexión. Y si el atacante se encuentra en la misma
red que su víctima, se trata de un patrón que no requiere de altos
conocimientos, ya que además existen distintas herramientas que facilitan
su construcción como Juggernaut o Hunt. En el vídeo se analiza cómo el
ataque es más complejo cuando el atacante no se encuentra en la misma
red que su víctima y se trata de una sesión TCP, ya que tiene que realizar
el secuestro "a ciegas", adivinando el número de secuencia con el que
entrar en la conversación entre cliente y servidor. Por desgracia, estos
números de secuencia no se inicializan siempre de forma aleatoria y se
pueden llegar a adivinar (automatizando la tarea) conociendo lo suficiente
acerca del funcionamiento del protocolo TCP.

En cuanto a las contramedidas, de nuevo la utilización de protocolos de

comunicaciones seguros (basados en criptosistemas fuertes) y de
mecanismos de autenticación, serían las básicas.

Denegaciones de servicio volumétricas

Vamos a estudiar a continuación una serie de patrones de ataque

tradicionales (en cuanto a poco sofisticados o no basados en
vulnerabilidades recientes), casi siempre basados en la fuerza bruta y
mucha veces construidos sobre técnicas conocidas desde hace años, que
preocupan mucho a todas las organizaciones en la actualidad porque están
dirigidos específicamente a perjudicar la disponibilidad, y por tanto, a
provocar denegaciones de servicio (DoS o Denial of Service). Este tipo de
resultado ha demostrado generar importantes pérdidas económicas y
dañar significativamente la reputación de las organizaciones en diferentes
sectores. Junto con las brechas de datos, son probablemente las
amenazas que más preocupan en la actualidad (ya mencionamos algunos
ejemplos de este tipo de ataques en la primera semana del MOOC
¿recuerdas?).
Amenazas que suelen preocupar más en la actualidad, ambas con
importantes efectos económicos para las víctimas.

Los ataques de denegación de servicio se centran en hacer un servicio,

aplicación o sistema no disponible para sus usuarios o clientes. Hasta el
año 2012 no eran ataques muy extendidos ni con consecuencias
demasiado graves, pero su crecimiento ha sido exponencial desde
entonces. En concreto, el de los ataques distribuidos (DDoS o Distributed
Denial of Service), gracias al relativamente fácil acceso a botnets (como
estudiareis con Isaac más adelante, redes de equipos infectados con algún
tipo de malware que permite a los atacantes controlarlos de manera
remota) y a kits específicos (que liberan a atacantes inexpertos de
programar sus propios scripts). Incluso se han lanzado recientemente
servicios de DoS que cobran una suscripción temporal, y que se pueden
controlar desde una aplicación en el móvil.

Los peores ataques observados hasta el momento han sido,

probablemente (es difícil tener medidas exactas), el ataque al sitio web de
la BBC a principios de 2016, con más de 600 Gb/s (a veces este pico se
expresa en megapaquetes por segundo o Mp/s para medir la velocidad en
lugar del ancho de banda) y el ataque al proveedor de DNS Dyn a finales
del mismo año, con más de un 1.1 Tb/s. Este último ataque se lanzó desde
la botnet de dispositivos en Internet of Things denominada Mirai y dejó
innacesibles importantes webs y servicios de Internet en varias
oleadas. Para que te hagas una idea, de las 2000 organizaciones más
importantes del mundo un porcentaje muy alto (más de tres cuartas partes,
seguro) hubiera caído con este ataque. Y ten en cuenta que para estas
compañías, el coste del downtime es en media de 1 millón de dólares al
día. Más de la mitad del tráfico generado para realizar ataques DDoS en el
año 2016 provenía de países de la zona de Asia Pacífico (China, India,
Tailandia, Japón) y alrededor de un 20% de EEUU. Los objetivos son
principalmente EEUU y China, en plena guerra económica y utilizando en
ella la ciberseguridad prácticamente todos los días. Puedes observar esto
con aplicaciones y servicios del estilo de DigitalAttackMap de Arbor (esta
herramienta es sólo a nivel ilustrativo, pero hay paneles comercializados
como herramientas de ciberseguridad que dan información muy precisa en
tiempo real que puede resultar tremendamente útil).

Los principales sectores objeto de estos ataques, debido a sus objetivos

eminentemente económicos, son el financiero, el tecnológico (TIC en
diferentes ámbitos, proveedores cloud, plataformas de videojuegos o
proveedores de telefonía y telecomunicaciones por mencionar algunos
ejemplos), el de los medios de comunicación y cada vez más, el industrial,
el educativo y en general, el sector público.

Conceptos básicos en la denegación de servicio

Como ya hemos comentado, la denegación de servicio se considera una

de las principales amenazas en la actualidad. De hecho es la amenaza por
excelencia para la disponibilidad de los activos. Pero ¿qué tipo de patrones
de ataque se utilizan en la actualidad para materializar esta amenaza?

Los ataques de denegación de servicio actuales suelen basarse en

ataques de suplantación o spoofing en una o varias capas de red y en
vulnerabilidades de servidores y equipos que contribuyan al ataque
involuntariamente (suelen denominarse víctimas para distinguirlas del
target u objetivo del ataque). Estas víctimas también suelen sufrir
denegación de servicio en cierto grado, ya que se consumen recursos
suyos para construir el ataque y esto degrada su rendimiento. Pero
normalmente, no al mismo nivel que se degrada el del target del ataque. La
suplantación se necesita porque al contrario que en los ataques clásicos,
que se basaban en la inundación o flood provocada desde el atacante, los
actuales se suelen basar en el reflejo (reflection) a través de las víctimas.
Ahora lo comprenderás mejor.

Si intentamos extraer un patrón estándar para las denegaciones de

servicio, sería el que se muestra en la siguiente figura.

Patrón de ataque para una denegación de servicio.

Como puedes observar, el atacante, después de la fase de recogida de

información, debe decidir con qué protocolo de red va a construir el ataque
y por qué puerto. Veremos a continuación cómo estos protocolos pueden
estar a nivel infraestructura o a nivel aplicación.

Después se seleccionan las víctimas que van a contribuir

involuntariamente al ataque, estas víctimas suelen ser servidores o
equipos vulnerables o infectados con algún tipo de malware que permite
que el atacante los controle a su voluntad (incluso formando parte de una
botnet completa). Incluso hoy en día es posible alquilar una botnet para
construir el ataque pagando por horas.

El siguiente paso es que el atacante, suplante al target del ataque en la

capa de red necesaria (siempre que sea necesario, a veces no lo es). Y
como el objetivo es "inundar" a este target con tráfico (o peticiones) que le
impida realizar sus labores adecuadamente (se habla de ataques
volumétricos, porque se busca un volumen suficiente para consumir todo
el ancho de banda del target o conseguir que deje de dar servicio por el
colapso de alguno otro de sus recursos), después se busca la manera de
amplificar este tráfico en todo lo posible. La amplificación se puede realizar
de dos formas:

Amplificación por tamaño de paquete: Es decir, se aumenta en todo lo

posible el tamaño de cada paquete que se consigue que llegue al target
durante la construcción del ataque (entendiendo tamaño de diferentes
maneras según se construya el ataque, puede ser en bytes pero también
en la cantidad de cómputo que se requiere del servidor, por ejemplo).

Amplificación por distribución (DDoS o Denegación de Servicio

Distribuida): Se consigue que más de una víctima colabore en el ataque,
de manera que el tráfico provenga de muchas fuentes diferentes. Este tipo
de técnica, no sólo amplifica el ataque, sino que dificulta su mitigación, ya
que si el tráfico tiene una única fuente, con un filtrado por dirección de
origen se puede resolver, por lo menos temporalmente.

Por último, hay que tener en cuenta que estos ataques suelen prolongarse
durante unas horas, por lo que la fase de automatización mediante
scripting o cualquier otro tipo de herramienta hace que el atacante lo lleve
a cabo de manera más cómoda. Algunas herramientas conocidas son
LOIC, XOIC, HULK o RUDY.
Amplificación por tamaño de paquete y por distribución en un ataque de
denegación de servicio.

Patrones de ataque para DoS en la capa de infraestructura

Utilizando como vector de ataque un protocolo tradicional de la

infraestructura de Internet es como la mayor parte de los atacantes
construyen en la actualidad las denegaciones de servicio. En el siguiente
vídeo trataremos de entender cómo se consigue esto, primero con dos
protocolos clásicos como TCP y DNS y luego con otros dos, que aunque
tienen también unos años (NTP y SSDP), sólo se han comenzado a utilizar
para construir DoS recientemente.

Como has podido observar cualquier protocolo de infraestructura que

permita realizar un "reflejo" (reflection), es decir, provocar que la víctima
responda al target debido a la suplantación que el atacante realiza, es
susceptible de ser utilizado para construir una denegación de servicio.
Además, ciertos protocolos son especialmente interesantes para los
atacantes por su capacidad de amplificación: o por tamaño de paquete (es
fácil de incrementar manipulando las peticiones) o por distribución (las
potenciales víctimas son muchas). En este sentido, Internet of Things está
proporcionando una plataforma sin precedentes para las denegaciones de
servicio, ya que en este contexto se ponen a disposición de los atacantes
millones de dispositivos de consumo, normalmente diseñados y
desplegados sin conciencia de seguridad, y que pueden ser empleados
como víctimas para llevar a cabo ataques de una gran magnitud. Incluso
nuestros teléfonos móviles pueden colaborar en este tipo de ataque sin ser
nosotros conscientes.

Patrones de ataque para DoS en la capa de aplicación

Aunque estos patrones son mucho menos frecuentes (están suponiendo

alrededor de un 10% del total de los ataques DoS), conviene conocer cómo
se realizan. La mayor parte de estos ataques utilizan como vector de ataque
el protocolo HTTP.

Recordemos con este protocolo se utilizan principalmente dos tipos de

peticiones, el HTTP GET para recuperar de un servidor o aplicación web
contenido estático (texto, una imagen) y el HTTP POST para recuperar
contenido dinámico (formularios, comentarios). Nos vamos a centrar a
continuación en los ataques que utilizan estos dos tipos de peticiones,
aunque en principio, un atacante podría utilizar cualquiera de los otros
tipos de peticiones que HTTP permite para provocar la denegación de
servicio, es menos común, pero también se utiliza.

Recordatorio de la diferencia entre un HTTP GET y un HTTP POST.

Con un ataque construido sobre peticiones HTTP GET, lo que se pretende

es inundar al servidor o aplicación web (HTTP flood) con más peticiones
por segundo de las que puede manejar, de manera que esto provoque la
denegación de servicio. Este tipo de ataques se amplifica, sobre todo, por
distribución, ya que el tamaño de las peticiones y respuestas no suele
poder amplificarse demasiado. Para este tipo de ataques se está
observando la ya mencionada utilización de dispositivos móviles y de
consumo conectados a Internet of Things como víctimas sencillas y
numerosas desde las que lanzar las peticiones.

En cuanto a los ataques construidos sobre HTTP POST, la idea es la misma

pero la amplificación se puede conseguir no sólo mediante distribución,
sino también mediante la manipulación de los parámetros del protocolo
utilizado para construir el ataque. Con cada petición HTTP POST se puede
conseguir que el servidor o aplicación web target del ataque tenga que
realizar tareas intensivas en cómputo, lo que acelera la denegación de
servicio.

Si te fijas, a diferencia de los ataques en la capa de infraestructura, en el

caso de los ataques en la capa de aplicación no suele ser necesario utilizar
ningún tipo de suplantación ni de reflejo. Basta con conseguir peticiones
HTTP correctas y válidas desde diferentes fuentes al mismo tiempo. Ahí
radica la dificultad de detectar y mitigar este tipo de ataques, porque
¿cómo distinguimos las peticiones que vienen del atacante de las que
vienen de nuestros usuarios?

Es complicado distinguir entre las peticiones "buenas" y las "malas".

Contramedidas para mitigar las denegaciones de servicio

Aunque en próximas semanas del MOOC nos centraremos en explicar en
detalle las contramedidas que más se despliegan en la actualidad, vamos
a comentar brevemente las más extendidas para la mitigación de ataques
de denegación de servicio. Obviamente es importante dificultar que los
atacantes utilicen nuestros recursos para colaborar involuntariamente en
ataques como víctimas (configurando correctamente los servidores DNS y
NTP, por ejemplo, o evitando que troyanos u otros tipos de malware
conviertan nuestros equipos en zombies dentro de una botnet).

Si nos centramos en defensas específicas para los potenciales targets:

Es imprescindible para un potencial target realizar un cierto grado de over-

provisioning de recursos (aunque con el volumen de los ataques actuales,
si se trata de un ataque distribuido, hay que asumir que no hay cantidad
de recursos que los pueda mitigar).

También es muy importante contar con soluciones de tolerancia a fallos y

con un buen plan de respuesta ante incidentes y de continuidad del
negocio.

Por último, como medidas genéricas, es importante que los firewalls de

perímetro tengan la posibilidad de filtrar el tráfico por región geográfica,
por dirección de red y por dirección IP de origen, incluso trabajando con
sistemas de reputación, de manera que se manejen listas con direcciones
IP sospechosas de ser origen de ataques DoS.

En el caso de las contramedidas específicas para los ataques volumétricos

en la capa de infraestructura, se puede intentar limitar el número de
mensajes ICMP Destination Unreachable con los que el target responde en
el caso de los ataques por UDP flood o evitar el spoofing en los ataques de
SYN reflection con el uso de cookies o tokens para la autenticación del otro
extremo de la conexión.

Para mitigar los ataques en la capa de aplicación, han surgido proveedores

específicos que ayudan con sus cleaning-centers y productos o servicios
similares a distinguir entre el tráfico legítimo y el generado por los
atacantes y las víctimas que controlan, normalmente mediante análisis de
comportamiento, patrones, anomalías, etc.

Introducción a los ataques por desbordamiento

En esta unidad subimos un poco de nivel y nos centramos en patrones de

ataque que aprovechan casi exclusivamente debilidades y/o
vulnerabilidades del código de las aplicaciones, no de los protocolos de
red como habíamos estudiado hasta ahora.

Un ataque por desbordamiento (overflow) aprovecha una vulnerabilidad

del software que permite ejecutar cualquier código en el sistema
vulnerable, con los mismos permisos que la aplicación que presenta la
vulnerabilidad por no comprobar el tamaño de los parámetros que se
pasan a una función o procedimiento en tiempo real. ¿Qué tipo de
aplicaciones pueden ser vulnerables a este tipo de ataques? En principio,
cualquiera que utilice un buffer en memoria, que no compruebe
adecuadamente el tamaño de los parámetros que se escriben en ese buffer
y que ponga a disposición del atacante un vector que le permita acceder a
estos parámetros para manipularlos según sus objetivos.
Ranking Common Weakness Scoring System (CWSS), el buffer overflow
clásico aparece, todavía en el 2016, en el tercer puesto.

Según el ranking Common Weakness Scoring System (CWSS) el buffer

overflow clásico está en el tercer puesto, con una puntuación de 79 sobre
100 y sólo por detrás de la inyección de código SQL y de comandos en el
sistema operativo.

Este tipo de vulnerabilidades se conocen desde finales de los años 80, pero
multitud de sistemas operativos, aplicaciones y navegadores la siguen
teniendo. En general, para construir un ataque de este tipo, lo primero que
tiene que hacer el atacante es localizar un buffer que desbordar, y este
buffer puede ubicarse en la pila (stack) o en el montón (heap), que no son
más que zonas de la memoria del proceso en las que se almacenan
punteros, valores de variables, etc. A continuación, el atacante tiene que
localizar la manera de aprovechar el exceso de datos que se van a
almacenar en este buffer.
Pila y montón en la memoria de ejecución de un proceso.

Si el objetivo del atacante es afectar a la disponibilidad (es decir, provocar

una denegación de servicio, pero no con técnicas volumétricas como las
ya estudiadas), le basta con provocar un fallo en la aplicación, por lo que
estos datos excesivos pueden ser un conjunto de datos aleatorio. Pero si
el objetivo del atacante es afectar a la confidencialidad, la integridad o el
control de acceso, tendrá que manipular estos datos excesivos para
conseguir que se ejecute un código que sirva a sus objetivos.

El primer tipo de patrón es más fácil de ejecutar y no hacen falta

conocimientos avanzados, eso sí, se detecta inmediatamente. En el
segundo caso, es un ataque de construir (prácticamente artesanal) y de
detectar por parte de la víctima.

Buffer overflow clásico

Vamos a intentar explicar en el siguiente vídeo cómo puede un atacante

construir un ataque de buffer overflow, y para ello nos vamos a servir del
ejemplo del desbordamiento de pila, más sencillo de entender

Como has podido observar, conseguir una denegación de servicio a partir

de un ataque de desbordamiento es bastante sencillo, ya que basta con
pasar a la aplicación vulnerable una cadena de datos aleatorios. Sin
embargo, conseguir otro tipo de objetivos es más complejo e implica un
grado de conocimientos (memoria de ejecución de un proceso, punteros,
peculiaridades de cada lenguaje de programación, shell coding, etc.)
bastante mayor por parte del atacante.

En cuanto a las contramedidas, la básica implica siempre la comprobación

del tamaño de los parámetros que se pasan a los procedimientos y el
testeo de las aplicaciones, con las diferentes técnicas disponibles en la
actualidad, para corroborar que estas comprobaciones se hacen en todos
los casos. Pero ¿qué ocurre si no tenemos acceso al código de la
aplicación vulnerable? ¿O si lo tenemos, pero no se puede modificar? En
estos casos se puede recurrir a proteger la memoria de ejecución de los
procesos desde el propio hardware y sistema operativo, a proteger el
perímetro con firewalls DPI (Deep Packet Inspection) que puedan detectar
paquetes sospechosos en la interacción con la aplicación, etc. Ya lo
estudiaremos más adelante en el MOOC, no te preocupes, que
dedicaremos dos semanas completas a las contramedidas.

NOP-sled y otros trucos

Una de las dificultades de construir un ataque de buffer overflow está en

conseguir sobre-escribir en la dirección de retorno la dirección en la que
comienza el shell-code que se desea ejecutar. La dirección de inicio del
shell-code puede ser difícil de predecir ya que depende del sistema
operativo y del compilador, de las variables de entorno (tipo y número), etc.
Aunque se intenta ubicar este shell-code justo al principio de la pila (que
suele ser más fácil de localizar) cualquier fallo en este direccionamiento
puede provocar un Segmentation Fault y alertar a la víctima del ataque.

Para tener un poco de margen, los atacantes suelen utilizar la técnica del
NOP-sled. Todos los repertorios de instrucciones contienen alguna
instrucción de tipo NOP (No operación), que no hace ningún trabajo útil.
Los atacantes pasan en el parámetro que se utiliza para provocar el
desbordamiento el shell-code que se desea ejecutar, una secuencia de
instrucciones NOP y de vez en cuando, una instrucción de salto
incondicional (para saltar ciertas zonas de la pila y para llegar hasta el
shell-code especificando la dirección destino de salto con un offset
relativo) que salta al inicio de la pila. Siempre y cuando el tamaño del
código no sobrepase el tamaño del buffer, esta técnica garantiza muchas
más probabilidades de éxito.

Introducción a los ataques por inyección

Los patrones de ataque basados en inyección de comandos o de código

siempre se basan en el mismo principio: una aplicación acepta una entrada
del usuario (input) sobre la que construye un comando o código, no la filtra
adecuadamente, y entonces un usuario malicioso puede aprovechar para
inyectar, gracias a esta entrada, comandos o códigos que le sirvan para
conseguir sus objetivos. La entrada puede ser introducida por el usuario a
través de la línea de comandos o shell del sistema operativo, a través de
un formulario web o incluso a través de cookies o de la URL, depende de
la aplicación que presente la vulnerabilidad.

Patrones de ataque por inyección de comandos o de código.

Aunque los patrones de inyección suelen asociarse con las bases de
datos, se pueden inyectar comandos y códigos en otro tipo de aplicaciones
vulnerables.

Este tipo de patrones de ataque suelen ir dirigidos a vulnerar la

confidencialidad, la integridad o el control de acceso (raramente la
disponibilidad, aunque en ocasiones se utilizan para borrar ficheros o
incluso bases de datos completas, y esto puede afectar mucho a la
disponibilidad), su potencial impacto es muy alto y en muchos casos no
hacen falta grandes conocimientos para construirlos. De hecho, si
recuerdas la primera pantalla de esta unidad, las dos debilidades
consideradas más graves por el CWSS son dos inyecciones, la SQL y la de
comandos en el sistema operativo. Y según el conocido proyecto OWASP
Top10, es la primera amenaza en el caso de aplicaciones web (lo era en la
versión del 2013 y parece que lo va a seguir siendo en la versión del 2017,
todavía en borrador).

Descripción de los ataques por inyección según OWASP (en el año 2013)
en el caso de aplicaciones web.
Veamos el ejemplo clásico de inyección de comandos. En la siguiente
figura se muestra un código que permite a los administradores de un
sistema Unix/Linux ver el contenido de un fichero pero no modificarlo.

Programa sencillo para que un administrador vea el contenido de un

fichero.

Este código se ejecuta con los permisos necesarios para que el

administrador vea el contenido de los ficheros que necesite. Supongamos
que queremos que vea el contenido de cualquier fichero, entonces, se
ejecutará con privilegios de root. Si el administrador le pasa a este
programa como argumento "nombre_de_fichero", todo funciona como se
esperaba, y lo único que ocurrirá es que se mostrará por pantalla el
contenido de ese fichero.

Pero el código de la figura es vulnerable a inyección de comandos, así que

si el administrador pasa como argumento "nombre_de_fichero ; rm -rf /",
habrá inyectado un comando que borrará recursivamente todo el
contenido de la partición /. Y esto es sólo un ejemplo, cualquier usuario
malicioso podría aprovecharse de la vulnerabilidad de este código (por no
comprobar los parámetros de entrada proporcionados por el usuario) para
inyectar comandos en el sistema operativo.

Inyecciones SQL
SQL (Structured Query Language) es un lenguaje declarativo de acceso a
bases de datos relacionales, que permite efectuar consultas, y en general,
interactuar con esta bases de datos de manera sencilla. Probablemente la
inyección SQL sea el tipo de ataque de inyección más conocido (aunque
también se pueden realizar ataques por inyección con LDAP o con XPath,
por mencionar algún ejemplo más), y aún así, todavía muchas aplicaciones
en la actualidad presentan vulnerabilidades que permiten que se explote.
Estas vulnerabilidades permiten que un atacante añada a una consulta SQL
legítima, sentencias SQL que le permitan conseguir sus objetivos. Como
dice el chiste...

Problemas provocados por no comprobar los parámetros de entrada en

entornos SQL...

Para que lo puedas entender bien, en el siguiente vídeo vamos a analizar

los dos patrones típicos de inyección en entornos SQL.

A veces las inyecciones clásicas se denominan in-band SQL para

distinguirlas de otros tipos de patrones de ataque que han surgido con
posterioridad como por ejemplo, las inyecciones a ciegas o "blind"
(inferential, boolean, time-based; puedes encontrar cualquiera de estas
denominaciones para los últimos patrones). Lo que caracteriza a este tipo
de inyección clásica es que se utiliza el mismo canal de comunicación para
lanzar el ataque que para recoger los resultados, al contrario de en las que
hemos estudiado al final del vídeo.

Los ejemplos que se han mostrado en el vídeo son los clásicos con
formularios en aplicaciones web, pero recuerda que este no es el único
punto de entrada para una consulta SQL construida con valores
proporcionados por el usuario. Las inyecciones de código pueden
aprovechar cualquier punto de entrada de parámetros, como los
parámetros en la URL o los valores almacenados en cookies.

Y como has podido ver, la defensa principal y más efectiva es la

comprobación de estos parámetros antes de la construcción de la consulta
o la parametrización de estas consultas, no el filtrado de las respuestas
desde la base de datos, porque este filtrado puede hacerte vulnerable a
ataques de inyección a ciegas. Este es un ejemplo claro de que la
seguridad por oscuridad no suele funcionar.

Introducción a los ataques por forgery

Este tipo de ataques por forgery o falsificación pretenden crear, imitar o

adaptar un entorno, aplicación o servicio real con el propósito de engañar
a la víctima con intenciones maliciosas, casi siempre, que se ejecute algún
tipo de script en el contexto de su navegador. El ataque más común de este
tipo es el Cross Site Scripting (XSS) a aplicaciones web, aunque existen
multitud de patrones que entran dentro de esta categoría. Diferentes
estudios cuantifican en como mínimo un 50% los sitios web que presentan
vulnerabilidades que permiten realizar este tipo de ataques y todas las
clasificaciones y estudios las consideran como una de las principales
amenazas en la actualidad (puedes comprobarlo en la lista del CWSS o en
el proyecto OWASP Top10). Al contrario de lo que ocurre con los
desbordamientos y las inyecciones, que pueden afectar a distintos tipos
de software, en este tipo de patrones estamos centrándonos
específicamente en aplicaciones web.

Hay que tener en cuenta que las aplicaciones web se construyen

habitualmente mezclando elementos fijos (contenido estático) con
información que proviene de una base de datos (contenido dinámico),
incluso esta información contenida en la base de datos la pueden
actualizar los propios usuarios (foros, blogs, etc.). Para crear este tipo de
aplicaciones se utilizan Java, PHP ó Visual Basic. Por ejemplo, cuando un
usuario visita un foro, la web que se le muestra está compuesta por HTML
estático y HTML dinámico con los mensajes enviados por todos los
usuarios. Permitiendo que se trabaje en HTML es más fácil que puedan dar
formato, insertar links o imágenes, etc. Usuarios maliciosos pueden
aprovechar estos componentes dinámicos para conseguir sus objetivos si
no se comprueban, filtran y/o ignoran adecuadamente.

Recordatorio de las diferencias entre HTML estático y HTML dinámico.

Este tipo de vulnerabilidades pueden sufrirse tanto en el lado cliente como

el lado servidor, por lo que las defensas y contramedidas serán
responsabilidad de ambas partes. Aunque es difícil generalizar, porque se
trata de una categoría en la que entran muchos patrones de ataque
diferentes, se puede decir que son ataques muy extendidos, que necesitan
de un nivel de conocimientos medio por parte de los atacantes y que
pueden utilizarse para afectar a la confidencialidad, integridad y control de
acceso (muy raramente a la disponibilidad).

El impacto de estos ataques depende mucho del objetivo perseguido por

los atacantes. Uno de los contextos en los que más se ha utilizado
recientemente es para el robo de credenciales (sobre todo en forma de
cookies de sesión) en combinación con campañas de phishing o
aprovechando vulnerabilidades en servidores, como veremos dentro de un
momento. Pero también se emplea para realizar keylogging, para robar
información sensible o cuentas, para modificar información, etc.

Ejemplo típico de patrón de ataque con XSS.

Cross Site Scripting (XSS)

Vamos a intentar comprender con dos ejemplos sencillos los dos patrones
de ataque típicos con XSS, el no persistente y el persistente, en ambos
casos con el objetivo que mencionábamos de robar las cookies de sesión
de sus víctimas.

Como ya analizábamos antes, las defensas y contramedidas para mitigar

este tipo de amenazas tienen que estar en el lado del cliente y en del
servidor. Por ejemplo, el cliente no debe pinchar nunca sobre un link desde
un email, ni su gestor de correo electrónico descargar contenidos que
pueden esconder links maliciosos. Además, su navegador tiene que estar
configurado adecuadamente para que no se ejecuten scripts de manera
transparente. En cuanto al servidor, se debería comprobar lo que se copia
en el contenido de la web, a través del JavaScript o el contenido dinámico
con el que los usuarios alimentan la base de datos.

Además, se podrían detectar sesiones simultáneas del mismo usuario (por

lo menos desde direcciones IP diferentes, lo que es, al menos
sospechoso), utilizar autenticación multi-factor (por lo menos para realizar
ciertas tareas), etc. Lo iremos viendo en las próximas semanas.

Más XSS

Los dos patrones de ataque que hemos aprendido en el vídeo anterior no

son, ni mucho menos, los únicos de XSS que se utilizan en la actualidad.
Los atacantes encuentran muy a menudo nuevas formas de ejecutar sus
scripts aprovechando para ello vulnerabilidades de las aplicaciones web.
Normalmente se emplea el término cross-site siempre que el atacante
consigue que la víctima lance al servidor una petición construida por él de
forma maliciosa. Analicemos una primera variante, la denominada XSS
local o DOM0.

En este tipo de patrón de ataque el flujo del ataque no sale del cliente. Hay
que tener en cuenta que las aplicaciones web son cada vez más complejas,
esto hace que cada vez más a menudo parte de los contenidos se generen
directamente a través de JavaScript en el propio navegador del cliente, y
no hace falta que estos contenidos sean enviados desde el servidor. Cada
vez que los contenidos se modifican sin refrescar la página entera, la
actualización se realiza ejecutando este JavaScript local. Esto se puede
observar cuando se utiliza AJAX, por ejemplo.

¿Qué ocurre entonces si la aplicación en el servidor es segura y no

presenta vulnerabilidades XSS pero el código en el lado del cliente sí? Que
todo el ataque se realiza localmente, la página que se sirve desde el lado
servidor no incorpora ningún script malicioso en su HTML, pero en algún
momento, desde que la página se descarga hasta que se muestra en el
navegador, este código malicioso es incorporado localmente. El servidor
puede detectar el código o script malicioso si se le envía en la petición
(aunque no lo inserte) o en ocasiones, ni siquiera. Por ejemplo, los
identificadores de fragmento (lo que va detrás del carácter #) se tratan en
el cliente y no se envían al servidor, y lo mismo ocurre con ciertos
parámetros en HTML5. Si la vulnerabilidad XSS tiene que ver con estos
parámetros, ni siquiera se envían en la petición al servidor.

En cuanto a otras variaciones de los patrones XSS, casi todas se basan en

encontrar las posibles entradas para insertar en el HTML dinámico que el
navegador interpreta los scripts maliciosos. Por ejemplo, hay un patrón de
de ataque XSS que se basa en la utilización de los atributos HTML.
Supongamos que con alguno de los patrones de ataque ya estudiados, o
con alguno que veremos la semana que viene, el atacante consigue que la
víctima visite un sitio web controlado por él. A partir de este momento
puede utilizar los atributos HTML de la hoja de estilos para hacer que el
navegador de la víctima ejecute comandos o scripts maliciosos. O incluso
el atacante puede distribuir una hora de estilos maliciosa de manera
gratuita y conseguir que todos aquellos sitios que la usen estén sirviendo
a sus clientes estos atributos HTML "maliciosos". Existen patrones
similares que corrompen las cabeceras HTTP (los headers), los Query
Strings, (cadenas de consulta, es decir, una parte de una URL), los
parámetros de un vídeo en Flash, etc. Hay que tener en cuenta que
cualquier tipo de entrada que el navegador interprete sin validar
previamente puede utilizarse como vector de ataque. Esto es importante,
pues el ataque a los clientes de un sitio puede venir por un fallo en
cualquiera de los servidores que están sirviendo código en la web que
visualiza el cliente. Hay que ser extremadamente cuidadoso con todo el
contenido externo: plantillas CSS, imágenes, JavaScripts, estadísticas,
publicidad.

Por último, hay un patrón de ataque que merece la pena mencionar: el que
se sirve de los logs del sistema. Supongamos que un atacante encuentra
la manera de insertar un JavaScript malicioso entre los logs del sistema
(por ejemplo, creando una cuenta de usuario nueva e introduciendo como
nombre del nuevo usuario ese script). Si a continuación el administrador
utilizar un navegador web para acceder a estos logs y visualizarlos
cómodamente (este tipo de interfaz se utiliza cada vez más en este tipo de
tareas), el atacante habrá conseguido su objetivo y habrá realizado un XSS
a través de una inyección en los logs del sistema.

Ejemplo de XSS a través de los logs del sistema.

Ejemplo XSS DOM

Aquí tienes un ejemplo de patrón XSS de tipo 0 o DOM en el que el flujo del
ataque no sale del equipo de la víctima. Como puedes observar, el objetivo
del atacante en este ejemplo es robar la cookie de sesión de esta víctima.

Cross Site Request Forgery (XSRF)

Ya hemos visto que uno de los objetivos típicos de un atacante cuando

construye un ataque de XSS es robar las cookies de sesión de sus
víctimas. Con este mismo objetivo, conseguir saltarse el control de acceso
de una aplicación web, surgen los ataques de Cross Site Request Forgery,
también llamados de Session Riding.

Como iremos analizando a lo largo del MOOC, los ataques son cada vez
más persistentes y dirigidos. Por lo tanto, aunque en los ejemplos de esta
unidad hemos hablado casi siempre de campañas de phishing (en
principio, aleatorias, juegan con la probabilidad, si se envían miles de
emails y un 1% de los usuarios pinchan en el enlace malicioso, ya se tiene
un número significativo de víctimas), imagina lo fácil que puede llegar a
ser para un atacante construir un ataque de XSS o en concreto, de XSRF
si, mediante ingeniería social por ejemplo, consigue saber que sitios y
aplicaciones visitan o usan con frecuencia sus potenciales víctimas (los
empleados de una empresa, un grupo de amigos, los habitantes de una
ciudad en cierto rango de edad, etc.).

Si cualquiera de estos sitios o aplicaciones presenta una vulnerabilidad de

tipo XSS almacenado, tendrá lugar lo que se ha llamado en los últimos
años un ataque de Watering Hole (de abrevadero) y el atacante sólo tendrá
que esperar el tiempo suficiente para conseguir sus objetivos. César ya
habló de esto en la primera semana del MOOC ¿te acuerdas?

Otros patrones de ataque de tipo forgery

Aunque de menor importancia por ser menos habituales, existen otros

patrones de ataque de tipo forgery por los que también hay que
preocuparse en la actualidad. Estos son algunos de ellos:
Clickjacking. Una web maliciosa debe cargar una web legítima delante,
pero de forma transparente (con opacidad cero). Si se posiciona
correctamente un enlace sobre otro, y se cuadran las capas, el efecto
puede ser el del "secuestro" del clic del ratón. Una ventaja de esta técnica
que la diferencia del XRSF es que con ella se sigue disponiendo del token
válido en el caso de aplicaciones que lo usen además de la cookie de
sesión. Una posible defensa o contramedida es evitar que se cargue tu sitio
web dentro de un iframe. Así ningún atacante podrá ponerlo "invisible" y
sobre otra que el propio atacante ha creado. Los clientes también pueden
protegerse con algún software anti-malware que detecte este
comportamiento extraño del navegador.

SaaS User Request Forgery. Lo servicios cloud son accedidos a menudo

desde dispositivos inseguros conectados a redes no controladas. La
probabilidad de que un atacante potencial esté conectado a esa misma red
es alta, y puede aprovechar este hecho para conseguir de diferente
maneras que la víctima ejecute un script o software malicioso en su
dispositivo. Este script o software aprovecha que la víctima ya está
autenticada en el servicio Cloud, y abusa de la confianza que el proveedor
tiene en este usuario para llevar a cabo acciones maliciosas. Un ejemplo
reciente de utilización de este patrón de ataque, en Febrero del 2014, se ha
servidor de una variante del troyano Zeus para aprovechar sesiones de
SalesForce ya abiertas de usuarios de diferentes organizaciones y robar
los datos de sus clientes. Una posible defensa o contramedida es utilizar
protocolos de comunicaciones seguros, especialmente, cuando se
conectan los dispositivos del usuario a redes inseguras. También es
necesario mejorar los sistemas de identificación, autenticación,
autorización y trazabilidad (IAAA) de los proveedores, ya que deberían
presuponer que los usuarios siempre acceden desde dispositivos
comprometidos y redes inseguras.

XSS por webmail (con extensiones MIME). Este tipo de extensión permite
el intercambio a través de Internet de todo tipo de archivos (texto, audio,
vídeo, etc.) de forma transparente para el usuario. Prácticamente todos los
mensajes de correo electrónico escritos por personas y muchos de los que
son generados automáticamente son transmitidos en formato MIME a
través del protocolo SMTP. El atacante incluye el script malicioso dentro
del archivo etiquetado con extensión MIME. Si el navegador interpreta que
el archivo es MIME (es decir, confía en la extensión si realizar más
comprobaciones) y, que por lo tanto, no necesita pasar por filtros de
scripts y otro tipo de validaciones, es posible que lo pase directamente al
intérprete y se termine ejecutando el script como en cualquier otro ataque
XSS de los ya estudiados.

Qué hemos aprendido esta semana?

Si ya has dedicado alrededor de cuatro horas al estudio de esta segunda

semana del MOOC y vas a pasar a realizar la evaluación de estos
contenidos, comprueba primero que tienes claros los siguientes
conceptos (si alguno no lo tienes claro del todo, revisa el material antes de
pasar a la siguiente pantalla). Recuerda que en las pruebas de evaluación
sólo tienes una oportunidad y que tienen que estar las 6 aprobadas si
quieres certificar que has superado el MOOC con éxito:

Los patrones de ataque intentan categorizar los ataques hacker haciendo

un análisis de ejemplos reales, intentando comprender cómo se explotan
las vulnerabilidades y debilidades conocidas y extrayendo los aspectos
comunes a estos ataques agrupándolos por familias o categorías.

Las técnicas de envenenamiento o poisoning se basan en utilizar los

protocolos dinámicos de traducción de nombres y direcciones en los que
se basa la pila de protocolos TCP/IP de manera que el atacante “envenene”
la traducción empleada por la víctima con una traducción falsa.

Esta es la base para cualquier suplantación o spoofing , ataque que se

puede realizar a diferentes niveles (suplantación o spoofing ARP, IP, etc.).

El ataque Man in the Middle (o Janus) básico se construye sobre un

envenenamiento y suplantación ARP para interceptar/modificar todas las
comunicaciones entre dos equipos que se encuentren en el mismo
segmento de red que el atacante (o entre un equipo y su puerta de enlace).

Se trata de un patrón típico para el robo de credenciales, aunque no es su

único resultado posible.

Al contrario de lo que mucha gente piensa, este tipo de ataques puede

darse en IPv4 y en IPv6, lo que cambia es la manera de construirlos.

Cuando el atacante no puede iniciar la sesión cuando él quiera ya que no

puede realizar un robo de credenciales completo, sino que tiene que
esperar a que su víctima inicie la sesión, y cuando ésta ya está establecida,
secuestrarla, el patrón de ataque se denomina así, secuestro de sesión.

Los ataques de denegación de servicio se centran en hacer un servicio,

aplicación o sistema no disponible para sus usuarios o clientes.

En el caso de los volumétricos , este objetivo se consigue por fuerza bruta,

utilizando para ello o bien los protocolos en la capa de infraestructura de
Internet (lo más frecuente), o bien los protocolos en la capa de aplicación.

La amplificación que consigue un volumen suficiente de tráfico para que

el objetivo no lo pueda manejar se puede conseguir de dos formas: por
tamaño de paquete o por distribución (DDoS o Denegación de Servicio
Distribuida).

Un ataque por desbordamiento aprovecha una vulnerabilidad del software

que permite ejecutar cualquier código en el sistema vulnerable con los
mismos permisos que la aplicación que presenta la vulnerabilidad por no
comprobar el tamaño de los parámetros que se pasan a una función o
procedimiento en tiempo real.

Un ataque por inyección de comandos o de código aprovecha que una

aplicación acepta una entrada del usuario (input) sobre la que construye
un comando o código, y no la filtra adecuadamente. Un usuario malicioso
puede aprovechar para inyectar, gracias a esta entrada, comandos o
códigos que le sirvan para conseguir sus objetivos.
Cuidado, la entrada puede ser introducida por el usuario a través de la línea
de comandos o shell del sistema operativo, a través de un formulario web
o incluso a través de cookies o de la URL, depende de la aplicación que
presente la vulnerabilidad.

Los ataques por forgery o falsificación pretenden crear, imitar o adaptar un

entorno, aplicación o servicio real con el propósito de engañar a la víctima
con intenciones maliciosas, casi siempre, que se ejecute algún tipo de
script en el contexto de su navegador.

El Cross Site Scripting (XSS) es un tipo de forgery, quizás el más conocido,

y existen tres variantes que suelen denominarse de tipo 0, 1 y 2 (local,
reflejado y almacenado).

Pero existen otros patrones como el XSRF o el clickjacking que también se

consideran forgeries y que pueden tener resultados igual de peligrosos.