			  Nomad Mobile Research Centre
			 
                        first release,     July 13, 1998
                        second release,     June 9, 1999                                         
                        third release,  November 5, 1999
				[www.nmrc.org]


Abstract
--------

This paper deals specifically with several technical flaws and weakness found
in the commercial network operating system NetWare, developed and marketed by
Novell, Inc. Covered in this paper are flaws and weaknesses that are found in
the latest shipping versions of NetWare, version 4.11 with the latest patches
applied, as well as version 5.0 SP 2, and that can totally compromise an
attacked system. This technical paper assumes a basic-to-advanced knowledge
of NetWare and networking.


1. Introduction
---------------

Novell's NetWare systems have historically been based upon a client/server
model, and Novell developed a proprietary protocol to support their
implementation of the model. This protocol is known as NetWare Core Protocol
(NCP). This protocol swelled with time to support hundreds of remote procedure
calls to NetWare inner functions, and Novell extended the NCP concepts to
embrace NDS connectivity in the protocol, their proprietary networking 
protocol runs over IPX and IP (since Netware 5).

 OSI Model  --------------------------------------------
	   | Application          any / Netware&NDS     |
	   |--------------------------------------------|                                            
	   | Transport            TCP / UDP / IPX & NCP |
	   |--------------------------------------------|
	   | Network              IP / IPX              |
	   |--------------------------------------------|
	   | Link layer           Ethernet / Token Ring |
	    --------------------------------------------

Hackers soon realized that by exploiting flaws in both Network and Transport
protocols, client packets could be "spoofed", and by properly implementing 
these flaws an administrator's NetWare session could be "hijacked" to allow 
an attacker to increase the rights of unprivileged users to privileged users. 
Two well known examples of this, the programs HACK.EXE and NW-HACK.EXE [1], 
allowed an intruder to temporarily hijack a Supervisor account long enough to 
make every valid account on the system equivalent in system rights to the 
Supervisor.

Further work was done by Greg Miller [2], with a series of programs that
exploited various aspects of both the NCP and IPX protocols, in particular
exploits that involved sniffing and capturing data during a typical user's
login sequence. And the NCP and IPX protocols were explored even more by two
Russian hackers, Eugene Ilchenko and Igor Gusev [3]. Some of the these hacking
techniques and their use in combination with other exploits and techniques are
described in detail in the Unofficial NetWare Hack FAQ compiled by
Simple Nomad [4].

The shift to Netware 5 "full IP ONLY" renders the mentioned attack programs
useless, simply because they are IPX based; yet the core Novell NCP parsing
engine remains, hence the potential flaws. 

A part of the answer to these security threats has been a series of
technologies and enhancements from Novell, including "packet signature"
(a process of signing packets with a key to prevent hijacking) and various
patches (or "security triggers" against designated attacks) to prevent a
number of NCP exploits. This paper will explore these technologies and how
well they work.

NCP Packet Signature works by using an intermediate step during the initial
login sequence to calculate a 64-bit key. This 64-bit block is never sent over
the wire in plaintext, but is used to create a signature on the most important
part of each NCP packet exchange. Per Novell's model, a signed packet that
passed muster from a cryptographic viewpoint at the server is considered a
valid packet coming from the claimed client.

There are four levels of packet signature which can be set on both the server and
client end. They are as followed:

	0 - Do not do packet signature.
	1 - Do packet signature only if requested by the other end.
	2 - If the other end will allow packet signature, do it.
	3 - Require packet signature or don't communicate.

Packet signature is an add-on to early versions of NetWare 3.11, but is a
standard part of NetWare versions since then. The default on both the client
and server end is Level 1, which means that by setting Signature Level=0 in
the client's NET.CFG file you will not be signing packets.

It should be noted that Microsoft's Netware client for Windows 95/98/NT does not
support packet signature, so if the server is Level 3 your Windows platforms
with Microsoft clients will not be able to attach [5].


2. Pandora
----------

Pandora [6] is a project that was originally released in 1997. Pandora's initial
goal was to prove it was possible to recover passwords from Novell's NetWare
Directory Services (NDS), a task that Novell boasted was impossible. Included in
second revision of Pandora were a couple of utilities that attacked specific
portions of NDS via NCP calls. This was the genesis for the current Pandora work,
which has evolved into a full security attack tool capable of not just password
recovery, but full system compromise of a modern NetWare environment. While
examining the works of individuals mentioned in the last section, and studying
interactions during tool development, and number of new flaws were discovered
and were made public for the first time in Pandora version 3.


