DNS amplification attack

I recenti fatti che hanno riguardato Spamhaus hanno rimesso in risalto il problema non nuovo di un DNS amplification attack al punto che anche l’US-CERT ha diramato un bollettino in merito.

Innanzi tutto la risposta alla domanda legittima: cosa diavolo viene amplificato in questo attacco?

L’amplificazione consiste nella differenza tra i byte che l’attaccante trasmette alla vittima e quelli che la vittima trasmette indietro. In altre parole è la differenza tra la banda necessaria per portare l’attacco e la banda che viene consumata sui server della vittima.

Un ipotetico attacco portato ad un server FTP ha un fattore di amplificazione vicino all’unità perché se vogliamo occupare la banda in upload del server FTP ci vuole anche qualcuno che abbia altrettanta banda in download per accettare i suoi pacchetti TCP.

Differente è un attacco portato ad un server DNS: con una query di poche decine di byte via UDP si ottengono risposte molto importanti, ecco un esempio:

$ dig -t ANY siamogeek.com +edns=0

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6.3 <<>> -t ANY siamogeek.com +edns=0
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61880
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 5, ADDITIONAL: 25

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;siamogeek.com. IN ANY

;; ANSWER SECTION:
siamogeek.com. 3601 IN SOA dns1.registrar-servers.com. hostmaster.registrar-servers.com. 2012101500 3600 1801 604800 3601
siamogeek.com. 1800 IN MX 10 mx.insconsulting.biz.
siamogeek.com. 583 IN A 78.47.70.164
siamogeek.com. 583 IN AAAA 2a01:4f8:d15:1c00::beef
siamogeek.com. 1800 IN NS dns3.registrar-servers.com.
siamogeek.com. 1800 IN NS dns1.registrar-servers.com.
siamogeek.com. 1800 IN NS dns2.registrar-servers.com.
siamogeek.com. 1800 IN NS dns5.registrar-servers.com.
siamogeek.com. 1800 IN NS dns4.registrar-servers.com.

;; AUTHORITY SECTION:
siamogeek.com. 1800 IN NS dns2.registrar-servers.com.
siamogeek.com. 1800 IN NS dns1.registrar-servers.com.
siamogeek.com. 1800 IN NS dns4.registrar-servers.com.
siamogeek.com. 1800 IN NS dns5.registrar-servers.com.
siamogeek.com. 1800 IN NS dns3.registrar-servers.com.

;; ADDITIONAL SECTION:
mx.insconsulting.biz. 322 IN A 78.47.70.164
mx.insconsulting.biz. 322 IN AAAA 2a01:4f8:d15:1c00::badd:ecaf
dns1.registrar-servers.com. 153476 IN A 69.16.244.25
dns1.registrar-servers.com. 153476 IN A 38.101.213.194
dns1.registrar-servers.com. 153476 IN A 50.7.230.26
dns1.registrar-servers.com. 153476 IN A 66.90.82.194
dns1.registrar-servers.com. 153476 IN A 68.233.250.45
dns3.registrar-servers.com. 153476 IN A 67.228.228.216
dns3.registrar-servers.com. 153476 IN A 173.224.125.12
dns3.registrar-servers.com. 153476 IN A 184.173.112.216
dns3.registrar-servers.com. 153476 IN A 188.138.96.213
dns3.registrar-servers.com. 153476 IN A 204.45.254.2
dns2.registrar-servers.com. 153476 IN A 208.64.122.244
dns2.registrar-servers.com. 153476 IN A 208.64.122.242
dns4.registrar-servers.com. 153476 IN A 184.171.163.91
dns4.registrar-servers.com. 153476 IN A 184.173.147.66
dns4.registrar-servers.com. 153476 IN A 37.58.77.234
dns4.registrar-servers.com. 153476 IN A 50.23.83.48
dns4.registrar-servers.com. 153476 IN A 173.236.55.99
dns5.registrar-servers.com. 153476 IN A 213.229.119.229
dns5.registrar-servers.com. 153476 IN A 69.160.33.75
dns5.registrar-servers.com. 153476 IN A 72.20.38.137
dns5.registrar-servers.com. 153476 IN A 95.211.9.35
dns5.registrar-servers.com. 153476 IN A 188.138.2.23

;; Query time: 33 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Mar 30 11:02:31 2013
;; MSG SIZE rcvd: 748

748 byte ricevuti, oltre dieci volte la dimensione del pacchetto inviato. Ho scelto il nome a dominio di questo blog, ma se si prova con altri nomi si possono superare i 3.000 byte di risposta, con un fattore di amplificazione di quasi 50 volte.

Siccome il protocollo DNS viaggia prevalentemente su UDP, è anche facile contraffare il mittente del pacchetto, in quanto l’UDP non richiede un handshake come il TCP, facendo in modo che le risposte non vengano inviate all’attaccante, ma a qualcun altro.

I guai sono tutt’altro che finiti. Come dall’inizio di Internet fino a pochi anni prima della fine del millennio scorso era normale che un server SMTP accettasse mail da tutti, così adesso continuano a proliferare i cosiddetti open DNS, ovvero i server DNS che rispondo a query da tutta Internet in merito a qualsiasi nome a dominio (query ricorsiva).

Secondo l’Open DNS Resolver Project attualmente 25 dei 27 milioni degli open DNS disponibili su Internet sono utilizzabili concretamente per un attacco di DNS amplification.

In altre parole, un botnet di zombie controllato da un’associazione criminale potrebbe sfruttare questi 25.000.000 di server DNS per portare un attacco analogo a quello che ha colpito Spamhaus.

Chi gestisce un server DNS potrebbe disabilitare la ricorsione o limitarla solamente agli IP della propria rete (BIND, Microsoft DNS). Chi deve o vuole proprio lasciare aperto il server DNS può limitare la frequenza delle risposte del server (solamente per BIND). Chi usa server differenti può sempre RTFM.

The Measurement Factory offre una serie di tool e i link ad una serie di siti che possono aiutare i SysAdmin a verificare le configurazioni dei loro DNS.

Per verificare se il server DNS all’indirizzo IP a.b.c.d ammette query ricorsive è sufficiente utilizzare dig:

dig -t ANY @a.b.c.d google.com

Se si ottiene una risposta valida, o si sta interrogando un DNS autoritativo per la zona google.com o si sta interrogando un DNS che ammette ricorsione.