Aviso sobre amenazas: DDoS de reflexión basado en mDNS

Autor: Wilber Mejia

Descripción general

Hacia finales del tercer trimestre de 2015, el equipo de respuesta a incidentes e inteligencia en seguridad (SIRT, por sus siglas en inglés) de Akamai empezó a observar que determinados ataques DDoS tenían su origen en dispositivos compatibles con el sistema de nombres de dominio de multidifusión (mDNS). La posibilidad de que mDNS se convierta en un vector de ataque mediante DDoS de reflexión y amplificación también se anunció en marzo de 2015.

En este aviso se detallan el concepto y las técnicas del vector de ataque de reflexión basado en mDNS y cómo mitigarlo. Dicho vector de ataque se aprovecha de la disponibilidad de dispositivos de origen que ponen en riesgo el sistema mDNS en Internet, normalmente a través del puerto 5353.

En octubre de 2016, Akamai detectó y mitigó satisfactoriamente siete ataques DDoS basados en mDNS dirigidos contra objetivos de los sectores verticales del juego y el software y la tecnología. Por lo tanto, y a la vista de las características observadas en los ataques del mundo real, puede ponerse en cuestión la longevidad de este ataque.

Cronología del ataque

El vector de ataque mDNS se ha utilizado de forma esporádica desde que fue detectado por primera vez en septiembre de 2015. Como se indica en la siguiente cronología, transcurrió un lapso de aproximadamente cinco meses entre el ataque inicial y el sucesivo. Esta laguna probablemente se deba a que se trataba de pruebas iniciales de las secuencias de comando de los ataques. No fue hasta finales de marzo y principios de abril de 2016 cuando empezó a observarse un uso más asiduo de este vector de ataque. Sin embargo, los ataques que utilizan mDNS como único vector no han sido hasta la fecha tan potentes como otros vectores de reflexión.

mDNS attack timeline

Atributos destacados del ataque

En la siguiente sección, presentamos un ataque que tuvo lugar en 2016. De los siete ataques mitigados hasta la fecha, ninguno se ha dirigido al mismo objetivo.

  • Ancho de banda máximo: 2,9 gigabits por segundo (Gbps)
  • Paquetes máximos por segundo: 465 200 paquetes por segundo
  • Vector de ataque: mDNS
  • Puerto de origen: 5353 (mDNS)
  • Puerto de destino: Aleatorio


17:07:32.071836 IP Z.Z.Z.Z.5353 > X.X.X.X.80: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

17:07:32.071857 IP Z.Z.Z.Z.5353 > X.X.X.X.80: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

17:07:32.071873 IP Z.Z.Z.Z.5353 > X.X.X.X.80: 0*- 4/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local., PTR _http._tcp.local., PTR _rfb._tcp.local. (143)

17:07:32.072187 IP Z.Z.Z.Z.5353 > X.X.X.X.80: 0*- 3/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local., PTR _ipp._tcp.local. (123)

17:07:32.072274 IP Z.Z.Z.Z.5353 > X.X.X.X.80: 0*- 3/0/0 PTR _workstation._tcp.local., PTR _https._tcp.local., PTR _http._tcp.local. (119)

17:07:32.072279 IP Z.Z.Z.Z.5353 > X.X.X.X.80: 0*- 4/0/0 PTR _pdl-datastream._tcp.local., PTR _printer._tcp.local., PTR _ipp._tcp.local., PTR _http._tcp.local. (143)

17:07:32.072295 IP Z.Z.Z.Z.5353 > X.X.X.X.80: 0*- 8/0/0 PTR _workstation._tcp.local., PTR _webdavs._tcp.local., PTR _webdav._tcp.local., PTR _smb._tcp.local., PTR _sftp._tcp.local., PTR _http._tcp.local., PTR _afpovertcp._tcp.local., PTR _device-info._tcp.local. (235)

17:07:32.072361 IP 193.147.161.117.5353 > X.X.X.X.80: 0*- 7/0/0 PTR _workstation._tcp.local., PTR _ftp._tcp.local., PTR _edcp._udp.local., PTR _afpovertcp._tcp.local., PTR _device-info._tcp.local., PTR _smb._tcp.local., PTR _http._tcp.local. (209)

