                           NCP: Novell Cries Pandora

                          Jitsu-Disk [jitsu@nmrc.org]
                        Simple Nomad [thegnome@nmrc.org]

                          Nomad Mobile Research Centre
                                 July 13,  1998
                                  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 weakness that are found in
the latest shipping versions of Netware, version 4.11 with the latest patches
applied, as well as version 5.0 beta 3, 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 the IPX protocol, their proprietary networking protocol.

Hackers soon realized that by exploiting flaws in both 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].

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.

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

Pandora [5] 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 have been
discovered and are being made public for the first time.

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 [6].

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. "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).

(Note: Exploits involving spoofing requires a packet driver on interrupt 0x60
with Novell 802.3 translation if your network uses ethernet 802.3 frames, e.g.
3c509.com -n 0x60)

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 with
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, whith 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 client32 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.


Coding up an exploit to actually "take over" the current session would be very
difficult but not impossible. It would probably 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...

5. 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 Pandora is Level1-1.c [5], 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.

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 [5] (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
                                            (or 9c070001 50% of the time)
    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
                                            (or 9c070001 50% of the time)
    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.

The revised attack summarized:

   Attacker
   --------

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

   (2) Idle 1 second

   (3) Spoof Admin address
   request : <handle> Equivalent to me GUEST.nov.hack
             (<handle>=010400c0 in Level3-1.c example)

   (4) Idle 1 second

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

   (6) Idle 1 second

   (7) Spoof Admin address
   request : <handle> Security Equals Admin.nov.sec
             (<handle>=010400c0 in Level3-1.c example)

6. 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>
   ------------- -------------------- ----------------
      xxxxxxxx    NIC MAC of station    4007 (usually)
   
   |                                 ||               |
    ---------------------------------  ---------------
            IPX address                   Socket

These values are displayed under the user name with tools like Onsite [7] and 
are accessible to anyone. 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 :-))

7. 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 [7]. 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... 

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 [5].

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 attach    |  GameOver attack   |
|   1     |  level1-1 attack     |  Havoc & other DoS  |  Havoc & other DoS |
|(defautl)|  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 |
|         |                      |                     |                    |
 ---------------------------------------------------------------------------

Finally, let's pinpoint a last clear case of erroneous conception : Netware
authentification 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 authentification 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 his password hash.
For Bindery illustration of this little game see bindas.c [5] in the Pandora
files, and yes you can do the same for NDS authentification : see ndsas.txt
and ndsas.dif [5], the "diff" file is meant to be applied to the Linux GNU
Novell Client : ncpfs-2.2.0.tgz [8].

8. 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 are 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 a MD4-hash, the wild-pad 0xffffffffffffffff is
      rendered useless.

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.

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. This should do the trick.

As for the server broadcast when someone sends a broken request with function
0x83h, Novell introduced this 'feature' for specific reasons, so our guess is 
that it's their call to deal with it. 

Also, they are a 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 was unable to work during
   our tests).

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 client/device
      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 nor 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.

To prevent the 'file server connection' exploit from happening, there is one
simple solution until Novell posts a patch: since the exploit relies on a 
bindery call, NO user should be in the same container as a server, period.

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.

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.

Regarding our final point about Novell authentification 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 "Ndsas" trick makes use of
packet signature (thanks to the ncpfs project), therefore if someone knows a
user hash, that person can login, sign and authentificate for that user :
HASH = PASSOWRD. 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.

9. Final Comments
-----------------

Note that Novell has recently added an undocumented setting to the Netware
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 from as near as we can tell from the
betas, Netware 5) NDS security scheme was build as an "additional layer" to the
existing "bindery and file system" model used in Netware 3.x, and not 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. 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 [5].

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.


                         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] The Pandora Home Page is at http://www.nmrc.org/pandora/index.html.

[6] 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.

[7] 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.

[8] 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/ncpfs-2.0.0.tgz