3. Invalid NCP Requests
-----------------------

During initial testing and tool development for version 3 of Pandora, it was
discovered that invalid NCP packets (with flawed headers) would be logged as
erroneous but valid NCP packets (with good headers) carrying invalid data
would not. This is a clear case of conceptually flawed security triggers, and
thus create Denial of Service (DoS) problems for NetWare 4.x servers. Three
DoS utilities were developed -- YANG.EXE, BURN.EXE, and KILL.EXE [7]. 
Netware 5 is still vulnerable to YANG and BURN, the more serious KILL that
would crash the server has a patch since Nw4SP3.

YANG sends broadcast messages on the network with invalid content causing all
clients to show endless crappy messages. With BURN, you can send structurally
invalid packets that will be logged by the server even if you are not connected,
and depending on the server settings the error-logging file may grow until all 
available disk space is used. Novell released a patch to combat problems with
invalid NCP packets, and without this patch KILL will allow you to overflow
the NCP socket with invalid packets, crashing the server.

The latest patches and service packs from Novell should correct these problems
for NetWare 4.x, and setting the packet signature level to 3 at the server also
helps in rendering these DoS attacks from harming the server.


4. "Not-logged-in" NCP requests
-------------------------------

The more information an attacker can get on the system (servers, usernames...)
the better off s/he'll be. By default, NetWare can be very "talkative" -- 
[Public] has read access to the [ROOT] of NDS, this means that a "Not-logged-in"
user may retrieve a bucket-load of information from it (using CX and NLIST). 
NMRC issued an advisory about the subject of default access [8]. We partially 
mimicked these attacks in Pandora 4 to retrieve connection information from the
default server, as this is a very promising track to follow for information
retrieval used in server compromise.


5. "Packet Signature" Attacks
-----------------------------

While testing these simple DoS utilities is was determined that packet signature
appeared to work differently depending on the Level setting, and it was quite
apparent that not all packets were signed even when signing was working. The 
64-bit signature was experimented with and we learned that if we simply create
a "wild card pad" consisting of 0xffffffffffffffff, this would be accepted by the
file server as a valid signed packet, when in the default signing mode (level 1).

In the default signature level 1 if you spoof a packet with a legitimate MAC/IPX 
owner but packets are sent without any pad, the server will respond with "station
xxxxxxxxx attempted an unencrypted password call" and terminate the connection.
Obviously if you forge the packet with another user's MAC/IPX address that 
legitimate user will be disconnected. If you add our wild-pad (0xffffffffffffffff)
to the packets and use a "sensitive" service call, namely NCP function 0x83
(which is used to perform remote console operations), the server will terminate 
all connections with the MAC/IPX owner. Proof of concept code is included since
Pandora v3 (see the source code file havoc.c [5]). One interesting sidenote,
the MAC and IPX values don't have to be aligned, so you can send the packet as
a broadcast packet. This ensures the server will pick up the packet and is
needed if you are trying to get the server to listen and you don't know the
server's MAC address.

Several older attacks, such as those developed by Greg Miller (see [2] and [4])
can be adapted over by just adding our wild-pad. This means that some of the
same old exploits for NetWare 3.11 can be re-introduced as valid attacks
against servers using packet signature.

Also, with the signature level set at Level 1 you can perform IPX session
hijacking. As those in the Unix world know, if you can predict the sequence
number of the next TCP packet you can "hijack" and in some cases take over
a user's session. Unfortunately Novell has implemented a very simple scheme
for tracking sequence numbers : new_sequence_number=previous_sequence_number+1,
if old sequence number=255, new sequence=0. Here are the rough steps as to
how hijacking this would work:

- Sniff the network for the NCP calls of the victim you wish to hijack.
- The last request will have the current sequence number.
- Send the server 5 packets with valid requests, the victim's address, and
  the magic wild-pad to terminate the packet. 5 packets need to be sent
  because the victim and server can "re-synch" if the sequence number
  difference is no more than 3 packets out of sequence. To ensure a hijacking
  you MUST get the victim and server de-synched.
- Now only you (the attacker) know EXACTLY what sequence number the server
  expects next (+6) while the victim's client times-out.

