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.