DHCP-Sicherheit in Windows 10: Erkundung der kritischen Sicherheitsanfälligkeit CVE-2019-0726

Bild: Pexels

Mit der Veröffentlichung der Januar-Updates für Windows erregte die Nachricht von der kritisch gefährlichen Sicherheitsanfälligkeit CVE-2019-0547 in DHCP-Clients die Öffentlichkeit. Die hohe CVSS-Bewertung und die Tatsache, dass Microsoft die Leistungsbewertung nicht sofort veröffentlichte, was es den Benutzern schwer machte, sich für ein dringendes Systemupdate zu entscheiden, weckte das Interesse. Einige Veröffentlichungen schlugen sogar vor, dass das Fehlen eines Index als Beweis dafür interpretiert werden kann, dass in naher Zukunft ein funktionierender Exploit auftreten wird.

Lösungen wie MaxPatrol 8 können Computer im Netzwerk identifizieren, die für bestimmte Angriffe anfällig sind. Andere Lösungen wie PT NAD erkennen solche Angriffe selbst. Um dies zu ermöglichen, müssen sowohl die Regeln zum Erkennen von Schwachstellen in Produkten als auch die Regeln zum Erkennen von Angriffen auf diese Produkte beschrieben werden. Um dies zu ermöglichen, muss jede einzelne Sicherheitsanfälligkeit den Vektor, die Methode und die Bedingungen ihrer Operation herausfinden, dh buchstäblich alle Details und Nuancen, die mit der Operation verbunden sind. Ein viel vollständigeres und tieferes Verständnis ist erforderlich als das, was normalerweise aus Beschreibungen auf Anbieterseiten oder in CVE zusammengestellt werden kann, wie z.

Die Sicherheitsanfälligkeit tritt auf, weil das Betriebssystem Objekte im Speicher falsch verarbeitet.

Um den Produkten des Unternehmens die Regeln zum Erkennen von Angriffen auf eine neu erstellte Sicherheitsanfälligkeit in DHCP sowie die Regeln zum Identifizieren der von ihr betroffenen Geräte hinzuzufügen, sollten Sie die Details verstehen. Bei binären Sicherheitslücken wird Patch-Diff häufig verwendet, um einen Einblick in die zugrunde liegenden Fehler zu erhalten, dh einen Vergleich der Änderungen, die am Binärcode einer Anwendung, Bibliothek oder eines Kernels des Betriebssystems vorgenommen wurden, mit einem bestimmten Patch. Dieses Update behebt diesen Fehler. Aber die erste Stufe ist immer die Aufklärung.

Hinweis : Um direkt zur Beschreibung der Sicherheitsanfälligkeit zu gelangen und die zugrunde liegenden DHCP-Konzepte zu umgehen, können Sie die ersten Seiten überspringen und direkt zum Abschnitt "DecodeDomainSearchListData-Funktion" wechseln.

Aufklärung

Wir wenden uns an die Suchmaschine und zeigen alle derzeit bekannten Schwachstellendetails an. Dieses Mal gibt es ein Minimum an Details, und alle sind kostenlose Prozessionen der Informationen, die aus der Originalveröffentlichung auf der MSRC-Website stammen. Diese Situation ist typisch für Fehler, die Microsoft während eines internen Audits entdeckt hat.

Aus der Veröffentlichung geht hervor, dass wir mit einer Sicherheitslücke des Typs Speicherbeschädigung konfrontiert sind, die sowohl in Client- als auch in Serversystemen von Windows 10 Version 1803 enthalten ist und sich in dem Moment manifestiert, in dem ein Angreifer speziell gestaltete Antworten an einen DHCP-Client sendet. Nach einigen Tagen ab diesem Moment auf der Seite werden auch die Leistungsindizes angezeigt:



Wie Sie sehen können, bewertete MSRC "2 - Ausbeutung weniger wahrscheinlich". Dies bedeutet, dass ein Fehler mit hoher Wahrscheinlichkeit entweder überhaupt nicht betriebsbereit ist oder der Betrieb mit solchen Schwierigkeiten behaftet ist, deren Überwindung zu hohe Arbeitskosten erfordert. Zugegebenermaßen neigt Microsoft dazu, solche Schätzungen nicht zu unterschätzen. Dies wird teilweise durch das Risiko von Reputationsverlusten und teilweise durch eine gewisse Unabhängigkeit des Reaktionszentrums innerhalb des Unternehmens beeinflusst. Nehmen wir daher an: Da die Gefahr der Ausbeutung im Bericht als unwahrscheinlich angegeben wird, ist dies sicherlich der Fall. Eigentlich hätte dies die Analyse vervollständigen können, aber es wäre nicht überflüssig, die Sicherheitsanfälligkeit noch einmal zu überprüfen und zumindest herauszufinden. Letztendlich wiederholen sich Fehler trotz aller unbestreitbaren Persönlichkeit und manifestieren sich an anderen Orten.

