Monday, September 29, 2008

New CSRF paper with vulnerability disclosure

Ed Felten and Bill Zeller recently released a very well-written paper about Cross-Site Request Forgery (CSRF), including some real-world vulnerability examples from ING Direct, YouTube, MetaFilter, and The New York Times. As you all know so well, CSRF vulnerabilities are easy find when you just decide to look on basically any website. Don't expect any ground breaking research per-say, but the papers content is really helpful to those unfamiliar with CSRF (and that's still a lot people - especially developers). Ed and Bill also did some work on a potential client-side solution, like LocalRodeo I think, which I hope to find time to investigate further. We need as many smart people as we can trying to solve this problem in creative ways. CSRF certainly isn't going to go away anytime soon.

Insecure Magazine Issue #18

Issue #18 of my favorite online magazine, (IN)SECURE, is now available for download. The magazine is consistently content rich, high quality, and best of all - free! ;) This issue has several articles on Web security, one of which was written by yours truly, "Browser Security: Bolt it on, then build it in." Obviously with software security this is the opposite of what you want things to work, but when you consider the business objectives of Web browser security this is the way it tends to work. Here’s an excerpt of the premise...

"Some vendors attempt an über secure design - Opus Palladianum as an example, but few use it. Others opt for usability over security, such as Internet Explorer 6, which almost everyone used and was exploited as a result. Then, somewhere in the middle, is fan-favorite Firefox. The bottom line is that any highly necessary and desirable security feature that inhibits market adoption likely won't go into a release candidate of a major vendor. Better to be insecure and adopted instead of secure and obscure."

Other compelling web security articles:

- Web application security: risky business?
- Secure web application development
- Enterprise application security: how to balance the use of code reviews and web application firewalls from PCI compliance.

Thursday, September 18, 2008

I used to know what you watched, on YouTube

In doing some crossdomain.xml Flash research I noticed that YouTube’s policy file trusted *.google.com. They quickly removed it after I privately disclosed the following security flaw to Google.

My idea was if an attacker could upload an arbitrary Flash movie (SWF) anywhere on the google.com domain they could leverage that trust. So if an authenticated YouTube user visited an attacker-controlled page anywhere on the Web, the attacker could SRC in the google.com hosted SWF, and use it compromise the victims YouTube username, email address, first/last name, viewing history, and even comment or post/delete videos.

Billy Rios blogged in the past about being able to upload arbitrary files to google.com, but the only place I could locate that allowed SWFs when I checked was Gmail. Maybe others?

Anyway, I emailed a SWF attachment to a Gmail account and located the download URL. Perfect, but the next problem was even with the correct URL the victim is not authorized to view the file unless they are authenticated on THAT particular Gmail account. This is where the login-CSRF / identity misbinding trick the Stanford guys wrote up came in quite handy.

Here’s the step by step.

1) Attacker emails a special SWF to a Gmail account they control and locates the attachment download URL on google.com.
2) Logged-in YouTube user visits an attacker controlled page
3) Attacker forces their victim to authenticate to the attackers Gmail account (identify misbinding / CSRF).
4) Attacker embeds SWF from the Gmail account into the web page
5) Attacker now has read write access on YouTube.com as the victim's account.

Video:






Clever eh? :) I’m sure the Google/YouTube aren’t the only places where this particular scenario is still possible.

Many thanks to Rich Cannings and Chris Evans from the Google Security team who sheparded this along!

What’s important, Palin’s Yahoo Mail account hacked

That’s right, Alaska Governor and republican Vice-presidential candidate Sarah Palin's quasi-personal Yahoo Mail (gov.palin@yahoo.com) account was hacked into by the infamous group called “Anonymous”. While there are conflicting news reports on the incident’s authenticity - emails, screen shots, and family photos have been posted to Wikileaks as proof. If we assume the incident is real, there are so many ways a free WebMail account could be compromised – some more likely than others:

1) Password guessing / brute force attacks
2) Password recovery system flaw or website vulnerability
3) Network sniffers
4) Phishing scams
5) Insider (rouge customer service representation or software backdoor)
6) Operating System Malware/Spyware
7) Stolen hardware
8) Lost backup tape (hah, as if free WebMail providers have backups!)
9) Use of a public computer

etc. maybe more I’m not thinking of.

For myself and the rest of the InfoSec industry the “how” is interesting, but its unimportant for everyday users like our friends, family, coworkers, politicians, etc. What they need to know is WebMail compromises could happen to anyone - even if they do everything “right” because security is largely out of their hands or impossible to behave perfectly all the time. Mistakes happen and the more high profile of a person you are the higher the likelihood you will be targeted.

Bottom line: DO NOT receive or store anything you don’t want read or made public on these “free” WebMail systems. They are NOT private. They are NOT secure. They are NOT safe. The same goes for Google Docs, social network private messages, online backup solutions, whatever. What they are is FREE and CONVEINIENT. The businesses that support them are not accountable for your privacy, security, or lack thereof. Read their EULA or ToS if you don’t want to take my word for it.

Monday, September 15, 2008

Let's talk Software Serviceability

Financial Times graciously invited me to write an opinion piece for their publication entitled "Learn from today’s software flaws to protect corporations tomorrow", where I discuss a bit about Software Serviceability. In the wake of Dan K's vulnerability announcement (and others like it), I couldn't shake the notion that no matter how hard to try to write perfectly secure code, given a long enough time line we'll always fall short. We will miss a bug, there will be a new attack technique, hackers will exploit our systems. To me this says our important systems must have speedy and adaptive security measures to identify threats as they happen and the ability to quickly service our deployed software (preferably within days or hours). Some systems have this capability, but it's too few and far between.

"So in the case of the issues found by Dan, Tony, and Alex it is hard to put a top-end market value on them, but consider that other less severe issues have sold for five and six figure sums. Would seven figures be out of the question? Will the next security researcher be influenced by the potential financial reward instead of giving it away for free? We know for sure that there will be a next time, because software is imperfect. Vulnerabilities will be found and long standing encrypting algorithms will be broken or at least weakened. And it’s difficult, if not impossible, to future-proof our code against attack techniques that don’t yet exist."

(Cancelled) / Clickjacking - OWASP AppSec Talk

“Clickjacking,” the presentation Robert “RSnake” Hansen and I had planned for OWASP AppSec NY 2008, has been postponed due to vendor request.

The premise of Clickjacking is that we know a lot about what JavaScript malware is capable of once a user comes in contact with an attacker-controlled webpage (or a page with their code on it) such as history stealing, intranet hacking, phishing with superbait, Web worms, browser exploit, and so on, but comparably little about what can be done with a captured “click”. Clickjacking gives an attacker the ability to trick a user into clicking on something only barely or momentarily noticeable. What could they possibly do then?

With Clickjacking attackers can do quite a lot. Some things that could be pretty spooky. Things also performed, with a fair amount of ingenuity, quite easily. Over the past couple of weeks/months RSnake and I have been completing our PoC examples to demonstrate the potential attacks and sharing the results privately with a few industry colleagues to obtain a third-party opinion. At the time, we believed our discoveries were more in line with generic Web browsers behavior, not traditional “exploits,” and that guarding against Clickjacking was largely the browser vendors' responsibility. Clickjacking is a well-known issue, but severely underappreciated and largely undefended, and we hope to begin changing that perception.

One Clickjacking PoC utilized an Adobe product with an attack technique they considered to be a critical issue, we just hadn’t realized it, so we narrowly avoided 0-day’ing them! Considering the short notice, Adobe requested additional time in case the browser vendors do nothing to prevent Clickjacking. High severity issue #2 in Internet Explorer 8 would have potentially given the aforementioned issue persistent qualities. There was/is a third issue with websites in general, which would have required all website owners to make an update, but that would obviously be impossible to do so. Again, better fixed by the browser vendors. With much of our technical details taken off the table waiting for patches and/or new safeguards we weren’t left with much to convey the true power of Clickjacking other than what’s already known.

Postponing our OWASP talk wasn’t an easy decision to make as we put a lot of time and effort into the presentation. We apologize to the attendees and had every intention of releasing mind-blowing stuff. At this time just about everyone out there using the latest versions of Internet Explorer (including version 8) and Firefox 3 is affected. Please be assured that as soon as we’re able to expose the information we will do so. In the meantime, the only fix is to disable browser scripting and plugins. We realize this doesn’t give people much technical detail to go on, but it’s the best we can do right now.

Adobe PSIRT (psirt@adobe.com)

More to come.

Thursday, September 11, 2008

My Picks for OWASP NY AppSec 2008

OWASP NY AppSec 2008 is only week away and is going to be big, really big, bigger than anyone expected I think. So big in fact that Tom Brennan, conference organizer, had to find a larger venue this week to accommodate all the attendees. The Park Central Hotel - 870 Seventh Avenue at 56th if you hadn’t already seen the updated page. What Tom and Co. also did was create a jam-packed line-up of sweet looking presentations. So much so that everyone will probably miss something they wanted see because of dueling talk. Oh well, that’s what video is for! While the schedule still seems to be in a bit of flux, I thought I’d list the stuff I’m most interested in and get my personal schedule going.

Disclaimer: If I don’t pick your talk it doesn’t mean I don’t like you or the material. :) It might be that I’ve already seen it and/or familiar with the content.

Day 1

Web Application Security Road Map - Joe White
Because its initiatives like this one that will eventually serve as a template for other organizations to follow.

Http Bot Research - Andre M. DiMino - ShadowServer Foundation
I have a soft spot for bots, seemed interesting, and wanted to see what data they have.

Get Rich or Die Trying - Making Money on The Web, The Black Hat Way - Trey Ford, Tom Brennan, Jeremiah Grossman
Well, you know, I sorta have to be there. :)

New Exploit Techniques - Jeremiah Grossman & Robert "RSnake" Hansen
One of those presentations exposing what Web attacks in the next 12-18 month will look like. We’ve purposely kept really quiet about what we plan to demonstrate, but its certainly going to make people a little nervous. :)

Industry Outlook Panel
Curious about what these folks have on their mind.

Multidisciplinary Bank Attacks - Gunter Ollmann
Good speaker and I enjoy hacking backs. :)

Case Studies: Exploiting application testing tool deficiencies via "out of band" injection
I have no idea, though appeared to be an interesting topic

w3af - A Framework to own the web - Andres Riancho

I'd like to see this tool demonstrated and understand what it can really do.

Coding Secure w/PHP - Hans Zaunere
Want to see more about how this is done. It can be right?


Day 2


Best Practices Guide: Web Application Firewalls - Alexander Meisel
A big toss up between this one and Pen Testing VS. Source Code Analysis, but had to go with the WAFs. Wanted to see what their point of view is and the guidance they're suggesting.

APPSEC Red/Tiger Team Projects - Chris Nickerson
Sounded cool, that’s about it.

Industry Analyst with Forrester Research - Chenxi Wang
It’s always good to know how the certain enterprises will be influenced

Security in Agile Development - Dave Wichers
As before, is this possible? And if so, how!? TELL ME!

Next Generation Cross Site Scripting Worms - Arshan Dabirsiaghi
cmon Arshan, no holding back. Give me the next NEXT generation XSS worms! :)

NIST SAMATE Static Analysis Tool Exposition (SATE) - Vadim Okun
Tools lined-up side-by-side and tested always interested me.

Practical Advanced Threat Modeling - John Steven
It's been a while since I attended a threat modeling talk, especially one targeted towards webappsec, which I hope this is.

Off-shoring Application Development? Security is Still Your Problem - Rohyt Belani

Uh yap it is, but what to do about it is the question. Hopefully Rohyt will answer that one.

Flash Parameter Injection (FPI) - Ayal Yogev & Adi Sharabani
Flash security is HUGE! HUGE I SAY!

Most of these speakers I've never seen present before, which I find refreshing. New talent, new ideas, and shows an emerging industry. Good luck everyone!

Monday, September 08, 2008

WASC Web Application Security Statistics 2007

For those hungry for more web application security vulnerability data, WASC has released its Web Application Security Statistics report for 2007. Under the leadership of Sergey Gordeychik and the broad participation by Booz Allen Hamilton, BT, Cenzic, dblogic.it, HP, Positive Technologies, Veracode, and WhiteHat Security – we’ve combined custom web application vulnerability data from roughly 32,000 websites totaling 70,000 vulnerabilities. Methodologies include white box and black box, automated and manual, all reported using the Web Security Threat Classification as a baseline. Excellent stuff.

Vulnerability frequency by types


The most prevalent vulnerabilities (BlackBox & WhiteBox)


Sergey did a masterful job coordinating all the vendors (whom we thank), compiling the data, and generating a report in a nicely readable format. I’d like to caution those who may read too deeply into the data and draw unfounded conclusions. It’s best to view reports such as these, where the true number and type of vulnerabilities is an unknown, as the best-case scenario. There are certainly inaccuracies, such as with CSRF, but at the very least this gives us something to go on. Future reports will certainly become more complete and representative of the whole as additional sources of vulnerability data come onboard.