Blind Fury: An Alternate Web App Fingerprinting Technique

Web app fingerprinting attempts to identify the type and version of frameworks installed on a web site. Knowledge of frameworks and their version helps determine whether a site has kept up to date with security patches. Accurate fingerprinting can be more efficient and less intrusive than blackbox vulnerability scanning for identifying potential vulnerabilities.

Traditional approaches to fingerprinting web applications rely on brute force enumeration of pages, scraping content with regexes, or hybrids of the two. These are suboptimal. Page enumeration is bandwidth-intensive. Its accuracy falls when “install” files are removed or pages are minified. Regexes are prone to errors of matching incorrect content or are defeated by simple site modification (such as removing <meta> content). These techniques tend to identify the presence of pages on a site, but do not indicate whether the files are actually used of the application.

Blind Fury uses a new approach that does not rely on page enumeration or regexes. Yet it is still able to identify several popular frameworks. In fact, the technique can be extended to generate fingerprints for almost any type of web site. It can create and analyze fingerprints from a completely blackbox perspective; it does not require prior knowledge of a target’s directory structure.

If you love Rutger Hauer movies, vote for Blind Fury.

Fear not, regardless of the outcome of voting, I’ll be posting more about it at the end of the month.

p.s. Regular visitors may have noticed that the site has moved to WordPress.com from Blogger (saying good-bye to negative privacy and policy changes). The only drawback so far is that some of the archive links are broken because they were originally saved as year/month rather than year/month/day. All of the content remains, just under a slightly different link.

To set the stage, no one on the list is arguing in bad faith. If you’d prefer the troll-baiting titillation of he said/she said threads, look elsewhere. Never the less, keep reading here and you’ll be rewarded with a pontifical comment or two.

So, back to Google’s desire to include VBScript to the WebKit browser engine. I mean Dart; I believe they call it Dart because four fewer letters improves efficiency. The basic idea is that JavaScript is nice, but insufficient to fully replicate certain kinds of desktop apps. For example, JavaScript becomes creaky if you push it to handle anything associated with frame rates — namely games.

There’s clearly self-interest in improving browser computing if your entire platform relies on the browser. For starters, you want a browser that won’t have ad-blocking on by default. And you’ll want to smooth out the wrinkles of something like a Do Not Track header.^1,2 Sometimes, it’s even convenient to get other browsers, say Internet Explorer, to catch up on technology by plugging your own browser into them.³ (Never mind the implications of a browser in a browser.^4,5) That brouhaha of 2009 enabled users to experience brave, new products with their Chrome/IE chimera — which in hindsight must have been necessary since the product was no longer around by the time IE caught up on HTML5.⁶

But all of that avoids the fact that JavaScript isn’t perfect. Enter Dart, accompanied by tweaks that make it more bare-metal-compiler friendly

On the other hand, maybe JavaScript (ahem, the ECMAScript standard) just needs its own tweaking to enable performance gains.^7,8 And while we’re on this JavaScript tirade, why not throw improve our privacy with some crypto-related capabilities rather than start over with VBDart?⁹

ECMADart isn’t Google’s sole flirtation with browser extensions. Google also wants to reinvent ActiveX in the form of a plugin called NaCl.¹⁰ NaCl is a sort of the arterial bypass of JavaScript in that it provides a way to execute native code (C or C++) in your browser. Instead of relying on the non-standard closed sandbox plugins like Flash or Silverlight you can rely on the non-standard open source sandbox plugin of NaCl.

Words That Start With E

Understand first that reinvention intends to improve upon the original. Hollywood likes to call this “rebooting” a franchise. This brings us cool Batman movies. At the price of yet another Batman movie. Or yet another Superman. Or Spiderman. (Hey, Star Trek was pretty awesome so reboots aren’t out-of-hand a bad idea.) Yet this pushes other, fresher ideas out of the way. In web terms, those other, fresher ideas involve developers embracing HTML5 and JavaScript as the standard deployment model for web apps rather than coding to browser quirks or throwing Flash-driven menus everywhere.

Now fill in the blank: Reinventing a technology is a great way to [ ____ ]

• Learn from sins of the past
• Remember history and not repeat it
• Forget history and repeat it
• “Embrace, extend, and extinguish” competing standards¹¹

