My Security Planet » ha.ckers.org web application security lab

ha.ckers.org web application security lab

Facebook Patents Social Feeds and I Patent XSS

Posted: February 26th, 2010, 3:10pm CST by RSnake

Tags: xss [edit]

In honor of the USPO’s decision to allow Facebook’s patent for social feeds I decided to patent XSS. Please pay up. You know who you are. Thank you.
Banks, Businesses, Viruses and the UCC

Posted: February 24th, 2010, 12:19pm CST by RSnake

Tags: General News [edit]

There’s an interesting post over at Krebs On Security talking about some poor company that is going bankrupt because TD Bank allegedly will not give them their money back after it was stolen out of their account. Now, I wish I could say this concept is totally foreign to me, but unfortunately this isn’t the first time I’ve heard this story. I’m under NDAs not to describe the people involved, or the bank involved, but the important details are nearly identical to this story. Why is this happening?

There is a little known code call the UCC (Uniform Commercial Code) that essentially says that if you are a business and you want to do wire transfers you are essentially to be treated as a bank. You are probably wincing right now, because it’s just as stupid as it sounds. Note that this is not true for consumers - but even if your business consists of even one person, you still are treated as a bank. As such, if your company has money wired out of it’s account, the bank isn’t to be held liable - or at least that’s been their argument. This is happening all the time, so why aren’t we hearing about it all the time? Well that leads me to the worst part of this story.

The banks have essentially two options if a company takes them to court. They can win the case, or they can lose the case. If they win, that leaves the company in question free to say and do whatever they want (as is the case with TD Bank above). If they lose the case, it essentially creates precedence and can open the bank to class action lawsuits to overturn the UCC. Either way, it’s a bad day for the bank. So they opt for the third choice which is to delay the inevitable. They make these poor businesses wait for sometimes years before they will begrudgingly settle for somewhere shy of the full amount. Sometimes companies just give up, and sometimes they take the money and sign the NDAs. Either way, that’s a much better outcome than letting something get litigated. So yes, those poor companies are getting the run around, and we don’t get to hear about it because at the end of the day they are all signing NDAs.

So, if you run a company, be prepared for the worst when it comes to how the bank is going to treat you if someone steals your money. There don’t appear to be any safeguards other than individual contracts you might be able to get your bank to sign and agree to. However, if anyone happens to work for a bank, and can guarantee that money held there will be treated just like physical cash (and reimbursed just like if it is stolen out of the vault), I’m sure companies would flock to you - I know a lot of small businesses that would like to know that their money is safe, and right now, it just isn’t with TD Bank and their ilk. In the meantime, I sort of hope some lawyer is salivating at the prospect of a class action suit.
Google Buzz Security Flaw

Posted: February 16th, 2010, 1:17pm CST by RSnake

Tags: xss [edit]

… Speaking of Google, I got an email from TrainReq (the same fellow who allegedly hacked Miley Cyrus for those who don’t keep up to date on your tween idols). The email was regarding an exploit against Google Buzz. It’s yet another example of bad input validation/output encoding by your favorite advertising overlords at Google. As you can see, nothing up my sleeves:

Click here to enlarge.

There’s four things of note here. Firstly it’s on Google’s domain, not some other domain like Google Gadgets or something. So yes, it’s bad for phishing and for cookies. Secondly, it’s over SSL/TLS (so no one should be able to see what’s going on, right?). Third, it could be used to hijack Google Buzz - as if anyone is using that product (or at least you shouldn’t be). And lastly isn’t it ironic that Google is asking to know where I am on the very same page that’s being compromised? Why on earth does Google think its systems are secure enough to trust them with that kind of sensitive information? Yes, bad guys can figure out where you’re located if you allow that function. Chinese dissidents beware! But if you have something to hide, you must be a bad guy, right, Eric?
Nevermind, I Was Wrong, Google Is Evil

Posted: February 15th, 2010, 4:07pm CST by RSnake

Tags: Webappsec [edit]

I’ve been waiting a while to do this post - several weeks actually since my original post. In that post, I applauded Google’s apparent interest in reigning censorship as “the first really truly non-evil thing I have seen Google do in years”. Since then, I thought it appropriate to give them some time to sift through the nuances of their blog post - you know, to give them the benefit of the doubt - of which I had many. I’m sure you remember just one month ago when Google was waxing on about how they were going to stop censoring:

We have decided we are no longer willing to continue censoring our results on Google.cn, and so over the next few weeks we will be discussing with the Chinese government the basis on which we could operate an unfiltered search engine within the law, if at all.

Well, according to The Register:

Google Chief Legal Officer David Drummond never said his company would stop censoring hot-button issues such as the Tiananmen Square massacre of 1989.

