CGI Vulnerabilities
by Aleksandar Stancin - for Help Net Security
In order for an attacker to find an vulnerable CGI, all he has to do is to connect to port 80 and repeatedly send a GET request to CGI's on the server or suspecting they are on the server. Simply by checking your logs for repeated GET requests from a single remote host resulting in a 404, the 'file not found' error can give you an idea that something wicked is going on. As time passes, that same attacker may come up with an unsecure CGI on your system. If that is the case, he'll most probably try to exploit the vulnerability.

Basically, most security issues that arise from usage of CGI's is the fact that the user input is not parsed or filtered properly, and various parameters, or commands can be issued via web URL. An attacker may try to access any of your CGI's in order to exploit any known security issues or vulnerabilities. For instance, an example of malformed URL would be:

As you can see, after the valid part of the URL, the attacker has added a new line code (%0a) and has issued a simple viewing of /etc/passwd via the cat command. The %20 presents an ASCII value for a blank line. This will not work provided that the CGI is properly set. Also, badly implemented system calls in various scripting languages such as perl, can prove to be fertile ground for various vulnerabilities.

Another example of viewing the files outside the restricted folder is to exploit a bug in the viewsrc.cgi, which is documented here. It's a script for viewing source code, but it contains a vulnerability which allows viewing any file on the server, by issuing the following



But viewing of files is not the end of the story. You can do a Denial of service attack against a host running a vulnerabile CGI, for instance, a good example is the IBM Websphere/NetCommerce3 DoS vulnerability, where you can do a DoS against a server running Websphere/NetCommerce3, by simply issuing the following:

http://host/cgi-bin/ncommerce3/ExecMacro/macro.d2w/%0a%0a..(aprox 1000)..%0a

Those were the most obvious examples of a CGI vulnerabilities. A lot of other possibilites exist for an attacker, weather it may be a simple directory traversal, command execution to obtaining the proper permissions or privileges to manipulate with the web server.

If you're planning on creating some CGI's of your own, bear in mind these few things: in perl and bash scripts, don't use the 'eval' statement used for creating strings which will be executed, be careful with popen() and system() calls, and turn off the server side includes. Also, don't leave any means for a client to manipulate with input of your scripts, don't rely on the fact that it will escape any special characters for they will be used by an attacker. It would be smart to check the 'suexec' documentation, for apache web server and use it on your server.

If you're interested in tools publicly available for checking CGI vulnerabilities, read on...

And cats have...whiskers!

A great and effective CGI scanner is Rain Forrest Puppy's Whisker. You can obtain Whisker here.. Download it and use it. It's a perl script, so you have nothing left to do but run it, so:

perl -i -v -h hostname -l filename

and the filename you provided should resemble something like this. Mind you, these whiskers can smell a lot of things, and if you invoke it without any switches and addresses, ie perl you will get a full list of options. As you can see from the output, it's pretty much clear situation. Of course, output may vary, from host to host, accordingly. So, try it, and see for yourself.


Most IT pros have seen potentially embarrassing information about their colleagues

More than three-quarters of IT professionals have seen and kept secret potentially embarrassing information about their colleagues, according to new research conducted by AlienVault.

Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.

Daily digest

Receive a daily digest of the latest security news.

Wed, Feb 10th