On Mon, 8 Oct 2001, Michael Janke wrote:
> Ron DuFresne wrote:
> > The more you describe this, the more it appears to be merely a secondary
> > affect from those systems with the mis-installed <the novell client
> > stacks should not be there, right?>, systems infested with nimda worm
> > code. What might be interesting and of concern is the external replies
> > echoing back from those misconfigured systems initial probes for an NDS
> > server. Sounds like there well might be open novell servers responding,
> > which may open a new attack vector for future worm code to also attempt to
> > abuse.
> >
> > AFAIK, nimda was not coded to utilize novell protocols as an attack
> > vector, and the analysis of the code was pretty intensive. On a
> > compromised unix system, it is not key that the system might have been
> > setup with an illegit irc server after compromise, what is key is how the
> > system was compromised and how to prevent future compromises. The illegit
> > irc server is merely a secondary affect of the former.
> >
> > Thanks,
> >
> > Ron DuFresne
> [..]
>
> All the scan source PC's that we found at our sites so far had a late-version
> Novell client. My assumption is:
>
> 1) The analysis(s) were not done on PC's with Novell clients.
That should not matter, the analysis was thourough enough to have caught
any special hooks for netware specific attack vectors.
>
> 2) The worm makes network system calls at a 'higher' or 'more abstract' layer in
> the Windows API, and the Novell client intercepts these calls and sends them out
> via TCP 524 (Netware Core Protocol) and IPX. I believe that this would be normal
> behaivior for any app that uses network resources on a Windows desktop with
> multiple network clients installed. The app does not know or need to know what
> type of server it is using. The Windows API hides that.
>
> If I open up 'Network Neighborhood' on my Novell client equipt desktop I send
> out broadcasts & multicasts via all bound protocols and all loaded clients. So I
> send out broadcasts via IPX and Netbios-TCP/IP, and multicasts via TCP for both
> Win2K and Netware 5. If I had NetBUEI loaded, I'd send out a broadcast via that
> protocol also. That functionality is a part of Windows network stack and API,
> and the level of integration of the Netware client into the Windows stack. From
> my desktop I can open a UNC path to any NT or Netware server without knowing or
> caring about the difference. Just whack-whack-server-whack-vol-whack-dir, except
> that <vol> on Netware equates to <share> on NT. The whacks & the results are the
> same.
>
> Another example would be Windows printing. I can take a printer that was using a
> Novell queue via IPX and swtch it to a LPD/LPR printer, & my applications don't
> know or care about the diference. The API they call is not protocol specific.
>
> If the worm calls an API function that is not protocol specific, the function
> call could/would get replicated on all bound protocol/client combinations, hence
> the combined UDP/137 and TCP/524 scans. I know that most of the file-mangling
> worms that have come out lately don't care if I map a drive to a Netware server
> via IPX or to an NT server via CIFS, they will still find the mapped drive and
> muck it up. Apparently whatever function they call to enumerate remote drives is
> not protocol specific.
>
> Only a theory though, as I haven't looked at the Windows API since v3.0.
>
> If my theory is valid, it is a possible avenue of infection.
>
> I wish I could hook up an analyser & infect my PC, but we've got 90% of our IT
> employees out on strike right now, so I don't have any staff available for this
> kind of stuff. I've got to do real work this week. :-)
>
It would be nice if you did so that this could be fully determined, yet,
from your original post in this:
The probes appear to be coming from ordinary PC's, both internal and
external to our network. The probes follow a regular pattern of 3
probes followed by DNS and Netbios lookups. The probes appear to
scan their own class 'A' and 'B' more often than other networks,
but will jump randomly a percentage of the time. The time between
packets and the packet lengths are very consistent across many
scans.
To my mind this merely indicates the systems in question were trying to do
normal braodcasts under the protocol stacks in question to determine what
other systems are within 'talking range'. Unless the netware clients were
in use, unless you have a netware server in place talking with these
clients, and I got the impression that the discovery of netware clients on
those systems was a surprise, correct me if I assumed incorrectly, that
these systems are still looking for an NDS server to loginto and or locate
other netware aware systems, not finding those it broadcasts in the other
discovery protocols you document to update it search patterns and retry.
This certainly seems to explain the points you make about "The time
between packets and the packet lengths are very consistent across many
scans". So, merely a secondary affect from infested systems with netware
clients whence it seems they should not be anyways. Yet, I may have
misread your report. Had/if your original packet scans show more of the
packet contents, this can be determined from those packet traces.
Thanks,
Ron DuFresne
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
***testing, only testing, and damn good at it too!***
OK, so you're a Ph.D. Just don't touch anything.
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
