COMMAND
MITM attacks
SYSTEMS AFFECTED
Novell NetWare 5.0, 5.1
PROBLEM
Following is based on a BindView Advisory. Man-in-the-middle
Attack can reveal password hashes and private keys in Novell
NetWare. Affected systems are Novell NetWare 5.0, 5.1. Unsure
if NDS for other platforms (such as NT, Linux, or Solaris) are
impacted, but since the client software allows connectivity to
NetWare they probably are.
Novell has implemented RSA's public/private key technology for
encryption and part of their authentication process. Due to
protocol implementation problems, a man-in-the-middle attack
could allow for password hash recovery, and even a user's RSA
private key. In theory, a network intruder could recover password
hashes for cracking and system access, as well as RSA private keys
for authentication.
Based upon the work originally put forth by Greg Miller, plus
using further detailed information regarding the protocol, a more
complete analysis of the protocols used during both login and
authentication has been completed. Greg Miller's contributions
to cryptanalysis of the login process can be found at
http://www.nmrc.org/faqs/netware/nw_sec11.html#11-2
Also, the following links contain interesting fully commented code
that is related:
http://www.nmrc.org/faqs/netware/a-02.html
http://www.nmrc.org/faqs/netware/a-03.html
http://www.nmrc.org/faqs/netware/a-04.html
The "login" protocol is the protocol used during initial
authentication to a Novell Directory Services (NDS) tree. It is
a hybrid cryptosystem where a symmetrical algorithm is used to
encrypt data and a public-key algorithm is used to encrypt a
session key. This session key is used to sign packets and to
build a "credential". The "authentication" protocol is used with
the credential to authenticate to additional resources, and is a
variation of a Guillou-Quisquater zero-knowledge identification
algorithm. Hybrid cryptosystems and the Guillou-Quisquater
identification algorithm are discussed in "Applied Cryptography,
2nd Edition" by Bruce Schneier. ISBN 0-471-11709-9. Published by
John Wiley & Sons, Inc.
In the login protocol, we will assume hash function H is Novell's
proprietary one-way hashing function [4], E(data,key) is
encryption, and D(data,key) is decryption (encryption and
decryption are done using RC2 in CBC mode). Novell has licensed
RSA's public/private key technology, and uses the BSAFE SDK that
RSA licenses.
1. Alice initiates the login sequence, and the server replies with
a 4 byte random value RS1.
2. Alice generates random values RU1 and RU2, and creates
datablock DU1 consisting of RU1 and RU2 (all of these
datablocks contain checksums and usually some padding material
to make everything multiples of 8).
3. Alice retrieves the server's RSA public key KS and computes
DU2=E(DU1,KS).
4. Alice creates datablock DU3 from RS1.
5. Alice creates datablock DU4 from E(DU3,H(password,UID)).
6. Alice creates datablock DU5 from random numbers RU3 (which is
small) and RU4 (which is large), and DU4.
7. Alice computes DU6=E(DU5,RU1).
8. Alice sends DU2 and DU6 to the server.
9. The server computes DU1=(DU2,server private key) and extracts
RU1 which it uses to compute DU5=D(DU6,RU1) revealing RU3, RU4,
and DU4.
10. The server decrypts DU3 from DU4, and verifies RS1. The server
checks H against its own copy stored in NDS. If they match
then Alice has typed in the correct password.
11. The server takes Alice's stored private RSA key KU and creates
datablock DS1 by XORing KU with an equal number of bytes from
RU4.
12. The server builds DS2 from RU3 and DS1, and then builds DS3
from a timestamp datablock called DS4, and the encryption of
DS2 with DU4. The server sends DS3 to Alice.
13. Alice decrypts DS2 with DU4, verifies RU3, and XORs DS1 with
RU4 to get KU.
14. Alice builds credential C from DS4, random number RU5, and her
full account name in Unicode. A message digest M is taken of
C, and this is encrypted with KU to get value S. S is used to
sign packets.
This does several things. It allows Alice to log in using her
password without the password or the computed hash being
transmitted across the wire in clear text. It allows Alice's RSA
private key to be transmitted to Alice for creating a hash to sign
packets without sending it in clear text.
Now to the steps used during authentication to a secondary
resource, after logging in:
1. Alice sends a request to the server whose resource she wishes
to access, and sends a random value R.
2. The server generates value R2, and using Alice's public key
computes X=E(K,(R+R2)). This is sent to Alice.
3. Alice decrypts X and extracts R2. R2 may be related to the
time-to-live of S.
4. Alice encrypts random values R3, R4, and R5 with her private
key to get E3, E4, and E5 (note here that a Guillou-Quisquater
zero-knowledge identification algorithm would normally use 8
values instead of 3).
5. Alice creates E6=(E3+E4+E5+S). Alice then computes 16 byte
X2=H(E6). She uses the first three byte pairs of X2 as
exponent values EV1, EV2, and EV3 (the last 10 bytes are
ignored).
6. Alice computes three test values (PKM is Alice's
public_key_modulus):
TV1=(R3*S^EV1) mod PKM
TV2=(R4*S^EV2) mod PKM
TV3=(R5*S^EV3) mod PKM
7. Alice sends E3, E4, E5, TV1, TV2, TV3, and S to the server.
8. The server creates E6 as Alice did in step 5, recreates X, and
gets EV1, EV2, and EV3. Then the server computes to check the
following (assuming PKE is Alice's Public Key Exponent):
(TV1^PKE) mod PKM = (E3*(message_digest(C)^EV1)) mod PKM
(TV2^PKE) mod PKM = (E4*(message_digest(C)^EV2)) mod PKM
(TV3^PKE) mod PKM = (E5*(message_digest(C)^EV3)) mod PKM
9. If they work out equal, access to the resource is granted, as
it proves Alice knows the private key.
There are several scenarios that need to be reviewed in detail.
Two are very similar, and involve a "man-in-the-middle" (MITM)
attack against the login sequence to gain various pieces of
material to be used for later attack.
Of course MITM attacks assume that the attacker can sniff the
network, process and resend data to Alice and the server faster
than Alice and the server can to each other. The attacker could
conceivably use a combination of arp redirection and limited
denial of service attacks against key network points to help in
the effort to get packets to Alice and the server quickly (even in
a switched environment), although this is probably a bit beyond
our discussion. The main point here is to analyze the possibility
of attacking the protocol.
Scenario #1 - Our first MITM scenario is for our attacker Bob to
gain access to the server as Alice during Alice's authentication
process:
1. When Bob sees Alice request a login, Bob also requests a login
as Alice from the server.
2. The server will generate two random values RS1[a] and RS1[b] --
RS1[a] sent to Alice and RS1[b] sent to Bob.
3. When Bob receives RS1[b], he spoofs the server's address and
sends RS1[b] to Alice.
4. Alice asks the server for its public key KS. Bob asks the
server for KS as well.
5. Bob sniffs Alice's request for the server's public key and
spoofs the reply with his own public key KB.
6. Alice sends DU2 and E(DU5,RU1) to the server as normal, but DU2
is encrypted with Bob's public key.
7. Bob sniffs this request, performs DU2=E((D(DU2,KB)),KS), and
sends DU2 and Alice's E(DU5,RU1) to the server as his own.
8. Once all the information is received by the server, Bob's login
attempt will succeed and Alice's will fail, assuming all the
packets arrive properly and Bob gets his packets to the server
first.
9. When the server sends DS3 back to Bob, Bob is logged in as
Alice. Bob can also sign packets, because he has DU4 and can
decrypt DS2, and he also has RU4 and can XOR DS1 to get KU.
Scenario #2 - The second MITM attack involves obtaining data for
an offline brute force attack against the recovered material to
obtain Alice's password. If that is Bob's only objective, a
variation on the previous MITM attack will work even better:
1. When Bob sees Alice request a login, he immediately spoofs a
packet as the server with value RS1 of his own choosing.
2. When Bob sees Alice request the server's public key, he
immediately spoofs a reply as the server with his own public
key.
3. When Alice sends DU2 and DU6 to the server, Bob sniffs it.
Alice's login attempt will fail, and she will probably just try
again.
4. Bob decrypts DU2, extracts RU1, decrypts DU6, and extracts DU4.
5. Bob queries the server for Alice's UID (or possibly Bob
obtained it via sniffing during Alice's login attempt).
6. Bob knows what DU3 is since he provided his own RS1. Therefore
Bob can compute E(DU3,H(password,UID)) using different
passwords until he gets a match with the hash in the recovered
DU4. If Alice has chosen a weak password, Bob will be able to
get the password fairly quickly.
Scenario #3 - If Bob at any point obtains X where X=H(Alice's
password, Alice's UID) without knowing what the password actually
is, Bob can log in as Alice. X can be found in the NDS files
themselves, and if Bob ever gains access to the NDS files he can
extract X for any account and authenticate as that person:
1. Bob initiates a login sequence to the server as Alice, and
proceeds to login as normal.
2. When it comes time to compute DU4, Bob performs E(DU3,X).
3. The protocol continues, and assuming Alice hasn't changed her
password since Bob obtained X, Bob is logged in as Alice.
This scenario may seem far-fetched as it requires acquisition of
the NDS files, but consider if Bob gains access to the server
console, backup tapes, or copies of backup files left over from
certain maintenance operations. In those cases Bob could very
well obtain the NDS files, and X for every account on the server
including Admin.
Scenario #4 - If Bob obtained Alice's private key during Scenario
#1 or #3, Bob can authenticate as Alice to a NetWare resource at a
later date, even if she changes passwords. By sniffing, Bob will
know from Alice's last successful login the value of DS4, RU5,
Alice's full account name in Unicode, and can therefore compute S.
By using this and Alice's public key, Bob can compute E3, E4, E5,
TV1, TV2, and TV3 and send that with S as a part of an
authentication process posing as Alice.
For the first MITM attack to work, Bob has to be in the right
place at the right time. Bob will have to be able to get
information to and from the server and from Alice faster than
they can get it from each other. Possibly by using a combination
of arp tweaks, ICMP quenches, and a network DoS here and there it
might be possible to increase the odds of a successful attack.
We realize that it is entire possible to check Alice's desk for a
PostIt note with the password, which is a much easier attack (and
arguably more likely to succeed) as are many other attack vectors.
Nonetheless, it is still a risk.
But the second MITM attack could quite easily work, since Bob can
have his packets for steps 1 and 2 all ready to go, just waiting
for Alice to log in. Then you are solely dependent on the
strength of Alice's password for a security measure.
Even in a switched environment it is still possible to attempt
these attacks. Using arpredirect from the Dsniff package would
make this possible, so we will not be including anything in the
Mitigation section that recommends using a switched network.
Using STATION RESTRICTIONS for everyone is great, although
impractical in large environments. Minimally STATION RESTRICTIONS
should be used for those with access to privileged data,
especially system administrators. This and using strong passwords
that expire minimally every 42 days will help prevent offline
attacks. If you really wish to prevent the second MITM attack,
lengthen the passwords being used, make sure they are not
dictionary words, and shorten the number of days between password
expirations.
Another mitigation step is to avoid IPX and use IP. The sequence
numbering in SPX/IPX is so unbelievably simple (0 to 255, then
repeat as needed) that it is trivial for hackers to write
software that can handle it. Using TCP/IP at least allows for a
level of complexity (although still not impossible to deal with)
that will thwart a lot of spoofing attacks.
It is also possible that alternate backend authentication
mechanisms can be used, or completely different methods of
authentication, such as biometrics or smartcards. Novell has
developed NMAS (Novell Modular Authentication Services) and has
partnered with dozens of vendors to provide alternate methods of
authentication.
In summary, a physical network layout that has system
administrator traffic never crossing end user traffic, coupled
with STATION RESTRICTIONS, strong passwords, and even alternate
methods of communication should effectively mitigate crypto
attacks.
SOLUTION
Novell was contacted January 26, 2001. They acknowledged the
issues, will work to improve future products, and added to the
mitigation section of this document.