Archive for the ‘Vulnerabilities’ Category

So, in case you haven’t seen it yet, a couple of researchers are totally against the idea that companies freeload off their research. Pete Lindstrom over at Spire weighed in on it, which is interesting to see since he’s not really a fan of the full disclosure stuff.

Anyway, it seems to me that there are two things going on… First, they have a legitimate point. Many vulnerability researches aren’t compensated monetarily for the work that they do. In fact, bug finding is a PITA. It is. Finding the bug is the easy part. The hard part? Dealing with development teams who don’t want to hear from you in the first place, dealing with people who are irritated by your bug-finding, etc. Not getting paid for it is the icing on the cake.

But is it the case that there isn’t any value in finding bugs? I’m not sure you can say that. How many folks, for example, see David Litchfield as an expert on Oracle because of the bugs he’s found in their software? How much cred did the l0pht get for the stuff they did with breaking the auth in NT? Is there really no value to be had in finding bugs besides monetary remuneration? I’m not sure that’s the case.

Maybe the market’s working as it should. Maybe folks don’t do it to get paid but instead for free advertising… Just my two cents. It’ll be interesting to see how this pans out. But something tells me folks like X-Force are going to still find and publish bugs even without the getting paid angle.

You know who doesn’t suck? Kaspersky.

In case you missed it, they got hacked a few days ago in a pretty embarassing incident that I’m sure was pretty painful for folks over there. And they have proceeded to handle this thing in an honest and forthright manner.

Now, I’ve been pretty critical of Kaspersky before. But I have to say that I’m downright impressed by how they’re handling this thing. First, they’ve refrained from minimizing the impact until they’ve had a chance to have an independent well-respected party determine what was accessed vs. what wasn’t. They’ve taken ownership of the issue and admitted it was “their fault”. And they’ve admitted that it shouldn’t have happened. All in all, the right response in my opinion.

They’re right – it’s an embarrassing thing to happen to them because they’re a security company. They’re also right that it probably shouldn’t have happened and it’s their fault. Fair enough. No data was compromised – they’ve proved that already. And they’re an AV company, so I don’t really expect them to be perfect when it comes to application security (a totally different discipline). So I’m on board with giving them a pass on this one.

Actually, more than a pass – Kaspersky went up a notch in my esteem. They went from a value added reseller for grep (true of most AV) to a company that actually has the spine to stand up and admit to making a mistake – without the BS and drama that usually accompanies these types of things.

I am now a full-fledged Kaspersky fan.

So, you’ve heard about the Heartland Payment Systems breach? I have to confess that as a connoisseur of human folly, my first reaction was “wow, sweet!”. Of course, then I started speculating that maybe this had something to do with the 5k in fraudulent charges that some yahoo managed to accrue on my Chase card the other day. Oh well, stuff happens, right?

But then I saw the response from the the company… Did you see it? If you’re feeling like you could use a good fire-up, check it out. It starts off ok… maybe even note-worthily admirable:

The transactional data crossing our platform, in terms of magnitude… is about 100 million transactions a month,” Baldwin said. “At this point, though, we don’t know the magnitude of what was grabbed

That makes sense, and seems reasonable and honest. But then, just when they were starting to impress me with their non-foolishness, they say this:

The company stressed that no merchant data or cardholder Social Security numbers, unencrypted personal identification numbers (PIN), addresses or telephone numbers were jeopardized as a result of the breach…

Wait a sec… For rulz? So, to paraphrase: it’s the largest theft of credit card data of all time, but it’s really not so bad because they didn’t lose my social too? Are you kidding me? Financial data is leaking from the environment like a broken pipe, but really that’s OK, because my phone number is all good? Oh no, no.

But then comes the part that’s outright disingenuous:

“The nature of the [breach] is such that card-not-present transactions are actually quite difficult for the bad guys to do because one piece of information we know they did not get was an address… As a result, he said, the prospect of thieves using the stolen data to rack up massive amounts of fraud at online merchants “is not impossible, but much less likely.”

I call shenanigans. While it is, in fact, true on the surface, it manages to completely dodge the real issue. Which is, who gives a rat’s backside for card-not-present transactions? Yes, for CNP, the address would be nice to have. But since the “bad guys” have the track data, they’d have to be smoking crack to go down the CNP route. Why? Because they’re better off printing farking cards using YOUR track data. Because the address isn’t on the track data in the first place – so they don’t need it.

Are they telling people that? No. Should they be? Well, maybe – maybe not. But don’t tell people everything’s all good when it’s really almost as bad as it could get. Don’t put the icing on it – it just causes trouble.

