Full Disclosure mailing list archives
RE: DCOM RPC exploit (dcom.c)
From: "Marc Maiffret" <marc () eeye com>
Date: Mon, 28 Jul 2003 13:47:13 -0700
Most of the mail I have been reading on this list is rather incorrect. All this talk about hard coded offsets to specific OS patch levels is very old school. A worm wouldn't need to determine (brute force) what offset to use on the remote system or any of that sort of archaic technique, were past the "Tao of Windows overflows" aren't we? :-o There are plenty of tricks to make this exploit happen 99.99999% of the time. I'm sure someone will drop an exploit that doesn't suck soon. The LSD guys paper even covers some of these tricks so go read. Also saw someone make a comment about reading the remote registry to make your exploit more accurate. That's not only totally inaccurate (you don't have permission to) but even more so very much overkill as you don't need to know the remote OS level to make your exploit work 99.99999%. all of your Blackhat/Defcon tequila are belong to us. Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities | -----Original Message----- | From: full-disclosure-admin () lists netsys com | [mailto:full-disclosure-admin () lists netsys com]On Behalf Of Robert | Wesley McGrew | Sent: Monday, July 28, 2003 10:11 AM | To: full-disclosure () lists netsys com | Subject: RE: [Full-disclosure] DCOM RPC exploit (dcom.c) | | | | | On Mon, 28 Jul 2003, Schmehl, Paul L wrote: | | > > 2) For this DCOM RPC problem in particular, everyone's | > > talking about worms. How would the worm know what return | > > address to use? Remote OS fingerprinting would mean it would | > > be relatively large, slow, and unreliable (compared with | > > Slammer), and sticking with one would cause more machines to | > > just crash than to spread the worm. I haven't looked into | > > this very closely yet to see if it can be generalized. | > | > What fingerprinting? If you've got 135/UDP open to the Internet, you're | > screwed. Slammer didn't fingerprint. It simply hit every box it could | > find on port 1434/UDP, and the exploit either worked or it didn't. Most | > worms do the same. They attack indiscriminately, and infect those Oses | > that are susceptible. And with Windows, that's enough boxes to cause a | > real problem. | | Thanks for responding. I realize that having 135 open on any Windows | machine makes you vulnerable, and that you wouldn't need to differentiate | Windows/OtherOSes. My question is about different Windows versions. The | version (NT/2000/XP), service pack, and language at least have to be known | to get the return address right. If it's "guessed" wrong, the system goes | down with no shell executed. | | Any worm using this would need to know the return address before | attempting to exploit If a worm were to stick to targetting one return | address (say, English XP SP1), everytime it ran across something slightly | different (SP0, german, win2k, etc) it would simply crash it and not | spread. One of three things would happen in the case of this worm : | | 1) Sticks with one return address, makes a spectacular DoS against all | other languages/versions/SPs. This could limit how quickly it spreads. | | 2) Somehow finds out ahead of time what the remote language/version/SP is. | Could be very unreliable and slow. | | 3) There is some way of generalizing the return address in a way that | would work on at least a large portion of installs. This is what would | bring it into the league of Very Scary Worms. | | Has anyone seen any indication in the private exploits or in their | research that there's a way to get it to work reliably on systems without | having to know version/SP/etc? | | _______________________________________________ | Full-Disclosure - We believe in it. | Charter: http://lists.netsys.com/full-disclosure-charter.html | _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- Re: DCOM RPC exploit (dcom.c), (continued)
- Re: DCOM RPC exploit (dcom.c) Curt Purdy (Jul 31)
- Re: Re: DCOM RPC exploit (dcom.c) Jennifer Bradley (Jul 27)
- Re: DCOM RPC exploit (dcom.c) dhtml (Jul 27)
- Re: DCOM RPC exploit (dcom.c) dhtml (Jul 27)
- Re: DCOM RPC exploit (dcom.c) CHeeKY (Jul 27)
- RE: DCOM RPC exploit (dcom.c) Schmehl, Paul L (Jul 28)
- RE: DCOM RPC exploit (dcom.c) Ron DuFresne (Jul 28)
- RE: DCOM RPC exploit (dcom.c) Robert Wesley McGrew (Jul 28)
- RE: DCOM RPC exploit (dcom.c) gml (Jul 28)
- Re: DCOM RPC exploit (dcom.c) Valdis . Kletnieks (Jul 28)
- RE: DCOM RPC exploit (dcom.c) Marc Maiffret (Jul 28)
- RE: DCOM RPC exploit (dcom.c) Schmehl, Paul L (Jul 28)
- RE: DCOM RPC exploit (dcom.c) Ron DuFresne (Jul 28)
- RE: DCOM RPC exploit (dcom.c) Admin GSecur (Jul 28)
- RE: DCOM RPC exploit (dcom.c) Nick FitzGerald (Jul 28)
- RE: DCOM RPC exploit (dcom.c) Thiago Campos (Jul 28)
- RE: DCOM RPC exploit (dcom.c) John . Airey (Jul 29)
- RE: DCOM RPC exploit (dcom.c) Nick FitzGerald (Jul 29)
- RE: DCOM RPC exploit (dcom.c) Schmehl, Paul L (Jul 29)
- Re: DCOM RPC exploit (dcom.c) Robert Banniza (Jul 29)
- Re: DCOM RPC exploit (dcom.c) Preston Newton (Jul 30)
- Re: DCOM RPC exploit (dcom.c) Robert Banniza (Jul 29)
(Thread continues...)