Article 42193 of alt.security: May 2, 1997 *************************** *** Novell (In)security *** *************************** The Nomad Mobile Research Centre has been watching the events unfold surrounding highly-publicized security problems surrounding Microsoft's Windows NT product, and the computer industry's reaction to it. Most shocking has been a number of statements issued by Novell via press releases and web pages at their corporate web site. Some of the statements are puzzling because of their direct contradiction to the truth, or a mixture of half-truths with carefully worded statements to place the blame squarely upon the System Administrator. While some may argue that Microsoft deserves a proper racking across the coals for some of their security problems, Novell seems to offer little or no real solution to a number of security problems. I have included a few quotes from Novell's web site, and offer rebuttal to a lot of the ideas Novell has presented. *** "Known" Exploits and "Solutions" *** From http://www.novell.com/nds/hacks2.html - Novell: "Wiretapping attacks to obtain passwords: Resolved by protecting the network and requiring that workstation (trusted computer bases) TCBs prevent wiretapping by untrusted software." Translation to English: "To prevent someone from running a sniffer with the intention of using sniffed data to compromise a user account, make sure no one runs a sniffer. Not running a sniffer prevents sniffing attacks. Protect your network." NMRC Comments: "Without going to switched Ethernet or Token Ring, it is extremely difficult to prevent someone from putting a modern network interface card into promiscuous mode and sniff the network. Some network topologies make it harder, but there is no way to 100% prevent it on MOST networks. This is an issue faced by EVERY vendor of products that use the network -- not just Novell's issue. This problem is not 'resolved' -- not by Novell, and not 100% by any vendor. Even securing each individual workstation is no guarantee an intruder will not unplug the secure machine and plug in their own. There are no clues exactly how this 'protect your network' idea is implemented." Novell: "Inserting packets into the data stream for spoofing: Resolved by requiring that workstation TCBs prevent emmission of packets with falsified packets." Translation to English: "Don't let workstations send spoofed packets." NMRC Comments: "There is no indication as to how to prevent this other than just don't let it occur. Saying 'don't let it occur' does not fix the problem. Once again, this is an industry-wide issue -- not just Novell's issue." Novell: "Creating spoofing login programs to collect passwords: Resolved with specific access controls on TCB files, including the login program." Translation to English: "Don't allow someone to replace your LOGIN.EXE file. The LOGIN.EXE file is read only by default." NMRC Comments: "The only way to successfully implement this attack is to have administrator privileges or to take advantage of a zero knowledge attack. The zero knowledge attack is discussed later." Novell: "Genuine bugs in Netware: There was only one identified (it allowed access to Netware under certain limited circumstances). Resolved." Translation to English: "We had a bug and we fixed it." NMRC Comments: "Which bug? What fix? This could be either 1) the bug using convert.bas that shipped with IntranetWare and allowed Internet users to read any text file on an Internet connected Netware 4.1 server running IntranetWare that left the example scripting code in place, or 2) the bug with FTPSERV.NLM that allowed some FTP clients to have full read/write access to the SYS volume if NFS namespace wasn't loaded. The first one was fixed in 4.11, I have not heard if the second one has been fixed." *** NDS Authentication *** Regarding http://www.novell.com/nds/authent.html - Please read this web page. While it is informative, there are security flaws in this scheme. Basically, the login scheme works as follows - 1. Alice requests a login from the server. 2. The server generates a random value R, and retrieves X'=hash(UID, password), and also computes Y'=hash(X',R). R is sent to Alice. 3. Alice computes X=hash(UID,password) and Y=hash(X,R). Alice generates a random value R2, retrieves the servers public key and sends the pair (Y,R2) to the server encrypted with the server's public key. 4. The server decrypted the (Y,R2) pair. If Y=Y', the password Alice gave is correct. The server retrieves Alice's private key, computes Z=(Alice's private key XOR R2) and transmits Z to Alice. 5. Alice computes private_key=R2 XOR Z. This key is used to sign packets. The flaws for this include several scenarios. Scenario #1 ----------- 1. Bob sees Alice request a login. He requests a login as Alice as well. 2. The server generates Ra for Alice and Rb for Bob. 3. Bob resends Rb to Alice, with the packet spoofed to look like the server's address. 4. If Alice receives Bob's Rb before the server's Ra, Alice will compute Yb=hash(X,Rb) instead of Ya=hash(X,Ra). Alice will consider Ra a dupe packet and drop it. 5. When Alice sends Yb, Bob sniffs it and resends Yb with his address. 6. If Bob's packet arrives before Alice's packet, Bob is in as Alice without knowledge of her password. Alice's packet is dropped as a dupe. Not only does Bob have to be at exactly the right spot on the network, he has to hope the server will not require packet signature. So while a security problem, it is not a likely exploit. Scenario #2 ----------- 1. While sniffing Alice's logging in to the server, Bob obtains R and Y. Bob can get Alice's UID easily. 2. Bob performs an offline attack to get Alice's password by encrypting passwords using X'=hash(UID, guessed_password) followed by Y'=(X,R). If Y'=Y, the guesssed password was correct. 3. Bob can now log in as Alice AND sign packets. Scenario #3 ----------- This is a zero knowledge attack -- that is, it takes advantage of the fact that the user has not been authenticated and exploits it. 1. When Alice boots up her workstation, she is attached to the server and has read-only access to the SYS:LOGIN directory. 2. Bob waits until Alice requests LOGIN.EXE from the server. 3. Bob spoofs packets as coming from the server and sends his OWN LOGIN.EXE to Alice. 4. Bob spoofs acks from Alice to the server so the server thinks Alice is receiving the real LOGIN.EXE. 5. The trojan LOGIN.EXE allows Alice to log into the server. However the password is broadcast on the network and Bob sniffs it. 6. Bob now has Alice's password. This scenario is the easiest to exploit since SPX packets all start their ack counters at zero. Even if the packets get out of sync, Bob still gets Alice's password. *** Obtaining Passwords *** Regarding http://www.novell.com/nds/secure.html - The guist of this article is that Microsoft leaves a way for administrators to obtain passwords from Windows NT using a combination of maintenance and hacking tools. Novell claims that they are immune from such scenarios. To quote Novell, "The problems discovered with NT Server are NOT problems with any version of Netware, Intranetware or NDS on any other platform". THIS IS A COMPLETELY FALSE STATEMENT. There are two different maintenance routines, one for Netware 3.x and one for Netware 4.x, that dump enough material out that the encrypted passwords, or one way hashes, can be extracted. For Netware 3.x, the BINDFIX utility creates NET$*.OLD files located in SYS:SYSTEM. An administrator could use a tool found on the Internet that allows extraction of the password information and perform a dictionary crack to obtain passwords. This information has been widely known about for about a year on the Internet. But most disturbing, Netware 4.x has the DSMAINT utility that creates a copy of NDS in a file called BACKUP.DS located in SYS:SYSTEM. An administrator could examine this file using a hex editor or hex dump utility and extract not only the one way encrypted passwords, but the private RSA keys for each user. Exploit code to automate this extraction process and perform an attack to obtain passwords is currently being developed. While this information has not been discussed in public, the DSMAINT utility has existed for over a year. Knowing the login sequence as outlined in the NDS Authentication section of this statement, the value of X (remember -- X=hash(UID,password)) can be determined by simply extracting it from BACKUP.DS. This means that an exploit could be written that would allow an intruder to login into a server WITHOUT knowing the password, but by simply sending the extracted X value for the user. *** Non-Administrators Gaining Access *** By using the FTPSERV.NLM bug, it is possible to not only gain access to the Novell Netware 4.11 console, but to extract the BACKUP.DS file. Consider the following exploit scenario - You do a web search and find DSMAINT.NLM on a Novell web site. You download it. Using Fetch (a shareware FTP client), you access ftp.nmrc.org's Novell InterNetware server. You discover that you can gain access to everything on the SYS volume. You upload DSMAINT.NLM to SYS:SYSTEM, and upload an edited LDREMOTE.NCF file. This NCF file unloads CONLOG.NLM, unloads and reloads the REMOTE.NLM with a password of YOUR choosing, and loads XCONSOLE.NLM. After a reboot of the server (which you assisted with a SYN flood to overload buffers), the remote console password has been reset to one of your choosing. Telnet to ftp.nmrc.org and use your password. If your machine supports X Windows, you could choose that, but you use VT-100 instead since it creates less network traffic. You load DSMAINT.NLM and choose the Prepare for upgrade option. It looks nasty because of the VT-100 representation of the color screen, but in a few minutes, it is complete. An offshoot of the DSMAINT process is the creation of BACKUP.DS in the SYS:SYSTEM directory. Within a few minutes, Fetch is used to retrieve BACKUP.DS. This file contains all of the account names and passwords. The passwords are in encrypted form, but this is enough to log in. So you start writing an exploit to do just that, plus a brute force attack to get ALL of the passwords, including Admin's.... *** Summary and Acknowledgements *** "Sleep tight ... do security right: with Novell Directory Services." This quote comes from one of the aforementioned Novell web pages. Facing the facts, that quote seems arrogant and quite unappropriate. Currently in the bug wars between Novell and Microsoft, I'd have to state that I personally feel that Novell's offering IS more secure than Microsoft, but I cannot allow these remarks and quotes to go unchallenged. Novell does offer a lot of solid advice, advice that has been echoed in the Netware Hack FAQ and in other places, but after reading Novell's comments about Microsoft on April 11 I was inspired to discover the DSMAINT "flaw", and ultimately release this statement. Feel free to reprint and redistribute portions of this document in whole or in part, but please reference the Nomad Mobile Research Centre at http://www.nmrc.org. A lot of the information in this statement is derived from the Netware Hack FAQ. There have been many people besides myself that have contributed to this FAQ, including people from the Netware Hack mailing list and USENET newsgroups sci.crypt and comp.os.netware.security. But I would like to thank and acknowledge Greg Miller and Willem Jan Hengeveld for providing a lot of the background for much of the information presented here. Version 6 of the Netware Hack FAQ will be released within the next few days (currently being converted to HTML), and will include not only pointers to some of the hacking tools eluded to in this statement, but also proof-of-concept Pascal and C source code for a number of the security exploitation ideas expressed here. Expect an exploit for the DSMAINT flaw very soon.... Simple Nomad thegnome@nmrc.org http://www.nmrc.org