[English]Ich kippe mal wieder eine Information hier im Blog ein, über die ich die Tage gestolpert bin. Wer sich um den Punkt Windows-Sicherheit Gedanken macht, sollte das Befehlszeilentool licensingdiag.exe im Fokus behalten. Es ist ein weiteres "living of the land" Tool, welches für Side-Loading DLL-Angriffe genutzt werden kann. Denn es gibt in der Registrierung einen Eintrag, der angibt, welche DLL aus welchem Pfad zu laden ist.
Anzeige
Dynamic-Link-Library (DLL) Side-Loading ist eine Methode für Cyber-Angriffe, die sich die Art und Weise zunutze macht, wie Microsoft Windows-Anwendungen mit DLL-Dateien umgehen. Bei solchen Angriffen platziert Malware eine gefälschte bösartige DLL-Datei in einem WinSxS-Verzeichnis von Windows, so dass das Betriebssystem diese anstelle der legitimen Datei lädt. Mandiant befasst sich beispielsweise in diesem PDF-Dokument mit dieser Thematik. Es gibt aber weitere Möglichkeiten, das Laden einer DLL zu manipulieren.
Grzegorz Tworek hat die Tage nachfolgenden Tweet auf X veröffentlicht. Dort weist er darauf hin, dass das in Windows enthaltene Befehlszeilentool licensingdiag.exe eine Möglichkeit für Angriffe bietet. Weil das Tool in Windows enthalten ist, spricht man auch von "living of the land"-Angriffen.
In der Registrierung von Windows gibt es für die integrierte Anwendung licensingdiag.exe den Registrierungseintrag:
Anzeige
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\LicensingDiag
wo der REG_SZ-Wert den Pfad zur ausführenden DLL (hier LicensingDiagSpp.dll) enthält. Gelingt es einem Angreifer, den Registrierungseintrag zu manipulieren (HKLM erfordert Administratorrechte), ist die Büchse der Pandora geöffnet.
Ein Angreifer könnte dann einen Pfad auf eine eigene DLL hinterlegen, die dann beim Aufruf der Konsolenanwendung licensingdiag.exe ausgeführt wird. Ändert der Angreifer den Wert in REG_EXPAND_SZ, ließen sich gleich mehrere DLLs zum Aufrufen angeboten (ob das mit licensingdiag.exe klappt, sei dahin gestellt).Anwendung laden.
Einziger Schutz ist, dass die Manipulation Administratorrechte benötigt. Es wäre aber ein weiterer Weg, wie Angreifer sich hinter legitimen Windows-Anwendungen verstecken und bösartige DLLs per Side-Loading nachladen und ausführen können.
Ähnliche Artikel:
AdwCleaner 8.0.6 schließt erneut DLL-Hijacking-Schwachstelle
Die Nirsoft-Tools und die DLL-Hijacking-Schwachstellen
Microsoft fixt DLL-Hijacking-Schwachstelle in Store-App Telemetrie-Wrapper-Installer
Cicada: Chinesische Hacker missbrauchen u.a. den VLC Player per DLL-Side-Loading für Spionage
AppLocker mit #squiblydoo COM Hijacking aushebeln?
Anzeige
> Gelingt es einem Angreifer, den Registrierungseintrag zu manipulieren (HKLM erfordert Administratorrechte), ist die Büchse der Pandora geöffnet.
Hm, ich glaub wenn ein Angreifer Adminrechte hat ists eh vorbei :-)
Hm, denkst Du nicht zu kurz? Korrekt ist zwar, dass ein Angreifer keine Adminrechte bekommen sollte.
Aber mal weiter gedacht: Ich berichte hier ja schon mal über unerkannte Infektionen von Systemen, die über Jahre liefen. Auf den meisten Systemen laufen Super-Duper-Sicherheitslösungen.
Denke ich aus Sicht eines Akteurs, der möglichst lange unerkannt im System bleiben will, ist die Erlangung von Administrator- oder Systemberechtigungen ein Schritt. Weitere Schritte sind: Wie kann ich als Akteur meine Nutzlast im System verankern, ohne von Sicherheitslösungen oder Administratoren bemerkt zu werden? Wie erreiche ich, dass meine Nutzlast ggf. ein Update des Systems übersteht?
Ob der obige Ansatz praktisch ausnutzbar ist oder ob es einfachere Möglichkeiten gibt, kann ich nicht beurteilen. Ich zeige eine mögliche Problemstelle auf … nicht mehr und nicht weniger. Damit liegt der Ball im Spielfeld und mag aufgegriffen werden oder auch nicht.
"platziert Malware eine gefälschte bösartige DLL-Datei"
Wie Michael schon geschrieben hat.
Eine Malware auf einem Rechner, welche Dateien im WinSxS-Verzeichnis von Windows schreiben kann, ist kein "Einfaches" Programm.
Somit ist der Sideload eher ein Folgeproblem, nach der Infektion mit einer Malware.
Ein Folgeproblem ist dann aber nicht das Problem, sondern die Auswirkungen der Infektion.
Ein Angriff ist über diesen Weg grundsätzlich denkbar. Die DLL-Datei darf als solche aber nicht durch den Virenscanner erkannt werden, denn ich muss diese ja irgendwo im Dateisystem bereitstellen, so dass diese auch geladen werden kann. Somit läuft die DLL dem "living of the land" Gedanken ein wenig zuwider. Die bösartige DLL ist ja kein normaler Bestandteil des Betriebssystems.
Dazu kommt die Frage wie die Endpoint Protection mit neuen, ausführbaren Dateien umgeht bzw. wie die IT das konfiguriert hat. Hier dürften die Regelungen sehr unterschiedlich sein.
Bei uns ist es so geregelt, dass jede unbekannte Programmdatei erstmal geblockt wird, solange diese nicht eindeutig als gutartig klassifiziert wurde.
Die IT wird über jede dieser Blockierungen informiert und sieht auch in der Konsole, ob die Datei am Ende ein Virus war oder in die Liste der Goodware aufgenommen wurde. Auch bekommt man Informationen wie es zum Aufruf gekommen ist. Habe letztens selber eine Meldung erzeugt, als ich im Rahmen eines Updates eine Datenbankverbindung per ODBC zur einer Progress DB einrichten wollte. Der Treiber war schlicht noch nicht klassifiziert:
Warnung blockieren 03.07.2024 07:48:42 UTC
Zeitpunkt: 03.07.2024 07:48:26 UTC
Computer: XXX
Name des blockierten Elements: pgoe27.dll
Hash: 9E028EB0DEDFAB5505F57012044D0C87
Wird geladen von: SYSTEMX86|\odbcad32.exe
Hash: 270A8ECB4852CE263591DBBCEDE32EDA
Vertrauenswürdig: Ja
Occurrences on the network:
Liste weiterer PCs und Server, welche das blockierte Element im Dateisystem enthalten.
Das Ganze kann zwar auch nerven, weil in dem Moment erstmal keine Funktion vorhanden ist und die Klassifizierung auch etwas Zeit benötigt, aber ich denke einen Tod muss man sterben.
AUTSCH: das ist KWATSCH hoch 4!
1) Übel(!)schrift und Attributierung "DLL Side-Loading" sind GRÖBSTER irreführender Unfug: unter einem Registry-Schlüssel eingetragene (vollqualifizierte) DLL-Pfadnamen haben ÜBERHAUPT nichts mit dem WinSxS-Verzeichnis oder einem Anwendungs-spezifischen "side-by-side"-Verzeichnis zu tun!
2) "Ändert der Angreifer den Wert in REG_EXPAND_SZ, ließen sich gleich mehrere DLLs beim Aufruf der Anwendung laden." ist ebenfalls GRÖBSTER irreführender Unfug: das Programm LicensingDiag.exe erwartet jeweils EINEN DLL-Pfadnamen pro Registry-Eintrag — die Änderung in REG_MULTI_SZ wäre ebensolcher Unfug, da die Funktion LoadLibrary() nur den ersten NUL-terminierten DLL-Pfadnamen auswertet.
3) Da der existierende Registry-Eintrag SppDesktopGather vom Typ REG_SZ ist muss das Programm LicensingDiag.exe die dort referenzierte Umgebungsvariable %windir% SELBST auflösen — bei REG_EXPAND_SZ machen das die Funktionen zum Lesen von Registry-Einträgen.
4) "Dank" %windir% statt C:\Windows im Registry-Eintrag (ein BLUTIGER Anfängerfehler: siehe https://cwe.mitre.org/data/definitions/73.html "CWE-73: External Control of File Name or Path") kann jeder (unprivilegierte) Nutzer das Programm LicensingDiag.exe zum Laden beliebiger DLLs missbrauchen — was SAFER alias Softwarebeschränkungsrichtlinien, AppLocker sowie WDAC jedoch zuverlässig verhindern können: er legt ein Verzeichnis "System32" in einem beschreibbaren Verzeichnis an, darin dann eine LicensingDiagSpp.dll, setzt die Umgebungsvariable "windir" auf den Pfad des Elternverzeichnisses seines "System32" und ruft LicensingDiag.exe auf.
https://skanthak.hier-im-netz.de/!execute.html beschreibt, wie SICHERES Laden von DLLs zur Laufzeit (nicht nur) in LicensingDiag.exe zu implementieren ist, entweder LoadLibraryEx("LicensingDiagSpp.dll". NULL, LOAD_LIBRARY_SEARCH_SYSTEM32) zu verwenden oder SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32) vor dem ersten Aufruf von LoadLibrary("LicensingDiagSpp.dll") (siehe https://support.microsoft.com/en-us/kb/2533623 bzw. https://support.microsoft.com/en-us/kb/2758857)
"Windows-Sicherheit" ist ein Widerspruch in sich. Microsoft Produkte haben mit Sicherheit leider so gar nichts zu tun. Ein bessere Formulierung wäre "Windows-Unsicherheit" oder "Gefährdung durch Windows":
Wie andere schon geschrieben haben, es sind bereits Adminrechte notwendig, um diesen Angriffsvektor zu benutzen. Und dann muss man noch darauf hoffen, dass ein Benutzer das Tool licensingdiag.exe tatsächlich nutzt. Das Tool kennt wahrscheinlich niemand hier, es wird nur extrem selten mal benötigt, vielleicht höchstens mal bei einem Supportcase mit Microsoft?
Also, imho gibts da dauerhaftere, einfachere und zuverlässlichere Methoden, welche letztendlich "living of the land" eine Hintertür einbauen, zum Beispiel diese hier: Admin sein, (lokaler) Admin bleiben – Hacken als Admin -> https://www.gruppenrichtlinien.de/artikel/admin-sein-admin-bleiben-hacken-als-admin – Erschwerend kommt dazu, solche Scheduled Tasks netztwerkweit zu finden und als solche zuverlässig zu erkennen keine triviale Aufgabe ist.