SamuraiNet Blog

As far as I know this has not been patched yet.

There is a very simple solution to monitoring this problem. Simply adding your own filter with an alternative email address. I just tested this and while the email is sent away from your inbox, it is sent to both addresses. This way you will atleast have a record, and if you check that address more regularly it will act as a notification system.

The exploit is not quite as glamorous as that article depicts either. It’s a Cross Site Request Forgery vulnerability introduced by an improperly implemented token key-pair. As the author mentions, the token should be changed at each request, rather than each session. As mentioned in the article, both the ‘Session Authorization Key’, the token, and the ‘Unique Account Identifier’, which I assume is something like the session key are required. Neither is trivial. The session key would require a vulnerability, such as Cross Site Scripting or Tracing vulnerability, to be accessed. The token must be read from the page that you are posting ‘from.’ Because of JavaScript’s sandbox, this cannot be done through the use of an iFrame or AJAX request. It must be done from the client’s localhost or the domain, in this case Google.

Obviously it is possible, since Google has responded to the threat and proof has been shown of domains being stolen, but nothing new has happened here. It is simply a clever implementation of a few common tricks.

http://geekcondition.com/2008/11/23/gmail-security-flaw-proof-of-concept/

http://googleonlinesecurity.blogspot.com/2008/11/gmail-security-and-recent-phishing.html

Continuing on with my web application penetration testing series I will now go into the usage of RefControl. RefControl is useful in checking referrer-based exploits, such as CSRF.

RefControl

RefControl allows you to specify the referrer for a site when you view it. Accessed either from the Tools->RefControl options is the global list of all rules for all sites that you have set. Access from the right clicking menu are the current settings for the site you are visiting. If you have set no rules, you will be able to add in a new rule.

After selecting the RefControl options for the current site, you are able to add in your custom referer, send no referer, or have RefControl automatically send the root of the current site.

What use is this? With the tidal wave of CSRF exploits being found a tool that can help find these would be welcomed with open arms. This is where RefControl enters the domain. While referrer checking is not a hardened safe guard against CSRF many site still employ its use.  By setting RefControl’s custom referrer to an off-site referrer you are able to check forms and links with GET variables simply by interacting as you normally would. If the request goes through, that form or link should be inspected further. Sites using only Token Key Pairs might be vulnerable to this method of probing, but not vulnerable to CSRF itself. This is why it is important to continue inspecting after said vulnerability is found, rather than simply accepting it as a vulnerability.

Another interesting permutation of RefControl is setting the custom referrer to include SQL characters. Many sites check referrers and store then in a database for analytic purposes and this allows the penetration tester to check if those inputs are being validated also.