Date: Fri, 9 Apr 1999 02:24:45 -0700 From: dreamer@RELIA.NET To: BUGTRAQ@netspace.org Subject: New Novell Remote.NLM Password Decryption Algorithm with Exploit I am providing this message in hopes that it will contribute to the general knowledge of others. Please distribute this document fully intact, so people can learn the -entire- algorithm. - - - - - - Novell is known to use a one-way hash algorithm in their password encryption, so all captured encrypted passwords must be brute-forced, slowly and painfully. However, a few days ago, I cryptographically cracked Novell's Remote.NLM password encryption algorithm. It is a very weak algorithm compared to what Novell has implemented in NDS, as it is instantaneously decryptable. RConsole password encryption is different from Remote.NLM password encryption because: 1) Encrypted RConsole passwords are sent across the wire, via RConsole. Remote.NLM's encrypted passwords are generated at the server console by typing REMOTE ENCRYPT MyPass, and they are optionally stored in SYS:System\LDRemote.NCF. 2) They use a different password encryption algorithm. RConsole passwords are encrypted with information from the workstation that is currently running RConsole. Remote.NLM passwords are encrypted with a time byte, one of 255 constants in a hash table, appended characters, some XORing, and bit-order separation. 3) Encrypted RConsole passwords are locally obtained with a packet sniffer, but Remote.NLM passwords are remotely accessible to anyone with the ability to view SYS:System\LDRemote.NCF. The Remote.NLM passwords are decrypted using only five steps. To encrypt, simply reverse the steps. I don't know if this would be called a two-way hash algorithm, but I assume it is. The password will look something like this: AF8CBBF48CA9955F5ADAFDADAA23 The structure of the password is as follows: AF8CBBF48CA99 55F5ADAFDADAA - 23 The first section contains the low-order bits, and the second, the high-order bits. 23 is the time byte, which is decremented by the server once every two seconds, from FF to 02, then back up to FF, etc. Step 1) Realign the low-order bits and high-order bits. This is extremely simple to do. The high-order bits are in order from the first character to the last, and so are the low-order bits. Example: Password: AF8CBBF48CA99 - 55F5ADAFDADAA, Output: 5A 5F F8 5C AB DB AF F4 D8 AC DA A9 A9 At this point, ignore 5A 5F F8 5C, or the first four bytes. They are appended somewhere during encryption, and decrypt to "%*@$". It was a TERRIBLE idea for Novell to implement those four characters into every single password, as those are what helped me rebuild their hash table from scratch. Also, if the length of the password is 10, the password is automatically decryptable to nul. Step 2) Match each of the password characters (group of two hex characters) to the hash table below. Use their position from the beginning of the table to determine the value of the pre-hash encrypted password. Example: F4, the 8th character of the password, matches the hash table at 95. This means that 95 is the pre-hash value of F4. Thus far, (ignoring the first four characters) the password was: AB DB AF F4 D8 AC DA A9 A9 and now the password is: 98 A0 9B 95 A1 9D A6 9C 9C Remote.NLM Hash Table 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00 5B 58 5E 5F 59 5C 5A 5D-73 70 76 77 71 74 72 75 10 13 10 16 17 11 14 12 15-7B 78 7E 7F 79 7C 7A 7D 20 53 50 56 57 51 54 52 55-03 00 06 07 01 04 02 05 30 1B 18 1E 1F 19 1C 1A 1D-0B 08 0E 0F 09 0C 0A 0D 40 2B 28 2E 2F 29 2C 2A 2D-63 60 66 67 61 64 62 65 50 83 80 86 87 81 84 82 85-3B 38 3E 3F 39 3C 3A 3D 60 8B 88 8E 8F 89 8C 8A 8D-33 30 36 37 31 34 32 35 70 93 90 96 97 91 94 92 95-6B 68 6E 6F 69 6C 6A 6D 80 9B 98 9E 9F 99 9C 9A 9D-A3 A0 A6 A7 A1 A4 A2 A5 90 F3 F0 F6 F7 F1 F4 F2 F5-AB A8 AE AF A9 AC AA AD A0 DB D8 DE DF D9 DC DA DD-FB F8 FE FF F9 FC FA FD B0 23 20 26 27 21 24 22 25-B3 B0 B6 B7 B1 B4 B2 B5 C0 CB C8 CE CF C9 CC CA CD-BB B8 BE BF B9 BC BA BD D0 C3 C0 C6 C7 C1 C4 C2 C5-D3 D0 D6 D7 D1 D4 D2 D5 E0 43 40 46 47 41 44 42 45-E3 E0 E6 E7 E1 E4 E2 E5 F0 4B 48 4E 4F 49 4C 4A 4D-EB E8 EE EF E9 EC EA ED Step 3) Subtract the length (the number of groups of hex characters, excluding the time character) of the full password from each encrypted password character. Now you have the ACTUAL pre-hash encrypted password. If the subtracted value is negative then simply continue from FF down to the negative value. Example: if the password character is at 04, and the length is 6, the value of the password character will be FF. The length is 13 (D in hex), so the password was: 98 A0 9B 95 A1 9D A6 9C 9C and is now: 8B 93 8E 88 94 90 99 8F 8F Step 4) Get the time var, in this situation 23 (hex), and subtract it >from FF. This new character is for use in Step 5. Example: FF-23=DC. Step 5) Finally, XOR each character (group of 2 hex characters) of the encrypted password with the new time character, and you now have the decrypted password! The password was: 8B 93 8E 88 94 90 99 8F 8F (before the XOR) Now, the decrypted password is: 57 4F 52 54 48 4C 45 53 53 "WORTHLESS" I used "worthless" because if I seventeen-year-old with almost NO experience in cryptography can crack an encryption algorithm, then under most circumstances the algorithm is ABSOLUTELY WORTHLESS!!! I have written a program in Pascal (oh well) which decrypts Remote.NLM passwords instantaneously. I am unsure of the password length limits of the program because I just wrote it. However, it has never failed to decrypt a password. I have tested it on a password of around 50 characters, and it worked flawlessly, so there shouldn't be anything to worry about regarding the length limit. It can decrypt any character, from 00 to FF, and it will display that value upon execution. The source of the program is attached. If you need help understanding this, or you wish to contribute to this document, feel free to e-mail me. TheRuiner dreamer@relia.net "Some OTHER operating systems suffer from weak password encryption." - A quote from Novell's course of Networking Technologies. ------------------------------------------------------------------------ Novell Pandora Hack Jeremy M. Guthrie (jguthrie@CINET.NET) Mon, 12 Apr 1999 12:37:18 -0500 I had a friend show me the Novell TID: 2941119 about what Novell calls the "Pandora Hack". I suggests patching Netware to at least SP5 and setting client/server signatures to 3. I was under the impression that the signature fix did not take care of the issue. Comments???? It looks like Novell wants you to see the error messages... then figure out a corrective action against the attacker. Or I could be on crack. -- Jeremy M. Guthrie Network Administrator Certified Novell Engineer Custom Internetworking email: jguthrie@cinet.net 6404 Odana Rd. Phone: (608)-663-8000 Madison, WI 53719 FAX: (608)-276-6406 ------------------------------------------------------------------------ Re: Novell Pandora Hack Simple Nomad (thegnome@NMRC.ORG) Tue, 13 Apr 1999 12:03:05 -0500 On Mon, 12 Apr 1999, Jeremy M. Guthrie wrote: > I had a friend show me the Novell TID: 2941119 about what Novell calls the > "Pandora Hack". I suggests patching Netware to at least SP5 and setting > client/server signatures to 3. I was under the impression that the > signature fix did not take care of the issue. Comments???? It looks like > Novell wants you to see the error messages... then figure out a > corrective action against the attacker. Or I could be on crack. I thought crack ran on Unix...;-) There are two things you need to do to stop the Pandora attacks from succeeding - load up the correct DS.NLM (hence the SP5B fix), and have SET NCP PACKET SIGNATURE OPTION=3 somewhere before this NLM loads. Putting the SET statement at the beginning of either the STARTUP.NCF and AUTOEXEC.NCF is fine. I'd also recommend binding protocols to cards last. The client packet signature settings must be on at least 1 (which is the default) otherwise you will not be able to log in. This means proper protection from Pandora will involve updating any stone age client software. That error is supposed to be there anyway -- that was the original problem, you could bypass all of the signature stuff and NCP spoof your way onto the server with elevated privs. Yes the default out of the box settings on Netware 4.x leaves you vulnerable to attack. By default Netware 5 uses IP instead of IPX, but of course Novell's IP stack is susceptable to sequence prediction so you stand the same theoretical risk (Pandora is IPX-based only). Of course spoofing the source of a Pandora attack can have other effects with these security measures in place, since you could fill up the SYS volume (stopping all server processing) with "invalid security signature" messages. There is no "last message repeated 200,000 times" log entry in Netware.... Simple Nomad // thegnome@nmrc.org // ....no rest for the Wicca'd.... www.nmrc.org // ------------------------------------------------------------------------ Date: Tue, 13 Apr 1999 12:36:48 -0600 From: Sam Morris To: BUGTRAQ@netspace.org Subject: Re: Novell Pandora Hack I just went through this extensively with Novell, up to the point of having the issue declared "CRITSIT" which is their highest level an incident can be raised to. By setting the server to reject incomplete NCP packets and those with bad lengths, and also setting the NCP packet signature level to 3 (all of these must be set in STARTUP.NCF, before DS.NLM loads...setting these in SERVMAN will add them into AUTOEXEC.NCF, and you must cut and paste them into STARTUP.NCF) you will effectively kill the exploit. You will still see the utilization rise on the server if someone "attacks" the server, but that is merely the server rejecting the packet, and not processing it. (The server HAS to look at the packets coming to it...they are NCP (NetWare Core Protocol) packets, and to ignore them would effectively render the server useless.) All that can be done is to have the server reject it and not process it. The downside of this all is that the attacker doesn't have to be logged into the network, and there is no effective way to track the MAC address they are coming from, as the packets take on the MAC address of the spoofed connection. I would suspect thought that if you thought someone was attacking your servers, you could eventually figure out where that person is, and take appropriate administrative actions. But for Novell's part, there isn't much more one could expect them to do. Keep in mind that setting NCP packet signature to level 3 will prevent people using microsoft's client for NetWare from being able to log in. Sam "Jeremy M. Guthrie" on 04/12/99 11:37:18 AM Please respond to "Jeremy M. Guthrie" To: BUGTRAQ@NETSPACE.ORG cc: (bcc: Samuel A. Morris) Subject: Novell Pandora Hack I had a friend show me the Novell TID: 2941119 about what Novell calls the "Pandora Hack". I suggests patching Netware to at least SP5 and setting client/server signatures to 3. I was under the impression that the signature fix did not take care of the issue. Comments???? It looks like Novell wants you to see the error messages... then figure out a corrective action against the attacker. Or I could be on crack. -- Jeremy M. Guthrie Network Administrator Certified Novell Engineer Custom Internetworking email: jguthrie@cinet.net 6404 Odana Rd. Phone: (608)-663-8000 Madison, WI 53719 FAX: (608)-276-6406 ------------------------------------------------------------------------ Date: Tue, 13 Apr 1999 15:08:07 -0500 From: Iain P.C. Moffat To: BUGTRAQ@netspace.org Subject: Re: Novell Pandora Hack Yes this is why the console log (and any other log files for that matter) should be redirected to a quota restricted directory or better yet another volume "var" perhaps. Hmmm...what a concept. While this is still less than ideal, it will at least minimize the impact. -Iain On 13 Apr 99, at 12:03, Simple Nomad wrote: Much stuff Cut..... > Of course spoofing the source of a Pandora attack can have other effects > with these security measures in place, since you could fill up the SYS > volume (stopping all server processing) with "invalid security signature" > messages. There is no "last message repeated 200,000 times" log entry in > Netware.... > > Simple Nomad // > thegnome@nmrc.org // ....no rest for the Wicca'd.... > www.nmrc.org // ******************************************* Iain P.C. Moffat College of Health Professions University of Florida E-mail: ipm@ufl.edu Voice: 352.392.0965 Fax: 352.392.6529 ******************************************* ------------------------------------------------------------------------ Date: Tue, 13 Apr 1999 13:38:27 -0600 From: Sam Morris To: BUGTRAQ@netspace.org Subject: Re: Novell Pandora Hack - Filling the SYS Volume You can put a limit on the maximum size of the error log file (SYS$LOG.ERR) though..... This will stop it from filling the volume. Sam Of course spoofing the source of a Pandora attack can have other effects with these security measures in place, since you could fill up the SYS volume (stopping all server processing) with "invalid security signature" messages. There is no "last message repeated 200,000 times" log entry in Netware....