novell.remote.nlm.passwd.txt

`Date: Fri, 9 Apr 1999 02:24:45 -0700  
From: [email protected]  
To: [email protected]  
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  
[email protected]  
  
"Some OTHER operating systems suffer from weak password encryption."  
- A quote from Novell's course of Networking Technologies.  
  
------------------------------------------------------------------------  
  
Novell Pandora Hack  
  
Jeremy M. Guthrie ([email protected])  
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: [email protected]  
6404 Odana Rd. Phone: (608)-663-8000  
Madison, WI 53719 FAX: (608)-276-6406  
  
------------------------------------------------------------------------  
  
Re: Novell Pandora Hack  
  
Simple Nomad ([email protected])  
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 //  
[email protected] // ....no rest for the Wicca'd....  
www.nmrc.org //  
  
------------------------------------------------------------------------  
  
Date: Tue, 13 Apr 1999 12:36:48 -0600  
From: Sam Morris <[email protected]>  
To: [email protected]  
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" <[email protected]> on 04/12/99 11:37:18 AM  
  
Please respond to "Jeremy M. Guthrie" <[email protected]>  
  
To: [email protected]  
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: [email protected]  
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 <[email protected]>  
To: [email protected]  
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 //  
> [email protected] // ....no rest for the Wicca'd....  
> www.nmrc.org //  
  
  
*******************************************  
Iain P.C. Moffat  
College of Health Professions  
University of Florida  
E-mail: [email protected]  
Voice: 352.392.0965  
Fax: 352.392.6529  
*******************************************  
  
------------------------------------------------------------------------  
  
Date: Tue, 13 Apr 1999 13:38:27 -0600  
From: Sam Morris <[email protected]>  
To: [email protected]  
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....  
  
  
`