Even desultory readers should notice the biased presentation of choices: Three phrases of cliched meaninglessness and one possibly-too-subtle allusion to the dark times of an almost two decade-old past. It wasn’t until the late 90′s when a Rolling Stones‘ song first graced a t.v. commercial. Their song, “Start Me Up,” played over an ad (this is the dark times part) for Microsoft — the company that created the “embrace, extend, and extinguish” strategy to give Internet Explorer dominance in the browser market.

One great way to embrace and extend is to provide New! Cool! features that work great in one browser, but degrade or don’t exist in any other. A new scripting language is one way to do that, even if it’s as useful as VBDript. To be fair, plugins like Flash and Silverlight need to be pulled into this category. Java counts as cross-platform, but when was the last time you used a Java app in your browser? When was the last time a hacker did? (Hint: Probably more recently than you think.)¹²

Stepping outside of boundaries isn’t always bad. After all, a foundation of the modern web, the XMLHttpRequest object, arose from an IE-only extension.¹³ A detraction further compounded by requiring ActiveX. XHR’s adoption into the W3C standards was both acknowledgement of the feature’s widely recognized utility as well as the desire to make the feature equal among all browsers.

All You Need is <!doctype html>

Maybe everything doesn’t have to go into the browser. Yes, I can think of a few reasons why App stores (trademarked ones and not) equally threaten divergence and uncrossable platforms. But at least consider the app+device duo has a better security model than the browser. The browser’s model is mostly a Same Origin Policy affair, whereas you ostensibly have to approve and acknowledge certain behaviors for your sandboxed app.

The worst thing you can do is sign up to the WebKit developers list in order to spam it with flaming, troll-ridden diatribes for or against JavaDart. Let engineers more involved in the browser sausage making sort it out with their constructive conversation.

The best thing you can do is continue to create cool web sites with technology that works in every browser: HTML5 and JavaScript. Let the annoying litter of the Web’s past (pop-up windows, scrolling marquees, even Flash has a terminal diagnosis by now) scatter in what the Scorpions so awesomely sung as the “Wind of Change.”

=====
[1] http://googlepublicpolicy.blogspot.com/2011/01/keep-your-opt-outs.html
[2] http://www.w3.org/Submission/web-tracking-protection/
[3] http://arstechnica.com/open-source/news/2009/09/google-brings-chromes-renderer-to-ie-with-browser-plugin.ars
[4] http://shaver.off.net/diary/2009/09/28/thoughts-on-chrome-frame/
[5] http://blog.lizardwrangler.com/2009/09/28/browser-soup-and-chrome-frame/
[6] http://googlewave.blogspot.com/2011/11/final-steps-for-google-wave.html
[7] http://www.ecmascript.org/
[8] http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-ecmascript.aspx
[9] https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
[10] http://www.chromium.org/nativeclient
[11] http://www.economist.com/node/298112?Story_ID=298112
[12] http://blogs.technet.com/b/mmpc/archive/2010/10/18/have-you-checked-the-java.aspx
[13] http://support.microsoft.com/kb/285081

1. Software execution is less secure than software design, but running code has more users.
2. The time saved by not using parameterized queries to build SQL statements should be used to read about using parameterized queries.
3. Same Origin Policy restricts the DOM access and JavaScript behavior of content loaded from multiple origins. Malware only cares about plugin and browser versions.
4. Content like XSS exploits are affected by the Same Origin Policy, which is nice for XSS attacks that inject into the site’s origin.
5. CSRF countermeasures like Origin headers mitigate CSRF, not XSS. Just like X-Frame-Options mitigates clickjacking, not XSS.
6. Making data safe for serialization with JSON does not make the data safe for the site.
7. There are four XSS vulns in your site today. Hackers will find two of them, the security team will find one, the dev team will introduce another one tomorrow.
8. Blacklists miss the payload syntax that works.
9. A site that secures user data still needs to work on the privacy of user data.
10. Hashing passwords with 1000-round PBKDF2 increases the work factor to brute force the login page by a factor of 1. Increasing this to a 10,000-round PBKDF2 scheme provides an additional increase by a factor of 1.
11. The vulnerabilities in “web 2.0″ sites occur against the same HTML and JavaScript capabilities of “web 1.0″ sites. HTML5 makes this different in the same way.
12. A site is secure when a compromise can be detected, defined, and fixed with minimal effort and users are notified about it.
13. Off-by-one errors only happen in C.

