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= | |MAC/IPX/Socket of server |Data : request <------ |MAC/IPX/Socket of dest : victim |Pad = 0x???????????????? (ID??) | |Connection, Sequence= | |Data : reply | |Pad = 0x???????????????? | (a) Exchange Sniffed | ___________________________________| | Attacker |MAC/IPX/Socket of victim (b) |MAC/IPX/Socket of dest : server ------> Server |Connection, Sequence=..<+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= | the server discards the |Data : request | request since it's expecting |Pad = 0x???????????????? (ID??) | sequence to be . 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= | |MAC/IPX/Socket of server |Data : request <------ |MAC/IPX/Socket of dest : victim |Signature = 0x???????????????? | |Connection, Sequence= | |Data : reply | |Signature = 0x???????????????? | Exchange Sniffed | ___________________________________| | Attacker |MAC/IPX/Socket of victim |MAC/IPX/Socket of dest : server |Connection, Sequence=, ------> Server |Fragmented request : give NDS |MAC/IPX/Socket of server |rights, no pad, no signature |MAC/IPX/Socket of dest : victim |Connection, Sequence= Victim <------- |Data : request : confirm conn. |MAC/IPX/Socket of victim |Signature = 0x???????????????? |MAC/IPX/Socket of dest : server |Connection, Sequence= |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 : 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 : 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: ------------------- 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 / 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 "*.") 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.