Hacking: The Next Generation

Photo: OReilly

Photo: O'Reilly

My first book Hacking: The Next Generation is now available in electronic format. The physical version should be available on Amazon and in book stores in the next few days.

I want to thank Mike Loukides of O’Reilly, and my co-authors Billy Rios and Nitesh Dhanjani. A special thanks to Nitesh for providing me this opportunity.

Here is a description and the layout of the book. If you read the book please send me a shout-out on Twitter and let me know what you think, I would love to hear feedback.


With the advent of rich Internet applications, the explosion of social media, and the increased use of powerful cloud computing infrastructures, a new generation of attackers has added cunning new techniques to its arsenal. For anyone involved in defending an application or a network of systems, Hacking: The Next Generation is one of the few books to identify a variety of emerging attack vectors.

You’ll not only find valuable information on new hacks that attempt to exploit technical flaws, you’ll also learn how attackers take advantage of individuals via social networking sites, and abuse vulnerabilities in wireless technologies and cloud infrastructures. Written by seasoned Internet security professionals, this book helps you understand the motives and psychology of hackers behind these attacks, enabling you to better prepare and defend against them.

  • Learn how “inside out” techniques can poke holes into protected networks
  • Understand the new wave of “blended threats” that take advantage of multiple application vulnerabilities to steal corporate data
  • Recognize weaknesses in today’s powerful cloud infrastructures and how they can be exploited
  • Prevent attacks against the mobile workforce and their devices containing valuable data
  • Be aware of attacks via social networking sites to obtain confidential information from executives and their assistants
  • Get case studies that show how several layers of vulnerabilities can be used to compromise multinational corporations.

Chapter 1 – Intelligence Gathering: Peering Through the Windows to Your Organization

To successfully execute an attack against any given organization, the attacker must first perform reconnaissance to gather as much intelligence about the organization as possible. In this chapter, we look at traditional attack methods as well as how the new generation of attackers is able to leverage new technologies for information gathering.

Chapter 2 – Inside-Out Attacks: The Attacker Is the Insider

Not only does the popular perimeter-based approach to security provide little risk reduction today, but it is in fact contributing to an increased attack surface that criminals are using to launch potentially devastating attacks. 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 generally trusted with information that is confidential and critical to the organization.

Chapter 3 – The Way It Works: There Is No Patch

The protocols that support network communication, which are relied upon for the Internet to work, were not specifically designed with security in mind. In this chapter, we study why these protocols are weak and how attackers have and will continue to exploit them.

Chapter 4 – Blended Threats: When Applications Exploit Each Other

The amount of software installed on a modern computer system is staggering. With so many different software packages on a single machine, the complexity of managing the interactions between these software packages becomes increasingly complex. Complexity is the friend of the next-generation hacker. This chapter exposes the techniques used to pit software against software. We present the various blended threats and blended attacks so that you can gain some insight as to how these attacks are executed and the thought process behind blended exploitation.

Chapter 5 – Cloud Insecurity: Sharing the Cloud with Your Enemy

Cloud computing is seen as the next generation of computing. The benefits, cost savings, and business justifications for moving to a cloud-based environment are compelling. This chapter illustrates how next-generation hackers are positioning themselves to take advantage of and abuse cloud platforms, and includes tangible examples of vulnerabilities we have discovered in today’s popular cloud platforms.

Chapter 6 – Abusing Mobile Devices: Targeting Your Mobile Workforce

Today’s workforce is a mobile army, traveling to the customer and making business happen. The explosion of laptops, wireless networks, and powerful cell phones, coupled with the need to “get things done,” creates a perfect storm for the next-generation attacker. This chapter walks through some scenarios showing how the mobile workforce can be a prime target of attacks.

Chapter 7 – Infiltrating the Phishing Underground: Learning from Online Criminals?