Enjoy. And stick around for (the not quite yet imminent arrival of) new content. Thanks for reading!

CSRF detection definitely falls into the “hard” category of automation. The Book discusses CSRF in Chapter 2. You may also be interested in reading the excellent Stanford Web Security Research papers on the topic.²

CSRF is a complex topic that engenders a lot of strong opinions on risk, exploitation, and what constitutes a vuln. A few months ago I wrote on the broader aspects of web security and how they do or do not relate to CSRF.

Since July was a rather dry period for updates here, I’ll take August to dive into some of the ways automated CSRF detection succeeds and which approaches are doomed to fail.

=====

1 https://community.qualys.com/blogs/securitylabs/2011/08/10/the-was-approach-to-csrf
2 http://seclab.stanford.edu/websec/csrf/
3 http://www.deadliestwebattacks.com/2011/04/csrf-and-beyond.html

Last week I answered a call on my work phone whose caller ID showed “unknown”. I’m already predisposed to ignore such calls because of telemarketing. However I can imagine some situations where one of our customers’ phone exchanges would not appear on caller ID. So I answer.

A man politely informs me that he needs to confirm my email address in order to send me a tracking number for a FedEx package. I prefer to think that I’m a suspicious person rather than a cynical one. This statement was immediately suspicious because it was an out-of-the-blue attempt to extract information from me and I rarely receive packages. To be clear, my work email address is trivial to find (as apparently is my phone number). In fact, the caller had the correct email address. He only wanted me to confirm it.

I evaded acknowledging the email address which led the caller¹ to assert that the package couldn’t be sent without giving me a tracking number. Here he also tried to deflect my suspicion by mentioning that the package was from Chase Bank. And it was to be delivered tomorrow, but I needed to confirm my email so “They” could send me the tracking number.

I mentioned that I was confused why the package couldn’t arrive unless the tracking number was acknowledged. A little earlier in the conversation I had asked the caller’s name. He replied, “Jason.” Now I asked another question, “Could you tell me who the sender is?” After all, maybe I’m being overly cautious and Chase Bank wants to send me lots of cash for some reason.

The answer was even more telling, “We don’t have access to that data. For privacy reasons.” Even though the package was apparently coming from Chase, I was being told that the sender’s information was obscured from this poor FedEx rep’s view. Giving me a somewhat contradictory explanation doesn’t build my confidence in the goal of this call.

By now I was explaining that if the package doesn’t arrive because I refused to acknowledge my email address then I was sure the sender would deal with the problem. The caller made a final effort at confirmation, at which point I said something along the lines of, “Send an email if you want, but I’m not going to look at it. We’ll see if a package arrives.”

There’s potential for fun to be had with turning the tables on cons and phone phishing attempts like this. Yet the call was grating and it was time to hang up. Neither email nor package arrived. Quelle surprise.

I can only speculate on the ultimate goal of this phishing attempt, but I suspect the immediate objective was to soothe any suspicions about receiving an unsolicited “Fedex package tracking” link so that I’d click on it. I would probably also have been reminded to check my spam folder in case the email was accidentally marked as spam. A link, of course, leading to a site laced with malware that would like nothing else than to infect my already abysmally slow desktop.

The simplest, most straight-forward way to end the call could have been, “I have a pen and paper right here. You can just give me the number now.” This would not only have called the bluff, but might have provided brief entertainment as the caller tries to make up an excuse for not being able to give the number over the phone or lamely creates a number on the fly.

There are some very basic things you can do to possibly foil a social engineering attempt or build confidence in the claims of an unsolicited caller. The easiest step is to politely ask simple questions:

• What’s your name? On who’s behalf are you calling?
• Do you have a number I where can call you back?

If you’re confused about something or a statement seems odd, ask for clarification. Social engineering usually relies on the human characteristics of greed or the desire to be helpful. You don’t need to counter a possible attack by being rude or belligerent (although it probably helps to not be greedy). After all, someone may be calling for good reason.

