Protect Your Site By Hacking It

I frequently see comments on various security forums from webmasters after a compromise wondering how their sites could possibly have been attacked. In discussions with some of the webmasters that have been affected with some of these issues, I have found that most are unaware of simple and free steps that can be taken to help protect a web site. This is purely preventative, but when it comes to web site security, prevention is the most important element.
DISCLAIMER: This information is for educational purposes only. Check with your hosting company before using ANY of the software I mention to ensure it is allowed under their policies. Any misuse of this information, and any damage resulting from your use of this information is solely your responsibility.
One of the simplest and most important things to do is make sure you are on the mailing list for every piece of third party software you use so you know about security patches as soon as they are released. It is important to keep the software on your site up to date.
The next thing to do is hack your server. There are a few tools that malicious users use to find ways of gaining access to a web server. By using these tools yourself, you can find many of the same problems before you are attacked. Nessus is the most commonly used tool for finding vulnerable software on the Internet. In fact, this program forms the basis of most commercial vulnerability scanners and is available for free. Nessus can be downloaded from http://www.nessus.org/ although you need to register (for free) to get the program and updates. You want to download these updates so that every time you use the scanner it looks for the most recently known vulnerabilities.
Finally, there is a range of attacks that are hand coded. In most cases, these attacks are done by editing the requests sent to your server. This can be accomplished in two ways. The easiest is to install a Firefox plug-in (if you use Firefox) called HackBar. This can be installed from the Firefox plug-in library or by searching Google. This software allows you to edit the requests you send to a web server to test how well the server and scripts validate incoming data, while bypassing any security features of the web browser and any JavaScript validation. The other method is to install a proxy program called Paros Proxy. This program enables you to change the data being sent between your browser and the remote server, as well as seeing the raw data. This tool is also useful for testing redirects. A few searches on the web for “cross site scripting,” “SQL injection” and “buffer overflow” should give you plenty of ideas of things to try. This is the best way to test scripts that you have created yourself to ensure that those scripts are as secure as possible.
One often overlooked element of web site security is the validation of input on web forms. Javascript is useless for validating input, as the previous paragraph shows two easy ways to get around it. Your scripts should follow a simple formula: trust nothing, validate everything.
Bear in mind, all of the technology I describe is intended to demonstrate possible problems. This will not fix any issues. However, you should be able to find where you are vulnerable and make the appropriate corrections. Obviously this is no replacement for a full security analysis, but this will give you a starting point. Also, note that these methods are less likely to find security issues in custom made scripts. For that, you should consult a security consultant or a programmer who has experience securing applications in whatever programming language you are using.

E-Mail Forgery

Definition

E-mail forgery is the alteration of the headers of an e-mail to circumvent spam filtering, gain the trust of the recipient, or commit a crime such as identity theft. This is an easy thing to accomplish, it is very effective, and for webmasters there is almost no defense against this.

Symptoms - End User

Because of the way e-mail is displayed in most e-mail applications, it is virtually impossible to determine if an e-mail is legitimate, or if the headers have been forged. There are a few mechanisms that can be used to verify the identity of the sender, but these methods are out of the reach of the general public. Most of this technology has to be implemented by the Internet Service Provider.

Symptoms - Company

If your e-mails address is being forged, usually the only indication is "bounce messages". These are server messages that are sent in response to a bad e-mail address. For example, you may get a message saying that an e-mail address is invalid, but you have never sent an e-mail to that address.

How to Forge E-Mail Headers

There are a few different ways someone might forge the e-mail headers. The easiest, and frighteningly, a very effective method, is to simply change the reply-to address in your E-mail client before sending the message. Note that it is easy for an investigator to track these e-mails back to the sender.
The second method is to find an e-mail server on the web, establish a telnet connection to the mail server using forged credentials, and send the e-mail. This hides your actual e-mail address and makes it harder to determine your IP address. This is one of the more common methods, as spammers will use this technique to bypass spam filters.
The third method is to compromise a web site that sends e-mail, such that you can feed the web site a list of e-mail addresses, and let the server do the work. This very effectively hides your identity, and the messages from the compromised server will contain the headers associated with the company whose site was attacked. Because these e-mails are coming from the company web server, any authentication method that the recipient uses will allow the messages to pass through.

Defense