Phishers are a unique bunch. They are a nuisance to businesses and legal authorities and can cause a significant amount of damage to a person’s financial reputation. In this chapter, we infiltrate and uncover this ecosystem so that we can shed some light on and advance our quest toward understanding this popular subset of the new generation of criminals.

Chapter 8 – Influencing Your Victims: Do What We Tell You, Please

The new generation of attackers doesn’t want to target only networks, operating systems, and applications. These attackers also want to target the people who have access to the data they want to get a hold of. It is sometimes easier for an attacker to get what she wants by influencing and manipulating a human being than it is to invest a lot of time finding and exploiting a technical vulnerability. In this chapter, we look at the crafty techniques attackers employ to discover information about people to influence them.

Chapter 9 – Hacking Executives: Can Your CEO Spot a Targeted Attack?

When attackers begin to focus their attacks on specific corporate individuals, executives often become the prime target. These are the “C Team” members of the company—for instance, chief executive officers, chief financial officers, and chief operating officers. Not only are these executives in higher income brackets than other potential targets, but also the value of the information on their laptops can rival the value of information in the corporation’s databases. This chapter walks through scenarios an attacker may use to target executives of large corporations.

Chapter 10 – Case Studies: Different Perspectives

This chapter presents two scenarios on how a determined hacker can cross-pollinate vulnerabilities from different processes, systems, and applications to compromise businesses and steal confidential data.

Understanding Cookies

Photo: Mrs. Magic

Photo: Mrs. Magic

When testing web applications, penetration testers should look at how the session is handled. Session management is commonly overlooked by developers and system administrators. It is so often overlooked that it is one of the OWASP Top 10, refereed to as “Broken Authentication and Session Management.”

This article will cover certain attributes that cookies typically have. In the future we will address how to use attribute tags to help aid developers in securing their applications. This article assumes the reader has a basic understanding of what a cookie is.

Here is a sample HTTP response. This is what the server responds with after a client request is made. The response has been edited for brevity.

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session=YnJldHQ6bXlwYXNzd29yZA==;expires=Thu, 30 Dec 2037 00:00:00 GMT;path=/;domain=.misc-security.com
Content-Length: 8400

For those unfamiliar with cookies, a cookie consists of a name/value pair. In this case the cookie name is “session” and the cookie value is “YnJldHQ6bXlwYXNzd29yZA==

Following the cookie name/value pair are the attribute/value pairs that apply to that cookie and are delimited with a semicolon. In this example their are three attribute/value pairs: expires, path, and domain.

Expires Attribute

expires=Thu, 30 Dec 2037 00:00:00 GMT

The expires attribute is used to tell the browser when the cookie should no longer be used. Browsers will cache this cookie locally until the expires date is reached. When the expires date is reached the browser will stop sending the cookie after the browser is closed. In our example the cookie will remain valid until December 30th, 2037.

Path Attribute


The Path attribute specifies the subset of URLs to which this cookie applies. In this case, the cookie will be sent for any request to this server. If a user requests /bobsapp/ or /tomsapp/ this cookie will be sent.

Domain Attribute


The Domain attribute specifies the domain for which the cookie is valid. An explicitly specified domain must always start with a dot. In our example, this cookie will be sent to misc-security.com and any sub-domains of misc-security.com (e.g. asparagus.misc-security.com).

In a future article we will continue looking at the attribute/value pairs that cookies can have and will even revisit these attributes explaining how each needs to be understood to securely handle a user’s session.

Further Reading:

RFC 2109 – HTTP State Management Mechanism
RFC 2965 – HTTP State Management Mechanism (New Version)

A Closer Look at the Twitter-Controlled Botnet

Photo: Don Solo

Photo: Don Solo

Today, I have asked Paul Makowski, a fellow security researcher, to write up a detailed post regarding the recently discovered botnet being controlled through Twitter. What I love about this article is how in depth Paul actually dug regarding this botnet – He actually had to break up the post into two separate posts.

This is only part one. In part one, Pual explains how he gets the malware, decodes, and scans it. In part two, Paul will delve into dissecting the malware and making sense of what it does.

