lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 2 Oct 2013 01:21:53 +0200
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <bugtraq@...urityfocus.com>
Cc: <full-disclosure@...ts.grok.org.uk>
Subject: Defense in depth -- the Microsoft way (part 11): privilege escalation for dummies

Hi @ll,

in <http://seclists.org/fulldisclosure/2013/Sep/132> I showed a
elaborated way for privilege elevation using IExpress (and other
self-extracting) installers containing *.MSI or *.MSP which works
"in certain situations".

The same IExpress installer(s) but allow a TRIVIAL to exploit
privilege escalation which works in all situations too:

Proof of concept (run on a fully patched Windows 7 SP1):

Step 0:
   login as UAC-enabled user.

Step 1:
   download the IExpress package "CAPICOM-KB931906-v2102.exe" from
   <http://www.microsoft.com/en-us/download/details.aspx?id=3207>
   resp. <http://technet.microsoft.com/security/bulletin/ms07-028>

Step 2:
   download <http://home.arcor.de/skanthak/download/SENTINEL.EXE>
   (note: all downloads go per default into the same directory)
   as MSIEXEC.EXE (this executable is just used as a canary).

Step 3:
   execute the downloaded "CAPICOM-KB931906-v2102.exe" (UAC will
   ask for confirmation or prompt for administrative credentials).


Result:
   the downloaded MSIEXEC.EXE is executed with administrative
   credentials!


Reason:
   the COMPLETELY SUPERFLUOUS elevation of IExpress packages through
   UAC (due to its braindead "installer detection").


Note 0:
   it is completely sufficient to run IExpress packages unprivileged/
   unelevated: the target directory for the extraction,
   "%TEMP%\IXP000.TMP", can be created/written with standard user
   rights!

Note 1:
   if the downloaded MSIEXEC.EXE requests elevation by itself UAC
   displays the publisher name etc. read from the digital signature
   of the downloaded MSIEXEC.EXE giving the user a chance to detect
   the "fake" MSIEXEC.EXE.

Note 2:
   if an IExpress installer executes another command (setup.exe,
    ...) rename the downloaded file to the resp. name.

Note 3:
   of course other self-extractors which execute commands without
   fully qualified path (remember: the application directory is
   searched first) can be used too!

Note 4:
   in general, setup PROGRAMS are evil!

   there is no need to wrap a call of "MSIEXEC.EXE /package *.MSI"
   or "RUNDLL32.EXE SETUPAPI.DLL,InstallHinfSection ... *.INF"
   into an executable!

   at least Microsoft stopped to deliver updates/hotfixes/patches
   for NT6.x as executables, but uses CAB archives named *.MSU.


Timeline:
~~~~~~~~~

2013-09-22    sent report to vendor

2013-09-23    vendor replies and asks: is the vulnerability in IExpress?

2013-09-23    NO, the vulnerability results from the UAC!

2013-09-23    vendor replies: "this scenario has been publicly known,
              and was mentioned in a presentation a Black Hat in 2012.
              the resolution was to implement a policy that IExpress
              will no longer be used on Microsoft Update."

              Really & really?

              The Black Hat presentation used IExpress to wrap and
              disguise a MetaSploit/meterpreter payload, not for a
              privilege escalation.

              <http://www.microsoft.com/en-us/download/details.aspx?id=39802>
              alias <http://support.microsoft.com/kb/931125> is an
              IExpress package AND is delivered via Microsoft Update!

2013-09-23    asked about the details of the Black Hat presentation and
              whether/when the SUPERFLUOUS detection and elevation of
              IExpress installers will be addressed.

2013-09-30    vendor replies: "I still do not see any security vulnerability
              here. I can see an escalation of UAC privileges, but as has
              been documented on numerous occasions*, UAC is not considered
              to be a security boundary, so such an escalation is not
              considered to be a security vulnerability."

2013-10-02    report published


stay tuned
Stefan Kanthak

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