RE: SUMMARY: SMB overflow attacks

[monti <monti () ushost com>]

On Thu, 29 Aug 2002, Jason Coombs wrote:

> However, port 1025 is still being bound by SYSTEM ... I have no idea why.

Try rpcdump.exe (on windows -- may wrap):
http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/rpcdump-o.asp

or dcetest by David Aitel (on Unix):
http://freshmeat.net/projects/dcetest/?topic_id=43
<props to Mr. Aitel; Unix-2-Win2k utils are muy good!/>

Your port 1025 may be identifiable using either of these tools, but you'll
need to re-enable the DCE endpoint mapper (port 135) if you've turned it
off. 


On a (rather long) side note, this isn't entirely true:

> Microsoft added the ability to run SMB directly over TCP/IP, without
> the extra layer of NBT. This is what happens on port 445.

Based on my own tests, SMB still is (or can be?) encapsulated in netbios
on port 445.  What they appear to have gotten rid of was the NB Session
Setup that precludes SMB negotiation and session setup on port 139. 

NB Session Setup is where the client requests a session on the server by
providing a calling(its own) and called(server's) netbios name and the
server responds with a positive session response if it likes the called
name. It looks like M$ didnt completely do away with NetBIOS on 445, just
the netbios naming stuff.

My best guess is that the NB layer is used for 'fragmenting' over-long SMB
packets (i've seen this happen on 445 and it uses NBSS continuation
packets), and possibly for determining the length of SMB's themselves. Who
really knows? but it's still there. 

I should note that my testing so far has been with Samba clients to
initiate connections. I cant verify whether this behavior exists between
two W2k boxen. It would seem to indicate it though. At any rate, it does
prove NBT is at least available on 445.
<props to Samba too!/>

Cheers, and thanks for sharing the info on shutting it down :)

-Eric Monti