Update: The mirrored malware links have been removed.

A Closer Look at the Twitter-Controlled Botnet (Part 1)


I wasn’t aware of Jose Nazario’s post concerning this topic while I was conducting this research; I had only been exposed to the Wired Threat Level article prior to researching. So while I present some of the same information as Jose, this duplication of information only came to my attention afterwords.

If you’ve read Jose’s post, this post may still be worth the read for several reasons:

  • Jose and I differed on some of the tools & techniques used.
  • I attempt to offer a more detailed description of my methods/logic as a pseudo-tutorial.
  • I mirror all the necessary info so the readers can do this themselves.
  • There’s a quick discussion on some malware I found hosted at ubuntu.com (Jose probably saw it too but didn’t mention it) as well as a possible lead to a very sloppy botnet master.

Getting the Malware:

I was reading some feeds on Friday (Aug 14th) and came across Wired’s article on outsourcing botnet C&C (command & control) to Twitter. What caught my eye wasn’t so much the article itself but the screenshot accompanying the article. Many times when major outlets report on botnet/worms/virii/etc, crucial details are left out either intentionally (to protect the innocent) or accidentally. This was not the case with this article.

Paul Makowski

Paul Makowski

I immediately recognized the tweets in the above screenshot as being base64 encoded. Furthermore, all of the posts started with the same 18 characters, indicating to me that these are not encrypted nor obfuscated beyond the simple base64 encoding. Perhaps the botnet herders are using Robin Wood’s KreiosC2 for nefarious purposes? This is evidence for a fairly unsophisticated botnet herder.

I transcribed the messages captured in the screenshot and decoded them in order from most recent to least recent. Some contained what appeared to be multiple links (redirections valid as of Aug 14th, 2009):


http://bit.ly/17a3tS (malware)

|_ http://rifers.org/paste/content/paste/9509/body?key=upd4t3


http://bit.ly/LOfRO (malware)

|_ http://rifers.org/paste/content/paste/9508/body?key=upd4t3

http://bit.ly/Img (unrelated?)

|_ http://www.friedbeef.com/save-time-on-your-spreadsheets-asap-utilities/


http://bit.ly/17l4Fa (malware)

|_ http://rifers.org/paste/content/paste/9507/body?key=upd4t3

http://bit.ly/1 (unrelated?)

|_ http://www.blogger.com/profile/09172993341866649612


http://bit.ly/pmSuc (malware)

|_ http://paste.ubuntu.com/252515/plain/

http://bit.ly/17 (unrelated?)

|_ http://www.17tech.com/soft/index.shtml


http://bit.ly/GhuUu (malware)

|_ http://rifers.org/paste/content/paste/9506/body

http://bit.ly/Qj (unrelated?)

|_ http://nossacamiseta.net/product_info.php/products_id/564


http://bit.ly/QjAZY (dead link)

|_ http://paste.debian.net/44059/download/44059


http://bit.ly/7PaD9 (dead link)

|_ http://paste.debian.net/44056/download/44056


http://bit.ly/3RwAN (dead link)

|_ http://pastebin.com/pastebin.php?dl=m49f3b4c2

http://bit.ly/2pS (unrelated?)

|_ http://friendfeed.com/koltregaskes/6c53228d/twine_official-i-ll-e-mail-straight-away-any

