As the Bob Dole campaign realized in 1996, web spoofing can be a very easy technique to accomplish. During the campaign, an attacker
registered the site dole96.org, which many guessed was a pro-Dole web site. In reality, it was a site that shined a negative light on the whole campaign. When people surf the web, most forget that many sites are not
what they claim to be. When some users want to go to a web site, they use a search engine to try and find the site. In other cases, users guess the Web address by using the name of the company they are looking for— for example, if the name of the company is Eric, they try eric.com or eric.org. Then, when they go to that site and see the logo for the Eric Company, users assume that they are at the right place.
For his campaign, George W. Bush registered several domain names, but he didn’t cover all the bases. Interestingly enough, if you go to
bushsucks.com, it automatically forwards you to his campaign web site. However, if you go to votebush.com, you get a site that has several
domain names for sale, some of which could have been used against Bush (see Figure 4.7). It would have been trivial for someone to acquire or buy votebush.com and put up a negative site about his campaign.
Figure 4.7. List of possible domains for sale and associated price.
Recently, a similar type of attack was launched against customers of an online bank. Attackers registered an URL similar to the bank’s URL, but without the period between the www and the bank’s name. The real URL was www.banksname.com and the spoofed URL was wwwbanksname.com (with the period missing). An email was then sent to the bank’s customers saying To connect to the new online Web site, click on the link below, which was wwwbanksname.com. At quick glance, it looks correct,
so several people went to this site and entered their account information. The attackers gathered the information and then went to the real site and had access to several accounts.
Now let’s take a look at several web spoofing techniques, starting with some very basic attacks.
Basic Web Spoofing
Most people fail to realize that there are no requirements for registering a domain name—basically it’s first come, first served. Before the web
became popular, many people registered a name and later tried to sell it back to the company for big dollars. I have worked with several
companies that came late to the Internet game, and they had to pay big dollars to get the right to use their name. There have been a lot of legal proceedings around this because some consider it extortion, but it will be interesting to see how this continues to play out.
Let’s look at another alternative. Suppose Eric is a software company that is selling several products and someone owns eric.com. If he is nice, he either sells it back to the company or includes a link on the site that says If you are looking for Eric Software Company, click here, which then takes users to the real site, ericcompany.com.
But what if that someone is an attacker who wants to make money off of your name? He could set up a Web site for eric.com and make it look like the Eric company’s web site. This way, when people go to that URL, they think they have entered the real site and try to order software.
Here’s how it works: A user goes through this spoofed site and clicks on items she wants to order. She then goes to checkout to buy the items, and the site prompts her for her shipping and credit card information. At this point, the site records the credit card information, gives the user a cookie, and puts up the message This site is currently
experiencing problems. Please try back later. When the user tries back later, the site receives the cookie, knows that this is a user that has already been spoofed, and, because her credit card data has already been gathered, it automatically forwards the user to the real site at
ericcompany.com. Because so many people do not look at the URL line or hide it on their browser, they probably would not even notice that the URL has changed.
Note
A cookie is a piece of information that the browser passes to the client to help track state information. The client then stores this information on the local hard drive. The next time the user goes back to that web server, it
gives the cookie back to the server and the server processes it so that it can track that user over time.
Protection Against Basic Web Spoofing
The best way to protect against basic web spoofing is for sites to use
server-side certificates. Server-side certificates are much harder to spoof and provide a higher level of protection, ensuring that the site you are connecting to really belongs to the company you are expecting. A server side certificate is a validated certificate that the server presents to a client to prove they are who they say they are. It can be thought of as an ID card for a server.
The biggest problem is that users do not understand the inherent dangers of using the web. They don’t understand certificates, so even if a site does not give a certificate, they still trust it. For those sites that give
certificates, users frequently just click OK without ever looking at the certificates. Users need to take the time to verify that the certificates belong to the companies they want to connect to. Another way you should educate your users is by configuring web browsers to always display the URL. This way, you can better help users understand where they are going.
Man-in-the-Middle Attacks
We have covered a very basic and effective method of web spoofing, but now we will look at a more complex method. Man-in-the-middle attacks
can be used for all different types of exploits, not just web spoofing. We cover them in this context because they‘re fairly easy to do and extremely effective. With a man-in-the-middle attack, the attacker has to position himself so that all traffic coming and going to the victim goes through him. For an ordinary user, this might be hard, but for an attacker, he can compromise the external router for your company (see Figure 4.8).
All traffic coming in and going out of your organization has to pass through this router. If an attacker can compromise it, he can launch a passive attack at a minimum. He cannot read information that is encrypted with SSL, so he might not be able to get credit card information—but he can still get sensitive information.
Remember that passive attacks can provide a lot more information than you might realize. When I worked internal security at one company, it had a policy of monitoring all traffic that was coming in and leaving the
organization. You’d be amazed at what we were able to observe. We caught two people committing corporate espionage, one person actually committing a crime, and several people connecting to sites that they should not have been connecting to.
In an active attack, an attacker not only can intercept your traffic, but he also can modify it. Let’s say that you connect to an e-commerce site and you put in the online ordering form that you want to order five widgets at $1000 each. What if an attacker adds two zeroes to that five without you knowing about it and you order 500 widgets? You can expect a lot of potential problems.
Also, consider this scenario: You are using Web mail to send mail to a prospective client about an upcoming meeting and you agree to meet the client at 2:00 p.m. on Wednesday. Let’s say that a competitor intercepts and modifies this traffic, and he changes the date and time to 4:00 p.m. on Tuesday. Now, you think the meeting is on Wednesday and your client thinks it is on Tuesday. When you do not show up at the meeting, you can insist that the meeting was on Wednesday and probably lose the client because you look incompetent. (Remember, the client is always right.) Or, you can figure out what happened and admit that you had a major
security breach. Either way, from a business standpoint, your chances of winning that client’s business are slim.
Let’s make this a little more interesting. If instead of just intercepting the traffic, as in the preceding example, the attacker actually inserts himself in the middle of your communication. With this attack, the attacker plays the role of a proxy, passing all information between the victim and the recipient of the communication. A proxy is a system that sits between two computers that are communicating and, in most cases, opens a separate connection between each system. For example, if computer A and B were communicating through a proxy, computer A would open up a connection to the proxy and the proxy would open a second connection to computer B.
Even if you encrypt the traffic with SSL, the attacker can still read it
because the traffic is being encrypted between the victim and the attacker and the attacker and the end recipient, so there are actually two
encrypted streams as opposed to one. From a victim’s standpoint, he has no way of knowing that this is happening. Not only can all of his data be read, but it can be modified. Therefore, it is very important that the perimeter of your organization be properly secured.
A similar type of attack is a replay attack. This is where an attacker records all the traffic between a user and a server, including
authentication information and requests (Bob thinks he is talking directly with the server) for data. At a later point in time, the attacker sends the same data or replays it back to the server to impersonate that user and gain access.
The man-in-the-middle attack is effective but fairly complex. Later, we will look at another technique that is as effective, but simpler to perform.
Protection Against Man-in-the-Middle Attacks
For the first type of man-in-the-middle attack, where someone is just reading your traffic, encryption definitely helps. Because the attacker does not know your encryption key, he cannot read or modify any of the data. In the case of the man-in-the-middle attack where the attacker acts like a proxy, encryption does not help because you have one connection to the attacker and the attacker has a separate connection to the recipient. Therefore, he can un-encrypt the traffic, read or modify it, and then re- encrypt it for the recipient. In this case, it is important that you have strong perimeter security, because in most cases, for an attacker to launch this type of attack, he either has compromised your perimeter or the company’s perimeter you are communicating with. If you do your part and secure your perimeter, hopefully the person you are connecting to has strong security. Remember that if your company has strong security and if the person you are communicating with has weak security, this attack can still be successful because an attacker will just compromise the other company’s router. An attacker will compromise the weakest link in the chain. This can be frustrating because even if your company has top- notch security, it can still be compromised if everyone else you are communicating with does not.
URL Rewriting
With URL rewriting, an attacker inserts himself in the flow of
communication, as in the man-in-the-middle attack. The only difference is, with the man-in-the-middle attack, the attacker has to physically be able to intercept the traffic as it goes over the Internet. If you are on the same local network or can compromise a router, this is fairly easy; but in other cases, it can be very difficult to perform. In those cases, the
Usually, a web page has links to several other sites or several other
pages. (If a web page only has static text with no links to anything else, it is not useful to the attacker.) With URL rewriting, the attacker has to rewrite all of the URLs (or links) on a web page. Instead of pointing to the real page, the rewritten links point or redirect the user to the attacker’s machine. Through a web browser, this looks no different to the user. The only way the user can tell is if he looks at the source or at the bottom of the browser where it states where the link goes. Looking at the HTML, a normal link might look like the following:
<BR><A href=" http:://www.newriders.com/write.php3" style="TEXT-DECORATION:
none"><B>Write for Us</B></A>
The attacker changes this link to the following: <BR><A
href="http://attackermachine.com/http://www.newriders.com/writ e.php3"
style="TEXT-DECORATION: none"><B>Write for Us</B></A>
The attacker makes this change for all links on that page. As you can see, all the attacker has to do is insert his URL before the original URL. When a user clicks on these links, she goes to the attacker’s site, which then
redirects her to the real site. From a user’s standpoint, everything looks fine, but an attacker is placed in the middle of all communication and can intercept or modify any information.
To illustrate how URL redirecting works, I will use a site on the Internet that performs this for users. The site is www.anonymizer.com and is used to surf sites anonymously so that the end site does not know who you are. With this site, a user goes to the site first and puts in the URL he wants to surf to. After that, all communication goes through the Anonymizer to shield the privacy of the user. Figure 4.9 is the main page for the Anonymizer.
Now when the user goes to www.newriders.com, the site comes up just as if the user directly connected to it. From an attacker’s standpoint, he could do the same thing and it would seem transparent to the user. Figure 4.10
shows the New Riders’ web site going through the Anonymizer.
Figure 4.10. How the URL changes when a user connects to a site via the Anonymizer.
From a detection perspective, there are two important things to note. First, if you look closely at the URL, it looks suspicious:
http://anon.free.anonymizer.com/http://www.newriders.com The URL of the Anonymizer is followed by the URL of the real site. If an attacker is using URL redirecting, you can see it. As long as users keep the Address field visible and look at it, they can probably detect this type of attack.
Another way to detect this is to look at the source. From any browser, you can choose View Source (or View Page Source in Netscape) and look at the source code. As you can see in the following source code, all links have been preceded with the Anonymizer’s URL:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML>
<HEAD>
<TITLE>Welcome to New Riders [Anonymized-spica]</TITLE> <META content="text/html; charset=windows-1252" http-- equiv=Content-Type>
</HEAD>
<BODY aLink=#003366 bgColor=#ffffff leftMargin=0 link=#003399 text=#000000
topMargin=0 vLink=#006699><!– Begin Anonymizer Control Bar –> <CENTER><FORM METHOD="POST"
ACTION="http://util.anonymizer.com/cgi- bin/freeaction.cgi" TARGET="_top"> <TABLE BGCOLOR="#000099"><TR><TD>
<B><FONT COLOR="#FFFFFF">Please visit the Anonymizer's Sponsors:</FONT></B><BR>
<TD
background=http://anon.free.anonymizer.com/http://www.newrider s.com/images/fade.gi
f width=600>
<IMG alt="" border=0 height=20
src="http://invis.free.anonymizer.com/http://www.newriders.com /images/dot_c.gif" width=1> </TD> ….. <p>
<img alt="welcome to newriders.com"
src="http://invis.free.anonymizer.com/http://www.newriders.com /images/nrp-
logo.gif"> <p>
<img alt="welcome to newriders.com"
src="http://invis.free.anonymizer.com/http://www.newriders.com /images/road-
150.jpg">
<TABLE border=0 cellpadding="4"> <TBODY> <TR> <TD vAlign=top> <FORM action="http://anon.free.anonymizer.com/http://www.newriders.c om/cfm/prod_search.c fm" method=post> href="http://anon.free.anonymizer.com/http://www.newriders.com /calendar.php3" style="TEXT-DECORATION: none"><B>Calendar</B></A> <BR><A href="http://anon.free.anonymizer.com/http://www.newriders.com /promotions.php3"
style="TEXT-DECORATION: none"><B>Current Promotions</B></A> <BR><A href="http://anon.free.anonymizer.com/http://www.newriders.com /faq.php3" style="TEXT-DECORATION: none"><B>FAQ</B></A> <BR><A href="http://anon.free.anonymizer.com/http://www.newriders.com /international.php3" style="TEXT-DECORATION: none"><B>International</B></A> <BR><A href="http://anon.free.anonymizer.com/http://www.pearsonptr.co