|
Paul O’Brien
April 25, 2001
Web Spoofing – What are you looking at?
The World Wide Web has provided a new and innovative method for companies to conduct business on a global scale. As this type of business continues to grow, companies are required to obtain greater amounts of information from the public, and are pushed to increase the value-added services they provide, such as online transactions. This increased interaction has resulted in vast amounts of information being transferred across the Internet and as a consequence has escalated the concern over the confidentiality and security of this information as it travels across the various networks.
One of the catalysts for this security concern has been the introduction of spoofing attacks, and in particular Web spoofing attacks. This paper will examine the concept of Web spoofing and discuss the various implications it has for the security of information across the Internet. The paper will further discuss possible countermeasures and prevention techniques that could be used to mitigate the potential damage such an attack may cause.
Spoofing can be defined as, "A technique used to gain unauthorised access to computers or information, whereby an attacker communicates with a user under the false pretence that they are a trusted host" (Felten et.al 1997).
In other words, an attacker may take on the identity of someone or something else in order to fool the user into believing they are a trusted source that can be safely communicated with. The concept of spoofing was discovered through a vulnerability in the TCP/IP stack that was first identified by Steven Bellovin in his 1989 paper ""Security Problems in the TCP/IP Protocol Suite". This discovery introduced the IP spoofing attack, in which an attacker sends messages to a computer with an IP address indicating the message is coming from a trusted host port, when in fact the message has come from the attacker’s machine.
In addition to IP spoofing, other attacks have followed such as DNS spoofing, frame spoofing, form spoofing and Web Spoofing. All of these attacks share the common goal of gaining unauthorised access by misleading the user and consequently, have highlighted the need to provide adequate security over all network communications.
As more people continue to use the Web to perform a myriad of functions Web spoofing has become an attractive attack for hackers to glean valuable information. The relative ease at which this attack can be performed has further increased the attractiveness of such an attack on unsuspecting users.
Felten et.al. (1997) describe Web spoofing as, an attack that allows the attacker to create a "shadow copy" of the entire World Wide Web, from which access is then funnelled through the attacker’s machine, allowing the attacker to monitor all of the victim’s activities as well as alter the information that is being transferred. Spoofing is reported to work on major browsers, Netscape Navigator and Microsoft Internet Explorer, and cannot be prevented through the use of a secure connection.
The implications of Web spoofing are varied and given the increase in E-Commerce activities present on the Web today, are cause for much concern. Such an attack provides a method for attackers to get personal information on users such as addresses, phone numbers, credit card numbers, banking details and passwords. In addition to this, the attack could be used to provide users with false or misleading information causing a type of "Denial of Service" attack by denying users access to the Web site information they are after. Information such as this, could also be used today for corporate espionage, allowing one company to gain valuable information or prevent valuable information from being communicated.
Once this information has been obtained through Web spoofing there are further implications that this information can then be used to perform more sinister attacks on the individual hosts or networks. For example, if an attacker has gleaned information about a user such as their password, user name, location and perhaps their company name, the attacker probably has enough information to attempt further attacks to gain unauthorised access into that companies network and valuable resources. So whilst a Web spoofing attack may not appear to cause serious damage, it is the collection of this confidential information and its ability to be used as a stepping-stone for additional attacks that make it such a security risk.
Web Spoofing also exploits a flaw in the way that browsers employ 'digital certificates' to secure web sessions. By exploiting this flaw the surveillance and tampering techniques mentioned can be carried out over "Secure" connections, usually via Secure Sockets Layer (SSL) to the server, rendering such a security countermeasure useless.
This exploit is due to SSL’s reliance on verifying the server portion of the Universal Resource Locator (URL), and not the hyperlink that the user is clicking on (which could display anything at all). Therefore, if an attacker sets up the URL to point to the "Attacker" server, the user will be unknowingly sent there. The browser will tell the victim they have a "secure connection" and will show solid keys, however, the secure connection is with the wrong server, namely the "Attackers".
Web Spoofing involves an attacker setting up a malicious web server on the Internet between unsuspecting users and the rest of the Web. This attack is considered a "man in the middle" attack, as the attacker is sitting between the victim and Web. The attack is initiated when the victim visits a malicious Web page, or receives a malicious e-mail message. The following are the steps that occur during an attack:
1. The victim requests a URL from their browser.
2. The attacker gets the real page requested from the World Wide Web.
3. The real server provides the page to the attacker’s server.
4. The attacker then rewrites the page.
5. The attacker’s server then provides the rewritten version to the victim
Before the above steps can take place the attacker must first re-write the URL’s belonging to the targeted Web Site, so that the URL’s now point to the attacker’s Web server.
For example, if the attacker’s server resides on www.attacker.com the attacker re-writes the URL’s by adding www.attacker.com to the front of the real URL, so it now becomes http://www.attacker.com/http://www.targetsite.com. This technique causes the victim to be routed through the attacker’s server, whilst the remainder of the URL tells the attacker’s server where on the Web to get the real document.
Therefore, the attacker's server fetches the real document needed to satisfy the request of the victim, the attacker then rewrites all of the URLs in the document using the method previously mentioned. The attacker's server then provides the rewritten page to the victim's browser.
Since all of the URLs in the rewritten page now point to www.attacker.com, if the victim follows a link on the new page, the page will again be fetched through the attacker's server. The victim remains trapped in the attacker's false Web, and can follow links forever without leaving it.
The method attackers use to re-route victims to their own Web server is made even easier by a design flaw in the location bar of most Internet browsers. Bogen et.al. (1999) suggest that, due to this design flaw, if a URL does not fit into the location box the browser may display the right part of the URL only. For example, if you navigate to a site like http://www.attacker.com/ http://www.targetsite.com… The address bar may only display http//www.targetsite.com... thus assisting attackers in their attempt to fool the victim into thinking they are visiting the correct site. This design flaw can however, be countered by simply dragging and dropping the address bar to the right side of the standard buttons bar.
Attackers also make use of frame spoofing to assist them in attracting would-be victims into their false Web. Festa, P. (1999) suggests, that a vulnerability in Web browsing software allows manipulation of frames across domains, ultimately allowing one Web site insert its own frames into a third-party site in the window of a surfer who visits both sites.
Netscape confirmed this vulnerability suggesting that, a malicious attacker could exploit this vulnerability to make the content of the attacker's own creation appear as if it were provided by another web site. In doing so, the attacker could mislead a victim by leading the user to believe they were visiting a trusted web site.
Using the same method the attacker could also make potentially embarrassing information appear on a web site. In doing so, however, the attacker is not actually placing the offending data on the targeted site's server, rather the attacker makes it appear as if the data is coming from the targeted site.
Although a frame-spoofing attack does not require JavaScript to be active to achieve its effects, successful exploitation of this vulnerability does require JavaScript. If JavaScript is not active, a window within the targeted site must already be open on the user's machine when the attacker entices the user to click the hyperlink in the attacking email or on the attacker's web site.
Whilst frame spoofing has been a problem in the past, both Microsoft and Netscape have released patches that address the multi-domain manipulation thus mitigating the effect of such an attack.
Before any of these attacks can truly take place the attacker must first lure the victim to their site. This can be achieved by providing a false link onto a commonly used or popular page. In order to do this, the attacker must first compromise the server that serves that particular page. Once this is achieved the attacker can then modify the pages, adding links to their own server.
Victims may also be lured to the false Web through Web-enabled e-mail. The attacker could e-mail the victim a pointer, which directly points to the attacker’s Web, or the attacker may even e-mail the victim the entire corrupted page.
One of the last methods available to the attacker is to trick or convince a Web search engine into indexing part of the false Web, which would then provide a link for potential victims to click on, resulting in them being instantly trapped within the attacker’s Web.
Whilst the Web spoofing attack works relatively well, there are a number of ways victims may be able to identify that they are in fact being spoofed. However, Felten et.al. (1997) suggest attackers can easily eliminate these clues, allowing the attacker to cover their tracks and complete the illusion to the victim. The following methods describe the ways these clues can be identified and the ways in which an attacker may eliminate them.
The browser’s status line is the first possible clue a victim could use to indicate that they are being spoofed. Typically, the status line displays various messages regarding the status of pending web transfers. When the mouse is held over a Web page hyperlink, the status line will display the URL the link points to. Therefore, if the attacker does not disguise this, the victim may notice that the address displayed in the status line does not in fact correspond to the address the victim is expecting and is instead pointing to www.attacker.com
However, this scenario places a large reliance on the fact that the victim is going to check the status line, which unfortunately is unlikely in many cases. Secondly, most attackers will eliminate this clue by adding a JavaScript applet to every written page. As Java applets can write to the status line, and it is possible to bind JavaScript actions to the relevant events, the attacker can ensure that the status line always reflects what would have been displayed in the real page.
The victim may also use the location line within the browser to view where the web page is coming from. However, as previously mentioned, depending on the size of the address, the location line may only show the end of the address, which could appear to be the correct destination to the victim. In addition to this, JavaScript can again be used to replace the real location line with a fake one. The fake location line can be written to always show the URL the victim is expecting to see, as well as, accept keyboard input from the user, allowing them to input URLs manually. These manually typed URLs are then re-written by the JavaScript applet to re-direct the victim to the attacker server.
Viewing the Web page documents source code is yet another method victims may utilise in order to identify that their page has been spoofed. Viewing the source code of the document will display the URL’s that are contained within the site and will demonstrate to the victim that the URLs are in fact pointing to the attacker’s web server not the legitimate server they are requiring. Whilst this identification process is foolproof, many users are either unaware this option is available or are unable to determine what they are actually looking for within the pages of code. Therefore as effective as it is, it does not pose a great threat to the success of the attacker.
Likewise, a victim may also view the correct source of the document by either going to the "Properties" menu item in "Internet Explorer" or the "View document information" menu item in "Netscape". This will display the full URL of the document indicating that it has come from the attacker’s server. As previously mentioned, many users are unaware this option exists and whilst it may provide secure assurance of the content, it can be quite tedious for users who are accessing many pages at a time, thus discouraging them from taking on this measure.
The following cases demonstrate the use of Web spoofing over the Internet.
Customers of the online computer store, Kaypro Technology, Inc., were presented with e-mail from an attacker that read,
"During this week we have had problems with out Customer Database and may have lost some of our customer’s information, so we ask if you could fill in this form http://www.kaypro.net/form.htm"
Fortunately for the potential victims, the Web spoof was betrayed by an inaccurate address in the e-mail, Kaypro Technology’s real Web site is Kaypro.com. A spokesperson for the company said it immediately sent e-mail to all its customers warning about the spoof.
A further example existed when a fake PayPal.com Web site (PayPal.com being a large third-party payment company), was designed to trick potential victims into revealing their account information to the attackers. PayPal customers were sent e-mails saying,
"We regret to inform you that your username and password have been lost in our database. To help resolve this matter, we request that you supply your login information at the following website." A link to http://paypalsecure.cjb.net followed.
Victims that fell for the ploy were unwittingly misled into entering their PayPal account information into a Web site set up by the attackers. According to one source familiar with the investigation, approximately 175 people were deceived by the attackers and the site was reported to be operating for at least two months. Furthermore, PayPal spokesman Vince Sollitto stated that, "computer criminals had been identified as setting up several password-stealing sites in the past.
Although the developers of Internet browsers have taken steps to address the problem of Web spoofing through various updates and patches, difficulties still exist in detecting a Web spoofing attack. However, there are countermeasures that can be implemented, which can provide some level of protection.
The first defence mechanism that can be implemented is to disable the ability for active content to be downloaded. In order to do this, it is necessary to disable Java, JavaScript, and Active X from within the browser. Furthermore, it is essential that plug-ins are disabled and all helper applications are turned off. As an example, Shumway R. (1998) suggests, documents such as hyperlinked word documents and power point presentations should be saved to disk and then read using a viewer that does not enable these active macros.
Whilst disabling active content may provide added security, it is important to acknowledge that, doing so reduces the functionality of the site or browser. It is therefore essential that conscious business decisions be taken to assess what level of trade-off is necessary to achieve both the required level of security, whilst still maintaining an acceptable level of functionality.
Users should ensure their browser starts up on a 'secure page'. This will provide users with a level of assurance that their initial links can be trusted and may prevent them from being sent anywhere suspicious. In this instance a 'secure page' refers to a page whose integrity can be trusted, which in practice probably means a local HTML file. For added protection, the page or URL could be stored by out-of-band means (e.g. floppy disk or a paper memo), otherwise it remains susceptible to the attack that is trying to be prevented. The user must also ensure that all the links contained within the ‘secure page’ also point to trustworthy sites.
It is further recommended that once a site has been visited and its authenticity and security have been established, the user saves the appropriate link in a repository. This repository will then be used as the entry point to the web sites when required by the user. Once this repository has been established the user could regain the functionality previously lost by enabling the active content within these trusted sites.
O’Dwyer F. (1997) explores this idea further by suggesting that users implement a type of mapping process that maps hyperlink text or images to DNS names/URLs kept in the browser. For example, an entry might contain:
"*Allied Irish Banks*:*.aib.ie".
Then, when the browser sees a https link with 'Allied Irish Banks' in it, it would check for a server certificate in the domain aib.ie. Also, when a connection was made to a domain that was not on the right hand side of a bookmark entry, the browser would warn the user about that too. This would allow users to configure in-browser safeguards for accessing certain content. This approach attempts to supply the missing secure mapping from the link text to the URL domain name.
The implementation of DNSSEC technology is another measure that may be taken to make a Web Spoofing attack more difficult for an attacker to complete. DNSSEC allows Web Sites to verify their domain names and corresponding IP addresses using digital signatures and public-key encryption. With DNSSEC, when you get back an answer from DNS, you can verify that it's from someone who is authorized to give you back an answer.
When an end user types a domain name into his browser, his local DNS server sends a query through the Internet's distributed hierarchical DNS to look up the matching IP address for that domain name. DNSSEC allows a user to control which IP addresses the user can get DNS updates from, therefore providing a restriction to trusted or well-known IP’s.
For DNSSEC to work most effectively, the end user's local DNS server and the Web site's DNS server must support DNSSEC, along with the Internet's root and top-level domain servers. When all of these pieces are in place, the Web site's DNS server uses public-key encryption to send out a digital signature to the local DNS server to verify the authenticity of the Web site. Once the authenticity is confirmed, the end user can access the Web site.
DNSSEC requires more powerful hardware and a significant increase in management time and it is suggested that due to the extra effort required, successful adoption of this security measure may be reduced.
Whilst there are a number of countermeasures that can be undertaken to reduce the risk of a Web Spoofing attack, real defence remains with the individual users. As Felten et.al. (1997) explain, the problem relies heavily on the vigilance of users to check the location lines on their browsers and identify whether these locations point to a location they would assume as being reasonable. This obviously requires the user to always ensure that the location line is displayed on their browser. As previously mentioned, checking the properties of the pages being viewed is another method that can be used, however, this again relies on the vigilance of the user to carry out such a check.
Web Spoofing, whilst not being one of the more popular attacks, remains one of the easiest and has the potential to cause not only disruption to services, but actual financial loss to both organisations and individuals. As the use of the Internet continues to grow particularly in regard to E-Commerce, the risk associated with Web Spoofing attacks will also increase. It is therefore essential that users are made aware of such attacks and take a "Defence-In-Depth" approach to reducing the potential risks that may be present. Such an approach must include the implementation of any commercial browser patches, disabling active content, secure page repositories, domain name/URL mapping and user awareness. Adopting "Defence-In-Depth" will provide an approach that makes it more difficult for the attacker to successfully carry out the Web spoofing attack, so whilst it does not guarantee that such an attack will not occur, it will provide an increased level of security.
Bellovin, S. (1989), Security Problems in the TCP/IP Protocol Suite.
Bogan, M. Lenz, M. Reichpietsch, A. Simons, P. (1999),
http://cryp.to/publications/web_secure_platform/
Felten, E. Balfanz, D. Dean, D. Wallach D. (1997), Web
Spoofing: An Internet Con Game, Technical Report 540-96, Department of Computer Science,
Princeton University,
http://www.hackersclub.com/km/library/articles/spoofing.txt
Fester, P. (1999), CNET News.com, January 5,
http://news.cnet.com/news/0,10000,0-1005-200-336994,00.html
http://geek-girl.com/bugtraq/1998_4/0475.html
http://home.netscape.com/security/notes/framespoofing.html
http://www.cs.princeton.edu/sip/WebSpoofing/
http://www.info-sec.com/internet/00/internet_101900a_j.shtml
http://www.nat.bg/~joro/b14.html
http://www.nmrc.org/faqs/hackfaq/hackfaq-9.html
Kerstetter, J. (1999), eWeek, February 18,
http://www.zdnet.com/eweek/stories/general/0,11011,1013941,00.html
O’Dwyer, F. (1997), Hyperlink Spoofing: An attack on
SSL Server Authentication, January 3,
http://www.brd.ie/papers/sslpaper/sslpaper.html
Passmore, S. (1997), Research Paper on Web Spoofing,
http://www.mis.txwes.edu/~passmore/project.html
Shumway, R. (1998), Common-Sense: An Alternative to Web
Security,
http://csrc.nist.gov/nissc/1998/proceedings/paperD8.pdf
University of Washington Computing & Communications
(1999), Windows on Computing, No. 22, Winter,
http://www.washington.edu/computing/windows/issue22/spoofing.html
to top of page | to Threats & Vulnerabilities | to Reading Room Home
