ClickCease KernelCare-Patches für SAD DNS sind da - TuxCare

Abonnieren Sie unseren beliebten Newsletter

Schließen Sie sich 4.500+ Linux- und Open-Source-Experten an!

2x im Monat. Kein Spam.

KernelCare-Patches für SAD DNS sind da

18. November 2020. TuxCare PR Team

KernelCare-Patches für SAD DNS sind auf dem WegSad DNS (Side-channel AttackeD DNS) ist eine Sicherheitslücke, die von Wissenschaftlern der University of California und der Tsinghua University auf der ACM Conference on Computer and Communications Security CCS 2020 bekannt gegeben wurde. Die Schwachstelle wurde zugewiesen CVE-2020-25705. Sie betrifft Distributionen ab der 7. Version (d.h. RHEL6 ist nicht betroffen, da sein Kernel noch keine ICMP-Antworten-Drosselungsfunktion enthält). KernelCare-Patches werden in Kürze veröffentlicht. Die neue wissenschaftliche Entdeckung ermöglicht es einem böswilligen Akteur, den Cache eines DNS-Servers zu vergiften und so möglicherweise den Benutzerverkehr auf Websites oder Dienste umzuleiten, die unerwünschte oder gefährliche Inhalte anbieten. 


Inhalte:

  1. Wie das traurige DNS funktioniert
  2. Entschärfung von Sad DNS
  3. Die Hauptursache
  4. Zeitplan für die Veröffentlichung von KernelCare-Patches

 

Wie das traurige DNS funktioniert

Wie das traurige DNS funktioniert

DNS-Cache-Poisoning wurde erstmals 2008 von einem Sicherheitsforscher entdeckt Dan Kaminsky. Wie die meisten Administratoren wissen, ist das Domain Name System (DNS) eine grundlegende Komponente des Internets. Wenn ein Benutzer eine Domäne in seinen Browser eingibt, führt der Browser eine Abfrage bei einem DNS-Server durch, um die IP-Adresse zu ermitteln, die dem Domänennamen entspricht. 

 

Die meisten DNS-Abfragen verwenden UDP, ein zustandsloses Protokoll, das keine Authentifizierung oder Handshake erfordert. DNS-Abfragen mit UDP erfordern nur eine Quelladresse (den Rechner des Benutzers) und ein Portpaar (Quelle und Ziel). Da keine Authentifizierung erforderlich ist, kann jeder einen DNS-Server nach der IP-Adresse einer beliebigen registrierten Domäne abfragen.

 

UDP wird auf der Transportschicht des OSI-Modells ausgeführt, aber die Entwickler haben Entropie in DNS-Abfragen eingebaut, um eine gewisse Sicherheit zu gewährleisten. Abfragen enthalten eine zufällige Transaktions-ID, die in der Abfrage und in der Antwort gleich sein muss. Die Randomisierung dieses Wertes macht das Fälschen von Anfragen aufgrund seiner Entropie weniger wahrscheinlich. Die Abfrage-ID besteht jedoch nur aus 16 Bit, was bedeutet, dass weniger als 100.000 "Vermutungen" erforderlich sind, bevor ein Angreifer eine Übereinstimmung erzwingen kann. Mit der heutigen Rechenleistung können Brute-Force-Angriffe mit nur 100.000 Möglichkeiten innerhalb weniger Sekunden ausgeführt werden.

 

Da das Internet so groß ist, werden DNS-Resolver verwendet, um Abfragen an autoritative Server zu zentralisieren und Domänen-IPs an Client-Anfragen zu verteilen. Wenn ein rekursiver DNS-Server einen autoritativen Server abfragt, wird normalerweise Port 53 zum Senden und Empfangen von Nachrichten verwendet. Da der Port bereits bekannt ist, braucht ein Angreifer nur die 16-Bit-Abfrage-ID. Bei einem Cache-Poisoning-Angriff überflutet ein Angreifer den rekursiven Server mit Antworten, die alle möglichen ~65.000 IDs enthalten. Wenn der rekursive DNS-Server die Antwort des Angreifers vor der Antwort des autoritativen Servers erhält, ist der DNS-Cache für die Zieldomäne vergiftet. Da keine Authentifizierung oder ein Handshake stattfindet, akzeptiert der Resolver die Antwort des Angreifers ohne zu hinterfragen, und die bösartige IP wird für eine Zieldomäne aufgelöst. 

 

