Novell NetWare & Ethernet address spoofing with ODI

Ethernet level spoofing
Published: Oct 16, 2002 Updated: Oct 16, 2002 Section: Network Security Library :: NetWare Author: Company: WindowSecurity.com Printable Version Adjust font size: Rating: 3.3/5 - 12 Votes 1 2 3 4 5

------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------