Making A Change²

Sometimes, you go out looking for change, and sometimes it just happens.

Since I joined Foreground Security, I've been lucky enough to work with some top-notch skilled and dedicated people. Among them is Mike Murray, one of the world's leading experts on social engineering via psychology, linguistics and sneaky peoplehacking. Suffice it to say, I've learned a lot from him, and I've enjoyed every minute of it.

When I learned he was leaving Foreground, I was a bit disappointed. When he called me up a few weeks later to offer me a position with Mad Security, I was less disappointed. It was a tough decision, as I've had nothing but good experiences at Foreground, but I feel like I have a lot to learn yet, and I'm pretty excited about some of the new opportunities that come with it.

I'll be doing much of the same security research and penetration testing work, but with an additional focus on training- for security people, IT people and non-IT people. With everybody from developers to users, training is the most useful security tool in the bag, and is used less effectively than any other.

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.