Good questions might fluster the attacker or further erode your trust in the call. However, there’s always the chance that answers will seem reasonable. In any case, you can always report suspicious calls to your IT or security department. That way you can help them identify a trend or to be more vigilant for certain activity. You probably don’t want to be the reason your company’s passwords, source code, or financials appear on a peer-to-peer file sharing network.

=====

1 I’m being nice by referring to him as “caller”. Unethical jerk is merely the tip of the iceberg of more suitable names.

Choose an established, vetted algorithm (SHA-256 would suffice), include a salt (we’ll explain this a bit later), hash the password. Get rid of the plaintext password. Done. See how simple that was? There’s even Open Source code⁴ to help you with more complex issues.

But once you’ve set foot on the path of hashing passwords you might be tempted to make the hash Even Better. An apparently common idea is that if you hash a password once, hashing it twice makes it more secure. Being “more secure” is a commendable goal, but beware the wild beasts of cryptography, for they are subtle and quick to…well, you should be able to finish that thought.⁵

Repeating encryption or hashing algorithm isn’t a bad idea, it’s just not fully thought-through idea. First, we need a paragraph or three to catch everyone up on hashing and brute force attacks:

A cryptographic hash function takes an arbitrary-length input and produces a fixed-length output that has no statistical relation to the input. Consequently, a password like friend becomes an unintelligible string like 97823jnsndf234.⁶ An important property of a cryptographic hash function is that it’s irreversible (information is lost, similar to a lossy compression algorithm). No algorithm exists to turn the output 97823jnsndf234 back into friend. Alternately, an encryption function turns friend into mellon and if you know the encryption scheme and a key, then you know how to turn mellon back into friend. AES is an example of an encryption function.

Cracking a hashed password requires effort on the part of the attacker. This effort, or work factor, represents the time to execute a single hash function multiplied by the expected number of guesses required to find the correct input to the hash function. For example, an attacker might try all six-letter strings such as friena, frienb, frienc until finally hashing the guess of friend and observing that the output matches the reference hash, 97823jnsndf234.

Trying all six-letter lowercase combinations of the English alphabet requires 308,915,776 guesses (26 characters to the 6^th power). This is actually a relatively small number in the age of multi-core behemoths and GPU trickery. If a single hash function takes 1 microsecond to execute on a particular system, then the complete brute force will take about 5 minutes. If you pass each input through the hash function N times, then you increase the work factor by N. With N = 100 the six-character attack would take close to 9 hours. The attacker is going to get the password eventually, but now it will take N times longer.

Notice that the previous equation only cared about the time required to execute a single hash function. From this perspective it doesn’t matter if the hash algorithm produces a 128 bit or 512 bit output. It only matters how long it takes to obtain the output. (We’re only talking about hashing and repeated hashing here; bit lengths and algorithm selection still have important security implications for other reasons and against other attacks.)

Here is a simplified explanation of how a repeated hash function fails to universally improve the work factor to brute force a value. The input plaintexts are marked P (with Greek letter subscripts). This brief examples uses 10 iterations of a lossy hash function. The output of each intermediate hash is marked H with a numeric subscript. The final hash iteration is marked C with a subscript corresponding to the original plaintext.

The following line shows how the final value for an input plaintext is achieved:

P_α -> H₁ -> H₂ -> H₃ -> H₄ -> H₅ -> H₆ -> H₇ -> H₈ -> H₉ -> C_α

A different input should produce a different final value:

P_β -> H₄₃ -> H₄₄ -> H₄₅ -> H₄₆ -> H₄₇ -> H₄₈ -> H₄₉ -> C_β

A problem occurs when the original plaintext has a collision with one of the intermediate or final hash values. For example, what if P_γ and H₇ have the same result when passed into the hash function? You have an overlapping sequence from the end of P_α’s chain:

P_γ -> H₈ -> H₉ -> H₁₀ -> H₁₁ -> H₁₂ -> H₁₃ -> H₁₄ -> H₁₅ -> H₁₆ -> C_γ

A more pathological case happens when a sequence overlaps significantly:

P_δ -> H₄₄ -> H₄₅ -> H₄₆ -> H₄₇ -> H₄₈ -> H₄₉ -> H₅₀ -> C_δ

