Help eliminate unquoted path vulnerabilities
-
not connected with Facebook
![Facebook "Like"-Dummy]()
-
not connected with Twitter
!["Tweet this"-Dummy]()
-
not connected with Google+
!["Google+1"-Dummy]()
Last Updated: 2012-11-08 04:05:52 UTC
by Mark Baggett (Version: 1)
Metasploit’s “Service Trusted Path Privilege Escalation” exploit takes advantage of unquoted service paths vulnerability outline in CVE-2005-1185, CVE=2005-2938 and CVE-2000-1128. The vulnerability takes advantage of the way Windows parses directory paths to execute code. Consider the following command line.
C:\windows\system32\notepad \temp\file.txt
This tells windows to launch notepad.exe from the c:\windows\system32\ directory and pass it the argument \temp\file.txt. The result is notepad.exe will execute and begin editing file.txt from the temp directory. How does Window’s differentiate between the program and the arguments? The SPACE is used as a delimiter between the program to execute and the arguments. Now consider this command line.
C:\program files\Microsoft Office\Winword.exe
If space is used as a delimiter, wouldn’t Windows think you are trying to execute the program C:\PROGRAM.EXE and pass it the argument “files\Microsoft Office\Winword.exe”? Or maybe you are trying to execute “C:\Program files\Microsoft.exe” and pass it the argument “Office\Winword.exe”? So how does it know what you are trying to do? If the software developer places quotation marks around the path then Windows knows the spaces are spaces and not delimiters. If the software developer fails to put the path in quotes then Windows just doesn’t know. If Windows doesn’t know then it tries to execute all the possible programs in the path. First it tries “C:\Program.exe”, Then, it tries “C:\Program files\Microsoft.exe” and finally the path we intended for it to execute.
This programming error is very common because when a developer is addressing paths on the file system they are usually stored in strings. Because they are in strings the developer has used quotes once already and they often fail to consider that they need two sets of quotes. For example, the following line would incorrectly assign the path variable.
pathvariable = “C:\Program Files\Common Files\Java\Java Update\jusched.exe”
Really, the developer needs to double quote it because they need the path to contain quotes. So they should have assigned their variable by doing something like this:
pathvariable = “\\”C:\Program Files\Common Files\Java\Java Update\jusched.exe\\””
In the first case, an attacker can strategically place a program in the path and his program will be executed instead of the intended program. If the process runs under administrative privileges or some account other than the attacker it can be used to cause code to execute under a different set of privileges.
We have known about these types of vulnerabilities for 12 years now. So much so, that if you create a file called c:\program.exe Windows will generate this pop up when you reboot the machine.
With such an old vulnerability, surely very few programs suffer from this problem, right? You might be surprised at how often this vulnerability occurs. So let’s start fixing it! This is an easy problem to identify. Here are some steps you can follow to identify applications that fail to quote their file paths directly. Then you can help fix this by contacting the vendor to have them fix these issues.
First you need to copy any existing executable and create a program named c:\program.exe. For example, take a copy of calc.exe and name it c:\program.exe. Then make a copy of calc.exe named c:\program files\common.exe. Last, create a copy of calc.exe called c:\documents.exe. Then go about your business and use your computer as you normally would. Sometime while you are running normal applications they will accidently launch the renamed calc.exe. System reboots, services and scheduled tasks may trigger calculator. Whatever the cause, eventually you will likely run a vulnerable program and it will launch the application on your computer. Several days may transpire between the time you create the files and the time they are executed. Remember you did this when you have strange copies of calc.exe spontaneously launching on your computer. Once one your copy of calculator executes, first find out which one of your calc.exe programs launched and who launched it. Use WMIC to query which copy of your calculator is running like this.
Here you can see this query for “program.exe” returns the command line that was executed when our executable launched. This program failed to properly quote the system paths and launched your renamed program. Often times you may be able to identify the vendor responsible for the software from just the command line that launched your program. But often times it is also useful to know the parent process that launched the command line that started your program. To find out what program launched the unquoted path we use the following commands.
There you go bug hunter. You found a 0-Day vulnerability! Now notify the vendor so they can patch it and keep everyone safe. While you are at it you can notify
us if you would like.
Join me in San Antonio Texas November 27th for SANS 504 Hacker Techniques, Exploits and Incident Response! Register Today!!
Follow me on Twitter @MarkBaggett
Mark Baggett
Update: Here are some additional references. Thanks to altonius for the links
http://blakhal0.blogspot.com/2012/08/hiding-files-by-exploiting-spaces-in.html
Comments
Thanks.
For example, if I right-click on my (XP SP3) desktop an choose "New" then "Shortcut", notepad starts.
Note: in registry key "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\" I have the value "CWDIllegalInDllSearch" set to 0xFFFFFFFF, which helps to prevent some "path" related vulnerabilities, but may cause existing applications to fail.
@G: agreed, applications such as web browsers should not drop binaries in unexpected directories. However such vulnerabilities have existed and may still exist. For example, Apple had to be convinced that dropping binaries on the users desktop was not a good idea (Google: safari carpet bomb).
http://xato.net/hardening/the-programexe-problem/
http://blakhal0.blogspot.com/2012/08/hiding-files-by-exploiting-spaces-in.html
Like I said this has been around for 12 years so there are probably lots of other great blogs about the same problem. We had dozens of people report vulnerable programs to the ISC. They included Anti-Malware products, Patch Management / Software Deployment products, Authentication Systems (all of which ran as SYSTEM). We had others report software from HP, Dell, Cisco, Microsoft, Synaptic and more. The good news is all of the ISC reader are repoting the issues to the vendors so HOPEFULLY we did a good thing and closed some holes. Keep up the good work!
I do use a wacom tablet with an unquoted path in the service.
Microsoft should prevent .exe files with the same name as a prefix of a directory name.
C:\Users\xxx>wmic process where name="program.exe" get processid
ProcessId
6644
C:\Users\xxx>wmic process where name="program.exe" get parentprocessid
ParentProcessId
4420
C:\Users\xxx>wmic process where name="program.exe" get processid
ProcessId
4720
C:\Users\xxx>wmic process where name="program.exe" get parentprocessid
ParentProcessId
4420
C:\Users\xxx>wmic process where processid=4420 get commandline
CommandLine
C:\Windows\Explorer.EXE
Or, to make things easier... does this technique only run executables, or would C:\Program.bat also run?
Short answer: YES (remember Carl Sagan saying "billions-and-billions")
Long answer: NO (but only after you've exhaustively proved there is no possible 'YES' answer).
It's an easy question to ask, but almost impossible to give a complete & correct answer, until you:
(1) list all operating systems (including those embedded in your parallel-parking-assisted Ford automobile);
(2) list all versions and releases of each operating system;
(3) obtain "administrator" access, to plant the equivalent of 'C:\PROGRAM.EXE';
(4) reboot the operating system;
(5) record/summarize and then "responsibly-report" each vulnerable operating system.
Danish King Canute thought that he was powerful-enough to stop the incoming tide, until he was proved to be wrong. :-)