Notifica di minacce: attacchi DDoS di riflessione di mDNS

Autore: Wilber Mejia

Panoramica

Verso la fine del terzo trimestre del 2015, il team SIRT di Akamai ha iniziato a rilevare un limitato numero di attacchi DDoS alimentati da dispositivi dotati di tecnologia Multicast DNS (mDNS). Il potenziale di mDNS come vettore utilizzato per attacchi DDoS di riflessione e amplificazione è stato rivelato anche nel marzo 2015.

Questa notifica di minacce illustra il concetto e le tecniche del vettore di attacco con riflessione di mDNS, nonché le soluzioni per ridurne l'impatto. Il vettore di attacco è supportato dalla disponibilità di dispositivi di origine che espongono su Internet il protocollo mDNS, previsto sulla porta 5353.

A partire da ottobre 2016, Akamai ha individuato e mitigato con successo sette attacchi DDoS mDNS contro obiettivi nei segmenti verticali dei settori gaming e software e tecnologia. Finora, la longevità dell'attacco può essere oggetto di discussione, in base alle caratteristiche osservate negli attacchi reali.

Cronologia degli attacchi

Il vettore di attacco mDNS ha avuto un utilizzo sporadico dal momento in cui fu osservato per la prima volta nel settembre 2015. Come indicato nella cronologia riportata di seguito, è stato registrato un intervallo di circa cinque mesi tra il primo attacco e quello successivo, dovuto probabilmente ai test iniziali degli script di attacco. Solo a fine marzo/inizio aprile 2016 l'utilizzo del vettore di attacco è diventato più costante. Tuttavia fino a oggi gli attacchi che sfruttano il protocollo mDNS come singolo vettore non sono stati così potenti come altri vettori di riflessione.

mDNS attack timeline

Attributi evidenziati dell'attacco

Nella sezione seguente viene analizzato un attacco verificatosi nel 2016. Dei sette attacchi mitigati fino a ora, nessuno è stato lanciato contro lo stesso obiettivo.

  • Larghezza di banda picco: 2,9 gigabit al secondo (Gbps)
  • Picco di pacchetti al secondo: 465.200 pacchetti al secondo
  • Vettore di attacco: mDNS
  • Porta di origine: 5353 (mDNS)
  • Porta di destinazione: Casuale


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)

L'ultimo evento di attacco mDNS rilevato si è verificato il 27 ottobre 2016. Si trattava di un attacco DDoS multivettore costituito da SYN Flood, UDP Flood, UDP Fragment, DNS Flood e mDNS Flood con picco a 41 Gbps.

  • Inizio evento: 27 ottobre 2016, 06:01:00 UTC
  • Larghezza di banda picco: 41 Gbps
  • Picco di pacchetti al secondo: 6 milioni di pacchetti al secondo
  • Vettore di attacco: SYN Flood, UDP Flood, UDP Fragment, DNS Flood, mDNS Flood
  • Porta di origine: Casuale
  • Porta di destinazione: Casuale

 

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

06: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

 

UDP fragment

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



Riflessione 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]

Panoramica su mDNS e sugli attacchi

Multicast DNS (mDNS) è un protocollo standard proposto rilasciato nel 2013 come RFC6762. Facilita l'individuazione di dispositivi e servizi, preferibilmente in reti di piccole dimensioni, con un'interazione minima o addirittura senza intervento da parte dell'utente. Per le sue caratteristiche, mDNS può anche essere un componente adatto per Zero Configuration Networking (zeroconf). La struttura di mDNS corrisponde sostanzialmente a quella dei normali pacchetti DNS, un probabile motivo della sua rapida adozione come vettore di attacco DDoS.

È chiaro che la semplicità di un protocollo progettato per consentire a un dispositivo di essere collegato e pronto all'uso implica alcuni rischi. Chad Seaman rilevò una vulnerabilità (VU#550620) di mDNS in base alla quale il protocollo consentirebbe risposte a query originate all'esterno della rete locale. Queste risposte permetterebbero quindi la divulgazione di informazioni sul dispositivo coinvolto, come il software e i servizi di cui è dotato, nonché di altri dati potenzialmente sensibili quali nome host, impostazioni di configurazione della rete interna, numero di modello e così via. Tale feedback può consentire a un malintenzionato di usare qualsiasi host mDNS che risponde a query unicast tramite la propria interfaccia di partecipare ad attacchi di riflessione/amplificazione DDoS (Distributed Denial of Service). Ulteriori informazioni sulla vulnerabilità sono disponibili qui.

