Ciberataques DrDoS basados en el protocolo Memcached

Tras el estudio preliminar de los ciberataques de denegación de servicio (DoS), junto con algunas de sus variantes expuestas en el artículo “DrDoS: características y funcionamiento”, en este nuevo artículo se abordará cómo el protocolo de Memcached es utilizado como una herramienta para desarrollar un ciberataque DoS en su variante DrDoS.

Memcached

En cuanto a los sistemas de almacenamiento de datos y objetos en memoria caché, Memcached es utilizado ampliamente por los servidores de sitios web que manejan información procedente de bases de datos, al ser de licencia libre y contar con versiones para todos los sistemas operativos de Windows, Linux y macOS. El propósito de este servicio es que las respuestas a las peticiones web, que llegan al servidor, se hagan de forma más rápida, para lo cual, los datos solicitados han de almacenarse en una memoria RAM, en vez de tener que ser accesibles a través de recursos externos.

Al igual que otros sistemas de caché, Memcached está basado en tablas hash que se mantienen en la memoria RAM de los equipos y que, conforme van alcanzando el límite de su almacenamiento o ha transcurrido su tiempo de validez, sus datos almacenados son eliminados, dejando espacio disponible para otros nuevos de las últimas peticiones. Los clientes no acceden a un servidor concreto, sino que se comunican con los servidores a través del puerto 11211, por defecto, mediante funciones de librería, y tienen configurada una lista de los posibles servidores a los que conectarse para buscar los datos.

- Figura 1. Esquema de funcionamiento Memcached. -

Este tipo de sistema es utilizado por conocidos sitios web, como YouTube, Facebook, Twitter, Reddit o GitHub, entre otros, e incluso Google ofrece un servicio de Memcached, implementado a través de las funciones de una API propia.

Vector de ataque

Hay que partir de que los ataques de DrDoS basados en la vulnerabilidad de Memcached utilizan los servidores mal configurados de este sistema que ejecuten versiones anteriores a la 1.5.6.

Como primer paso, el atacante identifica los servidores vulnerables, que sean accesibles por UDP, y genera un gran número de peticiones modificadas, que envía masivamente sobre esos servidores localizados, a través de una botnet bajo su control para inundar de respuestas al equipo víctima.

En esas peticiones al servidor el atacante falsea la dirección IP (spoofing IP) cambiando su IP por la del equipo víctima para que los servidores Memcached respondan involuntariamente, concentrando los paquetes de respuesta sobre el sistema objetivo. Asimismo, para asegurar la denegación de servicio las peticiones son modificadas en origen para que los servidores Memcached intermedios compongan respuestas con más datos y generen paquetes de gran tamaño. De esta forma, el tamaño del paquete de respuesta que recibe el equipo atacado puede llegar a ser 51.000 veces mayor que el del paquete de petición en origen.

Todo esto es posible gracias al protocolo UDP para las conexiones entre los extremos, ya que no requiere de una confirmación ni reconocimiento al establecer la conexión inicial o enviar un gran volumen de datos, como sí ocurre con TCP.

- Figura 2. Esquema del ataque a Memcached. -

Como consecuencia del ataque, y en función del dimensionamiento de los recursos de la víctima, esta no será capaz de absorber y procesar todo el tráfico y datos que le llegan desde los servidores intermedios, provocando la no disponibilidad del sistema o servicios a los usuarios legítimos por los errores que se producen al cargar los datos solicitados.

Además, las consecuencias también pueden afectar a los servidores intermedios, quedando estos inoperativos debido a la saturación de sus recursos al tener que atender y procesar las peticiones masivas que reciben desde la botnet.

Prevención

Para saber si un servidor de Memcached es vulnerable se puede utilizar el siguiente comando desde la consola de administración:

nmap -p 11211 --script memcached-info [Dirección IP]

Si la respuesta está en blanco, el servidor no es vulnerable. En cualquier otro caso, será vulnerable.

Por otro lado, para evitar que un servicio de Memcached propio sea utilizado como herramienta para desarrollar un ataque de DoS contra terceros, se recomiendan las siguientes medidas preventivas:

• Actualización del software de Memcached. Se tiene que verificar que los servidores que utilizan esta tecnología, sean del sistema operativo que sean, estén actualizados a la versión más reciente, o al menos la versión instalada sea superior o igual a la 5.6., ya que a partir de ella la vulnerabilidad está corregida, deshabilitando la posibilidad de conexión por UDP por defecto.
• Deshabilitar UDP. Si no se ha podido actualizar a una versión segura, se recomienda deshabilitar el puerto UDP si este no se utiliza. Para ello, hay que modificar el archivo de configuración donde se aloje el servicio (la localización de este archivo dependerá de la plataforma y software que se use). Los cambios por aplicar dependerán del sistema operativo sobre el que se ejecuta Memcached.
• Filtros para el puerto UDP/TCP. Si ninguna de las opciones anteriores se puede aplicar, se recomienda establecer filtros a través del cortafuegos para el puerto donde opera el servidor, siendo por defecto el 11211.
• Limitación de tráfico de los servidores Memcached. Es posible limitar la velocidad del tráfico en IPv4 e IPv6 y la longitud de los paquetes intercambiados entre los puertos de origen y destino de Mamcached, mediante la configuración de filtros adicionales en el puerto 11211, a través del cortafuegos.
• Reducir la exposición de los servidores Memcached en Internet. Esto sería posible filtrando las direcciones IP que pueden acceder al servidor. Los servicios de Memcached están orientados a un uso en redes de confianza.

Detección y evidencias

Una actividad intensa y anormal relacionada con el tráfico UDP en el puerto 11211 indicaría que nuestro sistema de Memcached está siendo víctima de un ataque de denegación de servicio amplificado, bien como objetivo del atacante o como sistema intermedio de reflejo.

Para comprobar si los paquetes de datos son iguales o tienen signos evidentes de manipulación, hay que revisar el tráfico de red, comprobando las direcciones de origen de las peticiones recibidas, y así confirmar el ataque.

En la detección temprana las herramientas de monitoreo del “estado” del equipo (los programas que monitorizan el uso de recursos como procesadores, memoria y discos) pueden detectar eventos anormales relacionados con Memcached. También son de gran ayuda las alertas que puedan generar los sistemas SIEM desplegados o las alertas generadas por el conjunto de filtros establecidos en el cortafuegos.

Respuesta y recomendaciones

Si las evidencias confirman que se ha producido un ataque de DrDoS sobre Memcached, se debe actuar rápidamente, aplicando el protocolo de operación y gestión de eventos para este tipo de ataque previamente definido. Este procedimiento debe incluir lo siguiente:

• Invalidar el caché del servidor usado para amplificar el ataque. El siguiente comando permite borrar el caché de servidores que están siendo usados para realizar una amplificación de tráfico, lo que invalidará el ataque:

flush-all

• Identificar la dirección IP de origen del ataque y la dirección IP de destino, junto con el puerto de destino: recopilar toda la información útil para comunicar al proveedor de servicios de Internet (ISP), con el objetivo de que pueda ser bloqueada.
• Establecer contacto con el ISP o proveedor de alojamiento: poner en conocimiento el incidente y transmitir la información necesaria para que se puedan aplicar las medidas de filtrado de tráfico necesarias, a fin de que se puedan prevenir ataques.
• Bloquear y filtrar el tráfico no deseado. Los datos recopilados previamente se pueden utilizar para configurar reglas de filtrado en firewalls y enrutadores para evitar que las solicitudes lleguen a su propio servidor de M
• Obtener asistencia técnica: contactar con los proveedores de servicios técnicos de TI que se tengan contratados o con los centros de respuesta a incidentes de seguridad (CERT) de carácter público de referencia, como puede ser INCIBE-CERT.

Finalizado el ataque y reestablecido el servicio con normalidad, se debe proceder al análisis de las causas que lo provocaron, identificando las posibles vulnerabilidades que lo hicieron posible, y tomando medidas para eliminar las debilidades del sistema, o al menos mejorar la prevención, y así evitar que vuelva a ocurrir.