Alerte de sécurité : attaque DDoS par réflexion mDNS

Auteur : Wilber Mejia

Présentation

Vers la fin du 3e trimestre 2015, l'équipe Security Intelligence Response Team (SIRT) d'Akamai a commencé à observer l'utilisation limitée d'attaques DDoS perpétrées à l'aide de terminaux compatibles avec le mDNS (Multicast Domain Name System). Le potentiel d'utilisation du mDNS en tant que vecteur d'attaques DDoS par amplification et réflexion a également été révélé en mars 2015.

Cette alerte expose en détail les techniques et concepts sous-jacents au vecteur d'attaque par réflexion mDNS, ainsi que les solutions permettant de le contrer. Ce vecteur d'attaque est rendu possible par la disponibilité de terminaux source exposant sur Internet le mDNS, normalement sur le port 5353.

À compter du mois d'octobre 2016, Akamai a détecté et réussi à contrer sept attaques DDoS mDNS ciblant plusieurs segments du marché des jeux vidéo et des logiciels ainsi que celui de la technologie. Pour le moment, la longévité de cette attaque peut être débattue, en fonction des caractéristiques d'attaques observées en situation réelle.

Historique de l'attaque

Le vecteur d'attaque mDNS a été utilisé ponctuellement depuis sa première observation en septembre 2015. Comme l'indique l'historique ci-dessous, environ cinq mois se sont écoulés entre la première attaque et la suivante, un écart qui peut s'expliquer par les premiers tests effectués sur les scripts d'attaque. Ce n'est qu'entre la fin du mois de mars et le début du mois d'avril 2016 que ce vecteur d'attaque a commencé à être utilisé plus régulièrement. Cependant, les attaques utilisant le mDNS en tant que vecteur unique n'étaient pas aussi efficaces que les autres vecteurs de réflexion connus à ce jour.

mDNS attack timeline

Attributs d'attaques mis en évidence

La section suivante présente une attaque perpétrée en 2016. Toutes les attaques de ce type contrées jusqu'à présent visaient différentes cibles.

  • Pic de bande passante : 2,9 gigabits par seconde (Gbit/s)
  • Pic des paquets par seconde : 465,2 milliers de paquets par seconde
  • Vecteur d'attaque : mDNS
  • Port source : 5353 (mDNS)
  • Port de destination : Méthode aléatoire


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)

Le dernier événement lié à une attaque mDNS observé s'est produit le 27 octobre 2016. Il s'agissait d'une attaque DDoS incluant plusieurs vecteurs, à savoir un SYN Flood, un UDP Flood, un Fragment UDP, un DNS Flood et un mDNS Flood, avec une pointe à 41 Gbit/s.

  • Heure de début de l'événement : 27 oct. 2016, à 06:01:00 UTC
  • Pic de bande passante : 41 Gbit/s
  • Pic des paquets par seconde : 6 millions de paquets par seconde
  • Vecteur d'attaque : SYN Flood, UDP Flood, Fragment UDP, DNS Flood, mDNS Flood
  • Port source : Méthode aléatoire
  • Port de destination : Méthode aléatoire

 

mDNS Flood

 

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

 

SYN Flood

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

 

UDP Flood

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

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

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

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

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

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

 

Fragment 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



Réflexion DNS

06:16:34.508072 IP Z.Z.Z.Z.53 > X.X.X.X.23130: 28397| 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]

Présentation des attaques utilisant le mDNS

Le multicast DNS (mDNS) est une proposition de protocole standard soumise en 2013 sous la dénomination « RFC6762 ». Ce protocole simplifie la détection de terminaux et services, idéalement au sein de petits réseaux, sans interaction avec les utilisateurs, ou avec un niveau d'interaction minimal. Pour cette raison, le mDNS peut également être adapté au concept de réseau sans configuration (« zeroconf »). La structure du mDNS est pratiquement identique à celle des paquets DNS, ce qui peut expliquer son adoption rapide en tant que vecteur d'attaque DDoS.

La simplicité d'un protocole conçu pour permettre de brancher un terminal et de l'utiliser immédiatement s'accompagne évidemment de certains risques. Chad Seaman a détecté une vulnérabilité (VU#550620) poussant le système mDNS à autoriser l'émission de réponses aux requêtes provenant de l'extérieur du réseau local. Ces réponses permettent ensuite la divulgation d'informations au sujet du terminal affecté, comme ses logiciels et services, ainsi que d'autres informations potentiellement sensibles, comme le nom d'hôte, les paramètres de configuration du réseau interne, le numéro de modèle, etc. Grâce à ces informations, un cybercriminel peut utiliser tous les hôtes mDNS répondant à des requêtes en monodiffusion pour perpétrer, via leur interface connectée à Internet, des attaques par déni de service distribué (DDoS) par réflexion/amplification. Davantage d'informations à propos de cette vulnérabilité sont disponibles sur cette page.

Se fondant sur un concept similaire, un script d'attaque mDNS créé par des cybercriminels envoie une requête en monodiffusion pour obtenir une réponse de la part des terminaux mDNS. Énoncée dans le document RFC6763, la requête d'énumération de services est utile pour renvoyer tous les types de services annoncés sur un réseau. Le script d'attaque va générer une requête de charge utile de 46 octets (comme l'indique le diagramme suivant), qui adresse une requête DNS pour « _services._dns-sd._udp.local » à l'hôte vulnérable, afin que tous les services connus soient renvoyés aux terminaux à l'origine de demandes. Ces services annoncés peuvent également être interrogés à titre individuel avec des tailles de réponses variables, élargissant ainsi le champ d'action des pirates. Ceci étant, cette tactique exigerait un outil d'attaque plus sophistiqué pour exploiter facilement ces charges utiles de réponses supplémentaires dans une attaque DDoS.

 

STRUCTURE DE DONNÉEES DE LA CHARGE UTILE UDP DU SCRIPT D'ATTAQUE :

 

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.....

 

Les charges utiles de réponses mDNS observées jusqu'à présent dans des attaques DDoS étaient limitées en taille. La plus volumineuse d'entre elles contenait 428 octets de données, soit 12 octets de moins que le paquet de réponses de données obtenu avec la commande monlist NTP. Toutefois, la taille de réponse mDNS typiquement observée était comprise entre 100 et 200 octets. Cela signifie que le vecteur est plus susceptible de plafonner à une amplification d'environ 4,35x, ce en tenant seulement compte de la charge utile de la demande de 46 octets et de la réponse de charge utile de 200 octets.

Échantillon de signatures et d'utilisation du script d'attaque

Le script d'attaque créé pour le système mDNS est une version modifiée des nombreux scripts disponibles pour les attaques par amplification et réflexion UDP. Son utilisation est également similaire à tous les autres scripts : il suffit de fournir une IP cible, un port cible, la liste des terminaux mDNS sur Internet, les threads, le taux d'accélération des paquets et enfin la durée d'exécution de l'attaque. Le script se fait alors passer pour l'IP cible lorsqu'il envoie à l'aide de l'outil tcpdump les requêtes de 46 octets malicieuses observées dans le diagramme suivant.

 

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)

Lors de notre dernier test réalisé en laboratoire, les requêtes étaient envoyées vers une configuration de serveur Linux incluant un écouteur mDNS. La réponse de base peut être observée dans le diagramme suivant.

 

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)

Le 4 novembre 2016, la Shadowserver Foundation a effectué une analyse mDNS (5353/UDP) au cours de laquelle 526 245 IP uniques ont répondu à la requête mDNS. Le graphique ci-dessous présente les 20 principaux pays ainsi que leurs ASN dont le système mDNS était accessible, d'après la dernière analysée réalisée.

mDNS Source Distribution Countries
mDNS Source Distribution ASNs

Protection

Il s'agit d'un protocole conçu pour être utilisé au sein d'un réseau local. De fait, il ne devrait y avoir aucune exposition de terminaux mDNS sur Internet. Si nécessaire, il peut être avisé de filtrer toutes les requêtes entrantes et d'autoriser uniquement les sources connues. Un système de détection d'intrusion (IDS) tel que Snort peut également être utilisé pour détecter ces requêtes afin de mieux empêcher l'utilisation de vos terminaux dans le cadre d'attaques DDoS. Un exemple de règle de détection de Snort est présenté ci-dessous.

 

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;)

Conclusion

Jusqu'à présent, le vecteur d'attaque mDNS a connu une utilisation limitée. À l'instar du protocole SSDP, ce vecteur est plus enclin à être favorisé par des terminaux au sein d'un réseau domestique. Bien que les premières attaques aient été circonscrites, une analyse du port 5353 du système mDNS a été observée quotidiennement sur notre plate-forme de protection. Une fois que davantage de terminaux sont énumérés, des attaques plus importantes sont susceptibles de se produire. De plus, comme pour le SSDP, l'exposition de ce protocole est facultative. Le système mDNS est donc peu susceptible de s'imposer en tant que vecteur d'attaque DDoS, étant donné que les FAI permettent désormais aux utilisateurs à domicile de filtrer ce port. Malheureusement, même après des années d'utilisation, le SSDP continue d'être exploité quotidiennement et peut toujours générer des attaques DDoS de grande ampleur. Cela signifie que les attaques mDNS peuvent devenir plus virulentes avant qu'un important filtrage proactif ne soit appliqué.

Références