Basandosi su un concetto simile, lo script di attacco mDNS creato da malintenzionati invia una query unicast specifica per ottenere una risposta dai dispositivi mDNS. Definita in RFC6763, la query di enumerazione dei servizi è utile per restituire tutti i tipi di servizi pubblicizzati su una rete. Lo script di attacco genererà una query di payload di 46 byte, come illustrato nella figura successiva, inviando una query DNS per "_services._dns-sd._udp.local" all'host vulnerabile; lo scopo è riportare tutti i servizi noti sui dispositivi richiedenti. È anche possibile eseguire query individuali per i servizi pubblicizzati con varie dimensioni di risposta, situazione che fornisce maggiori opportunità per gli autori di attacchi. Tuttavia questa tattica richiederebbe uno strumento di attacco più sofisticato per sfruttare facilmente i payload di risposta aggiuntivi in un attacco DDoS.

 

STRUTTURA DATI PAYLOAD UDP SCRIPT DI ATTACCO:

 

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

 

I payload di risposta mDNS osservati finora negli attacchi DDoS sono stati di dimensioni limitate. Il più grande conteneva 428 byte di dati, 12 byte in meno rispetto a un singolo pacchetto di risposta con dati monlist NTP. Tuttavia le dimensioni tipiche delle risposte mDNS osservate erano comprese tra 100 e 200 byte. Ciò significa che il limite del vettore corrisponde generalmente a un'amplificazione 4,35 volte superiore, se si considera solo il payload di richiesta di 46 byte e il payload di risposta di 200 byte.

Utilizzo e firme dello script di attacco campione

Lo script di attacco creato per mDNS è una versione modificata dei numerosi script oggi disponibili per attacchi di riflessione e amplificazione UDP. Anche il suo impiego è simile a quello degli altri script: è sufficiente fornire IP di destinazione, porta di destinazione, elenco dei dispositivi mDNS su Internet, thread, velocità dei pacchetti e infine runtime di attacco. Lo script rappresenterà l'IP di destinazione al momento dell'invio delle query dannose da 46 byte indicate nella figura successiva tramite 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)

Nel nostro test di laboratorio, le query sono state inviate a un server Linux configurato con un listener mDNS. È possibile visualizzare la risposta di base nella figura successiva.

 

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)

Il 4 novembre 2016 la Shadowserver Foundation ha completato un'analisi mDNS (5353/UDP) in cui risulta che 526.245 IP univoci hanno risposto alla query mDNS. Il grafico riportato di seguito rappresenta i primi 20 paesi e ASN con mDNS accessibile secondo l'analisi più recente.

mDNS Source Distribution Countries
mDNS Source Distribution ASNs

Mitigazione

Si tratta di uno di quei protocolli concepiti per l'uso all'interno di una rete locale. Di conseguenza, non vi sono ragioni per l'esposizione di dispositivi mDNS su Internet. Se necessario, potrebbe essere opportuno filtrare le query in ingresso e autorizzare soltanto fonti conosciute. È inoltre possibile utilizzare un IDS come Snort per rilevare questo tipo di query e mitigare ulteriormente l'impiego dei propri dispositivi in attacchi DDoS. Di seguito è riportata una regola di rilevamento snort campione.

 

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

Conclusione

Il vettore di attacco mDNS ha avuto un utilizzo limitato finora. Come per il protocollo SSDP, è estremamente probabile che questo vettore possa essere alimentato da dispositivi all'interno di una rete domestica. I primi attacchi sono stati di portata contenuta ma abbiamo rilevato una scansione quotidiana della porta mDNS 5353 sulla nostra piattaforma di mitigazione. Una volta enumerati più dispositivi, si potrebbero verificare attacchi di dimensioni maggiori. Come per SSDP, vista l'esposizione non necessaria di questo protocollo, si prevede anche che mDNS possa non diventare un efficace vettore di attacco DDoS, dato che gli ISP forniscono funzionalità di filtro della porta in questione per gli utenti domestici. Sfortunatamente, anche dopo anni di utilizzo, il protocollo SSDP continua a essere sfruttato con cadenza quotidiana ed è ancora in grado di generare attacchi DDoS di notevole dimensione. Ciò significa che gli attacchi mDNS potrebbero diventare più potenti prima dell'applicazione di significative funzioni di filtro proattivo.

Riferimenti: