Thursday, November 03, 2011

thoughts on metasploit's impact

i listened to the network security podcast #257 this afternoon, specifically because i wanted to hear what martin mckeay, josh corman, and hd moore had to say about metasploit and what josh corman calls HD Moore's Law. there were a lot of mentions of PCI and being 'this tall to ride the internet', but the comment that really caught my ear (i was listening to it rather than reading it after all) was that metasploit allows people to test their security against the attacks that are readily available.

and then a voice in the back of my head said "yeah, but metasploit is what makes those attacks readily available". it's essentially equivalent to saying that the readily available attacks allow people to test their security against the readily available attacks - i believe the way the internet identifies such tautologies these days is by saying "obvious statement is obvious".

one of the interesting things josh corman brought to the conversation was a breakdown of adversary classes (i encourage you to read his post that i linked to above, not only for that breakdown but also a visualization of their relative success rates against a scale of defender strengths) and it occurs to me that, in the absence of metasploit, these so-called readily available attacks that are in the hands of the casual attacker wouldn't generally be in the hands of the casual attacker (and thus wouldn't be the readily available attacks) but rather in the hands of adversaries of a higher calibre.

one thing that isn't really mentioned but seems fairly obvious is that the higher up you go on the scale of adversary classes, the smaller the population will be (the more skills one has the rarer one becomes) and consequently the smaller the aggregate pool of practical targets will be (since there's a limit to what any one given person can pull off in a given period of time, the manpower available to an attacker is a finite resource). that means that in the absence of metasploit, these attacks would be directly impacting fewer systems - probably more important systems, but fewer systems in total.

now before i go any further, lets address an assumption i've made. i think it's an obvious one. you've probably had it on the tip of your tongue for at least the past two paragraphs. the assumption is that in the absence of metasploit nothing else would pop up to take it's place. for my purposes, that's actually not so much an assumption as it is an ideal starting point or degenerate case from which to build a more complex model.

so let's say that another group of well-meaning researchers decided to pick up the gauntlet. i see no intrinsic difference between that hypothetical case and the actual case we have with metasploit right now. that makes it really not that interesting an alternative, because it's not really alternative in any meaningful sense. the more interesting alternative lies in the argument that if the good guys didn't do it, if they were all too principled (for lack of a better word) to follow that path, then the bad guys certainly would.

so in that case let's say a group of ne'er do wells decided to produce a similar tool. would it be the same? would it have the same properties and present the same problems? i would argue that it wouldn't - that the incentives in the underground community are different enough that what would be produced either would not be free (and therefore not available to all casual adversaries) or it would not be as capable as metasploit would have been (perhaps because the best exploits would get held back in order to give the developers a competitive or strategic advantage over the attackers they're helping for free). the motive of doing it for the benefit of everyone (that drives the excellence found in the free edition of metasploit) simply isn't compatible with financially motivated cybercrime. greed and selflessness don't mix, so a criminal-driven equivalent to metasploit wouldn't lower the bar as far as metasploit does.

so what am i trying to say? what am i really getting at with all of this? the TL;DR version is that the metasploit folks are too nice to people, including the bad guys. the notion that metasploit represents the attacks that are readily available suggests to me that they lower the bar too much. no one seems to disagree that metasploit is a tool that is used by script kiddies (among others) and so i'm left to wonder very seriously whether there's an actual legitimate use case for metasploit that involves such a completely unskilled user. leave no user behind? i think under the circumstances an exception deserves to be made.

7 comments:

Infosec Enthusiast said...

A very good post. To add to what you're saying we need to keep the balance for the unskilled to learn and build on their knowledge and skillset. That being said, it shouldn't be too easy a tool either. Map that to frameworks, standards such as PCI, ISO 2700x series and you'll come across many that think they can recite the ISO standard word for word or sing PCI in their sleep so they know how to implement it.

kurt wismer said...

very true, there does need to be something that people can learn on. i don't think metasploit needs to be that thing. there are some things you just don't put training wheels on and let newbies drive - you make them learn on something safer instead, and once they have learned then you let them at the more dangerous thing.

Anonymous said...

Nice post, and yes I had that argument on the tip of my tongue as I read!

1. I'd still say, despite what you posted, that in the absence of Metasploit, we'd still have some measure of tools to automate things that would be available to script kiddies (or any color hats or researchers...). At some point, releasing tools for no profit is still a situation. We just don't typically see much in Metasploit's category because Metasploit fills a bit space quite well. Ultimately, I'd say Metasploit was made for the good guys, as opposed to the bad ones.

2. Metasploit can act as a quick win for budding security experts. Popping one's first box with Metasploit (just like any tool) is a very building-block sort of event.

Does that mean it's bad? I doubt it, and you're probably already anticipating the, "it's a tool..." argument that would inevitably bring up guns as the metaphor of choice. :) Still, I'd call that a use case for such a tool to unskilled users.

3. Lastly, and you've probably also thought of this as well, I'd say that Metasploit is just making something that is already a problem, simply easier to exploit. Whether Metasploit is present or not really doesn't affect any weaknesses it is leveraged against. That might actually be part of your point for how rare truly skilled people are and Metasploit brings down the bar. And I'd accept that. :)

But we also dance the line of that really awful discussion about obscurity such as the example that SSH is more secure on a non-default port vs SSH on the default port. A vulnerability is still present regardless whether people know it or not, or whether there are barriers (knowledgewise, tools, security) or not. Whether Metasploit makes it easy for an adversary or not, doesn't change the fact that the vulnerability is still there waiting to be popped.

-LonerVamp

Anonymous said...

As a side note, I swear I've seen those adversary classes recently somewhere else, maybe Hoff's blog or Securosis or linked from there...something about nation-states and how they overlap with rogue actors and such. Maybe it's just such a general concept that any listing will sound the same...

-LonerVamp

. said...

I disagree that metasploit poses an unnecessary threat, or that it lowers the bar. The primary problem with 'readily available' attacks is that there's lots of them, and they allow such a high level of damage. If your software is full of holes which allow remote root access via trivial attacks, it's not the fault of metasploit.

Further, this wouldn't be a problem is operating systems were designed securely - and by this I mean, designed with security in mind, and not security tacked on, such as virus scanners and various other blacklisting systems which need constant updating. The system should be impervious to remote exploitation already, not one that needs a giant wall built around it, ever thicker and stronger to prevent a single malicious microbe getting in.

If you can exploit an application, which already has a high privilege level by default so 'everything just works', and use this to exploit the OS and the entire hardware set, you've failed in designing your OS properly.

TL;DR saying that metasploit makes it 'too easy' to run exploits is misinformed; having insecure applications and OS's makes it too easy for noobs to cause damage with simple exploits. This would be like saying that mag-strip scanners be banned worldwide because it makes it too easy for small-time criminals to scam credit cards; why not just invent a better system? (yes, I know, chip+pin)

The debate on 'software weapons' has been going since the beginning of time. You might as well say ping makes it too easy to run a DoS on a remote system.

Strengthen insecure systems. Design them to be secure. Any readily available remote exploits for IBM mainframes? Didn't think so.

kurt wismer said...

@Lonervamp
1) yes, i suspect there would still be tools available to the script kiddies too - but if the tools aren't being created by the good guys (who are motivated to make it both free and the best it can possibly be at the same time) then it seems to me like the lowest adversary class wouldn't be quite as empowered as they are right now.

2) i don't think it's necessary to bring up guns. yes, i understand that unskilled users require a tool to learn with, but as i said in another comment here i don't think metasploit needs to be that learning tool. i think it's possible to address elevating the unskilled using something else, perhaps something that hasn't been made yet. one-size-fits-all certainly has it's advantages but it also often leads to undesirable and unintended consequences.

3) yes, that exactly what i think, that metasploit makes vulnerabilities easier to exploit. frankly, that seems to be the implication of what josh corman was saying - it's doesn't just lower the bar for the casual adversary, it sets that bar, it is the bar.

4(unnumbered)) yes, we are dancing around the obscurity argument. i still hold by what i said here about the relationship between obscurity and security. i don't think there's any security in obscurity but i do think that in a world of finite resources it can lead to a similar outcome of safety that we're looking for.

5(second comment, unnumbered)) i believe you're right, i think i've seen mention of adversary classes elsewhere as well. josh corman's explanation was good enough for me for this purpose, though.

kurt wismer said...

@.

(that's a very succinct name)

i'm not blaming vulnerabilities on metasploit. i don't think we'd all be more secure without metasploit. what i think is that casual adversaries would have a smaller pool of readily available attacks to choose from if it weren't for metasploit, and i think that would make us safer (there is a world of difference between safe and secure).

also, i don't believe the argument that we should just design our systems to be secure is fruitful. this may be a fundamental philosophical difference between us, but as i see it vulnerabilities arise out of the fact that we can't anticipate every possible outcome for every existing conditional evaluation involving every possible input. i think that it's very much a matter of hindsight being 20/20. i think that the problem of anticipating outcomes for arbitrarily complex functions is probably intractable.

finally, the question of readily available attacks for IBM mainframes seems like a strawman. there are a lot of variables involved in evaluating the set of readily available attacks that we're aware of, not the least of which being how many people we know who are actively looking for them. mainframes are no longer a mainstream platform and are not receiving the same kind of attention that PCs are.