We Used to Laugh at XSS

I remember at Defcon 10 in 2002, when members of GOBBLES took to the stage for their much anticipated talk about the state of the security industry. The talk turned out to be a largely incoherent, but entertaining rant and I still remember the Unix Terrorist (aka Stephen Watt) poking fun at the many cross-site scripting (XSS) holes that people had begun to publish advisories for. At the time, he was right. XSS wasn't a high risk vulnerability. It wasn't being leveraged by attackers for anything meaningful and could be easily thwarted by simply avoiding the use of JavaScript. Well...things have changed. Today, Watt faces some serious charges due to his alleged involvement in the TJX breach and XSS vulnerabilities have emerged as a legitimate threat.

What changed?

Last weekend, a web based Twitter worm (aka Mikeyy/StalkDaily worm) hit the media. It was the work of Michael Mooney, a 17 year old, self described 'bored developer', who was brazen enough to brag about the attacks after the fact. He may be regretting the publicity at this point, now that his systems have been publicly hacked and he's no doubt heard about how Samy Kamkar was rewarded for his efforts after a similar attack on MySpace with a felony conviction. However, thus far it seems to have landed him a job as opposed to jail time.

What has happened to turn XSS from amusing interweb trickery into a valuable attack vector? In short, the web has changed, but unfortunately security is lagging behind. In general, I see the following four factors that deserve credit:

1.) Prevention [should be] the best Medicine - We've known about the dangers of XSS for at least a decade now, and yet it remains the most prevalent web application vulnerability out there. Efforts to educate developers has produced limited results, not in my opinion because developers don't care, but because the population of web developers is growing at a tremendous pace, thanks to point 'n click development environments. We've empowered millions with the tools to develop web applications but we've also made it far to easy to produce an insecure application.

2.) The Ubiquity of JavaScript - We used to tell users to avoid XSS by avoiding JavaScript. That was a reasonable statement in 2001 but good luck surfing the web today without a JavaScript enabled browser. You'd be better off using a text based browser such as lynx. With the advent of AJAX enabled sites and the demand for increasingly interactive, user-friendly web content, you'd be hard pressed to find a JavaScript free site that is actually used by anyone.

3.) The Power of Social Networking - Web based worms such as the Twitter worm have one inherent limitation - they live within the ecosystem where they were created. While this would be significant for a seldom used web application, with social networking sites measuring active users in the hundreds of millions this is hardly a limitation at all.

4.) Sky's the limit - While we tend to think of XSS as a way to steal session credentials, such attacks are limited only be the creativity of the researchers/attackers that pursue them. Anton Rager developed XSS-Proxy as a means to remotely control XSS attacks. Billy Hoffman turned a browser into a vulnerability scanner via XSS. Jeremiah Grossman demonstrated gaining insight into someone's browser history and at Black Hat DC this year, I talked about how XSS can be used to conduct client-side SQL injection. The list goes on and on...

The Twitter and MySpace worms were largely benign. When traditional worms began spreading, they were largely benign as well, a proof of concept to prove that something could be done. Once that hurdle had been overcome, criminals moved in to profit and I don't expect the outcome to be any different this time around either.

We've set the bar far too low for attackers. Well known vulnerabilities such as XSS remain far too prevalent, despite having been around for years. It's encouraging to see Microsoft stepping into the fray by adding XSS prevention to Internet Explorer 8 and I hope that other browser vendors will do the same. While the root cause lies with web app developers, it is clear that focusing on developers alone will not fix the problem. The interconnected nature of the web requires that all players pitch in to reduce risk to end users.

- michael

Public Service Announcement: EFF Coder's Rights Project

