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.
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. :-)
--
-----------------------------------------
Michael Janke
Director, Network Services
Minnesota State Colleges and Universities
Saint Paul MN 55108
--------From real Server 7.0 startup------
Starting RealServer 7.0 Core...
Loading RealServer License Files...
Detecting Number of CPUs...
Testing 1 CPU(s): 1 CPU Detected, Phew...
-----------------------------------------
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
