Financial Sector Fail

The fail keeps rolling in. I'm not really sure what the story is behind this screenshot, but I'm pretty sure I can guess: A user notices that American Express's password policy forces weak passwords, then emails them to get more information. Amex responds with the following bit of creative writing:

I would like to inform you that our website has a 128 bit encryption. With this base, passwords that comprise only of letters and alphabets create an algorithm that is difficult to crack. We discourage the use of special characters because hacking softwares can recognize them very easily.

The length of the password is limited to 8 characters to reduce keyboard contact. Some softwares can decipher a password based on the information of “most common keys pressed”.

Therefore, lesser keys punched in a given frame of time lessen the possibility of the password being cracked.

Moreover, American Express is committed to protecting the privacy and security of all of our Cardmembers, both on-line and off-line. We believe that our current security measures, which include our sophisticated monitoring systems to detect unusual or fraudulent card activity, provide strong, ongoing protections for our Cardmembers.

This response may not make much sense to a non-security person, but to a security person, well... it still doesn't make much sense. 128 bit encryption makes passwords with just alphanumerics stronger than ones with a larger character set? Hacking software recognizes special characters easily? Deciphering passwords based on the most common letters? They wouldn't dare... is American Express really just using substitution ciphers to "encrypt" passwords? That is the only thing that vaguely makes sense.

This is absolutely unbelievable.

At least it would be, if I didn't have more of the same kind of stories. Fortunately mine deals with a local mortgage company, and not a $15 billion global financial services company. I sent them an email in early 2009 detailing about half a dozen issues with their website (an ancient payment and account tracking application), all of which I would rate as critical in any penetration test, and all of which could be tested unintrusively, on the client side. Things like predictable Session IDs (a timestamp, with a granularity of only seconds), password retrieval features (all you need to do is guess a username and the answer to the secret question and it echoes the password back), cross-site scripting, publicly available statements (a directory full of pdfs. Guess my loan ID (sequentially assigned), get my statements. If it's tax season, you get my SSN with it). Lack of two-factor authentication.

Bad stuff. Of course, you'd expect them to be happy to recieve a free assessment from somebody as distinguished as myself (okay Mikey, hold back the ego). My rates aren't cheap, after all. You'd expect them to at least fix things by now, but they haven't. Instead, I got an email detailing why the issues (which I had not only described, but also demonstrated to myself) would not work. The usual lies:

our #1 priority is the protection of personal information and we appreciate feedback we receive from our customers to continually improve and/or test that protection.

No, it isn't. Your #1 priority is making money from loans. You are a mortgage company, after all. If your #1 priority was security, you would be a security company.

we look at the user-id and question as the two-factor authentication. the system has been re-written (and will be implemented soon) to add a 3rd factor (ssn) and then the password will be sent to the email address on file or the user can have the option of setting themselves up again.

Oh that's good. Keep my SSN on file in the database with it. It's bad enough you're putting that data in the publicly-accessible reports.

[On XSS:] This is an area that is like a moving target. It is a high priority with us. You can also include xss cookie theft, hijacking sessions, etc. etc. we have several safeguards in place. i am not at liberty to discuss them since they are a major key to the security of our site

How comforting, you're one of those people who thinks "secret filter" is a solution for XSS. And yet, my XSS still executes. Every time. Even now, almost a year later.

[On Session ID Generation] This algorithm is extremely secure. Of course i’m not going to explain how it’s programmed. We also use hacker and virus proof servers. Once again, the algorithm in place will not allow this to happen. As i stated in my previous email the only place SSNs were visible were on the January 2009 statements, which we have removed even though we feel they were secure.

I'm tearing my hair out at this point. What algorithm is "extremely secure"? The one that takes a timestamp, and turns it into a Session ID? Remember, this was not conjecture, I actually demonstrated it for my initial email. The SSNs were only visible in the January statements, but they were never removed from the server. The links to the PDF files sure were, but all I have to do is take the link to the February statement and change a "2" to a "1". That's epic hax right there.

