Eine Gruppe von Forschern der UniversitÀt Tel Aviv und des InterdisziplinÀren Zentrums in Herzlia (Israel) eine neue Angriffsart (), die es ermöglicht, beliebige DNS-Resolver als Traffic-VerstÀrker zu nutzen, mit einer VerstÀrkungsrate von bis zu 1621-fach bei der Anzahl der Pakete (auf jede an den Resolver gesendete Anfrage kann einen 1621 Anfragen an den Server des Opfers ermöglicht werden) und bis zu 163-fach beim Traffic.
Das Problem hĂ€ngt mit den spezifischen Arbeitsweisen des Protokolls zusammen und betrifft alle DNS-Server, die die rekursive Anfrageverarbeitung unterstĂŒtzen, einschlieĂlich (CVE-2020-8616), (CVE-2020-12667), (CVE-2020-10995), und (CVE-2020-12662), sowie öffentliche DNS-Dienste wie Google, Cloudflare, Amazon, Quad9, ICANN und andere Unternehmen. Die Behebung des Problems wurde in Zusammenarbeit mit den Entwicklern der DNS-Server koordiniert, die gleichzeitig Updates mit der Behebung der SicherheitsanfĂ€lligkeit in ihren Produkten veröffentlicht haben. Der Schutz vor dem Angriff wurde in den Versionen
, , , .
Der Angriff basiert auf der Nutzung von Anfragen des Angreifers, die auf eine groĂe Anzahl bisher unbekannter gefĂ€lschter NS-EintrĂ€ge verweisen, die mit der Bestimmung des Namens beauftragt sind, jedoch ohne die Angabe von Glue-Records mit Informationen ĂŒber die IP-Adressen der NS-Server in der Antwort. Zum Beispiel sendet der Angreifer eine Anfrage zur Bestimmung des Namens sd1.attacker.com, und kontrolliert den DNS-Server, der fĂŒr die Domain attacker.com zustĂ€ndig ist. Als Antwort auf die Anfrage des Resolvers an den DNS-Server des Angreifers wird eine Antwort ausgegeben, die die Bestimmung der Adresse sd1.attacker.com an den DNS-Server des Opfers delegiert, indem in der Antwort NS-EintrĂ€ge angegeben werden, ohne IP-Details der NS-Server. Da der genannte NS-Server bisher unbekannt ist und seine IP-Adresse nicht angegeben ist, versucht der Resolver, die IP-Adresse des NS-Servers durch eine Anfrage an den DNS-Server des Opfers zu bestimmen, der die Ziel-Domain (victim.com) bedient.
Das Problem ist, dass der Angreifer in der Antwort eine riesige Liste von nicht wiederholenden NS-Servern mit nicht existierenden fiktiven Subdomain-Namen des Opfers (fake-1.victim.com, fake-2.victim.com,⊠fake-1000.victim.com) ausgeben kann. Der Resolver wird versuchen, eine DNS-Anfrage an den DNS-Server des Opfers zu senden, erhĂ€lt jedoch die Antwort, dass die Domain nicht gefunden wurde, und versucht, den nĂ€chsten NS-Server in der Liste zu bestimmen, und so weiter, bis er alle vom Angreifer aufgelisteten NS-DatensĂ€tze durchlĂ€uft. Dementsprechend wird auf eine Anfrage des Angreifers vom Resolver eine riesige Anzahl von Anfragen zur Bestimmung der NS-Hosts gesendet. Da die Namen der NS-Server zufĂ€llig generiert werden und auf nicht existierende Subdomains verweisen, werden sie nicht aus dem Cache abgerufen, und jede Anfrage des Angreifers fĂŒhrt zu einem Sturm von Anfragen an den DNS-Server, der die Domain des Opfers bedient.
Forscher haben das AusmaĂ der AnfĂ€lligkeit öffentlicher DNS-Resolver untersucht und festgestellt, dass bei der Absendung von Anfragen an den Resolver von CloudFlare (1.1.1.1) eine Vermehrung der Paketanzahl (PAF, Packet Amplification Factor) um das 48-fache erreicht werden kann, bei Google (8.8.8.8) um das 30-fache, bei FreeDNS (37.235.1.174) um das 50-fache und bei OpenDNS (208.67.222.222) um das 32-fache. Deutlichere Werte sind zu beobachten fĂŒr
Level3 (209.244.0.3) â 273-fach, Quad9 (9.9.9.9) â 415-fach
SafeDNS (195.46.39.39) â 274-fach, Verisign (64.6.64.6) â 202-fach,
Ultra (156.154.71.1) â 405-fach, Comodo Secure (8.26.56.26) â 435-fach, DNS.Watch (84.200.69.80) â 486-fach und Norton ConnectSafe (199.85.126.10) â 569-fach. Bei Servern auf der Basis von BIND 9.12.3 kann der VerstĂ€rkungsfaktor durch Parallelisierung der Anfragen bis zu 1000 betragen. Im Knot Resolver 5.1.0 liegt der VerstĂ€rkungsfaktor bei etwa mehreren Dutzend (24-48), da die Bestimmung der NS-Namen sequenziell erfolgt und an einer internen Begrenzung der Anzahl von Schritten zur Namensauflösung stöĂt, die fĂŒr eine Anfrage zulĂ€ssig sind.
Es werden zwei Hauptstrategien zum Schutz identifiziert. FĂŒr Systeme mit DNSSEC man bereits etwas braucht (ich arbeite mit dem clusterfĂ€higen Proxmox VE 5.x und ZFS ĂŒber iSCSI). zum Schutz vor Cache-Bypassing, da Anfragen mit zufĂ€lligen Namen gesendet werden. Der Kern der Methode besteht darin, negative Antworten zu generieren, ohne auf autoritative DNS-Server zuzugreifen, indem eine BereichsprĂŒfung ĂŒber DNSSEC angewendet wird. Ein einfacherer Ansatz besteht darin, die Anzahl der Namen, die bei der Verarbeitung einer einzelnen delegierten Anfrage bestimmt werden können, zu begrenzen, jedoch kann diese Methode Probleme mit einigen bestehenden Konfigurationen verursachen, da die Grenzen im Protokoll nicht definiert sind.
Quelle: opennet.ru