I just came across the Register article pointing out the inanities of Bit9’s new vulnerable application list. Now, I’m not going to pig-pile on Bit9 here. I think the Register’s already done as much slamming it, everything it stands for, and the horse it rode in on, as needs doing.

But I do have a few unanswered questions. Not wanting to pre-judge Bit9 based solely on the content in the Register (they’re usually right on the money but “trust no one” as Mulder would say), I went off and viewed the Bit9 report to find out what they actually said. And the thing I can’t figure out is what the significance of an application being on the list is. To save you the effort of reading it, the apps on the list are (in order):

- Firefox
- Adobe Acrobat Reader
- VMWare Player
- Sun JRE
- Apple iTunes, Quicktime, and Safari
- Norton AV
- Citrix
- Aurigma, Lycos
- Skype
- Yahoo Assistant
- MSN Messenger

Paraphrased, the criteria for inclusion in the list are:

- most people can run the app (items #1 and #3)
- it’s popular (item #2)
- it’s had a critical bug (item #4)
- it has security-related configuration settings that the user can monkey around with (items #5 and #6)

So, here’s the thing. Based on the criteria, it seems to me that they picked a reasonable set of apps. I’d ask why Citrix and Lycos, and not say, the Google toolbar? But whatever… maybe the recent Google toolbar bugs weren’t critical enough. I agree that this is a set of popular apps that have security bugs. I agree also that unless you lock down the environment, users get to download them, control the security settings, and maybe even not patch them. So… what next?

I think the issue here is that the Bit9 set themselves up by being (deliberately?) vague about what the list is supposed to prove. It could be one of two things:

1) a “top n” of “dangerous” apps
2) proof-points that there are security issues in apps people download

The Register assumed they meant it as #1 (which is implied by the title, “The Most Vulnerable Applications”). If this is true, I would say the Register is right to mock it. But if they really meant #2, I would ask first why they chose to call their paper what they did. Based on the title, I’m thinking #1. Based on the content, I’d say #2.

If it’s really #2 that they were trying to say, the paper basically reads as follows: “Security’s a huge problem. Here’s a list of popular apps that have security bugs. That being the case, you should buy our product.” But the part that’s missing (in my opinion) is, “Security’s a huge problem. Here’s a list of popular apps that have security bugs. Here’s why this matters to you. That being the case, you should buy our product.”

Anyway, I think at the end of the day that The Register was harsh – maybe overly so based on what Bit9 actually (may have) meant, but I’m also not sure that Bit9 expressed their message as well as they could have. I’m totally on board with Bit9 telling me why I should buy their product – and if they have data points to back it up, so much the better. But if you’re going to do that, spoon-feed me the connection between the message and the data points so that the list doesn’t look like FUD. People hate that… and some people are more caustic about it than others.

You probably already know this, but I love it when people try to predict the future. Seriously, it’s great. The reason I love these so much is for two reasons: #1) they succinctly capture the “zeitgeist” (like a snow-globe of the industry) and #2) because they’re usually wrong – but in being wrong, they still make us think.

For example, remember these:

- McAfee predicts 2006 to be the “Year of Phone Malware”
- Gartner declares “Death of IDS”
- Websense predicts VOIP Phishing (Vishing)

These were all way off the mark of what actually happened in the years they were predicted, but still great because they’re probably going to be right someday. In fact, that’s what I think makes a great prediction. Wrong today, but true enough that it’ll be true someday. For example, IDS isn’t dead yet… but it probably will be someday (or at least change so much that’ll be unrecognizable as IDS). Phone malware’s not a huge issue yet, but it could be at some point.

And I have to admit that this year I’ve been slightly bummed out. Bummed out because it’s December 11 already and there’s been a dearth of predictions. Where are all the swamis telling us how 2009 will go? But then I saw Bill Brenner’s CSO article where Brian Chess of Fortify predicted the death of pen testing in 2009. I love it.

Now, it won’t be true in 2009 in my opinion.

#1) PCI specifically requires an annual pen test (requirement 11.3). Since PCI isn’t going away in 2009, neither will pen testing.
#2) When I read a pen test report that doesn’t say “surprise, you’re running NT 4″, then I’ll agree it’s not needed.
#3) I don’t accept the assertion that better monitoring is a replacement for testing. (I.e. just because the sheep wear a bell doesn’t mean they won’t get lost.)

But look past 2009 and farther down the road? 2015? 2020? Well, I think I see his point. Maybe monitoring will get so good that we can intuit the results of a pen test without doing one. Maybe we can find out all we need to know about these systems without the need to plumb around and check it out. We’re not there yet, but that doesn’t mean we won’t get there. In the meantime though, it’s trust *and* verify.

We in this house love Boston. It’s a great place. Especially those little cream pies that they have at the Omni Parker House… mmmmm… they melt in your mouth.

Yep. We love Boston. But the MBTA… that’s another story. Maybe you heard, or maybe you didn’t, that the MBTA sued three MIT students and had a court issue a gag order to prevent them from publishing their research about how the MBTA system can be defrauded.

Now, a lot of folks have made this about full disclosure. I, for one, don’t think it is. I understand the temptation to make the parallel, though. But in this case, we have to acknowledge that the forces at work are different. Full disclosure – at it’s core – is about getting product companies to fix their bugs. It works because it embarrasses vendors into fixing their issues.

The MBTA, on the other hand, probably won’t be able to fix this issue – at least not in the short term. They’re not a product company, so they’re going to feel the pressure in the same way that, say, Microsoft would in the event of a Windows bug. So embarrassing them – well, it really doesn’t serve much of a purpose (other than intellectual curiosity) than just embarrassing them. They’ve already got a significant deployment going on and probably quite a bit of money invested. So it’s probably not worth their while to fix the issue. Which means, at the end of the day, that their probably right in saying that publishing the details of the issue is likely to encourage people to exploit that issue.

That being said, I think they have a valid point. Even so, however, I still disagree with their decision to take these kids to court. Not because they’re argument isn’t accurate (which I think it is), but instead for two wildly different reasons: a) because of the precedent that it sets for future research, and b) because it’s dumb (counter to their own interests).

