Hackers Beware
.pdfFrom 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-
“Hackers Beware “ New Riders Publishing |
150 |
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
m/"
style="TEXT-DECORATION: none" target=new_window><B>Pearson PTR</B></A>
<BR><A
href="http://anon.free.anonymizer.com/http://www.newriders.com
/write.php3"
style="TEXT-DECORATION: none"><B>Write for Us</B></A> </FONT>
<p>
</TD>
If an attacker really wants to hide his tracks, he could make them more difficult to detect. With JavaScript, it’s possible to modify the Address field so an attacker can write code that strips out his portion of the URL and hides the fact that URL redirecting is taking place. The one thing that is
“Hackers Beware “ New Riders Publishing |
151 |
hard to cover is the source. Because the source is what is actually loaded, if an attacker changes it, it can cause some problems and change what was loaded. I know of very few users who actually check the source, so this probably is not a big issue for an attacker.
As you can see, for an attacker to run this attack, he must be able to redirect all of the links. He can do this either by modifying the source code on the server or using a proxy that modifies the links as the web pages are being loaded.
Protection Against URL Rewriting
As we have stated, there are two easy ways to determine that URL redirecting is taking place. First, web browsers should be configured to always display the destination URL, and users should be trained to look at it. If they see two HTTP requests coupled, they have a pretty good idea that URL redirecting is taking place.
The second method, examining the source, is guaranteed to tell you if redirecting is taking place. Unfortunately, it is unreasonable to assume that users will check the source for every page they connect to. Hopefully, most attackers are not sophisticated enough to write JavaScript, which can modify the source field to hide the fact that redirecting is taking place. But even if they are and do, if the browser is set up to check with a user before running any code, a well-trained, educated user might detect this.
As you might notice, having very strong security is dependent on having users who are well educated and do the right thing. From a purely technical standpoint, you can have some level of protection, but to have really strong security, you must depend on your users.
Another way to protect against this attack is to make sure that the code for your web pages is properly protected not only on the web server but also in transit. If an attacker cannot redirect the URLs, he cannot launch this attack.
Tracking State
Another popular way attackers spoof the web is by attacking the e- commerce web sites and impersonating a user. By nature of how the web works, there is no concept of state or tracking a user over time. If a user connects to a web site and then connects to three other pages on the web site, there is nothing inherent in the HTTP protocol or HTML that allows the web server to know that the same person connected those three times.
For e-commerce, being able to track the state of a connection and what a user does over time is very important. If a web site wants to track a user
“Hackers Beware “ New Riders Publishing |
152 |
over time or identify the user, as in the case of online banking, a web application must take care of that.
There is no feature built into web servers or web browsers that tracks a user over time and allows her to perform multiple actions in sequence. Because web application developers are usually under very tight deadlines and usually are not security professionals, there is room for mistake. What works from a functionality standpoint does not necessarily work from a security standpoint.
As with normal authentication, users are usually authenticated at the beginning of the session only, and that authentication is valid as long as they stay active or logged in. Remember, after a user logs on, it is the responsibility of the application developers to track this information. In practice, there are three ways to track a user after he logs on to a Web site:
•Cookies
•URL session tracking
•Hidden form elements
Cookies
Cookies are a piece of information that the server passes to the browser and the browser stores for the server. Whenever a user connects to the server, the server can request the cookie from the browser, the browser passes it back to the server, and the server can track the user.
Cookies are fairly easy to use and very popular. However, cookies have gotten a lot of negative press. People compare them to wearing a bar code, because now you can be tracked in cyberspace by cookies. People also have claimed that cookies can be used to pass viruses and other malicious code, which is not true. Cookies are just text stored on a local machine and generated by a server.
There are two types of cookies: persistent and non-persistent. A persistent cookie is stored on the hard drive in a text file format, which is accessed by the browser. Because it is stored in a text file, an attacker that has local access can easily access the cookie. A non-persistent cookie is stored in memory and is a little harder to access, because it goes away after you reboot or turn off the machine.
To launch an attack against non-persistent cookies, an attacker has to access and edit memory or get the source code for a shareware browser and modify it to write non-persistent cookies to a file. Another easy way is to write Java code that intercepts the cookies as they are sent back and forth.
“Hackers Beware “ New Riders Publishing |
153 |
Also, sniffers are applications that can be used to pull non-persistent cookies off the wire as they are transmitted from source to destination. There is also a program called Achilles that allows you to edit http sessions and modify non-persistent cookies. The program is available at http://www.digizen-security.com.
For the remainder of our discussion on cookies, we will concentrate on persistent cookies. To modify the cookies, search your hard drive for a file called cookies.txt. The following is a copy of the cookies file for my Netscape browser, located in
C:\Program Files\Netscape\Users\default:
#Netscape HTTP Cookie File
#http://www.netscape.com/newsref/std/cookie_spec.html
#This is a generated file! Do not edit. www.webtrends.com FALSE / FALSE 125439375653685 WEBTRENDS J8ELWGNW56FGPMA
.netscape.com |
TRUE |
|
/ |
FALSE |
1293343364751 |
UIDC |
|
|
|
|
|
207.139.40.22:093418703649:143018323 |
12932102302393 |
||||
.miningco.com |
TRUE |
|
/ |
FALSE |
|
Tmog |
|
|
|
|
|
29523211252159102514m |
|
FALSE |
/ |
FALSE |
|
www.prosofttraining.com |
|
||||
12923232327238513 |
|
|
|
|
|
EGSOFT_ID |
227.153.90.22-52552323323904.2239250232926 |
||||
.imgis.com |
TRUE |
/ |
FALSE |
1075923454743428 |
|
JFEDEB2 |
|
|
|
|
|
28C51302DB2GF09E7FCF935F5A1653430SDF04DEHFDF
The values that are stored after each of the URLs is the state information for me. If an attacker wants to be Eric, all he has to do is copy this information to his cookie file.
Another effective method is to guess the cookie. An attacker can go to a site several times and get an idea of the values that site assigns for tracking users. If the attacker guesses and puts in a different value, he can become a different user. Numerous times, I have performed penetration tests against web sites, have randomly guessed cookie values, and instantly have taken the identity of someone else. An attacker can access account information, change an order, make an order, change the shipping address, or just cause chaos. (In all cases referenced in this book, I always have authorization before attempting any of these exploits.)
Protection Against Cookies
“Hackers Beware “ New Riders Publishing |
154 |
To protect against cookies, a company needs good physical security. An attacker cannot access a user’s cookie file if he cannot gain access to a machine. I recommend that systems be properly protected and users log off when they are not using their computers. One way to accomplish this is to use a password protected screen saver, so if a user walks away from his machine, another party cannot gain access.
In general, it is better to have non-persistent cookies, because a copy of the cookie file is not permanently present on the user’s hard drive. In some cases, where you need to track a user over a longer period of time and there is a good chance he will be turning off his computer, nonpersistent cookies do not work. Of course, users cannot decide what kinds of cookies they will receive from Web sites, but it is good to be aware of the difference.
To make guessing your ID difficult, make sure the values you use are as long and random as possible. Using a 100-character string containing letters and numbers for your cookie value ensures that there is no pattern and makes the value almost impossible to guess. For example, if the first time an attacker goes to your site he gets a value of 0000000888, and the next time he goes he gets a value of 0000000889, there’s a good chance that if he tries 0000000885 he will get a valid cookie. The attacker can use this to access information he normally shouldn’t have access to.
On most browsers, you can disable cookies or selectively decide which cookies to accept. Just keep in mind that if you do not accept cookies, some sites do not work. To disable cookies, set the Security Level for the Internet Zone to High. Figure 4.11 shows this for Internet Explorer.
Figure 4.11. How to disable cookies using Internet Explorer.
“Hackers Beware “ New Riders Publishing |
155 |
URL Session Tracking
Another common way of tracking session information is by placing it right in the URL. When you go to certain sites, you might notice that the URL looks something like the following:
http://www.fakecompany.com/ordering/id=982671666273882.6647382
The number at the end is your session ID. If an attacker can guess that ID, he can take your identity and take over your active session. As with cookies, dozens of times while checking the security of a web site for a client, I have connected to a site to get a feel for the patterns the company uses for session IDs. After connecting, I try to guess some IDs. Usually, I can find out the session ID of a user within five guesses and access and modify their information. In one case, I accessed the results of a very sensitive online medical exam. Only the individual who took the exam was supposed to see the results, but they were stored online for a month in case the individual wanted to go back and check the results.
With this type of attack, you need to remember that the user does not have to be online for the attacker to be successful. In many cases, the web application does not time out a user immediately and can sometimes wait a couple of hours until the session ID is no longer valid. During this time, an attacker can guess the session ID and become that user. The way a web application is configured dictates whether the attacker can guess a session ID and connect while the user is still online.
Protection Against URL Session Tracking
“Hackers Beware “ New Riders Publishing |
156 |
The best defense against URL session tracking is to use long and randomlike strings for the session ID. Also, the more characters you use, the harder the chance of guessing correctly. For example, a four-character session ID, containing only numbers, is easy to guess or figure out the pattern. On the other hand, a 75-character session ID with letters, numbers, and special characters is much harder to guess. Remember, because most of your security is based on the session ID, it is worth a little extra time and energy to make sure it is secure. To protect against this type of attack, the defensive measures have to be done on the Web server side. There is little that a user can do to prevent this type of attack.
Hidden Form Elements
The old saying “What you see is what you get” is not necessarily true when it comes to the web. The data or document that the server sends to your browser is interpreted by your browser and displayed to you. The next time you have a Web page up, select Source from the View menu, and you will see all of the code that is interpreted by your browser. In some cases, the browser ignores some text, called hidden text. The following is a portion of code taken from an online bookstore:
<HTML>
<HEAD>
<title>Somestore.com - Product Info for A Guide to Expert Systems
(Teknowledge Series in Knowledge Engineering)</title>
<BASE HREF="http://www1.somestore.com">
<!– START PAGE HEADER CODE –>
<meta name="robots" content="all, index, follow"></head> <body bgcolor="#FFFFFF" text="#000000" link="#003399" vlink="#666633"
alink="#CC3300" topmargin="6">
<table cellpadding=0 cellspacing=0 border=0 width=100%>
<!–Top Row : Logo and Tabs–><tr> …..
<INPUT TYPE=HIDDEN NAME=YWH VALUE="http://www1.somestore.com/catalogs/computing/subjects.a sp?VM=C&SubjectCode=
XES" >
<form action="http://www1.somestore.com/shop/quicksearch.cl" method="get">
<input type="hidden" name="SearchFunction" value="key"><input type="hidden"
“Hackers Beware “ New Riders Publishing |
157 |
name="vm" value="c">
<table border="0" cellpadding="2" cellspacing="0" bgcolor="#D6D3C4">
<tr>
<td align="center"><table border="0" cellpadding="4" cellspacing="0" bgcolor="#D6D3C4">
<tr>
You might notice that several places begin with <INPUT TYPE=HIDDEN NAME. This is information that the browser wants to keep but does not want displayed to the user. HTML is not true WYSIWYG (What You See Is What You Get); therefore, data can be hidden in the HTML page but not displayed to the end user by the web browser. This is another way web sites track users. They use a session ID, as in the other examples, but in this case, the session ID is hidden in the form. Again, an attacker can go in and modify this information so that he can act or spoof a different account and therefore have access to that information.
Protection Against Hidden Form Elements
The best way to protect against these types of attacks is to have hard-to- guess IDs that are as random as possible. These measures are the same protection I recommended for cookies and URL session tracking. In all of these cases, the session ID must be protected and difficult to guess. If an attacker can make logical guesses and have a high chance of getting a session ID, it doesn’t really matter how the session ID was transmitted to the user.
The only thing the user can do is make sure his computers are properly protected and only use web applications for sensitive information like banking, if the connecting Web site has the site properly designed and protected security-wise. It all comes down to how well the session IDs are protected and how difficult they are for someone to guess.
For example, for an online banking application, I recommend at least a 15-character session ID that is composed of lowercase letters, uppercase letters, numbers, and special characters that are randomized, so the chances of guessing the ID are slim. I also recommend using two session IDs. One session ID for viewing information should be good for a maximum of an hour and expire as soon as a user logs off the system or after five minutes of inactivity. A second session ID is used for updating information and is good for a maximum time of five minutes. Remember, this might seem complicated, but these are things that the computers do, not humans. What is the difference between a 10-character or 30character session ID? From the user’s point of view, it does not matter, so why not err on the cautious side and, if in doubt, make it longer.
“Hackers Beware “ New Riders Publishing |
158 |
Because an attacker only needs to successfully guess one session ID, the length of the key is also a factor of the number of users on the system. If I have a five-character session ID but only two users, the chance of an attacker guessing one valid ID is slim. On the other hand, if I have a fivecharacter session ID and 20,000 users, the chance of success is much greater, because there are a greater number of valid sessions IDs to guess.
General Web Spoofing Protection
The scary thing about Web spoofing is that it does not require a lot of expertise or tools. Basically, if you have access to a browser and text editor, which come with most any operating system, you can launch these attacks. However, there are some things that you can do to prevent against these types of attacks. The following are some high-level suggestions:
•Disable JavaScript, ActiveX, or any other scripting languages that execute locally or in your browser so that the attacker cannot hide the evidence of the attack.
With Java or ActiveX, an attacker can run a process in the background that does whatever he wants and it is transparent to the user. The only way the victim would know is if she examines the source code for every page she views, which we all know is not a practical solution.
If it is not possible to disable scripting languages, at least make sure the warning banners are enabled and that users are educated on what these messages mean.
Some other examples of malicious code that have been used to breach security are Visual Basic Scripting language and the Windows Scripting host (wscript.exe) and its DOS equivalent (cscript.exe).
•Make sure you validate your application and that you are properly tracking users. This is not easy to do because it requires a company that runs a web server to validate the source code and have an independent security assessment done of the site. This might seem like a lot of time and energy, but if the site is to process large amounts of money, it is worth every penny to make sure it is secure before it goes live. A company can be in a lot of trouble if it is held liable for compromising sensitive information.
•Make sure users cannot customize their browser to display important information. Also, make sure that the browser’s location line is always visible and checked.
“Hackers Beware “ New Riders Publishing |
159 |