Aus der Ankündigung wird Realität: Mit dem Patch ADV190023 aktiviert Microsoft die LDAP-Kanalbindung und LDAP-Signaturen standardmäßig auf seinen Active-Directory-Produkten. Ab März 2020 sollten alle Systeme, die mit dem Active Directory kommunizieren, nur noch LDAPS (Lightweight Directory Access Protocol over SSL) nutzen.
Zahlreiche Anwendungen, darunter Legacy-Software und auch SAP Identity Management (IdM), nutzen bisher das unsichere LDAP, bei dem weder der Datenverkehr verschlüsselt noch die Authentizität des LDAP-Servers überprüft wird. Wie die folgenden Szenarien zeigen, kann das zu akuten Sicherheitslücken führen. Wenn Sie sich weniger für die technischen Hintergründe, sondern eher für die Auswirkungen der Umstellung für SAP IdM interessieren, sind Sie hier richtig.
Unverschlüsselte LDAP-Verbindungen bergen viele Gefahren. Da LDAP meistens für die Authentifizierung und Autorisierung von Usern in Applikationen über das hauseigene Active Directory verwendet wird, verschaffen mitgeschnittene oder manipulierte Kommunikationen einem Angreifer einfachen Zugang in die interne IT.
Jedes Mal, wenn eine Applikation einem unbekannten Benutzer eine Anmeldeseite zeigt und der Benutzer sie mit einem Usernamen und einem Passwort füttert, sendet die Applikation die eingegebenen Daten in Form einer LDAP-Abfrage an das Active Directory, um die Userkennung zu überprüfen. Bei einem User mit dem Namen „Bob“ und dem Passwort „admin123“ sieht die Abfrage wie folgt aus:
(&(user=Bob)(password=admin123))
Wenn ein Angreifer es schafft, den Netzwerkverkehr (mit einem Sniffer) mitzuschneiden, kann er ganz bequem die Passwörter von allen Usern auslesen, die sich gerade an der Applikation anmelden.
Statt eines Klartextpassworts nutzen viele Applikationen einen Hash, also einen kryptografisch erstellten Fingerabdruck des Passworts. Dieser ist jedoch meistens mit unsicheren Hash-Funktionen (zum Beispiel MD5) encodiert. Ein Angreifer kann diese Hashes sammeln und moderne Cracking-Tools zur Analyse verwenden, um sie zu brechen.
Bei einer LDAP Injection meldet sich ein Angreifer über eine Man-in-the-Middle-Attacke (MITM) ohne jegliche Passwörter an einem System an. So muss er weder Passwörter mitschneiden noch Hashes knacken. Außerdem müssen sich beim Lauschen auch nicht die „richtigen“ User anmelden.
Nehmen wir das obige Beispiel:
(&(user=Bob)(password=admin123))
Die Query sucht nach einem Benutzer, dessen Username „Bob“ und dessen Passwort „admin123“ ist. Findet das Active Directory einen solchen Benutzer, geht die Applikation davon aus, dass die Benutzerkennung valide ist, und autorisiert ihn.
Wenn der Angreifer es schafft, die Verbindung zwischen Applikation und Active Directory zu kompromittieren, kann er die Abfragen der Applikation modifizieren. So kann er sich als „Bob“ anmelden und als Passwort „keineAhnung1234“ verwenden. Normalerweise sollte sich der User nicht erfolgreich einloggen können, da das Passwort nicht stimmt.
Allerdings kann der Angreifer die Query folgendermaßen manipulieren:
(&(user=Bob)(!(password=keineAhnung1234)))
Diese Query sucht nach einem User, der „Bob“ heißt, dessen Passwort aber NICHT „keineAhnung1234“ ist. Da diese Bedingung für den User Bob zutrifft – sein Passwort ist „admin123“ und nicht „keineAhnung1234“ –, autorisiert das LDAP den User erfolgreich.
So erhält der Angreifer Zugriff auf das System, ohne das Passwort von Bob zu kennen. Dieser Angriff lässt sich nicht nur für Bob, sondern für jeden Nutzer durchführen. Die beliebtesten Opfer sind natürlich Systemadministratoren.
Das Abfangen von User- oder Administrator-Passwörtern ist zwar sehr lukrativ, aber der Missbrauch von Benutzeraccounts durch Angreifer kann schnell auffallen. Kommunikationsuser hingegen werden selten beobachtet, schreiben/lesen oft viele Daten und fliegen daher unter dem Radar von Analysetools oder Intrusion-Detection-Software. Außerdem haben sie meist ein breites Spektrum an Berechtigungen und bieten dem Angreifer auch Zugriff auf die tiefsten Systeme.
Beim LDAP-Impersonation-Angriff gibt sich der Angreifer als LDAP-Server aus. Da LDAP nicht den angesprochenen Server mit einem Zertifikat verifiziert, kann der Angreifer die Verbindung zum Active Directory kappen und sich selbst als Active Directory ausgeben. Die Applikation verifiziert die Verbindung nicht und denkt, dass sie mit dem echten Active Directory spricht. Dabei versucht sie, sich am Server zu authentifizieren, bevor sie eine Query an den Server schickt. Hierfür wird der angegebene Kommunikationsuser benutzt. Die Applikation schickt Usernamen und Passwort des Kommunikationsbenutzers an den vermeintlichen AD-Server und der Angreifer gelangt an dessen Daten.
Beachtlich ist, dass man sich beim Entwurf des LDAP dieser Gefahr bewusst war und deshalb die Authentifizierung in LDAP in neueren Versionen mit Hash-Funktionen versehen hat. Der Server bekommt so gut wie nie ein Klartextpasswort des Kommunikationsusers, sondern fast ausschließlich Hashes.
Jedoch bietet das LDAP-Protokoll die Möglichkeit, den Server entscheiden zu lassen, welche Hash-Funktionen er akzeptiert. Das hat historische und technische Gründe. So kennen viele ältere LDAP-Server nur alte Hash-Funktionen. Meistens wird hier jedoch eine moderne SHA256-Funktion genutzt.
Behauptet der Angreifer, der einen LDAP simuliert, dass er nur unsichere Hash-Funktionen kennt, sendet die Applikation das Passwort des Kommunikationsusers ebenfalls mit einem unsicheren Hash. Diesen kann der Angreifer abfangen und Analyse-Tools nutzen, um ihn zu knacken und das Passwort zu extrahieren.
Auch SAP IdM benutzt standardmäßig eine unsichere Verbindung zum Active Directory, lässt jedoch die Verbindungsmöglichkeit per LDAPS offen. Beim Setzen von Active-Directory-Passwörtern hingegen ist es Pflicht, LDAPS zu nutzen. Viele IdM-Systeme haben also in einzelnen Prozessen LDAPS wahrscheinlich schon aktiviert.
Alle anderen Prozesse, zum Beispiel Initial Loads oder die Zuweisung von Privilegien, werden in der Regel nicht über LDAPS abgewickelt. Daher werden sie nach dem Patch ADV190023 nicht mehr funktionieren, weil der Server Operationen über LDAP nicht länger zulässt.
Je nach Prozess und Implementation könnte das schwerwiegende Auswirkungen in SAP IdM haben. Deshalb ist es ratsam, so schnell wie möglich mit dem Active-Directory-Admin zu sprechen und abzuklären, wann dieser Patch in der Infrastruktur eingespielt wird. Die LDAPS-Umstellung sollte auf jeden Fall VOR dem Patchen aktiviert und getestet werden, um einen störungsfreien Betrieb zu gewährleisten.
Folgende To-dos sind zu erledigen:
Einspielen der aktuellen AD-Zertifikate in den Java Keystore der Runtime
Umstellen aller IdM-Prozesse mit LDAP-Konnektivität auf LDAPS
Umstellung auf LDAPS Port 636
Aktivierung von SSL in den IdM Passes
LDAPS verbraucht nicht nur mehr Traffic, sondern auch mehr RAM/CPU. Möglicherweise ist mit einem erhöhten Overhead bei den Dispatchern zu rechnen. Ebenso sollten potenzielle CPU/RAM-Einschränkungen beachtet werden.
Gerade bei zeitkritischen Loads ist besondere Vorsicht geboten. Ein Beispiel: Ein LDAP-Load wird um 12 Uhr gestartet und um 13 Uhr soll ein Folgeload die eingelesenen Daten für andere Prozesse wiederverwenden. Obwohl der Load unter LDAP in weniger als einer Stunde gelaufen ist, könnte der LDAPS-Load länger dauern, sodass der Folgeload unter Umständen mit unvollständigen Daten startet.