Carlo Di Dato : 25 July 2024 14:43
If you choose to read this article, please note that it will not discuss a vulnerability or a bug, but rather an intended behavior of Windows Command Prompt which, in my opinion, poses a security risk.
I decided to publish it because I was not aware of this behavior, and most of the people I asked about it were not aware of it either.
I would like to thank Microsoft’s MSRC for their prompt response to my report and the additional information they provided.
If you were already aware of the behavior shown in the following video, you can save yourself the trouble of reading this article
The Windows Command Prompt (cmd.exe) is the primary command-line shell used on Windows operating systems. This program is designed to interpret and execute a series of commands, passed as strings, both internal (e.g., “ping”, “ftp”, “notepad”, “calc”, etc.) and external (e.g., “blahblah”). The interpretation of the entered command follows the logic described at this link https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/start and can be summarized as follows:
For example:
Is this a problem? In my opinion, yes and this is because of the way file extensions are managed.
If the typed command does not have an extension, the command prompt will use the %PATHEXT% variable to get the list of extensions and check them one by one, according to Windows standard search order. In our example, the command prompt will look for “C:\test\ftp.vbs”, “C:\test\ftp.dll”, “C:\test\ftp.exe”, and so on until it finds a file with an extension to execute in the same path. This significantly increases the chances of executing risky files disguised as legitimate commands.
Keep in mind that this behavior will apply to all typed commands, included those saved in the “PATH” environment variable (e.g., “java”, “python”, “php”, “node”, etc.…)
A second risk is the possibility of executing commands from shared network folders:
Another attack scenario could involve creating a compressed file containing “ping.vbs”, convincing a user to decompress it and run the ping command from the folder where the archive that was decompressed.
An additional “remote” scenario might be:
If you want to try it by yourself, just follow these steps:
Last but not lease, I tested some Windows internal commands and most of them can be (ab)used to replicate the behavior and this is the list of the tested commands with their respective status:
Command | Affected |
cd | No |
cls | No |
copy | No |
del | No |
dir | No |
md | No |
mkdir | No |
move | No |
rd | No |
ren | No |
rename | No |
type | No |
cls | No |
set | No |
echo | Yes |
rmdir | Yes |
attrib | Yes |
chkdsk | Yes |
fc | Yes |
format | Yes |
mode | Yes |
more | Yes |
tree | Yes |
ftp | Yes |
ipconfig | Yes |
net | Yes |
ping | Yes |
tracert | Yes |
pathping | Yes |
tasklist | Yes |
taskkill | Yes |
sc | Yes |
sfc | Yes |
diskpart | Yes |
shutdown | Yes |
compact | Yes |
expand | Yes |
nbtstat | Yes |
xcopy | Yes |