Category Archives: Security

Why you need a security@ address

Posted on by

If you run any kind of webservice, you should set up a security@yourdomain.com email address, display it prominently on your website and make sure it gets read by an employee with a technical background.

Not convinced? As a case study, check out this post on HackerNews. The OP said he had tried to report a security vulnerability at a messaging and voice services provided, but nobody would listen to him.

The suggestions ranged from full-disclosure to emailing the CTO. I pinged the official Twitter account of the company with a link to the thread, but they brushed it off. Ironically, the company even advertises their service as a security solution on their Facebook page.

After about two hours, a member of the ops team finally chimed in on HackerNews and the issue got addressed. A little later, they also got back to me via Twitter. But the damage was done: people started telling stories of unrelated bad customer service experiences and one person said they are going to evaluate a competitor.

With a security contact prominently visible on the website, the whole thing could have been avoided.

Gmail CSRF vulnerability explained

Posted on by

There has been the claim on the blog Geek Condition of a CSRF vulnerability in Gmail. The idea was that an attacker can automatically create a filter in the victims Gmail account to forward sensitive mail to the attackers email. A detailed proof of concept walks you through the steps of exploiting the alleged vulnerability. This attack was supposed to be linked to recent cases of domain theft. The story was picked up by various site, e.g. Heise. Today, Google denied the security hole. So who is wrong?

Indeed, if you follow the detailed instructions, you can craft a URL, which creates a filter upon visit, as long as you are logged into Gmail. This seems scary, but let’s have a closer look.

To create the URL, you have to obtain valid values for a number of parameters. The error of reasoning lies in this paragraph:

Obtaining the at variable on the other hand can be done by tricking a user into visiting a page that contains malicious code that subsequently steals a cookie from the user called GMAIL_AT which is the same as the at variable, just named differently. Once the cookie is stolen the malicious code creates a hidden iframe with a url containing the variables that authorize Gmail to create a filter for your account.

In other words, to create the filter, the attacker has to get the session id from the cookie. As the content of the cookie is only known to you and Gmail, that is not really a fair prerequisite. Once the cookie is stolen, you are pwned anyway. With a valid session id, an attacker can completely control your Gmail account. The creation of a filter doesn’t make much of a difference.

Indeed, Gmail had a CSRF vulnerability in September 2007. Google was upfront enough to note that fact in their post, but it has been fixed a long time ago. It seems that someone barked up the wrong tree in this case.

Don’t get me wrong, there are ways to steal the cookie. But complaining that you can create a filter with a valid Gmail session id is like complaining that you are able to open the trunk of a car if you can get hold of the keys. You could just as easily drive away with it.