The way an attacker would exploit these artifacts is by creating some chain reference tables, much like a rainbow table. Yet in this case, the chain reference is used to skip rounds. For example, given an input plaintext P_x, if the first hash round is H₁₃ and the table has a precomputed chain with an H₁₃ in it, then the attacker can fast-forward 10 steps (or however many steps have been precomputed) to get the C_x.

This case for this Time-Memory-Trade-Off (TMTO) attack chains didn’t present any math or probability calculations to back up these assertions. If you’re about to dismisse this attack based on the lack of hard evidence (in this article), consider something else about repeated rounds: they do not introduce additional entropy. Consequently, each round might actually weaken the entropy of the initial input despite the increased work factor due to additional rounds. In a worst case scenario, this dilution of entropy might lead to collisions that make a brute force search even easier.

Repeated hashing does not increase entropy (the “difficulty” of the initial password), it only increases the work factor. Repeated hashing of iloveyou doesn’t make the password any harder to guess, just longer to get there.

Think of it in terms of the attacker’s dictionary. The attacker has a pre-defined list of common passwords, from iloveyou to KAR120C. Neither the hashing algorithm nor the number of repetitions has any impact on this dictionary. Those only affect the amount of time required for the attacker to cycle through the dictionary.

The common theme for using cryptosystems is to first look for implementations that conform to a standard⁷ rather than creating something you think is new, novel, and unique.

In the case of repeated encryption, you should turn to RFC 2898 for the Password-Based Key Derivation Function 2 (PBKDF2).⁸ PBKDF2 inserts an iteration counter to prevent “chain” attacks. In other words, the attacker must perform every encryption stage. At a minimum, the iteration prevents the attacker from shortcutting rounds using a TMTO trick.

Where repeated rounds increase the attacker’s work factor, salts defeat other precomputation (a.k.a Rainbow table) attacks. A salt is merely a number of bytes (like a string, though it need not be) prefixed or suffixed to a password.

Salting passwords affects the composition of the attacker’s dictionary. Rather than trying the password me+galadriel the attacker must include a salt, which makes it somethinglongbefore-me+galadriel. Salts don’t make the dictionary bigger, they make the dictionary specific to the salt. The idea here is that all of the effort put forth to crack a password with a particular salt cannot be reused to crack the same password with a different salt — the brute force must begin anew. The hash for somethinglongbefore-me+galadriel is completely different from anotherstringinfrontof-me+galadriel. This is the primary way to prevent another TMTO attack, usually referred to as a rainbow table.

If you want a recommendation on the length of a salt, 19 is a nice, mystical number.⁹

Every measure you take to encrypt and obfuscate the password reduces the risk should the web site’s password store be stolen. (There’s quite a bit of precedent for such things.)

However, everything you do to protect the password in the database (or wherever it is stored) has no bearing on a multitude of other attack vectors, including the database itself.

Imagine a SQL injection attack that sets every user’s password to the hash of a password known to the attacker. What would you rather do? Download the entire DB over a period of several minutes or change every account to a password you know? These approaches have different goals: obtaining original passwords are likely re-used across email, banking, and other sites whereas setting a known password gives immediate access to the site at the expense of blatant activity more likely to be noticed.

Imagine a scenario where the attacker is able to modify the login page so cleartext passwords are stored to a file or shuffled off to another web site.

The focus on encrypting the password and preserving its confidentiality is laudable. However, too much focus takes away from the more immediate threat of brute forcing the login form itself. The work factor to crack a short password like ncc1701 might be measured in days or weeks depending on the method of encryption. On the other hand, the attacker may have a list of the site’s users (or have a reliable way of generating likely user names). In this scenario, the attacker targets the login page with a static password (ncc1701) and cycles through the user list.

Once again, there’s precedent of success for this approach such as against our high-profile friend Twitter. In 2009 a hacker cracked the long (more than the mystical “8 character minimum”), but unsophisticated password happiness for an account that had permissions to reset passwords for any other account.¹⁰

Clearly, it didn’t matter how well happiness had been kept secret, encrypted, obfuscated, and otherwise concealed. There were no limits on how many times the login page could be requested for brute forcing the account. Furthermore, the password protection for every other account was moot since the hacker now had access to an admin account from which he could take over any other. The only apparent good news in this scenario is that, while several accounts were compromised, the original passwords to those accounts were not. This is possibly negligible consolation, but important none the less considering the prevalence of password re-use across web sites.

