Sonicwall Vulnerability Fixed

A month ago I complained about Sonicwall and google brushing us off when we reported vulnerabilities to them. The good news: Sonicwall has since contacted us, acknowledged the problem and is now rolling out a fix.

Was I too harsh on Sonicwall? It was hard to get their initial attention, but once we did they cooperated in an exemplary way. I’m not fooling myself to think any researcher that will notify them of a problem will get the same level of attention, but obviously they do give a damn, and maybe security@sonicwall will be open for notifications from now on.

CAPTCHA bypassing for profit

Did you wonder what this is used for? The following FAQ may give a hint:

Hi! I want to bypass captcha from my bots. Bots have different IPs. Is it possible to use your service from many IPs?

We have no restrictions about IP: with DeCaptcher you can bypass CAPTCHA from as many IPs as you need.

In other words: Just used a Virus to break into thousands of botnet computers and now you are not sure what to do? These guys will help you take the next step and set up myspace/facebook/gmail/twitter accounts while bypassing the CAPTCHA and you can then use that to spam the world. Thank you DeCaptcher for giving the Internet such a valuable service.

Why a 27 character password is less secure than an 8 character one

The Russians obviously did not read my earlier posts on why longer passwords are often less secure than shorter ones.
So they forced their agents to use a 27-character password which was easily retrieved by the FBI… since it was written on a piece of paper.

The time it takes to break a 27-character password: a few hours (going through the post-it notes and paper scraps)
The time it takes to break an 8-character password: 242 Days (assuming uppercase/lowercase letters only, brute forcing 10,000 passwords per second).

(via Bruce Schneier. Password recovery calculation time here)

Why Is Free Vuln Disclosure so Damn Difficult?

Xyberpix described how difficult it is to disclose vulnerabilities to ZDI and iDefense. But even after you sold it, the process is just beginning. Sure, the researcher gets paid and he is free to resume his work, but the work us, the vulnerability coordinator, just begins.

We recently received 2 disclosures to our SecuriTeam Secure Disclosure program for Sonicwall and google vulnerabilities. We received sponsors for both vulnerabilities which means there is a commercial organization out there that was willing to pay the researcher for their efforts. That part ended well for the researchers.

Now both organizations want the vendors to patch up. Sounds easy, right? We are giving Sonicwall and google free information about security holes in their products, and want nothing in return except for them to fix it.

Well, it’s damn difficult.

Google is always difficult when it comes to security. When I reported an information disclosure vulnerability in google calendar they ignored me, then sent their PR person to say “it’s a feature”, then silently fixed it claiming it was never there. Dealing with google on security issues is like talking to a girl that speaks a foreign language. But more on that later – lets start with Sonicwall.

Wouldn’t you be expect security vendors to be more aware of security problems in their products? Well, for the last few weeks we’ve tried to bang every door, calling in personal favors to tell Sonicwall (for free, let me remind you) about a security hole in their product.
Why bang every door? Because they won’t talk to us since “we’re not Sonicwall customers”. We can’t open a support ticket and they won’t give “us” support. security@sonicwall? yeah, right. Even good friends couldn’t help. The system will not accept a report from non-customers.

I guess our only course of action is to pay Sonicwall money to let them know about their vulnerabilities. I wonder if that’s Sonicwall’s long term strategy for profit? BTW, if you work for Sonicwall and can help, please contact me – but keep in mind paying Sonicwall for telling them about their own security issues is not a part of our plan.

Back to google. The story there is simple and boring. It’s not a bug, it’s a feature. In fact, every browser has this problem, errm I mean feature. In fact, it’s been proven you can execute javascript on the chrome user’s browser so we’ll leave this open as well. If the stupid web app developers can’t solve this we certainly aren’t going to help them.
But why am I boring you with the broad strokes, go read the discussion:
http://code.google.com/p/chromium/issues/detail?id=46795. Nothing we haven’t seen with previous google security bug handling, just ask this guy.

Yes, it is 2010, and we are still talking about Vulnerability Disclosure to vendors. I guess next we’ll be arguing if heap overflows are exploitable.

Update: We were contacted by Sonicwall and the bug will be looked at. Hopefully security@sonicwall will start accepting submissions from non-customers.

KHOBE: Say hello to my little friend(*)

Guess what? You personal firewall/IDS/Anti Virus/(insert next month’s buzzword here) isn’t going to save you from an attacker successfully executing code remotely on your machine:
http://www.zdnet.com/blog/hardware/update-new-attack-bypasses-every-windows-security-product/8268

So no, it’s not the doomsday weapon, but definitely worthy of the Scarface quote in the title.
This isn’t surprising, researchers find ways to bypass security defenses almost as soon as those defenses are implemented (remember non-executable stack?). Eliminating vulnerabilities in the first place is the way to go, guys, not trying to block attacks hoping your ‘shields’ hold up.

(*) If you’re reading this out loud you need to do so in a thick cuban accent

T-Mobile phishing camp

Cory Doctorow shares his experience of being ‘phished’. I had a similar experience, only in reverse.

As I’m waiting to board a flight, my phone rings and someone claiming to be a T-Mobile rep is on the other side.

“You’ve been using your phone a lot” she says

Yes, I spent a week in China and the roaming charges are especially high there.

