CGI Vulnerabilities

Everybody and their mom uses cgi-bin’s in some way or another on their web pages, or on their web server, aware or not of that fact. Today’s not so hot topic is cgi-bin vulnerabilites. In the following couple of infite text lines below, I’ll explain the cgi-bin concept, and some little mischevious naughty things you can accomplish misusing it. Notice that I’m not encouraging any sort of malvolent activites, nor will take any reponsibility for your actions. This article is written for educational purposes only. Let’s pretend that we don’t know anything about CGI’s, so…

The interface in-your-face

CGI stands for Common Gateway Interface, which is a standard for a gateway, or interface, between clients and web servers. It allows interaction between them, transparent and smooth. Web pages per se are static, plain HTML, sometimes rather messy, but readable text files. Now, CGI’s are scripts, or small programs, which allow you to make your web pages dynamic, and add various nifty things to them. A CGI program/script can be written in any language that allows it to be executed on the system, such as: C/C++, Fortran, PERL, TCL, Any Unix shell, Visual Basic, AppleScript… It just depends what you have available on your system. Usually, CGI’s are located in the /cgi-bin folder of your web server, and if you have CGI’s which are not only shell scripts, you also might have a /cgi-src folder. Of course, these may vary, so please don’t think it is carved in the stone just because I said so…

CGI’s are emmbeded into HTML pages via a simple link tag, ie. a CGI script incorporated into your page might look something like this:

picknose.sh

where picknose.sh is just a simple bash script, located in the /cgi-bin folder. What it does, well, that’s a different story, and completly irrelevant to our little debate. 🙂

For what will I use CGI’s one might wonder, and to that question the answer is fairly simple, but to make it even more simplified, I will elaborate it on an example. Imagine you have some sort of a database on your web, and you need to make it searchable to the user surfing the web. The best way to do this is via CGI scripts. You need a way to interact and transmit information between your host, and the user’s web browser and that’s what the common gateway interface or CGI does. It serves as a gateway between the user and your web. It (CGI script) will be executed by the web daemon to transmit query to the database and send results back to the user, via the same daemon. Kinda of a third party involvment. This is the simplest example of how to use CGI’s. Implementation is easy, and the possibilites are limited only by your immagination. Make sure your CGI’s are as simple as possible and that they do not take long time to execute. You can read more about the CGI concept and other CGI stuff here.

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:

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:

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 whisker.pl -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 whisker.pl 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.

By using a cgi scanner you can safely find out by yourself for any insecure CGI’s on your system. And, surely you want to do that, you don’t want to leave anybody any options for manipulating with your system. You can use any other CGI scanner, it should work just fine. Most of them have plugins of some kind to keep them up-to-date with vulnerabilities.

And thus cameth the conclusion

CGI vulnerabilities exist, and new ones are being found on a daily basis. And, of course, they will be exploited for this or that purpose. Unfortunately, if you have to use them, you can only hope that a patch exists or will be soon put out. Alternative, if you’re into programming, you can try to fix them yourself.

So, if you use CGI’s, use them wisely. Check them out, constantly as you try new ones. A good thing would be to regularly check sites like cgisecurity and Help Net Security for new CGI vulnerabilites, as they appear on a daily basis. It is of vital importance to keep an eye on new vulnerabilities concerning any software you run on your web. It will help you prevent any malicious activities against your site. Apply patches that become available sooner or later for the same issues. Applying patches reduces the risk level to minimum. Consider running utilites such as above mentioned suexec and CGIWrap on your web.

Hopefully, this article brought you in speed with the term cgi-bin vulnerabilities. Of course, much more can be said here, but for starters and for getting acguinted, this should do just fine. If you’d like to find out more, a lot of good information and links can be found at the sites mentioned in throught the article.

Last but not least, I’d like to thank Zenomorph from cgisecurity for his help and suggestions. Believe it or not, this concludes today’s easy reading material!