This shit pisses me off, and what's more, I don't have any reasonable recourse. My mortgage was sold to this company by the group I originally financed my house through. At the time, I did some research but never came up with a good answer of who to report the issue to (I'm no lawyer, but I believe this is a pretty clear violation of the GLBA). Even when I no longer have that mortgage, they're required by law to hang onto my personal data for several more years.

They aren't the first people to act negligently with my personal data, and they won't be the last. While writing this piece, I was registering a domain name on another screen, and while making the payment, I ran across more of the same stupidity, this time from my credit card company.

At that point, I couldn't help laughing.

Adobe Update Fail

Hot on the tail of Mozilla's fail, we get notification from Adobe. Apparently they forgot to fix a critical Flash Player crashing bug.

Really. They just forgot.

This is not okay. Ironically, Dan Goodin wrote a piece in The Register just yesterday, remarking that an overhaul of their security program is long overdue.

I think this pretty much confirms it.

Mozilla Malware Fail

Apparently Mozilla has been spreading malware in the form of a few user-submitted Firefox addons. They were infected with trojans, and some 4,600 people downloaded them. This fail doesn't suprise me- people have been talking about potential exploits from Firefox addons for years now.

I am a bit surprised that it was client-pwning malware, and not Chrome-based sniffers or keystroke loggers or something else that could work within the DOM. I have to wonder if any of those exist... Somebody should download all the extensions off addons.mozilla.org and do some static code analysis. Maybe I will, if I find myself bored in the next few weeks.

But you know what really grinds my gears? Here's the quote from Mozilla:

These were not originally detected with the anti-malware scanning tools that we have been using. We have since increased the number of scanning tools, and will be taking additional steps to minimize the risk of further incidents.

Now, I don't have much personal experience with the Mozilla team, and what I have had has been generally very good, but really? Your malware-scanning approach didn't work, so you decided... to add more scanners? Really? Do you think that's solving your problem?

I want to know more about these "additional steps," because I'm not sold. Considering this last round of screwups, I don't have a lot of faith in your scanning.

We Suck At Security

Disclaimer: This is a rant. It meanders. It rambles. It contradicts itself. It uses mildly dirty words. It alternates clumsily between idealism, cynism, frustration, ignorance, and brilliance. Read at your own risk, and don't complain if you don't like what I have to say. Feel free to discuss, but don't complain. By the time you read this, I probably won't agree with me either.

We suck at security.

A few months ago, I ran across a copy of Lincoln D. Stein's Web Security FAQ. It's an awesome document that first showed up around 1994. I tried to track down the original version, and the best I could do was 1.1.4, which was published December 1995. I even went so far as to contact the guy and buy a copy of his book (1997). The "current" version of the FAQ is dated 3.1.2 February 2002.

I probably first read that FAQ in the late '90s, but I wasn't a security guy then. I was just a crappy web developer with an unhealthy love of animated GIFs. If you've never read this document, print out a copy and put it on your kitchen table. Not only will you get a kick out of it, but there are some very interesting lessons to be learned.

A high point:

Q33: What CGI scripts are known to contain security holes?

Just including this question shows how small and non-interactive the web was back then. Only two CGI scripts are named explicitly, but I find it particularly funny that FormMail is listed. FormMail is basically a script that allowed us to put contact forms on our websites, process the results, and send them to our email inboxes. Early versions had gnarly code execution bugs- the kind of thing you find in every "Hacker Training" course, but rarely find in the wild anymore. You'd think that such a dated script wouldn't be an issue today, wouldn't you? You'd be wrong.

FormMail has been revised and rewritten hundreds of times, in practically every language in use on the web. FormMail.php is now a common one, as is FormMail.cgi (AKA FormMail.pl), which is included by default with every site on every cPanel installation. Both are vulnerable to XSS. This has been known for years, but people are still using it. It's not caught by any of those PCI/Web Security scanners that regularly certify cPanel-hosted sites. I've reported it to cPanel, and it's not being fixed. It's not being removed. Bad coders are copying bad coding practices from fifteen year old scripts. Splendid.

These things aren't getting fixed, but do you think this is wholly the developers' fault? Dead wrong. This is our fault.

A recent post to the web security mailing list said "who would be 'stupid' enough to click a malicious link like bit.ly/xxxxx?" This bugs the hell out of me. bit.ly is a useful service. Somebody has to be stupid to use a useful service? I click bit.ly links every day. bit.ly has its share of problems, but if our "solution" is expecting people to not click a link we're going to fail. Expecting J. Random User to understand how bit.ly can be abused in order to not be "stupid" on the web is equally moronic. It's not his fault, the web is just designed very, very wrong.

And it's because we suck at security.

The biggest thing we're currently doing well? We're making some things easier to do right than do wrong. The code execution bugs of the 90s are indeed getting rarer, because most PHP programmers are taught to be scared of backticks, and are given libraries for interfacing with third-party applications (rather than being asked to run ImageMagick as a shell command). Sure, it still happens, and more than I'd like, but it's happening far less than it was. Let's take a lesson from that.

Side note: If you're a developer and you haven't played with the OWASP ESAPI yet, why not make your life simpler while making your code more secure? Wave of the future, man.

Specifically, the issues I like to talk about here are what I call the "application boundary bugs". These are the things like CSRF, XSS, Clickjacking, even that stupid "XSHM" one that was "released" last week. In these attacks, the exploit stems from a webapp forcing a browser to do something to another webapp. Why does it work? Because cross-domain communication is a common, legitimate, insane, and unnecessarily necessary thing for a website to do.

You know what would fix that? Putting hard boundaries on web applications. Not this Same-Origin Policy bullshit, which is regularly bypassed with ease by attackers and developers alike. Not this zone crap, which makes the outdated assumption that the sensitivity of data is related to where it's found on the network. We need boundaries that cannot be crossed under any circumstances. They need to be defined by websites, opt-in today, opt-out tomorrow, mandatory down the road, extremely easy to implement correctly, and extremely difficult to implement wrong. Let's find a solution.

It's easy to blame poor coding practices, poor site maintenance, backwards compatibility, or weird browser quirks for the issues we're dealing with today, but frankly, that's bullshit. Every party, be he browser (or plugin) designer, security appliance vendor, web developer, user, UX guy, security guy, or alcoholic vagrant (okay, those last two are pretty much the same thing), has some role to play here. My biggest complaint with this entire situation really has nothing to do with security: it is the "Somebody Else's Problem" attitude. This is everybody's problem. Whichever party you are, suck it up and be the one to handle it. Fix it for your users, your customers, or yourself. Have your marketing department spin it however they like. Charge people for a "premium" package. Please, just start fixing things. Let's fix them right. Let's fix them permanently.

NoScript is a perfect example of the "wrong" fix. Not to say it isn't useful. Today, it's a necessity, but it shouldn't be a long-term solution. It plugs countless specific holes, but does not address the major design issues around the web. On the other hand, if you've played with Request Policy, it cleanly solves CSRF, XSS, (some) history theft, and other issues. It renders the web virtually unuseable in the process, but it absolutely does solve those problems.

It's not all bad news- we're starting to get some other solutions. Mozilla's Content Security Policy may turn out to be the best thing to happen to web security in years, but it's complex, and it does very little for CSRF. There's a proposed "Origin" header to prevent CSRF, but frankly, it won't help unless it's insanely easy to enable and enforce. X-Frame-Options is great, but still pretty rough. None of these feel like complete "solutions."

Seriously, we're hackers. Hackers are supposed to be guys who can do, break, and fix anything.

What a delusional bunch we are.

Perspective on Pentagon "Pwnage"

Last night, Daniel Kennedy posted on his blog about a vulnerability in the Pentagon's web site. The vulnerability that was identified used XSS to steal session cookies. The story bothered me for a few reasons. Partially because it's usually a great blog, and the wording of the post made the vulnerability sound worse than it was. Daniel has since changed the wording, and I'm perfectly okay with that.

On to the exploit. My first reaction was that it isn't news. To begin with, the vulnerability is an old, known one- posted to XSSed last April. The site with the vulnerability contains no sensitive information, and unless you want to force somebody to book a tour of the Pentagon, really doesn't appear that useful at first brush. On top of this, there is no shortage of XSS vulnerabilities in much more sensitive .gov and .mil sites. The biggest story here really is that this vulnerability has been known for so long, and still has not been patched. Sadly, lack of fixes for every found XSS vulnerabilty isn't exactly a rare thing either.

I truly believe that XSS is one of the biggest threats on the web today. I'm not one to trivialize this kind of thing, but this one is small. As far as XSS holes go, this is about as trivial as can be. That said, this is still very dangerous.

Remember my cross-subdomain cookie attacks paper from last month? This is a perfect example of how widespread these issues are. The military has a hierarchical structure. It makes sense to give military websites a hierarchical structure. In this case, the domain with the vulnerability is pentagon.afis.osd.mil. Each of these subdomains means something- .mil for military, .osd for "Office of the Secretary of Defense," .afis. for "Armed Forces Information Services", and pentagon stands for, well, the Pentagon. Each department can have its own website, and its sub-departments have subdomains.

This is exactly how the web was designed. Academic Institutions' (.edu) websites also use this model heavily. It makes sense, particularly given the military and academic background of the web. Unfortunately, due to the cross-subdomain leakage of cookies described in my previous paper, any osd.mil website (there are hundreds, if not thousands of them, in various departments, serving various functions, and with various levels of sensitive data, user interaction, and exploitability) can be attacked due to this single, seemingly useless XSS hole.

As noted, finding such an XSS hole is rarely difficult. In less than half an hour, I was able to find half a dozen such domains vulnerable to XSS, some vulnerable to much worse. Most of those websites are simple informational websites, but there are a few with user logins, adminstrative sections, and sensitive data. This is where things get really scary.

Putting XSS in Perspective

After all that doom and gloom, I want to put this in perspective. As bad as an XSS hole is, it still requires somebody with the right level of access to click on it. Not necessarily hard, but definitely harder than a more direct exploit such as, for example, SQL injection. If somebody documents an XSS hole, they have not "hacked" that server. The Pentagon's website has not been "pwned." XSS is, and should be considered, a critical issue, but, at risk of appearing to agree with one of the dumbest quotes in the history of web security, it isn't generally used to hack into servers. Usually, that's not the point anyways- the attackers are after information, not a root shell.

Keep in mind, this is not a checklist of things you can and can't do with XSS. Don't use this in a risk assessment. Don't even quote me on it. This is just an attempt to put a realistic perspective around stories like the one mentioned above. I've seen too many headlines saying "$SITE Is Serving Malware!" or "$COMPANY Is Bad At Security" when there is no evidence of that happening. Web security is in a pretty dismal state right now, but spreading ungrounded FUD is simply not useful.

A single XSS vulnerability doesn't mean a company is bad at security. Frankly, a non-trivial application that is completely free of vulnerabilities is like a unicorn: It might exist, people claim to have seen them, but I have my doubts. I'd love to see organizations be more careful here, but in my experience, XSS vulnerabilities somewhere on a network is a virtual certainty. Security-wise, the key issue is what controls are in place to limit data leakage. News-wise, the key issue is how the organization responds to a vulnerability report.

XSS attacks are, by themselves, not actually very useful. However, they are attacks that stack beatifully with CSRF, credential theft, and clickjacking. They can also be leveraged nicely against vulnerable browsers and plugins to attack the client himself. It's worth noting though- unless you're stealing sensitive information directly from the page you're embedding the exploit in, it takes more than just XSS to do something malicious.

An XSS vulnerability in an application with sensitive data or access to sensitive resources (such as an internal network) is a serious matter indeed. A single targeted attack can compromise the data or allow an attacker to use the increased access of that user's browser as a jumping-off point for further attacks.

If that application is also popular, it is even more serious. The attack doesn't need to be targeted: it can be used in drive-by attacks or worms to hit a large number of users. As common as it is, this is in my opinion a worst-case scenario for XSS.

An XSS vulnerability can be used to anonymize attacks, but from what I've seen, attackers rarely bother. Using it this way generally just adds complexity without a lot of added benefit.

With cross-subdomain cookie attacks, an XSS vulnerability in one subdomain may attack another subdomain. Domains with many applications on their namespace (such as osd.mil) probably have other, more sensitive applications. Check before you disregard such a vulnerability on a non-sensitive application. They also may not. Check before you get too excited.

XSS works remarkably well for phishing. Currently, it's not particularly common to see it used this way, but it's happened before, and it will happen a lot more in the future.

There are many more uses for XSS, and there are just as many controls (ineffective as they are) for limiting XSS. The actual risks presented by an XSS vulnerability are extremely dependent on environment- the application, the server, other servers within the namespace, the web browsers being exploited, and security controls that are in place. Making vague statements about XSS vulnerabilities isn't particularly useful, and in most cases borders on FUD.

CSRF Isn't Just For Access

One common assumption people make with regards to CSRF is that it is used to escalate privileges or otherwise abuse sessions. While it's certainly useful there, CSRF can also be used to DoS a website by having a few hundred visitors to your site load a resource-intensive page on the target's server. It could also be used to anonymize sql injection, remote file inclusion, and other attacks.

The concept of having a website's normal users abuse another site has fascinated me for a long time- essentially, any high-traffic website could be used to create dynamic, temporary botnets of web browsers. This is neat.

Hold that thought. Wired Magazine is in the running for AdweekMedia's "Best of the 2000s" top magazine of the decade. I'm a big fan of Wired. I'm not a big fan of Rachel Ray, whose magazine is currently in the lead. I'd never heard of Adweekmedia, but like others before me, I can't help laughing when I see an online poll, survey, petition or other people-oriented data-gathering application. While gaming such systems isn't usually very hard, I laugh even harder when I notice the application is vulnerable to CSRF. In the case of this poll, it allows one vote per IP address, but doesn't appear to contain any other restrictions.

It probably raises some ethical issues to perform this kind of attack, and I certainly wouldn't condone this kind of thing. If you want to vote for Wired, you can do so manualy with this url:

http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850

For demonstration purposes only, here's a bit of HTML that you could theoretically place in your own website, harnessing the power of your users.

<!-- Help Wired win magazine of the year VIA CSRF. Copy/paste the following code into your websites -->
<img src="http://answers.polldaddy.com/vote/?va=10&amp;pt=0&amp;r=2&amp;p=2232025&amp;a=10937850" width="1" height="1" onerror="this.parentNode.removeChild(this)">

Putting that payload into an XSS worm would get a nice spread of visitors. On the off chance that they check referers, you can iframe in a page with an HTML injection/XSS hole to do it for you:

<!-- Help Wired win magazine of the year VIA CSRF. Copy/paste the following code into your websites -->
<iframe src="http://polldaddy.com/ratings/rate.php?cmd=get&id=61037&uid=wp-comment-29028&item_id=_comm_29028%22%3E%3Cimg%20src=%22http%3A%2f%2fanswers.polldaddy.com%2fvote%2f%3Fva%3D10%26pt%3D0%26r%3D2%26p%3D2232025%26a%3D10937850%22%3E" width="1" height="1" >

To be fair, XSS isn't really necessary. They provide us with a bit of Javascript to embed the poll in our own websites. All we have to do is use a bit of our own javascript, and we can hijack that method of poll submission as well.

But why should we restrict ourselves to web browsers? Lots of other applications make HTTP requests, and we can certainly use those ones. favicon.ico and robots.txt are some of the most common URLs for non-web-clients to hit. A few .htaccess rules can be used to help herd bots, malware, and non-browser RSS readers in the right direction:

Redirect /robots.txt http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850
Redirect /favicon.ico http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850
Redirect /info.php http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850
Redirect /errors.php http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850
Redirect /rss.xml http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850
Redirect /atom.xml http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850

By posting a few links to Twitter, we can also get the URL prefetchers, anti-malware applicatons, and other bots in line.

Now when I think "Where can I get a lot of IP addresses?" the obvious answer is BitTorrent. We can add the URL in question (or something that redirects to it) to the "announce" and "scrape" sections of a .torrent file. The clients will perform GET requests to specified URL, and everybody is happy. Uploading a torrent of a popular TV show will get you an awful lot of clients, awfully fast. There is another way to get BT clients making requests- an unofficial extension known as WebSeeding allows one to serve up chunks of a file from an HTTP server. Again, there's no reason that BT clients won't follow the occasional redirect and snag a piece from the wrong place. They'll even recognize the pieces as invalid and download them from another location- nobody will ever know that the request was made.

This concludes my random thoughts for the day. Isn't abusing the web fun?

Today's Bad Idea: MyMoney

Warning: This post makes heavy use of a cutting-edge rhetorical device known as "sarcasm." If your brain has a defective superior frontal gyrus, please consult your doctor before continuing.

I'm a heavy Facebook user, and most of my friends are too. I love it! Facebook is like an online portal to my social life. It also has a convenient platform for including third-party applications, so I can not only communcate with my friends: I can also play online poker, have (simulated) gang wars, and send fun quizzes to them. Awesome!

The only thing I was really missing was the ability to manage my finances from my facebook page. It drives me insane to have to fire up a separate web browser, navigate to my bank's website, type in a username and a password and punch in those frustrating digits from my hardware token. That's just too much work. If I had my way, I'd have a running counter of my net worth on my Facebook wall, like a villain from a James Bond movie. Bummer!

Imagine how excited I was to receive an email from Etienne Janot, letting me know that the future is here: Fiserv has a product called MyMoney. MyMoney is an application that "enables Facebook users to search for and join a financial institution and manage their funds via the familiar Facebook interface." Sweet!

The video on Fiserv's website really sells it to me: it helps bring the boring world of banking to us fast-paced Gen Y users. Not only that, but (quoting from their website, because I really couldn't make this up) "MyMoney also leverages Facebook's viral marketing opportunities. When Facebook users add MyMoney to their profile, their friends are notified and given the opportunity to add it too, enabling financial institutions to extend their reach, particularly within the Gen Y market." I've always wanted to know who my friends bank with, and now, thanks to MyMoney, I can! Woot!

I know you're thinking this is a bad idea, and are concerned about MyMoney's security. Don't worry, I checked it out. They have "multiple layers of security protecting...data and accounts." The application iframes you into their site (hosted on https://mm.galaxyplus.com). If you forget the URL, they left zone transfers enabled for you, so you can just select from a list of galaxyplus.com subdomains. The iframe's URL has a parameter called "fb_sig_user." If you manipulate this parameter, you get to see the contents of all your friends' accounts (presumably so you can borrow money without all that awkward asking). The only thing I don't like about this application is that they left error reporting on. I don't like seeing those ugly ASP stack traces every time I use an HTML tag as a form parameter. Lol!

All in all, I'd say this whole MyMoney thing is a pretty damn good idea. I'm glad somebody did it.