Here is a detailed chart to show the events outlined:


				 Packet Exchange
  ------------------------------------------------------------------------
  Victim                                      
   |MAC/IPX/Socket of victim                    
   |MAC/IPX/Socket of dest : server ------> Server           
   |Connection, Sequence=<i>          |      |MAC/IPX/Socket of server
   |Data : request                 <------   |MAC/IPX/Socket of dest : victim   
   |Pad = 0x???????????????? (ID??)   |      |Connection, Sequence=<i>
				      |      |Data : reply
				      |      |Pad = 0x????????????????
				      |
			  (a) Exchange Sniffed
				      |
   ___________________________________|
  |
  Attacker
   |MAC/IPX/Socket of victim          (b)
   |MAC/IPX/Socket of dest : server ------> Server
   |Connection, Sequence=<i+1>..<+5>         | the server send his reply to
   |Data : request (just any kind)           | the victim, who happily 
   |Pad = 0xffffffffffffffff                 | discards it since it didn't
					     | ask for nothing (instead of
					     | warning the server...)

  Victim                                      
   |MAC/IPX/Socket of victim          (c)          
   |MAC/IPX/Socket of dest : server ------> Server           
   |Connection, Sequence=<i+1>               | the server discards the 
   |Data : request                           | request since it's expecting  
   |Pad = 0x???????????????? (ID??)          | sequence to be <i+2>. The 
					     | victim gets into an endless 
					     | loop waiting. 

  (a) The attacker sniff the network for the packet exchange which gives him
       all relevant information. The attacker waits for the victim to be in an
       idle state before performing the Hi-Jack.
  (b) The attacker spoofs 5 consecutive request in the name of the victim.
       The attacker can now send any number of requests in the name of the
       victim, thus benefiting from the victims rights.
  (c) The victim's requests are never performed. The victim loops endlessly.


At first glance it seems coding up an exploit to actually "take over" the 
current session would be difficult, since it would involve a massive rewrite 
of the ODI driver as a large number of conditional "errors" from taking over 
the session would have to be dealt with (open files, drive mappings, additional
server connections, etc.). But once again, as those in the Unix world are aware
of, it only takes a few carefully planned packets to open up additional access.
So let's continue our hijacking session from above:

- Send the necessary requests to make another user equivalent to the victim.
- Send the server the remaining packets necessary to "re-synch" the sequence
  numbers to what the victim would be sending.

Hardly a new idea for Unix, or NetWare. Check out Greg Miller's nocrypt.c
code (see [2] and [4]) as this is based upon the same principle. Of course you
can foil all or part of the attack by setting your server's signature level to
the highest level. This disallows the wild-pad from working, yet the attacker
is not out of luck...


6. On Becoming Admin
--------------------

The goal of any attacker would be to become security equivalent to the Admin
account, as this account has full access to the entire NDS tree and can do
virtually anything from a system and administrative standpoint.

Eugene Ilchenko and Igor Gusev [3] documented an attack technique, that make
use of IPX fragmented requests/replies (NCP function 0x68), which only worked
with Level=1. Included with Pandora3 is Level1-1.c [6], designed for servers at
Level=1 and clients at Level=1. Level1-1.c is based off of the Russian
hackers' work, but uses some additional tricks. It is based on an NDS call
that requires the ObjectID of the victim to gain rights from, and makes use of
the "re-synch" trick by allowing the server talk to the victim during the
attack. What happens is that after issuing the spoofed request, the server
asks for "connection confirmation" from the victim, who happily responds. If
you spoof no more than two packets, the victim is able to catch up the
sequence gap without questioning the server.

A little scheme to clarify it all :

				 Packet Exchange
  ------------------------------------------------------------------------
  Victim                                      
   |MAC/IPX/Socket of victim                    
   |MAC/IPX/Socket of dest : server ------> Server           
   |Connection, Sequence=<i>          |      |MAC/IPX/Socket of server
   |Data : request                 <------   |MAC/IPX/Socket of dest : victim   
   |Signature = 0x????????????????    |      |Connection, Sequence=<i>
				      |      |Data : reply
				      |      |Signature = 0x????????????????
				      |
			      Exchange Sniffed
				      |
   ___________________________________|
  |
  Attacker
   |MAC/IPX/Socket of victim          
   |MAC/IPX/Socket of dest : server  
   |Connection, Sequence=<i+1>,<i+2> ------> Server
   |Fragmented request : give NDS            |MAC/IPX/Socket of server
   |rights, no pad, no signature             |MAC/IPX/Socket of dest : victim
					     |Connection, Sequence=<i+2>
  Victim                           <-------  |Data : request : confirm conn. 
   |MAC/IPX/Socket of victim                 |Signature = 0x????????????????   
   |MAC/IPX/Socket of dest : server  
   |Connection, Sequence=<i+3>
   |Data : reply : confirmed
   |Signarure = 0x????????????????


