From: sockz loves you To: full-disclosure@lists.netsys.com Subject: Security Industry Under Scrutiny: Part 3 Date: Thu, 05 Dec 2002 18:41:40 -0500 You say, 'Hail, Full-Disclosure.' Full-Disclosure hits YOU for 492 points! You cry. First off I want to say that I'm extremely open to intelligent debate. The key word in that statement being "intelligent". I am no longer paying attention to personal attacks, or people who try to use buzz-words and trendy phrases as the basis for their logic. YOU PEOPLE SUCK! Secondly, THERE ARE MAIN POINTS AT THE END IF YOU DONT WANT TO READ THE ENTIRE THING. If you hate reading, are short of time, or whatever, I'd still love for you to read through the general jist of what I'm saying here. That said, I'm writing today about the flow of information in the security industry. Granted I haven't put much effort into this so far. I kinda started, and then got side-tracked with legitimate work, then had some computer problems, and have had to start again. But. I like what I have so far, so I'm putting it up for comments and constructive criticism. This wasn't where I started but I thought it was very interesting. I stumbled across this while reading through Ranum's slides to his Blackhat 2000 speech. He described the general process of the security industry as looking something like this: Flaw (not yet implemented) | V Vulnerability | V Exploit | V Disclosed Vulnerability -> Detection/Assessment Logic | | V V Toolz Patch | | V V Script Kiddiez -------> Users install patch (source: http://www.ranum.com/usenix/blackhat-2000-keynote.pdf) I think this flow diagram kinda makes sense. The main issue for Ranum isn't the flow of information though (at least not from what I could gather). I think his real focus was on the role of script kiddies in the security industry -- their relationship with whitehats and their purpose in promoting security. By looking at his diagram we can see his proposed solution would be to remove the 'tools' section from the process. For Ranum this ensures a smooth flow from flaw to patch with minimal risk to security. It seems simple, sure. But I'm tempted to think that maybe things are a bit more complex. So I tried approaching the concept from a different angle, and narrowed in on the whole "lets tell others about the bugs we've found!" scheme of things. I think my diagrams ended up a bit similar to Ranum's but different in a lot of ways. ________ | 1 | ____________ Advisory |........| Advisory _________________ | Whitehat | --------->| |------------> | Software Vendor | ............ + Proof | Report | | ................. of Concept| Vuln | | _______________ | | | | | Mailing | | -----> | | List In | | ............... | | Tool + _______________ | |------------> | | Whitehat's | | Advisory | | Website ........ ............... _________ | 2 | Tool + |.........| Advisory ________________ _______________ | Process |------------> | Script Kiddies | | | Whitehat's | Site | | ................ | | Website ------>| Traffic | | ________________ ............... | | -----> | System Admins | ......... ................ What happens after the second stage is that the script kiddy attacks a system and/or a system admin patches their system. As I continually state, a script kiddy can attack many systems, while an admin can only fix one system. I keep reitterating this because I think it's a very important point to make, considering that script kiddies and admins find out about the bug at the same time. The way our current system works is that information is released to everybody at the same time. This means that script kiddies find out about vulnerabilities at the same time system admins do. Even if the vendor has been notified before the bug was released to the public, this system relies heavily upon all admins taking part, because if they don't a security risk is created. In effect this system forces everyone to support it, and punishes those who don't. But what is support? Support is usually charging clients for protection from vulnerabilities that the security company makes known to everyone on a regular basis. Support can also be a security company paying for whitehat's to send in bug information. Support == Money. But the fundamental problem with paying people for vulnerabilities is that you create an economic dependency upon bad security. People start to rely upon software flaws to provide money for car repayments or their mortgage. Why is this bad? Because when people with adequate skill and knowledge look for money, they are going to start to look for bugs in software. In this case, ISS pay for virgin bugs that affect many systems (because this means a greater number of their clients will need to be secured). There's something very wrong with that picture. As anyone who's read or listened to Ranum's work will realise, in making a conscious effort to look for bugs we negate the argument that "hackers already know these things exist". Maybe (though its a remote chance), one or two hackers might have realised the same vuln. So what? If its anything like the majority of posts to vuln-dev or bugtraq or even here on full-disclosure, its not something that can be used as a weapon of mass destruction. That is, in the hands of a few it poses little threat. But as we know, low threat means low return on investment for security companies. So by telling everyone about this bug, security companies know that script kiddies will then be more likely to exploit the bug. Which justifies the companies role in society as being able to fix security problems. But I'm getting way off track here. So, going back to our first process... ________ | 1 | ____________ Advisory |........| Advisory _________________ | Whitehat | --------->| |------------> | Software Vendor | ............ + Proof | Report | | ................. of Concept| Vuln | | _______________ | | | | | Mailing | | -----> | | List In | | ............... | | Tool + _______________ | |------------> | | Whitehat's | | Advisory | | Website ........ ............... In light of who will access this vuln information we can now pinpoint a few areas in need of critcal improvement. First of all is the proof of concept code being released into the wild via the whitehats website. Removing tools from the net means that you remove the threat of socially inapt morons (who have really good s34rch 3ng1n3 sk1llz ph33r) finding the information and using it to exploit others. If you don't like this idea, or if you rely upon the internet to transfer proof of concept code to someone who is legitmately seeking to improve security then why not implement another measure, make this information harder to get. You could try a 'members only' section, or ask people to email you with a good reason why they should have a copy of the code. Of course these solutions can be a bit dodgy... It would be great to hear some suggestions from the community... (yes, this is a subtle hint). The other main area of concern is the Mailing List In data store. This leads on to process 3: _________ | 3 | |.........| Acceptable ________________ _______________ | Process |------------> | | Mailing | | Mailing | Mail | Advisory | | List Out | | List In ------>| | ................ ............... | | | | Unacceptable ________________ | |------------> | | Trash?? | | Advisory | | ......... ................ _________ | 4 | |.........| Advisory ________________ _______________ | Send |------------> | Script Kiddies | (attack!) | | Mailing | Mail | | ................ | | List Out ------>| to List | | ________________ ............... | | |-----> | Software Vendor| (fix code) | | | ................ | | | ________________ | | |-----> | System Admins | (patch) | | | ................ | | | ________________ | | |-----> | Whitehats | (learn/copy) | | | ................ | | | ________________ | | -----> | Media/Society | (panic!) | | | at Large | ......... ................ I have no problem with mass communication. I think its a great invention. But when it comes to things like spam, where I start to get things that I don't need, then I begin to see a problem. In this case, we're saying that an advisory, which contain information on how to compromise a system, is not the kind of information that should be available to just *anyone*. I think there are two main problems with mailing lists: a) Moderators should be doing more to ensure that the kinds of advisories that make it to the list aren't the kind that can be used to compromise systems. We need to be more careful about what we're telling society. Some secrets are better kept from others because they are secrets that can _destroy_ others. b) We need to find a way to remove the "script kiddies" and "media/society at large" terminators from the process. Even if the advisory was written in good faith that it will help security, it is being transferred to people in society who are not bound by any professional ethic to improve security. Unlike software vendors, whitehats, and system admins, these people can get away with harbouring malicious intentions because they are not expected to act any differently. There are a lot of bad people out there. People who spoil the fun for everyone. We need to design ways of transmitting information about security to people who can _improve_ security and NOT destroy it. Otherwise the entire system fails. To abrubtly CONCLUDE, I'd like to SUMMARISE with my MAIN POINTS: 1. I make cute ascii diagrams, doncha think? 2. We need to place better control measures in the following areas: a) What moderators consider to be "acceptable" advisories b) On whitehat websites that provide proof of concept code c) Lists in general, because they are read by evil ppl and not just good 3. The security industry is getting a bad name for itself because of money- grabbing "security consultants" and participants who leech information to be used for malicious activities. We need to find a way to remove these kinds of people from the system. So what am I calling for here? A new industry standard for operating business? Yes. Tighter cyber-laws for websites that seem to tell ppl "how to hack"? Yes. Computers and the internet were created to communicate and experiment. We have turned them into vehicles for profit and malicious intent. As long as we are supporting and communicating to those people who are destroying our society, we are communicating our _consent_ for them to continue making things worse. You say "information wants to be free", but whats the point in releasing something into the wild if its going to be captured and trained to rape and pillage? Let's start being more responsible with our work. Let's stop rewarding malicious people with ready-to-go exploits. Let's stop educating our enemies. <3 sockz