Date: Thu, 15 Jul 1999 12:38:28 -0500
From: Simple Nomad <[email protected]>
To: [email protected]Subject: NMRC Advisory: Netware 5 Client Hijacking
_______________________________________________________________________________
Nomad Mobile Research Centre
A D V I S O R Y
www.nmrc.org
Jitsu-Disk [[email protected]]
Simple Nomad [[email protected]]
15Jul1999
_______________________________________________________________________________
Platform : Novell Netware
Application : NDS/NCP
Severity : High
Synopsis
--------
Armed with the MAC address of the Administrator, an intruder can hijack an
Admin's session and issue NCP calls as the the Admin on Netware servers.
Tested configuration
--------------------
The bug was tested with the following configuration :
Novell Netware 5, Service Pack 2 (with IPX configured)
Latest Client Software for Windows 95/98
Also confirmed on Netware 4.x.
Bug(s) report
-------------
This is an old bug. We reported it to Novell over a year ago, and even released
exploit code (see http://www.nmrc.org/pandora/). Since several people had
problems using the exploit code and Novell still hasn't corrected (to our
satisfaction) all of the problems with Netware 5, we've updated the exploit
code in the new Pandora v4, which is now in beta release. While Netware/IP is
the recommended path for Netware 5, most organizations using Netware are still
using Novell's proprietary IPX protocol for server access. IPX is required for
this exploit to work.
In essence, IPX fragmented requests/replies (NCP call 0x68) are not signed if
the packet signature level is not set to 3. Setting it to 3 on the server side
is good, but if the client is set at 1, it is possible to spoof or hijack a
portion of the client's session. If the target client is the Admin, we can tell
the server to make us security equivalent to the Admin. Please refer to the
details at http://www.nmrc.org/pandora/ncp.txt, especially sections 6 and
7, which detail how the attack works.
The new Pandora Online utility will simply require you insert the MAC address
of the Admin's workstation into a dialog box, and Pandora will handle the rest
of the sniffing required to make the attack work. As always, placement of your
attack box is critical:
---------- ---------- ---------- -------------
| Admin | | Attack | | Router | | Netware 5 |
| Client | | Box | | | | Server |
---------- ---------- ---------- -------------
| | | | |
--------------------------- -------------
So here are the steps:
0. Admin client is Packet Signature Level 1, and server is Packet Signature
Level 3.
1. Attack box gets Admin's MAC address, and inserts it into the Pandora
Online tool. Attacker has the option to adjust other parameters as needed, but
the main one is the MAC address.
2. Admin performs actions dealing with NDS that use fragmented packets (normal
administrator activity will give us the needed packets quickly).
3. Attack box sends forged request to server, making us security equivalent to
Admin.
4. Netware 5 server accepts forged packets.
5. Admin client loses connection from server as its packet sequence is now out
of whack.
6. Attacker adjusts security settings for self so that the attacker has full
access to entire tree, and removes "equal to Admin", so s/he will not show up
on a basic "who's equiv to me" investigation by Admin.
Caveats:
0. This attack will fail in a switched environment since sniffing is involved.
1. This is a race. If the Admin client beats the attacker, the attacker must try
again.
2. Obviously the attacker being on the same Ethernet segment as the Admin will
help considerably in an attack. In theory this should work if you are anywhere
in between the Admin client and the server, although you will need to use the
MAC address of the router interface the Admin's session is coming from. At best,
this may not work at all, but is still theoretically possible.
3. In theory this could be adapted to a Netware/IP environment, as Novell's
TCP/IP stack is vulnerable to sequence number prediction. We have not explored
adapting Pandora exploit code over to a pure IP environment, but will explore
this possibility in future Pandora releases.
Solution/Workaround
-------------------
Use Packet Signature Level 3 everywhere, and make sure clients cannot touch
their own signature settings. LAN Admins should never access a server unless
using Level 3, and the security on the workstation should be restrictive enough
to prevent unauthorized adjustments (i.e. use a locked-down NT client with no
server services running, behind a locked door, although this simply places your
trust in Microsoft). Use switched Ethernet.
Alternately, you can ask Novell to patch things. We did our part a year ago.
Comments
--------
Simple Nomad had to leave Las Vegas right after Black Hat due to a minor
medical emergency at home, and missed DefCon. This advisory was one of the
things slated to be discussed during the DefCon presentation.
As stated, Novell was contacted regarding this bug in June of 1998, 13 months
ago. We got this to work in a lab setting. YMMV.
The new Pandora v4 includes all of the Pandora v3 attacks against Netware 4
updated to work against Netware 5. It was developed with 100% freeware libraries
and compilers. We are proud that this code doesn't look like a normal 95/98/NT,
the GUI was developed on Linux. Pandora v4 is 100% freeware. Source code is
freely available.
We always recommend using the latest versions of Netware with the latest
patches, and using the maximum security settings at all times on Netware
servers.
_______________________________________________________________________________