We then tried setting Signature Level to 3 at the server to prevent this; and
we uncovered that even with Signature Level=3, since the default setting on the 
client side is Signature Level=1, IPX fragmented requests from the client are 
still NOT signed. For detail on foiling this attack, see the "Defensive 
Administration" section below.

By sniffing the packet exchange from NwAdmin when "Equivalent to" rights are
given, we realized that this was done by a set of two fragmented requests/replies,
totaling 4 packets. The next step with Level3-1.c [6] (for level 3 signature
at the server), is to mimic this exchange with the spoofed address of the Admin
to make any user equivalent to Admin.

Let's look at the exchange that gives GUEST the rights of Admin, with GUEST's
context is .nov.hack, and Admin's context is .nov.sec:

   IPX Spoofed Fragmented request/reply 1
   --------------------------------------
    Admin (forged)
    --------------
    Resolve name of GUEST.nov.hack  --->    Server
					    ------
					    Completion successful
					    Temporary Handle for object
					    GUEST in this example: 010400c0
    Admin (forged)                  <---    
    --------------
    set 010400c0 (returned Handle)
    "Equivalent to me"
    Admin.nov.sec                   --->    Server
					    ------
					    Completion successful

At this point GUEST has the rights of Admin BUT another exchange must happen to
update Admin's "Equivalent table" and add GUEST to it. This second exchange is
required, because if "set check equivalent to me" is "=ON" at the server, GUEST
will be refused access.

   IPX Spoofed Fragmented request/reply 2
   --------------------------------------
    Admin (forged)
    --------------
    Resolve name of Admin.nov.sec   --->    Server
					    ------
					    Completion successful
					    Temporary Handle for object
					    GUEST in this example: 010400c0
    Admin (forged)                  <---    
    --------------
    set 010400c0 (returned Handle)
    "Security Equals"
    GUEST.nov.hack                  --->    Server
					    ------
					    Completion successful

Okay, obviously to do things properly, we should spoof the Admin address and
sniff the server answer to feed our packets with the right Handle. One more
thing here -- If we don't listen to the returned value by the server (or can't)
and try to guess the Handle value  (010400c0 ?, 9c070001 ? ...), we must wait
an idle time between two packets we sent for the server response, otherwise
our requests would simply be discarded; experience shows that an idle time of 
approximately 1 second will suffice. In Pandora4 the new algorithm takes care
of all the details for spoofing Admin and sniffing Server answers.

The revised attack summarized:

   Attacker
   --------

   (1) Spoof Admin address
   request : Resolve name of Admin.nov.sec

   (2) Sniff server response : handle

   (3) Spoof Admin address
   request : <handle> Equivalent to me GUEST.nov.hack

   (4) Sniff acknolegment from server

   (5) Spoof Admin address
   request : Resolve name of GUEST.nov.hack

   (6) Sniff server response : handle

   (7) Spoof Admin address
   request : <handle> Security Equals Admin.nov.sec


7. Snarfing the Details
-----------------------

One note on this spoofing, and probably the most important: when a user logs
into a NetWare server they are assigned an IPX address, a listening socket 
and a connection number:

   <connection number>
   -------------------
   from 1 to max number of licenses on server

   <4 bytes net>:<8 bytes MAC address>:<2 bytes Socket>
   ------------- -------------------- ----------------
   Internal net   NIC MAC of station    xxxx
    if server
   IPX Frame net  00000001 if server    4007 (usually)
    if station
   |                                 ||               |
    ---------------------------------  ---------------
	    IPX address                   Socket