I ran across this today, and thought it was just too valuable to not make mention of. The EFF has a "Coder's Rights Project" that includes FAQs and guides related to the legalities of security disclosure, reverse engineering, and ethical hacking/testing for security vulnerabilities. They are absolutely fantastic layman summations of all the legal nuances (US-centric) that you should be aware of while pursuing any of these legally grey endeavors. The FAQs and guides concisely lay out how the various US laws, such as DMCA, copyright, and Computer Fraud and Abuse Act can come into play during security testing, disclosure and reverse engineering efforts. The EFF material also provides very good advice regarding how to reduce/limit your risk.

If you had any doubt, it should be thoroughly dispelled by the time you are finished reading the material on EFF: testing software and web sites for vulnerabilities is NOT a legally granted right. The law does NOT recognize the concept of "ethical" hacking. As such, the true key to ethical hacking is the confidence that the person you are hacking is not going to legally pursue you after your activities. Hack only when you have permission to do so. Without permission, you are putting yourself legally on the hook regardless of your morals and non-malicious intentions.

If you are still steadfast in your desire to perform security tests without explicit permission in a manner that you feel is morally clean, then you need to ensure that you keep all your actions above board and follow through on your non-malicious intentions. If you do find a problem, report it immediately. Taking the time, for example, to dump the entire user database along with passwords and play around with it for a few weeks before you finally disclose the problem is not going to be seen as aligned with clean intentions. Also keep in mind that law enforcement agencies are very keen on people trying to hide their identities while undergoing these types of activities; using anonymizers and the like is not looked upon favorably and as such could push your activities to the 'blackhat' end of the spectrum rather than the 'whitehat.' If your intentions are good and you have nothing to hide, then don't hide it.

Above all else, if there is any doubt, then just don't do it.

Until next time,
- Jeff

Anatomy of a Straight Answer

You're a software developer, going along minding your own business when some crazy security geek (hopefully a coworker rather than a stranger who just stepped in from the Net) has the nerve to discover that your code is broken. There is, he says, a hole. "How bad is it?" you ask. "That depends," he usually says, and continues with a long treatise covering many hypothetical possibilities (but always veering away from firm opinions). Maybe he asks 20 questions about how your customers deploy your product (most of which you can't answer) . Only if he already knows all about the deployment environment and what your customers are doing with the product will he give you a straight answer, and even then it'll probably sound like an answer plus lecture or disclaimer. What is up with that? Why doesn't anybody seem to be able to give a straight answer about how bad a vulnerability is?

The problem, from the security geek's perspective, is that "it depends" is the straight answer. "How bad is it?" depends on at least two things: expectations and environment.

• Expectations because, if Alice believes she is using world-wide Internet photo publishing software, and later it turns out that anyone on the Internet can see the snapshots she added to her photo library, she is unlikely to call this a security problem even if said Internet user can use a technique the software developer didn't intend. But if Alice believes she is using software to share photos with her friends over the Internet, and later her prospective employer Googles her and finds pictures from that one party because the photo sharing site has an anonymous FTP server on the same box, she will be quick to cry security hole.
• Environment because there's nothing wrong with an anonymous FTP server, and nothing wrong with an access-controlled photo sharing site, but put them together in the wrong way, and Alice is out of a job and hopping mad.

Expectations and deployment environment are especially important in evaluating design flaws. It's a design flaw when the system is implemented exactly the way the designer intends, but the design allows unauthorized users to do more than the system owners or legitimate users expect. Given a design and some expectations, how bad the design flaw is (and even whether it exists) is entirely a function of the deployment environment. Likewise, given a design and a deployment environment, the severity of the design flaw (if any) depends entirely on stakeholders' expectations. So, if you ask a security geek how bad a design flaw is, he is going to spend a lot more time looking into stakeholders' expectations and the environment than into the system you asked him to analyze. This may seem weird, but he's looking there because that's where the answers are.

