Nochmals kurz zu einem Sicherheitsthema, welches ich bereits im Blog grob adressiert hatte. Microsoft hat bei der Office 20xx-Installation mehrere potentielle Schwachstellen, von denen eine gefixt wurde, aber einige wohl offen bleiben sollen.
Anzeige
Sicherheitslücke im Office-Installer ose.exe gefixt
Microsoft hatte seit Jahren eine wandelnde Sicherheitslücke im Office-Installer ose.exe. Dieser Installer wird einzelne Office-Anwendungen oder das gesamte Paket verwendet. Stefan Kanthak hatte Microsoft auf die potentielle Schwachstelle in ose.exe aufmerksam gemacht und Microsoft wollte diese schließen. Ich hatte das Thema ausführlicher im Blog-Beitrag Microsoft und die Office 20xx-Sicherheitslücke in ose.exe behandelt.
Warum DLL-Hijacking ein Problem ist
DLL-Hijacking bedeutet, dass sich Malware im Huckepack bei der Installation eines (Office-)Pakets über dessen Entpacker oder Installer administrative Berechtigungen verschaffen kann (weil diese mit Administratorberechtigungen laufen und dann abhängige Komponenten in Form von DLL-Bibliotheken nachladen).
Ein Problem beim Office-Entpacker
Im Entpacker officesips.exe, der von Office-Modulen und -Updates verwendet wird, kommt das Problem hinzu, dass diese bereits mit Administratorrechten ausgeführt werden. Stefan Kanthak schreibt dazu:
diese Selbstextraktoren fordern beim Start Administratorrechte
an, obwohl die gar nicht nötig sind! Erst wenn diese eine von ihnen ausgepackte Datei installieren wollen sind ggf. Administratorrechte nötig; die Updates für Office sind *.MSP, die werden an den Windows Installer verfüttert, der sich selbst um erhöhte Rechte kümmert, d.h. das Verhalten des Selbstextraktors ist völlig bescheuert!
In der Tat sind mir schon Software-Pakete untergekommen, wo die Entwickler während der Installation mit Standard-Benutzerrechten entpacken. Erst die MSI-Pakete fordern dann beim Aufruf Administratorrechte per Benutzerkontensteuerung an. Stefan Kanthak schrieb mir dazu, dass Microsoft da aber wohl aktiv geworden ist und die Schwachstelle beseitigt habe.
officesips.exe ist der Standard-Selbstextraktor, den Microsoft seit Office 2007 für alle Sicherheitsupdates oder Extra-Würste verwendet; dieser ist (wie üblich) anfällig fuer DLL hijacking.
Ich war völlig baff, dass Microsoft in diesem Fall DLL-Hijacking in einem ihrer Installationsprogramme behoben hat; normalerweise weigern sie sich, diesen Anfängerfehler zu beseitigen!
Ob sie diese Korrektur auch in alle seitdem gebaute Selbstextraktoren übernommen haben, habe ich nicht geprüft; eigentlich müssten sie das machen, wenn die verschiedenen Teams den Quelltext des Extraktors aus einer gemeinsamen Ablage verwenden.
Es sieht also so aus, als ob Microsoft solche Schwachstellen beseitigen will, wenn das möglich ist. Allerdings ziehen sich diese Fehler durch viele Pakete (Installer, Update-Installer), so dass die Schwachstellen an vielen Ecken lauern.
Anzeige
SIPs: Ein weiteres Problem ist ungefixt
In Office werden "Microsoft Office Subject Interface Packages for Digitally Signing VBA Projects" unterstützt. Diese lassen sich von dieser Webseite herunterladen. Subject Interface Packages (SIPs), ermöglichen die digitale Signatur und Signaturprüfung von Visual Basic for Applications-Projekten in den meisten Microsoft Office Dateiformaten, die VBA-Makros unterstützen.
Stefan Kanthak hat mir noch einen Kurzabriss zum Thema bereitgestellt:
Ein "Subject Interface Package" (SIP) stellt Schnittstellen bereit, die von Windows Crypto-Subsystem (bzw. dem CryptoAPI alias CAPI) aufgerufen werden. Zweck ist es, Dateien/Daten (-strukturen) zu ver- und entschlüsseln, zu signieren etc. Eine umfangreichere Erläuterung findet sich in den Beiträgen
Subject Interface Packages – Part 1 und Subject Interface Packages – Part 2.Das Paket "Microsoft Office Subject Interface Packages for Digitally Signing VBA Projects" ist insbesondere für
Administratoren, die VBA-Makros auch ohne Installation von Microsoft Office signieren wollen oder müssen. Das ist z.B. erwünscht, wenn Administratoren im Unternehmen Office per GPO nur signierte VBA-Makros ausführen lassen
wollen. Das wäre eine gängige Praxis, die beispielsweise die Erstinfektion bei Krauss-Maffei oder im Klinikum Fürstenfeldbruck durch die Ransomware Emotet verhindert
hätte.
Diese SIPs werden über die Datei officesips.exe heruntergeladen und bei der Installation entpackt. Dort hat man aber wohl die (DLL-Hijacking) Schwachstellen nicht behoben. Dies geht aus der Korrespondenz zwischen Stefan Kanthak und dem Microsoft Security Response Team (MSRT) vor. Im Oktober 2018 gab es bereits folgenden Austausch zwischen dem MSRT und Stefan Kanthak:
> The product was fixed.
WRONG!
The executable self-extractor was fixed, but the product itself
(really: its installation process, as documented in README.txt)
is STILL vulnerable.On fresh installations of Windows the product's dependencies
MSVCR100.DLL, VCRuntime140.dll and MSVCP140.dll are NOT present.The command lines
REGSVR32.exe "%ProgramFiles%\vbe7.dll"
REGSVR32.exe "%ProgramFiles%\msosip.dll"
REGSVR32.exe "%ProgramFiles%\msosipx.dll"which according to the README.txt need to be run elevated, load MSVCR100.DLL, VCRuntime140.dll and MSVCP140.dll from the PATH, which is but under control of an attacker.
Please read my INITIAL vulnerability report AGAIN, more CAREFUL.
Then rebuild then product's modules WITHOUT dependencies to
files NOT shipped with all supported Windows versions, i.e.
replace the dependencies MSVCR100.dll, MSVCP140.dll and
VCRuntime140.dll with MSVCRT.dll> Please look out for your ACK in the October Hall of Fame
Microsoft hatte also die Schwachstellen beim Extrahieren von Office-Installationspaketen geschlossen. Das MSRT war daher der Meinung, dass der Fehler behoben sei (alle Zeilen mit > am Anfang). Stefan Kanthak hielt dort dagegen, dass es bei der Registrierung der betreffenden DLLs der Subject Interface Packages (SIPs) (aus der heruntergeladenen officesips.exe) mittels RegSvr32.exe weitere potentielle Angriffspunkte gibt. Anfang November fand dann folgender Mail-Austausch statt (alle Zeilen mit einem > am Anfang stammen vom MSRT).
Stefan,
> We are closing this case as a Duplicate of one of your earlier
>cases, 37732, which was fixed with an Advisory based on a
> Defense in Depth method.OUCH!
Case 37732 was
| %SystemRoot%\Temp\OSE*.exe, running under SYSTEM
| account, loads a bunch of
| DLLs from its application directory, which is writable by
| unprivileged users.See <https://seclists.org/bugtraq/2018/May/22>
The CURRENT, still UNFIXED vulnerability, is but UNRELATED to that case. It is:
| When registering VBE7.dll, MSOSIP.dll and MSOSIPX.dll,
| %SystemRoot%\System32\REGSVR32.exe, running with
| administrative privileges,
| loads the DEPENDENCIES (MSVCR100.DLL,
| VCRuntime140.dll and MSVCP140.dll) of
| VBE7.dll, MSOSIP.dll and MSOSIPX.dll from the PATH.Since these dependencies are missing in standard/default installations of Windows, arbitrary rogue DLLs with these names are loaded and their DllMain() executed in the REGSVR32.exe process.
Since PATH is under control of the unprivileged user this results in elevation of privilege.> Responses to this case will no longer be monitored.
Das Microsoft Security Response Team (MSRT) war der Meinung, dass der gemeldete Fall beendet sei, hat aber offenbar nicht erfasst, dass eine weitere Sicherheitslücke über officesips.exe in den genannten DLL-Modulen besteht. Bei der Registrierung der DLLs mit RegSvr32.exe sind administrative Berechtigungen erforderlich. Bei der Ausführung von RegSvr32.exe gibt es aber Abhängigkeiten auf diverse Bibliotheken aus Laufzeitumgebungen. Klinkt sich eine Malware dort ein, kann sich diese bei der Registrierung der DLLs wieder administrative Berechtigungen verschaffen. Stefan Kanthak fasst es wie folgt zusammen:
Was sie nicht gestopft haben sind die Luecken im Installationsprozess der ausgepackten DLLs: diese sind laut README per REGSVR32.exe zu registrieren. Dazu muss REGSVR32.exe mit erhoehten Rechten gestartet werden. Sobald dieses die ausgepackten DLLs laedt werden IMPLIZIT auch die DLLs geladen, von denen die ausgepackten DLLs abhaengig sind: MSVCR100.DLL, VCRuntime140.dll and MSVCP140.dll
Diese DLLs existieren in frischen Installationen von Windows NICHT, also werden sie im PATH gesucht … und dieser ist unter Kontrolle eines Angreifers.
Klingt zwar alles wie ein 'Orchideenthema' – und sicherlich kommt von dem einen oder anderen Blog-Leser die Bemerkung 'wenn eine Malware es auf ein System geschafft hat, ist eh alles zu spät'. Kann man alles diskutieren – aber der Umstand, dass Microsoft an einigen Stellen nachgebessert hat, zeigt, dass sie das Thema nicht auf die leichte Schulter nehmen.
Das Problem, was ich sehe: Deren Software ist inzwischen so komplex und in den Installer-Paketen stecken oft alte Komponenten mit Schwachstellen, so dass das Stopfen der Sicherheitslücken ein unendliches Thema ist. Für mich geht es daher nicht zusammen, dass Microsoft auf der einen Seite in AI-gestützte Advanced Thread Protection (ATP) mit dem Windows Defender investiert. Aber im gleichen Atemzug muss man feststellen, dass im Unterbau vieler Microsoft-Produkte oft die einfachsten Regeln im Hinblick auf robuste Programmierung zur Vermeidung von potentiellen Schwachstellen ignoriert werden.
Ähnliche Artikel:
Microsoft und die Office 20xx-Sicherheitslücke in ose.exe
Intel NUC per BIOS-Schwachstelle CVE-2018-12176 hackbar
Windows-Schwachstelle RID Hijacking macht dich zum Admin
RDP-Hijacking für RDS und RemoteApp
AppLocker mit #squiblydoo COM Hijacking aushebeln?
Warnung: NVTrimmer-Tool für Nvidia-Treiberanpassung
Warnung vor Intel Extreme Tuning Utility (XTU) V6.4.1.23
Anzeige
Wer ein Benutzerkonto mit administrativen Berechtigungen nutzt und Schadsoftware einpflegt, muss sich nicht wundern, wenn die Schadsoftware unter administrativen Berechtigungen agiert. Aus diesem Grund hat Microsoft vor langer Zeit UAC (User Account Control) eingeführt, um den Nutzer davor zu warnen, dass er mit einem priviligierten Konto angemeldet ist. Wer die UAC-Warnungen ignoriert und Software installiert, muss auch die Folgen tragen. Wer auf der sicheren Seite bleiben will, kann und sollte ein einfaches Benutzerkonto für die nicht-adminstrative Nutzung des Computers verwenden.
Genau da versucht die Malware ja "rüberzuflutschen". Anstatt auffällig selber die Anfrage aufklappen zu lassen geht es um Wege sich an legitime Installer "anzukletten" um unauffälligst die Berechtigungen zu kapern.
Das ist ja auch kein Problem, solange ein einfaches Benutzerkonto genutzt wird. Schadsoftware, die unter diesen Bedingungen installiert wird, besitzt lediglich die Berechtigungen des einfachen Benutzerkontos und hat keine Auswirkung auf die Nutzung von Benutzerkonten mit administrativen Berechtigungen.
Die Argumentation übersieht ein Problem: Wenn ein Admin die officesips.exe installieren will, benötigt dieser Prozess administrative Rechte. Und genau da könnte sich Malware durch DLL-Hijacking einklinken (einfach eine DLL im Pfad der Installationsdateien platzieren und warten, bis diese aufgerufen wird).
Das setzt jedoch voraus, dass der "Admin" zuvor auch die Schadsoftware mit seinem Benutzerkonto installiert hat. Anders geht es nicht — und Schadsoftware, die mit einem nicht-administrativen Benutzerkonto installiert wurde, bleibt hier wirkungslos. Sicherlich liegt es am "Admin", eine sichere Installationsumgebung zu schaffen.
Nachtrag:
Es mag dem Einen oder dem Anderen vielleicht nicht so leicht eingehen, aber die primären "Pfade" in denen Windows nach "DLLs" sucht, sind für jedes Benutzerkonto verschieden. Zum Beispiel ist der "Temp" Ordner von Benutzer A nicht der "Temp" Ordner von Benutzer B.
Windows 7 bietet mir ein IE-Update ausser der Reihe an: KB4483187
Ist das normal, oder hat es u.U. mit der anderen Zero-Day-Lücke von Windows 10 zu tun? Reine Spekulation, aber ich musste halt sofort daran denken.
Ich kann momentan nicht wirklich reagieren (nur Smartphone mit wackeliger Inetverb. und wenig Zeit). Ich hatte vorgestern einen Beitrag dazu.
https://www.borncity.com/blog/2018/12/19/sicherheitsupdate-kb4483187-fr-internet-explorer-19-12-2018/