There’s several interesting items here, in no particular order:

  1. It appears as though Debian is better at proactively moderating these type of posts than Ubuntu is (all the Debian links were dead when I tried them but the Ubuntu link worked fine). In Ubuntu’s defense, however, the offending links were killed within an hour of me notifying them.
  2. Payloads are being pushed out in rapid succession to both the C&C venues (Twitter, Jaiku, Tumblr, etc) and the payload hosting sites, indicating that this process has been automated. Automated payload deployment was determined by looking at some of the URLs linked in the Twitter screenshot:





    It can be deduced from these URLs that malware was uploaded to rifers.org in a short enough time period to warrant consecutive numbers. Furthermore, it is clear that whoever controlled the Twitter C&C made these uploads as well, judging by the upd4t3 handle present across services.

  3. All the Twitter posts that included two redirect URLs appear to have a nonsense link as the second URL. If anyone has a theory as to the purpose of these secondary links, please leave a comment or shoot me an email @ my[remove_this].hndl@gmail.com
  4. The botnet herder’s name is Rafael? I took another look at the malware hosted at Ubuntu and removing the plain/:
  5. http://paste.ubuntu.com/252515/ (mirror)

Decoding the Malware:

Get the base64 samples. [Link Redacted]

Turning these base64 strings into something meaningful was more involved than simply decoding them. Still, the first step was to decode them. For that I wrote a little Python script. (I’m new to Python and figured this would be a simple exercise. It was.)

# decodes base64 files

# (C) 2009 Paul Makowski. GPLv2.

# usage: python /b64_decode.py (encoded_file) (output_file)

import base64

import sys

encodedFile = sys.argv[1]

outputFile = sys.argv[2]

encodedFileHndl = open(encodedFile,”r”)

outputFileHndl = open(outputFile, “w”)




After decoding the malware I now had 5 files and named them after their URLs: 9506, 9507, 9508, 9509 & 252515.

I ran an md5 on all of them (I used OS X… it would be md5sum in Linux):

$ md5 *.base64

MD5 (252515.base64) = a5f84f74cf9aa832355d5cd558cbfca6

MD5 (9506.base64) = 7743eac81be2b803093a6277323f17cb

MD5 (9507.base64) = a5f84f74cf9aa832355d5cd558cbfca6

MD5 (9508.base64) = a5051a6e5365bdc4dd8267e62d3e2902

MD5 (9509.base64) = 1a81e69e65b75f8b9e72e94c6f86a52b

As you can see, payloads 9507 from rifers.org and 252515 from ubuntu.com are actually the same payload. (Yes I know about md5 collisions…but there’s very little point to messing with the hashes in this scenario.)

So now we’ve narrowed down the available payloads to 4: 9506 through 9509. I named these 9506.bin through 9509.bin (since at this point I didn’t know their true filetype).

Making Sense of the Malware:

The first thing I tried after I de-base64′ed the payloads was to take a look at them with a hex editor. Being on OS X, I used Hex Fiend (if I were on Windows, I’d use WinHex; Linux I’d use hexedit):

Hex Fiend

Hex Fiend

I took note of two items:

  1. This is not a Windows executable; this is a .zip file. I determined this by the magic number at the beginning of the file (seen above). PK means zip; MZ (or ZM) means Windows PE.file verified these findings:

    $ file 950*.bin

    9506.bin: Zip archive data, at least v2.0 to extract

    9507_252515.bin: Zip archive data, at least v2.0 to extract

    9508.bin: Zip archive data, at least v2.0 to extract

    9509.bin: Zip archive data, at least v2.0 to extract

  2. There’s a file called gbpm.dll inside the archive. At the bottom of the binary (not shown), is another string that reads gbpm.exe. This also turned out to be a file in the archive.

All of the other payloads appeared the same way under a hex editor. I renamed them all from *.bin to *.zip and unzipped them.

Now I had four folders, each containing a unique gdpm.dll and gdpm.exe. I renamed all the gdpm.exes to gdpm.livemalware so I wouldn’t accidentally execute them on my Windows box.

I checked the md5s to see if any were duplicates:

$ md5 950*/*.dll && md5 950*/*.livemalware

MD5 (9506/gbpm.dll) = 0dc041988367e4ca0faa1f119c748efb

MD5 (9507_252515/gbpm.dll) = 6cd9ee23dedf7c6a53668a7c4f830d78

MD5 (9508/gbpm.dll) = 1a1b3c05470ea788a86c4b9ed5c9b28f

