How to effectively identify application vulnerabilities including some of the most dangerous application vulnerabilities that are frequently targeted by hackers.Threats Are Moving “Up the Stack”
In today’s business world, applications are utilized to automate processes and provide 24/7/365 services to customers. Outside the business world, applications are also heavily used by millions of home Internet users. Whether these applications are used for processing online merchandise orders, renewing medical subscriptions, or utilized by the government to transfer information and control your country’s national defenses, they are a critical component of most organizations. Consequently, applications that are not effectively secured can pose a grave risk to information security and allow unauthorized data access, computer misuse, or even be used to monitor the actions of an unsuspecting victim.
Because of the complexity and dynamic nature of applications, they can prove to be quite challenging to secure. Organizations ranging from large financial payment processors, to law-enforcement, to major software vendors’ themselves have suffered security incidents resulting from the exploitation of application vulnerabilities.
Today, application security is an essential skill for information security professionals.
This chapter will provide you with a good overview of application security including:
How to effectively identify application vulnerabilities including some of the most dangerous application vulnerabilities that are frequently targeted by hackers.
Countermeasures application developers can use to correct existing vulnerabilities and prevent the occurrence of new ones.
Steps that home and business application users can take to configure applications such as Web browsers and instant messaging clients in a secure manner and help to prevent the exploitation of application vulnerabilities.
Upon completion of this chapter, you will have the knowledge required to pass the Application Security Security+ exam objective, and effectively secure applications in your professional career and at your home.
Data must pass through multiple layers of communication when sent from one network device to another. These layers of communication were documented and released in 1984 within the Open Systems Interconnection (OSI) model. The OSI model details seven layers of communication and when viewing the model from the bottom up, each layer ultimately supports the layer above it. Figure 3.1 is an illustration of the OSI model.
An example of the dependency between OSI model layers, the physical layer (Layer 1) relates to the physical connection of two devices such as connecting a computer to a switch with a network cable. This physical connection between the two devices allows the second layer of the OSI model, the data link layer to verify that the connection between the two devices is intact.
When data is sent from one computer to another it starts at the application layer (Layer 7) and works its way down the stack. When the other network device receives data, the process is reversed and data begins at the physical layer and works its way up.
Over recent years, there has been a large shift in the focus of computer-related attacks moving from lower layers of the OSI model to the application layer.
FIGURE 3.1
The OSI Model
This is due to changes in network architecture and security technologies as well as efforts by vendors of operating systems (Sun, Microsoft, etc.) to harden the underlying operating system from attack. Examples of lower level attacks include Address Resolution Protocol (ARP) spoofing attacks, which allow an attacker to intercept and modify data sent between two network devices and ultimately allow the hijacking of networking communications. ARP spoofing attacks target the data link layer of the OSI model and have been largely overshadowed today by attacks targeting buffer overflow, cross-site scripting, and other application-related vulnerabilities residing within the application layer. When an attacker launches an application-based attack against another networked system, it would be received by the victim system at the physical layer and effectively work its way “up the stack.” In this chapter, we’ll discuss some of the most dangerous attacks targeting the application layer of the OSI model, but first let’s take a closer look at the reason for this shift in hacker focus.
TEST DAY TIP In preparation for the exam, you should understand the seven layers of the OSI model as well as the specific function within each.
In recent years, the objective of computer attacks has shifted from generating large denial-of-service (DoS) conditions such as those caused by the Blaster and Nachi worms to covert attacks involving data that is withheld, manipulated, or resold for financial benefit. The reason for this shift in focus is simple, crime pays. Attackers today are much more interested in receiving financial rewards for their crimes as opposed to gaining recognition within the digital underground. (For more information refer to www.symantec.com/business/resources/articles/article.jsp?aid=symantec_threat_report_documents_increasingly_sophisticated_attacks.)
Personal information such as health and financial data are prime targets of cyber crime. When attackers gain access to data for resale they often advertise it within black market forums referred to as an “underground economy.” Symantec, a leading antivirus and research organization, has recently released its 2008 report on the underground economy. Symantec’s findings show that in 2008 the most popular commodity advertised within the underground economy over a 12-month period was credit card numbers with an advertised price ranging between 10 cents and US$25 per number.1
Data that is resold within the underground economy typically resides within the application layer of the OSI model. Because of this it’s not surprising that research by Gartner shows that 75 percent of attacks occur within the application layer. Applications ranging from large e-commerce sites, such as ebay.com, to small applications, such as Internet Explorer (IE), installed on a local user’s computer are a critical component of any digital system and it’s imperative that there are knowledgeable information security professionals who can effectively secure them.
Over the past few years, security professionals have turned to a process called threat modeling to identify and assess security risks.
Threat modeling is a comprehensive process for assessing a system’s security risks. Threat modeling has been in use within large software organizations for many years; however, recently over the past few years, it has caught the eye of security professionals to address internal security challenges. Threat modeling can be applied to any information system; however, in this chapter we’ll look at how it can be used to secure applications. Threat modeling differs from other traditional forms of vulnerability assessments. A traditional vulnerability assessment performed within the corporate world involves running some sort of automated vulnerability scanning tool against an infrastructure. Scan results are generated and findings are associated with a generic risk rating that was developed by the vulnerability scanning tool vendor. Scan results at this point may be qualified and sent out to the appropriate individuals for remediation.
This approach may be viewed by many as effective; however, the reality is that this type of vulnerability assessment typically detects only a small subset of vulnerabilities that actually exist within an application. The reason for this is automated scans look primarily at common forms of insecure coding practices, misconfigurations, and missing patches. However, serious risks that don’t fit into this category often go undetected. As an example, running a vulnerability scan against an application may identify vulnerabilities, such as buffer overflow vulnerability within an application, which could be exploited to gain unauthorized access to data. This is good if your only security objective is preventing an unauthorized user from gaining access to data. Taking a step back, we note that information security is more than just protecting an application against a hacker; what about an attack from within? If the attacker is an insider—let’s say a database administrator (DBA)—he or she would have little reason to exploit a buffer overflow vulnerability to gain access to data if he or she could simply walk up to a server and steal the targeted sensitive information. Viewing information security with a narrow focus often neglects other high-risk attack vectors.
Threat modeling uses a systematic approach setting clear objectives and taking a holistic view of security to identify the threats and vulnerabilities that threaten defined objectives. There have been several books, articles, and case studies written about the threat modeling process. Although these publications each cover the practice of threat modeling, the various sources often have slightly different views about the phases of the threat modeling process. In this chapter, we’ll look at the threat modeling process as defined by Microsoft, an organization that has made a considerable investment in it and developed a vendor-neutral process that will prepare you for the exam. Figure 3.2 illustrates the five major phases of the threat modeling process.
Details on the phases illustrated within Figure 3.2 are covered in greater detail in the following sections:
Security Objective Definition: Security is a broad subject, which without clear focus can quickly become overwhelming. In this phase, the security objectives placed on the application are identified, thus helping to control the scope of the threat modeling process. For example, one might define the security objective of ensuring the confidentiality and integrity of credit card data stored, processed, or accessed by a Web application. This Web application may contain multiple components some of which are in no way involved in accessing, storing, or processing credit card data and these components should be omitted from the threat modeling process.
FIGURE 3.2
The Five Major Phases of Threat Modeling
Application Review: In this stage, the application solution and design documentation is reviewed to identify key functionality. Special attention should be placed on the application architecture and technologies in use, how the application is used, and the security mechanisms in use. An application diagram is developed based on the information gathered during the application review and used to plan further in-depth analysis within the application decomposition phase.
Application Decomposition: This stage focuses on the in-depth review of application internals such as ingress and egress data flows and application trust boundaries. Trust boundaries mark areas within applications that require a change in trust, for example, a trust boundary would be placed on an administrator function seeing it cannot be accessed by a normal user account or receiving data input from an untrusted source. This section involves further application diagramming and the findings within this phase will aid in threat identification.
Threat Identification: Threats to the earlier defined security objectives are identified factoring in knowledge gained during application decomposition. This is normally completed by way of brain-storming sessions where participants review prior collected information to identify possible areas of attack. To aid in threat categorization, a threat model framework such as Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service, Elevation of privilege (STRIDE)2 is used. An example of a common application threat is gaining unauthorized access through a brute force attack.
Vulnerability Identification: On the basis of the earlier documented threats, the application is reviewed and specific vulnerabilities are documented. In a brute force attack, the exploitable vulnerability would be weak password controls including password complexity and account lock out settings within the application.
Threat modeling can be an effective process if the correct people are involved. The best threat models involve representation from many groups within an organization including security analysts, developers, business analysts, and information architects. Combined, this group will provide a comprehensive understanding of the application, associated technologies, and vulnerabilities, therefore creating a much better threat model than the one created solely by a security analyst.
Because of the large amount of time and effort required to build a threat model, they are usually reserved for securing large or complex applications such as those that are custom developed by organizations.
TEST DAY TIP You will neither be expected to develop nor analyze a provided threat model during the exam. For preparation gain an understanding of the benefits and the five process phases.
Now that we have walked through an overview of threat models, we’ll look at some of the most dangerous application security threats that may find their way onto threat models that you are tasked with creating or reviewing.
When one thinks of application security one often thinks of custom developed applications as opposed to those developed and distributed by major software vendors. However, application security involves securing both custom developed as well as Common Off The Shelf (COTS) applications. Web applications dominate the business world so it’s only fitting that we look at the insecurities of the number one client application used to interact with these Web applications, the Web browser.
The primary purpose of using a Web browser is to navigate and interact with Web-based applications. On a daily basis a large number of Internet users store and process sensitive financial and health data within these Web browsers. With more than 248 million Internet users in North America alone, it’s not difficult to see why these widely deployed applications are a target for cybercrime. Browser-based security was ranked the No. 1 threat in 2007 by the SysAdmin, Audit, Network, Security Institute (SANS) in their Top 20 Security Risks report3 and again in 2008 within their Top 10 Cyber Security Menaces report.4 We won’t cover all browser-based attacks featured in these reports; however, we will take a look at an extremely serious method of attack, drive-by-download, that was a large factor for these ratings.
Drive-by-download attacks occur when a user navigates to or is unknowingly directed to a malicious Web site and hostile content is automatically downloaded and executed on the user’s computer. This code when executed can provide a hacker full control of the visiting user’s computer and the user normally has no idea this attack has occurred. When a hacker gains access to a user’s computer, he or she can perform any action, such as downloading hacking, keystroke logging, or other types of tools to run on the victim’s computer to steal data. What makes these attacks so devastating is that a user doesn’t need to formally perform any interaction and computers are actively being compromised silently in the background of standard user Web browsing. Most users have no idea at all that they have been comprised or were ever at risk. According to research by Symantec in 2008, there were more than 18 million drive-by-download attacks.5 Figure 3.3 illustrates a drive-by-download attack.
FIGURE 3.3
Drive-by-Download Attack
Drive-by-download attacks apply to many popular Web browsers including IE and Firefox. Although the same general principles apply, each of the popular Web browser programs has slightly different security features and methods to configure them. As we look at the technologies within these browsers that are exploited to launch browser-based attacks such as drive-by-download, we’ll also look how settings within IE, the most widely used Web browser in the world, can be used to prevent or minimize the impact of browser-based threats. To find information on how to secure other browsers available on the Internet, you can visit their individual Web sites and refer to the browser documentation to determine which options are available and how to properly configure them. The Web sites for other popular browsers include the following:
Konqueror www.konqueror.org
Mozilla Firefox www.mozilla.com/en-US/firefox/
Apple Safari www.apple.com/safari
Opera www.opera.com/support/tutorials/security
One of the most widely used Web technologies actively exploited by hackers to carry out drive-by-download and other forms of attack is ActiveX.
ActiveX is a Microsoft-created technology that enables software applications to share and reuse software components. This functionality is routinely implemented within ActiveX controls, which are tiny applications that can be developed using various programming languages such as C-Sharp (C#), Visual C++, Visual Basic, and Java. ActiveX controls written in one language can actually share code with controls written in another. The use of ActiveX controls greatly enhances Web applications as they can access operating system functionality which is not readily available via Hypertext Markup Language (HTML) or the Web browser. An example of this is a Web application that reuses the spell-check functionality of the operating system within a Web page displayed to the user.
Reusing ActiveX features is widely performed on the Internet and even several Microsoft applications including IE use ActiveX controls to load other applications within the Web browser. Depending on the configuration of a user’s browser, it’s possible for downloaded ActiveX controls to have no restrictions when executing on a local computer including accessing and manipulating files within the local file system or the system registry.
Microsoft Windows Operating Systems are shipped with several ActiveX controls; however, in addition to these default controls many organizations write and compile their own ActiveX controls. Many vulnerabilities have been and continue to be discovered in both Microsoft-issued and third-party ActiveX controls, which make them a prime concern for security professionals. One such example is Microsoft Security bulletin MS08-041,6 which details an ActiveX vulnerability that was discovered within a Microsoft-developed ActiveX control. This vulnerability when executed could grant an attacker full control over victim users’ computers. These types of vulnerabilities aside from being used by drive-by-download attacks are being exploited and can be used by hackers to compromise computers, monitor user actions, and steal data both sent and received from victim computers.
In response to vulnerabilities within ActiveX controls, Microsoft introduced Authenticode to help ensure the integrity and nonrepudiation of ActiveX controls.
Developing Secure ActiveX Controls
Authenticode is a method of code signing that allows developers to obtain a digital certificate generated by a certificate authority (CA) and digitally sign an ActiveX control. This process helps Web users to identify the true issuer of a control and verify that the control has not been modified since it was developed. Although implementing Authenticode on an ActiveX control does not certify that it contains no security vulnerabilities, it is often regarded within the industry as safer than a nonsigned control.
Additional security features were introduced within Web browsers to support Authenticode, allowing users to configure security policies that grant controls with Authenticode greater access without user interaction for an improved user experience then those that were not signed when executing within the browser.
One of the most common vulnerabilities with ActiveX controls has to do with the programmer’s perception of the capabilities of the control. Programmers are usually driven to write efficient ActiveX controls that are also user-friendly. User-friendly controls often avoid any unnecessary pop-up messages that can cloud the user interface. There is a conflict of interest associated with ActiveX control security as the same programmer who is motivated to write user-friendly controls also has the ability to mark it as “safe-for-scripting,” meaning that it bypasses the code checking process and is not checked for an Authenticode signature. The end result is that the control may contain serious security vulnerabilities but can be run without the user being aware of a problem. As you can see, this is a double-edged sword. If it is not marked “safe,” users will be inundated with warnings and messages on the potential risk of using a control that is not signed or not marked as safe. Depending on the security settings in the browser, they may not be allowed to run it at all. However, after it is marked as safe, other applications and controls have the ability to execute the control without requesting the user’s approval. You can see how this situation could be dangerous. A good example of the potential effects of ActiveX is the infamous Windows Exploder control. This was a neat little ActiveX control written by Fred McLain (www.halcyon.com/mclain/ActiveX) that demonstrates what he calls “dangerous” technology. His control only performs a clean shutdown and power-off of the affected Windows system. This might not seem so bad, but it was written that way to get the point across that the control could be used to perform much more destructive acts. Programmers have to be careful with ActiveX controls and be sure that they know everything their control is capable of before releasing it.
Ultimately, developers have the decision on marking their controls as safe or using Authenticode. Regardless of what that decision is in the default configuration of most Web browsers, ActiveX controls will still ultimately function as designed with the proper user interaction. Developers can use the following recommendations to help minimize the number of vulnerabilities that exist within developed ActiveX controls.
Follow secure coding practices Adhering to secure coding processes will minimize the number of vulnerabilities identified within ActiveX controls. Secure coding practices including data validation (which we’ll cover later in this chapter) can be obtained from the Microsoft Development Network (MSDN).7
Use Authenticode Sign controls with a certificate issued from a trusted CA to ensure ActiveX controls are not tampered with after they are developed.
Following the above recommendations will help to improve the security of ActiveX controls. Even taking these into consideration, people are human and regardless of secure coding practices or Authenticode, vulnerabilities are inevitably discovered and exploited. With this in mind, let’s look at how users can secure the executing of these potential malicious ActiveX controls within their browsers.
Securing the Execution of ActiveX Controls within the Web Browser
Numerous vulnerabilities have been identified with both vendor-shipped and third-party-developed ActiveX controls. Typically, these ActiveX controls are downloaded when a user visits a Web site and executes the control within the user’s browser. Even security companies are not immune to developing and shipping vulnerable ActiveX controls within their products. One such example is Symantec corporation which in 2008 disclosed that there was a buffer overflow present within an ActiveX control shipped with several of their products including Norton Internet Security 2008,8 a product that normally provides protection against these type of attacks. Successful exploitation of this vulnerability could result in arbitrary code execution.
Earlier in this chapter, we looked at drive-by-download attacks. These attacks were carried against technologies such as ActiveX that automatically download and execute without user interaction. Prior to 2006, ActiveX controls could have been loaded in a user’s Web browser without them knowing about it. However, IE6.0 on Windows XP SP2 or Windows Server 2003 SP1 implemented controls requiring users to click on ActiveX controls before they are downloaded. Users may, however, simply click the prompt to allow the ActiveX control to execute and thereby permit the attack to complete. The amount of control provided to the user on the actions that are occurring in the background with the Web site they are visiting is controlled through zones in IE.
A zone is a named collection of Web sites (from the Internet or a local intranet) that can be assigned a specific security level. IE uses zones to define the threat level a specific Web site poses to the system. IE offers four security zone options:
Internet It contains all sites not assigned to other zones.
Local Intranet It contains all sites within the local intranet or on the local system. The OS maintains this zone automatically.
Trusted Sites It contains only sites manually added to this zone. Users should add only fully trusted sites to this zone.
Restricted Sites It contains only sites manually added to this zone. Users should add any sites that are specifically not trusted or that are known to be malicious to this zone.
Each zone is assigned a predefined security level or a custom level can be created. The predefined security levels are offered on a slide controller with up to five settings with a description of the content that will be downloaded under particular conditions. The possible settings are:
Low This provides the least security and allows all active content to run, and most other content to be downloaded and run without prompts. With this setting, there is minimal security for users, so it should only be used with sites that are explicitly trusted.
Medium-Low This is the default setting for the local intranet zone and provides the same security as the medium level except that users aren’t prompted.
Medium This is the default level for trusted sites and the lowest setting available for the Internet zone. Unsigned ActiveX content isn’t downloaded, and the user is prompted before downloading potentially unsafe content.
Medium-High This is the default setting for the Internet zone, as it is suitable for most Web sites. Unsigned ActiveX content isn’t downloaded, and the user is prompted before downloading potentially unsafe content.
High This is not only the default level for restricted sites but also is the only level available for that zone. It is the most restrictive setting and has a minimum number of security features enabled.
Zones are defined on the Tools | Internet Options | Security tab as seen within Figure 3.4.
FIGURE 3.4
Internet Explorer Security Zone Administration Tab
Custom security levels can be defined to fit the specific security restrictions of an environment. Within a custom security level there are numerous individual security controls related to how ActiveX, downloads, Java, data management, data handling, scripting, and logon are handled. The most secure configuration is to set all zones to the high security level. However, keep in mind that increased security means less functionality and capability.
When vulnerabilities are exploited within ActiveX controls they primarily place the user’s local computer at grave risk. To help minimize this risk, there are some steps users can take to safeguard their machines against ActiveX exploitation.
Ensure your computer is up-to-date with security patches Because of the sheer number of ActiveX controls published on the Internet and the frequency that vulnerabilities are found within these controls, it’s imperative that computers run the latest security patches which will update known vulnerabilities within these ActiveX controls and related components. To obtain the latest patches for Microsoft developed ActiveX controls and related components, you can visit http://windowsupdate.microsoft.com. Because ActiveX controls are developed by numerous third parties, you will also need to make sure that other installed controls possibly from other installed applications or which have been downloaded from Web sites are updated with the latest patches.
To obtain a listing of downloaded ActiveX controls within IE7 or IE8 you can click on the Tools | Manage Add-ons | Enable or Disable Add-ons menu item. In doing so, you will see a dialog box similar to that shown in Figure 3.5, which lists the ActiveX controls loaded and used by IE, downloaded from the Internet, and ones that can run without permission.
FIGURE 3.5
Manage Add-ons Dialog Box in IE7
Don’t click on suspicious links or navigate to Web sites you are not familiar with User vigilance is an important element of ActiveX security. Avoiding sites and links you are not familiar with can be an effective way to avoid the execution of malicious code.
Utilize browser-based security zones Granular ActiveX restrictions should be implemented using zones. Focus should be placed not only on unsigned controls but also on making you aware of what is happening in the background while you are connected to a Web site.
EXAM WARNING ActiveX-related vulnerabilities will be covered in the exam. In preparation, you should ensure that you are familiar with IE security zones, default permissions, and how to add or remove sites from zones.
Damage and Defense
Many security professionals have had significant struggles with securing ActiveX. Some, including the US Computer Emergency Response Team (US-CERT), are now formally recommending that it be disabled altogether.9
Properly setting security zones can dramatically reduce the potential vulnerability to ActiveX controls. There are five security zones:
Local intranet zone
Trusted sites zone
Restricted sites zone
Internet zone
My computer zone
The last zone, My Computer, is only available through the Internet Explorer Administration Kit (IEAK) as opposed to the browser interface. The IEAK is a Microsoft-developed application that can be used to define and dynamically manage ActiveX controls. The IEAK can be downloaded from Microsoft’s Web site.
If you do not have access to the IEAK, you can also access the security zone settings through the [HKEY_CURRENT_USER\Software\Microsoft\Windows\Current-VersionVnternet Setttngs\Zones] Registry key. The appropriate settings for this key are shown in Table 3.1.
Complete the following steps to modify the security zone settings through IE7:
1. From the Tools menu, select Internet Options. The Internet Options dialog box appears (Figure 3.6).
2. Select the Security tab. The Security Options panel appears (Figure 3.7).
FIGURE 3.6
The Internet Options Dialog Box
FIGURE 3.7
The Security Tab of the Internet Options Dialog Box
FIGURE 3.8
Security Settings Panel
FIGURE 3.9
Viewing a Warning about Zone Settings
3. Select the zone you wish to change. For most users, this is the Internet zone, but depending on your circumstances, you may need to repeat these steps for the Local Intranet zone as well.
4. Click the Custom Level button. The Security Settings panel appears (Figure 3.8).
5. Change one or more of the following settings for your desired level of security:
Set Run ActiveX controls and plug-ins to administrator approved, disable, or prompt.
Set Script ActiveX controls marked safe for scripting to disable or prompt.
6. Click OK to accept these changes. A dialog box appears asking if you are sure you want to make these changes (Figure 3.9).
7. Click Yes.
8. Click OK to close the Internet Options dialog box and save your settings.
End users should exercise extreme caution when prompted to download or run an ActiveX control. They should also make sure that they disable ActiveX controls and other scripting languages in their e-mail applications, which is a measure that is often overlooked. A lot of people think that if they do not use a Microsoft e-mail application, they are safe. But if an e-mail client is capable of displaying HTML pages (for example, Eudora), chances are that they are just as vulnerable as using Outlook Express.
Developers have the most important responsibility. They control the first line of defense against ActiveX vulnerability. They must stay current on the tools available to assist in securing the software. They must always consider the risks involved in writing mobile code and follow good software engineering practices and be extra careful to avoid common coding problems and easily exploited coding mistakes. But most importantly, they must use good judgment and common sense and perform repeated tests before releasing the code to the public. Remember, after signing it and releasing it, it is fair game.
NOTE Hackers can usually create some creative way to trick a user into clicking on a seemingly safe link or opening e-mail with a title like, “In response to your comments.” Once a Web page is loaded in the browser, or an e-mail is opened or previewed in the e-mail software, scripts, components, and applets in the HTML document can be downloaded, loaded into memory, and run. If the code is malicious, and designed to exploit vulnerability, any number of issues (including running remote code) may occur. It is important to be wary of e-mail from unknown users or Web pages that seem to be legitimate. It is even more important to have the latest service packs and patches installed to resolve vulnerability issues and to make sure that security software on the computer (including antivirus software) is up-to-date.
Head of the Class
One of the most important aspects of using a browser securely is to practice safe surfing habits. Common sense should determine what users do, both online and offline. Visiting Web sites of questionable design is the virtual equivalent of putting yourself in harm’s way in a dark alley, but Internet users do it all the time. Here are some guidelines that should be followed to ensure safe surfing:
Download software only from original vendor Web sites.
Always attempt to verify the origin or ownership of a Web site before downloading materials from it.
Never assume anything presented online is 100 percent accurate.
Avoid visiting suspect Web sites—especially those that offer cracking tools, pirated programs, or pornography—from a system that needs to remain secure.
Always reject certificates or other dialog box prompts by clicking No, Cancel, or Close when prompted by Web sites or vendors with which you are unfamiliar.
To help address ActiveX security concerns, Microsoft, within IE7 and IE8, secured several of the default ActiveX controls and disabled many others that were deemed high risk. This security feature was called ActiveX-option and more information can be obtained at http://msdn.microsoft.com/en-us/library/bb250471.aspx. Windows IE8 provides further security by restricting ActiveX controls to specific user profiles as opposed to Web sites.
Another popular browser add-in is Java. Java is considered by many to be similar to ActiveX; however, there are some core differences which according to many make it more secure when compared to ActiveX.
EXAM WARNING For the Security+ exam, you will not be expected to know how to set specific settings on your Web browser, but you will be expected to know what will be exploited if you do not set such settings.
Java is a programming language, developed by Sun Microsystems, which is used to make small applications (applets) for the Internet as well as stand-alone programs. Similar to ActiveX, the purpose of Java applets is to reuse the code existing on the local machines of visiting Web site users. In some cases, this bypasses programming limitations associated with HTML and allows developers to create feature-rich applications. Applets are embedded into the Web page and are run when the user’s browser loads it into memory.
Many operating systems, including Windows, Unix, and Mac OS X, use embedded interpreters to recognize and interpret Java bytecode within the applets. Arguably, the interpreter of choice is the Java Runtime Environment (JRE) developed by Sun. A core component of the JRE is the Java Virtual Machine (JVM), which is a collection of programs that execute applications and scripts. The JVM supports a computer intermediate language referred to as Java bytecode. Each operating system has a JVM that serves as an abstraction layer between the operating system and the executing Java bytecode, which allows for a Java applet to be written once and run on many different operating systems.
In addition to providing an abstraction layer, the JVM also incorporates security features such as the bytecode verifier, which verifies the code for a list of predetermined insecurities and sandboxing that isolates executing code in a reserved area of memory to limit the damage potentially malicious code could inflict on the user’s machine. We will look at these two security features a little later after we look at how developers can secure their Java applets.
Notes from the Field
Java Vulnerabilities
Despite integrated security features such as the bytecode verifier and code isolation, Java is not immune to vulnerabilities that place end users at risk. An example of this is documented within US Cert Technical Cyber Security Alert TA08-340A.10 This alert contains 13 vulnerabilities discovered within JRE with the worst carrying a payload of remote code execution.
Developing Secure Java Applets
Developers who write Java applets can help secure their code by implementing code signing. Code signing, as we reviewed earlier in this chapter, involves digitally signing an object which proves to users that it was issued by the advertised individual or organization and that the code has not been tampered with since development. Similar to ActiveX, a signed Java applet does not guarantee that it is clear of the security vulnerabilities that can place users at risks. The JVM uses sandboxing to restrict the damage a Java applet can inflict on a user’s computer; however, when a control is digitally signed, it is allowed to leave the sandbox and obtain access to client resources that can result in a security issue. The level of access signed Java applets will have on a user’s computer is dictated by the security policies set on the local client.
Similar to ActiveX, the two practices a developer can implement to raise the level of security within their Java applets are as follows:
Follow secure coding practices Adhering to secure coding practices will minimize the number of vulnerabilities within Java applets. Guidelines on developing secure controls can be obtained from Sun’s Web site.11
Sign Java applets Signing Java applets with a certificate issued from a trusted CA will ensure that the applets are not tampered with after it is published on the Internet.
Let’s now look at the steps a user can take to further secure the execution of potentially malicious Java applets.
Securing the Execution of Java Applets
A key security component within the JVM is a built-in Security Manager, which controls the level of restrictions placed on executing Java bytecode. This includes what code must run within a sandbox. We talked about the security added by sandbox functionality, which is great for security; however, developers complained the restrictions affected the capabilities and usefulness of the technology. Therefore, there was a workaround introduced and digitally signed Java applets (similar to Authenticode within ActiveX) were then allowed to escape the sandbox for a greater level of access to client system resources.
These restrictions are controlled by the user through security policies. Security policies are similar to zones in IE as we reviewed earlier. To secure the execution of Java applets on local clients, the following recommendations can be followed:
Ensure systems are regularly patched Java applets like other browser-based technologies are developed by numerous third-party organizations and you will need to be vigilant in ensuring the latest security patches have been applied to correct vulnerabilities. To obtain patches related to the JRE-and Sun-developed applets, you can view Sun’s online database of bugs at www.bugs.sun.com. For Java applets developed by third parties you will need to ensure that the updates are received from the issuing vendor.
Use Java security policies Local security policies can be used to restrict the level of privileges downloaded Java applets (including signed applets) have on your local computer.
Don’t click on suspicious links or navigate to Web sites you are not familiar with User vigilance is an important element of Java security. Avoiding sites and links that you are not familiar with can be an effective way to avoid the execution of malicious code.
TEST DAY TIP Both Authenticode and signed applets are methods of object signing ActiveX and Java applets. This code signing allows granular security policies to be placed on ActiveX and Java code.
EXAM WARNING Remember that an applet is a program that has the capability of performing malicious activities on your system. The known security vulnerabilities in Java and ActiveX can be fixed by downloading security-based hot fixes from the browser creators’ Web site.
Another popular development technology widely in use on the Internet and corporate intranets is scripting. Contrary to ActiveX and Java applets which were developed in actual programming languages, lightweight scripting was released by Microsoft and Netscape to allow people with no formal programming experience to develop flexible Web pages. However, similar to ActiveX and Java applets, these scripts could be exploited resulting in many attacks including the drive-by-download which we discussed earlier. The Internet today is dominated by a handful of scripting languages, such as JavaScript, Active Scripting, VBScript, and Jscript.
JavaScript
In 1995, Netscape launched a new language, Javascript (not to be confused with Java), to perform client-side Web development and to reuse functionality within other Web objects. Javascript was designed to look like Java but it is a much simpler language to grasp, making it a favorite for people without much Java-specific programming experience. Unfortunately, in addition to looking like Java, JavaScript carried the same type of vulnerabilities as its big brother Java.
JavaScript scripts carried additional restrictions over and above what was placed on Java. JavaScripts are downloaded and run inside a sandbox that prevents execution of privileged tasks, such as reading and writing files on the local computer or accessing additional information.
Java Script Vulnerabilities
Despite these restrictions, JavaScript contains similar vulnerabilities to that of Java including vulnerabilities within applets written by countless software vendors. An example vulnerability is detailed in US-CERT Vulnerability Note VU#788019.12 In this advisory, a vulnerability in a piece of JavaScript code written by Adobe Systems could be exploited granting an attacker the ability to execute remote code on vulnerable systems.
Active Scripting
Active Scripting is a Microsoft-developed scripting language similar to ActiveX that enables software components to share information and interact with each other. It’s used commonly today to support animation and dynamic content within Web pages and/or e-mail clients. Microsoft released active scripting in 1996 within their IE3.0 Web browser under the name of ActiveX scripting. This name formally changed a little later to Active Scripting which is widely used today.
TEST DAY TIP You will not be expected to understand how to program or review code snippets in the exam. You should focus your studying on understanding the common browser-based programming and scripting languages, vulnerabilities, and countermeasures.
VBScript and Jscript
VBScript is a scripting language developed by Microsoft to compete with Netscape’s JavaScript. It was regarded by many as even easier to use than Java, which, at the time, was regarded by many as the easiest language to use for development. However, after seeing the widespread adoption and success Netscape achieved with JavaScript, Microsoft developed Jscript in 1996 as a comparable language for Microsoft systems.
VBScript and Jscript scripts are tiny pieces of code that are similar to active scripting and allow developers to extend and reuse Web functionality. When a user connects to a Web server the scripts are downloaded and executed on the user’s machine depending on the security zone the site resides within on recent editions of the IE.
Vulnerabilities with JavaScript, Active Scripting, VBScript, and Jscript
JavaScript, Active Scripting, VBScript, and Jscript all suffer from similar vulnerabilities as do ActiveX and Java applets, poorly written code can be exploited by attackers, as can the scripting engine which processes the downloaded scripts. An example of a vulnerability affecting the VBScript and Jscript engines is MS08-022.13 This vulnerability occurs when the scripting engine processes malicious code making it possible for an attacker to obtain full control over the vulnerable system. Looking back at our drive-by-download example, we note that if malicious VBScript was placed on a site, when a user visited that site the default configuration of IE would have downloaded that script and executed it, thereby granting full control of the vulnerable system to the attacker at the same privilege level as the user. Depending on the user’s browser settings, all of this could occur without prompting the user.
Securing the Execution of Client-Side Scripts
To secure browsers against active scripting vulnerabilities, you can follow similar recommendations to those we looked at to secure ActiveX and Java:
1. Ensure application updates are downloaded regularly There have been numerous vulnerabilities identified within scripts that are routinely fixed by vendors, and program updates should be downloaded to ensure the latest script updates are received.
2. Use browser security zones Browser controls such as security zones should be used to restrict the level of privileges granted to executing client-side scripts.
3. Don’t click on suspicious links or navigate to Web sites you are not familiar with User vigilance is an important element of Java security. Avoiding sites and links that you are not familiar with can be an effective way to avoid the execution of malicious code.
EXAM WARNING Remember that the exploitation of browser-based vulnerabilities within ActiveX, Java, and scripting only directly impacts the client computers. However, it is possible for a compromise of credentials stored or typed into a client computer to result in unauthorized access to the very Web application that issued the vulnerable code.
As we conclude our review of browser-based code and scripting vulnerabilities, it is important to look at some security risks associated with cookies that are heavily utilized by these programming and scripting languages.
Cookies are small text files downloaded and locally stored by a user’s browser. Cookies typically contain information about the user’s session and preferences. Occasionally, Web sites also store authentication-related information such as usernames and passwords. Each time the user visits the Web site, the cookie is retrieved by the site’s Web application and data from the cookie is processed. Storing this information within client-side cookies prevents Web sites from having to store and maintain information about all user sessions and preferences. There are three main cookie types: session, persistent, and tracking.
Session Cookies
Session cookies are used by Web applications to store information and when a user closes their Web browser session the cookie is deleted. Session cookies can often contain authentication-related information about the user’s session such as display preferences and in some cases session identifiers or user names and passwords.
Persistent Cookies
Persistent cookies are also used by Web applications to store information about the user connection. Persistent cookies are typically used to store user preferences about a Web site that is nonsensitive; therefore, there is less of a concern with it persistently stored on a user’s hard drive. These cookies however are not deleted when the user closes their Web browser (session). Instead, the cookies have a timeout value set by the application and the cookies are downloaded by a user’s Web browser and stored up until expiation of the timeout value.
Tracking Cookies
When a user connects to certain Web sites, a tracking cookie may be downloaded in the background. As their name suggests these cookies are used to record user’s Web activity such as the type and specific sites they visit. Many sites may use the same form of tracking cookie. If the same tracking cookie is used by multiple sites, these sites can all read and write to the contents of it.
Access to cookies will differ depending on the type of Web browser in use. In IE, cookies can be accessed by navigating to Tools | Internet Options | Settings | View Files. For simplicity you can arrange the files by type and look for text documents. Cookies are normally prefixed with the name cookie. An example of the cookie store of an IE7 browser is shown in Figure 3.10.
By double-clicking on a cookie it can be viewed within notepad. An example of cookie contents stored by the blogs.msdn.com site is shown in Figure 3.11.
Cookie Vulnerabilities
Applications use cookies as files to store data for processing. Anytime when there are data inputs into an application there are potential security risks; cookies are no different. Cookies, small and seamless, present a large security concern and are the target of many types of attacks. We’ll now discuss some common cookie vulnerabilities and learn how to prevent them from exploitation.
FIGURE 3.10
Screenshot of Cookies within IE7 Browser
FIGURE 3.11
Screenshot of a Cookie’s Contents
Cookies containing sensitive information such as usernames, passwords, or session identifiers can be a target for hackers. Attackers can sniff network traffic and capture a cookie downloaded from a site to a Web browser or gain access to a computer and view a cookie stored on the local hard drive. By capturing cookies, it’s possible for an attacker to initiate another session to the same Web site and submit your cookie to bypass site authentication and perform actions within your account without your knowledge.
NOTES FROM THE FIELD
A common countermeasure to cookie hijacking attacks is to send cookies over encrypted channels. This prevents cookies from being intercepted and replayed or disclosed. However, a recent tool named Cookie Monster showed how easy it really is to hijack cookies even sent over encrypted channels. Cookie Monster is an advanced cookie hijacking tool that was debuted in 2008 at DefCon 16, a popular hacking security conference. There, a demonstration of how Cookie Monster will monitor network traffic and filter for Hypertext Transfer Protocols (HTTPs) connections was provided. Cookie Monster stores information about the connection that it will later use to replay to the Web site the next time the user uses the Internet to trick the Web site into sending the authentication cookie over HTTP, a non-encrypted channel. Cookies are harvested and can be used by an attacker to masquerade as a legitimate user and gain unauthorized access to many popular Web sites. Additional information can be found on the http://defcon.org Web site.
Cookie Poisoning
Some cookies used by popular Web sites store authentication data such as session identifiers, user names, and passwords using cookies stored on users’ computers. Cookie poisoning involves the modification of the data stored within a cookie. When the cookie containing the modified contents is used by the application, the values entered by the attacker are processed by the application which may allow an attacker to gain access to sensitive information about the Web site, a user, or even impersonate the user’s session.
Example: A user uses an online banking application and makes a payment to an account number stored within a cookie. By tampering with the cookie and changing the account number to your own, the payment made by the user during the session would be made to the account of the hacker as opposed to the user’s account as intended.
Cookie leaking occurs when sensitive information such as user names and passwords and account numbers are stored within cookies and then the information is obtained by unauthorized users. In some cases browsing habits recorded by session cookies may also be considered sensitive. By gaining access to this information via cookies, unauthorized users may use this knowledge to launch other attacks.
Preventing Against Cookie Attacks
The following steps can be used to prevent or minimize the impact of cookie-related attacks for Web developers:
Enable the secure-bit setting on cookies, which will prevent the application from transmitting cookies over unencrypted channels such as HTTP. Always initiate SSL connections to supported sites to help prevent the network interception of cookies.
Web site developers should avoid using cookies to hold sensitive information. If absolutely necessary, the data values should be encrypted.
The following steps can be used to prevent or minimize the impact of cookie-related attacks for users:
Block third-party cookies. Third-party cookies are any cookie that does not originate from the domain you are visiting. Third-party cookies typically scan newly created cookies on your system and based on key words will generate targeted popup advertisements. To help combat this, IE7 introduced Advanced Privacy Settings that allow a user to specify the level of interaction they would like with cookie activity occurring on their system. To configure Advanced Privacy Settings within IE7, open Internet Options | Privacy and click the Advanced button, which will load the Advanced Privacy Settings window seen in Figure 3.12.
EXAM WARNING Cookie security is often thought of as something the Web developer is responsible for. However, integrated features within popular browsers such as IE can be used to implement security restrictions on cookie usage on the client.
As we discussed earlier in this chapter, sensitive information stored and processed by applications is big business in the underground economy. Cyber criminals will use multiple methods to gain unauthorized access to this information. Two common attacks used by hackers to gain unauthorized access to information are through the exploitation of cross-site scripting and buffer overflow vulnerabilities.
FIGURE 3.12
Advanced Privacy Settings within IE7
XSS attacks occur when one user injects malicious code into a Web site where it is downloaded and executed by another user. These attacks are performed without an attacker needing to modify Web site files or binaries. Injected data is stored within a Web application (temporarily within a variable or permanently in a file or other object on the server) and executed on the computers of unsuspecting victims. The typical method used to load and execute malicious code stored in a vulnerable Web site is in the form of client-side scripts. XSS attacks generally fall into one of two categories, Reflected and Stored.
Reflected XSS Attacks
Reflected XSS attacks involve an attacker reflecting (echoing) code of a Web application to another user where it is downloaded and executes actions crafted by the hacker. Reflected XSS attacks typically affect a single or small group of users and require user input. Therefore, hackers usually combine reflected XSS attacks with another attack such as social engineering to trick a victim into navigating to the site where the malicious code is echoed and executed by the user’s Web browser. An example of a nonpersistent attack is as follows:
1. A malicious Web site user identifies a XSS vulnerability within a Web application.
2. The malicious user crafts a hyperlink inclusive of malicious code and sends it to a victim enticing them to click on the hyperlink.
3. When the victim clicks on the hyperlink, the Web page within the hyperlink is loaded and the malicious code developed by the hacker is input into a variable within a Web page that is downloaded by the victim and executed on their local machine.
In this example, once the code has finished executing that is the end of the attack. If the attacker would like to launch another attack against the victim they would need to craft another malicious hyperlink and entice the victim to open it as well.
Stored XSS Attacks
Stored XSS attacks occur when the data supplied by a user is stored on the server by the Web application. This may be in the registry, file system, or database. This data is later retrieved by the Web application and downloaded by the Web site visitor and executed on their local machine. An example of this type of attack is as follows:
4. A malicious Web site user identifies a XSS vulnerability within the bulletin board feature of a Web application.
5. The hacker crafts a message inclusive of malicious code that is uploaded through the bulletin board application and stored within the bulletin board’s database.
6. When any user views the bulletin board message, the Web application retrieves the message’s text (and malicious code) from the database and it is then downloaded and executed automatically by the victims’ Web browser without their knowledge.
In this example, the attack is stored; therefore, every user who visits the site and views the message page will have the malicious code executed on their machines even if the user reboots his or her machine in between visits.
Preventing XSS Attacks
The following recommendations can be used to help prevent XSS attacks
Ensure all application data input is properly validated Data input can come in many forms including form fields, HTTP headers, cookies, and application variables. Regardless of where it is stored all the data should be properly validated before application processing.
Encode user supplied data Encoding is the process of converting data from one format to another. Encoding data input will not prevent the reflection of malicious code but rather will change malicious code into a format that is non-executable to block the attack.
Don’t click on unknown or malicious hyperlinks
Implement restrictive security zones As we discussed earlier, security zones will help to limit the impact of hostile code executing on your local machine.
The second common attack of choice used by attackers is the buffer overflow attack. These attacks are extremely dangerous and often don’t require any user interaction to exploit, making them a preference by hackers and virus writers.
A buffer is a holding area for data. To speed processing, many software programs use a memory buffer to store changes to data, then the information in the buffer is copied to the disk. When more information is put into the buffer than it is able to handle, a buffer overflow occurs. Overflows can be caused deliberately by hackers and then exploited to run malicious code.
There are two types of overflows: stack and heap. The stack and the heap are two areas of the memory structure that are allocated when a program is run. Function calls are stored in the stack, and dynamically allocated variables are stored in the heap. A particular amount of memory is allocated to the buffer. Static variable storage (variables defined within a function) is referred to as stack, because they are actually stored on the stack in memory. Heap data is the memory that is dynamically allocated at runtime, such as by C’s malloc() function. This data is not actually stored on the stack, but somewhere amidst a giant “heap” of temporary, disposable memory used specifically for this purpose. Actually exploiting a heap buffer overflow is a lot more involved, because there are no convenient frame pointers (as are on the stack) to overwrite.
Attackers can use buffer overflows in the heap to overwrite a password, a filename, or other data. If the filename is overwritten, a different file will be opened. If this is an executable file, code will be run that was not intended to be run. On UNIX systems, the substituted program code is usually the command interpreter, which allows the attacker to execute commands with the privileges of the process’s owner. This risk further increases if the exploited process was configured with the Set-User ID (SUID) option. Within UNIX, processes can be configured to run as root regardless of the level of permissions the user who is executing it has. Exploitation of buffer overflow vulnerability within a SUID program can grant an attacker the ability to execute malicious code as root on the victim system. On Windows systems, the overflow code could be sent using an HTTP request to download malicious code of the attacker’s choice. In either case, under the right circumstances, the result could be devastating.
Buffer overflows are based on the way the C or C++ programming languages work. Many function calls do not check to ensure that the buffer will be big enough to hold the data copied to it. Programmers can use calls that do this check to prevent overflows, but many do not.
Creating a buffer overflow attack requires that the hacker understand assembly language as well as technical details about the OS to be able to write the replacement code to the stack. However, the code for these attacks is often published so that others, who have less technical knowledge, can use it. Some types of firewalls, called stateful inspection firewalls, allow buffer overflow attacks through, whereas application gateways (if properly configured) can filter out most overflow attacks.
Buffer overflows constitute one of the top flaws for exploitation on the Internet today. A buffer overflow occurs when a particular operation/function writes more data into a variable (which is actually just a place in memory) than the variable was designed to hold. The result is that the data starts overwriting other memory locations without the computer knowing those locations have been tampered with. To make matters worse, most hardware architectures (such as Intel and Sparc) use the stack (a place in memory for variable storage) to store function return addresses. Thus, the problem is that a buffer overflow will overwrite these return addresses, and the computer—not knowing any better—will still attempt to use them. If the attacker is skilled enough to precisely control what values are used to overwrite the return pointers, the attacker can control the computer’s next operation(s).
Now that we’ve looked at the seriousness of a buffer overflow attack let’s look at a common fix, input validation. Proper input validation is the number one safeguard that can be implemented within applications and will not only prevent buffer overflow vulnerabilities but also multiple other types of attacks including XSS which we previously discussed.
For over a decade now, application security best practices have stated that input validation is a core requirement for building a secure application. Despite this awareness as reported by the Common Weakness Enumeration (CWE)/SANS Top 25 Most Dangerous Programming Errors report,14 in 2008, lack of or improper use of input validation accounted for the largest source of vulnerabilities identified within applications.
Any time information received from a user should be treated as untrusted and validated by a trusted application component prior to processing, regardless of whether or not the user providing the input has been successfully authenticated. To satisfy this requirement, many developers validate user input using server side code. Otherwise the user may intentionally or unintentionally provide malicious input to an application that can exploit a vulnerability.
An example of this is if an application is expecting to receive a numeric value from a Web user and the user enters an alphanumeric string; if no trusted input validation is in place to detect this condition and prevent processing by the application, it may result in an error during processing and associated DoS condition, or even worse, the possibility of remote code execution.
Damage and Defense
Client-side Input validation
In 2003, I was experimenting with Visual Studio.Net 2003, which provided seemingly excellent data input/validation controls integrated into Web page objects such as text boxes and drop down lists. These controls worked well in IE; however, to my amazement, loading the Web page within a Netscape browser generated several script errors and resulted in some of the contents of the page being incorrectly displayed. The integrated data validation controls did not function under this condition; however, the browser was still able to submit invalidated data using the Web page controls back to the server side C# application. This was a large security concern and just one example of how relying solely on client-based input validation controls can be bypassed without malicious intent.
Input validation is a single programming practice which if implemented properly can result in code that is immune from many types of attacks including the following:
Cross-site scripting
Response splitting
Buffer overflows
Data injection
Directory transversals
Denial of service
Not all of the aforementioned attacks will be on the exam and therefore we will not cover them in detail. They are listed to help convey the number of attacks that exist due to a lack of proper input validation. To avoid duplicating other content in this book, we will not step into the attacks that will be on the exam and are covered in various areas throughout this book. You can locate them by using the book’s index and Table of Contents.
Preventing Input Validation-Related Attacks
The best countermeasure against input validation-related attacks, such as buffer overflow, SQL Injection, or XSS vulnerabilities, is to implement proper input validation. Although the primary method used today to receive input from users is through text boxes on a Web page, applications can be written to send or receive data using multiple vectors including HTTP headers, cookies, and even text files. Therefore, proper data input validation needs to be implemented whenever and wherever data is received by the application and performed prior to processing, regardless of the method used to receive it. Data input validation should evaluate data at a minimum for the following criteria:
Type Verifies data received is within the specified format. For example, if an integer is expected the application should not process alpha values such as ABC.
Length Ensures the length of received data does not fall outside of an expected number of characters.
Format Verifies data is received within the specified format, for example YY/DD/MM.
Range Ensures the data falls within a specified range of values, for example, a value between 1 and 1,000.
Data input that does not pass all validation checks should be rejected. Data input functionality should be performed on the server that typically exists within a trusted location on the network. Malicious tools can easily bypass client-side input validation. If client-side validation is in place, data can be captured after the validation routine is run on the client, maliciously modified by an attacker, and submitted to the Web application, which could result in error.
Notes from the Field
Exploiting Client-Side Data Validation
Two popular tools used by hackers and penetration testers are Achilles and WebScarab. These tools can be used to observe how applications communicate with Web browsers. However, they can also function as a proxy that allows them to capture and manipulate application data submitted by a client and submit this data to a Web application. This can be used to exploit applications relying solely on client-side validation and result in information disclosure, DoS condition, or in some cases even remote code execution.
TEST DAY TIP For the exam you will not be expected to review code snippets and identify buffer overflow vulnerability. Just gain an understanding of what they are, what actions an attacker can perform after successful exploitation of one, and how to prevent them.
Thus far in this chapter, we have focused on some of the most serious types of application vulnerabilities such as browser-based, buffer overflow, and XSS vulnerabilities. Applications however in their default configurations and during expected use can present other significant risks to users over and above the types of attacks we have covered thus far. We’ll now shift our focus to looking at some of these risks within popular COTS applications beginning with instant messaging clients.
As more and more people go online and more businesses and their employees rely on communicating in real time, IM has grown by leaps and bounds. IM involves using tools such as ICQ, AOL Instant Messenger (AIM), Yahoo! Messenger, Google Talk, Windows Live Messenger (aka MSN Messenger or .NET Messenger), or Windows Messenger that comes with Windows XP. Additionally, other products include Lotus Sametime as well as Microsoft’s Office Communicator. This technology allows you to communicate with other members of your staff when used at work, or with friends and family when used at home. Generally, each of these IM clients ties into a service that transfers messages between other users with the same client software. However, there are programs like Trillian that allow users to consolidate their accounts on different IM networks and connect to AIM, Yahoo! Messenger, Windows Live Messenger, I Seek You (ICQ), and Internet Relay Chat (IRC) all within a single interface. In recent years, such features have also been folded into other IM software, such as Windows Live Messenger supporting messages exchanged with Yahoo! Messenger clients. Despite the popularity of IM clients, many businesses prohibit the use of IM programs on network computers. One reason is practical: incessant “chatting” can become a bigger time waster than gossiping at the water fountain (and one that is less obvious for management to detect). But an even more important reason is that IM technologies pose significant security risks. Each of the messenger programs has been exploited and most of them require a patch. The hacker community has discovered exploits, which range from DoS attacks all the way to executing remote commands on a system. For the Security+ exam, the following security issues that are related to using IM technology must be acknowledged:
Internet Protocol (IP) address exposure is prominent and, because an attacker can get this information from IM technology, provides a way that an attacker can isolate a user’s home machine, crack into it, and then exploit it.
IM technology includes a file transfer capability, with some providing the ability to share folders (containing groups of files) with other users. In addition to the potential security issues of users making files available, there is the possibility that massive exploits can occur in that arena if the firewall technology is not configured to block it. All kinds of worms and viruses can be downloaded (circumventing the firewall), which could cause huge problems on an internal network.
Companies’ Human Resources (HR) policies need to be addressed because there is no way to really track IM communication out of the box. Thus, if an employee is communicating in an improper way, it might be more difficult to prove as compared with improper use of e-mail or Web sites visited. To help solve this problem, some IM clients like Microsoft’s Office Communicator allow IM conversations to be stored in the Exchange environment and subjected to retention policies.
EXAM WARNING Make sure you fully understand the implications of using IM technology on your network. Many exploits, attacks, and hoaxes can be performed using IM.
For companies that want to allow IM for business purposes but prevent abuse, there are software products available, such as Akonix’s security gateway for public instant messaging, Zantaz’s Digital Safe, IMlogic’s IM Manager, and Microsoft Forefront Security for Office Communicator that allow companies to better control IM traffic and log and archive IM communications. Such products (combined with anti-virus software and security solutions already on a server running the IM service, and the client computer running the IM client software) add to the security of IM.
Packet sniffers are tools that can capture packets of data off of a network, allowing you to view its contents. As we will see later in Chapter 6, a considerable amount of data can be obtained by viewing the contents of captured packets, including user-names and passwords. By using a packet sniffer to monitor IM on a network, you can view what people are chatting about and other sensitive information.
The reason packet sniffers can view IM information so easily is because the messages are passed between IM users as cleartext. Cleartext messages are transmitted without any encryption, meaning the messages being carried across a network can be easily viewed by anyone with the proper tools. Being sent as cleartext makes them as easy to view in a packet sniffer as a text message would be on your computer.
In addition to packet sniffers, there are also a number of tools specifically designed to capture IMs. For example, a program called MSN Sniffer 2 is available at EffeTech’s Web site (www.effetech.com). This tool will capture any MSN chats on a local network and store them so they can be analyzed at a later time. If there is concern that information is being leaked, or policies are being broken through IM software on the network, you could use this tool to view the chats and use them as evidence for disciplinary actions or to provide to police when pressing criminal charges.
A peer-to-peer client is another type of application that is often used to promote data disclosure and an input vector for viruses.
Peer-to-Peer (P2P) networks have become a mainstream application with two of the largest P2P networks being BitTorrrent and eMule. Unfortunately, a large motivation for P2P networks is to allow users to illegally share copyrighted materials. However, there are groups of users and even some organizations who do use P2P networks for legal and morally acceptable use and need to be secured.
A typical network consists of a client-server model where there are dedicated servers that, as their name suggests, serve content to clients. P2P networks alternatively utilize a model where each client is a peer and serves each other client on the network. Figure 3.13 is an illustration of comparison client-server and P2P networks.
To join a P2P network, you must install a supported client application on a computer and ensure the appropriate network ports are open between the client computer and other P2P hosts. By looking at the previous illustration you will notice that if this were a client server model firewall rules could have been used to restrict port access between a specific client and the central server. However, with P2P networks each computer communicates with other systems. For this to work properly, a firewall rule would be required to allow traffic to and from all addresses that existing and future clients may use. For many P2P networks this would include the Internet and that would be a very bad idea. Aside from limitations on your inability to implement restrictive network-based Access Control Lists, P2P networks are associated with the following additional risks:
FIGURE 3.13
Comparison of Traditional and P2P Networks
Used as a target ingress path for Trojans and viruses The port(s) used between P2P clients to share data can include viruses. Furthermore, files within P2P networks are often renamed countless times and often only closely resemble what the contents are. Malicious users also purposely rename known Trojans with popular file names so they are appealing and hopefully downloaded by a larger number of users. There are even some viruses specifically written to spread over P2P ports in an effort to infect other P2P clients.
Used as an egress vector to transfer stolen data Stealing data requires first a successful attack granting an attacker access to data and secondly a means for the attacker to transfer the stolen information off a client/network to a location under the attacker’s control. P2P networks can satisfy the means of transferring data off a compromised computer.
Information disclosure Some P2P clients such as Kazaa and Gnutella provide backdoor file system access to other peers on the P2P network. These peers may have direct access to files stored locally on a user’s hard drive. Without strict configuration guidelines the unintentional disclosure of information can occur.
To help limit the risks associated with P2P networks, you can implement the following safeguards:
Enforce application software restrictions Software restriction policies enforced within Windows Group Policy, McAfee Host Intrusion Prevention agents, or other comparable product can be used to prevent the installation of unauthorized P2P client software.
Virus scan all files retrieved from P2P networks All files downloaded from a P2P network should be scanned using an up-to-date antivirus client before execution.
Implement strict restrictions on folders that are shared by other P2P clients This will help you to ensure that you specify and are aware of which file folders are being shared over the P2P network and can ensure not to store sensitive information within them.
Specific steps on how to implement the preceding will vary depending on the P2P client and you should refer to vendor documentation for specific instructions.
The last application we’ll look at are Simple Mail Transfer Protocol (SMTP) relays, which are used to e-mail data from a host to specific recipients. SMTP relays are used for legitimate purposes and by hackers for illegitimate purposes such as spreading spam.
Organized crime is a significant driving force behind spam. Research from Cisco shows that spam accounted for 90 percent of e-mail messages sent over the Internet during 2008. Each of these messages clogs network bandwidth, fills user mailboxes, and requires users to read or partially read the message and delete it. This wastes a significant amount of user productivity within organizations and serves as an annoyance for home users. With thoughts of spam dominating the Internet, you may envision a server room controlled by cybercrime lords or questionable product and service companies developing advertising for the sole purpose of blanketing Internet pipes with millions of spam messages per day. In reality, this scenario is rarely the case and most spam is sent from open SMTP relays existing on corporate networks or home computers without the knowledge or consent of the owner. Corporate mail systems usually contain fast servers with large network pipes; however, home computers although much slower than corporate systems can distribute millions of spam messages a day. When multiplied by the number of home computers with open mail relays, either intentionally installed or silently installed via malware, both are prime targets for relaying mail.
When attackers relay a mail message, they bounce it off an open mail relay, which in turn forwards the message to an address of the attacker’s choosing. Viewing mail headers and other network logs would lead back to the location of the mail relay application as opposed to the hacker.
Aside from serving as the source of spam messages that could lead authorities back to your organization during a cyber investigation, there are additional risks associated with sending spam via an open mail relay:
Denial-of-Service conditions Although businesses often use large Internet pipes, a single mail relay can quickly clog this pipe causing a DoS condition where legitimate business functions cease to operate due to lack of network resources.
Damage to brand Spam messages may include advertising, images, or in some cases viruses. If one of these viruses were to impact another organization, especially a client, then that organization could see the incident as an indication of the its internal security challenges, and this may affect future business.
Blacklisted on spam sites Blacklisting sites are used to track computers on the Internet that have been reported to be a major source of originating spam. These blacklists are maintained by spam-fighting organizations and used by several antispam products as the gospel to block e-mails originating from computers on these spam lists. In Chapter 6, we’ll discuss network address translation (NAT), which allows several computers within an organization to share the same IP address. This means that a single computer within an organization that is captured on the spam lists can prevent your entire organization from conducting business on the Internet with other companies using antispam technologies.
The preceding risks are most applicable for business but also apply to home users. There are several free Web sites on the Internet that can test SMTP mail relays for mis-configurations exposing open mail forwarding. One such example is www.abuse.net/relay.html that allows the user to type in the IP address of a mail relay in which the site will attempt to forward an e-mail from this mail relay just like an attacker would. A report with the test results is displayed on the Web site or e-mailed to a provided e-mail address.
To prevent the relaying of mail, mail relays and mail servers need to be properly configured to prohibit relaying or mail. In cases where mail relaying is legitimately needed, restrictions should be placed on the mail application to restrict which systems can relay mail off of it. The exact steps on how to configure mail relays will differ depending on the application; however, you can view vendor documentation for specifics.
EXAM WARNING For the exam just focus on understanding Open SMTP relay risks and countermeasures. You will not be expected to know the specific steps in securing a SMTP relay against this form of attack.
In this chapter, we reviewed application security-related Security+ exam objectives. We looked at how the focus of cybercrime has shifted in past years and how threat modeling, a relatively new method of risk assessment can help secure these complex applications. Internet usage is higher than ever, and browser-based threats are prevalent in the industry. We looked at some of the most serious browser-based threats and how they can be secured both by the developers who write them as well as the users to which they are downloaded and executed. Understanding the information, threats, and countermeasures in this chapter will not only help you to prepare for the Security+ exam but also provide you the insight needed to tackle application security, one of the largest threats to information security today.
The OSI model references the seven layers of communication that occur when two network devices communicate with each other.
Computer attacks now more than ever are targeting the application layer (Layer 7) of the OSI model.
Threat modeling uses a five-phased process of assessing and documenting a system’s security risks.
Application security consists of securing custom-developed applications in addition to COTS applications.
One of the largest risks within application security is browser-based threats.
ActiveX controls, Java applets, and scripting are tiny pieces of code stored on a Web site that are downloaded and executed on visiting users’ machines. These applications often contain serious vulnerabilities that place unsuspecting users at risk.
XSS attacks occur when one user injects malicious code into a Web site where it is downloaded and executed by another user.
Input validation is the single most overlooked secure coding practice that prevents many common forms of attack including buffer overflow and XSS attacks.
Q: Will threat models find all vulnerabilities within a software application?
A: No, threat models are a good method to identify and rate vulnerabilities that are typically missed when simply executing typical vulnerability assessment such as running a vulnerability scanner against an application. However, regardless of the number of teams involved in the threat modeling process and the level of depth it uses, there is no known method today to identify all vulnerabilities within a software application.
Q: How can my applications be protected against buffer overflow attacks?
A: It’s impossible to provide 100 percent protection, but a good start is making sure you are current with patches from the software vendor. Another approach for developers is to perform code reviews, looking for overlooked flaws in the code that could potentially be exploitable, and adopting secure coding practices with a security development lifecycle.
Q: I am afraid of Web servers learning my identity and using it against me. I think that if they have access to my cookies, they have access to my system. Is this true?
A: No, it is not. A cookie is a kind of token or message that a Web site hands off to a Web browser to help track a visitor between clicks. The browser stores the message on the visitor’s local hard disk in a text file. The file contains information that identifies the user and their preferences or previous activities at that Web site. A Web server can gain valuable information about you, but although it can read the cookie, that does not mean that the Web server can necessarily read the files on your hard disk.
Q: Do all buffer overflow vulnerabilities lead to privileged remote code execution which can allow an attacker to compromise a computer?
A: Not all buffer overflow vulnerabilities can result in privileged code execution (administrator level permission within the operating system). Depending on the application and the nature of the buffer overflow vulnerability it is possible that the only payload available to an attacker who successfully exploits a BO vulnerability is to cause a DoS condition. Other possible pay-loads are information disclosure, nonprivileged code execution which allows the code to be executed within the context of the vulnerable application or interactively logged in user account.
Q: Whose job is it to implement cookie-related security—the Web user or the Web application developer?
A: It is the Web application developer’s job to ensure that the cookie is not storing sensitive plain text information within the cookie and the actions of the cookie. However, not all Web application developers follow this principle; therefore, as a Web site user you should ensure that you implement browser-based cookie controls such as ensuring only cookies are received from the site you are visiting and that you should be prompted to alert you when cookies are being written to your computer and what the contents of these cookies are.
1. A user contacts you with concerns over cookies found on their hard disk. The user visited a banking site several months ago, and when filling out a form on the site, provided some personal information that was saved to a cookie. Even though this was months ago, when the user returned to the site, it displayed his name and other information on the Web page. This led the user to check his computer, and find that the cookie created months ago is still on the hard disk of his computer. What type of cookie is this?
A. Temporary
B. Session
C. Persistent
D. Tracking
2. Your company has recently installed IM software on computers throughout the network, to encourage better communication between departments. A user on a network has installed a packet sniffer, and is using it to attempt viewing IMs transmitted between users of the network. When the packet sniffer captures one of the packets from an IM session, which of the following will occur?
A. The information from the IM session can’t be viewed because it is encrypted.
B. The information from the IM session can be viewed because it is sent as cleartext.
C. The message will be unreadable because IM only allows small messages to be sent, meaning that the entire message will be split between numerous packets.
D. The message will be unreadable because the Short Message Service (SMS) Center automatically encrypts every message sent over SMS.
3. Which layer of the OSI model is the target of most Internet-based attacks?
A. The network layer directly above the data link layer
B. The session layer directly above the transport layer
C. The application layer directly above the session layer
D. The application layer directly above the presentation layer
4. What does the term drive-by-download refer to?
A. Downloading Trojans from P2P networks
B. Downloading Trojans from instant messaging applications
C. Downloading mail attachments via an open mail relay
D. Navigating to a Web site and having malicious code auto execute without your knowledge
5. Cookie security is truly only at the mercy of the Web site administrator. Is this statement true or false?
6. Proper input validation should include which of the following checks? (Select all that apply)
A. Data type
B. Data length
C. IP address of data transmission
D. Name of the user submitting the data
E. Range of values
7. If P2P networks are to be used on corporate networks, which of the following steps does the best job of securing it?
A. Configure P2P client to share files within a single directory and install an antivirus client on all the computers running P2P software
B. Disable any open mail relays that are accessible from P2P clients
C. Disable ActiveX, Java, and scripting within users’ Web browsers
D. Disable any IM clients installed on the P2P clients
8. Monday morning has brought news that your company’s e-mail has been blacklisted by many ISPs. Somehow your e-mail servers were used to spread spam. What most likely went wrong?
A. An insecure e-mail account was hacked
B. Sendmail vulnerability
C. Open mail relay
D. Port 25 was left open
9. Your developer contacts you for guidance on how to secure ActiveX controls he or she plans on using within his Web application. What advice would you provide him?
A. Ensure to follow secure coding practices and sign the control before publishing
B. Only transfer the control over SSL sessions to and from the Web browser
C. Write the ActiveX control within Java
D. Perform a Threat Model on the ActiveX control
10. Multiple user laptops have been compromised due to exploitation of vulnerabilities in Java applets downloaded from third parties. What should you do to secure Java and help prevent further security incidents from recurring? (Select the best answer)
A. Install the latest patches for all employee computers
B. Install the latest patches for all employee computers and ensure employees only visit sites with proper input validation
C. Install the latest patches for all employee computers and use Internet Explore security zones to restrict the permissions of downloaded Java applets
D. Install the latest patches for all employee computers and use Internet Explore security zones to restrict the permissions of downloaded JavaScript
11. You are tasked with creating a threat model for a new application your company is developing. Who should you include in the threat modeling process?
A. A member of the corporate security team
B. Members of the security team and upper management
C. Members of the security team and middle management
D. Members of the security team and members from all teams responsible for the design and operation of the application
12. You perform a security assessment of your company’s Web server and identify a cross-site scripting vulnerability. What recommendation can you provide to your company to correct the vulnerability? (Choose the best answer)
A. Advise Web site users to ensure cookies are only transferred over secure connections
B. Implement a policy mandating that Web site users disable ActiveX support within their Web browsers
C. Implement a policy mandating that Web site users disable Java applet support within their Web browsers
D. Advise the Web administrator to ensure all Web application data inputs are validated prior to processing
13. You push out a security hardening policy to corporate users and later receive complaints from users stating that they can no longer view business Web sites. What element of your security hardening policy is most likely the cause of the issue?
A. Removal of open mail relays
B. Disabling of ActiveX controls and Java applets
C. Implementation of P2P client restrictions
D. Implementation of IM client filtering
14. Which of the following is not a phase within the threat modeling process?
A. Security objective definition
B. Application review
C. Application decomposition
D. Threat identification
E. Vulnerability identification
F. Application vulnerability scan
15. Bob is preparing to evaluate the security on his Windows XP computer and would like to harden the OS. He is concerned as there have been reports of buffer overflows. What would you suggest he do to reduce this risk?
A. Remove sample files
B. Upgrade his OS
C. Set appropriate permissions on files
D. Install the latest patches
1. C
2. B
3. D
4. D
5. False
6. A, B, and E
7. A
8. C
9. A
10. C
11. D
12. D
13. B
14. F
15. D
1. Symantec Report on the Underground Economy—Goods and Services Advertised [document on the Internet]. Cupertino, CA: Symantec Corporation; 26 November 2008 [cited 25 June 2009]. Available from https://forums2.symantec.com/t5/ISTR/Symantec-Report-on-the-Underground-Economy-Goods-and-Services/ba-p/368226.
2. Threat Risk Modeling [document on the Internet]. Columbia, MD: The Open Web Application Security Project (OWASP); 2009? [last modified 27 May 2009; cited 25 June 2009]. Available from www.owasp.org/index.php/Threat_Risk_Modeling#STRIDE.
3. SANS Top-20 2007 Security Risks (2007 Annual Update) [document on the Internet]. Bethesda, MD: The SANS (SysAdmin, Audit, Network, Security) Institute; 2007? [cited 25 June 2009]. Available from www.sans.org/top20/.
4. Top Ten Cyber Security Menaces for 2008 [document on the Internet]. Bethesda, MD: The SANS (SysAdmin, Audit, Network, Security) Institute; 2008? [cited 25 June 2009]. Available from www.sans.org/2008menaces/.
5. The Latest in the Threat Landscape—Web Based Attacks: February 2009 [document on the Internet]. Cupertino, CA: Symantec Corporation; 2009 [cited 25 June 2009]. Available from www.symantec.com/connect/articles/latest-threat-landscape-web-based-attacks-february-2009-0.
6. Microsoft Security Bulletin MS08-041—Critical: Vulnerability in the ActiveX Control for the Snapshot Viewer for Microsoft Access Could Allow Remote Code Execution (955617) [document on the Internet]. Redmond, WA: Microsoft Corporation; 12 August 2008 [updated 15 October 2008; cited 25 June 2009]. Available from www.microsoft.com/technet/security/bulletin/ms08-041.mspx.
7. Desiging Secure ActiveX Controls [document on the Microsoft Developer Network Web site]. Redmond, WA: Microsoft Corporation; 2009 [cited 25 June 2009]. Available from http://msdn.microsoft.com/en-us/library/aa752035(VS.85).aspx.
8. Symantec AutoFix Support Tool ActiveX Control Vulnerabilities [document number SYM08-009 on Symantec’s Web site]. Cupertino, CA: Symantec Corporation; 2 April 2008 [updated on 30 May 2008; cited on 25 June 2009]. Available from www.symantec.com/avcenter/security/Content/2008.04.02a.html.
9. Dormann, W. and Rafail, J. Securing Your Web Browser [document on the Internet]. Washington, D.C.: United States Computer Emergency Readiness Team (US-CERT); 23 January 2006 [updated 14 February 2008; cited 25 June 2009]. Available from www.us-cert.gov/reading_room/securing_browser/browser_security.html#Internet_Explorer.
10. National Cyber Alert System: Technical Cyber Security Alert TA08-340A: Sun Java Updates for Multiple Vulnerabilities [document on the Internet]. Washington, D.C.: United States Computer Emergency Readiness Team (US-CERT); 5 December 2008 [cited 25 June 2009]. Available from www.us-cert.gov/cas/techalerts/TA08-340A.html.
11. Secure Coding Guidelines Version 2.0 for the Java Programming Language [document on the Sun Developer Network]. Santa Clara, CA: Sun Microsystems, Inc. [cited 25 June 2009]. Available from http://java.sun.com/security/seccodeguide.html.
12. Vulnerability Note VU#788019: Adobe Reader and Adobe Acrobat contain an unspecified flaw in a JavaScript method [document on the Internet]. United States Computer Emergency Readiness Team (US-CERT); 25 June 2008 [updated 25 June 2008; cited 25 June 2009]. Available from www.kb.cert.org/vuls/id/788019.
13. Microsoft Security Bulletin MS08-022—Critical Vulnerability in VBScript and JScript Scripting Engines Could Allow Remote Code Execution (944338) [document on the Internet]. Redmond, WA: Microsoft; 8 April 2008 [updated 3 September 2008; cited 25 June 2009]. Available from www.microsoft.com/technet/security/bulletin/MS08-022.mspx.
14. Martin, B. Experts Announce Agreement on the 25 Most Dangerous Programming Errors—And How to Fix Them. Agreement Will Change How Organizations Buy Software [document on the Internet]. Bethesda, MD: The SANS (SysAdmin, Audit, Network, Security) Institute; 12 January 2009 [cited 25 June 2009]. Available from www.sans.org/top25errors/.
