Incentivizing Good Behavior

A few months back, drunkloria posted what I still believe is my most favorite tweet of the year. For that, she gets a gold star.

Srsly. If all y'all are so good at social engineering, why do y'all have issues getting clients to implement security?

She's right, of course. We talk a big game. We read books on social psychology, influence, NLP and hypnosis. But we suck at it. Even the ones who are good at it suck at it.

If you haven't seen Naked Password yet, I suppose I can wait while you go check it out. Basically it's an 8-bit striptease that's used as a password strength meter. I like this. Complain about unprofessionalism, sexism, or whatever you like, but the fact is this: you put that on your website, your users WILL have strong passwords. Mostly they'll just do it because it's funny, but you'll get the results you're looking for.

It's not genius. It's one of the basics of every grifter movie out there-- focus the target on one thing, and have your desired result be a byproduct. Sleight of hand.

I like seeing this kind of creative thinking, even if it is somewhat in jest. Let's extend it. All those ecommerce sites that say they're dedicated to security? Why not provide a discount coupon when users set a strong password? Limit them to one a month, and suddenly you've got them changing their password regularly. See how easy this is? In a lot of cases, it's also probably cheaper than dealing with fraud from hacked accounts.

Provide special offers, features, or if you must, pixellated dirty pictures to users who install NoScript and Request Policy. It's easy enough to detect when those plugins are in place, you can encourage users to embrace security, help yourself and help the internet a bit at the same time. People install special toolbars, plugins and even malware for the stupidest reasons imaginable, but we can't get them to disable Javascript?

Getting people to change their behavior isn't all that hard, you just have to offer an incentive. "Not getting hacked" isn't an incentive. It's not even perceived as a real threat, to most people.

A Penetration Test Is Not A Vulnerability Assessment

There's been a bit of debate going around lately, in which David Maynor said that we should be using 0-day exploits in pentests, and subsequently got yelled at for it. Just for the sake of taking sides, I feel like I should point out that anybody who says 0-days don't belong in pentests have no idea what a penetration test is.

This isn't all that uncommon, so let's have a little vocabulary lesson:

Security Audit A technical assessment of an environment's security. This is a catchall term that may include one or more of the components below as part of a full security program.

Penetration Test An evaluation of security controls through a simulated attack. This can be automated (as real attacks can be), though it certainly will not be effective as a manual attack by a skilled attacker (as real attacks also can be). The goal: to evaulate the effectiveness of security controls, including incident response. Vulnerabilities may be found, but that is a side effect of the process, and a secondary goal at best.

Vulnerability Assessment A review of applications, configurations, and systems for vulnerabilities such as bugs, misconfigurations, or architectural flaws. This also may be automated (and should be, for efficiency) as well as manual (and should be, for thoughness). The goal: to find vulnerabilities, presumably for remediation, although vuln metrics can be useful in other ways, such as quality assurance and developer skills evaluation.

Risk Assessment Quantification and prioritization of assets and vulnerabilities. The goal: To get numbers about security posture and to focus remediation efforts where they are most needed.

While it may sound like I'm picking nits, each of these processes has distinct goals-- they gather different metrics, they create different kinds of data, and they are used for different purposes. There's certainly some overlap, and there are other compoments to security auditing, but these are the ones I see most often confused.

There's a lot of reasons people mix these terms up- Sales drones in this industry are often confused about the goals, the processes, and the results. Some people deliberately blur the lines for compliance reasons (For example, PCI requires anual penetration tests. By blurring the lines, many organizations get away with fulfilling this requirement without actually running a penetration test. I'll leave the question of whose fault this is, and whether it is a bad thing results-wise up to the reader). Salespeople, technicians, and management alike often use the word "Penetration Test" just because it's sexier. Regardless of why, the processes are not the same.

When I begin work on a "penetration test" only to find out that the client is expecting a risk assessment and the sales department sold (and scoped) the project as a vulnerability assessment, it's not just frustrating, it's dangerous. Confusion about these terms leads to poorly written contracts, misunderstood objectives, and miscommunication about rules of engagement. Let's all try to be a bit more careful about what we're saying.

Coming back to the original point of contention, it's obvious that penetration tests should include discovery and exploitation of 0-day vulnerabilities if possible. You're trying to simulate a real attack. Real attackers do things like that.

