Network News

X My Profile
View More Activity

Flaws in Financial Sites Aid Scammers

Most major U.S. financial institutions have made a noticeable effort over the past year to educate customers about the dangers of online "phishing" scams that use e-mail lures to trick people into giving away their personal data at fake bank Web sites. But according to research commissioned by Security Fix, many of these same institutions still don't do enough on their end to prevent scammers from exploiting programming flaws in their sites to steal customer credentials or otherwise swindle consumers.

Over the past two weeks, I worked with Lance James, chief technology officer for Secure Science Corp. and an expert on phishing attacks, to find and report a large number of such flaws in high-profile banking and e-commerce Web sites. The sites we looked at all were vulnerable to what are known as "cross-site scripting" (XSS) attacks, which occur when Web sites accept input from the user -- usually from something like a search box or e-mail form -- but do not properly filter that input to strip out or disallow potentially malicious code.

Phishers and online scammers exploit these types of flaws to make their scams appear more legitimate, because XSS vulnerabilities allow the attacker to force the target site to load content from somewhere else. A typical XSS attack usually goes like this: The bad guys send out e-mails designed to look like they were sent by the recipient's bank. The e-mails instruct recipients to click on a link and update their account information. Instead of directing them to a purely fraudulent site -- i.e., the hacker's own copy of a real login form -- the link puts the visitor on the bank's actual Web site, thereby giving it a legitimate URL. The page, however, has been manipulated to display content controlled by the attacker.

One XSS that James found recently at Visa.com uses a flaw in Visa's site-search function to load a sample login page from an external site. (That is just a gross example; James could just as easily have copied the HTML code from Visa's own login page, changed it so that the data went to him, and inserted the altered code from his site.)

Within a few minutes of searching, James found an identical flaw at the Web site of JPMorganChase.com. Notice that the name in the browser address bar shows that the visitor is indeed on Chase's site. Again, the content could have been anything: a login page, a request for the user's bank account number and mother's maiden name, or a script that that redirects the user to any other Web site.

Banks and e-commerce sites are not the only ones vulnerable to XSS exploitation. Even information-only sites -- those that hold no real financial or personal information about consumers-- can be leveraged to trick people. I have received quite an increase in penny-stock spam lately, the kind that fraudsters use in pump-and-dump scams to drive up the price of extremely cheap stocks through false and misleading statements.

Imagine how much more successful one of these spam runs could be if curious investors were shown such bogus statements displayed on the Web sites of the American Stock Exchange or the New York Stock Exchange? That's precisely what would be possible with the vulnerabilities James found on both Nyse.com and Amex.com.

In each screenshot, you can see that the link we followed loads the real site and then loads video content from a third-party site on top of it -- in this case from a rather humorous and apropos service at Justgotowned.com. Once again, these are merely examples.

A skilled attacker could completely redesign that entire page to show whatever he wanted. (The Amex.com screenshot does not include the address field because that exchange has not yet fixed the flaw. Amex spokeswoman Mary Chung said the company was in the process of doing so, and the folks at Nyse.com corrected their XSS problem Wednesday night.)

We found similar flaws at eBay, Nasdaq.com, BankofAmerica.com, American Express and Barclays, to name just a few others. One interesting XSS vulnerability was found at Microsoft.com, in a rather odd place: the page Microsoft uses to validate whether the copy of Windows you are using is registered and legitimate. Online criminals are constantly spoofing e-mailed security advisories from Microsoft in an attempt to trick people into installing malicious software. With XSS, attackers can put their download links right onto Microsoft's site.

I know what some of you may be thinking: "Wait a second, Brian. Smart consumers would know to look for an "https://" in front of a login page, or examine the site's security certificate to ensure that the site is in fact the bank they think it is and that it's using secure sockets layer (SSL) technology to safeguard the transmission of login data."

