Old-School Hackers

My mom's uncle Bob passed away last night. That's too bad, I never really spent a lot of time with him, and I didn't even know he existed until about a year ago, when I was traveling through southern Utah with my family and we decided to pop in and visit. He was awesome.

While I'm not really active in the DIY community, I always had that mentality- when I was a kid, I'd spend days playing with my Erector set or taking apart toasters and hard drives, eventually graduating to cars and motorcycles, and finally getting into the software side of computers. I consider breaking, fixing and building things an essential part of life, but anything I can do pales in comparison to Uncle Bob. He lived through the Great Depression, and spent most of his life in a farming community that never really made it out of the depression. He never threw anything away, and his back yard was a massive junk yard- the kind of place that car people fantasize about. Old tractors, vintage Fords, Chevys, Cadillacs, and a weather-beaten-but-mostly-intact International Harvester (remember Mater from the film Cars?). Most of them aren't salvageable, but there are some gems. He flew a Cessna until its hangar collapsed in a windstorm, at which point he bought a Corvette "so he could still fly." Like many of us, he was a serial career changer, doing what he thought was interesting, moving on when he found something else.

Uncle Bob had a perpetual motion machine (Except he didn't like people calling it that, because that's impossible. It was a "generator") that would lift a weight up an inclined plane, let it slide down, powering a generator that charged a battery that in turn would lift the weight up... I have no idea how it was supposed to work, because he never did figure out the friction issue. Maybe somebody here has ideas. It was a pretty cool bit of fabrication, at any rate.

No point to this post really, I've just been meaning to write about him since I met him. We could all learn a lot from the hot rodders, builders, mechanics, and DIY-enthusiasts-by-necessity of past generations.

If not, they still have great stories.

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.

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.