El último ataque mDNS observado se produjo el 27 de octubre de 2016. Fue un ataque DDoS multivectorial basado en un pico de inundación SYN, inundación UDP, fragmento UDP, inundación DNS e inundación mDNS de 41 Gbps.

  • Hora de inicio del ataque: 27 de octubre de 2016 a las 06:01:00 UTC
  • Ancho de banda máximo: 41 Gb/s
  • Paquetes máximos por segundo: 6 millones de paquetes por segundo
  • Vectores de ataque: Inundación SYN, inundación UDP, fragmento UDP, inundación DNS e inundación mDNS
  • Puerto de origen: Aleatorio
  • Puerto de destino: Aleatorio

 

Inundación mDNS

 

06:05:36.522973 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

06:05:36.522976 IP X.X.X.X.53301 > X.X.X.X.80: Flags [R], seq 194989615, win 0, length 0

06:05:36.523036 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 4/0/0 PTR _workstation._tcp.local., PTR _http._tcp.local., PTR _device-info._tcp.local., PTR _smb._tcp.local. (144)

06:05:36.523040 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _ssh._tcp.local. (97)

06:05:36.523102 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 3/0/0 PTR _workstation._tcp.local., PTR _https._tcp.local., PTR _http._tcp.local. (119)

06:05:36.523114 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 3/0/0 PTR _workstation._tcp.local., PTR _ssh._tcp.local., PTR _sftp-ssh._tcp.local. (121)

06:05:36.523147 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 4/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local., PTR _ssh._tcp.local., PTR _sftp-ssh._tcp.local. (147)

06:05:36.523168 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 3/0/0 PTR _workstation._tcp.local., PTR _https._tcp.local., PTR _http._tcp.local. (119)

06:05:36.523221 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _ssh._tcp.local. (97)

06:05:36.523285 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 3/0/0 PTR _workstation._tcp.local., PTR _ssh._tcp.local., PTR _sftp-ssh._tcp.local. (121)

06:05:36.523313 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _sftp-ssh._tcp.local. (102)

06:05:36.523322 IP X.X.X.X.58727 > X.X.X.X.80: Flags [R.], seq 2670641259, ack 2670641259, win 1400, length 0

 

Inundación SYN

6:01:35.894589 IP X.X.X.X.28970 > X.X.X.X.80: Flags [SEW], seq 4054777856, win 0, length 0

06:01:35.894639 IP X.X.X.X.1028 > X.X.X.X.80: Flags [SEW], seq 1405550592, win 0, length 0

06:01:35.894646 IP X.X.X.X.50021 > X.X.X.X.80: Flags [SEW], seq 3309240320, win 0, length 0

06:01:35.894655 IP X.X.X.X.40602 > X.X.X.X.80: Flags [SEW], seq 2493120512, win 0, length 0

06:01:35.894658 IP X.X.X.X.3847 > X.X.X.X.80: Flags [SEW], seq 1046675456, win 0, length 0

06:01:35.894658 IP X.X.X.X.21163 > X.X.X.X.80: Flags [SEW], seq 2160787456, win 0, length 0

 

Inundación UDP

06:08:36.313095 IP X.X.X.X.42862 > X.X.X.X.80: 2013UDP, length 1

06:08:36.313768 IP X.X.X.X.648 > X.X.X.X.80: 2013UDP, length 11

06:08:36.314002 IP X.X.X.X.60399 > X.X.X.X.80: 2013UDP, length 6

06:08:36.322169 IP X.X.X.X.19246 > X.X.X.X.80: 2013UDP, length 9

06:08:36.327485 IP X.X.X.X.22952 > X.X.X.X.80: 2013UDP, length 11

06:08:36.327764 IP X.X.X.X.55095 > X.X.X.X.80: 2013UDP, length 9

 

Fragmento UDP

06:06:43.088487 IP X.X.X.X > X.X.X.X: udp

06:06:43.088489 IP X.X.X.X > X.X.X.X: udp

06:06:43.088501 IP X.X.X.X > X.X.X.X: udp

06:06:43.088504 IP X.X.X.X > X.X.X.X: udp

06:06:43.088507 IP X.X.X.X > X.X.X.X: udp



Reflexión DNS

06:16:34.508072 IP Z.Z.Z.Z.53 > X.X.X.X.23130: 2013201328397| 20/0/1 MX stagg.cpsc.gov. 5, MX hormel.cpsc.gov. 5, TXT "v=spf1 ip4:x.x.x.x ip4:x.x.x.x ip4:X.X.X.X mx a:list.cpsc.gov -all", A x.x.x.x, AAAA 2600:803:240::2, DNSKEY, DNSKEY, DNSKEY, DNSKEY, Type51, RRSIG[|domain]