These values are displayed under the user name with tools like Onsite [9] and 
are accessible to anyone [10]. However, when a user sends IPX fragmented 
requests, and server Signature Level =3, he opens a new 
<socket>/<connection number> that doesn't show at the server or with Onsite, 
yet this is the info we need to feed into our exploit for it to work, so here 
is how to proceed:

   -- Sniff Admin packets until they send a fragmented request : byte[50] of
   packet=0x68, byte[51] of packet=0x02 -- Then grab the following from his
   latest packet (for sequence number) to feed the exploit:

   byte[0]->byte[5] :   Server MAC
   byte[20]->byte[23] : Server internal net
   byte[24]->byte[29] : Server address (probably 0x000000000001)
   byte[32]->byte[35] : Admin net
   byte[36]->byte[41] : Admin address
   byte[42] : Admin Socket high (probably 0x40)
   byte[43] : Admin Socket low  (probably 0x11)
   byte[46] : This packet sequence number => sequence+1 for next expected
   byte[47] : Admin connection number
   byte[48] : Admin task number (doesn't matter from our perspective :-))

   Again this is taken care off automagically in Pandora4.


8. Anarchy and more Havoc
-------------------------

You are a serious system administrator and serious about security. You've set 
packet signature to level 3 on the server, AND you've set packet signature to 
level 3 on the client side. Finally your users are protected from spoofing,
except....

Yes there is an exception that bypasses packet signature entirely. There is 
one special user called "the file server", which is an internal connection to 
the NetWare server, and yet is bound to an IPX/Socket number. The bad news is 
that this user holds all sorts of funky privileges and only uses level 1 
signature, no matter what. Retrieval of the IPX/Socket number for this 
connection can be retrieved once again via Novell's Onsite tool [9]. Now that 
we have the IPX/Socket/Connection number of the file server (it's the 
connection labeled "*<server_name>.<server_context>") we can spoof a bindery 
request telling the server to give user "GUEST" the rights of "Admin". This
works because GUEST and Admin are in the same "container" (remember, we are
doing a bindery request so this is how they appear to our "file server" user),
and, well, "GUEST" now owns your server... 

After the first publication of this document, Novell revealed how to foil
this attack, see the "Defensive Administration" section below.

The reason this works is because the "file server" connection has full 
read/write access to the NetWare volume and that is all that is required to 
process any kind of bindery call. Once again, exploit code is included with
Pandora, in GameOver.c [6].

Wait, we're not finished :-) How about a vicious Denial of Service? If you 
feed the _file server's_ IPX/Socket/Connection into the "havoc" program 
described in section 4, very interesting things will happen:

- The server will echo on the whole network that the server itself tried to do
  something illegal.
- All workstations will run slow (forget about loading or saving a file)
- All connections will eventually time-out, dropping all connections.

If you send the connection number as 0 (zero) and send our "file server" info
via the "havoc" program:

- The server will lock up.
- All connections drop
- The CPU utilization will redline at 100%.
- Nothing on the console indicates the source of the problem.
- During tests we could not get the server into the debugger even half the
  time, so a power cycle is typically needed to recover the server.

The chart below summarize the type of attack than can be performed in regard
to the Signature Level.

 --------- -----------------------------------------------------------------
| \Server |    Signature Level   |                     |                    |
|   \     |           1          |          2          |           3        |
|Client\  |       (default)      |                     |                    |
|________\ ______________________|_____________________|____________________|
|         |                      |                     |                    |
|Signature|  IPX hijacking       |  level3-1 attack    |  level3-1 attack   |
| Level   |  Wild pad attack     | (*) GameOver attack | (*) GameOver attack|
|   1     |  level3-1 attack     |                     |                    |
|(default)|  GameOver attack     |                     |                    |
|         |  Havoc & other DoS   |                     |                    |
|---------|----------------------|---------------------|--------------------|
|         |                      |                     |                    |
|   2     |  GameOver attack     |  GameOver attack    | (*) GameOver attack|
|         |  Havoc & other DoS   |  Havoc & other DoS  |  Havoc & other DoS |
|---------|----------------------|---------------------|--------------------|
|         |                      |                     |                    |
|   3     |  GameOver attack     |  GameOver attack    | (*) GameOver attack|
|         |  Havoc & other DoS   |  Havoc & other Dos  | Havoc & other DoS  |
|         |                      |                     |                    |
 ---------------------------------------------------------------------------

(*) Since Pandora 3 release, we are now aware that the GameOver attacked can
be foiled if the following conditions are met : (1) you have at least Nw4SP5
(2) you set the packet signature to 3 at the server (3) you load ds.nlm first
thing in Autoexec.ncf so the NDS engine gets loaded up BEFORE the NCP engine.


9. Who needs a password when the hash will suffice
--------------------------------------------------

Finally, let's pinpoint a last clear case of erroneous conception: NetWare
authentication scheme. Supposedly, a user password is stored encrypted (or
"hashed") on the server so in case someone managed to get that hash there
isn't much that can be done with it (albeit brute force and dictionary attack).
However, all authentication processes to NetWare servers are not based on
the real password but its hash (which is processed on the client side every
time a user fills the login screen). The consequence is simple -- knowing the
hash is as good as knowing the real password! Therefore, you can login as
someone else and even change someone's password just knowing their password 
hash. For Bindery illustration of this little game see bindas.c [6] in the 
Pandora files, and yes you can do the same for NDS authentication : see the 
panmount [11] utility for linux, compiled and crafted by NMRC from the NCPFS 
project.


10. Defensive Administration
----------------------------

Things are not as grim as they might appear. There are a number of steps you
can try that will make things a little bit more difficult for these attacks to
succeed. Some of these items were already mentioned, but here is the list of
items we can recommend to implement NOW, and what items we consider to be
false solutions that introduce more problems than they fix.

First off, all production systems you depend on should have the latest and
greatest patches and service packs loaded. Often Novell squeezes in fixes for
problems you didn't even know you had, and like most major commercial network
operating system vendors they will NOT tell you about potential problems you
should patch for if these problems are not publicly known, especially when it
comes to security issues. So at least get current on your patches.

This most important SET command should be set as follows:

   set ncp packet signature option = 3
   // this will force all NCP packet to be signed, the only problem you might
      encounter is with old DOS or Windows clients that don't support this
      option, but then you should REALLY upgrade your network. Since all NCP
      packets are signed with an MD4-hash, the wild-pad 0xffffffffffffffff is
      rendered useless. If you run ArcServe on that server, make sure to patch
      it too. 
      
      TO PREVENT GameOver attack make shure you have this packet signature 
      setting, the latest patches, AND load DS.NLM before you bind your 
      network cards.

      If for some reason you just can't set signature to 3 at the server, at
      least make sure NO user objects lives in the same container as the
      server object.

Also to prevent your server's SYS volume from filling up (rendering your 
server useless), you should limit the error logs:

   load servman
   -> server parameters
   -> error handling
   // Here make sure that the sum of the overflow size is reasonable compared
      to the actual free space of your disk. Also the 'file state' for the 
      error log file should be set to 1 (default): delete the file when file 
      size reach overflow.