MD5 (9509/gbpm.dll) = b15df1614d09ebb7b15d04ce914ee05f

MD5 (9506/gbpm.livemalware) = 4c537d461490ac998256c6deca11eeb4

MD5 (9507_252515/gbpm.livemalware) = 359ca7a025c3fe3cb7f60a3dd8ff4478

MD5 (9508/gbpm.livemalware) = b3a7f3145dc93e8721a4078f5e32fb44

MD5 (9509/gbpm.livemalware) = 08b05a33c6a989cc9c3f0a0918afa943

None were the same – I have 4 different pairs of malware samples 🙂

I uploaded the files to Virustotal to see if any were recognized. AV detection was poor to say the least (not that I’m surprised):

9506/gbpm.dll (4/41 antivirus detection) (new file)

9506/gbpm.exe (11/39 antivirus detection) (new file)

9507_252515/gbpm.dll (4/41 antivirus detection) (new file)

9507_252515/gbpm.exe (13/39 antivirus detection)

9508/gbpm.dll (5/41 antivirus detection)

9508/gbpm.exe (13/39 antivirus detection)

9509/gbpm.dll (6/41 antivirus detection)

9509/gbpm.exe (8/41 antivirus detection)

The files marked new file had not been seen by Virustotal previously. All .dlls had a fairly low detection rate. That combined with the fact that some had not been seen by Virustotal previously reminds me of PandaLabs recent press release on virii only being useful for 24 hours.

So what kind of malware do we have anyways? Virustotal points toward Eldorado or Svelta for some files. Jose says in his post that these aren’t the botnet control agents, but are additional feature-adding payloads. Perhaps this means keyloggers, DDoS tools, etc?

Note: The domains found hosting malware have been notified (Ubuntu, rifers.org). The malware has been taken down from these sites in order to prevent further propagation, but is offered below in a password protected archive for the reader to practice on.

Information Leakage and Improper Error Handling

Photo: Andres Rueda

Photo: Andres Ruedahis

This is the sixth-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What is Information Leakage and Improper Error Handling

Information leakage and improper error handling happen when web applications do not limit the amount of information they return to their users. A classic example of improper error handling is when an application doesn’t sanitize SQL error messages that are returned to the user. Upon receiving a SQL error message an attacker will immediately identify a place for identifying injection flaws.

Although preventing error messages from reaching users will not prevent vulnerabilities from occurring, it does make it difficult for an attacker to accomplish his goal and it is also an industry best practice.

An Example of Information Leakage

Common examples of information leakage include helpful error messages and service banners. Developers and system administrators often forget or disregard how something as simple as a server banner can be used by an attacker.

As an example, if your server is running Apache and you return the server header with your responses, an attacker could leverage this to fingerprint the version of the web server you are running.

Using nmap an attacker could send a few packets at your application server using the command, nmap -sV -p 80 and identify the following:

Interesting ports on
80/tcp  open  http     Apache httpd 1.3.37

The attacker has now identified your Apache version and can now search for vulnerabilities affecting that version of Apache.

An Example of Improper Error Handling

Attackers attempt to leverage information that applications freely volunteer. If an application displays an error messages to the user (attacker), there is not guarantee that the user will “ignore” this error message.

Developers typically forget to properly handle their error messages. Stack traces and SQL errors are two examples of very commonly forgotten errors that should be handled.

Attackers love seeing error messages such as:

ERROR:  unterminated quoted string at or near "'''"

How Do You Prevent Information Leakage and Improper Error Handling

When developing applications, developers should assume all of the users are hostile. As a developer having this mentality will greatly aid you in developing secure applications.

All information returned from a web server should be reviewed for potential leakage. This can be automated by a QA team using a fuzzer.

Developers should also use a standard exception handling architecture to prevent information leakage from occurring. This architecture should be used and shared across the entire development team. All developers should handle their errors the same way.

