[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <MKEAIJIPCGAHEFEJGDOCIEPCLDAA.marc@eeye.com>
From: marc at eeye.com (Marc Maiffret)
Subject: DCOM RPC exploit (dcom.c)
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@...ts.netsys.com
| [mailto:full-disclosure-admin@...ts.netsys.com]On Behalf Of Robert
| Wesley McGrew
| Sent: Monday, July 28, 2003 10:11 AM
| To: full-disclosure@...ts.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
|
Powered by blists - more mailing lists