Von derselben Seite laden wir den Patch (Sicherheitsupdate) herunter, der in Form eines MSU-Archivs bereitgestellt wird, entpacken ihn und suchen nach Dateien, die höchstwahrscheinlich mit der Verarbeitung von DHCP-Antworten auf der Clientseite zusammenhängen. In letzter Zeit ist es viel schwieriger geworden, dies zu tun, da Updates nicht in Form von separaten Paketen bereitgestellt wurden, die bestimmte Fehler beheben, sondern als einzelnes kumulatives Paket, das alle monatlichen Korrekturen enthält. Dies erhöhte das übermäßige Rauschen erheblich, dh Änderungen, die nicht mit unserer Aufgabe zusammenhängen.

Bei der Suche werden unter dem gesamten Dateisatz mehrere für den Filter geeignete Bibliotheken gefunden, die wir mit ihren Versionen auf einem nicht gepatchten System vergleichen. Die Bibliothek dhcpcore.dll sieht am vielversprechendsten aus. In diesem Fall führt BinDiff nur minimale Änderungen durch:



Abgesehen von kosmetischen Änderungen an einer einzelnen Funktion - DecodeDomainSearchListData. Wenn Sie mit dem DHCP-Protokoll und seinen nicht allzu häufig verwendeten Optionen vertraut sind, können Sie bereits davon ausgehen, dass diese Funktion die Liste verarbeitet. Wenn nicht, fahren Sie mit der zweiten Phase fort - dem Studium des Protokolls.

DHCP und seine Optionen

DHCP ( RFC 2131 | wiki ) ist ein erweiterbares Protokoll, dessen Nachschubfunktionen über das Optionsfeld bereitgestellt werden. Jede Option wird durch ein eindeutiges Tag (Nummer, Kennung), die Größe der in der Option enthaltenen Daten und die Daten selbst beschrieben. Diese Vorgehensweise ist typisch für Netzwerkprotokolle, und eine der in das Protokoll „implantierten“ Optionen ist die in RFC 3397 beschriebene Domänensuchoption. Damit kann der DHCP-Server die Standarddomänennamenendungen auf Clients festlegen, die als DNS-Suffixe für die auf diese Weise konfigurierte Verbindung verwendet werden.

Nehmen wir zum Beispiel die folgenden Namensendungen für unseren Kunden an:

.microsoft.com .wikipedia.org 

Bei jedem Versuch, die Adresse anhand des Domänennamens zu ermitteln, ersetzen die DNS-Abfragen nacheinander die Suffixe aus dieser Liste, bis eine erfolgreiche Zuordnung gefunden wurde. Wenn der Benutzer beispielsweise ru in die Adressleiste des Browsers eingegeben hat, werden DNS-Abfragen zuerst für ru.microsoft.com und dann für ru.wikipedia.org generiert:



Tatsächlich sind moderne Browser zu intelligent und reagieren daher auf Weiterleitungen zur Suchmaschine auf Namen, die dem FQDN nicht ähnlich sind. Daher legen wir im Folgenden die Schlussfolgerung von weniger verdorbenen Versorgungsunternehmen bei:



Dem Leser scheint dies die Sicherheitsanfälligkeit zu sein, da die bloße Möglichkeit, DNS-Suffixe durch einen DHCP-Server zu ersetzen, mit dem sich jedes Gerät im Netzwerk identifizieren kann, eine Bedrohung für Clients darstellt, die Netzwerkparameter über DHCP anfordern . Aber nein: Wie aus dem RFC hervorgeht, wird dies als rechtmäßiges, dokumentiertes Verhalten angesehen. Tatsächlich ist der DHCP-Server von Natur aus eine dieser vertrauenswürdigen Komponenten, die einen starken Einfluss auf die Geräte haben können, die auf sie zugreifen.

Domain-Suchoption