Wenn ein Angreifer den Cache des rekursiven DNS-Servers vergiftet, erhalten alle Benutzer, die die Domäne abfragen, die vom Angreifer zugewiesene IP-Adresse für die jeweilige Domäne. Dies bedeutet, dass der Benutzer zu einem vom Angreifer kontrollierten Server weitergeleitet wird. Der Inhalt, der dem Benutzer angezeigt wird, ist in der Regel eine Phishing-Website, die das gleiche Aussehen wie die legitime Domain hat. Mit diesem Angriff kann ein Angreifer Anmeldeinformationen, Finanzdaten und möglicherweise vertrauliche Dateien stehlen, wenn Benutzer dazu verleitet werden, Inhalte hochzuladen.

 

Um dieses Problem zu bekämpfen, verwenden DNS-Auflöser randomisierte Ports. Das bedeutet, dass der Angreifer nicht nur die Abfrage-ID, sondern auch den Port erraten müsste, was den Angriff undurchführbar macht. Weitere Sicherheitsmaßnahmen wurden in die DNS-Architektur aufgenommen, z. B. die Verwendung von TCP anstelle von UDP und das Hinzufügen von DNSSec in den Prozess. DNSSec erfordert eine Signatur mit der Abfragemeldung, aber das Protokoll steckt noch in den Kinderschuhen und hat sich noch nicht allgemein durchgesetzt.

 

Traurige DNS-Angriffe umgehen die Port-Randomisierung mit Hilfe von ICMP-Fehlermeldungen ( Internet Control Message Protocol ). Wenn ein Port geschlossen ist, gibt eine ICMP-Anfrage die Fehlermeldung "port unreachable" zurück. Mithilfe dieses Protokolls und eines Scans der geschlossenen Ports kann ein Angreifer ableiten, welche Ports für DNS-Antworten offen sind. Indem er das "Raten" auf begrenzte Ports und Abfrage-IDs reduziert, muss ein Angreifer nur noch etwa hunderttausend Antworten erzwingen. Dieser Angriff ist nicht immer möglich, da einige Resolver verbundene UDP-Sockets statt offener Sockets verwenden. Bei einem verbundenen Socket sind beide DNS-Server als Peers über das Betriebssystem "gebunden".

 

Einige Server verwenden eine Ratenbegrenzung, um die Überflutung von ICMP-Ports durch Reflection-Angriffe zu verhindern. Dieser Schutz funktioniert zwar gegen Denial-of-Service (DoS) auf DNS-Servern, kann aber bei einem Sad DNS-Angriff ausgenutzt werden. Wenn ICMP-Antworten begrenzt sind, antwortet ein Server nicht mit einer Fehlermeldung, wenn das Ratenlimit erreicht ist. Angreifer überschwemmen den Zielserver mit genügend ICMP-Nachrichten, um das Ratenlimit zu erreichen und dann festzustellen, welche Ports offen sind, wodurch die Anzahl der Vermutungen bei einem Brute-Force-Angriff entfällt.

 

Um einen Sad-DNS-Angriff durchzuführen, benötigt der Angreifer:

 

  • Ein System, das in der Lage ist, DNS-Anfragen an einen verwundbaren DNS-Server zu stellen
  • Die Fähigkeit, ICMP-Antworten von diesem DNS-Server zu empfangen

 

 

Entschärfung von Sad DNS

Entschärfung von Sad DNS

