Practical Example of csSQLi Using (Google) Gears Via XSS

Comment: I would like to go out of my way to thank Paymo.biz for the professionalism that they displayed in promptly responding to vulnerabilities brought to their attention to ensure that their users were protected. Within 24 hours, they had responded to my initial communication and shortly thereafter were sharing proposed protections which were then quickly implemented on production systems. Web application vendors can learn from their example.

Yesterday, at the Blackhat DC security conference, I spoke about the dangers of persistent web browser storage. Part of the talk focused on how emerging web browser storage solutions such as Gears (formerly Google Gears) and the Database Storage functionality included in the emerging HTML 5 specification, could be attacked on sites with existing cross-site scripting (XSS) vulnerabilities. The overall message is that while such technologies have built in controls to protect against attacks such as SQL injection (SQLi), when secure technologies are implemented on insecure sites, protections become meaningless.

Both Gears and HTML 5 Database Storage, permit web applications to store content in local relational databases, which reside on the local file system by leveraging the SQLite database format. This provides powerful functionality as web applications can now be taken offline as was recently done with Gmail. At the same time, it adds a new attack vector as persistent data can now potentially be attacked on the desktop, not just the server. Given that we're dealing with a relational database, is client-side SQL injection (csSQLi) possible? Unfortunately, the answer is yes and it's not simply a theoretical attack, it's very practical thanks to the significant prevalence of XSS vulnerabilities.

Both Gears and HTML 5 Database Storage leverage client-side JavaScript to create and interact with local databases. Therefore, if an XSS vulnerability is present, it's all too easy for an attacker to compromise the confidentiality and integrity of locally stored data by reading from or writing to the local database. Web applications with local databases via HTML 5 are presently rare due to the fact that only WebKit based browsers have implemented the functionality (i.e. Safari). This however seems poised to change with recent announcements that offline Gmail access is being developed for the iPhone and Android based phones via HTML 5 Database storage. Gears enabled applications on the other hand have already started to spring up and csSQLi has therefore become a reality.

Paymo.biz, a time tracking application was previously vulnerable to csSQLi due to the existence of XSS vulnerabilities on the site. The associated image details how JavaScript could be injected to read from the local database and in this proof of concept simply write the data to an alert box. Step #1 is specific to this situation as the XSS injection point occurs within paragraph tags which need to be closed. Gears is a JavaScript API, so in step #2, the API is included in order to expose necessary functions. In step #3, the local database is opened. In traditional (server side) SQLi the database structure must first be determined either through error messages or other brute force means. With csSQLi this is not a challenge since the database structure is exposed. To determine the names of tables, columns, etc. an attacker simply needs to first access the application himself to establish a local copy of the database on his own machine. Executing the SQL statement is conducted in step #4 and once again csSQLi is far less challenging than a server-side SQLi attack. Thanks to having XSS facilitate the attack, the SQL command can be composed from scratch - no need to inject commands into the middle of an preexisting SQL statement. The results of this particular injection can be seen in the associated screen shot which simply displays default data from a newly configured database.

While Gears has not yet been widely adopted, I expect this to change in the coming months, especially with the exposure that the technology will receive thanks to recent integration with Gmail. As users recognize the power of being able to take web applications offline, developers are sure to investigate adding Gears to their own applications. It's important to note that this attack has nothing to do with insecurities within the Gears technology itself. As mentioned, the attack is made possible when Gears is implemented on a site with existing XSS vulnerabilities. Unfortunately, XSS is a vulnerability which is far too prevalent on the web today. As such, it is inevitable that we'll see sites vulnerable to csSQLi. I hope that this early example illustrates the risks associated with offline browser storage and the importance of ensuring overall application security before adding this powerful functionality. Don't avoid Gears...embrace it...but do so securely.

A full copy of the slides from my talk entitled A Wolf in Sheep's Clothing - The Dangers of Persistent Web Browser Storage is available here.

- michael

Brainstorming != Security Analysis

I mentioned a community meeting I recently attended to some friends, and they were astonished to learn that not only did I think our brainstorming session was productive, I actually suggested it. Apparently, I have ranted so much about brainstorming that my friends think I disapprove of brainstorming as a concept. Whoops. :) Let me explain.

Usually groups use brainstorming to generate a bunch of ideas about some topic. Brainstorming (especially the round-robin technique we were using at the community meeting I described) is a great way to ensure that everybody's point of view is represented. It's all about inclusion, suspending judgment, listening, and other touchy-feely stuff that is very important in a community, especially one that is just forming. But as Wikipedia tactfully puts it, "researchers have not found evidence of its effectiveness for enhancing either quantity or quality of ideas generated. … [B]rainstorming groups are little more effective than other types of groups, and they are actually less effective than individuals working independently." In my opinion, the main reason to use it is to improve the team's soft skills, understanding of each other, morale, or similar, which is exactly what we needed at the community meeting.

And it should make a good security analysis technique, right? Hah. Having a happy, well-adjusted analysis team that works well together is desirable, but hardly ensures decent results. Likewise, even if brainstorming were good for generating lots of ideas, having a lot of ideas (on any topic) is not a major contributing factor for good security analysis results. Yet many current security analysis techniques have a step (e.g. "now we all get together & think up everything that could possibly go wrong") that looks a lot like brainstorming. What is going on here?

For starters, most consumers of security analysis results (e.g. non-security developers or management folks) can count just fine, but don't have the skills or knowledge to tell the difference between high and low quality analysis. Therefore, they like quantity. Analysis consumers will feel more satisfied and comfortable when analysis investigates and finds more issues. This is not entirely unreasonable; my experience indicates that even for a small system, there are usually quite a few things to investigate. If analysis only investigates 3 potential issues, I expect low quality analysis. In the frequent situation in which the analyst doesn't have a lot of security analysis experience (e.g. the do-it-yourself model many security development lifecycles suggest) but knows that investigating 3 issues is not enough, brainstorming starts to look like a good technique for identifying potential issues: its stated goal is to increase quantity of ideas, and quantity of ideas is what seems to be missing. Brainstorming is so well-accepted as an idea generation technique that it rarely occurs to anyone to investigate its effectiveness. (For the record, what is actually missing is coverage. Quantity of potential issues is a secondary indicator of coverage; quantity of found issues is a secondary indicator of a combination of coverage, analysis quality, granularity of analysis or reporting, target quality and many other interrelated factors.)

Next, most experienced security analysts can't accurately explain what they are doing when they come up with a list of potential issues to investigate. When an inexperienced security analyst asks, the more experienced guy will frequently say something like "I start by making a big list of possible stuff to look into". He might even use the word brainstorming. When the inexperienced analyst looks at the output, it will look like brainstorming output. The trick is that brainstorming is not what he's doing. What the experienced analyst is actually doing is very similar to what Benjamin Kovitz (Practical Software Requirements) explains engineers do instead of the functional decomposition they appear to do: matching what he already knows to the target at hand, and writing a list of potential issues he already knows about for this or similar targets . If you get a group of experienced analysts together, they will do what looks like brainstorming and come up with a great list, each of them unconsciously using her own experience.

What happens when an inexperienced analyst tries brainstorming for security analysis purposes? Let's say he gets a group together, and they come up with some ideas. Frequently these days, the ideas are couched as a threat model. One such threat model I vividly recall receiving (as a guide to the code review and penetration testing I was supposed to do for a client) had one (1) threat. When I asked the security-inexperienced client about it, I found the development team had brainstormed a list of threats, but the application was so small that this was the only idea they had come up with. It's true, it was a small application with limited security requirements; if I recall correctly, I came up with only 2 dozen or so threats (maybe 50ish variations for my colleague and I to investigate) when I did a brief, more systematic analysis. This is an extreme example of intelligent but inexperienced analysts applying brainstorming in good faith and getting lousy analysis results for their trouble. More typical results in my experience are that inexperienced analysts think of around 5-15% of what experienced analysts investigate, with most threat models by inexperienced authors containing 5-12 potential issues to investigate. (These are approximations based on experience, not hard statistics.)

Now imagine that the inexperienced analyst looks at the 1 potential issue he got out of the initial brainstorming session, and thinks to himself, "hmm, something went wrong; better get some help". What does he do? Calls his more experienced buddy & has the more experienced buddy facilitate a brainstorming session. I've been that buddy and talked to a lot of other more experienced buddies, and the brainstorming session facilitated by the more experienced analyst is usually pretty successful. Why? It's not brainstorming either. The experienced analyst is asking questions that will guide participants to realize the potential security issues for this target, and helping them fill in the blanks (again based on her own experience) when participants miss something.

After a brainstorming meeting, most participants will express great satisfaction with the meeting, the process, and the results. This is great, but when interpreting their happiness, remember that suspending judgment is part of the brainstorming process and a morale boost is one of the effects. Also keep in mind that people who suggest that brainstorming is not an appropriate technique to use are frequently accused of having a bad attitude, not being team players, and so on, and may therefore be keeping their mouths shut. Either participants are experienced and/or knowledgeable, in which case they unconsciously used their experience and knowledge to get good results, or they are not, in which case they usually can't tell how good their results are (yet; some participants will notice the low quality as analysis proceeds). My experience has been that by the time a brainstorming-based security analysis completes, most participants have started to question the quality of results, the ROI, or both. Unfortunately, what's done next time is often based on familiarity and the emotions people expressed during the process ("Last time I led a group through this they were very happy with the results."), rather than costs and benefits calculated at the end.

Brainstorming is NOT a security analysis technique. Any security analysis technique that looks like brainstorming is suspect. Either it doesn't work but nobody can (or will) tell, or something else is going on behind the scenes. Find out which is happening for you, then skip the brainstorming and head straight for the secret sauce.

--Brenda

Rough Week for Security Companies

It's been a rough week for security companies, especially for their web masters. A Romanian hacking group decided to embarrass as many as possible by identifying SQL injection (SQLi) flaws in public facing websites and Kaspersky, F-Secure and Bit-Defender (actually a reseller) all fell victim to the attacks. Now SQLi is far from a new issue and it's widely accepted that pre-auth SQLi vulnerabilities are critical flaws that require immediate attention. Despite this, we see no shortage of SQLi and it is increasingly becoming a favorite tool for botnet authors, who use such vulnerabilities to inject content into otherwise legitimate web pages in order to redirect browser traffic. I recently commented on the volume of such attacks that we're seeing and stepped through a specific example.

I spend most of my time worrying about emerging threats - the risks that we'll face in the months and years ahead. However, from a business perspective, greater damage comes from current, widespread attacks and companies rightly so, dedicate the majority of security resources to combating the 'clear and present danger' which they face. The events of this past week caused to to ponder how we're doing as an industry in combating what is now a mature and well understood vulnerability - SQLi.

Unfortunately, web application security statistics are somewhat hard to come by. The best come from Whitehat Security, which generally publishes an overview of what they're seeing from scanning client websites. They publish these reports a couple of times a year, so I dug up all of their statistics dating back to November 2006. Sadly, as can be seen is the Whitehat chart, progress appears to be relatively flat. The Whitehat statistics shed light on the likelihood that a particular vulnerability will exist on a given website which they review. We can see that over the past 2+ years, on average, their is a 17 1/3% likelihood of discovering a SQLi vulnerability on any given site. That's truly frightening and while it helps to explain why such vulnerabilities are so prevalent, it doesn't explain why they aren't going away.

I also pulled statistics from a 2007 survey conducted by the Web Application Security Consortium. These statistics provide a consolidated view from eight separate security services vendors. This time around, we see that approximately 1/4 of sites scanned revealed SQLi vulnerabilities - even worse.

The question we need to ask ourselves is why are the statistics not improving? In my opinion, while the security industry is getting better at detecting and patching such issues and businesses are better understanding the risks associated with mature vulnerabilities such as SQLi, the population of new developers and web applications is growing at an even faster pace. Who is a web application developer today? Thanks to point and click tools, just about anyone can be a web application developer - but that doesn't mean that they're a good developer or one that understands and implements secure coding practices. We've struggled for a long time to educate developers about security and while such initiatives are important, they will never be enough. Education alone will never succeed in dropping the statistics included in this blog because the vast majority of 'developers' will never receive such training. The majority of developers don't have a Computer Science degree and they may not even get paid to develop. As such, vulnerability statistics will only begin to drop once protections are built into the architectures of the 'point and click' development tools, implementing security by default. Fortunately, we have started to see vendors take such steps. Only when the 'every man' developer can be protected from attack, without security knowledge will we truly see a drop in vulnerability statistics.

- michael

I am a virus, don't click me unless you're a twit

Yesterday some spam-esque messages hit a portion of the Twitter population. Twitter spam is nothing new, but there is a twist to this case. The Twitter messages read:

don't click: http://tinyurl.com/amgzs6

If you did click the URL anyway despite the warning, you were brought to another page that had another "don't click" button on it. If you clicked that button (again, ignoring the warning), you would become a victim to a clickjacking (twit jacking?) attack on your twitter account. The author of this clickjacking demonstration actually documents the whole brouhaha in his blog.

TinyUrl removed the offending URL, and Twitter added some frame-busting Javascript code to their pages in order to make them less "clickjackable." But what is probably the most concerning outcome of this whole situation is that users' curiosity trumped security education. They were warned to not click something, twice, and they did it anyway. Twitter admins had to actually send a message to people stating the obvious:




But then again, if the mass majority of people will tell you their password for a candy bar, I suppose we shouldn’t be that surprised.

Happy Friday the 13th!
- Jeff

Botnet Use of Unregistered Domain Names

A growing number of botnets are using unregistered domain names as a means of establishing a command and control network. The basic idea involves generating an algorithm which produces a series seemingly random domain names which can be registered at a later date as needed. This approach helps to ensure that individual hard coded domain names/IP addresses can't be blocked or taken off line in order to kill the botnet.

The Srizbi botnet employed this tactic, and FireEye, a security firm which focuses on botnet protection, attempted to get a step ahead by registering the generated domain names before they could be used. This was a noble effort, however, as can be expected, costs quickly escalated and the effort was abandoned once it was determined that it could cost the firm $4,000/week just to secure the domain names.

I was poring over some log files this week and was struck by the volume of domain names that appear to be requests from infected machines for these seemingly random, as of yet unregistered domain names. Despite the coordinated effort to take down Srizbi in November 2008, it would appear that there remains no shortage of infected zombies associated with Srizbi.

dfswuhet.com
dgudhdde.com
dihhushd.com
dudteigi.com
eastgage.com
edihhsfd.com
eefiwusg.com
euuetweg.com
fdsdeitu.com
ffwhutgi.com
fhhshddh.com
fiituhew.com
fthdedut.com
gewwhisd.com
gfssguhu.com
gstweude.com
gueswifu.com
guffesuf.com
gwuishts.com
heffiehs.com
hfiesfsu.com
hstuwhhe.com
sdghtife.com
sgtgewiw.com
shtfewwd.com
spoyahoo.com
sthdsstd.com
sthhdist.com
sugteegt.com
teisudgs.com
tewsshsg.com
twhtsdsf.com
ugifsfed.com
uidesgih.com
uiwegwth.com
uwfieuwd.com
wdttsewt.com
whdufuss.com
whwudshg.com

Thanks to the reverse engineering efforts of the team at FireEye, we have insight into the algorithm used to generate the domain names. It would however appear that we're dealing with a different variant than the ones inspected by FireEye as the domains that we're seeing do not line up with the future domain names that were predicted by the Srizbi Domain Calculator derived from the FireEye research.

More importantly than the domains listed above, we are beginning to see a very high volume of requests for unregistered pseudo random domain names that do not appear to be related to Srizbi. Conficker/Downadup has also employed this approach and F-Secure has done a solid job of posting predicted command and control domain names for Conficker, based on their own reverse engineering work. However, there appear to be various other botnets employing this approach, based on the traffic that we're seeing.

Registering domain names isn't like digging ditches. It's a sunk cost for the registrars and it's high time that they stepped up to assist in this matter. Entities like FireEye shouldn't need to expend real dollars to register domain names in an effort to stop the spread of a botnet. A coordinated effort between researchers and registrars needs to be established to ensure that future botnets cannot employ this tactic. It won't be easy as there are several registrars responsible for the many TLDs now available, but it's a worthwhile initiative, especially as this trend continues.

- michael

Keeping security relative

I really liked today's XKCD web comic:



There have been multiple times in my career where I’ve encountered someone who was caught up in the 'sex appeal' of a security technology without looking at the practicality/relativity of what they were trying to achieve as a whole. One encounter I remember was an on-site discussion I had with a security staffer of a large financial institution. I was going over some security audit findings, and he remarked that he was disappointed that their password policy didn't fail the audit. I responded with a discussion about how their password policy was actually very good and well above industry best practice at the time, particularly in password length. His response was that it could always be made stronger by requiring more characters in passwords. That is true, but given the numerous other critical areas that failed the security audit and therefore allowed arbitrary attackers to compromise practically any desktop or server on their network...what was the real value of requiring longer passwords? He failed to see that there were easier ways for an attacker to get at the same data without dealing with passwords or their strength; thus a increase in password length for the sake of an increase in password length would not provide any additional security protection value.

Sure, it's important to 'raise the bar' for security to lofty heights. But there comes a point where additional effort to further raise the bar of a single control doesn't return much additional security benefit (i.e. poor securitiy ROI). And there will inevitably be a point when trying to increase/improve the benefit of a specific security control will be questionably pointless because an alternate avenue of attack will now have a comparably much lower bar. In other words, you are wasting your valuable security dollars by over-doing one security control if you have poor security benefit from another control protecting the same resource.

So every time you think about adding or increasing the level of security of a particular control, you should always take a moment, step back, and consider the level of security provided by controls encompassing alternate avenues of attack. If those other controls are under-performing, then you should consider raising the security level of the other controls instead. Otherwise you will find all of your great security effort is negated by a clever-but-predictable use of a $5 wrench.

Until next time,
- Jeff

Google SafeBrowsing Goes Haywire

[Update: Google has fessed up in a blog post. Apparently the problem was caused when a URL of '/' was added to the StopBadware block list. The incident also caused a DoS attack on the StopBadware site due to the volume of users clicking on links in the warning messages.]

This morning, some time after 9am EST, Google's StopBadware feature went haywire. StopBadware is a Google initiative to maintain blacklists of malicious and phishing URLs. It can be leveraged by third parties via the Google SafeBrowsing API. As can be seen in the associated screenshot, the functionality was broken as a search for 'test' indicated that every search result could contain malicious content with a link stating 'This site may harm your computer'. Clicking on any search results would take the user to a warning page as opposed to the actual destination.

The issue has now been resolved, but it illustrated two things for me - the power of Google and the potential of user driven reporting sites like Twitter. We trust Google. It's been our friend for a long time, so when it starts telling us that every site is malicious we get worried. A Twitter search for posts related to the problem shows plenty of confusion and speculation as to what the problem was.

More interestingly, it provided timely information based on the start and stop time of the bug. Posts that I reviewed show that the issue began just after 9am EST and was resolved approximately an hour later. Others, suggest that problem was not fixed but rather code was rolled back to restore a stable state. Was it a regression bug introduced during an upgrade? Seems likely.

Thankfully the crisis has been averted so the world can keep turning on its axis. Nothing to see here, move along.

- michael