Die Domain-Suchoption ist mit 0x77 (119) nummeriert. Wie alle Optionen wird es mit einem Einzelbyte-Tag mit der Optionsnummer codiert. Wie bei den meisten anderen Optionen wird unmittelbar nach dem Tag eine Einzelbyte-Größe der Daten nach der Größe angezeigt. Optionsinstanzen können in der DHCP-Nachricht mehrmals vorhanden sein. In diesem Fall werden Daten aus all diesen Abschnitten in der Reihenfolge verkettet, in der sie in der Nachricht erscheinen.



In dem vorgestellten Beispiel aus RFC 3397 sind die Daten in drei Abschnitte mit jeweils 9 Bytes unterteilt. Wie Sie auf dem Bild sehen können, werden die Subdomainnamen im vollständig qualifizierten Domänennamen mit einer Einzelbyte-Länge des Namens codiert, unmittelbar gefolgt vom Namen selbst. Die Codierung des vollständig qualifizierten Domänennamens endet mit einem Null-Byte (dh einem Subdomänennamen mit der Größe Null).

Darüber hinaus verwendet die Option die einfachste Methode zur Datenkomprimierung oder vielmehr nur Analysepunkte. Anstelle der Größe des Domänennamens kann das Feld den Wert 0xc0 enthalten. Das nächste Byte setzt dann den Offset relativ zum Anfang der Optionsdaten, mit denen nach dem Ende des Domänennamens gesucht werden soll.

In diesem Beispiel wird daher eine Liste von zwei Domänensuffixen codiert:

 .eng.apple.com .marketing.apple.com 

DecodeDomainSearchListData-Funktion

Mit der DHCP-Optionsnummer 0x77 (119) kann der Server DNS-Suffixe auf Clients konfigurieren. Aber nicht auf Computern mit Windows-Betriebssystemen. Microsoft-Systeme haben diese Option traditionell ignoriert, sodass das Ende von DNS-Namen bei Bedarf in der Vergangenheit durch Gruppenrichtlinien gerollt wurde. Dies wurde bis vor kurzem fortgesetzt, als in der nächsten Version von Windows 10, Version 1803, die Verarbeitung für die Domänensuchoption hinzugefügt wurde. Gemessen am Namen der Funktion in dhcpcore.dll, in der die Änderungen vorgenommen wurden, liegt der betreffende Fehler im hinzugefügten Handler.

An die Arbeit gehen. Wir kämmen den Code ein wenig und finden Folgendes heraus. Die DecodeDomainSearchListData-Prozedur dekodiert in voller Übereinstimmung mit dem Namen die Daten aus der Domänensuchoption der vom Server empfangenen Nachricht. Bei der Eingabe empfängt es ein Datenarray, das auf die im vorherigen Absatz beschriebene Weise gepackt wurde, und bei der Ausgabe wird eine nullterminierte Zeichenfolge generiert, die eine durch Kommas getrennte Liste von Domänennamenenden enthält. Diese Funktion konvertiert beispielsweise die Daten aus dem obigen Beispiel in eine Zeichenfolge:

  eng.apple.com,marketing.apple.com 

DecodeDomainSearchListData wird von der UpdateDomainSearchOption-Prozedur aufgerufen, die die zurückgegebene Liste auf den Wert "DhcpDomainSearchList" des Registrierungsschlüssels setzt:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{INTERFACE_GUID}\
Speichern der Hauptparameter einer bestimmten Netzwerkschnittstelle.



Die Funktion DecodeDomainSearchListData wird in zwei Durchgängen ausgeführt. Beim ersten Durchgang werden alle Aktionen außer dem Schreiben in den Ausgabepuffer ausgeführt. Somit ist der erste Durchgang der Berechnung der Speichergröße gewidmet, die erforderlich ist, um die zurückgegebenen Daten aufzunehmen. Beim zweiten Durchgang wird bereits Speicher für diese Daten zugewiesen und der zugewiesene Speicher wird gefüllt. Die Funktion ist ziemlich klein, ungefähr 250 Anweisungen, und ihre Hauptaufgabe besteht darin, jede der drei möglichen Optionen für das im Eingabestream dargestellte Zeichen zu verarbeiten: 1) 0x00, 2) 0xc0 oder 3) alle anderen Werte. Die hypothetische Korrektur für den DHCP-bezogenen Fehler besteht im Wesentlichen darin, zu Beginn des zweiten Durchgangs eine Überprüfung der Größe des resultierenden Puffers hinzuzufügen. Wenn diese Größe Null ist, wird der Speicher nicht für den Puffer zugewiesen und die Funktion beendet sofort die Ausführung und gibt einen Fehler zurück:



Es stellt sich heraus, dass sich die Sicherheitsanfälligkeit in Fällen manifestiert, in denen die Größe des Zielpuffers Null ist. Gleichzeitig prüft die Funktion zu Beginn der Ausführung die Eingabedaten, deren Größe nicht weniger als zwei Bytes betragen darf. Für den Betrieb ist es daher erforderlich, eine nicht leere Option für Domänensuffixe so auszuwählen, dass die Größe des Ausgabepuffers Null ist.

Bedienung

Das erste, was Ihnen in den Sinn kommt, ist, dass Sie die zuvor beschriebenen Analysepunkte verwenden können, damit nicht leere Eingabedaten eine leere Ausgabezeile erzeugen:



Ein Server, der so konfiguriert ist, dass er eine Option mit solchen Inhalten in der Antwort sendet, führt tatsächlich zu einer Zugriffsverletzung auf nicht aktualisierten Clients. Dies geschieht aus folgendem Grund. Wenn die Funktion bei jedem Schritt einen Teil des vollständig qualifizierten Domänennamens analysiert, kopiert sie ihn in den Zielpuffer und setzt einen Punkt danach. In dem Beispiel aus dem RFC werden die Daten in der folgenden Reihenfolge in den Puffer kopiert:

 1). eng. 2). eng.apple. 3). eng.apple.com. 

Wenn die Domäne keine Domänengröße enthält, ersetzt die Funktion das vorherige Zeichen des Zielpuffers durch ein Komma:

 4). eng.apple.com, 

und analysiert weiter:

 5). eng.apple.com,marketing. 6). eng.apple.com,marketing.apple. 7). eng.apple.com,marketing.apple.com. 8). eng.apple.com,marketing.apple.com, 

Am Ende der Eingabe muss nur noch das letzte Komma durch ein Nullzeichen ersetzt werden, und Sie erhalten eine Zeile zum Schreiben in die Registrierung:

 9). eng.apple.com,marketing.apple.com 

Was passiert, wenn ein Angreifer einen auf die beschriebene Weise gebildeten Puffer sendet? Wenn Sie sich das Beispiel ansehen, sehen Sie, dass die darin enthaltene Liste aus einem Element besteht - einer leeren Zeichenfolge. Beim ersten Durchgang berechnet die Funktion die Größe der Ausgabedaten. Da die Daten keinen einzelnen Domänennamen ungleich Null enthalten, ist die Größe Null.

Beim zweiten Durchgang wird ein dynamischer Speicherblock zugewiesen, um Daten darin abzulegen und die Daten selbst zu kopieren. Die Analysefunktion stößt jedoch sofort auf ein Nullzeichen, das das Ende des Domänennamens kennzeichnet, und ersetzt daher, wie gesagt, das vorherige Zeichen von einem Punkt durch ein Komma. Und hier stehen wir vor einem Problem. Der Zielpuffer-Iterator befindet sich an Position Null. Es gibt kein vorheriges Zeichen. Das vorherige Zeichen gehört zum Header des dynamischen Speicherblocks. Und dasselbe Zeichen wird durch 0x2c ersetzt, dh durch ein Komma.

Dies geschieht jedoch nur auf 32-Bit-Systemen. Wenn Sie unsigned int verwenden, um die aktuelle Position des Zielpuffer-Iterators zu speichern, werden Anpassungen an der Verarbeitung auf x64-Systemen vorgenommen. Achten wir genauer auf den Code, der für das Schreiben eines Kommas in den Puffer verantwortlich ist:



Die Einheit wird unter Verwendung des 32-Bit-eax-Registers von der aktuellen Position subtrahiert, während der Code beim Adressieren des Puffers auf das vollständige 64-Bit-Rax-Register zugreift. In der AMD64-Architektur machen alle Operationen mit 32-Bit-Registern den oberen Teil des Registers ungültig. Dies bedeutet, dass im Rax-Register, das zuvor Null enthielt, nach der Subtraktion nicht der Wert –1, sondern 0xffffffff gespeichert wird. Daher wird auf 64-Bit-Systemen der Wert 0x2c in die Adresse buf [0xffffffff] geschrieben, dh weit über die Grenzen des für den Puffer zugewiesenen Speichers hinaus.