(In the case of an implementation flaw, proportionally more time may be spent figuring out the direct, technical implications of the flaw, mostly because by the time you've identified the existence of a design flaw, you usually have a pretty good idea how it affects this system in isolation. After that, the analysis is the same as for a design flaw. Mitigation, on the other hand, is usually easier since you can fix the bug without changing anything for your legitimate users or relying on protection in the environment. )

-- Brenda

Spoofing caller-ID: the new hacking inroad

It is amazing to see the number of bridged services that rely upon the source telephone address of an incoming call (supplied via caller-ID) or SMS message as a form of authentication. Maybe this made sense in the 90's when spoofing caller-ID was hard, and the most it would offer is accessing someone's voicemail without a PIN. But nowadays there are countless online services that allow SMS and caller-ID source spoofing (Spoofcard, Phonytext, etc). Pair this with the growing number of services offering telephony or SMS integration, and you start to have a problem.

Let's review some recent examples of this situation in action. Twitter was found to allow spoofed SMS messages to perform Twitter account actions/changes. The core problem was first identified nearly two years ago, but a recent variant allowed attackers to circumvent previously added safeguards. Twitter offers the option of using a PIN, but using a PIN impacts the ease of use and the overall user experience--so users do not jump at the opportunity to opt-in to this additional hurdle.

Google Voice has also had a fair amount of problems exposed, although some of the problems use different vulnerability vectors than the simple spoofed caller-ID/SMS. Spoofing caller-ID of a mobile phone configured for a Google Voice account allows an attacker to get into the Google Voice IVR system for that account and modify certain settings. Google has since closed these holes.

While we are talking about hacking telephone/SMS-related services, it is probably worth mentioning an XSS bug found on Skype's website. The attacker can try the usual bag of tricks to get a user to click on an XSS-ified link and gain access to the Skype session cookie. Fortunately, it seems Skype session cookies expire after thirty minutes...making the window of exploit opportunity it bit more difficult for an attacker to hit.

Overall, it is important for companies looking to add SMS/telephony bridged capabilities to their existing services to understand that caller-ID and SMS source information is not reliable for authentication purposes. Period. It is no different than asking a user for their username without the additional authentication aspect of a password; it creates an "on your honor" system which is ripe for abuse.

Until next time,
- Jeff

Why Are Two Holes Worse Than One?

I'm giving a talk at Metricon next week. One of my more successful pre-talk strategies is to corner whatever non security experts I can find and practice explaining what I am going to talk about. By the time I can successfully explain a concept to my doctor's accountant, a freelance outdoor photographer, and a graphics programmer (this week's semi-randomly selected crew of listeners), I usually have a pretty good idea of which explanations work. Plus, talking to people outside my field is a great way to practice answering unexpected and frequently awkward questions in real-time. Like "why are two security problems worse than one?" "Of course they're worse; there are two of them" is not a satisfying answer. Now that I've had a bit more time to think about the question, I even recall a conversation with another security geek who argued fairly passionately that two similar holes are not worse than one.

For discussion purposes, let's assume the two vulnerabilities are independent (i.e. not caused by the same design problem or line of code), but very similar (e.g. they have identical CVSS vectors), and consider things the second vulnerability might affect:

Discoverability

The second vulnerability will not affect the attack surface (i.e. the area an attacker with no knowledge of the system searches to discover vulnerabilities), but it will affect the number of vulnerabilities an attacker could find. Therefore, it is more likely that an attacker will find one of the vulnerabilities, and two holes are worse than one.

Mitigation costs

If two vulnerabilities allow access to the same target, from the same starting state, one must mitigate both vulnerabilities to prevent access to this target from this starting state. But if they are independent, they must be mitigated separately. Therefore, it will cost more to prevent access to the target, and two vulnerabilities are worse than one.

Throughput

Depending on the vulnerabilities in question, the second vulnerability may allow more attackers to attack simultaneously than the first one alone. If this were the case, two vulnerabilities would be worse than one. In practice, attackers are not usually trying to fully load the system with attacks, so even if it's theoretically worse, it may not be worse in practice.

Reachability

For reachability purposes, it doesn't matter how many ways the attacker can do it, it only matters whether the attacker can do it. Therefore, two holes with identical CVSS vectors are not worse than one. This makes a lot of sense from the perspective of a goal-oriented attacker with knowledge of the first vulnerability, but less sense from the perspective of a defender.

I may have left out some relevant philosophical issues, but for myself, I'm satisfied enough to continue thinking that two vulnerabilities are worse than one.

-- Brenda

Gmail and HTML 5

If you accessed Gmail today on your iPhone or Android based phone using a web browser, you will have noticed some differences. It has a few more bells and whistles but of particular interest is the addition of offline access. Gmail went offline a few months ago thanks to Gears (formerly Google Gears). Mobile Safari on the iPhone doesn't however have a Gears plugin, so how was this accomplished? The answer lies in the yet to be finalized HTML 5 specification and specifically the client-side database storage functionality that it calls for. While HTML 5 remains a work in progress, WebKit based browsers, such as Safari and Mobile Safari have already adopted database storage. This permits developers to create and subsequently read from/write to a fully capable, locally stored, relational database which is accessed via the web browser. I view today's Gmail release as a watershed moment for offline web applications as this is the first mainstream web application that I've seen using the technology.

I view offline access as an inevitable next step for web applications. We have continued to blur the line between desktop applications and their web based counterparts. Technologies such as AJAX, Flash, Silverlight, etc. have continued to push the limits on what browser based applications are capable of but despite all of the added functionality, web apps suffer from one inherent limitation - they disappear when you go off the grid. Well, that's about to change.

Local Gmail Storage

Since the iPhone (un-jailbroken) doesn't permit raw file access, I'll walk through Gmail's use of HTML 5 via Safari on a standard OS X platform. First off, in order to get Google to deliver the HTML 5 version of Gmail, we'll change the User-Agent header to match that used by the iPhone as follows:

Mozilla/5.0 (iPhone; U; CPU iPhone OS 2_2_1 like Mac OS X; en-us) AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.1 Mobile/5H11 Safari/525.20

Now when we visit Gmail, the iPhone version of the app is displayed. At this point, local database storage has automagically been setup. One concern that I have here is that the end user is not informed of this. Gears will at least require the end user to acknowledge that a local copy of data is being set up. While I'm not a fan of leaving security decisions in the hands of the average end user, I do feel that users should be informed that they're now carrying around a local copy of their email, which could be accessible if their phone were ever lost.

Now let's see exactly what has been stored locally. On OS X, the database is set up in the following location:

/Users/[username]/Library/Safari/Databases/http_mail.google.com_0/000000000000000x.db

Separate databases will be established for each separate Gmail account accessed, with each receiving an incremented numerical value. The database leverages the SQLite format. As such, database content can be viewed with an application such as the SQLite Database Browser. Below are details the tables that are created, along with a description of the data contained within:

• action_queue - Purpose unclear
• cached_contacts - Top 20 contacts, including email addresses and names
• cached_conversation_headers - Abbreviated content from email messages including the full subject, sender's name and first sentence or two of the message
• cached_labels - User defined labels which can be assigned to email messages
• cached_messages - Similar to cached_conversation_headers
• cached_queries - Purpose unclear
• config_table - Application version number
• hit_to_data - Purpose unclear
• log_store - Purpose unclear

Security Concerns

I've commented in the past that Gears and HTML 5 represent fantastic technologies but as with most new technologies, when poorly implemented, they can lead to increased security risk. Applications communicate with local data storage via JavaScript calls. The calls are restricted by a same origin policy to ensure that only the application which created the data, can then subsequently access it. However, as I demonstrated at Black Hat DC this year, when sites are affected by XSS vulnerabilities, a remote attacker could gain access to local database storage and perform client-side SQL injection attacks. Now fortunately, I have no reason to believe that Gmail is currently suffering from any XSS vulnerabilities, but they certainly have numerous times in the past. What I'm more concerned about is the fact that XSS remains an all too common vulnerability and as other developers adopt local database storage either via Gears or HTML 5, we are sure to see plenty of vulnerable sites, which will place end users at risk. This isn't just a privacy concern, it's also a data integrity issue as an attacker can write to the database just as easily as they can read from it.

Overall, I feel that the HTML 5 specification has a great deal to offer and it's encouraging to see some early adoption. It will be up to developers to ensure that powerful features such as local database storage do not unnecessarily expose end users to increased risk.

- michael

Re-blogging headlines – March/April

It felt like a whole day was lost due to April 1st, the day many Internetizens feel they will be unique in their effort to fabricate ruse to demonstrate their cleverness. The Internet already has a low signal-to-noise ratio; on April 1st, the few valuable sites that exist seem to actively collude to drive the ratio even lower. One has to wonder how many man-hours were spent on CADIE the panda-loving artificial life form and facial gestures for web browsers. At least Mr. Astley continued to receive further free marketing through many gimmicks.

Anyways, it seems the world survived the Conficker worm. Many media outlets poised April 1st as nothing less than the end of the online world. Perhaps it was the biggest April Fool's joke of all time, getting so many agencies to report with veracity on something that didn't happen. And while it sounds like the making of another April 1st prank, the "Conficker eye chart" is actually a real tool. Apparently Conficker blocks access to certain security vendor sites, and the eye chart will make that readily apparent when your browser tries to fetch graphics from said sites. Quite clever.

There have been a lot of cloud-centric headlines recently. The Cloud Security Alliance was launched, of which Zscaler is an active participant. There is a LinkedIn group available for general discussion, but it seems things will really start moving around the time of RSA Conference. The Open Cloud Manifesto group (with a LinkedIn group as well) also launched recently. They are trying to promote open standards for cloud vendors. On the one hand, this is a great plan as most cloud technology is home-grown; current implementations are often proprietary systems and thus have very minimal opportunity of interoperability with other clouds. On the other hand, the pioneering cloud vendors are currently deriving large amounts of market advantage simply from the fact that they have tackled the architecture and implementation hurdles others need to surmount to compete. So I don't predict a lot of vendors willingly jumping onto the openness bandwagon until cloud platforms become ubiquitous and commonly obtainable...meaning the market advantage of merely possessing the technology is minimized or removed entirely and commoditization sets in. And despite all this recent excitement over clouds, I feel I need to provide honorary mention of Craig Balding over at www.cloudsecurity.org, who has been talking about cloud security for quite a while now. It's nice of us to finally start catching up with him.

I've blogged relatively recently about Google, Gmail, beta status, and their cloud technology (in my posts "Changing a tire while going 60mph" and "Big, white, puffy clouds can still evaporate"). There were some recent articles which address some of the points I raised. First was the Ars Technica interview of Gmail product manager Todd Jackson, who addressed the whole Gmail 'beta' moniker despite Gmail celebrating its fifth anniversary. And then Google unveiled some details relating to their hardware designs, which include using localized batteries in the server chassis instead of external UPS battery backups. Apparently internal batteries can achieve better efficiency than a UPS can offer; also interesting was their 12-volt only power supply. But there were two much broader takeaways from that story that appealed to me. First was the notion that Google's investments into platform innovations, even if producing only a minute improvement, can still realize a quick return due to the sheer mass of Google's infrastructure. That's a very unique position to be in, because Google can derive advantage from micro improvements that other corporations just simply do not have the economy of scale to realize a return. Second is the statement that Google is currently obtaining efficiency levels that the EPA hopes will be commonly possible in 2011, after additional "advanced technology" is made available to help realize that goal. That is a pretty big tip of the hat to Google and their level of innovation; apparently they are at least two years ahead of where everyone hopes to wind up down the road. Maybe we should ask them what their lottery number choices are...

Until next time,
- Jeff