[English]Noch ein kleiner Nachtrag vom Dezember 2024-Patchday. Zum 10. Dezember 2024 hat Microsoft einen kritische Schwachstelle (CVE-2024-49112) im Lightweight Directory Access Protocol (LDAP) öffentlich gemacht. Diese ermöglicht Remote-Angriffe auf Windows-Clients und -Server, wurde aber gepatcht. Es gibt aber eine Reihe Systeme, im Internet per LDAP erreichbar, was man vermeiden oder die Systeme besonders absichern sollte. Hier ein kurzer Überblick.
Anzeige
Windows LDAP-Schwachstelle (CVE-2024-49112)
Ich habe es im Beitrag Microsoft Security Update Summary (10. Dezember 2024) ergänzt. Microsoft hat zum 10. Dezember 2024 die Schwachstelle CVE-2024-49112 im Windows Lightweight Directory Access Protocol (LDAP) offen gelegt. Es handelt sich um eine Remote Code Execution-Schwachstelle, verursacht durch einen Integer-Overflow, die mit einem CVEv3 Score 9.8 als kritisch bewertet wurde.
Ein nicht authentifizierter Angreifer, kann diese Schwachstelle remote erfolgreich ausnutzen. Er hält dann die Möglichkeit, beliebigen Code im Kontext des LDAP-Dienstes auszuführen. Die erfolgreiche Ausnutzung hängt jedoch davon ab, welche Komponente angegriffen wird.
- Im Zusammenhang mit der Ausnutzung eines Domänencontrollers für einen LDAP-Server muss ein Angreifer speziell gestaltete RPC-Aufrufe an das Ziel senden, um eine Abfrage der Domäne des Angreifers auszulösen, um erfolgreich zu sein.
- Im Zusammenhang mit der Ausnutzung einer LDAP-Client-Anwendung muss ein Angreifer das Opfer überzeugen oder austricksen, damit es eine Domain-Controller-Abfrage für die Domäne des Angreifers durchführt oder eine Verbindung zu einem bösartigen LDAP-Server herstellt. Unauthentifizierte RPC-Aufrufe wären jedoch nicht erfolgreich.
Die Schwachstelle wurde im Rahmen der am 10. Dezember 2024 ausgerollten Sicherheitsupdates für Windows (siehe Links am Artikelende) geschlossen. Microsoft gibt an, dass diese Schwachstelle bisher nicht ausgenutzt werde und die Ausnutzbarkeit wird als weniger wahrscheinlich eingestuft.
Kunden sollten zudem sicherstellen, dass Domänencontroller entweder so konfiguriert sind, dass sie nicht auf das Internet zugreifen oder keine eingehenden RPCs aus nicht vertrauenswürdigen Netzwerken zulassen. Beide Maßnahmen schützen ein System vor dieser Sicherheitsanfälligkeit.
Anzeige
Der Hintergrund ist, dass RPC und LDAP extern über SSL veröffentlicht werden. Die Anwendung der obigen Abschwächungsmaßnahmen verringert das Risiko, dass ein Angreifer ein Opfer erfolgreich davon überzeugen oder austricksen kann, eine Verbindung zu einem bösartigen Server herzustellen. Wenn eine Verbindung hergestellt wird, könnte der Angreifer bösartige Anfragen über SSL an das Ziel senden.
Zahlreiche Systeme im Internet erreichbar
Das Thema ist mir die Tage über den Sicherheitsdienstleister Hunter unter die Augen gekommen. Dieser weist in nachfolgendem Tweet auf den Sachverhalt hin.
Hunter schreibt, dass Microsoft Einzelheiten zu der kritischen Schwachstelle CVE-2024-49112, die eine Remotecodeausführung (RCE) im Windows Lightweight Directory Access Protocol (LDAP) ermöglicht, bekannt gegeben hat.
Hunter schreibt, dass jährlich 178.900 LDAP- und LDAPS-Dienste jährlich beim Scans über hunter.how gefunden würden. Obiges Bild zeigt die Funde über verschiedene Länder. Die Treffer für Deutschland werden hier aufgelistet, es sind Systeme von Hetzner oder Contabo oder Mittwald dabei.
Ä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)
Anzeige
Hä, wer lässt seinen Domaincontroller denn öffentlich im Internet stehen? Das ist ja schon grob fahrlässig. Dass der Domaincontroller kein Internet haben soll verstehe ich auch, aber das würde ich nicht als so kritisch sehen.
Das wäre einmal eine gute Best-Practice-Frage an die Profis.:
Mit welchen Gegenstellen sollte einen Standard-DC (DNS auch für exteren) maximal kommunizieren dürfen, um nicht zu veraltern und dauerhaft zu funktionieren?
z.B. *.Microsoft.com, ein paar DNS-Server, NTP-Server, ???
Abgesehen von zusätzlichen Produkten wie XDR, Monitoring, etc.
Wer weiß, was ein DC wirklich braucht, damit es ihm gut geht :-) ?
Ein DC braucht gar keine Verbindung ins Internet!
Weder direkt noch über einen Proxy o.Ä.
Und er sollte auch keine Verbindung ins Internet haben.
Updates bekommt der DC per WSUS.
Und für NTP kann man einen separaten Server aufsetzen oder das macht der Server, auf dem der WSUS läuft, gleich mit.
DNS sollte auch nicht auf dem DC laufen und auch keine anderen Dienste.
Best Practice ist es, für jeden Dienst einen eigenen Server aufzusetzen.
In der Windows-Welt nimmt man dann idealerweise Server Datacenter, ist billiger als Einzellizenzen.
DNS nicht auf den Domain Controllern. Das sieht Microsoft anders. Installier mal einen DC ohne DNS rolle.
Kann man machen, aber DNS nicht ins AD integriert ist keine schöne Sache, sofern man für mehrere Standorte mehrere DNS hat. Denn praktischerweise syncronisieren die integrierten DNS sich übers AD untereinander, Nur fremde oder Subzonen und Reversezonen muss man leider händisch auf jedem DNS einzeln anlegen. Idealerweise schaltet man diesem Konstrukt aber für Namensauflösungen/Forwarding nach draußen eigenen externe DNS (Redundanz!) vor, dann sprechen die AD-DNS immer mit etwas, was man vertraut, das darf dann auch ein auch immer wieder zu patchendes Bind sein.
Genügte es nicht vollständig, den DC nirgends als DNS-Server zu einzutragen und/oder zuzuweisen?
Dann braucht er keinen Internetzugriff und man kann man seine DNS-Rolle in Ruhe vor sich hin-idlen lassen.
Hier:
DNS auf dem DC, ja, aber:
Der DNS auf dem DC löst nur interne Adressen auf.
Adressen die er nicht auflösen kann, wie z.B. externe Adressen, werden an einen zweiten DNS weitergeleitet, der dann die externen Adressen auflöst.
Der DN auf dem DC hat also gar keine Verbindung ins Internet, wie auch der ganze DC nicht.
so haben wir das setup auch bei uns.
Meine Rede und Best-Practise seit Jahrzehnten!
Dazu dann noch Terminalserver, wo nur der Firefox zum Surfen im Internet mit einem Proxy bedacht ist. Das darunterliegende System bleibt offline.
PKI, NTP, DNS und DHCP sollten immer auf eigenen (Linux) Hosts oder die eigene Firewall/Router außerhalb des ADs sein. Das AD delegiert dann nur noch. Dann klappt's auch mit Routing zwischen den Segmenten. Hinzu kommt der ganze Zoo an übrigen Netzdiensten wie interne und externe Reverse-Proxies, Mailgateway etc.
Windows Clients gibt es faktisch nicht mehr. Sind alle mit Linux Thin- und Fatclients ersetzt, die sich auf Terminalserver aufschalten oder direkt einen Webbrowser im Kiosk haben. Und auch auf Serverseite sieht es Jahr für Jahr besser aus. Lag vor ca. 10 Jahren das Verhältnnis Windows zu Linux bei Baremetal bei 7:3 ist es heute umgekehrt. Bei den virtuellen Boxen hingegen herrscht in etwa Gleichgewicht, weil die meisten sogenannten Business Fachanwendungen vergammelts Windows Zeugs sind.
Und sollte das AD doch einmal trotz SRPs abfackeln, ist es binnen eines Arbeitstages wieder aus einem zurückliegenden Backup eingespielt. Das schöne: Die User können dann in der Zeit auf Ihren Linux Kisten zumindest für alles im Webbrowser (Email, Kontakte, Termine, Nextcloud, Collabora) auf der eigenen Instanz weiterarbeiten.
DNS: AD integriert für sichere ZonenUpdates
PKI: Die Issuing ist auf einen AD integrierten MS System, da man ein AutoEnrollment über die AD Sicherheitsgruppen möchte
NTP: Wozu? Im ganzen AD gibt es kein NTP. MS Systeme kommunizieren über NT5DS und gleichen sich automatisch mit dem LogonDC ab, der den PDC fragt. Dieser darf eine interne Zeitquelle fragen oder hat eine Funkuhr (altmodischer Kram)
DHCP: Beim KMU gerne auf dem DC, der hat ja sowieso nichts zu tun. Solange der Admin derselbe ist.
Zum NTP:
Es gibt auch Nicht MS-Systeme, deren Zeit stimmen sollte und synchron zu den anderen Systemen sein sollte.
Beispielsweise Drucker, managed Switche, Router, NAS, USV, Zeiterfassungssysteme ("Stempeluhr"), etc.
Deshalb NTP.
Und meine Erfahrung:
NT5DS funktioniert in der Praxis nicht, NTP dagegen sehr wohl.
Ich hatte früher manchmal Zeitdifferenzen in der Domäne.
Sind die größer 5 Minuten, gibt es lustige Effekte, wie z.B., das man sich nicht mehr anmelden kann, oder Rechner sich nicht mehr mit Freigaben verbinden, etc.
Seit es im Netzwerk einen NTP-Server gibt, sind Zeitdifferenzen und die damit verbundenen Probleme kein Thema mehr.
Der NTP-Server ist firmenweit die Zeitreferenz für alles.
NTP darf ein alternatives Device liefern.
wer Probleme mit NT5DS hat, hat zu 100% an der Zeit gefummelt und verschiedene Zeitserver im Netz, bzw am einigen Stellen keinen.
gerade wegen der 5 Minuten Kerberos Ticket Toleranz ist Zeit der Punkt im AD, dem MS zu 100% im Griff haben musste und das vom Anfang an.
nur der PDC benötigt eine valide Zeitquelle oder er ist eine. thats it.
> Windows Clients gibt es faktisch nicht mehr. Sind alle mit Linux Thin- und Fatclients ersetzt, die sich auf Terminalserver aufschalten oder direkt einen Webbrowser im Kiosk haben.
Wann hören Sie endlich auf diesen Unsinn ins Internet zu blasen? Das mag in Ihrer kleinen Welt so sein, es gibt noch eine Welt außerhalb davon. Ich kann Ihn sagen, dass Sie da aber mal gewaltig auf dem Holzweg sind.
> PKI, NTP, DNS und DHCP sollten immer auf eigenen (Linux) Hosts oder die eigene Firewall/Router außerhalb des ADs sein.
Nur bedingt. DNS sollte auf dem DC installiert sein für das AD-interne DNS. Was außerhalb davon läuft ist egal. Die PKI sollte für Windows-Systeme ebenfalls auf einem Windows-System sein (wenn auch nicht dem DC).
Wichtig ist eine saubere und strikte Netztrennung und auf der Firewall ausschließlich die benötigten Ports und Verbindungen zulassen.
Da ich ohnehin weiß, dass jetzt die immer gleiche Leier kommt, lasse ich es hiermit auch mal gut sein.
Man darf auch nicht vergessen, dass Security Appliances wie Checkpoint und Palo Alto für die Remoteeinwahl via VPN eine AD Integration benötigen, das impliziert schon einen LDAP-Zugang.
Wird nun beispielsweise mit Palo Altos GlobalProtect eine VPN Verbindung aufgebaut, benötigt man hierzu die Credentials, die gegen das AD geprüft werden und ein Zertifikat. Leider wird letzteres nicht auf EKU geprüft, sondern nur die Certificate Chain, die valide sein muss. Und schon ist man, frei nach Boris Beckers AOL Spot, drin.
Ein nslookup -type=srv _ldap._tcp.dc._msdcs.DOMAINNAME liefert mir nun bereitwillig alle DCs. Alles weitere sollte nun nur noch eine Sache von wenigen Minuten sein.
Insofern ist es bitter notwendig auch immer die LDAP-Services im Auge zu haben, auch wenn es kein originärer MS Dienst ist.
Weder Checkpoint noch Palo Alto VPN-Lösungen blockieren den Zugang zu LDAP, sondern reichen die Anfragen des Clients erst einmal durch.
Diese sind nämlich keine Torwächter, sondern nur Schrankenwärter, die diese öffnen sobald jemand eine valide Zertifikatskette und Credentials vorzeigt. Die Validierung findet erst statt, nachdem die Schranke schon geöffnet wurde.
Im Falle von Palo Alto muss noch mit HIP Profilen nachgesteuert werden, diese binden den Client in eine Wartezone. Allerdings auch erst hinter der geöffneten Schranke.