Now the question about the chilling effect on future research has been beaten to death, so I won’t beat it again here. But the stupidity argument I haven’t seen yet, so I’ll lay it out. What’s the best surefire way to make sure that everybody in the free world hears about the MBTA fraud issue? If you wanted to shine a spotlight on this thing, what would you do? How about suing some college students and making it into a free speech issue? Oh yeah, brilliant idea… we’re the government, so let’s take some college kids to court over it – that’ll go over well. Not. If they had just ignored it, it would have been a blip on the radar – some people out at DefCon would have heard about it, and everybody would have moved on. But putting on a Darth Vader mask and standing on the rooftops shouting that you’re the evil empire? Not such good PR.

So, I’m sure you heard about the Super-duper tip-top secret DNS Cache Poisoning issue? In case you haven’t, here’s a quick synopsis of backstory. For the TLDR (“too long, didn’t read”) crowd, a synopsis of the synopsis is:

- Researcher finds a big bug in DNS
- Because it’s so incredibly huge, non-essential peeps were kept in the dark for 6 months
- The supreme largitude of the patches to be released brought on dead silence for 30 days
- The silence was lifted at BlackHat where the technical details were revealed onstage

Now, throughout this whole episode, people were all kinds of pissed off because the researcher in question didn’t go the whole full disclosure route and just ante up what the issue is. Other people were pissed off because of the pressure to go public. Seems like too many people in a huff.

Personally, I’m a fan of natural selection, so I tend to agree with the folks that say that holding back the information was bogus. What do I mean by natural selection? I mean – if product A can’t release a patch to address a security issue in a reasonable timeframe, folks should know about that. If that means that they’re unprotected against some issue for a few days, maybe that’s a small risk by comparison. Small compared to what, you ask? Well – simply put – compared to the risk of keeping the bug on the down low while everybody fixes it. Here’s why…

Say, hypothetically, you have a known bug that you’re keeping quiet for a year (or 7 months if you want to get all literal about it). How many people do you think know about that bug during that time? The developers? Well, they’d have to know right. In a multiple-vendor alert like this one, you’re talking about most of the developer population for all the products that are impacted. Could be a pretty big audience. The security architects at these vendors? Absolutely. Management? Of course. Technical writers? Sure, somebody’s got to write the alert.

Do you think that out of all these people, somebody’s not going to let the goods out to someone? It seems inevitable to me. Plus, don’t forget about human nature. If you tell someone something is super-secret, doesn’t that make it all the more compelling for them to tell their friends? Absolutely. So the theory that people are going to keep it under their hat is ridiculous. In reality, there will be people with the data. I guarantee it. So, probably disclosing the details is a good thing.

In this case, I don’t think that anybody was motivated by anything untoward. I don’t think it was all about “hacking the press” as some people seem to suggest. Instead, I really think the secrecy was an attempt to do something good and keep people safe. Good intentions. However, I think it probably could have been handled better. Personally, I probably would have gone through CERT since they seem to be pretty good at this kind of thing. But hey, that’s just me, and it’s easy to armchair quarterback