By all means, put some effort into hashing passwords using well-established techniques. You’ll be adding to the work factor of anyone trying to crack the passwords should the password store ever be extracted from the site.

On the other hand, you may be increasing your own work factor with over-engineered solutions for password protection at the expense of other protections — like preventing SQL injection or rate limiting authentication points.

Here’s an additional note I made in the comments, but should highlight in the article:

For comparison, WPA2 uses PBKDF2 with the SSID of the network as a salt, a 256-bit key, HMAC-SHA1 for the algorithm, and 4096 iterations.

If you trying to figure out “what’s best” for hashing a password, consider WPA2 as the reference metric. For example, your hashing should generate a work factor of N times the work factor for WPA2 where N is your degree of paranoia that WPA2 is easily broken.

If you chose a double-digit N “just because”, then why would you ever use a wireless network (phone or Wi-Fi, GSM A5/3 or WPA2, etc.)? It’s much more likely someone will be able to sniff your encrypted traffic than they’ll ever get your hashed passwords. In fact, GSM’s A5/X algorithms have reported attacks. Seems like another reason to layer encryption, such as always using HTTPS.

For another comparison, the OSX File Vault apparently uses PBKDF2 with 1000 iterations. (Although it’d be nice to have a more detailed reference.)

=====

1 http://risky.biz/sosasta
2 http://blogs.wsj.com/digits/2011/06/08/some-top-apps-put-data-at-risk/
3 http://www.pcworld.com/article/229316/lulz_boat_hacks_sonys_harbor_faq.html#tk.hp_fv
4 http://www.keyczar.org/
5 If you’re not well-read in crypto you should at least be well read in fiction. After all, the security of a home-grown cryptosystem is closer to fiction.
6 It’s not necessary to think of any specific hash function at this point, but if you want a more concrete example, “friend” is hashed to the hexadecimal string “8e8b4d64f704c7a6aa632a7e6c2024e4f9fed79caac319e6bb7754db587e6f58″ using the SHA-256 algorithm.
7 http://csrc.nist.gov/groups/ST/hash/index.html
8 http://www.ietf.org/rfc/rfc2898.txt
9 Read the Dark Tower series by Stephen King, books V and VII in particular. The series also has one of the greatest first lines in a book, “The man in black fled across the desert, and the gunslinger followed.”
10 http://www.wired.com/threatlevel/2009/01/professed-twitt/

Here’s the text from the original article¹:

“Given the types of hacks that made the news in the last 12 months it’s not surprising that SQL Injection is high on the list,” Mike Shema, engineering lead for the Qualys Web application scanning service told InternetNews.com. “What is surprising is that the countermeasures to SQL injection are well-known, effective, and available in all of the major programming languages used in web apps — for at least half a decade.”

And the output after putting a Japanese version² of the article through Google translate:

Mr. Mike Shema He has served as an engineering lead in Qualys vulnerability management for Web applications, said in an interview as follows. “Given the type of hacking made headlines during the past 12 months, that’s up to the top of the list of SQL injection is not surprising.’s Surprising is to measure at least 5 years SQL injection is not well known, effective, and it is in a state that can be used in all major programming languages used in Web Applications”

I love the fact that my cynical observation of Advanced Persistent Ignorance was turned on its head to clearly explain three reasons why SQL injection survives to this day:

• it’s not well known,
• it’s effective,
• and (my favorite part) it can be used in all major programming languages.

It sounds so much better that way!

=====

1 http://www.esecurityplanet.com/features/article.php/3936581/SQL-Injection-Most-Dangerous-Software-Error.htm
2 http://japan.internet.com/webtech/20110630/4.html

Threats have agency. They are persons (or even natural events like earthquakes and tsunamis) that take action against your assets (information, network, etc.). An XSS vulnerability in an email site isn’t a threat — the person trying to hijack your account with it is. With this in mind, the term APT helpfully self-describes two important properties:

• the threat is persistent
• the threat is advanced

Persistence is uncomplicated. The threat actor has a continuous focus on the target. This doesn’t mean around-the-clock port scanning just waiting for an interesting port to pop up. It means active collection of data about the target as well as development of tools, techniques, and plans once a compromise is attained. Persistent implies patience in searching for “simple” vulns and enumerating resources vulnerable to more sophisticated exploits.

