RSA Europe 2011

Here are the slides I used for my presentation at RSA 2011 Europe. The topic was HTML5 with an emphasis on distinguishing between HTML5 features that may present vulnerabilities vs. how HTML5 would simply be leveraged as part of older exploits. It also touches on broader aspects of web security such as design vs. implementation issues, the impact of mobile devices, and how using frameworks can improve security — as long as the frameworks themselves are good.

Big in Japan

It’s not quite a Spinal Tap moment, but here’s a curious translation via Google.

Here’s the text from the original article1:

“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 version2 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

Will the Real APT Please Stand Up?

The Advanced Persistent Threat (APT) is now competing with Cyberwar for reign as security word(s) of the year. It would have been nice if we had given other important words like HTTPS1 or Prepared Statements their chance to catch enough collective attention to drive security fixes. Alas, we still deal with these fundamental security problems due to Advanced Persistent Ignorance. (I noted2 previously that you can only defeat Advanced Persistent Ignorance with CAKE3.) It’s not wrong to seek out examples of APT, but it helps to have an idea about its nature. Otherwise, we risk seeing the APT boogeyman everywhere.

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 sqlmap4 or metasploit5 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 one6, but two7 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.

Or Was it Sindarin?

I have a new article1 on Mashable regarding the importance of having https:// in front of the web sites you visit.

I finished that article and its linguistic metaphor a few days before coming across an article2 on El Reg that describes research3 showing the feasibility of identifying language patterns over encrypted channels.

One goal of an encryption algorithm is to create diffusion of the original content in order to camouflage the content’s structure. For example, diffusion applied to a long English text, say one of Iain M. Bank’s novels, would reduce the frequency of the letter ‘e’ from the most common letter to (ideally) an equally common frequency within the ciphertext. The confusion property of an encryption algorithm would do something like replace every letter ‘e’ with the letter ‘z’, but that wouldn’t affect how frequently the letter appears — hence the need for diffusion.

There have been similar analyses of SSL and SSH in the past that demonstrated it was possible to infer the length of the encrypted content (which might reveal the length of a password even if the content is not known) or guess whether content was HTML or an image. The Skype analysis is a fantastic example of looking for structure within an encrypted stream and making inferences from those observations.

=====
1 http://mashable.com/2011/05/31/https-web-security/
2 http://www.theregister.co.uk/2011/05/26/bypassing_skype_crypto/
3 http://www.cs.unc.edu/~amw/resources/hooktonfoniks.pdf

DEFCON 18

DEFCON 18 is coming up from Friday July 30th to Sunday August 1st in Las Vegas. They always have cool badges so you should at least sign up just for that.

If badges aren’t enough to whet your appetite, think about how much fun you might have learning about “Securing MMOs: A Security Professional’s View From the Inside” or the forensics of video games in “The Games We Play“.

The EFF is also running a contest to sign up attendees and gather new members. You can go directly to their web site or click on the following image to be part of The Book’s efforts to support the EFF:
Join EFF!

Article on the new OWASP Top 10

The Tech Herald has an article on the recently updated OWASP Top 10 Web Application Security Risks. The article discusses a little bit of the evolution of the Top 10 list and how one major vulnerability, logic flaws, tends to get hidden behind the noise of SQL injection and XSS.

You can find out more about logic flaws in Chapter Six of Hacking Web Apps.

Zombie Mall Attack II: The SQL

In a world where time must be killed and only one man sits in row L…

A few days ago I went to see a movie as the Castro Theatre. I arrived early for the show and sat in an empty theater. The mighty Wurlitzer was off for the night so I turned to my iPod Touch for entertainment until the movie would begin. Since I was in a movie theater it seem appropriate to look for some movie-themed apps. An obvious choice was the IMDb app1.

I installed the app and multi-touched my way through a few screens. I recognized several of IMDb’s list of the Bottom 100 films from MST3K episodes (which were fresh in my mind from seeing Cinematic Titanic live a few weeks earlier).

Another menu took me to US Box Office Results. Stuck between A Single Man and Lovely Bones was a curiosity that had taken $291K for the week and grossed $43.4M. The movie title was (null). Interesting…and possibly related to web security no less!

Now, there are a few options for looking behind the scenes of an app:

  • Jailbreak the device, reverse engineer the IMDb app or hook its network layer, write all of its network communications to a log file
  • Set up a wireless sniffer to capture traffic, hoping that it won’t be using an encrypted channel
  • Set up a sniffer on the access point’s LAN connection (in case KisMAC won’t work), but still be foiled by the potential of encrypted traffic
  • Change the Touch’s HTTP Proxy settings for the Wi-Fi Network to point to Paros running on another system. You realize Paros doesn’t just have to listen on localhost, right?


