Internet Explorer Attacks

Let me count the ways. There are dozens of ways to attack a computer using its browsing client. Attack types include URL spoofing, buffer overflow, cross-site scripting, zone manipulation, file execution, directory transversal, malicious content, MIME type mismatch, cookie manipulation, browser interface manipulation, and plug-in exploits. The different types of attacks can result in a complete system compromise, system reboot, denial-of-service, privilege escalation, information disclosure, session hijacking, and defeat of security controls. Here's a summary of the different types of attacks.

URL Spoofing

This has been one of the most popular types of attacks of the past few years because of professional phishers. Phishers send fraudulent e-mails with spoofed URL links. Usually the message appears as though it were coming from some entity the user may have business with (e.g., eBay, a banking site, an ISP, etc.), and it urges the user to follow the enclosed links and reveal confidential information. Usually phishing e-mails are looking for credit card information. Users click on the provided links, thinking they are headed to a particular web site, but are instead headed to the phisher's fraudulent web site (mocked up to look like the official web site).

Figure 10-2 shows a phishing e-mail I received. It claims to be welcoming me to the Bank of America company as a VISA card user, but I do not have a Bank of America VISA card. None of the links point to the legitimate Bank of America web site (www.bankofamerica.com). One of the most telling signs of this phishing e-mail is the sender's e-mail address, [e-mail]. The Mynewcard.com domain is not registered to Bank of America.

Figure 10-2

Most phishing e-mails are not as obvious as this one. Most contain links that do point to the legitimate web site. Maybe only one or two of the twenty links in the e-mail point to the fraudulent site, but it is the main link the phisher points the user to. Most phishing e-mail contains a statement that warns about fraudulent e-mail, or a message indicating that the current message was scanned and found to be free of viruses.

URL Obscurity

The phishers often obscure the true URL using a variety of methods. One of the most common methods is to encode the URL using something other than plaintext characters. The majority of URLs contain nothing but plaintext characters, but the formal RFCs on URL formatting allow URLs to be "encoded" many other ways besides plaintext characters. Originally, the idea to allow encoding was to allow the many different types of computer systems to share the same Internet. However, almost all legitimate sites on the Internet use plaintext characters (and maybe percent encoding — e.g., %20 for a space, etc.). The only people using the many obscure encoding techniques are malicious hackers. Table 10-2 shows some of the various ways that the www.wrox.com URL can be encoded.

Table 10-2

Encoding Example(s)	Type of Encoding/Description
http://www.wrox.com	Normal plain ASCII text DNS domain name
http://208.215.179.178	IP address (decimal-dotted). Uses normal IPv4 address instead.
http://3503797170	IP address in base 10 (double word or DWORD decimal)
http:// 0320.0327.0263.0262	IP address in base 8 (octal)
http://www%2Ewrox%2Ecom http://%77%77%77%2E%77% 72%6F%78%2E%63%6F%6D	Percent hexadecimal (base 16) encoding
http://www.wrox.com/anythingIwant/.%2e	Percent encoding reverse — several control characters will "backspace" over the previous portion of the URL
http://0xD0D7B3B2
http:// 0xD0.0xD7.0xB3.0xB2	Hexadecimal notation
Note 1: Not all of these examples work in Internet Explorer, and some depend on the version of IE. Most of the malformed examples have been disabled in IE 6 XP SP2 and IE 7.x.
Note 2: You can use the URL Calculator (www.searchlores.org/zipped/urlcalc.zip) to see some of the encoded outcomes of your favorite URLs.

The following reference is a good site for hexadecimal URL conversions: www.w3schools.com/tags/ref_urlencode.asp. A good paper on URL encoding can be found at www.technicalinfo.net/papers/URLEmbeddedAttacks.html.

There are several other ways of encoding, and of course all the methods can be mixed together to fool the nonsecurity-aware user. In order to defeat these types of encoding tricks, the browser must "normalize" the link first to its plaintext ASCII equivalent using great care, and then evaluate it. Sometimes a mixture of malicious encoding and other spoofing tricks works when complex encoding won't (see Table 10-3).

Table 10-3