Die erhaltenen Daten stimmen gut mit der Leistungsbewertung von Microsoft überein, da ein Angreifer, um diese Sicherheitsanfälligkeit auszunutzen, lernen muss, wie er auf einem DHCP-Client Heap-Spray aus der Ferne ausführt, und gleichzeitig eine ausreichende Kontrolle über die Zuweisung des dynamischen Speichers hat, um vordefinierte Werte, nämlich ein Komma, aufzuzeichnen und Null Byte, erzeugt in der vorbereiteten Adresse und führte zu kontrollierten negativen Konsequenzen. Andernfalls führt das Schreiben von Daten an eine nicht verifizierte Adresse dazu, dass der Prozess svchost.exe zusammen mit allen derzeit darin gehosteten Diensten gelöscht wird und diese Dienste vom Betriebssystem erneut gestartet werden. Eine Tatsache, die Angreifer unter bestimmten Bedingungen auch zu ihrem eigenen Vorteil nutzen können.

Das scheint alles zu sein, was über den untersuchten Fehler gesagt werden kann. Es bleibt nur das Gefühl, dass dies noch lange nicht zu Ende ist. Als ob wir nicht alle Optionen in Betracht gezogen hätten. In diesen Zeilen muss noch etwas verborgen sein.

CVE-2019-0726

Wahrscheinlich so wie es ist. Wenn Sie sich den Datentyp, der den Fehler verursacht, genau ansehen und ihn mit dem genauen Auftreten dieses Fehlers vergleichen, werden Sie feststellen, dass die Liste der Domänennamen so geändert werden kann, dass der resultierende Puffer eine Größe ungleich Null hat, aber versucht, außerhalb des Fehlers zu schreiben das gleiche wird getan. Dazu muss das erste Element in der Liste eine leere Zeichenfolge sein, und alle anderen können normale Domänenenden enthalten. Zum Beispiel:



Die vorgestellte Option enthält zwei Elemente. Das erste Domain-Suffix ist leer und endet sofort mit einem Null-Byte. Das zweite Suffix ist .ru. Die berechnete Zeilengröße am Ausgang beträgt drei Bytes, wodurch die durch die Januar-Aktualisierung der Leere des Zielpuffers auferlegte Überprüfung überwunden werden kann. Gleichzeitig erzwingt Null am Anfang der Daten die Funktion, ein Komma mit dem vorherigen Zeichen in die resultierende Zeichenfolge zu schreiben. Da jedoch die aktuelle Position des Iterators in der Zeichenfolge Null ist, wie im oben betrachteten Fall, erfolgt die Aufzeichnung erneut außerhalb des zugewiesenen Puffers.

Nun ist es notwendig, die in der Praxis erzielten theoretischen Ergebnisse zu bestätigen. Wir simulieren eine Situation, in der der DHCP-Server eine Nachricht mit der Option sendet, die als Antwort auf eine Anforderung vom Client angezeigt wird, und sofort eine Ausnahme abfangen, wenn versucht wird, ein Komma an die unter der resultierenden Pufferzeile zugewiesene Position 0xffffffff zu schreiben:



Hier enthält das r8-Register einen Zeiger auf die eingehenden Optionen, rdi ist die Adresse des ausgewählten Zielpuffers und rax ist die Position in diesem Puffer, an der das Zeichen geschrieben werden soll. Wir haben solche Ergebnisse auf einem vollständig aktualisierten System erhalten (Stand Januar 2019).

Wir schreiben über das entdeckte Problem in Microsoft und ... sie verlieren den Brief. Ja, dies passiert manchmal sogar bei seriösen Anbietern. Kein System ist perfekt, und in diesem Fall müssen Sie nach anderen Kommunikationswegen suchen. Daher kontaktieren wir eine Woche später, ohne in dieser Zeit auch nur eine automatische Antwort zu erhalten, den Manager direkt über Twitter. Nach den Ergebnissen einer mehrtägigen Analyse der Anwendung stellen wir fest, dass die gesendeten Details nichts mit CVE-2019-0547 zu tun haben und eine unabhängige Sicherheitsanfälligkeit darstellen neue CVE-Kennung. Einen Monat später, im März, erscheint die entsprechende Korrektur und der Fehler erhält die Nummer CVE-2019-0726 .

Auf diese Weise können Sie manchmal versuchen, die Details der 1-Tages-Sicherheitsanfälligkeit herauszufinden, um versehentlich 0-Tage zu entdecken, indem Sie einfach Ihrer Intuition vertrauen.

Gepostet von Mikhail Tsvetkov, Spezialist für Anwendungsanalysen bei Positive Technologies.