So, Pete Lindstrom’s looking for vulnerability researchers with enterprise experience. Now I think I just barely qualify; not on the enterprise experience side (that I have quite a bit of experience in) – but on the research side (where I have less experience). However, there are a few names that leap to mind; for example, I immediately think of Alex Wheeler who not only punches holes in AV software, but also worked in one of the largest (if not the largest) insurance companies in the world. Now, my objective here is not to gainsay Pete, because I think he has a point; l think it is uncommon for people to have both enterprise and research experience.

But I don’t think it’s because practitioners in industry have a high moral standard that precludes them from working on vulnerability research; I also don’t think it’s because they fundamentally believe that vulnerability research contributes to the problem of patch mania and/or increased exposure to the enterprise. Not that Pete is saying any of those things, mind you. However, one could. Instead, I think that vulnerability research and industry do not go hand in hand for a totally different reason – I think it’s about time and incentive.

In actuality, vulnerability research is a very time-intensive process. And the truth is that the majority of enterprise IT departments do not reward employees for finding bugs. Now, if you work for a product company (eEye, ISS, etc.), you might be rewarded for finding bugs. Even if you participate in a pay-for-research venue where you can actually sell your bugs, what are you going to earn? A thousand dollars? If it takes weeks to research and write up a bug and go through the rigmarole with the vendor (say conservatively 200 hours), you’re talking about 5 dollars an hour. Oooooo, sign me up (not.) However, product companies that use vulnerability research as *marketing* have an entirely different perspective. How much is the front page of google news worth to them? Enough to incent their employees to look for bugs? You bet…

The trouble with statistics is that they can sometimes be deceptive. For example, my RSS reader and inbox has been flooded for the past few days with news about the recent Mitre report citing cross-site scripting as the number one attack vector; everybody’s writing about it. The short story around this is that the 2006 Mitre CVE statistics point to the fact that Cross-Site Scripting accounts for the largest share of reported vulnerabilities (21.5%) followed closely by SQL Injection (14%). Now, no doubt this is interesting. No doubt that Mitre’s doing a service to the community by publishing these statistics. And no doubt this tells us something about the state of vulnerability research in 2006. But what it tells us is not exactly the same as what’s being represented in the industry press.

Here’s what I mean. Clearly, the data does tell us that more application vulnerabilities were located this year than in prior years. Based on those statistics, we can say without question that web vulnerabilities are a more popular target for research. However, the temptation is to draw broader conclusions from the numbers that aren’t necessarily in scope. For example, Network World calls Cross-Site Scripting the “top security risk”; the Inquirer says that “hackers are looking to cross site scripting bugs as the best way to bring down a system.” LinuxWorld tells us that Cross Site Scripting is “now the most preferred hacking techniques used by hackers since these vulnerabilities allow access to such data as credit card details.” The implication is that XSS is in active use by blackhats to commit fraud and that it’s being used as a vehicle to bring systems to a halt; not only can we not know that based on what was released, but they also go against things that we know to be true (such as, for example, that XSS can’t bring a system down.) Moreover, the data from Mitre doesn’t account for usage of vulnerabilities – it’s just their appearance that gets tracked.

So “caveat lector.” All we can say for sure based on the data is that researchers are finding more XSS vulnerabilities; there could be a number of reasons for this not having to do with attackers using it more. Maybe cross-site scripting is easier to find (it is) or maybe web-based products that might be impacted by xss are more popular now than three years ago (they are). I don’t think we can draw conclusions about anything other than the fact that XSS is more popular with researchers – we can’t/don’t know anything about the popularity with attackers or level of risk associated with a XSS vs. a buffer overflow.

By now, you’ve probably seen the news coverage about the French Ministry of Defense and their analysis of OpenOffice. You may have even seen the OO.org rebuttal where they claim that it’s “all good” over there and that anything to the contrary is bull. All in all, it’s an interesting debate.

What’s interesting to me is not whether or not OpenOffice is more secure – after all, I’m sure it has its security advantages (like the fact that researchers/haxors are targeting it less) and its security disadvantages (like leaving out anti-macro-virus countermeasures). However, what I find fascinating is the general unwillingness on the part of indviduals to accept that Microsof Office might have a lesser attack surface than OpenOffice. Maybe it does and maybe it doesn’t, but why is the discussion so loaded?

Look, the word on the street is that OpenOffice is clearly more secure – that it’s 100 times more secure in fact. But where is the evidence? Why are we so unwilling to accept that MSFT might have made some advances, and why are we so willing to accept that OpenOffice is superior just because it’s an open-source project? Shouldn’t we be objective?