You must use Novell's client software on Windows platforms to take advantage of
packet signature. In mixed shops (both Netware and NT file servers) where you
are not running NDS for NT, odds are there are lots of Microsoft Netware client
software installations, and this will certainly prevent quick fixes of Level 3
packet signature on the Netware servers.

Now, for the message "echoing" problem we're not quite sure if you can prevent 
Client32 to do it altogether, but at least there is an NCP request you could 
send to the server as an Admin: func 0x15h, subfunc 0x02h : DISABLE STATION 
BROADCASTS. Also try adding "send /A=N" to prevent broadcast in the login
script. This should do the trick.

As for the server broadcast when someone sends a broken request with function
0x83h, Novell fixed this in Nw5SP2.

Regarding the ability of the "Not-logged-in" connection to retrieve details of 
your NDS architecture, disable public read access from the root of your NDS 
tree.

Also, there are some options that should be avoided because they would 
certainly break a few things :

   the 'reject ncp packets with bad components' and 'reject ncp packets with
   bad lengths' SET options should both be '=OFF' (default), the reason being
   that those security triggers are too restrictive and would prevent some
   third party products from working (in fact Groupwise 5.2 was unable to work 
   during early tests -- there may be other examples).

The steps taken so far should suffice to prevent hijacking and most other 
similar spoofing items described here. However, they are some additional things
you might want to do:

   set allow unencrypted passwords = OFF
   // Okay, OFF is the default value, this thing should ALWAYS be OFF. If it
      is ON for legacy equipment, upgrade to modern equipment if you care
      about security.

   set enable ipx checksum = 2
   // This does not prevent security flaws, the IPX checksum algorithm is
      publicly known and doesn't use a cipher of any kind, but by forcing all
      IPX packets to hold a checksum (instead of no checksum value 0xffff) it
      leverages the difficulty of spoofing. All NetWare-enabled clients/devices
      should support IPX checksums. Actually we're rather against these kind
      of "smoke-screen" solutions, but you work with what you are given with a
      closed proprietary operating system.