If all you're doing is running a few automated scanners to find vulnerabilities, you're not performing a penetration test. You're performing a vulnerability assessment. There's a place for that. I'd even argue that the vuln assessment is a more important part of a complete security program, as long as management, development, and compliance people are already on board with this whole "security" thing.

Please stop using words wrong. We're a young industry, and we don't want to get stuck with incorrect definitions and unclear vocabulary.

McAf.ee is Stupid

McAfee just announced that they are releasing a URL shortener, and it's currently in beta (well it actually says "This Site is a Beta."). Honestly, I'm still trying to figure out what it's actually useful for, and not coming up with much. Did somebody decide it was needed? Did somebody think it would be helpful? Is this just McAfee swinging wildly in the dark at things that vaguely sound security related in order to bloat their product portfolio and brand?

Yeah, that might be it.

At any rate, there's a few issues I noticed with a quick inspection.

The server doesn't appear to be prefetching the URL, so it can't have any idea whether the URL is dangerous or not. Presumably it's checking the URL against the (admittedly impressive) database of sites that they use for SiteAdvisor, another McAfee product.

It does have some basic Javascript/XSS filtering, but it's only effective against specific vectors- it filters out some HTML characters (like < and >), but not other XSS vectors: " onload=alert(1)

Most URLs will be placed inside an iframe with some basic information about the target URL. If the URL is deemed harmless (or "green"), the user's browser can be set to bypass the iframe and go directly to the page. Presumably this is just a convenience-- there's no way this could actually provide any browser security, but if a way to attack this iframe were found, or if the iframe needed to be disabled, an attacker could turn that feature on/off via CSRF:

http://mcaf.ee/api/config?bypass_frames=1
http://mcaf.ee/api/config?bypass_frames=0

The only real information McAfee provides somebody visiting a shortened URL is in the iframe, where it says what kind of website they think you're visiting (in the case of skeptikal.org, it's "Software/Hardware Blogs/Wiki"). Interestingly, if the link I provide throws a 302 or other redirect, it still thinks you're looking at my site. Since they're not prefetching the page, they have no idea whether I'm redirecting you elsewhere, or attacking you directly. If users are screening pages using McAf.ee, it's trivial to bait-and-switch them onto another site.

The question I'm still asking is "who thought this would be useful?" It's really not. First off, they claim to let people create "safe short URLs." That's not even close to true, based on what I've seen. Second, the whole thing is pointless unless users refuse to click on any other shortened URLs-- a ridiculous proposition to begin with. Attackers will just use a different URL shortener. Users will keep clicking on anything, and it's not the URL shortener's job to keep them safe at any rate. Not to say that McAf.ee directly causes security issues, but it doesn't appear to solve any security issues either.

/sigh

Another day, another Twitter XSS

It may surprise some, but I really haven't been big on XSS lately, mostly because it's a problem that hasn't changed for years, and the most basic form of it is still brutally simple to exploit. Not a lot of excitement in it, I guess. But that doesn't mean that it doesn't deserve attention- in fact, that's exactly why it does. So when a new Twitter XSS popped up on my feed reader this morning, I took the 10 minutes it takes to write a proof of concept, and put together an exploit.

You can check it out if you like (It won't bite until you manually click the "pwn me" button, so the link is safe, but don't take my word for it, use NoScript and RequestPolicy). Frankly, if I wanted to hack you, I'd be doing it silently on this page, not that one.

I'll post a followup later. This example drives some pretty interesting points home.

Cross-subdomain Session Fixation

Last fall I wrote a bit about cross-subdomain cookie attacks. As often as I come across more uses for them, I think that they are a much more serious issue than most people (myself included) have made them sound. Today, I came across a variant which I'd theorized about in the past, but never bothered to find in the wild, and I think it merits some attention.

You may be familiar with Hack Is Wack- a stupid marketing campaign from Norton/Symantec. The premise is simple: users submit videos, which are voted on, and the winner gets to roll with Snoop Dogg...'s manager. You may not know it, but most of Snoop's music is information security-related. "What's My Name" is about AuthN, "Drop it like it's Hot" is about SQL injection, not to mention constant references to cron, gzip, and other unix commands in his lyrics. It's really a pretty natural match.