Ten times out of nine the simplest approach is the best approach. So, I set up Paros, which conveniently solves the problem of HTTPS as well2. If I had wanted to work hard I would have chosen binary exploit development over throwing together a few angle brackets and quotes to pull off XSS and SQL injection attacks against web sites.

With Paros listening I returned my fingers to the IMDb app. A few taps later I had my traffic. The User-Agent was “IMDb/1.1 CFNetwork/459 Darwin/10.0.0d3” which isn’t really relevant, but of interest if you’re into HTTP Headers…*crickets*

Okay, let’s stay relevant. Paros reveals that app makes simple GET requests and receives JSON-formatted data from the server as shown here:

There’s a copyright notice for each response that states, “For use only by clients authorized in writing by IMDb. Authors and users of unauthorized clients accept full legal exposure/liability for their actions.” A likely reason for the notice is to prevent other apps or services from spoofing requests and emulating the IMDb app. HTTP messages are trivial to spoof, but that’s a topic for another time.

This is what the first entry looks like. The title information, thumbnail image, and year of release are in red (I haven’t seen this movie yet, so expect the gross to go up by at least $10 next week):

{"weekend":{"currency":"USD","amount":41062440},"title":{"tconst":"tt1130884","type":"feature","title":"Shutter Island","image":{"width":501,"url":"http://ia.media-imdb.com/images/M/MV5BMTMxMTIyNzMxMV5BMl5BanBnXkFtZTcwOTc4OTI3Mg@@._V1_.jpg","height":755},"year":"2010"},"rank":1,"gross":{"currency":"USD","amount":41062440}}

Now, let’s search for our mysterious Number 25, which is highlighted in the previous screenshot. The title, image, and year are missing — in their place sits a single “vendor_title” field:

{"weekend":{"currency":"USD","amount":291360},"vendor_title":"2010 OSCAR SHORTS","rank":25,"gross":{"currency":"USD","amount":291360}}

So, no obvious SQL errors or malformed JSON syntax lurking here. We’ll have to change plot direction mid-course and find a happy ending. The app is still an inherently web-based application since it uses HTTP for transport and returns data with JSON formatting.

This leaves us with a chance to talk about defensive programming. The data for Number 25 was well-formed, but in the wrong format. The entry didn’t contain invalid characters and its content used correct delimiters to separate fields. Yet it was clearly missing the expected fields for title, image, and year. Since the app didn’t blow up in the face of unexpected results it was either lucky or benefited from some degree of a secure failure state.

In this case, a value was non-existent, NULL. In programming languages like C referencing a NULL value can be disastrous, as in Michael Bay disastrous3:

printf(“%s”, title)
*BOOM*

Whereas a slightly more secure technique would ensure the title pointer is valid:

printf(“%s”, title != NULL ? title : “(null)”)

Web applications typically use languages that don’t have the potential pointer problems of a language like C, but the concept is still applicable.

Defensive programming is a proactive countermeasure that helps protect web sites from unexpected errors or situations. In this IMDb example, the JSON was well-formed. It also only contained name/value string pairs as opposed to serialized functions. So, we’ll end with a brief, high-level checklist for implementing secure code.

  • Check return values of functions.
  • Check for errors.
  • Fall back to a default value or action.
  • Don’t try to massage data to correctness. While it probably wouldn’t have been bad in our example if “vendor_title” had been used since it had the word “title” in it. On the other hand, filtering out “<script” from “<sc<scriptript>” in an attempt to massage bad mojo, i.e. an offending <script> tag, into good mojo fails miserably. Fixing data can also cause problems when dealing with character encoding schemes.
  • Write output securely. A simple example is writing custom 404 messages. If the non-existent link is written back into the page, then it’s a good idea to URL encode the link before rendering it into the page. Otherwise, you end up with attackers looking for links like “/<script+src=http://ip.address/j>” to send to their phishing victims — who see a link being served safely, one assumes, since it’s from the original site.

Also, keep in mind that web security pops up in unexpected places. Just because an application doesn’t look like a web browser doesn’t mean it’s immune to the types of injection attacks that plague the more familiar web sites.

—–
1 One of the app’s ratings warns it may contain “Infrequent/Mild Profanity or Crude Humor”. Mild? Not if you dig into reviews for some of the more awful movies. There are times when the English lexicon fails to describe movies like Robot Holocaust.
2 The app will see a certificate from Paros rather than the one used by the web site. If the app enforced strict checks on the SSL certificate’s validity, then intercepting the traffic would be more difficult.
3 In the huge explosion sense, not plot. (They’re just different types of disasters. Watch Transformers 2 if you don’t believe me and you’re really bored. The kind of bored that makes you read parenthetical notes inside endnotes bored.)