To "strengthen" Level 3 signature, there are quite a few things that can be
done:

   First and foremost, assuming your clients are under Windows 95 and/or NT,
   use NWSETUP to set some parameters in the Advanced section :

   Packet checksum level = Require checksum or don't communicate
   // This will force IPX fragmented requests/replies to be signed, thus
      preventing level3-1.c type of attacks.
   Auto-reconnect level = No auto-reconnect
   // The default value for this one is "Devices, files, locks", setting it 
      to not reconnect might be a nag if your Server is unreliable, but be 
      aware that strange things can happen with this feature enabled...

Of course this does not prevent a user from changing these on their own
unless you are using some type of add-on security product that locks down the
workstation better than the given 95/NT built-in solutions. Just advise your
users that this is required to enhance security and cut off their Internet
access if they are dropping their own defenses ;-).

On the server side you might want to set the following:

   set check equivalent to me = ON
   // This undocumented option will enforce verification of a "equivalent to
      me" request against a "security equals" : if user A is security
      equivalent to user B, server double checks for B security equals A.
      This double-check thing is useful in a couple of scenarios, and
      specifically defeats level1-1.c attack. However it doesn't prevent the
      'file-server connection' exploit or level3-1.c attack.

   set nds client ncp retries = 1
   // Default value for this is 3. Setting it to 1 helps to prevent attacks
      where the real client replies blindly to a server request after an
      attacker spoof, but leverage the risk of DoS attacks. The bottom line
      is Novell Client/Server trust architecture needs a serious lifting.

As for the "havoc" DoS attack, until a patch is posted, if you are really 
concerned by this, there might be a solution: "firewall" or "packet filter"
your server. This may not be practical especially in large companies with a
lot of NetWare servers, but you can at least try to do this. Here are several
options to consider (none have been tested):

- Install BorderManager on your server and filter out all incoming NCP/NDS
  requests that have the MAC/IPX origin of the server itself.
- Some routers (such as Bay, Cisco, etc.) are "NCP/IPX aware", and it might be
  possible to filter out some evil packets this way.
- Inexpensive packet filtering software, like KarlBridge, may support
  conditional packet filtering to assist in spoof prevention.

It seems that Netware 5 SP2 behaves somewhat better when the server itself is
under a Havoc attack.

For those of you with the will and the way (a.k.a. money and time), you should
consider variations on the following network layout:

 *---------------*      *-----------------*      *----------*
 |               |      |                 |      |          |
 | Administrator |------| NetWare Server  |------| Userland |
 | Workstations  |      | Network Segment |      |          |
 |               |      |                 |      |          |
 *---------------*      *-----------------*      *----------*

The point here is to NOT allow the "unwashed masses" between your administrator
workstations and servers. This limits chances for sniffing to a degree.

Switched Ethernet also should be considered as this defeats a lot of sniffing
based attacks, including Pandora's.

Regarding our final point about Novell authentication scheme, if someone
manages to grab your NDS database, consider your security terminated. The
"Bindas" trick provided will not work if signature level is higher than 1
simply because the hash is not "registered" to the ODI interface which
calculates the packet signature. HOWEVER the "panmount" trick makes use of
packet signature (thanks to the ncpfs project), therefore if someone knows a
user hash, that person can login, sign and authenticate for that user.
Remember, HASH == PASSWORD. Novell introduced RSA encryption into the NDS 
authentication scheme, but this was just an additional layer to the 
pre-existing login scheme which was not changed.


11. Final Comments
-----------------

Note that Novell has added an undocumented setting to the NetWare 4 file 
server to attempt to secure the "SECURITY EQUAL" call, however our testing
proves that this "secure latch" doesn't prevent anything for the two latest 
attacks described (it will echo garbage on the server console from time to time).
The SET command is "SET CHECK EQUIVALENT TO ME=ON". It should be noted there are
dozens of NCP calls besides the "SECURITY EQUAL", we simply focused on it as it
seemed more of an elegant hack to poke a quick but devastating blow into NetWare
and NDS. The sky is the limit as additional NCP calls to do other administrative
functions could be used in concert to gain higher privileges to the server.