At any rate, the Hack is Wack site is chock full of holes. For example, there's the publicly available, indexed cache directory with all that SQL, JSON and other data. There's the XSS vulns (HTML5 only, though it should be simple enough to rewrite), CSRF holes, and the Flash upload issues in the video upload script (a Joomla module that appears to have been used without any quality control or review despite the fact that it's currently in Alpha)

A security company using bad code in a marketing site? Shocking, I know. I'm really not here to harp on them though. I'm over security vendors being full of shit- they all are, it's not news.

I just found a particular attack vector interesting.

The voting system for uploaded videos is grossly vulnerable to CSRF, and probably much more serious things, based on the format of the "vote" URL (unencoded, for ease of reading):

http://www.hackiswack.com/index.php/home/rate.html?videoid=\'.24.\'&rating=4

This means that I can create image tags in my own website to vote for a specific video and stuff the ballot box. Classic CSRF, right? It's something I've talked about before, but unfortunately, this one isn't quite so simple. You have to be logged into the site to vote, and they prevent a user from voting twice for the same video, so to manipulate this poll, we really need to create a whole bunch of user accounts. The user registration page is part of the main Joomla codebase, and it uses session-based tokens to prevent CSRF- the way they should.

The interesting thing here, is that the application doesn't enforce the HTTP Host header. Instead of http://hackiswack.com, there's no reason you can't use the application from http://184.106.223.144, or more importantly, http://hackiswack.skeptikal.org (no, this doesn't actually go there, but there's no reason it can't).

Once I have my own domain set up, I can easily force a visitor to skeptikal.org to assume arbitrary session cookies that will also be sent by his browser to hackiswack.skeptikal.org, and with a known session cookie, I can request the page myself and parse it for the CSRF token. I can then embed that token in any forms I force the user to send, bypassing the protections that Joomla so carefully puts in place.

All right, so this is a lot of work, and probably isn't practical for stuffing ballot boxes, (especially since there are already much more serious vulnerabilities to take advantage of) but as a way of bypassing CSRF protections, it's perfectly valid. There are plenty of times where a CSRF protection mechanism can be bypassed with a simple session fixation attack. A variation on this was described by RSnake last fall, using DNS rebinding instead of subdomains. It's probably more potent with DNS rebinding, but a cross-subdomain attack tends to be much simpler to set up.

The key to remember is that in this case, you can't take over an arbitrary session, so it is of limited use for, say, compromising an Admin. However, if you want to log a user into a website (with known credentials), or otherwise force him to do something on your behalf, it's a very useful technique. Something to keep in mind, at least, and another reason why websites that don't require specific Host headers should be considered vulnerable.

Hat tips to The Harmony Guy and Packetwerks for pointing out some of the holes in the Hack is Wack site

Getting The Gist Of Things

This blog post represents a progression of thought. I'm not making arguments, I'm making suggestions as they occur to me.

Security is very hard to quantify- it's the classic "how to prove a negative" problem, coupled with the "every application has bugs" problem, and wrapped up with the "holy crap this is impossible" problem. Maybe we don't need to accurately quantify it though. I mean, when we're doing the risk assessment part, we want to be close, but as far as the remediation phase? In my experience, at the end of a vulnerability assessment, people usually care about about three things:

a) What issues do I need to fix?

b) What kinds of issues are most common?

c) Where does my organization stand (relative to the competition and the global web application environment)?

When people focus on one of these issues, which one they fixate on can be very telling. While somebody should always take a look at the report and fix the specific issues (where possible), the people who only care about the found vulnerabilities often refuse to look at the big picture.

If we're doing vulnerability assessments to find bugs, we're going to fail. This is the problem with every assessment: It won't find all the vulnerabilities. What it can do is find "a bunch" of vulnerabilities, which collectively can inform you about where you need to put your efforts. The job isn't done when you've patched the bugs. The goal of a vulnerability assessment, at least from an action standpoint, is to know where you stand security-wise. If you can do that, you can manage the specifics.

In Jeremiah's response to my last blog post, he discussed some of the problems with web app scanner inconsistencies, making the point that all scanners will miss something, and that some are better than others at specific things. I'm going to neatly ignore that and talk about something slightly different.