Encoding Example(s)	Type of Encoding/Description
http://www.wrox.com/www.microsoft.com.downloads.patches/.%2e	Percent encoding reverse — several control characters will "backspace" over the previous portion of the URL
http://208.215.179.178/www.microsoft.com.downloads.patches/.%2e	Mixture of IPv4 address and the previous example
http://%77%77%77%2E%77%72%6F%78%2E%63%6F%6D/www.microsoft.com.downloads.patches	The end user only sees the Microsoft download reference
http://[e-mail] http://www.microsoft.com@%77%77%77%2E%77%72%6F% 78%2E%63%6F%6D	The @ sign in the middle of a URL is usually indicative of a login name and password being passed to the web site, but in this case it is just a hacker trick. The hacker's website will ignore the fake login, but the end user sees www.microsoft.com.
http://www.eBay.com.badsite.com	In this case, the user sees www.ebay.com and thinks the link is legitimate, but www.eBay.com is the server name at badsite.com.
http://www.BankofAmericaUSA.com
http://support.micosoft.com/downloads.patches
http://wwwebay.badsite.com	Sound-alike web sites fool many users.

There really are an unlimited number of ways to fool unsuspecting end users. Phishers even write scripts that pop up dialog boxes, message boxes, or other windows that hover over the true URL, so that even though the browser is displaying the true web site URL, the end user sees the fake URL.

Phishers have even used legitimate web sites to redirect victims to the malicious web sites. Several legitimate web sites have functions that can be manipulated to redirect browsers to outside web sites. The format is something like the following:

• www.goodsite.com/scripts/goodscript.asp?www.badsite.com/login

The legitimate good site contains a script or feature that allows the legitimate web site to quickly redirect the user to the bad site. Here's a real redirection example received by the author:

• http://www.medicallab.com.tw/%20/https::/www.paypal.com/cgi-bin/webscr/update.html

Malware, especially spyware, will spoof the user outside of IE. Several malware programs have re-written the user's DNS HOSTS file so that legitimately specified URLs point to redirected sites. Other rogue programs poison the DNS server's cache (often completely unknown to the user) so that the legitimately typed address ends up redirecting the user to the malicious site. Spyware and adware programs often manipulate the browser's proxy settings so that all transactions pass through a malicious proxy server to and from the legitimate web sites.

To fix these types of attacks, the browser needs complex anti-spoofing mechanisms. Internet Explorer 7.x contains significant upgrades to its anti-spoofing and anti-phishing mechanisms. Good reading on the different mechanisms can be found at www.technicalinfo.net/papers/Phishing4.html. Microsoft has a good anti-spoofing article at http://support.microsoft.com/?id=833786.

Buffer Overflow

