------------------------------------------------------------------------------

Novell NetWare & Ethernet address spoofing with ODI
---------------------------------------------------

Just to save you from the boredom of Yet Another UNIX  Security Weakness, here
are some things to consider about Novell NetWare for your next Security Audit
or Hacking session (depending on which side you are on).

Novell claim to have  over 20 million PCs using their network operating system,
substantially more than the estimated 4 million TCP/IP systems worldwide.
There are many reasons for its popularity and its 60 to 80% market share, one
of which has been its relatively good security.

NetWare has been one of the few widely available systems which offer some form
of login encryption of accounts and passwords over the wire, as standard,
unlike most of its rivals which send them out as plaintext, even if they are
stored in an encrypted form eventually. Novell now offer RSA based public key
encryption of the data as well.

However, since it is so popular, there are likely to be plenty of systems out
there which have not been upgraded to the latest versions and patch releases
and which may be still be vulnerable to programs like KNOCK , the patched
ATTACH command (published in HackTic 16/17 1992), or the University of Leiden's
HACK (which has been published in issue 43 of PHRACK)

Since the latest security features are implemented as NetWare Loadable Modules
for NetWare 3x and 4x, but as Value Added Processes for NetWare 2x,  which
require the server to be brought down to install them, it is likely that there
are many NetWare 2x systems which are still vulnerable

I shall also assume that you are not on one of those wide open "box shift"
installations where none of the  security features have been switched on (try
logging in as SUPERVISOR or GUEST  without a password), all the programs and
data are in a single SYS: volume and the Network Address of the cable is the
default 00000001.

Like any project, the more you know about your particular Novell LAN, the
easier it gets to "explore". Login as GUEST or a normal account.

Try to see who else is on the system e.g.

USERLIST /A >c:\ulist.txt

will give you a list of users currently logged in, with their Ethernet card
addresses saved to a text file . Your current connection will be marked with
an asterisk. If your system has 100 or more users, then any sane Supervisor
will have used some form of logic when allocating the user's login accounts,
probably based on personnel or id number, often including their initials.

SYSCON with privilege is what you are aiming to be able to use, but even
without any privileges, you can still use it to look at your own account,
change your password etc. You can also see a list of all the other registered
users.

This should help you sort the accounts into normal and privileged accounts
(obviously SUPERVISOR, but often there are SUPERVISOR equivalent accounts, or
Work Group Manager accounts which stand out from the list). You are quite
likely to see an account called something like TAPE_BACKUP  or DATA_LOGGER,
TRAINER, STUDENT1, STUDENT2  i.e. accounts which do not belong to individual
humans. These often require abnormal security privileges e.g. normal users may
have their connections broken by the WATCHDOG at say midnight, to ensure that
they are not modifying files during the nightly tape backup. At an academic or
industrial site, you are likely to find data logging PCs connected to
instrumentation or machinery which needs to be monitored or controlled 24
hours a day. These PCs are likely to have 24 hour accounts which are not time
restricted at weekends, for example.

Since it is usually more practical to do tape backups (DAT or helical scan)
from a separate, dedicated PC rather than from the fileserver itself (one tape
unit might also back up several fileservers), these PCs are likely to use an
account e.g. TAPE_BACKUP which is a SUPERVISOR equivalent. If you can get
physical access to this sort of PC, either datalogger, or tape backup unit,
you  have a good chance of finding the password on the local drive C:,
possibly in a file with Hidden and/or System attributes (have a look at the
AUTOEXEC.BAT and see what it calls)

The security aware Novell supervisors, will have set up any such accounts with
an extra level of security which restricts logins to only those Ethernet
addresses which have been specified. The really sensible ones will have made
sure that any such machines are sited in physically secure areas, as well.

Although this is a very good idea, from the security point of view, Novell
have now provided a mechanism which allows you to get around this:
the replacement for monolithic IPX/NETX called Open Datalink Interface (ODI)

Novell's ODI, and its slower Microsoft equivalent Network Driver Interface
Specification (NDIS), both work by putting a common layer of software between
the hardware of the Network Interface Card and the rest of the MSDOS
Redirector. This allows multiple protocol stacks and frame types to be bound
to the same physical card e.g.

IPX    TCP/IP    NETBeui   DECnet   Appletalk
----------------------------------------------
Link Support Layer
----------------------------------------------
Hardware Specific device driver e.g. NE2000

Thus, to start up NetWare on older systems, you had to generate a hardware
specific version of IPX.EXE for your Ethernet card,

IPX
NETX

Extra parameters were set in SHELL.CFG, now under ODI, things are a little
bit more complex:

LSL
NE2000
IPXODI
NETX

The same parameters as in SHELL.CFG such as preferred server or machine type
(if you have different versions of MSDOS for different types of PC) can be
specified in NET.CFG. With ODI, there are more parameters for NET.CFG but the
worrying/interesting one is the ability to specify a different MAC level
address to that of your actual Ethernet card. It needs this ability
to cope with  TCP/IP or DECnet coexistence e.g.

BUFFERS 100
MACHINE TYPE COMPAQ
PREFERRED SERVER FINANCE
NODE ADDRESS AA-00-04-00-12-34

Since this DECnet address does not depend on the "real" unique Ethernet
address which has been burnt into the PROM on the card and is centrally
registered (originally by Xerox, but now by the IEEE), this mechanism allows
you to put a different Ethernet card address into NET.CFG, thereby fooling the
Address Restriction security.

e.g. NODE ADDRESS 02-60-80-12-34-56

This is where the data you gathered earlier with USERLIST and SYSCON becomes
threatening/useful.

Of course, if your target PC is on a different LAN segment, there may be Routers
or intelligent hubs which restrict your ability to do this, or at least record
attempts in a log files which can trace your activity, provided that suspicions
are aroused before they are periodically wiped out.

How much of  a security threat this little work around constitutes depends on
your specific site, but there is another danger/opportunity, namely that of a
denial of service or nuisance attack on the LAN.

If you set this connection parameter to be the same as that of another PC, the
fileserver (Novell, DEC or UNIX)  and the Ethernet has no way of preventing
some packets intended for just one unique address going to the other, if they
are both online at the same time. This usually results in PC hangs, incomplete
closure of files, File Allocation Table problems (usually curable by running
CHKDSK C: /F, but not within Windows or you will make things worse).

If by accident or design, you set your PC to have the same address as the
fileserver (Novell, DEC or UNIX) or a router, then you can cause havoc to the
whole network segment (even before you have started to play your multiplayer
DOOM Deathmatch !).

This could be achieved with a simple  command in the AUTOEXEC.BAT  e.g.

echo NODE ADDRESS fileserver Ethernet address >>C:\ODI\NET.CFG

which  will only take effect the next time the PC is re-booted (allowing a good
headstart for the perpetrator)

This could  also be the payload of a virus, which would cause more havoc than
simply trashing the hard disk of a single PC.

This problem is due to the inherent design weaknesses of TCP/IP and DECnet,
which were developed at a time when the number of mini-computers that they
connected could be counted on your fingers,. DEC or Xerox or Prime etc
sales teams  could only have dreamed of selling thousands of mini computers to a
single customer. Nowadays, thousands of PCs connected to central servers are
quite common, and the problems of duplicate addresses is significant.

These same features are what make Ethernet Packet Sniffing possible, which
is what was behind the recent CERT warning and media hype about Internet
password security, but that is a topic for another article.

Otaku

------------------------------------------------------------------------------