The first thing to do is ensure your server is as secure as possible. Make sure you are using strong input validation on all scripts on your web site, and make sure your e-mail server does not allow anonymous users to send e-mail. Also, make sure you log all access to scripts on your site that send e-mail, and log all traffic to your mail server so if a compromise does occur, you can track down the offender.

Securing a Server

The Problem

Simply put, the Internet is a dangerous place, and you (presumably) have a web server. Web servers, by default, are relatively insecure, presenting potential attackers with a variety of attack vectors (an "attack vector" is a way to attack a server or application). Fortunately, depending on your needs, it is usually easy to properly secure your server. For this example, we will be assuming you are using a Linux based server, and you are responsible for making sure that the server is as secure as possible.

The Attack

To understand how to secure your server, you have to have some understanding of how someone would perform the attack. This description is going to be based on someone who has located and targeted your server specifically, although most of what I talk about would also apply to a script kiddie doing general searches who happens to find your server.
The first step in attacking a server is to gather intelligence. The more you know about a server, the better able you are to find it's weaknesses and exploit them. The first step is to scan the ports on the server. Every application that allows external software to connect to it is called a service, and every service listens on a port for incoming connections. In this way, the operating system on the server can route incoming connections to the correct service/application. For example, if you have an Apache web server installed and listening for connections, it typically binds to port 80. When a browser requests a page from the server, the request goes to port 80.
A port scanner requests data from every port (or from selected ports) on the server. Based on the responses, an attacker can determine exactly what ports are listening for connections, and thus what services are installed on the server.
Once the services running on the server have been identified, the attacker then exploits known weaknesses in those services. Every service should be secured on it's own, and individual services are outside the scope of this article, but some important services are Telnet, FTP and HTTP. Your server will, under most configurations, allow connections to these ports, whether such access is needed or not, trusting the application's own security.

The Defense

The first step in protecting your server is with the firewall. A properly configured firewall will not allow incoming requests on any port that is not absolutely required. For example, a server being used to serve web sites typically only needs a few ports to be available to the public (80 and 443 for the web server, and 21 for FTP). Other ports may be required for administrative access, such as port 20 or 22 for remote command line functionality, or port 10000 for access to a web based control panel. The firewall should only allow traffic to these ports from IP addresses that are known to be trustworthy.
Next, if possible, an intrusion detection system should be installed. These applications detect suspicious behavior and block it at the firewall level. Hardware IDS devices are best, as they block the traffic before it ever reaches the server, but if that is not possible, software IDS systems can be very effective as well. The reporting functions can be invaluable if the server is ever successfully attacked, and most possible attacks will be thwarted before they ever threaten the security of the server.

Secure Redirects

Recently, SANS (a security certification organization) posted an article related to the exploit of the redirect system on Google. The exploit was used to hide URLs in spam e-mails. The article had a lot of detail on the attack, but didn't give much information about how to defend against this type of attack. Since redirect scripts are fairly common as they allow webmasters to track traffic on outbound links, I wanted to post some defensive information.

The Problem

You have paid advertising, or other types of outbound links on your web site, and to track the outgoing traffic you have installed a redirect page. The redirect page invisibly redirects users to the final destination after logging information about the redirect.

The Exploit

To exploit a redirect, you simply need to have a URL that you need to get past a filter, and a redirect that meets the requirements of the filter. For example, lets say you want to post a link to your web site in a forum that does not allow links to outside web sites. The forum does, however, allow internal links, such as those to other posts on the forum.
The first step is to find a redirector on the domain. So if you are posting on blog.com, you would browse through blog.com, looking at the various outgoing links until you find one that goes to a url like blog.com/redirect.php?url=www.somesite.com. This is the redirector. To exploit the redirect, you would replace the ad URL with your own URL - ie blog.com/redirect.php?url=myurl.com.

The Defense

There are a few defenses, but most of them have drawbacks. For example, you could set up the redirect script to only allow the redirect if the user came from another page on the current site. Unfortunately, many anti-spyware programs hide the referring page and would cause legitimate traffic from following the link.
Another option would be to use cookies. However, the same software may disable tracking cookies.
Possibly the most effective method would be to use a code based on the user's IP address. If you are using your redirects to track ads, and the ad code is dynamically generated you could add an extra parameter that contains the sum of the four segments of the user's IP address as a check. If the check is not there, or if it fails, the user would be taken to an error message instead of being redirected. An attacker creating a static link would be unable to create a working exploit because the URL changes for every visitor.