Don’t let scammers redirect customer anger at you

A recent edition of the RISKS digest reports on the receipt of an interesting phishing email. Like most phishing attacks, the email informs the reader that their bank account status (at Barclays Bank in this case) is in jeopardy. To keep their account in good standing the reader is required to log into the online banking service, and to facilitate this process they just need to click the provided link.

Normally this link takes them directly to the attacker’s site, configured to impersonate the legitimate bank site. To add legitimacy to the email, an attacker often tries to obscure the fact that the reader is being directed to their site instead of the real bank. They may use an IP address, a slight variation of the legitimate site’s DNS domain, a HTML hyperlink, or another method of obfuscation.

But this particular link actually did take readers to the legitimate Barclays Bank site, at least initially. Here is a safe sample link that mimics what was contained in the phishing email:

http://www.barclays.co.uk/cgi-bin/gotosite.cgi?location=%68%74%74%70%3A%2F%2F%77%77%77%2E%73%65%63%75%72%69%74%79%70%73%2E%63%6F%6D

As you can see, the link does point to Barclays Bank. But it requests a CGI script that is designed to redirect your browser to the URL contained in the ‘location’ parameter. And the URL in the location parameter is encoded to prevent you from seeing that it really looks like this:

http://www.barclays.co.uk/cgi-bin/gotosite.cgi?location=http://www.securityps.com

So, visiting this link does take you to Barclays, but also immediately redirects you (via a HTTP 302 response) to the Security PS Web site. An attacker might make use of this feature to convince an only slightly savvy reader that the link is safe to follow.

So a good question is why does Barclays support this feature? Barclays may have intended the cgi for use in site navigation, in which case the location parameter should only contain references to another page on their site. However, if they fail to actually constrain this functionality they end up supporting offsite links as well.

Barclays isn’t alone in having their application’s functionality abused by criminals. Both Visa and eBay fell victim to the same issue last year. They both eventually modified their application when the abuse received public attention.

To their credit, Barclays does try to educate its customers about phishing and other email scams: http://www.personal.barclays.co.uk/BRC1/jsp/brccontrol?task=articleFWvi2&value=9190&target=_self&site=pfs They specifically instruct customers not to click on any links they receive in emails purporting to be from Barclays. But try explaining this to an angry customer who thinks your Web site facilitated fraud against them.

While this certainly isn’t a critical risk – stealing credentials by exploiting a cross-site scripting attack on your site would be much worse – it is important to recognize that the feature has potential for abuse. Find out if your Web applications have a similar feature. If they do, we recommend that you eliminate or constrain the redirect functionality.