Re: Messenger Service on W2K server

From: Bill Sanderson (bill_NoSpamSanderson@msn.com)
Date: 10/17/02 

From: "Bill Sanderson" <bill_NoSpamSanderson@msn.com>
Date: Thu, 17 Oct 2002 08:33:45 -0400

I don't know--my sense of this thing is we don't need a patch--just an app
like ISLOCKDN (sp?) that uses existing settings to set things to a safer
default. Unless, of course, there's a buffer overflow exploit in the
messenger service--it's kind of hard to believe there isn't.

"David Williams" <davidwnh@ncia.net> wrote in message
news:elTmhVbdCHA.2400@tkmsftngp10...
> Well you got me to learn something new in any case !
> Regards
>
> It's kinda funny(so to speak) but I saw a segment on TechTV about 6 months
> ago about this issue where a 24 yr old reported this "exploit" to MS and
> they basically shunned his concern. They recapped it again tonight on the
> same show because of the recent activity. I guess we'll see another patch
> soon :)
>
> "Gary Flynn" <flynngn@jmu.edu> wrote in message
> news:3DAD7F6A.6392325C@jmu.edu...
> > David Williams wrote:
> > >
> > > Gary,
> > >
> > > Thanks for the info on blocking UDP-135! Looks like you were
> instrumental in
> > > this solution.
> >
> > No, I can't claim credit for that. Some folks at other universities
> > found the UDP-135 traffic way back on the 10th and 11th. I was just
> > trying to confirm their findings on my computers because there was
> > a lot of conflicting information about what other ports may be used.
> > I was also looking to see the ramifications and alternatives to
> > outright port blocking and desktop service shutdowns. I still haven't
> > got my arms around that.
> >
> > Its important to realize that all we can say with certainty at this
> > point is that the DirectAdvertisor service often uses UDP-135. The
> > Messenger service may also be available through TCP-135 and maybe even
> > through 139. RPC supports many access protocols and I'm confused
> > about what is implementation dependent and what is supported in
> > the core RPC services. Its interesting to note that there is even
> > an IIS RPC proxy that would enable clients to access RPC services
> > behind a firewall through port 80. Luckily, it doesn't appear that
> > this service runs by default on IIS.
> >
> > Others have mentioned seeing the "net send" command use ports
> > other than UDP-135. In fact, most of the reports I saw said
> > it used 139. My own test used UDP-135 but I only ran it from
> > the same two systems and only enough to verify that it sometimes
> > uses UDP-135. This may not be the end of the story or the
> > incidents :(
> >
> > > Looking at item #3 Are you in effect breaking DCOM on the server in
> which
> > > you have made these settings?
> >
> > As the documentation suggests, the setting would break remote access
> > to DCOM services. I wasn't sure if it would also break remote access
> > to non-DCOM RPC services but that is what appears to happen...at least
> > on an XP Home system. Kind of makes sense considering the registry
> > key involved.
> >
> > Right now, I'm thinking this would be an alternative to shutting down
> > the Messenger service altogether if it couldn't be firewalled. This
> > would permit the use of the service for local applications to alert
> > the local user but not for remote applications to do the same...or
> > to abuse it. I saw some things that made me believe the local user
> > may miss out on important messages if the service was shut down
> > entirely...like event log full messages.
> >
> > While blocking access with a firewall may be the best solution, this
> > doesn't help the 20-30 million home cable/DSL users. It would be
> > better to find a way to limit remote access to the service and, in
> > the future, make that the shipping configuration. The XP firewall
> > will probably protect it but I'd rather see the problem fixed
> > at the root rather than covering it up with a bandaid.
> >
> > The question now is...what remote services regularly use RPC/DCOM?
> > Surely, we wouldn't want to break this on a server known to offer
> > services and applications written around RPC and DCOM but what
> > about on the average, Internet connected user's desktop?
> >
> > > That I can't say for sure since the article
> > > says always "Y" for that reg entry and doesn't explain the
consequences
> of
> > > "N".
> >
> > Yea. I took a shot in the dark :)
> >
> > > However it looks like this is to be used in conjunction with the
others
> > > reg settings in the article for a different, however related purpose.
> >
> > True.
> >
> > --
> > Gary Flynn
> > Security Engineer - Technical Services
> > James Madison University
> >
> > Please R.U.N.S.A.F.E.
> > http://www.jmu.edu/computing/runsafe
>
>