mailing list archives
Defense in depth -- the Microsoft way (part 11): privilege escalation for dummies
From: "Stefan Kanthak" <stefan.kanthak () nexgo de>
Date: Wed, 2 Oct 2013 01:21:53 +0200
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):
login as UAC-enabled user.
download the IExpress package "CAPICOM-KB931906-v2102.exe" from
(note: all downloads go per default into the same directory)
as MSIEXEC.EXE (this executable is just used as a canary).
execute the downloaded "CAPICOM-KB931906-v2102.exe" (UAC will
ask for confirmation or prompt for administrative credentials).
the downloaded MSIEXEC.EXE is executed with administrative
the COMPLETELY SUPERFLUOUS elevation of IExpress packages through
UAC (due to its braindead "installer detection").
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
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.
if an IExpress installer executes another command (setup.exe,
...) rename the downloaded file to the resp. name.
of course other self-extractors which execute commands without
fully qualified path (remember: the application directory is
searched first) can be used too!
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.
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
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
- Defense in depth -- the Microsoft way (part 11): privilege escalation for dummies Stefan Kanthak (Oct 02)