“Well, you are over $2,000 in your phone bill”

Well, thanks for letting me know. When the bill comes I will be happy to pay it.

“No, you need to pay it now; it is higher than your monthly average and we need to collect the payment outside your monthly billing cycle”

Fine. I will call the billing center once I get back to the office tomorrow

“No, you need to pay it now”

I am just about to board the plane. Call me in 3 hours when I land.

“Sorry, I need to collect a payment or we will suspend the account”

Fine. Bill me. You have my credit card details on file.

“No, we need you to provide them again as proof that you are ok’ing the billing”

Hmm… This is beginning to sound like the most unsophisticated phishing attack ever. You need my credit card details? Now? Can’t wait? Ok. Give me your number and I will call you right back and give you my CC.

“This line is for outbound calls only. There is no direct number back to me”

No problem – I will call the t-mobile 800 number and ask for your department.

“They cannot transfer you to me”

Then how do I know you’re a real T-mobile rep and not someone out to get my credit card number?

“Well, how else would I have known your charges this month were especially high?”

At this point I burst out laughing and since boarding is about to end I give her my full credit card details. VISA will take the loss on that one, but who will save me from the embarrassment of ‘securiteam blogger falls victim to the most amateurish phishing attack in history”?
I land, and log online to my t-mobile account, and am shocked to see a bill of $2,500 that is marked as paid. It really was T-Mobile.

Somewhere in Eastern Europe some guy is telling his boss: “Sergei, you’ll never believe this. The fake training material we planted at T-Mobile are actually being used. They are teaching their customers to be phished!”.

Phishing camp indeed.

Finally, a workable approach to web Single Sign On


In the last 20 years, practically all the large software vendors came out with Single-Sign-On (previously “PKI”) products that were supposed to give a single login that would give you access to all the resources on the network. As good as this idea sounds, in practice that almost never works. Why Single Sign On constantly fails in corporate environments is a mystery wrapped in an Enigma. But it just doesn’t.

On the web, it seems even more logical that a single login will give you access to all the resources, and yet the situation is even worse. Microsoft, google, yahoo, AOL, and now facebook have all tried their Single Sign On initiatives that ended up having users signing up to 4-5 different ‘single sign on’ services and typically just opting for the only single sign on method that works: Using the same username and password everywhere.

Before you ask, OpenID is not a single sign on solution – it’s an identification service. So with that out of the way, are we doomed to never have a workable option to web single sign on?

Well, it seems the solution was always there: in fact, most of us have been using it for a while. Your browser.

Done well, the browser can keep the username/password combination in a secure place, protected by a single password and encrypted on your hard drive. The only risk is a Trojan using your browser to log into web sites without your knowledge – but that’s a risk you have today with keylogger rootkits, so you are not worse off letting your browser save the password for you.

The only two challenges facing the browsers to truly provide an SSO experience were web sites like paypal that refused to let the browser save username/password information (though you could bypass that restriction with bookmarklets such as “Password Saver” on firefox) and the second challenge was just the convenience of needing to login instead of having the browser login for you, as you’d expect in a “real” SSO.

It seems that firefox has picked up the glove. In a recent blog post (http://hacks.mozilla.org/2010/04/account-manager-coming-to-firefox/) firefox announced an add on that will handle account management; likely not much different than what is done today, perhaps a bit more extended and automated. Facebook, google and some others won’t be happy about this move, but who cares. The best thing about this method of SSO is that you don’t need the site’s cooperation for it to work. In fact, as long as they don’t actively resist (e.g. by adding CAPTCHA’s) firefox can be the de-facto standard for account management in the not-too-far future.

Security Seal company sued by FTC

Lets start with the proper disclosure; we provide a Web Site Security Seal service which competes with ControlScan’s. That said, I’m not about to bash ControlScan but rather the poor practices of security seal companies giving out seals to whoever pays them without the proper security checks.

Some background: The FTC sued ControlScan for $750,000 for giving out security seals while not really checking the security of the web sites. This lawsuit and its verdict are good news: It means that services that give out seals need to be responsible for their actions; no more “scanless PCI” badges: if you give out a seal (and I’m looking at all you large domain resellers) that needs to stand for something – when customers see a seal that says “secure site” they need to know the site is secure.

Before you take out the pitchforks, sure – there is no way to verify with 100% certainty that the web site is “secure”. But vulnerability scanning is at a stage today where you can run automated scans and make sure the web site is “secure enough” – meaning it does not have any known vulnerabilities, doesn’t suffer from SQL injections or cross site scripting. If there is a zero day vulnerability in apache, I doubt it will be used against an e-commerce site – it is more likely to be used against a bank or the government. Fact is, over 90% of successful attacks use known vulnerabilities that would have been detected by any competent scanner. If the site is properly scanned and no vulnerabilities are found, this is probably as good as it’s ever going to get; and is definitely better than the chances of your credit card being stolen at a brick-and-mortar store.

What will happen with ControlScan is not really important. What’s important is that security seal providers will now have to stand behind their claims – the fact that the FCC went after a case like this, which is normally way below their threshold, probably means that someone is applying pressure on them; hopefully that will help clean up the act of some online scanning vendors.

Note: Complaint, Exhibits and final judgment here.