Developers or product managers may also decide to create a default error handler which returns sanitized error messages for most users in production for all error paths. Doing this will greatly reduce the attack surface that can be exploited through error message generation.

Cross-Site Request Forgery (CSRF)

Photo: Joe Penniston

Photo: Joe Penniston

This is the fifth-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What is Cross-Site Request Forgery (CSRF)

Cross-Site request forgery is a client-side vulnerability that allows an attacker to make requests on the user’s behalf. Although, most CSRF exploits require a user to be authenticated to the susceptible site to be successful, this is not always the case.

An Example of Cross-Site Request Forgery

A user (victim) opens their browser and logs on to their online banking application located at http://bank.com

After checking their balance they browse away from the site (without logging off) and start reading web pages about olives from Madagascar. One of these olive sites is owned by an attacker. The attacker’s website has the following img src tag:

<img src="http://bank.com/transfer.asp?to_acct=445544&amount=1000">

When the victim’s browser loads the malicious page that contains this img src tag, the victims browser makes the transfer request (/transfer.asp?to_acct=445544&amount=1000) to bank.com using the authenticated cookie from the earlier session. Upon making this request, the bank then transfers $1,000 from the victim’s account to account 445544. The attacker has now successfully executed a cross-site request forgery attack against a user of bank.com

How Do You Prevent Cross-Site Request Forgery

Any sensitive request that is generated by the user should force the user to “re-authenticate.” A simple example is that of change password functionality. You always want to verify the user knows the old password before changing their password, even if they are currently authenticated.

If you determine that “re-authentication” may be an inconvenience for the user or if all of your requests are considered sensitive then the application developers should include a random token that is unique to the user session. This token should not be present in the cookie, but rather as a hidden field in the HTML and then appended to the URL during any form submission.

When the attacker attempts to trick the users browser into making a request, the web application will look for this random token. The random token will not exist for the request, and the request will be denied. This prevents the CSRF attack from being successful.

Note: Having SSL does not protect your application from CSRF vulnerabilities.

Insecure Direct Object Reference

Photo: tim_norris

Photo: tim_norris

This is the fourth-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What is Insecure Direct Object Reference

Insecure Direct Object Reference is when a web application exposes an internal implementation object to the user. Some examples of internal implementation objects are database records, URLs, or files.

An attacker can modify the internal implementation object in an attempt to abuse the access controls on this object. When the attacker does this they may have the ability to access functionality that the developer didn’t intend to expose access to.

Examples of Insecure Direct Object Reference

Insecure direct object reference is a very broad category of vulnerabilities. There are many examples of these types of vulnerabilities found in the wild by other names. Open Redirects and Directory Traversal are two classic examples of an insecure direct object reference vulnerability.

Open Redirect

This is where the web application has a parameter that allows the website to redirect the user somewhere else. If this parameter is not implemented properly using a white list, attackers can use this in a phishing attack to lure potential victims to a site of their choosing. More information about Open Redirects can be found here.

Directory Traversal

Assume a web application allows for a file to be rendered to a user that is stored on the local machine. If the application isn’t verifying what files should be accessed, an attacker can request other files on the file system and those will also be displayed.

For instance, if the attacker notices the URL:


The attacker could modify the file parameter using a directory traversal attack. He modifies the URL to:


Upon doing this the /etc/shadow file is returned and rendered by file.jsp demonstrating the page is susceptible to a directory traversal attack.

How Do You Prevent Insecure Direct Object Reference From Occurring in Your Application
As always, web application developers can prevent these attacks through good planning.

Developers should use indirect reference maps. Direct mapping can easily be guessed by attackers. Developers should avoid exposing private objects to users. File names, external/internal URL’s, and database keys are all examples of things that should not be displayed to the user.

If direct objects must be used, then the developers should ensure through validation that the user is authorized to view what they are attempting to access. In the directory traversal example, determine what files the user should access and only grant them privileges to those files. This is known as an “accept known good” approach and is always a good idea when it comes to developing secure applications.