He's right, but it's a limited view of the problem. A scanner may not be able to find a specific issue, or all instances of a specific issue, but a human tester won't either. The quick wins that the scanner provides in tracking down holes should be considered a byproduct- we should use the scanner primarily to get a feel for where the problems exist. If you find out that your servers are rarely up-to-date, or that you have a high concentration of XSS vulnerabilities, that is useful information in itself. The most important part of a report should be a venn diagram of weak spots, not a list of vulnerabilities. I'd argue that, from a high-level security management perspective, whether an exploitable issue is actually found or not is irrelevant. That's not the goal.

The scanner's results will be skewed and inconsistent, just like the human tester. Unlike the human tester, a scanner will be consistently inconsistent. We can compensate for that. If we have base metrics regarding which vulnerabilities are most common in which situations (numbers we're only beginning to put together as a community), and we know that a scanner consistently produces skewed results, we can calibrate our reports to compensate. We can then spot check the weak points to confirm our findings, and further calibrate the reporting process.

Accuracy is always ideal, but lacking that, the ability to make reasonable estimates about where the problems lie would speed up the bug hunting process, the patching process, and allow us to focus training, policy and development procedures. With that approach, the problem of scanners "missing things" largely goes away, and in fact even the worst scanner will still produce useful results. On top of that, scanners can be easily compared with simple relevancy ratings between the predicted vulnerability distribution, the discovered issues, and actual findings (from supplementing the scanner with human testing).

Scanners are a tool in the bag, and they're a pretty good one. If the results aren't interpreted correctly, it doesn't matter if you have the world's best bug hunter on your side. An assessor's most important role isn't in finding the bugs- it's in interpreting the results.

Are Secure Web Apps Possible? Yes (and no)

Mike Rothman wrote a post addressing the general problem of web security, titled "Are Secure Web Apps Possible?". My answer: Yes. And no. The general conclusion Mike comes to is that web scanners are useful for generating quick wins, but hardly complete. As long as they are used with that knowledge, they are excellent tools to have available.

He's absolutely right, but there are some problems with web application scanners. Well, "some" is an understatement. In traditional application testing, the attack surface is relatively small, and fairly well-defined. The rules for building a secure application haven't changed much in the last few years, and the basic language communicating with the hardware has been relatively stable for quite some time. At the very least, it's well-documented. The fact that we still have critical bugs popping up in common applications has more to do with the development process than the technology itself.

With web applications, it's not so simple. The platform is not the hardware. The platform is the web browser, and the web browser speaks hundreds of dialects, in dozens of languages, and they all interact. There are many more layers between the user and the hardware, and every one of them is exposed- to the network, to malicious users, to malicious servers, etc. The attack surface that presents is massive, but more importantly, it's dynamic. With new standards being added to the browsers, old ones being phased out, and the way that they interact changing constantly, creating a scanner that understands the context a web site runs in seems impossible. When you consider that there are about a dozen browsers currently in mainstream use (including mobile versions), the problem just compounds.

I don't expect web scanners to ever be able to address those problems, but I hope I'm wrong. Currently, it takes at least a few years of dedicated experience before you really get a "feel" for finding and assessing bugs, and RSnake doesn't scale well.

My opinion is that the fundamental architecture of the web needs to change drastically before it is even remotely close to "secure." Until then, all we can do is fix bugs, fix development processes, fix user behavior, or try to hack on kludges when the problems come up.

The last solution doesn't seem very helpful, so let's take a look at the other three.

Fortunately, in many cases, the subtle and obscure bugs aren't the problem. Security isn't black and white, and the trivial ones are easy to fix. If a company like AT&T hasn't at least found the simple issues (like the ones used in the recent so-called "hack"), they are being negligent. Mike is right, getting a few quick wins with a web scanner isn't a bad idea- just make sure you know what that means. You won't get everything, but you'll get the easy stuff, and this is where risk assessments really shine. That's a much bigger topic than this blog post can handle though.

Fixing development processes is just starting to catch on. Web developers, browser developers, and low-level system developers alike are beginning to adopt SDLs, and we're already seeing positive results. People are developing frameworks for secure development (more on that in future posts). Things are happening.

If development processes are hard to change, user behavior is next to impossible. Still, the truly paranoid user can expect a decent level of security through careful system configuration, limited browser functionality and general security awareness.

The general conclusion, something we all know, is that security is an extremely difficult, complex process. Many facets are involved, but each can only be addressed by a specific party. It's each of their responsibility to help all of us.