A Gmail exploit which might be abused to allow domain hijacking has reared its ugly head once more.
The reported vulnerability revolves around the potential ability for hackers to create a malicious filter without needing to obtain the login credentials for a Gmail account. A flaw of this type hit web designer David Airey back in December 2007. Security watchers thought that Google had a handle on the problem, but now it seems that this confidence might have been misplaced.
The exploit kicks off by tricking surfers into visiting a maliciously constructed website. This site uses cross-site request forgery trickery to set up a filter on a targeted Gmail account which forwards email to a hacker's account while deleting it from a victim's inbox. The exploit involves stealing a cookie and creating a fake iFrame with a URL containing the variables that instruct Gmail to create a filter, as explained in greater detail here.
The creation of a malicious filter means, for example, that if a Gmail address is used as the contact details for domain registration then black hats can use a domain host's password reset features to hijack an account. The host sends account recovery instructions to a compromised account which forwards these emails to a hacker. Marks are left none the wiser, because the malicious filter means that tell-tale emails are deleted from their account before they get a chance to read them.
Geek Condition posted an explanation of the possible exploit, using password recovery and account hijacking at GoDaddy as an example, here.
ReadWriteWeb has a time line on the history of this type of attack here.
The most straightforward way to defend against the attack is to avoid using Gmail as the contact email address for sensitive accounts, such as those held with domain registrars. Use of the Firefox NoScript extension, to block exploits, and regularly checking Gmail filters for potential malfeasance would be sensible precautions. To fix the flaw, Geek Condition suggests, Gmail needs to change cryptographic credentials after every request rather than just after every session. ®