A script-kiddie joyriding the Internet with sqlmap⁴ or metasploit⁵ looking for anything to attack may be persistent, but the persistence is geared towards finding a vuln rather than finding a vuln in a specific target. It’s the difference between a creepy guy stalking his ex versus a creepy guy hanging out in a bar waiting for someone to get really drunk.

The advanced aspect of a threat leads to more confusion than its persistent aspect. An advanced threat may still exploit simple vulns (e.g. SQL injection). The advanced nature need not even be the nature of the exploit (e.g. using a tool like sqlmap). What may be advanced is the leverage of the exploit. Remember, the threat agent most likely wants to do more than grab passwords from a database. With passwords in hand it’s possible to reach deeper into the target network, steal information, cause disruption, and establish more permanent access than waiting for another buffer overflow to appear.

Stolen passwords are one of the easiest backdoors and the most difficult to detect. Several months ago RSA systems were hacked. Enough information was allegedly stolen that observers at the time imagined it would enable attackers to spoof or otherwise attack SecurID tokens and authentication schemes.

Now it seems those expectations have been met with not one⁶, but two⁷ major defense contractors reporting breaches that apparently used SecurID as a vector.

At this point I’m out of solid technical examples of APT. But I don’t want you to leave without a good understanding of what an insidious threat looks like. Let’s turn to the metaphor and allegory of television influenced by the Cold War.

Specifically, The Twilight Zone season 2, episode 28, “Will the Real Martian Please Stand Up” written by the show’s creator, Rod Serling.

Spoilers ahead. I insist you watch the episode before reading further. It’ll be 25 minutes of entertainment you won’t regret.

The set-up of the show is that a Sheriff and his deputy find possible evidence of a crashed UFO, along with very human-like footprints leading from the forested crash site into town.

The two men follow the tracks to a diner where a bus is parked out front. They enter the diner and start to ask if anyone’s seen someone suspicious. You know, like an alien. The bus driver explains the bus is delayed by the weather and they had just stopped at the diner. The lawmen scan the room, “Know how many you had?”

“Six.”

In addition to the driver and the diner’s counterman, Haley, there are seven people in the diner. Two couples, a dandy in a fedora, an old man, and a woman. Ha! Someone’s a Martian in disguise!

What follows are questions, doubt, confusion, and a jukebox. With no clear evidence of who the Martian may be, the lawmen reluctantly give up and allow everyone to depart. The passengers reload the bus8. The sheriff and his deputy leave. The bus drives away.

But this is the Twilight Zone. It wouldn’t leave you with a such a simple parable of paranoia; there’s always a catch.

The man in the fedora and overcoat, Mr. Ross, returns to the diner. He laments that the bus didn’t make it across the bridge. (“Kerplunk. Right into the river.”)

Dismayed, he sits down at the counter, cradling a cup of coffee in his left hand. The next instant, with marvelous understatement, he pulls a pack of cigarettes from his overcoat and extracts a cigarette — using a third hand to retrieve some matches.

We Martians (he explains) are looking for a nice remote, pleasant spot to start colonizing Earth.

Oh, but we’re not finished. Haley nods at Mr. Ross’ story. You see, the inhabitants of Venus thought the same thing. In fact, they’ve already intercepted and blocked the Ross’ Martian friends in order to establish a colony of their own. Haley smiles, pushing back his diner hat to reveal a third eye in his forehead.

That, my friends, is an advanced persistent threat!

=====

1 http://mashable.com/2011/05/31/https-web-security/

2 http://www.deadliestwebattacks.com/2011/04/advanced-persistent-ignorance.html

3 Continuous Acquisition of Knowledge and Experience

4 http://sqlmap.sourceforge.net/

5 http://www.metasploit.com/

6 http://www.reuters.com/article/2011/05/27/us-usa-defense-hackers-idUSTRE74Q6VY20110527

7 http://www.wired.com/threatlevel/2011/05/l-3/

8 The counterman rings up their bills, charging one of the $1.40 for his 14 cups of coffee. I’m not sure which is more astonishing — drinking 14 cups or paying 10 cents for each one.