{"id":82460,"date":"2020-05-21T19:42:00","date_gmt":"2020-05-21T17:42:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/ataka-nxnsattack-zatragivayushhaya-vse-dns-rezolvery"},"modified":"2020-05-21T19:42:00","modified_gmt":"2020-05-21T17:42:00","slug":"ataka-nxnsattack-zatragivayushhaya-vse-dns-rezolvery","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/ataka-nxnsattack-zatragivayushhaya-vse-dns-rezolvery","title":{"rendered":"Attacco NXNSAttack, che colpisce tutti i resolver DNS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Un gruppo di ricercatori dell'Universit\u00e0 di Tel Aviv e del Centro interdisciplinare di Herzliya (Israele) ha sviluppato<\/a><\/noindex> un nuovo metodo di attacco NXNSAttack<\/a><\/noindex> (PDF<\/a><\/noindex>), che consente di utilizzare qualsiasi risolutore DNS come amplificatori di traffico, fornendo un grado di amplificazione fino a 1621 volte nel numero di pacchetti (per ogni richiesta inviata al risolutore, \u00e8 possibile ottenere l'invio di 1621 richieste al server della vittima) e fino a 163 volte per il traffico. <\/p>\n

Il problema \u00e8 legato alle peculiarit\u00e0 del funzionamento del protocollo e riguarda tutti i server DNS che supportano l'elaborazione ricorsiva delle richieste, inclusi BIND<\/a><\/noindex> (CVE-2020-8616), Knot<\/a><\/noindex> (CVE-2020-12667), PowerDNS<\/a><\/noindex> (CVE-2020-10995), Windows DNS Server<\/a><\/noindex> e Unbound<\/a><\/noindex> (CVE-2020-12662), cos\u00ec come i servizi DNS pubblici di Google, Cloudflare, Amazon, Quad9, ICANN e altre aziende. La correzione del problema \u00e8 stata coordinata con gli sviluppatori di server DNS, che hanno simultaneamente rilasciato aggiornamenti per eliminare la vulnerabilit\u00e0 nei loro prodotti. La protezione contro l'attacco \u00e8 stata implementata nelle versioni
\nUnbound 1.10.1<\/a><\/noindex>, Knot Resolver 5.1.1<\/a><\/noindex>, PowerDNS Recursor 4.3.1, 4.2.2, 4.1.16<\/a><\/noindex>, BIND 9.11.19, 9.14.12, 9.16.3<\/a><\/noindex>.<\/p>\n

L'attacco si basa sull'utilizzo da parte dell'attaccante di richieste che si riferiscono a un gran numero di record NS fittizi mai visti prima, a cui viene delegata la risoluzione del nome, ma senza specificare nella risposta i record glue con le informazioni sugli indirizzi IP dei server NS. Ad esempio, l'attaccante invia una richiesta per la risoluzione del nome sd1.attacker.com, controllando il server DNS responsabile del dominio attacker.com. In risposta alla richiesta del risolutore al server DNS dell'attaccante, viene fornita una risposta che delega la definizione dell'indirizzo sd1.attacker.com al server DNS della vittima, specificando nelle risposte i record NS senza dettagli sugli IP dei server NS. Poich\u00e9 il server NS menzionato non \u00e8 mai stato visto prima e il suo indirizzo IP non \u00e8 specificato, il risolutore cerca di determinare l'indirizzo IP del server NS inviando una richiesta al server DNS della vittima, che gestisce il dominio target (victim.com).<\/p>\n

\"Attacco<\/a><\/noindex><\/center><\/p>\n

Il problema \u00e8 che l'attaccante pu\u00f2 restituire una lunga lista di server NS unici con nomi di sottodomini falsi (fake-1.victim.com, fake-2.victim.com,\u2026 fake-1000.victim.com). Il resolver tenter\u00e0 di inviare una richiesta al server DNS della vittima, ma ricever\u00e0 una risposta che indica che il dominio non \u00e8 stato trovato, quindi cercher\u00e0 il successivo server NS nella lista e cos\u00ec via, finch\u00e9 non avr\u00e0 esaurito tutte le registrazioni NS elencate dall'attaccante. Di conseguenza, per ogni richiesta dell'attaccante, il resolver invier\u00e0 un numero elevato di richieste per identificare gli host NS. Poich\u00e9 i nomi dei server NS sono generati casualmente e puntano a sottodomini non esistenti, non vengono estratti dalla cache e ogni richiesta dell'attaccante genera un'ondata di richieste al server DNS che gestisce il dominio della vittima.<\/p>\n

\"Attacco<\/a><\/noindex><\/center><\/p>\n

I ricercatori hanno esaminato il grado di vulnerabilit\u00e0 dei resolver DNS pubblici e hanno scoperto che inviando richieste al resolver CloudFlare (1.1.1.1) si pu\u00f2 ottenere un aumento del numero di pacchetti (PAF, Packet Amplification Factor) di 48 volte, Google (8.8.8.8) \u2014 30 volte, FreeDNS (37.235.1.174) \u2014 50 volte, OpenDNS (208.67.222.222) \u2014 32 volte. Indicatori pi\u00f9 significativi si osservano per
\nLevel3 (209.244.0.3) \u2014 273 volte, Quad9 (9.9.9.9) \u2014 415 volte
\nSafeDNS (195.46.39.39) \u2014 274 volte, Verisign (64.6.64.6) \u2014 202 volte,
\nUltra (156.154.71.1) \u2014 405 volte, Comodo Secure (8.26.56.26) \u2014 435 volte, DNS.Watch (84.200.69.80) \u2014 486 volte, e Norton ConnectSafe (199.85.126.10) \u2014 569 volte. Per i server basati su BIND 9.12.3, grazie alla parallelizzazione delle richieste, il livello di amplificazione pu\u00f2 raggiungere fino a 1000. Nel Knot Resolver 5.1.0, il livello di amplificazione \u00e8 di circa alcune decine di volte (24-48), poich\u00e9 la determinazione dei nomi NS avviene in modo sequenziale e si scontra con un limite interno sul numero di passaggi di risoluzione dei nomi consentiti per una singola richiesta.<\/p>\n

Si evidenziano due strategie principali di protezione. Per i sistemi con DNSSEC \u00e8 stato proposto<\/a><\/noindex> di utilizzare RFC-8198<\/a><\/noindex> per prevenire la elusione della cache DNS, poich\u00e9 le richieste sono inviate con nomi casuali. L'essenza del metodo \u00e8 nella generazione di risposte negative senza contattare i server DNS autorevoli, utilizzando verifiche per intervalli tramite DNSSEC. Un modo pi\u00f9 semplice \u00e8 limitare il numero di nomi che possono essere risolti durante l'elaborazione di una singola richiesta delegata, ma questo metodo pu\u00f2 portare a problemi con alcune configurazioni esistenti, poich\u00e9 i limiti non sono definiti nel protocollo.<\/p>\n

<\/a><\/noindex><\/p>\n

Fonte: opennet.ru<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0413\u0440\u0443\u043f\u043f\u0430 \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0438\u0437 \u0422\u0435\u043b\u044c-\u0410\u0432\u0438\u0432\u0441\u043a\u043e\u0433\u043e \u0443\u043d\u0438\u0432\u0435\u0440\u0441\u0438\u0442\u0435\u0442\u0430 \u0438 \u041c\u0435\u0436\u0434\u0438\u0441\u0446\u0438\u043f\u043b\u0438\u043d\u0430\u0440\u043d\u043e\u0433\u043e \u0446\u0435\u043d\u0442\u0440\u0430 \u0432 \u0413\u0435\u0440\u0446\u043b\u0438\u0438 (\u0418\u0437\u0440\u0430\u0438\u043b\u044c) \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043b\u0430 \u043d\u043e\u0432\u044b\u0439 \u043c\u0435\u0442\u043e\u0434 \u0430\u0442\u0430\u043a\u0438 NXNSAttack (PDF), \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0438\u0439 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u043b\u044e\u0431\u044b\u0435 DNS-\u0440\u0435\u0437\u043e\u043b\u0432\u0435\u0440\u044b \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 \u0443\u0441\u0438\u043b\u0438\u0442\u0435\u043b\u0435\u0439 \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0432\u0430\u044e\u0449\u0438\u0445 \u0441\u0442\u0435\u043f\u0435\u043d\u044c \u0443\u0441\u0438\u043b\u0435\u043d\u0438\u044f \u0434\u043e 1621 \u0440\u0430\u0437 \u043f\u043e \u0447\u0438\u0441\u043b\u0443 \u043f\u0430\u043a\u0435\u0442\u043e\u0432 (\u043d\u0430 \u043a\u0430\u0436\u0434\u044b\u0439 \u043e\u0442\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u043d\u044b\u0439 \u043a \u0440\u0435\u0437\u043e\u043b\u0432\u0435\u0440\u0443 \u0437\u0430\u043f\u0440\u043e\u0441, \u043c\u043e\u0436\u043d\u043e \u0434\u043e\u0431\u0438\u0442\u044c\u0441\u044f \u043e\u0442\u043f\u0440\u0430\u0432\u043a\u0438 \u043d\u0430 \u0441\u0435\u0440\u0432\u0435\u0440 \u0436\u0435\u0440\u0442\u0432\u044b 1621 \u0437\u0430\u043f\u0440\u043e\u0441) \u0438 \u0434\u043e 163 \u0440\u0430\u0437 \u043f\u043e \u0442\u0440\u0430\u0444\u0438\u043a\u0443. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":82461,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-82460","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Attacco NXNSAttack, che colpisce tutti i risolutori DNS | ProHoster","description":"Un gruppo di ricercatori dell'Universit\u00e0 di Tel Aviv e del Centro interdisciplinare di Herzliya (Israele)","canonical_url":"https:\/\/prohoster.info\/it\/blog\/news\/ataka-nxnsattack-zatragivayushhaya-vse-dns-rezolvery","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0410\u0442\u0430\u043a\u0430 NXNSAttack, \u0437\u0430\u0442\u0440\u0430\u0433\u0438\u0432\u0430\u044e\u0449\u0430\u044f \u0432\u0441\u0435 DNS-\u0440\u0435\u0437\u043e\u043b\u0432\u0435\u0440\u044b | ProHoster","og:description":"\u0413\u0440\u0443\u043f\u043f\u0430 \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0438\u0437 \u0422\u0435\u043b\u044c-\u0410\u0432\u0438\u0432\u0441\u043a\u043e\u0433\u043e \u0443\u043d\u0438\u0432\u0435\u0440\u0441\u0438\u0442\u0435\u0442\u0430 \u0438 \u041c\u0435\u0436\u0434\u0438\u0441\u0446\u0438\u043f\u043b\u0438\u043d\u0430\u0440\u043d\u043e\u0433\u043e \u0446\u0435\u043d\u0442\u0440\u0430 \u0432 \u0413\u0435\u0440\u0446\u043b\u0438\u0438 (\u0418\u0437\u0440\u0430\u0438\u043b\u044c)","og:url":"https:\/\/prohoster.info\/it\/blog\/news\/ataka-nxnsattack-zatragivayushhaya-vse-dns-rezolvery","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-21T17:42:00+00:00","article:modified_time":"2020-05-21T17:42:00+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"82460","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:37:29","updated":"2022-09-29 14:28:05","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/82460","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=82460"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/82460\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/82461"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=82460"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=82460"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=82460"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}