When a malicious hacker or program overflows a service or process, they normally get the permissions and credentials that the program was running in. Internet Explorer sustains several buffer overflows a year, although they are always quickly patched. Such was the case with the Web Browser ActiveX control (www.kb.cert.org/vuls/id/842160) in 2004 and the JPEG image buffer overflow (http://secunia.com/advisories/12528) in 2005. Unfortunately, too many users run IE using admin credentials. Windows Vista and its Protected Mode will run IE as a restricted user by default, decreasing the risk of IE buffer overflow. Luckily, Internet Explorer has not suffered a buffer overflow that was remotely exploitable that also allowed privilege escalation. IE 7 should make this less likely.

Cross-Site Scripting

Cross-site scripting (XSS) is a situation in which scripting in one IE window or frame (i.e., the malicious window) is able to interact with another window, web site, or frame in an unauthorized manner. In most cases, the malicious web site is attempting to steal confidential information intended for the legitimate site. A simple example would be when a user is tricked into visiting a malicious web site. The user either leaves the malicious site open or closes it, and then opens a legitimate web site. Maybe the legitimate web site is a banking web site asking the user to log on. The malicious web site might be able to launch a XSS attack whereby the logon prompt is spoofed and the information collected is sent to the malicious web site. The malicious web site can then send the stolen information to the legitimate web site where the user is none the wiser. The malicious web site could even spoof the SSL session. The user would see the 'lock" icon (i.e., SSL status) at the bottom of IE and think the web page is secure. However, the session they could be seeing as encrypted and authenticated would be between IE and the malicious web site, something they would not discover unless they clicked on the SSL icon and looked at the digital certificate.

Cross-site scripting attacks are very common. According to www.secunia.com, they accounted for 10% of IE vulnerabilities over the last three years. Microsoft has worked hard in IE 6.x and even more so in IE 7.x to prevent cross-site scripting attacks. One of the things they have done in IE 7.x is to make SSL/TLS session details more visible. A user clicking on the SSL icon can view the digital certificate and details (see Figure 10-3). An excellent discussion on cross-site scripting can be found at www.cgisecurity.com/articles/xss-faq.shtml.

Figure 10-3

Zone Manipulation

Internet Explorer has five different security zones:

• Internet

• Local intranet

• Trusted sites

• Restricted sites

• Local Computer

Internet security zones allow users to granularly define specific permissions for different Internet or intranet resources. Mature IE users wish for more zones or the ability to make customized zones, but most other browsers do not have this type of feature at all. Internet Explorer allows users (or administrators) to define ahead of time particular security permissions and privileges for various web sites. Of course, if a malicious user or program can make their content "jump" between a zone of fewer privileges to one of more permissions without the end user's consent, many security vulnerabilities can take place. This indeed has been a long ongoing weakness and problem with IE and its security zones.

Local Computer Zone

The first four zones are readily accessible in IE (see Figure 10-4) by choosing Tools ð Internet Options, and then selecting the Security tab. The last zone is not easily user definable and represents content residing on the local computer. The Local Computer zone (also known as the My Computer zone) was one of the most privileged zones in Internet Explorer. All content residing in the Local Computer zone executes with the permissions of the logged in user and was not otherwise restricted until Windows XP SP2 and Windows Server 2003 SP1. In all of the latest Windows versions, the Local Computer zone is locked down with additional restrictions to prevent malware execution.

Figure 10-4

The Local Computer zone lockdown establishes the following new default behaviors:

• ActiveX controls may not run.

• Java applets may not run.

• Users may be prompted before they can run a script.

• Users may be prompted before they can open a data source belonging to a domain other than the original server.

The Local Computer zone cannot be manipulated in IE by the end user, but it can be configured using registry edits and programmatically. This is bad for the end user and administrator but good for malware.

The zones can be manipulated in the registry at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\InternetSettings\Zones. Each zone is represented by the numbers 0 to 4, going from least to most restrictive. 0 is the My Computer zone, 1 is the Intranet sites zone, 2 is the Trusted sites zone, 3 is the Internet zone, and 4 is the Restricted sites zone. If you are interested in manipulating zones using the registry, read Microsoft KB article #182569 (http://support.microsoft.com/?id=182569). Editing zones via the registry allows a higher level of granularity than you can obtain through IE (i.e., defining of acceptable TCP/IP port numbers and protocols for each zone), but for most users IE zone settings are best configured in IE.

Note 

IE 6 SP2 for XP and IE 6 for W2K3 SP1 introduced increased protections on the Local Computer zone intended to prevent malicious code from exploiting the higher privileges of its local location.

Internet Site Zone

The Internet site is the default zone for all content not previously defined as residing in one of the other zones. Most of the time when you are surfing on the Internet using IE, the content being downloaded will reside in the Internet zone. The permissions and privileges in the Internet zone are moderately restricted (called Medium security) compared to the other zones. The security level is appropriate for most Internet sites but is too lax when unpatched vulnerabilities are prevalent. Many Internet attacks can be stymied when scripting and ActiveX controls are disabled, which the Internet zone allows by default. If a widespread vulnerability is present, users can benefit greatly by customizing the security (covered below) to disable scripting and other non-HTML content. Unfortunately, disabling the additional types of content all the time will cause errors on many web sites. Many security experts wish the most popular web sites used less special features and non-HTML content so that the Internet zone could be locked down more to prevent many malicious attacks without causing problems with legitimate content and web sites. Most users could benefit by customizing the Internet security zone to an acceptable level of usability and security.

The Internet site zone's default security level was moved to Medium-High in IE 7.

Local Intranet Zone

The Local intranet zone is a zone with high default privileges. The default security level is Medium-low. The intent is that users (or administrators) place internal trusted web sites in the Local intranet zone, and any sites in this zone will have elevated privileges. By default, all web sites residing on the local LAN (and other defined private IP subnets) will be placed in the Local intranet zone without the user having to specifically add the web site. External web sites can be added as well (see Figure 10-5), although users should remember that sites in this zone have elevated privileges.

Figure 10-5

As Figure 10-5 shows, along with the default selections, there are several options under the Local Intranet zone. The first is Include all local (intranet) sites not listed in other zones. This means that any server sites on the local network not listed in the Trusted sites or Restricted sites zone will automatically be included here. If you disable this option, sites on the local network will not automatically be included in the Local intranet zone. The Include all sites that bypass the proxy server option assumes that IE uses a nontransparent proxy to access the non-local site. By enabling the option, IE will add any sites that are excluded from having to be filtered through the proxy server. The reasoning is that only trusted sites would be excluded from being handled by the proxy server; and because they are trusted, they should be included by default in the Local intranet zone.

The Include all network paths (UNCs) option instructs Windows to include any NetBIOS shares in the Local intranet zone. This setting means that any security choices made on the Local intranet zone might impact regular Windows drive mappings. The Advanced button allows sites to be added manually. By default, the sites added to this location must be protected by using the HTTPS protocol to ensure site location authenticity, but this option is often deselected.

Note 

The Local Intranet zone will be disabled by default in IE 7 for non-domain computers.

Trusted Sites

Sites placed in the Trusted sites zone have minimal restrictions and a Low security level. Most actions and content will be allowed to execute without user intervention. Even the highest-risk actions only require the user to acknowledge before they proceed. Unlike the Local intranet zone, the Trusted sites zone has no included web sites by default. New sites can be required to be protected by HTTPS, the default, or just unsecured HTTP.

Note 

The Trusted sites zone's default security level was moved to Medium in IE 7.

Restricted Sites

The Restricted sites zone, as its name implies, restricts most non-HMTL content and activity by default. The security level is High. The only activity allowed without user intervention is pop-up ad blocking and font downloading. By default, no sites are within this zone. The Restricted sites zone has no HTTPS requirement option. Most users won't have any entries here, because if the web site is high risk, they should not go there. With that said, if a user plans on visiting a high-risk web site, they should put the web site's domain name here, although don't expect IE's High security level setting to prevent all attacks. Malicious web sites often have unknown "zero-day" attacks or use social engineering methods to trick the user into executing malicious code.

You can also create your own IE security zones programmatically or using registry edits, although these zones are not easy to configure and cannot be accessed using the IE GUI. For more information, see http://blogs.msdn.com/ie/archive/2005/01/26/361228.aspx. I hope that Microsoft creates an easy way for an unlimited number of new zones to be easily created and configured in the future. Why they have not done this already is a mystery. This chapter will cover each IE security setting and the default settings in each of default IE security zones in detail.

File Execution

Many IE attacks are successful at getting malicious content downloaded to the user's system and then executed. To do this, a malicious web site must instantiate one or more file downloads, and be able to trick the user into executing it or exploit a browser vulnerability. IE will not execute most potentially malicious content without the consent of the user, so malicious web sites will often attempt to download bad content to the user's local hard drive with the first command and then execute it with a second. If the malware is successful with both commands, the content, now considered part of IE's Local Computer zone, will be able to execute any future instructions in the context of the logged-in user. These attacks are known as cross-zone attacks, since the code originated from the Internet zone and was able to be placed in the more trusted Local Computer zone.

To prevent a web site or malware from easily accomplishing this process, IE downloads all content to a randomly created (and randomly named) file and subdirectories under the Temporary Internet Files (TIF) folder. Because the content is downloaded into unpredictable names and locations, malicious web sites cannot easily find and execute the content. At least, that is how the cross-zone defense is supposed to work.

Over the years, many malware programs have been able to find exploits in IE that allowed it to predict or determine where the malicious content would be downloaded and the temporary name given. IE 6, after many successful attacks, has been significantly strengthened against cross-zone attacks. XP Pro SP2 IE 6.x stopped most of the known cross-zone attacks and IE 7 is further strengthened. IE7 treats all downloaded code as belonging to the Internet zone even when it is stored or called from the local hard drive. Still, given the complexity of trying to keep the different zones separate, it would be unlikely that this class of attack would remain unexploited in the coming years.

Note 

One of the key aspects of file execution attacks is that IE usually downloads the content to the TIF area for evaluation even when the content is not going to be executed. It would be better if the content were evaluated and then downloaded, but it often appears the other way around, and this leads to many exploits that would otherwise not happen. For that to work, IE would have to restrict itself to behavior promised by the file name extension. As this is not the case, the first part of the file would have to be pulled down to sniff the header data for MZ marker, etc. IE may also initiate the downloading of material before the Save As dialog box is dismissed for performance reasons (this is welcomed by most users paying by the minute for dial-up service).

Directory Traversal

One of the most frequent types of attacks, although growing less successful over time, is the directory traversal exploit. In this type of attack, much like the URL spoofing attack class, a malicious link or web site attempts to access content that should be protected against remote interaction. If the attack is successful, a malformed URL can allow a remote attack or program to access content that the normal security permissions should prevent. Directory traversal attacks usually do this by using a combination of one or more \..\ sequences. In Windows, a single period (i.e., .) in a directory listing means the current directory. Two periods (i.e., ..) means the parent directory. Legitimate users often use ..\ or \..\ to jump among various subdirectories under a common parent (e.g., cd..\test to jump from c:\parent\example to c:\parent\test). Malicious URLs will contain one or more of these sequences in order to confuse the HTML parser and access resources they otherwise could not.

Here's an example from a Windows Server 2003 IE traversal vulnerability (http://secunia.com/advisories/9989):

 <a href="shell:cache\..\..\Local Settings\examplefile.html"> 

Malicious directory traversals can only be stopped by a rewrite of the HTML parser or a third-party intrusion detection tool. Thankfully, after many example exploits, directory traversal attacks are becoming less successful.

Malicious Content

It goes without saying that the content the user downloads can simply be malicious from the start. If the user can be socially engineered into running a piece of malicious code, it can often bypass any warning system or defense mechanism. Users are almost always warned about potential maliciousness before they run it, but most users are willing to take the risk that the program they are running is what it claims to be and will almost always run the program (or click on the file attachment). To paraphrase another security expert whose name I can't remember, "Users will bypass any warning, click on any file, ignore any security teaching to download a screensaver with pigs flying out of someone's butt!" That is indeed the problem. Most users will ignore all the good advice that we have given them, and when a security decision is left up to them, they will often make the wrong decision. That's why all software, including IE, needs to be better about not allowing truly malicious software to reach the end user.

MIME Type Mismatch

As covered before, MIME Types is the way different types of content are identified in a browser (and other applications). The web site indicates the MIME Type in the "TYPE=" or the "Content-Type=" field of the web page hosting the content to be downloaded. IE used to take the web site's word that the MIME type indicated matched the file format. This led to several vulnerabilities. For example, IE would download a file indicating it was a "skin" overlay for a multimedia player, but after downloading the "skin" turned out to be a malicious JavaScript, and executed as such.

Now, IE looks at the MIME Type indicated by the web page, checks the HKCR\MIME\Database\Content Type registry key, and locates the correct file extension. If IE thinks there is a problem between the indicated file type and the true file type, it will then read the first 200 bytes of the file (called MIME sniffing) and see if it can determine the true file format type. If it can determine the file format type from the MIME sniff, it will then run the correct related program. If IE cannot determine the file type at this point, it relies on the file extension used by the file and executes only the program associated with that file extension. IE will reject files it has determined are invalid or corrupted. IE 6.x, Windows XP SP2, and IE 7.x all have enhanced MIME typing abilities, although MIME Type mismatches are still found every now and then — enough to be on the lookout for them. Any browser that only uses file extensions to identify a file type is very prone to MIME Type mismatches. If you want more information on IE's MIME typing abilities, see http://msdn.microsoft.com/library/default.asp?url=/workshop/networking/moniker/overview/mime_handling.asp

Cookie Manipulation

Cookies are text files placed on a user's computer in order to keep track of the session state of a particular web site from click to click. Without cookies (or other session state mechanisms), web sites would not be able to keep track of which user sent what click and request. A user trying to buy jeans would have to enter their information (i.e., jean size, jean brand, color, type, credit card number, name, address, etc.) all on one screen, or else the web site would lose track.

Instead, a cookie placed by a web site usually contains information identifying a particular user. Every time a web page is requested, the delivering web site can read the cookie, get the identifying information, and then use a backend database to keep track of which user is doing what. It's the way that Amazon always says hello to you and recommends books that might hold your interest every time you log in.

Early on, web vendors put the user's identifying information in plaintext, in the cookie. For example, banks would put the user's bank account number and PIN number in the cookie. Other e-commerce companies would put the user's account information and credit card information in the cookie, and use the cookie request to retrieve the confidential information.

Unfortunately, two main problems arose. One, if a malicious web site can retrieve another web site's cookie (as is often the case), the malicious site can then "become" the user on the legitimate web site. Two, if what was stored in the cookie was the user's plaintext account number and that account number could be predicted, a malicious user could spoof their own cookie and become another user.

For example, the malicious user could join a popular e-commerce site and see if the cookie contained a predictable account number. For example, if the malicious user joins multiple times under different names and reads their own cookie, they might see that every time they join, their account number is incremented by 1. Then, by modifying their cookie and incrementing or decrementing the cookie account number value, they can spoof and become another user. The web site is none the wiser; it's simply reading a cookie value. Unfortunately, this type of issue is still common. One of the world's largest online banks was just recently found to have predictable, plaintext user account numbers stored in their cookies. IE 6.x and later has very strong cookie handling, but ultimately it is up to web site programmers to ensure that their cookies can't be spoofed.

Note 

Some browser versions also allow scripts to be stored and executed from cookies, which can allow malicious execution on the local computer.

Browser Interface Manipulation

As recounted in Table 1-1 in Chapter 1, spyware and adware has taken browser interface manipulation to a whole new level. There are dozens of ways IE can be modified, with or without the user's permission, to control the behavior of IE. Spyware often changes the way searchers are done, in order to direct users to locations other than where they would want to knowingly go. Menu bars are modified, added, or deleted; start or home pages can be modified; URLs are redirected; buttons, toolbars, and menu bars added; virtually the entire IE interface can be customized — for good or evil.

Plug-In Exploits

It's not just IE that is exploitable, but any program it loads. Browser plug-ins, also known as Browser Helper Objects (BHOs) or add-ons, add additional opportunities for the bad guys to break in. Nearly every popular add-on has had one or more exploits, including Macromedia's Flash, Sun's Java Virtual Machine, Microsoft Windows Messenger, and Winamp. The popular PDF viewer, Adobe Acrobat Reader, has had six vulnerabilities in the last two years alone. Without a doubt, every additional add-on software product added to IE increases the risk of a successful exploitation. IE 7.x has the ability to load with a quick "no-add-ons" feature to decrease vulnerabilities. IE 6.x with Windows XP SP2 and later has the ability to manage (choose Tools ð Manage Add-ons) or delete add-on packages (see Figure 10-6).

Figure 10-6

Secunia.com is an excellent web site to search on previous and existing IE vulnerabilities. It displays vulnerabilities by IE version, date of discovery, criticality, details, and whether or not a patch is available.

Browser Tests

At any given time there are between 6 to 20 unpatched IE vulnerabilities, although most of them aren't critical. If you are concerned about whether your version of IE is completely patched and what vulnerabilities it is still susceptible to, go to a browser test web site and let them check your browser for you. Most of them are safe. Here are a few browser test web sites:

• http://bcheck.scanit.be/bcheck (the best browser test site)

• www.jasons-toolbox.com/BrowserSecurity

• www.anonymizer.com (click on the Privacy Test, the only test that is a real concern is the Clipboard test)

When the author tested IE 7 beta 1 at the first browser test web site listed in the preceding list, it ran 24 checks. IE 7 passed all checks without a problem. The site maintains statistics and it claims that 32% of the browsers tested contained critical vulnerabilities. It also claims that IE had at least one unpatched, remotely exploitable vulnerability for 98% of 2004.