Sad-DNS-Angriffe erfordern mehrere Vorbedingungen, um erfolgreich ausgenutzt werden zu können, so dass Abhilfemaßnahmen eine zusätzliche Bedingung hinzufügen, die den Angriff undurchführbar macht. Durch Hinzufügen einer der folgenden Strategien zum DNS-Prozess werden Sad-DNS-Angriffe für einen Angreifer undurchführbar:

 

  • Konfigurieren Sie DNSSec, aber die breite Akzeptanz dieses Protokolls ist langsam.
  • ICMP-Antworten nicht zulassen. Dies hat potenzielle Nebeneffekte, da dieser Datenverkehr legitimerweise für andere Zwecke, z. B. die Überwachung, verwendet wird.
  • Wenden Sie einen Kernel-Patch an, um die Grundursache des Problems zu beheben und so die Identifizierung der verwendeten Ports zu verhindern. KernelCare arbeitet derzeit an den Patches für CloudLinux7. Patches für andere unterstützte Distributionen werden in Kürze veröffentlicht.

 

 

Die Hauptursache

Die Hauptursache

Traurige DNS-Angriffe sind aufgrund der vorhersehbaren ICMP-Antwortrate möglich, die vom Kernel des DNS-Servers festgelegt wird. Durch eine feste Anzahl von ICMP-Antworten pro Sekunde kann ein Angreifer herausfinden, welche Ports für die DNS-Kommunikation verwendet werden, und speziell gestaltete Pakete an diese Ports senden. Andere Betriebssysteme sind ebenfalls von diesem Problem betroffen und haben ebenfalls unterschiedliche, aber feste Grenzwerte.

 

Theoretisch ist es möglich, dass Sad DNS nur eine von mehreren Schwachstellen ist, die zur Ausnutzung der ineffizienten ICMP-Port-Randomisierung verwendet werden. Andere Dienste könnten für ähnliche Angriffe anfällig sein, aber bisher sind keine weiteren bekannt geworden. Das Patchen des Kernels kann helfen, sich gegen unbekannte Schwachstellen abzusichern.

A Patch für Sad DNS wurde für den Linux-Kernel eingereicht, und die Linux-Hersteller veröffentlichen entsprechende Korrekturen für ihre Distributionen, darunter Redhat, Debian, Suse, Ubuntu. Der Nachteil bei der Verwendung von Patches, die vom Hersteller zur Verfügung gestellt werden, ist der für den Abschluss des Prozesses erforderliche Neustart. Mit KernelCare können Administratoren ihre Server ohne Neustart live patchen und Sad DNS sowie alle zukünftigen Schwachstellen, die auf das ICMP-Protokoll und Ratenbegrenzungsexploits abzielen, beheben.

 

 

Zeitplan für die Veröffentlichung von KernelCare-Patches

Freigegeben am 23. November:

  • CloudLinux 6 Hybrid,
  • CloudLinux 7, 
  • Oracle Enterprise Linux 7,
  • RHEL 7,
  • CentOS 7,
  • CentOS 7 Plus

Die Patches werden automatisch innerhalb der 4-Stunden-Frist ohne Neustart angewendet. Um manuell zu aktualisieren, führen Sie aus:

/usr/bin/kcarectl --update

Geplant für die Veröffentlichung in der Woche # 48:

  • Ubuntu-Patches
  • Debian-Patches

Geplant für die Veröffentlichung in der Woche # 49:

  • Amazonas-Linux

Bleiben Sie dran für weitere Updates.

Möchten Sie das Patchen von Sicherheitslücken ohne Kernel-Neustart, Systemausfallzeiten oder geplante Wartungsfenster automatisieren?

Erfahren Sie mehr über Live-Patching mit TuxCare

Werden Sie ein TuxCare-Gastautor

Los geht's

E-Mail

Beitreten

4,500

Linux & Open Source
Fachleute!

Abonnieren Sie
unseren Newsletter