|
|
CGI, Perl, Scripts, etc. 07-1. What is CGI? 07-2. Are there default vulnerabilities? 07-3. How do I spot code with holes? 07-4. Why are buffers so important?
07-1. What is CGI?
CGI stands for Common Gateway Interface. It is a way for users to submit requests and have the server perform some function, typically a function that is native to the operating system, to either send a more "dynamic" response to the user, or to gather information about the user. For example, the user fills out a survey form and mails it in, or requests information on a part number and the server looks up the price from a database before sending the user the HTML page.
07-2. Are there default vulnerabilities?
Yes and no. There are "default" vulnerabilities that exist in several example files, as mentioned in Section 02, but there aren't any real default vulnerabilities for the most part. What you have are default bad programming habits that can be taken advantage of.
The bad habits usually involve not properly parsing user-supplied information. This is why some of the stuff in Section 02 works, I've just stated a few examples there. You could get REAL psychotic about this stuff. Besides just grabbing the passwd file, you could try:
If the target site for some stupid reason has put PERL.EXE in say, /cgi-bin/ (I've seen this on some NT servers before), you should buy that book on Perl ;-). You can send entire Perl scripts for PERL.EXE to execute including all of the above mentioned items.
One vulnerability that I haven't mentioned is looking for files in /cgi-bin/ with a ~ on the end. If the administrator was editing change-your-password.pl with a package like emacs in the /cgi-bin/, there might be a change-your-password.pl~ backup file that the editor has created. You may be able to find holes in this code if you can read it, instead of simply guessing.
07-3. How do I spot code with holes?
If you can get ahold of actual Perl code, you can check to see if things are being parsed. Let's say you grab finger.pl~ from the /cgi-bin/ directory the way stated at the end of 07-2. Let's say you see the following line (example is for a Unix server):
#!/usr/local/bin/perl <--- The first line says we're using Perl, duh . . . print `finger $account_to_finger`;
Okay so we can finger an account. The Web page allows you to type in a user name and finger them to see if they are online. In that example supplying nobody;echo "toor::0:0::/:/bin/sh">>/etc/passwd as a user name might yield some interesting results, especially if the httpd is running under root. Why does this work? Because in Perl the command in ` ` is run from a spawned shell.
Now what does code look like that is "safe"? Well, first look for Perl running tainted. This means that Perl will assume all user input is tainted and could spread to other parts of the system. Taint checks are similiar to these examples:
#!/usr/local/bin/perl -T <--- Perl v5 invoking taint checks
.
.
.
# untaint the address
$user_to_finger=~/([\w-.]+\@[\w-.]+)/;
$untainted_user = $1;
# path hardcoded
$ENV('path') = '/usr/bin;/usr/local/bin:/bin';
# still paranoid let's hardcode the path to finger
system("/usr/local/bin/finger $untainted_user");
Obviously someone is taking more precautions here.
How about more examples of bad code? Well, here's a common example, a simple text file "database" that can be grepped against to return data:
system("grep $variable database_file"); or
sprintf(tmp, "grep %s database_file", variable); system(tmp);
Now what happens if you supply "0:0 /etc/passwd;id" as the variable? You'd get root or root equivalent lines from /etc/passwd, and you'd see which id the httpd process is running under. Of course if it looks like this, a shell is never invoked (note the -e in quotes):
system("grep", "-e", $variable, "database_file");
If you see this, your failed intrusion attempt will simply end up in a log file somewhere.
07-4. Why are buffers so important?
Let's look at some code first discussed in Section 02. Note the following:
/* code snippet in C, although you can do the same type thing in Perl */ sprintf(buffer, "/usr/lib/sendmail -t %s < %s", foo_address, input_file); system(buffer);
Now let's assume that somewhere at the start of the code is this statement:
char buffer[60];
What will happen if you overflow that buffer? I guess it would depend on the operating system and whether you were running your httpd daemon as root or nobody.
Well, Mr. Admin, you say that no one looks at your source code except existing personnel? Okay, that's fair, and for the sake of argument we will assume that those contractors you hired and you drove like dogs to finish their code are uncorruptable angels ;-), so what about vendor code? What about sample code? What about freeware?
Serious intruders will review the code of common shareware and freeware utilties and look for these types of details. Knowing the OS, it's revision, and that a piece of code whose buffer could be overrun an intruder can simply duplicate the environment as best as possible and then start writing their own code until a crack is found.