If that theory is true Google is essentially saying, “You were too stupid to read our post properly because clearly, our post means that we aren’t able to do so legally, so we’re still going to censor.” If that’s true why would Google wait to clarify such an extremely well publicized fauxpas in their own wording? Maybe they missed all those flowers at the Chinese office. No, I don’t believe that The Register’s theory is true - I think Google sincerely intended to pull out or get more support from the Chinese. However, I believe that Google is being stonewalled by the Chinese government - and for good reason. Google’s demands are impossible to comply with. But we all know that Google and China have been talking for weeks and we haven’t seen any movement other than China’s response to Hillary Clinton saying that they don’t censor (and if anyone still needs proof, email me and I’ll give you instructions on how to see it in action).

Google hasn’t stopped censoring anything, and they haven’t pulled out of China. They asked for a “few weeks” to have those talks, and it has been a few. So now we have to ask the question - does Google actually care about the Chinese people, or is it all about making money for the shareholders. We know that Google censors elsewhere in the world, it’s not just China, yet they’ve not even made mention of those citizens of the other nations. So we have to make the logical connection that Google is just acting in their own self interest and this whole China thing is a distraction from several other major issues, and has nothing to do with the best interest of people who are being censored. So now the real question is did Google do what it sent out to do?

And, so yes bravo, Google. Well done. You snowballed everyone as you stall for time trying to figure out what you want to do with your failing Chinese division. You spanked the Chinese government for hacking into your systems while you drew fire away from your crappy security around your warrant-less wiretapping system that you built into Gmail. So yes, I would have to assess Google’s incredibly calculated decision as a success, but not for the people of China or other censored peoples around the world. It’s back to business as usual at the Googleplex. And so yes, Google, you can keep slinging your ads well into the future. But I have to ask - at what cost?
Phishing With Google Wave

Posted: February 10th, 2010, 6:20pm CST by RSnake

Tags: Webappsec [edit]

Hat tip to cyberlocksmith for this post. He pointed me to a good article on how to phish Google Wave users using malicious gadgets. This is precisely what Tom Stracener and I were talking about in our presentation at DefCon and Blackhat a few years back - except this is for Wave instead of iGoogle. Either way the point is the same - when you let other people control content that is embedded in your site, you are at the mercy of whatever they chose to do within that gadget. In this case, they can pop the user out of the iframe and present them with a duplicate of the sign-in page. The vast majority of users would fall for this kind of attack too.

I really don’t mean to harp too much on Google specifically for this stuff (in as much as I have countless times in the past held them accountable for their crappy security). There are lots of other companies and websites that are moving to user supplied gadgets in an iframe as if that makes them safe. Maybe some variant of HTML5 + some trickery can solve these problems, but there’s a lot of legacy users who won’t be able to support those standards for a good long while. In the mean-time, we just continue to see more vulnerable code being outputted by Google and their peers and the only saving grace is that no one has yet decided to take advantage of their security flaws. Scary. But I’m sure a blacklist will solve their problems if and when they do get attacked, right? Right?
Releases.mozilla.org SSL and Manual Update Fail

Posted: February 4th, 2010, 9:37am CST by RSnake

Tags: Webappsec [edit]

I did a presentation at the DefCon Comedy Jam about how users manually validate updates for Firefox was just a total mess from a security perspective. It had a lot to do with the fact that they are using round robin DNS and relying on the good will of a lot of dispirit sites to do their hosting for them. Well, I’ve been wondering more and more about how I may or may not be able to download these releases and verify them manually in a secure way. So I did a few checks and here’s the IP space I found and the status of what their SSL/TLS ports were when checked yesterday:

63.245.208.152 (live but with SSL/TLS mismatch)
128.61.111.9 (connection refused)
129.101.198.59 (connection refused)
131.188.12.212 (connection refused)
149.20.20.5 (connection refused)
156.56.247.196 (connection refused)
202.177.202.154 (connection refused)
204.152.184.196 (connection refused)
204.246.0.136 (connection refused)
216.165.129.141 (connection refused)
64.50.236.214 (connection refused)
64.50.236.52 (connection refused)
129.101.198.59 (operation timed out)
155.98.64.83 (operation timed out)

So only 1 out of 14 even have SSL enabled. Okay… well today, I took a little spin on SSLLabs and I found that the one site that does have SSL enabled (63.245.208.152) has a SSL/TLS mismatch error for videos.mozilla.org. I mean… seriously! If your browser goes to https://releases.mozilla.org this is sort of what’s happening under the hood:

$ telnet releases.mozilla.org 443
Trying 202.177.202.154…
telnet: connect to address 202.177.202.154: Connection refused
Trying 204.152.184.196…
telnet: connect to address 204.152.184.196: Connection refused
Trying 204.246.0.136…
telnet: connect to address 204.246.0.136: Connection refused
Trying 216.165.129.141…
telnet: connect to address 216.165.129.141: Connection refused
Trying 64.50.236.214…
telnet: connect to address 64.50.236.214: Connection refused
Trying 128.61.111.9…
telnet: connect to address 128.61.111.9: Connection refused
Trying 129.101.198.59…
telnet: connect to address 129.101.198.59: Connection refused
Trying 131.188.12.212…
telnet: connect to address 131.188.12.212: Connection refused
Trying 149.20.20.5…
telnet: connect to address 149.20.20.5: Connection refused
Trying 155.98.64.83…
telnet: connect to address 155.98.64.83: Operation timed out
Trying 156.56.247.196…
telnet: connect to address 156.56.247.196: Connection refused
Trying 63.245.208.152…
Connected to releases.geo.mozilla.com.
Escape character is ‘^]’.
^]
telnet> quit

Yes, after a minute of trying your browser will eventually find the one HTTPS server - or it won’t (sometimes it just gives up). So then in poking around within my Mozilla config I saw a reference to http://en-US.www.mozilla.com/en-US/firefox/3.5.7/releasenotes/. So I switched to SSL/TLS with this link, because I like being secure, and I get a SSL/TLS warning as well. These are the kinds of things that make Firefox incredibly unsafe to manually download and verify the binaries if you are in a hostile environment. And I’m just scratching the surface compared to my presentation. How many of those 3rd party sites do you think can be exploited?
Accuracy and Time Costs of Web Application Security Scanner Report

Posted: February 3rd, 2010, 2:26pm CST by RSnake

Tags: Webappsec [edit]

Larry Suto is back with another report outlining the differences between some of the top web application scanners on the market. Before you get all uptight and start flaming me, I in NO WAY sponsored, encouraged or had anything to do with this test in any way. In fact, I only found out about it a few days ago. Not that I think that’ll stop the flame wars, but just direct your ire appropriately, please! Anyway, he took a different approach this time, and instead of running the scanners against something he had devised up to be used only in his own lab, he turned all the scanners on each other’s public test sites. You might think they should all fair fairly well since they’re all public and there’s nothing stopping them from testing to their heart’s content. But that’s anything but what he found. You can download Larry’s report here.

Some of the more interesting findings were that Burp Suite Pro (an extremely cheap product built by Portswigger - and a damned fine manual testing tool, I might add) fared better than Qualys or WebInspect when trained. I always loved Burp Suite! Larry’s commentary is particularly amusing as you go through it, with choice quotes, like:

Accuntix missed 31% of the vulnerabilities after training and 37% without training. This is a significant cause for concern as they should be aware of the links vulnerabilities on their own site and be able to crawl and attack them.

And…

WebInspect missed 66% of the vulnerabilities, even after being trained to know all of the pages. They missed 42% of the vulnerabilities on their own test site after being trained and 55% before training.

NTOSpider by NT Objectives came out in the lead with the best overall score of the application scanners tested (which included Acunetix, Appscan, Burp Suite Pro, Hailstorm, WebInspect, and NTOSpider). He also measured things like how long the various scanners take to configure, support and so on - all important things for companies about to make the big investment. This isn’t all scanners everywhere (notably WhiteHat is missing as is the newest player to the field, NetSparker who incidentally took it upon themselves to add themselves into the report after the fact, and other free web assessment tools, like Nikto etc…), but it’s a great start to a long future of heavily debated research, I’m sure. Love him, or hate him, Larry’s always got interesting research to share!

← January 2010 (8 items) March 2010 (7 items) →

My Security Planet » ha.ckers.org web application security lab » February 2010

Feeds

ha.ckers.org web application security lab

Facebook Patents Social Feeds and I Patent XSS

Posted: February 26th, 2010, 3:10pm CST by RSnake

Tags: xss [edit]

Banks, Businesses, Viruses and the UCC

Posted: February 24th, 2010, 12:19pm CST by RSnake

Tags: General News [edit]

Google Buzz Security Flaw

Posted: February 16th, 2010, 1:17pm CST by RSnake

Tags: xss [edit]

Nevermind, I Was Wrong, Google Is Evil

Posted: February 15th, 2010, 4:07pm CST by RSnake

Tags: Webappsec [edit]

Phishing With Google Wave

Posted: February 10th, 2010, 6:20pm CST by RSnake

Tags: Webappsec [edit]

Releases.mozilla.org SSL and Manual Update Fail

Posted: February 4th, 2010, 9:37am CST by RSnake

Tags: Webappsec [edit]

Accuracy and Time Costs of Web Application Security Scanner Report

Posted: February 3rd, 2010, 2:26pm CST by RSnake

Tags: Webappsec [edit]