[English]Noch eine kurze Information für Administratoren von Windows Server-Systemen. Es gibt wohl eine von Microsoft im Dezember 2024 gepatchte Active Directory-Schwachstelle, die Angreifern auf nicht gepatchten Windows Server-Systemen die Möglichkeit bietet, diese zum Absturz zu bringen. Ergänzung: Weitere Informationen ergänzt.
Eine erste Meldung
Ich bin über nachfolgenden Tweet vor Tagen erstmals auf den Sachverhalt gestoßen, der von Darkreading im Beitrag Unpatched Active Directory Flaw Can Crash Any Microsoft Server aufbereitet wurde.
Sicherheitsforscher von SafeBreach haben eine Analyse des DoS-Schwachstelle CVE-2024-49113 erstellt. Diese Schwachstelle wurde zusammen mit RCE-Schwachstelle (Remote Control Execution) CVE-2024-49112 (CVSS-Index von 9,8) im Lightweight Directory Access Protocol (LDAP) von Active Directory entdeckt.
Microsoft hat beide Schwachstellen mit den Sicherheitsupdates vom Dezember 2024 geschlossen. Problem ist, dass eine der beiden kritischen Active Directory Domain Controller-Schwachstellen nicht nur die ursprünglich berichteten Denial-of-Service (DoS)-Angriffe ermöglichen. Die Schwachstelle kann auch benutzt werden, um ungepatchte Windows-Server zum Absturz zu bringen. Experten befürchten, dass viele Unternehmen noch ungepatchte Windows Server betreiben und für solche Angriffe anfällig sind.
Es gibt einen Zero-Click-Exploit
Kurze Ergänzung: Für die Schwachstelle gibt es bereits einen Exploit, wie ich hier gelesen habe. Security Online skizziert im Beitrag PoC Exploit Released for Zero-Click Vulnerability CVE-2024-49113 in Windows, wie die ungepatchte Schwachstelle ausgenutzt werden kann.
Andy Wendel hatte mich bereits am gestrigen Samstag, den 4. Januar 2024 in einer privaten Nachricht auf Facebook bezüglich der Thematik kontaktiert. Da war der Beitrag aber bereits als Konserve erstellt und ich bin aktuell nicht in der Lage, groß zu reagieren (eine simple Erkältung nagelt mich mit starken Nervenschmerzen ans Bett – Spätfolge meines Sportunfalls mit Rückenmarksverletzung vor 10 Jahren). Daher kopiere ich in Informationen von Andy als Ergänzung hier in den Beitrag.
Andy schrieb „sehr genialer Beitrag über einen mittlerweile geschlossenen CVE-2024-49112“ und verlinkte auf nachfolgenden Tweet, der den Beitrag LDAPNightmare: SafeBreach Labs Publishes First Proof-of-Concept Exploit for CVE-2024-49113 aufgreift.
Ist nichts wirklich neues, außer, dass es ein Proof of Concept gibt. Andy Wendel hat mir auf Facebook aber noch einige Informationen gegeben, die ich für die Leserschaft 1:1 einstelle. Er merkt dazu an:
Ich schreibe und sage immer: Domänencontroller sollten niemals mit dem DNS-Server nach extern auflösen können – niemals. Zusätzlich sollten diese alle Root-Server gelöscht haben.
Andy hat dazu folgenden Screenshots mitgeliefert, der die Eigenschaften eines DC im DNS-Manager zeigt.
Er schrieb dazu, das ihm dies mal vor Jahren vom Security-Consultant der Firma @yet, Thomas Peters, gezeigt wurde. Er merkt dazu an: „die Recursion sollte deaktiviert sein“ (siehe folgender Screenshot).
Dazu merkte er an „Kannst Du gerne so schreiben, auch mit Bildern etc.“ (danke an Andy) – vielleicht hilft es dem einen oder anderen aus der Leserschaft.
Ähnliche Artikel:
Microsoft Security Update Summary (10. Dezember 2024)
Patchday: Windows 10/Server-Updates (10. Dezember 2024)
Patchday: Windows 11/Server 2022/2025-Updates (10. Dezember 2024)
Patchday: Windows Server 2012 / R2 (10. Dezember 2024)
Patchday: Microsoft Office Updates (10. Dezember 2024)
Kritische LDAP-Schwachstelle in Windows (CVE-2024-49112)
Mir ist der Ablauf bzw. der Zusammenhang noch nicht ganz klar?!
Ich verstehe es so, dass ein ungepatchter Server auch dann zum Absturz gebracht werden kann, auch wenn er kein Domain Controller ist.
Und selbst wenn die DCs gepatcht sind, ist ein ungepatchter Member Server immer noch anfällig.
Eine Mitigation ist wohl, dass die DCs kein Zugriff aufs Internet haben.
Kann dann auch ein ungepatchter Member Server ohne Internet Zugriff per RCE zum Absturz gebracht werden?
Kann da wer Licht ins Dunkel bringen?
Grüße
Stefan A.
Verstehe ich auch nicht auf Anhieb (der erste Absatz).
Es sollte einfach lauten, dass alle Member Server ohne aktuellen Patch zum Absturz gebracht werden können, wenn die folgenden Bedingungen erfüllt werden (…)
Oder doch nicht?
Manchmal verstehe ich in letzter Zeit bestimmte Blogs auch nicht mehr so richtig
Auf der Darkreading-Seite ist ein Link zu Safebreach und dort wird der Angriff erklärt. Wenn ein beliebiger ungepatchter Windows-Server dazu gebracht wird, eine Host-Abfrage zu einem manipulierten DNS-Eintrag vorzunehmen, erhält er als Antwort statt dem einfachen Hostnamen einen LDAP-String, den er mittels dem vorhandenen LDAP-Client ausführt und damit zum Absturz gebracht wird.
Somit kann jeder ungepatchte Member Server zum Absturz gebracht werden, wenn externe DNS-Abfragen möglich/erlaubt, auch über einen Forwarder am gepatchten Domain Controller, wenn dieser gleichzeitig DNS-Server ist.
Mir ist nur nicht ganz klar, geht das auch, wenn der Member Server keinen Internet Zugriff hat.
Ich habe das irgendwie so verstanden, dass die LDAP Abfrage dann auch gegen extern läuft. Bzw. vllt. habe ich es auch nicht richtig verstanden.
Im Artikel auf darkreading.com sind weitere Artikel zu der Schwachstelle verlinkt. Die Schwachstelle existiert wohl in der wldap32.dll, die auch clientseitig auf Memberservern zum Einsatz kommt.
Man muss zwar veranlassen, dass der Member-Server eine LDAP-Anfrage an den Angreifer schickt (der dann eine Antwort schickt, die die Schwachstelle antriggert), was aber wohl per RPC-Calls machbar ist.
Wenn der Memberserver keine Internetverbindung hat, dürfte er vor Angriffen aus dem Internet sicher sein.
Hab mir die Artikel auch schon zu Gemüte geführt.
Ich verstehe es auch so, dass diese LDAP-Abfrage von einem Member Server, auch Remote per RPC getriggert werden kann.
Da die LDAP Abfrage dann wohl via SSL rausgeht, war eben die Vermutung, ohne Internet am Member Server passiert auch nichts.
Bin eben verwundert, weil in den Mitigations von MS explizit die Domain Controller erwähnt sind und nicht sowas wie „Kein Internet“ allgemein als mitigation.
Sitzt der Angreifer aber bereits intern, dann ist die Lage wieder anders…
Wenn man die empfohlenen Änderungen am DNS vornimmt, wie genau können dann öffentliche Domains aufgelöst werden? Mag ja sein, dass das für andere öffensichtlich ist, für mich jedenfalls nicht.
Ich vermute mal, dass man den Clients einen anderen DNS zuteilt, den man ebenfalls selbst verwaltet, auf einem separaten Router oder mit Technitium oder ähnlichem. Nur die internen DNS-Anfragen gehen dann an den DC. So könnte ich es mir vorstellen, mache das normalerweise jedoch nicht so.
Zumindest für Windows Updates müsste der DC aber irgendwie die MS-Server auflösen können, wenn man keinen separaten WSUS oder eine Software von Drittanbietern für die Updates verwendet.
Das sind allerdings auch nur meine Ideen hierzu.
Würde mich auch interessieren, wie andere dies bereits praktisch handhaben.
IMHO ist das mit dem DNS Rekursion abschalten nur Rumdoktoren an den Symptomen und macht es nicht besser. Es gibt leider Anwendungen, die direkten Kontakt mit irgendwelchen Adresen außerhalb brauchen und nicht über Proxy verbinden können. Zumindestens für Diese muss man ganz gezielt Türchen aufmachen und dann braucht man leider im DNS auch Auflösung externer Adressen. Das wichtigere ist IMHO, Patcht eure Kisten durch, seht zu, dass die auf dem aktuellen Stand sind. In dem Fall hier war das erste was ich durchgepatcht habe, die DCs. Aber noch nen Tipp: Lasst eure internen DC/DNS nicht direkt mit der großen weiten Welt reden, stellt vor der Firewall in ein DMZ weitere DNS auf, die als Forwarder arbeiten. Das darf auch gerne ein Linux mit Bind sein, und am besten sammelt man alle Anfragen von denen im SIEM für die Forensik.
Das ist eine gute Frage.
Das würde ich auch gerne wissen.
Grüße.
der DC hat einen Forward zu einem internen DNS/Caching DNS (zb Fritzbox), der dann nach extern fragt.
ansonsten würdest du den AD eigenen DNS komplett zu einem anderen DNS umziehen.
ein Conditional Forward wäre auch möglich, aber umständlich. wenn du einen „anderen“ DNS hast , dann kann der auch die Zone inkl SRV records bereitstellen
Guten Morgen,
das Abschalten der Rekursion kam von mir.
Generell ist dies aus Sicherheits-Gründen ein Standard, der aktuell auch so immer umgesetzt werden sollte – und von mir auch bei allen Kunden so umgesetzt wird.
Mir ist vollkommen bewusst, das gerade in kleinen Umgebungen eine Fritzbox et.al. als Forwarder im DNS eingetragen wird, um so eine Namensauflösung und somit ein „Surfen“ für alle Clients (und Server, und Domänencontroller…) zu ermöglichen.
Somit hat JEDER Client und Server direkten Internet-Zugang – schlimmer geht es nimmer in den heutigen Zeiten.
„FunFact“: Ca. 95% alle Ransomeware stellt die Arbeit ein, wenn diese ihre C2-Server nicht erreichen können.
Weiterhin: Wie geht Ihr damit um, wenn Ermittlungsbehörden bei Eurem Kunden stehen und Daten von einem bestimmten Datum haben wollen, wo ermittlungsrelevante Daten heruntergeladen worden sind?
Da habt Ihr dann ggfs. nur die Logfiles Eures DNS-Servers, die aber regelmäßig überschrieben worden sind.
Wenn Ihr da nichts liefern könnte bei besonders üblen Downloads, kann es echt eng werden.
Über NIS2 reden wir dann noch nicht einmal – und die geänderte Haftbarkeit auch nicht…
Ihr fragt nach einer Lösung. Ganz einfach: Domänencontroller und ihr DNS lösen niemals nach extern auf.
Das „Surfen“ erledigt eine opnsense (als Beispiel – nehmt was Ihr wollt) als Proxy – gerne auch HA. Die opnsense bekommt einen externen DNS.
Das wars.
Und dort kann ICH auch festlegen, wer surfen darf, und wer auch nicht.
Und die können auch SSO mit LDAP-S…
Viele mögen anführen, das dies oversized in einigen Umgebungen ist:
Das Ganze kostet mit Hardware nicht einmal 500€.
In Hinblick auf NIS2, Nachweisbarkeit des Surfverhaltens und Haftbarkeit wäre ich da sehr sehr vorsichtig, mich einzig auf den DNS-Server des DCs zu verlassen… ;-)
Um mit Albert Einstein zu „denken“:
„Probleme kann man niemals mit derselben Denkweise lösen, durch die sie entstanden sind.“
Wenn wir weiter so arbeiten, wie in den letzten Jahren, werden wir in Richtung Ransomware und Angriffe, verlieren.
Das oben beschriebene ist einfach und gibt einem alles, was er braucht.
Beste Grüße aus Münster,
der
Andy :-)
Merci. Das war der fehlende Baustein.
Du machst gar keine Namensauflösung nach außen.
Surfen nur über einen Proxy. Danke.
DNS Auflösung nach Draußen ist kein Problem sofern in der Regel alle Systeme und User nur über den Proxy (mit Authentifizierung) raus dürfen. Ausnahmen sind leider manchmal nötig. Hab ich oben schon beschrieben. Und auf die Fritzbox als DNS nach Extern würde ich mich auch nicht verlassen, da gehört was hin, wo man DNS Abfragen monitoren und mitloggen kann, was sogar mit einem Windows-DNS geht, Debug-Log an, und per nxlog o.ä. ins SIEM schicken. Besser hier aber Bind als Forwarder auf einerm Maschine die man selbst unter Kontrolle hat, auch da kann man mitloggen und SIEM füttern.
Ausnahmen wirst du immer haben, es gibt keine 100%, egal über welche Technik wir reden. Wichtig ist immer die Masse und die Zeit, die es benötigt ein Ziel zu erreichen.
Im Bereich der Gruppenrichtlinien, gibt es ein paar „20-Minuten Lösungen“, die schnell integriert sind und eine große Wirkung erzielen.
Die „Fritz“ sehe ich als Symbol für alles, was man so haben kann, nicht unbedingt als Lösung. aber in der Praxis real existierend :-)
Hallo Andy,
was hilft mir denn ein Proxy, wenn der Server nicht mal mehr die Namesauflösung machen kann? Oder verstehe ich da etwas falsch?
Grüße
Thomas
Hallo Thomas,
der Proxy bekommt einen EXTERNEN DNS-Server – das ist glaube ich, wo es gerade im Verständnis hängt.
Ein Domänencontroller sollte niemals nach extern auflösen.
Passt das nun besser?
Andy
stell dir vor du hast keinerlei Idee, was IP, Routing oder DNS ist …
du trägst einen Proxy Server im Browser ein und kannst Surfen, obwohl du keinen Gateway oder DNS Eintrag hast.
die Intelligenz steckt jetzt und der Anwendung (browser, wupdate client etc) und nicht mehr im IP Stack.
das war das Ding mit dem OSI Modell. :-)
das OS kann in dem Moment nicht mehr und Internet, aber die Anwendung, die einen Proxy eintragen kann, kann.
Danke für die Ausführungen. Trotzdem verstehe ich nicht so richtig, wie ein separater DNS für externe Anfragen in der Praxis in einem KMU tatsächlich einen Mehrwert bringt. Worin liegt der konkrete Vorteil, wenn der DC eine DNS-Anfrage eines Clients zusätzlich intern weiterleitet statt direkt an den Provider/Google etc.?
Dann haben Browser und andere Software teilweise bereits angefangen OS-DNS-Einstellungen zu umgehen. Warum sollte das eine Malware nicht auch tun und die Anfragen sogar tunneln? 80/443 ist doch eh immer offen. Dann landen wir bei SSL Inspection was die Zertifikatkette aufsprengt und dann alles für gut befindet was durch ging. Wieder eine falsche Sicherheit für den KMU. Ein Teufelskreis.
Blenden wir das mal aus und nehmen also eine Zusatzlösung und filtern DNS-Anfragen eines DC oder anderen Maschinen für externe Adressen und blockieren sie, damit sie theoretisch keinen „direkten“ Internetzugang erhalten haben. Wie sollen sie dann z.B. Zertifikat-Ketten prüfen oder Updates holen? Oder schlimmer, die Zusatzlösung in der DMZ kriegt direkten AD Zugriff damit SSO geht. Brrrrrrrrrrrr
Als Dienstleister für KMU muss ich gestehen, dass ich mit der Thematik überfordert bin. Es hilft nicht mal etwas wenn ich weiss was zu tun wäre. Das notwendige Budget für die Installation kriegt man oft hin. Damit ist es aber nicht getan. Für den seriösen Betrieb, Unterhalt, Auswertung, Reaktion etc. fehlt schlicht das Personal und das KnowHow und am Ende ziemlich sicher das Geld. In Zeiten von dermassen viel Telemetrie geht ja manchmal selbst der normale Traffic unter. Also bringt es keinen echten Mehrwert. Die Dienstleister die man für diesen Bereich anstellen könnte, werfen KMU’s heute sogar raus, weil viele Mittelständer und Grossbetriebe auch überfordert sind. Neukunden nehmen sie sowieso nicht.
Daher ist meine Devise: Keep-It-Simple. Möglichst alles an Kommunikation die von aussen initiert wird vollständig unterbinden und Mitarbeiter sensiblisieren. Gegen den Rest kann man faktisch nur hoffen nicht Opfer eines 0-Days des Mailclients oder Browsers zu werden und das der Provider/Firewall einigermassen à jour mit den Blacklists ist. Dann alles möglich unternehmen, dass die Backup-Kette funktioniert, Verschlüsselungen frühzeitig entdeckt werden (Backups also etwas helfen) und die separaten Bereiche möglichst sauber getrennt sind und Infrastruktur/Backup physisch keinen Internetzugriff bekommen können. Wo immer möglich werden auch eingehende RPC-Calls durch die BFE von Windows unterbunden die oft für Attacken verwendet werden (z.B. Print, EFS etc.).
Gegenüber SSO/Authentifizierung gegen AD in Verbindung mit Nicht-MS-Software / Anmelderoutinen bin ich generell skeptisch eingestellt. Zusätzliche Software/Kommunikationsmöglichkeiten mit AD sind immer ein Risiko das ein KMU eigentlich nicht seriös handeln kann.
Vieles der angesprochenen Dinge bezüglich Aufzeichnung muss ja bereits der Provider machen. Einem KMU ist das kaum zumutbar. Nichtmal seinem Dienstleister der in der Regel selbst ein KMU ist.
der Mehrwert ist simple:
praktisch können nur Anwendungen ins Internet, nicht die Rechner selbst. auf dem Proxy hast du idR auch noch zusätzlich eine UserAuthentication mi AD Integration.
du kontrollierst, welche Personen ins Internet dürfen und welche Geräte am Proxy vorbei dürfen.
Ransomeware denkt ebenfalls Keept it simple. die wollen nach Hause telefonieren, können es aber nicht, weil sie erst den proxy ermitteln müssen oder einen Benutzer benötigen, der es darf. das System (der Computer) darf nicht raus.