Your system is the world's oyster

As written above, CGI's are programs or scripts, that serve as a gateway between your web and the end user. And, of course, CGI's are executables which means they run on your system. Now, the idea of having anyone accessing your web and running mayhem with executables on your system looks a bit frightening, does it not?

Most security issues that arise from usage of CGI's are not directly caused by CGI's but with the way certain standards are set by the HTTP protocol, and CGI's only allow access to these security holes. Specifications of the CGI interface enable reading files on the system, shell access, and accessing file structure on the hosts.

Naturally, malicious CGI's exist, and can be set up, but I will not disscuss them, instead I will focus on the damage that can be done via your CGI's on your own host, not on the user surfing your web.

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:


http://somehost.name/cgi-bin/query?%0a/bin/cat%20/etc/passwd

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

line:

http://localhost/cgi-bin/viewsrc.cgi?loc=../somefile

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: