This post outlines multiple unsafe practices in Microsoft Windows that can allow for local privilege escalation.
03789d62f112efaa28c4a21b48da3f31Hi @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 2922229
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 <command> between the parentheses.
Back-quoted is only correct with FOR /F "UseBackQ" %<var> IN (´<command>´) 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>