Hi @ll,
the batch script WINRM.CMD, which contains just the single line
@cscript //nologo "%~dpn0.vbs" %*
allows a binary planting or squatting attack: WINRM.CMD executes a
rogue CSCRIPT.COM, CSCRIPT.EXE, CSCRIPT.BAT, CSCRIPT.CMD etc. (see
environment variable PATHEXT) from the current working directory.
Proof of concept:
1. Start CMD.EXE
2. CHDIR /D "<arbitrary writable directory>"
(for example "%USERPROFILE%\Desktop", "%USERPROFILE%\Downloads",
"%HOMEDRIVE%%HOMEPATH%" or "%TEMP%")
3. COPY "<arbitrary executable>" .\CSCRIPT.COM
4. WINRM /?
-> .\CSCRIPT.COM is run!
WIMRM.CMD is installed as part of the (optional) "Windows Remote
Management" (see <http://msdn.microsoft.com/
available for Windows XP and 2003 with the hotfixes KB936059 and
KB968929, and included in all later versions of Windows.
"Windows Remote Management" implements the DMTF's Web Services for
Management alias WS-Management alias WS-MAN.
Trivial fix: change "@cscript " in %SystemRoot%\System32\WINRM.
to "@%SystemRoot%\System32\
JFTR: <http://blogs.technet.com/b/
aint enough!
ALL executables fed to interfaces which evaluate PATH, i.e.
CreateProcess(), ShellExecute(), CMD.EXE, ... MUST be specified
with their fully qualified pathname.
regards
Stefan Kanthak
Timeline:
~~~~~~~~~
2014-01-23 informed vendor
2014-01-23 vendor opens MSRC case 16790
... no more reaction from vendor
2014-06-20 requested status from vendor
2014-06-20 vendor replies:
"Not a vulnerability.
All directories on the PATH are protected and need Admin
privileges to modify. Modifying the PATH also require
admin privileges."
OUCH!
2014-06-20 rectified vendors elementary misunderstanding of CMD.EXE's
PATH handling:
- CMD.EXE (which interprets WINRM.CMD) searches . (the
current working directory) FIRST, ALWAYS;
- PATH (and of course PATHEXT too) can always be modified
by (unprivileged) users in various ways, both temporary
and permanent;
- users have full control over ., PATH and PATHEXT!
... no more reaction from vendor
2014-06-25 report published
//The information contained within this publication is
//supplied "as-is"with no warranties or guarantees of fitness
//of use or otherwise. Bot24, Inc nor Bradley Sean Susser accepts
//responsibility for any damage caused by the use or misuse of
//this information
the batch script WINRM.CMD, which contains just the single line
@cscript //nologo "%~dpn0.vbs" %*
allows a binary planting or squatting attack: WINRM.CMD executes a
rogue CSCRIPT.COM, CSCRIPT.EXE, CSCRIPT.BAT, CSCRIPT.CMD etc. (see
environment variable PATHEXT) from the current working directory.
Proof of concept:
1. Start CMD.EXE
2. CHDIR /D "<arbitrary writable directory>"
(for example "%USERPROFILE%\Desktop", "%USERPROFILE%\Downloads",
"%HOMEDRIVE%%HOMEPATH%" or "%TEMP%")
3. COPY "<arbitrary executable>" .\CSCRIPT.COM
4. WINRM /?
-> .\CSCRIPT.COM is run!
WIMRM.CMD is installed as part of the (optional) "Windows Remote
Management" (see <http://msdn.microsoft.com/
available for Windows XP and 2003 with the hotfixes KB936059 and
KB968929, and included in all later versions of Windows.
"Windows Remote Management" implements the DMTF's Web Services for
Management alias WS-Management alias WS-MAN.
Trivial fix: change "@cscript " in %SystemRoot%\System32\WINRM.
to "@%SystemRoot%\System32\
JFTR: <http://blogs.technet.com/b/
aint enough!
ALL executables fed to interfaces which evaluate PATH, i.e.
CreateProcess(), ShellExecute(), CMD.EXE, ... MUST be specified
with their fully qualified pathname.
regards
Stefan Kanthak
Timeline:
~~~~~~~~~
2014-01-23 informed vendor
2014-01-23 vendor opens MSRC case 16790
... no more reaction from vendor
2014-06-20 requested status from vendor
2014-06-20 vendor replies:
"Not a vulnerability.
All directories on the PATH are protected and need Admin
privileges to modify. Modifying the PATH also require
admin privileges."
OUCH!
2014-06-20 rectified vendors elementary misunderstanding of CMD.EXE's
PATH handling:
- CMD.EXE (which interprets WINRM.CMD) searches . (the
current working directory) FIRST, ALWAYS;
- PATH (and of course PATHEXT too) can always be modified
by (unprivileged) users in various ways, both temporary
and permanent;
- users have full control over ., PATH and PATHEXT!
... no more reaction from vendor
2014-06-25 report published
//The information contained within this publication is
//supplied "as-is"with no warranties or guarantees of fitness
//of use or otherwise. Bot24, Inc nor Bradley Sean Susser accepts
//responsibility for any damage caused by the use or misuse of
//this information