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.

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.

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)

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.

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

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.

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.

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.

The buzz was on about google buzz sharing your list of contacts (which they then quickly fixed in their casual we-did-nothing-wrong-these-are-not-the-droids-you’re-looking-for mind trick).

Readers of this blog remember when google calendar let you see the full name behind every gmail address. At that time, google ignored, then decided there’s nothing wrong with that feature, then fixed it. Only it still works, on other google services. Of course, these aren’t the droids I’m looking for.

Well, here’s a method to DoS a google group user; it was discovered by Shachar Shemesh of lingnu about 18 months ago, who told google and was answered with a strong silence. With google the only disclosure seems to be full-disclosure, so with apologies to you google-group users out there, here is the outline of the attack below.

DoS’ing google groups
Domain-Key is a good method to prevent spam from coming in, as well as preventing unwanted emails from being handled if they are sent through “the wrong” SMTP server.

Google has taken domain-key a step further, with their Domain-Key and Google Groups combo. In this combination, if an email is sent to a Google Groups from an SMTP server who is not listed in the Domain-key record, that email will be banned from writing or accessing the Google Group in question.

The banned user will no longer be able to write or read from that group, will not be able to “undo” this change as emails to Google’s technical support regarding this appear to go unanswered.

From this background, the attack seems clear. A malicious attacker can get pretty much anyone banned from a certain Google Group.

Steps to reproduce:

• Subscribe to a Google group.

• Look for a victim (Anyone posting to the group from a gmail.com account is fair game).

• Configure your email client to send emails with a “From” field that matches this email address, and use an SMTP that is not one of those authorized by the domain key. Your ISP’s SMTP servers will probably suffice.

• Use this configurations to send an email to the group. It doesn’t really matter what the email content is, but I recommend making it look like a genuine email to make is harder to filter (and raise ‘plausible deniability’ in case someone comes asking questions).

As a result:
The victim will be automatically banned from the group.

He or She will receive no notification of that fact: not to the fact he or she was banned, and not even to the fact that the email he or she supposedly sent failed Domain key verification.

The victim will cease to receive emails from the group. They will only find out about it if they try to send an email, at which point they will receive a brief and unhelpful message saying they were banned, with no explanation why and no means to appeal.

Trying to access the group from the web site will result in a “you are banned” message, again, with no helpful information on why the ban was instated nor how to appeal. It is a curious point that even information that is publicly available without registration, such as the group’s archive or description, will be blocked. They will have to sign out of Google to be able to see it(!).

The best means to appeal she is likely to find is “Google Help”, which points to an email address where past experience shows the request email will be unceremoniously ignored, just like Shachar’s email notifying google of this vulnerability.

My wish for 2010: I want this guide to be taught in CS classes to developers everywhere:

http://vrt-sourcefire.blogspot.com/2009/12/matts-guide-to-vendor-response.html

Happy new year everybody.

Occasionally, I see articles like this.

Hackers don’t, as a rule, need to go to such lengths to crack passwords. That’s because most of us fail to follow good security habits. A recent article on PhysOrg cites a study that found people are the weak link in computer security.

This is silly. People don’t need to “follow good security habits” unless they have “security” somewhere in their title. Security is a means to an end, and not the target. The target is to get the job done (or surf the web, or read your emails).

Saying this is not just silly - it’s also dangerous. When experts say “people are the weakest link in computer security”, they remove all responsibility from the security industry to make security better, and easier, for users. Why work on preventing brute-force attacks on passwords? Instead lets force our users to choose a 10 character password including at least 1 number and 1 letter of each case. Oh, and lets prevent those walking security hazards from saving the password in the browser on their malware infested machines. Yeah, that’ll teach them. The article over at discovery.com suggests I use e$4WruX7 as a password - a most helpful advice if I ever saw one. Here’s a better suggestion for you Jonathan: have the system lock out for 24 hours after 3 failed tries.That will make guessing a simple 6 digit-only PIN take more than 450 years.

Enough with this.  Users are not the weakest link any more than drivers are the weakest link in driving accidents. Sure, if we remove users (or drivers) from the equation, that solves all our problems. But since we can’t do that, lets focus on making seat belts, and airbags, and warning systems. Or easier (not harder!) password systems, better protected servers and better user interface.

Here’s a weird spam I got last night:

Hello

The route taken through Customs is mainly determined by your point of departure and whether you are bringing into the country more duty payable goods than your free allowance. For those passengers who have flown in from outside the European Community (EC), their baggage will have a white tag and they must pass through either the Red or Green channel according to the amount of duty free goods they have. Those passengers arriving from countries within the EC should use the Blue channel, and their baggage will have green-edged tag.

As part of our routine check and based on the above, we have a consignment in your name; you are advised to come to the office address below

Customs office
Terminal 3
Heathrow Airport

You are required to come with the following:
1. Your ID
2. Diplomatic Tag either white or green-edge tag.
3. Non Inspection document

Your appointment time is 10am GMT, failure to comply; we will have over the matter to Metropolitan and the FBI. I am the officer in charge of your matter.

Thomas Smith
UK Customs
Heathrow Airport

It’s weird, because it contains no advertisement, and no links. There’s nothing “encoded” in it -  it seems to be an old version of this notice.

So why would a spammer waste valuable botnet cycles on sending me the email? The only explanation I could come up with is “a boy who cried wolf” attack. You send this email a few times, and the Baysian filtering systems train themselves that this is a good email (i.e. “ham”). Most Baysian spam filtering systems have a loopback mechanism where spam email is used to train the system further, and ham email is used to teach the system what “good” email is. If this email is seen a few times and considered ham, spam filters will accept something similar to it that contains a link. That link, can be the spam or phishing attack.

Another guess is that it’s simply used to verify email addresses - you read that a scary Customs agent from Heathrow wants you in his office first thing tomorrow morning, and you quickly reply to ask what it’s about; the spammer (whose reply-to address is different than the “From”) gets a confirmation that your email address is valid, maybe with some more details like your phone number. This is a plausible explanation but it seems like too much hard work just to get some valid email addresses.
Any other guesses?