Great Circle Associates Firewalls
(August 1996)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: FW: Novell Vulnerabilities
From: Marc Mosko <marc @ tear . com>
Date: Thu, 29 Aug 1996 14:01:21 -0700
To: firewalls <firewalls @ GreatCircle . COM>
References: <3225B1BC @ mnbp . network . com>
Reply-to: marc @ tear . com

It depends which client software you use and what server version. 
Netware 4.x with the VLM client software CAN be made to use "packet
signatures".  These are derived from the RSA certificate and are session
based.  They work with both IPX (connectionless) and SPX (connection
oriented) exchanges.  These are a good protection layer.  Also with 4.x
and VLM you get the RSA login encryption.

With NetWare 3 or the NETX client software, things are much less
secure.  You run in to many of the same problems that IP has with
spoofing.  Most all NetWare operations (called NCP -- NetWare Core
Protocol) are IPX based.  The requests are identified by a "connection"
identifier.  This can all be spoofed.  You need, like IP, promiscuous
access to the network.

You can do password crackers just as easily -- if not easier -- than
UNIX, especailly for Bindery.  As long as there are not incorrect login
attempt limits.  There's also a funciton NWVerifyObjectPassword(), and
I'm not sure if calling this will count against incorrect login
attempts  (I've not played with this function, so it might be that you
need an authenticated connection).

With NetWare 3 and especially 4, there's a wealth of information
NON-authenticated users can get.  I'm not too familiar with 3.x server
APIs, but in NetWare 4 you can get a wealth of information by virtue of
the PUBLIC object.  This "group" applies to all object and connections
to the directory tree.  Even unauthenticated connections.  That's how
you login.  The PUBLIC trustee needs minimal rights to see user objects
and read /compare certain specific properties.  If you have given PUBLIC
extra rights (as a poor substitute for creating groups, or giving the
rights to [ROOT], which only applies to authenticated users) then you
give the hacker a bunch of information.

Sometimes IPX is tunneled through other protocols (i.e. IP).  This
usually obviates any IPX packet filters running on intermediate
routers.  Be careful with these.

IPX diagnostic services can give you a wealth of information about
Servers and workstations -- to anyone!  You can disable this on
workstations by loading IPXODI with the appropriate flag (think it's
/d).  Any user can get all sorts of information about your 3.x servers
via the client API.  4.x is a bit more restricted, but generally just as
talkative.  Information includes things like how many LAN cards, all the
addresses bound to the cards, disk controllers, maximum connections,
etc.

Russell J. Dwire wrote:
> 
> Hopefully you guys can help me.
> 
> Russell
>  ----------
> From: Jeff D. Hayes
> To: Russell J. Dwire
> Subject: FW: Novell Vulnerabilities
> Date: Wednesday, August 28, 1996 8:45PM
> 
> If you don't get a good response, I would post your message to
> firewalls @
 greatcircle .
 com .
   I can't provide you the details you need.
> 
>  -jeff
>  ----------
> From: owner-demigods
> To: demigods
> Subject: Novell Vulnerabilities
> Date: Wednesday, August 28, 1996 4:06PM
> 
> Folks,
> 
> I would like to gather any information on (Novell) IPX vulnerabilities.  I
> want to identify possible ways an individual can infiltrate (hack) into a
> network, it is common knowledge concerning attacks on IP networks.
> (spoofing and collecting information through to process of using a passive
> listening deviceS and fragmentation attacks etc.).  What about IPX?



-- 
   Marc Mosko                   Email: marc @
 tear .
 com
                                Web:   http://www.tear.com/

   "If anyone knocks out another's eye, he shall pay him
   sixty-six shillings, six pence, and a third of a penny."
   -- Leges Henrici Primi (13th century)

           PGP Key availabe via Public Servers and
               http://www.tear.com/pgp-key.html


References:
Indexed By Date Previous: Blocking non-http (executable) content
From: carl @ hdshq . com
Next: Re: Novell Vulnerabilities
From: Marc Mosko <marc @ tear . com>
Indexed By Thread Previous: FW: Novell Vulnerabilities
From: "Russell J. Dwire" <dwirerj @ vavi . network . com>
Next: RE: Novell Vulnerabilities
From: Keith McCammon <keithm @ asymetrix . com>

Google
 
Search Internet Search www.greatcircle.com