06:16:34.508077 IP Z.Z.Z.Z.53 > X.X.X.X.23130: 28397| 20/0/1 MX hormel.cpsc.gov. 5, MX stagg.cpsc.gov. 5, TXT "v=spf1 ip4: X.X.X.X ip4:X.X.X.X ip4:X.X.X.X mx a:list.cpsc.gov -all", A x.x.x.x, AAAA 2600:803:240::2, DNSKEY, DNSKEY, DNSKEY, DNSKEY, Type51, RRSIG[|domain]

06:16:34.508409 IP Z.Z.Z.Z.53 > X.X.X.X.10157: 32564 14/2/0 MX stagg.cpsc.gov. 5, MX hormel.cpsc.gov. 5, DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG,[|domain]

Ataque y descripción general de mDNS

El sistema de nombres de dominio multidifusión (mDNS) es un protocolo estándar, publicado en 2013 bajo el número de referencia RFC6762, cuya función es facilitar el descubrimiento de dispositivos y servicios, idealmente en pequeñas redes, con una interacción mínima o inexistente por parte de los usuarios. Dadas sus características, mDNS también puede convertirse en un componente adecuado para las redes exentas de configuración (zeroconf). Además, mDNS comparte gran parte de la estructura de los paquetes DNS habituales, lo que supone una posible razón de su rápida adopción como vector de ataque DDoS.

