-
Nicht nur Java betroffen
Autor: 0xDEADC0DE 08.02.16 - 17:24
Es sind unzählige, nicht bekannte Anwendungen betroffen, die u. A. mit dem WiX Toolset erstellt worden sind:
http://wixtoolset.org/news/
WiX v3.10.2 is an important security release of the WiX toolset. All users of WiX's Burn engine should upgrade to WiX v3.10.2 as soon as possible. Special thanks to FireGiant for rapidly and responsibly addressing the issue. They have more details on their blog. -
Re: Nicht nur Java betroffen
Autor: hg (Golem.de) 08.02.16 - 17:49
Danke für den Hinweis, das schaue ich mir nochmal genauer an!
Hauke Gierow - Golem.de -
Re: Nicht nur Java betroffen
Autor: FibreFoX 08.02.16 - 21:23
Wie unlängst auch auf Full-Disclosure diskutiert bzw. gelistet, ist das eine Architektur-Schwäche von Windows selber, zu der es von Microsoft aber schon lange entsprechende Tipps gegen dieses Problem gibt:
http://seclists.org/fulldisclosure/2015/Dec/index.html
Eine Suche nach dem Titelbestandteil "Executable installers are vulnerable^WEVIL" ergibt hier wunderbar viele Treffer, die zeigen, dass selbst AV-Software-Hersteller davon betroffen sind.
Ist also IMHO kalter Kaffee. -
Re: Nicht nur Java betroffen
Autor: 0xDEADC0DE 09.02.16 - 12:12
Das stimmt und aus genau dem Grund sollen Installer eben nicht mehr Setup.exe benannt werden weil dann natürlich jede x-beliebige Seite eine Setup.dll unterjubeln kann, die dann von der Setup.exe auch indirekt von Windows geladen wird.
-
Re: Nicht nur Java betroffen
Autor: geeky 09.02.16 - 14:28
Man wird eher per Process Monitor oder ähnlichem schauen, welche dlls die .exe versucht zu laden und einfach eine nehmen, die nicht explizit auf dem Windows-Ordner geladen wird, und die als Hijack-DLL versuchen im Download-Ordner zu platzieren.
Windows lädt nicht generell eine setup.dll wenn es eine setup.exe gibt (oder war das so gar nicht gemeint?)
Bei Dateinamen wie "setup.exe" öffnet Windows allerdings generell den UAC-Prompt (sofern die setup.exe kein Manifest enthält). Setup-Dateien sind quasi nur besonders interessant, weil die untergejubelte *.dll dann mit mehr Rechten läuft.
Einfachste Lösung für Installer wäre eigentlich das dafür vorgesehene MSI-Format zu verwenden oder zumindest das Anwendungsverzeichnis (Download-Ordner) per SetDllDirectory("") bzw SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32) aus dem Suchpfad zu entfernen - wobei man hier noch aufpassen muss, dass der Befehl auch tatsächlich vor Laden diverser DLLs ausgeführt wird. Die APIs dürften wohl die meisten betroffenen Installer als Bugfix einbauen (wie es z.B. beim WiX Toolset getan hat) -
Re: Nicht nur Java betroffen
Autor: 0xDEADC0DE 10.02.16 - 14:23
Ich schätze Windows versucht immer Dlls nachzuladen, die den selben Namen wie die Exe, nur halt mit .dll statt .exe als Endung.
ProcMon taugt zum Ausnutzen recht wenig, weil kein Zugriff auf das Zielsystem vorhanden ist. Man könnte aber Seiten infizieren, die Setup.exe Dateien oder auch Installer.exe Dateien zur Verfügung stellen und dann eben Setup.dll oder Installer.dll unterjubeln. Bei "MyFirstApp v1.2.exe" ist das eher unwahrscheinlich auf den Namen zu kommen und die Datei dann auch der Downloadseite so unterzuschieben.
Siehe https://www.firegiant.com/blog/2016/1/20/wix-v3.10.2-released/ -
Re: Nicht nur Java betroffen
Autor: geeky 10.02.16 - 20:56
Ich hab mal fix mit VS2015 eine einfache Setup.exe (ohne CRT) erstellt, die nur eine MessageBox anzeigt und mal geschaut, welche DLLs da versucht wird zu laden:
Eine setup.dll ist zwar nicht dabei, aber etliche andere DLLs werden im Anwendungsordner gesucht, unter anderem:
- UxTheme.dll
- WINMM.dll
- samcli.dll
- MSACM32.dll
- VERSION.dll
- USERENV.dll
- dwmapi.dll
- urlmon.dll
- MPR.dll
- WINMMBASE.dll
- iertutil.dll
- bcrypt.dll
...also lauter Windows DLLs, zu denen man infizierte Dateien natürlich leicht in den Downloads-Ordner bekommen könnte.
(Edit: Getestet unter dem aktuellen Win10 x64 Insider-Build)
Der Fall tritt nicht auf, wenn man die .exe z.B. in test.exe umbenennt, d.h. diese Setup-Erkennung anhand von Dateinamen von Windows ist hier der Übeltäter.
(http://blogs.msdn.com/b/onoj/archive/2007/04/20/windows-vista-uac-and-installer-detection.aspx)
Wenn die Datei test.exe heisst, wird uxtheme.dll, etc. erst bei Aufruf der MessageBox-Funktion versucht zu laden - also wenn die Anwendung bereits den Programmeinsprungpunkt passiert hat und via SetDllDirectory("") die Dll Suchreihenfolge bereits ändern konnte. Sie ist dann also nicht betroffen.
=> D.h. wenn die .exe setup.exe heisst, hat man als Anwendungsentwickler scheinbar gar keine Chance den Installer abzusichern, weil Windows selbst scheinbar auf unsichere Weise DLLs in den Prozess lädt, bevor der reguläre Prozess-Einsprungspunkt angesprungen wird.
Betroffen sind dann also vermutlich sämtliche Installer, die Windows über den Dateinamen als Setup identifiziert ;(
1 mal bearbeitet, zuletzt am 10.02.16 20:58 durch geeky.