Overall, this means that NetWare 4.x (and Netware 5) NCP engine was recycled 
from Netware 3.x, therefore NDS security scheme inherited the "bindery flaws" 
of NetWare 3.x, nonstanding its own... Yes, Netware 4 (hence 5) were not built
as a clean new operating system. Granted, this is to be expected for a number 
of reasons, namely backward compatibility. This is quite evident when looking 
at the NDS database as it appears to be a kind of "collection" of bindery files.
Novell denies this completely, but if you have the same programmers looking at
the same two projects -- bindery files and NDS files -- you end up with some of
the same programmatic and conceptual flaws in both projects. In other words, if
other security flaws existed (see [1] and [2]) in NetWare 3.x but were never 
disclosed, chances are NetWare 4.x and further versions hold the same flaws 
which could rear their heads under certain conditions. Besides the examples in
this paper, version 2 of Pandora included SUPE.EXE, which worked on a flawed 
user that existed in NDS named Supervisor. Information on this "hidden" user 
has been included in Pandora since version 2 [6].

Also you've noticed that Client32 (Novell's client package) is very cooperative 
with the attacker, since it doesn't question at any time the server's requests
or why his own requests are not processed; this further indicates that the
Novell Client/Server model is based on some kind of blind and dull belief at
least on the client side, something the Unix world has long discarded.

Additional note regarding Netware 5 (sure to please Novell for once ;-) ),
despite all criticism two things are quite obvious : When comparing the 
overall NetWare and Microsoft OS's security and robustness, Netware wins.
Secondly, Novell NDS is certainly one of the better implemented X.500 
Directory Service today.
			 
			 
			 
			 Jitsu-Disk  //  Simple Nomad


References
----------

[1] HACK.EXE and NW-HACK.EXE by Itsme [itsme@xs4all.nl]. Written in 1992, it
is available at http://www.nmrc.org/files/netware/.

[2] Greg Miller [greg.miller@usa.net] has a number of NetWare exploits 
available from his home page at http://members.iglou.com/gmiller/, as well as 
several that have been included in the Unofficial NetWare Hack FAQ (see [4]).

[3] "Hacking Novell NetWare 4.1" by Eugene Ilchenko and Igor Gusev. Written in
1997, it includes technical details regarding NCP and IPX, and suggests hacking
techniques against a typical NetWare 4.1 server. The paper is available online
at http://www.tsu.ru/~eugene/netware/archive/nw41hack.html.

[4] "The Unofficial NetWare Hack FAQ", version 6 by Simple Nomad is available
online at http://www.nmrc.org/faqs/netware/index.html. The latest version of
this FAQ was released on May 1, 1997. Further revisions of this FAQ will be
released as a part of a general Hack FAQ currently being compiled by Simple
Nomad that will contain information on common network operating systems,
including Novell NetWare.

[5] Microsoft's client software for Netware server connectivity does not
support packet signature. For details search www.microsoft.com with the words
"packet signature" which will refer you to a number of documents.

[6] The Pandora Home Page is at http://www.nmrc.org/pandora/index.html.

[7] YANG and BURN are available at http://www.nmrc.org/files/netware, and the
source code for KILL can be found in the NW-Hack mailing list archive at
http://www.nmrc.org/compute/index.html.

[8] "Default NDS Rights", NMRC Advisory issued on September 16, 1998. See 
http://www.nmrc.org/news/nds1.txt for the full advisory.

[9] Onsite is a freeware tool available from Novell. It can be downloaded via
the Internet from Novell's web site at http://www.novell.com/, or alternatively
at the SimTel.net archive site.

[10] After this document was first released, Novell posted a patch that simply
broke Onsite. Then under customers pressure, they re-released a modified 
version of Onsite that requires the user to be logged in to retrieve 
connection information. However, thanks to the attacks described in section
4 above, the attacker is still able to retrieve usefull information even when 
not logged in.

[11] The "GNU Novell Client" project gives a unique insight on the NCP protocol, 
it can be downloaded at http://sunsite.unc.edu/pub/Linux/system/remotefs/ncpfs.
The panmount utility based on NCPFS can be found on nmrc web site, under the
Novell insecurity files section.