No obstante, como no podía ser de otra manera, la simplicidad de un protocolo diseñado para permitir conectar y usar rápidamente un dispositivo conlleva cierto riesgo. Chad Seaman detectó una vulnerabilidad (VU#550620) en mDNS mediante la que el protocolo permite enviar respuestas a consultas procedentes de orígenes externos a la red local. Estas respuestas a su vez permiten divulgar información sobre el dispositivo afectado, como su software y servicios, además de otra información potencialmente confidencial, como el nombre del host, los ajustes de configuración de la red interna, el número de modelo, etc. Con dichos datos, un agente malicioso podría utilizar cualquier host mDNS que responda a consultas de unidifusión a través de su interfaz conectada a Internet con el fin de participar en ataques distribuidos de denegación de servicio (DDoS) de reflexión o amplificación. Puede consultar más información sobre esta vulnerabilidad aquí.

De forma similar, la secuencia de comandos del ataque mDNS creado por agentes maliciosos envía una consulta de unidifusión para obtener una respuesta de los dispositivos mDNS. Según se define en el estándar RFC6763, la consulta de enumeración de servicios resulta útil para devolver todos los tipos de servicios publicados en una red. La secuencia de comandos genera una consulta de carga de 46 bytes (ilustrada en la siguiente figura) y envía una consulta de DNS "_services._dns-sd._udp.local" al host vulnerable. El objetivo de esta consulta es devolver todos los servicios conocidos a los dispositivos que los solicitan. También se pueden dirigir consultas individualmente a los servicios anunciados con diferentes tamaños de respuesta, lo que ofrece oportunidades adicionales a los atacantes. Sin embargo, esta táctica requeriría una herramienta de ataque más sofisticada para aprovechar fácilmente las cargas de respuesta adicionales en un ataque DDoS.

 

ESTRUCTURA DE LOS DATOS DE CARGA UDP DE LA SECUENCIA DE COMANDOS DEL ATAQUE:

 

0000000: 0000 0000 0001 0000 0000 0000 095f 7365  ............._se

0000010: 7276 6963 6573 075f 646e 732d 7364 045f  rvices._dns-sd._

0000020: 7564 7005 6c6f 6361 6c00 000c 0001       udp.local.....

 

Las cargas de las respuestas de mDNS observadas en los ataques DDoS han sido de un tamaño limitado hasta la fecha. Las más grandes contenían 428 bytes de datos, 12 bytes menos que un paquete de respuesta de datos monlist de NTP. Sin embargo, el tamaño típico de respuesta de mDNS observado ha rondado el intervalo de 100 a 200 bytes. Por lo tanto, el vector suele registrar una amplificación máxima unas 4,35 veces superior, si solo tenemos en cuenta la carga de solicitud de 46 bytes y la respuesta de carga de 200 bytes.

Uso y firmas de muestra de la secuencia de comandos del ataque

La secuencia de comandos de ataque creada para mDNS es una versión modificada diseñada a partir de muchas secuencias de comandos disponibles para ataques de reflexión y amplificación de UDP. Su uso es también similar al de otras secuencias de comandos: simplemente proporciona una IP y un puerto de destino, una lista de dispositivos mDNS en Internet, subprocesos, la tasa de aceleración de paquetes y, finalmente, el tiempo de ejecución del ataque. Tras ello, la secuencia de comandos suplantará el IP de destino cuando envíe las consultas maliciosas de 46 bytes observadas en la siguiente figura a través de tcpdump.

 

18:37:12.565541 IP Z.Z.Z.Z.13763 > X.X.X.X.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

18:37:12.565908 IP Z.Z.Z.Z.13763 > X.X.X.X.188.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

18:37:12.566332 IP Z.Z.Z.Z.13763 > X.X.X.X.188.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

18:37:12.566726 IP Z.Z.Z.Z.13763 > X.X.X.X.188.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

18:37:12.567137 IP Z.Z.Z.Z.13763 > X.X.X.X.188.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

18:37:12.567507 IP Z.Z.Z.Z.13763 > X.X.X.X.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

18:37:12.567895 IP Z.Z.Z.Z.13763 > X.X.X.X.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

18:37:12.568274 IP Z.Z.Z.Z.13763 > X.X.X.X.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

18:37:12.568672 IP Z.Z.Z.Z.13763 > X.X.X.X.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

18:37:12.569069 IP Z.Z.Z.Z.13763 > X.X.X.X.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

En nuestra prueba de laboratorio, las consultas se enviaron a un entorno de servidor Linux con un agente de escucha de mDNS. La respuesta básica puede verse en la siguiente figura.

 

18:38:10.252994 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

18:38:10.253256 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

18:38:10.253694 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

18:38:10.254043 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

18:38:10.254394 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

18:38:10.254739 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

18:38:10.255098 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

18:38:10.255458 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

18:38:10.255823 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

18:38:10.256193 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

El 4 de noviembre de 2016, la Fundación Shadowserver completó un análisis de mDNS (5353/UDP) en el que 526 245 IP exclusivas respondieron a una consulta de mDNS. El siguiente gráfico representa los principales 20 países y ASN con mDNS accesibles según el último análisis.

mDNS Source Distribution Countries
mDNS Source Distribution ASNs

Mitigación

Este es uno de los protocolos diseñados para utilizarse dentro de una red local. Por lo tanto, los dispositivos mDNS no deberían verse expuestos a riesgos en Internet. En caso de ser necesario, se recomienda filtrar las consultas entrantes y permitir solo los orígenes conocidos. Se puede utilizar un IDS como Snort para detectar las consultas y mitigar aún más el uso de dispositivos en ataques DDoS. A continuación se incluye una regla de ejemplo de detección de Snort.

 

alert udp $EXTERNAL_NET !5353 -> $HOME_NET 5353 \

(msg: "mDNS DDoS Abuse request"; \

flow: to_server; \

content: "|00 00 00 00 00 01 00 00 00 00 00 00 09 5f 73 65 72 76 69 63 65 73 07 5f 64 6e 73 2d 73 64 04 5f 75 64 70 05 6c 6f 63 61 6c 00 00 0c 00 01|"; dsize:46<>46; \

classtype:Reflection-Abuse; \

sid: 201600004; rev:1;)

Conclusión

El vector de ataque mDNS no ha sido muy utilizado hasta la fecha. Al igual que SSDP, probablemente aproveche los dispositivos de una red doméstica. Los ataques iniciales han disminuido, pero hemos observado exploraciones del puerto mDNS 5353 diariamente en nuestra plataforma de mitigación. La posibilidad de ataques a mayor escala aumentará a medida que crezca la enumeración de dispositivos. Asimismo, al igual que sucede con SSDP y teniendo en cuenta la innecesaria exposición de este protocolo, se espera que mDNS no prospere como vector de ataque DDoS conforme los proveedores de servicios de Internet vayan introduciendo filtros para este puerto en las redes particulares. Por desgracia, incluso tras años de uso, SSDP se sigue utilizando diariamente y todavía es capaz de perpetrar importantes ataques DDoS. Paralelamente, la potencia de los ataques de mDNS puede crecer antes de que se aplique una estrategia proactiva de filtrado significativa.

Referencias