Maybe so (and they'd be smarter not to click on links that arrive in e-mail, period). But last week, Web site monitoring and security firm Netcraft posted a fascinating writeup on a scam e-mail that used an XSS flaw at Paypal to present visitors with a fraudulent login page on the company's legitimate SSL-protected site -- https://www.paypal.com.

Rich Miller, an analyst with Netcraft, said he is constantly surprised that these sorts of flaws exist because the banking industry always talks about how hard it is working to defeat phishing attacks. "Customer awareness is good," Millers said, "but the flip side of that is you have to work just as hard to secure your own Web site."

If there is a silver lining in all of this XSS madness, it's that for the most part, phishers have been content to try to scam online banking customers by directing them via e-mail to wholesale counterfeit sites, said Dan Hubbard, senior director of security and technology research for Websense, an anti-phishing and e-mail security company.

"We've seen a several attacks in the wild that utilize [cross-site scripting flaws] on banking sites, and it's definitely a big future threat," Hubbard said. "However, right now there is just so much low-hanging fruit for these guys that it's kind of not needed."

It's worth noting that as I tested some of these XSS flaws at various sites, Netcraft's anti-phishing toolbar -- which I have installed on the version of Firefox I have on one of my home PCs -- actually alerted me whenever I clicked on the links, noting that the technique is commonly used in phishing attacks.

Update, 12:24 p.m. ET: I've heard from a few people who were concerned that I was pointing out links to live exploits in the pictures in this blog post. Rest assured that in any of the pictures above, I have only included a view of the address bar in cases where the featured institution had already fixed the problem.

By Brian Krebs  |  June 23, 2006; 10:45 AM ET
Categories:  From the Bunker  
Save & Share:  Send E-mail   Facebook   Twitter   Digg   Yahoo Buzz   Del.icio.us   StumbleUpon   Technorati   Google Buzz   Previous: Lessons Learned from the 'Leaves' Worm?
Next: Security Update Available for Winamp

Comments

Re SSL: in fact it has been recently documented that a very large number of banks do not use SSL to protect the login page. Instead they serve the login page in the clear, and have the login form post to an SSL page. While this does effectively protect the credentials in transit over the network, it fails to assure that you are viewing the bank's true login page in the first place. An attacker can substitute a false login page and have it post wherever he likes, ultimately redirecting the user to the real login page so that everything looks perfectly normal.

People who would comment that this is not a problem (including a lot of financial institutions, apparently) do not understand the threat. Go read and understand the following page and its reference and discussion before you dismiss this:

http://www.schneier.com/blog/archives/2006/06/bad_security_ev.html

Fortunately I find that while some financial institutions I deal with engage in this brain-dead practice, I can work around it by submitting an empty or bogus login initially in order to end up on an SSL-secured version of the login page.

Posted by: antibozo | June 23, 2006 12:43 PM | Report abuse

I can see it now:

Dear Windows User,

It has been reported that you are using an illegal or unregistered copy of Windows XP. Please visit this link to validate your version of windows. You have 48 hours to comply or our legal department will be contacting you.

Microsoft Anti-Piracy Group.

Ouch.

Posted by: Fred | June 23, 2006 2:44 PM | Report abuse

From the article above:
===========================================
"Web sites accept input from the user -- usually from something like a search box or e-mail form -- but do not properly filter that input to strip out or disallow potentially malicious code."
===========================================

Which is basic php/mysql or asp/MS SQL security by *competent* web designers/programmers. If a web designer/programmer isn't checking the values and strings of search fields to stop bridged code to be sent via POST, they aren't fit for the job and should be barred from the profession outright. Doesn't matter if the site has a 2056k encryption if anything can be delievered to the database via the input box!!

And web site owners need to be educated that site security is an ever going update job (like anti-virus updates). Can't just shell out $2000+ for a site, then think it'll last for months without code tweaking too (let alone database optimization and security -- the real danger as once that's hacked and cracked everything can be exploited or lost). Phishing is a concern for end-users, but the main problem is database exploits and hijackings.

SandyK

Posted by: SandyK | June 23, 2006 4:09 PM | Report abuse

Unfiltered web forms are much more dangerous than just acting as fronts for Phishing, they can be used to attack the backend database and download data. For instance, entering a logical expression that returns the value "true" instead of a password can in unfiltered simple lookup systems result in an authentication.

Posted by: Dave H | June 23, 2006 4:09 PM | Report abuse

XSS attacks are usually made against PHP scripts - its a monoculture problem. Everyone uses linux apache mysql PHP, though java also cops it of course.

You can spam these attacks onto the comments section of blogs, due to various massive security holes in various blog software, so that the end user looks at a discussion of anti fraud techniques, and gets his bank session cookie fixed.

To prevent them, any time variable data, from user input or from the database, is displayed to the user it should be sterilized, either by casting to numeric type or by htmlentities

: : echo $value

is a security hole, because the contents of $value will be interpreted as code by the client's browser.

: : echo htmlentities($value)

is safe against XSS, because $value will appear on the client's screen as a string, making the attack visible and ineffectual.

Similarly everything sent to the database needs to be sterilized.

: : $query = sprintf("SELECT * FROM users WHERE
: : user='%s' AND password='%s'",
: : mysql_real_escape_string($username'])
: : mysql_real_escape_string($password'])
: : );

to protect against sql injection.

As a half assed effort to protect programmers from themselves, php servers are often set up to apply addslashes to all user input, which fails to stop these attacks, while causing garbage to appear in your display. To protect against this protection, clean up all input from the user with

: : if (get_magic_quotes_gpc()) {
: : $lastname =
: : striplashes($_POST['lastname']);
: : } else {
: : $lastname = $_POST['lastname'];
: : }

if the input is supposed to be non numeric. If it is supposed to be numeric, cast it to to numeric.

Validate all input in your script, server side, even if it is supposedly validated client side.

I believe that absent these protections, your software will fall to attack, with these protections, will work.

If PHP was a Microsoft product, everyone would be whining that it is Microsoft's fault for not protecting us from ourselves.

Posted by: James A. Donald | June 26, 2006 5:36 AM | Report abuse

Another attack, to which a great many sites are vulnerable, is session fixation. The scammer fools the victim into using the scammers cookie, so when the victim does a legitimate login to the legitimate web site, the scammer is also logged in.

To prevent this, the website programmer should never raise the privilege level associated with a cookie. Instead, on a successful login, the website should issue a new and unpredictable cookie with a higher privilege level.

Posted by: James A. Donald | June 26, 2006 5:46 AM | Report abuse

Do not follow any instructions from any e-mail requesting you to update your secure info and only access your secure online accounts using a hardware type of authentication security solution.

Posted by: Mike | June 26, 2006 8:53 PM | Report abuse

James A. Donald wrote:
===========================================
"If PHP was a Microsoft product, everyone would be whining that it is Microsoft's fault for not protecting us from ourselves."
===========================================

Now just have the whole LAMP or WAMP series secure out of the box (with included IDS), and it'll be wonderful.

Why I dislike opensource: Apache 2.2.2 and OpenSSL for WAMP (there goes the idea of testing offline pages for security!). Still no fix, just a manual install if you want to risk installing OpenSSL and it not working right. Then trying to get Apache 2x to work right with any php accelerator (well anything but stock or commercial $$$$ Zend). And to add insult to injury, add PHP 5x and Mysql 5x and pray each works well with each other (knowing full well too many older scripts break in 5x, yet using 4x you expose your rig to more security exploits). :cry:

Then folks wonder why frustrated folks just turn to MS products -- they cost, and yes they're targeted by bots and crackers, but they at least work with very good anti-virus ware (can't stand CLAM), IDS ware that's enterprise strength, and uses a much better and faster database (and certification training is more uniform and available).

SandyK

Posted by: SandyK | June 27, 2006 12:10 AM | Report abuse

Great article on phishing, namely the PayPal issue. E-mails requesting an update of my account(s) appeared legit. I reported this to PayPal and I got a response that any more e-mails requesting personal information should be directed to spoof@PayPal.com.
It was easy in my case since I've never used PayPal, yet I wonder how many people got taken.
The penny stock issue is another one that manages to get in my e-mail acounts. Easy to delete, yet disturbing, especially since my e-mail address is not correct.
In closing, congrats to Brian Krebs for writing pro-active articles on these subjects.

Posted by: edm | June 27, 2006 12:05 PM | Report abuse

The comments to this entry are closed.

 
 
RSS Feed
Subscribe to The Post

© 2010 The Washington Post Company