Full Disclosure mailing list archives
Re: DCOM RPC exploit (dcom.c)
From: w g <xillwillx () yahoo com>
Date: Sun, 27 Jul 2003 17:56:12 -0700 (PDT)
ive noticed ever since i posted to bugtraq and this list my site http://illmob.org has been under attack from ddos... lame H D Moore <fdlist () digitaloffense net> wrote:On Saturday 26 July 2003 07:16 pm, Chris Paget wrote:
Personally, I'm tempted to set up my firewall to NAT incoming requests on port 135 to either www.metasploit.com or www.xfocus.org. I know this is the full-disclosure list, but working exploit code for an issue this huge is taking it a bit far, especially less than 2 weeks after the advisory comes out.
So you are going to intentionally DoS my web server because you don't agree with full disclosure? Go right ahead, it will do wonders for the your own credibility and that of your company. If you are going to make threats of that nature, at least have the decency to post from a non-work account. You have just destroyed any moral ground you had to stand on in regards to exploit disclosure policy. Stick your head back in the sand. There are a number of reasons why I write and release fully-functional exploits. The first one is easy; even after xfocus.org released their exploit code, there still wasn't enough widespread awareness of the issue to convince many people to patch. Releasing *functional* exploit code to the public is one of the few methods that actually make a difference when it comes to improving the overall security of the Internet. Just because my exploit wasn't available to the public at large until yesterday doesn't mean there weren't people exploiting systems for the last two weeks. There are at least four different exploits that I am aware of that were not based on the xfocus code. These exploits were already in the hands of the "script kiddies" and they have had free reign of most of the internet for at least a week or so. I feel that providing people with an accurate way to determine their risk to a given vulnerability is a good thing. There will always be people who will use these types of tools for malicious purposes, but the overall goal is to motivate people to patch their systems. The second reason is related to what I do for a living. I work for a company that provides penetration testing and vulnerability assessment services. Writing exploits is time consuming and can be fairly difficult. Since the security industry has started to shy away from releasing even proof of concept code, there has been a huge gap of available exploit code that I need to fill to do my job. While I could keep them all private, I prefer to make them available to administrators and other security professionals so that they can guage the risk to the systems they work with. Unfortunately, its not possible to verify that everyone who asks for a copy of the exploit has the best intentions in mind. Even if I created a registration system, the code would still be leaked and it would have zero effect on the availability of the exploit. IDS vendors have the same problem, all of the good exploits are private these days, if they can't capture it in the wild, they can't detect it in their products. The lack of public exploit code has absolutly no relation to what most of the malicious types are able to compromise. If they can't detect an attack, they will more than likely lose a customer. The recent Samba vulnerability is a perfect example about why full disclosure is a good thing. I "discovered" the vulnerability while watching someone crack into an external server using a private exploit. The exploit was effective in providing remote root access in under thirty seconds. This vulnerability had been in the Samba code for over eight years, there is still speculation as to how long people had been exploiting it in the wild. When the advisory and exploit code was made public, there was a massive backlash about how we were "endangering millions of users". They failed to take into account that the people they need to worry about already had the means to exploit to vulnerability. This "bury your head in the sand" attitude is the reason why I continue to release exploits the way I do and why I have no plans to remove the DCOM code from my web site. The problem with buggy exploits is that when someone uses them to test their system and they don't work, the common reaction is to put off patching until a more convenient time. The public perception seems to be that risks are directly associated with available exploits. This is far from the truth. The reasoning behind it can be directly attributed the media in general and a few large security companies in particular. There is a common thread among the media when reporting security issues: "Whose fault is it?". If the exploit for a vulnerability is not public yet, they tend to blame the vendor. If an expoit has been released, they blame the author. If a worm is on the lose that utilizes the vulnerability as an attack vector, they blame the end users and administrators. The result of all this is that people stopped releasing exploits to avoid bad press. I can name at least three well-known researchers who have stopped releasing code simply because of the media backlash they received when doing so. The really twisted part about this are the quotes the reporters use when writing their articles. Often they will call people who work at security companies that practice non-disclosure and ask them what they think of an exploit release. The ironic part is that many of the people who provide these quotes depend on publicly available code to provide their own penetration testing services. The really silly part is that now there are companies who make thier bread money by selling commercial exploits. What makes them "responsible" in the public eye is that they only sell thier tools to people with "good intentions". This usually means they verify that you have a job where you have a legitamate need for their product. This verification procedure can only be so strict, many large institutions may want to use this product to gauge their risk to given vulnerability. Not all of the clients restrict their use of the product to work related activities. As of a couple months ago, pirated copies of these products are already circulating in the underground. There are actually a number of good reasons for not releasing exploit code. Public exploits tend to provide capabilities to the average user that they really shouldn't have. This results in many less-skilled users compromising hosts with public exploits. I certainly agree that this is not a desirable situation. The main problem is that there is not a way to securely distribute exploits to the people who need them legitamately and still keep them out of the hands of those who have malicious intent. Many times these are the same people; there have been quite a few high-profile criminal cases where the perpetrator had a day job as a system administrator. A registration system may slow down the public distribution of an exploit, but the disclosure timeline will get progressively smaller inversely proportional to the number of users. In the future, I might look into alternative methods of distribution as well some benign exploit payloads, but I do not believe that releasing crippled code or binary-only proof-of-concepts will make a significant impact on the availabilty of functional exploits. I feel that the benefit of having publicly available exploit code far outweighs the side effect of arming the less-skilled and less-connected malicous parties. See you in Vegas? -HD _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html --------------------------------- Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo.
Current thread:
- Re: DCOM RPC exploit (dcom.c), (continued)
- Re: DCOM RPC exploit (dcom.c) Paul Schmehl (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Nathan Seven (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Neeko Oni (Jul 26)
- Re: DCOM RPC exploit (dcom.c) Blue Boar (Jul 26)
- Re: DCOM RPC exploit (dcom.c) security snot (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Blue Boar (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Georgi Guninski (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Chris Paget (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Valdis . Kletnieks (Jul 27)
- Re: DCOM RPC exploit (dcom.c) H D Moore (Jul 27)
- Re: DCOM RPC exploit (dcom.c) w g (Jul 27)
- Re: DCOM RPC exploit w g (Jul 26)
- Re: DCOM RPC exploit (dcom.c) Valdis . Kletnieks (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Neeko Oni (Jul 27)
- Re: DCOM RPC exploit (dcom.c) tcpdumb (Jul 27)
- Re: DCOM RPC exploit (dcom.c) El Guille (Jul 27)