![](\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2015\/01\/Schutz.jpg\")
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.<\/p>\nNochmals 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.<\/p>\n
<\/p>\n
Warum DLL-Hijacking ein Problem ist<\/strong><\/p>\n DLL-Hijacking bedeutet, dass sich Malware im Huckepack bei der Installation eines (Office-)Pakets \u00fcber dessen Entpacker oder\u00a0Installer administrative Berechtigungen verschaffen kann (weil diese mit Administratorberechtigungen laufen und dann abh\u00e4ngige Komponenten in Form von DLL-Bibliotheken nachladen).<\/p><\/blockquote>\n Im Entpacker\u00a0officesips.exe, <\/em>der von Office-Modulen und -Updates verwendet wird, kommt das Problem hinzu, dass diese bereits mit Administratorrechten ausgef\u00fchrt werden.\u00a0Stefan Kanthak schreibt dazu:<\/p>\n diese Selbstextraktoren fordern beim Start Administratorrechte In der Tat sind mir schon Software-Pakete untergekommen, wo die Entwickler w\u00e4hrend der Installation mit Standard-Benutzerrechten entpacken. Erst die MSI-Pakete fordern dann beim Aufruf Administratorrechte per Benutzerkontensteuerung an.\u00a0Stefan Kanthak schrieb mir dazu, dass Microsoft da aber wohl aktiv geworden ist und die Schwachstelle beseitigt habe.<\/p>\n officesips.exe ist der Standard-Selbstextraktor, den Microsoft seit\u00a0Office 2007 f\u00fcr alle Sicherheitsupdates oder Extra-W\u00fcrste verwendet;\u00a0dieser ist (wie \u00fcblich) anf\u00e4llig fuer DLL hijacking.<\/p>\n Ich war v\u00f6llig baff, dass Microsoft in diesem Fall DLL-Hijacking in\u00a0einem ihrer Installationsprogramme behoben hat; normalerweise weigern\u00a0sie sich, diesen Anf\u00e4ngerfehler zu beseitigen!<\/p>\n Ob sie diese Korrektur auch in alle seitdem gebaute Selbstextraktoren\u00a0\u00fcbernommen haben, habe ich nicht gepr\u00fcft; eigentlich m\u00fcssten sie das machen, wenn die verschiedenen Teams den Quelltext des Extraktors aus\u00a0einer gemeinsamen Ablage verwenden.<\/p><\/blockquote>\n Es sieht also so aus, als ob Microsoft solche Schwachstellen beseitigen will, wenn das m\u00f6glich ist. Allerdings ziehen sich diese Fehler durch viele Pakete (Installer, Update-Installer), so dass die Schwachstellen an vielen Ecken lauern.<\/p>\n In Office werden\u00a0\"Microsoft Office Subject Interface Packages for Digitally Signing VBA Projects\" unterst\u00fctzt. Diese lassen sich von dieser Webseite<\/a> herunterladen.\u00a0Subject Interface Packages (SIPs), erm\u00f6glichen die digitale Signatur und Signaturpr\u00fcfung von Visual Basic for Applications-Projekten in den meisten Microsoft Office Dateiformaten, die VBA-Makros unterst\u00fctzen.<\/p>\n Stefan Kanthak hat mir noch einen Kurzabriss zum Thema bereitgestellt:<\/p>\n Ein\u00a0\"Subject Interface Package\" (SIP)\u00a0stellt Schnittstellen bereit, die von Windows Crypto-Subsystem (bzw. dem CryptoAPI alias CAPI) aufgerufen werden. Zweck ist es,\u00a0Dateien\/Daten (-strukturen) zu ver- und entschl\u00fcsseln, zu signieren etc. Eine umfangreichere Erl\u00e4uterung findet sich in den Beitr\u00e4gen Das Paket \"Microsoft Office Subject Interface Packages for Digitally\u00a0Signing VBA Projects\" ist insbesondere f\u00fcr Diese SIPs werden \u00fcber die Datei officesips.exe<\/a>\u00a0heruntergeladen und bei der Installation entpackt.\u00a0Dort hat man aber wohl die (DLL-Hijacking) Schwachstellen nicht behoben. Dies geht aus der\u00a0Korrespondenz 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:<\/p>\n > The product was fixed.<\/p>\n WRONG! On fresh installations of Windows the product's dependencies The command lines which according to the README.txt need to be run elevated, load\u00a0MSVCR100.DLL, VCRuntime140.dll and MSVCP140.dll from the PATH,\u00a0which is but under control of an attacker.<\/p>\n Please read my INITIAL vulnerability report AGAIN, more CAREFUL.<\/p>\n Then rebuild then product's modules WITHOUT dependencies to > Please look out for your ACK in the October Hall of Fame<\/p><\/blockquote>\n 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\u00a0DLLs der\u00a0Subject Interface Packages (SIPs) (aus der heruntergeladenen officesips.exe<\/em>) mittels RegSvr32.exe weitere potentielle Angriffspunkte gibt. Anfang November fand dann folgender Mail-Austausch statt (alle Zeilen mit einem > am Anfang stammen vom MSRT).<\/p>\n Stefan, OUCH!<\/p>\n Case 37732 was<\/p>\n | %SystemRoot%\\Temp\\OSE*.exe, running under SYSTEM See <https:\/\/seclists.org\/bugtraq\/2018\/May\/22<\/a>><\/p>\n The CURRENT, still UNFIXED vulnerability, is but UNRELATED to that case. It is:<\/p>\n | When registering VBE7.dll, MSOSIP.dll and MSOSIPX.dll, Since these dependencies are missing in standard\/default installations\u00a0of Windows, arbitrary rogue DLLs with these names are loaded and their\u00a0DllMain() executed in the REGSVR32.exe process. > Responses to this case will no longer be monitored.<\/p><\/blockquote>\n Das Microsoft Security Response Team (MSRT) war der Meinung, dass der gemeldete Fall beendet sei, hat aber offenbar nicht erfasst, dass eine weitere Sicherheitsl\u00fccke \u00fcber officesips.exe<\/em> in den genannten DLL-Modulen besteht. Bei der Registrierung der DLLs mit RegSvr32.exe sind administrative Berechtigungen erforderlich. Bei der Ausf\u00fchrung von RegSvr32.exe gibt es aber Abh\u00e4ngigkeiten 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:<\/p>\n Was sie nicht gestopft haben sind die Luecken im Installationsprozess\u00a0der ausgepackten DLLs: diese sind laut README per REGSVR32.exe zu\u00a0registrieren. 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<\/p>\n Diese DLLs existieren in frischen Installationen von Windows NICHT,\u00a0also werden sie im PATH gesucht … und dieser ist unter Kontrolle\u00a0eines Angreifers.<\/p><\/blockquote>\n Klingt zwar alles wie ein 'Orchideenthema' \u2013 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\u00e4t'. Kann man alles diskutieren \u2013 aber der Umstand, dass Microsoft an einigen Stellen nachgebessert hat, zeigt, dass sie das Thema nicht auf die leichte Schulter nehmen.<\/p>\n 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\u00fccken ein unendliches Thema ist. F\u00fcr mich geht es daher nicht zusammen, dass Microsoft auf der einen Seite in AI-gest\u00fctzte 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.<\/p>\n \u00c4hnliche Artikel:<\/strong> 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.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[426],"tags":[4328],"class_list":["post-212968","post","type-post","status-publish","format-standard","hentry","category-sicherheit","tag-sicherheit"],"_links":{"self":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/212968","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/comments?post=212968"}],"version-history":[{"count":0,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/212968\/revisions"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/media?parent=212968"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/categories?post=212968"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/tags?post=212968"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Microsoft hatte seit Jahren eine wandelnde Sicherheitsl\u00fccke im Office-Installer ose.exe<\/em>. Dieser Installer wird einzelne Office-Anwendungen oder das gesamte Paket verwendet. Stefan Kanthak hatte Microsoft auf die potentielle Schwachstelle in ose.exe <\/em>aufmerksam gemacht und Microsoft wollte diese schlie\u00dfen.\u00a0Ich hatte das Thema ausf\u00fchrlicher im Blog-Beitrag Microsoft und die Office 20xx-Sicherheitsl\u00fccke in ose.exe<\/a> behandelt.<\/p>\n
Ein Problem beim Office-Entpacker<\/h2>\n
\nan, obwohl die gar nicht n\u00f6tig sind!\u00a0Erst wenn diese eine von ihnen ausgepackte Datei installieren wollen sind ggf. Administratorrechte n\u00f6tig; die Updates f\u00fcr Office sind *.MSP, die werden an den Windows Installer\u00a0verf\u00fcttert, der sich selbst um erh\u00f6hte Rechte k\u00fcmmert, d.h.\u00a0das Verhalten des Selbstextraktors ist v\u00f6llig bescheuert!<\/p><\/blockquote>\nSIPs: Ein weiteres Problem ist ungefixt<\/h2>\n
\nSubject Interface Packages – Part 1<\/a> und\u00a0Subject Interface Packages – Part 2<\/a>.<\/p>\n
\nAdministratoren, die VBA-Makros auch ohne Installation von Microsoft\u00a0Office signieren wollen oder m\u00fcssen. Das ist z.B. erw\u00fcnscht, wenn Administratoren im\u00a0Unternehmen Office per GPO nur signierte VBA-Makros ausf\u00fchren lassen
\nwollen. Das w\u00e4re eine g\u00e4ngige Praxis, die beispielsweise die Erstinfektion\u00a0bei Krauss-Maffei<\/a> oder im Klinikum F\u00fcrstenfeldbruck<\/a> durch die Ransomware Emotet verhindert
\nh\u00e4tte.<\/p><\/blockquote>\n
\nThe executable self-extractor was fixed, but the product itself
\n(really: its installation process, as documented in README.txt)
\nis STILL vulnerable.<\/p>\n
\nMSVCR100.DLL, VCRuntime140.dll and MSVCP140.dll are NOT present.<\/p>\n
\nREGSVR32.exe \"%ProgramFiles%\\vbe7.dll\"
\nREGSVR32.exe \"%ProgramFiles%\\msosip.dll\"
\nREGSVR32.exe \"%ProgramFiles%\\msosipx.dll\"<\/p>\n
\nfiles NOT shipped with all supported Windows versions, i.e.
\nreplace the dependencies MSVCR100.dll, MSVCP140.dll and
\nVCRuntime140.dll with MSVCRT.dll<\/p>\n
\n> We are closing this case as a Duplicate of one of your earlier
\n>cases,\u00a037732, which was fixed with an Advisory based on a
\n> Defense in Depth\u00a0method.<\/p>\n
\n| account, loads a bunch of
\n| DLLs from its application directory, which is writable by
\n| unprivileged users.<\/p>\n
\n| %SystemRoot%\\System32\\REGSVR32.exe, running with
\n| administrative privileges,
\n| loads the DEPENDENCIES (MSVCR100.DLL,
\n| VCRuntime140.dll\u00a0and MSVCP140.dll) of
\n| VBE7.dll, MSOSIP.dll and MSOSIPX.dll from the PATH.<\/p>\n
\nSince PATH is under control of the unprivileged user this results in\u00a0elevation of privilege.<\/p>\n
\nMicrosoft und die Office 20xx-Sicherheitsl\u00fccke in ose.exe<\/a>
\nIntel NUC per BIOS-Schwachstelle CVE-2018-12176 hackbar<\/a>
\nWindows-Schwachstelle RID Hijacking macht dich zum Admin<\/a>
\nRDP-Hijacking f\u00fcr RDS und RemoteApp<\/a>
\nAppLocker mit #squiblydoo COM Hijacking aushebeln?<\/a>
\nWarnung: NVTrimmer-Tool f\u00fcr Nvidia-Treiberanpassung<\/a>
\nWarnung vor Intel Extreme Tuning Utility (XTU) V6.4.1.23<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"