The Hacker's Encyclopedia 1998/hackers_encyclopedia.iso/hacking/network/zeroknow.txt

Text File | 2003-06-11 | 21.4 KB | 418 lines

From [e-mail] Sat Oct 12 23:31:23 1996
Date: Sat, 03 Aug 1996 22:39:21 -0400
To: [e-mail]
From: Greg Miller <[e-mail]>
Message-ID: <[e-mail]>
Subject: Draft of "A Few Attacks on the Zero Knowledge State In  Novell's NetWare"


        This is a text draft of my paper on the zero knowledge state attacks
of Netware.  The finished document will be distributed in PostScript format
which will produce a document which is much easier to read.
------------------------------------------------------------------------------



       A Few Attacks on the Zero Knowledge State In Novell's NetWare

                                Greg Miller
                               July 30, 1996




                                  Abstract

Novell's NetWare has employed a number of security measures to ensure the
protection of  data on both the workstation and the server.  However, a few
design flaws allows even the most secure version of NetWare (NetWare 4.0) to
fall to attacks.  The attacks employed have been well known throughout the
cryptographic community for several years.  The features Novell has added
include packet signatures and two different elaborate login protocols (one
for NetWare 3.x and one for 4.x).  I will show that these added features
fail to provide the security they intend to as well as feasible means of
implementing the attacks on a NetWare internetwork.



1.0 Introduction

    Contrary to the number of security measures Novell has added to its NetWare
servers over the years, there still remain a few serious flaws.  Some of the
flaws can be bypassed through the reconfiguration of the server and the
workstations.  However, some of the attacks require the security features of
NetWare to be redesigned.
    I will start with a general overview of the relevant security features of
NetWare, then move on to a description of the attacks I will be using to
defeat these security features.  The two attacks I will be using are the Man
in the Middle Attack, and the Chessmaster Attack (or Grand Chessmaster
Attack).  Having described these attacks in general terms, I will then show
how the attacks can be implemented feasibly on a NetWare network.  The
attacks will include a method which allows the attacker to execute any
arbitrary program on a given workstation, a method which allows an attacker
to log in as a given user without knowing the user's password (separate
attacks are given for 3.12 and 4.x), an attack which allows the intruder to
do an off-line guessing attack on NetWare 4.x passwords, and one attack
which enables the intruder to modify data sent to a workstation.
    After I have presented the attacks, I will describe a few changes in the
network configuration which can be used to secure the network against most
of the attacks.  However, some of the attacks can only be secured by
redesigning the way NetWare implements its security features.

    Throughout the paper I will make use three different names to describe
entities in the network.  I call them Alice, Jane, and Bob.  I will assume
that Alice and Jane are two entities which wish to communicate securely, and
that Bob wishes to attack the security features Alice and Jane implement in
their protocols.  In some cases it is necessary to indicate that Alice will
request to initiate the conversation, while Jane will accept (or deny) the
request.


2.0 An Overview of NetWare Security Features

    Novell has implemented features into NetWare to prevent methods such as
address spoofing and password capturing through the use of packet sniffers.
Also a feature added to NetWare 4.0 was added to prevent the use of an
off-line password guessing attack.  The features include a packet signing
scheme, an encrypted login sequence, and NetWare 4.0 employs the use of
public key cryptography.

2.1 Packet Signatures

    Packet signatures were added to NetWare 3.12 to prevent address spoofing
attacks after a few students at Leiden University put together a program
which allowed anyone to grant supervisor rights to every user on the NetWare
server.
    To solve the problem, Novell added a feature to NetWare 3.12 which allows
the client and the server to sign packets based on the common knowledge of a
hash of the user's password.  In its default configuration the NetWare
server doesn't require all clients to sign packets.  The server can be
configured for packet signatures in three different ways:  not sign packets
at all, only sign packets if the client can, and always require the client
to sign packets (if the client cannot sign packets, then the login sequence
fails).
    NetWare 4.x employs a different method of signing packets.  The
configuration is the same, but the algorithm used to sign the packets
changed.  The combination of the RSA algorithm and the Guillou-Quisquarter
authentication scheme are used.  Here the client uses the GQ key while the
server uses the RSA key.  Please note that these are only used for
authentication and not encryption of network traffic.
    In either case, only the first 52 bytes of each packet are signed to
increase efficiency.  Novell claims that this is sufficient to guard all the
vital data in the packet.  I will show that this is not true.

2.2 The NetWare 3.12 Encrypted Login Sequence

    The login sequence isn't really encrypted, but for some reason all the
literature states it that way.  Really a one way hash is performed on the
password, and then a hash is performed on the hash.  The user's actual
password is never transmitted in a reversible way across the network (nor is
the hash of the password).  The login sequence is as follows:

1.  Alice sends a login request to the server.
2.  The server retrieves a hash of Alice's password (X) and Alice's user ID
(s) stored in the server's database, then computes a random value (R), and
sends the pair (s,R) to Alice.
3.  Alice computes X'=hash(password,s), then computes Y'=hash(X',R).  Then
sends the value Y' to the server.
4.  The server checks to see if Y=Y', if so, Alice is granted access.
5.  If both Alice and the server agree to use packet signatures, they both
compute another hash of the triple (X,R,c) (where c is some constant value).
This value is then used as a common secret for generating hashes of the
vital data in packets sent between Alice and the server.

2.3 The NetWare 4.x Encrypted Login Sequence

    The login protocol for NetWare 4.x is similar to that used in NetWare 3.12.
It differs in the fact that it uses RSA encryption to prevent an off-line
guessing attack, and RSA authentication is performed if Alice and the server
agree to use packet signatures.  The protocol is as follows:

1.  Alice sends a login request to the server.
2.  The server retrieves Alice's UID (s) and generates a random value (R)
and sends the pair (s,R) to Alice, as well as the server's public RSA key.
3.  Alice generates X'=hash(password,s) and Y'=hash(password,R) and
generates       another random value (R2).  Alice then encrypts the pair
(R2,Y') with the server's public key and sends the result to the server.
4.  If the server verifies that Y=Y', the server will retrieve Alice's
private RSA key (P) from the server's database, compute P XOR R2, then
encrypt the result with Y, and will send this value back to Alice.
5.  Alice decrypts her private key, and generates a GQ key which she uses to
sign packets.

    The primary advantage (and apparently the only advantage) this protocol has
over the 3.12 protocol is that it prevents an off-line guessing attack
through the encryption of the (R2,Y') pair with the server's public key.
    A rather odd feature is the encryption of the P XOR R2 result with Y in
step #5.  This appears to have no effect on the security of the protocol
since the only way to reveal R2 is to decrypt the (Y',R2) pair.  If Bob can
decrypt the pair (Y',R2), he will also know Y if Y=Y' and thus, can decrypt
the value sent to Alice in step #5.

3.0 The Man in the Middle Attack

    A Man in the Middle Attack can be implemented on a protocol which uses a
reliable transport layer such as SPX or TCP without requiring the attacker
(Bob) to be physically in the middle of the two communicating parties (Alice
and Jane).
    One method for implementing an attack using a single machine with a single
entry point in to the network was done Joncheray in [JON95].  Joncheray's
attack has two disadvantages:  it requires that the connection be closed
then re-opened, and it causes the generation of a significant number of
packets which overload the network.  Due to these two disadvantages the
attack can be detected.  One other thing to note about this attack is that
it won't work with SPX.
    I'll present an attack which will work for both TCP and SPX, but requires
more resources to be available than Joncheray's attack.  I will later show
that due to a design flaw in the SPX implementation that the need for these
added resources can be removed when Alice and Jane are using SPX.
    Under normal circumstances, when Alice wishes to initiate a conversation
with Jane, the setup goes as follows:

1.  Alice sends a connect request to Jane.
2.  Jane responds by sending her public key to Alice.
3.  Alice uses Jane's public key to encrypt some secret which will be used
for authentication for the remainder of the session.
4.  Jane decrypts the secret and uses it to authenticate packets to and from
Alice.

    Now suppose Bob wants to interrupt this protocol so that he may participate
in the conversation with Alice and Jane without their knowledge.  For this,
Bob will need two entry points into the network (one close to Alice, the
other close to Jane).  Bob will also need a "fast" transmission medium
between these two entry points, such as wireless network cards, cellular
capable modems, normal modems over existing phone lines, etc. (this may
require the use of more than one computer system).
    I will now define a few parameters needed for the attack:

A            The network Alice is physically connected to.
B            The network of Bob's first entry point close to Alice.
C            The network of Bob's second entry point close to Jane.
D            The network Jane is physically connected to.
s[j],s[b]            Jane's and Bob's private key.
p[j],p[b]            Jane's and Bob's public key.
S(a,b)            The secret shared between Alice and Bob
S(b,j)            The secret shared between Bob and Jane.
E(a,b)            S(a,b) encrypted with p[b].
E(b,j)            S(b,j) encrypted with p[j].
P(x,y)            The propagation delay between points x,y in the Network.
Pb(x,y)            The propagation delay over Bob's "fast" medium between x,y.

    For the attack to work, Bob must define a topology where B and C are
between A and D and P(B,C)1 must be much greater than Pb(B,C)2.  This allows
Bob to observe a packet at point B, retrieve the information from it, alter
it, and introduce the altered packet into the network at point C (and vice
versa).  Bob will use the sequence numbers retrieved at point B in the
packet introduced at point C.  Bob's altered packet will beat Alice's packet
to Jane.  When Jane receives Alice's packet, it will be discarded as a
duplicate.
    To interrupt the protocol, the following procedure will be followed:

1.  Alice will send a connect request to Jane.
2.  Jane will send p[j] to Alice.
3.  Bob will see p[j] at point C, and copy the packet into memory, replace
p[j] with p[b], and introduce the packet into the network at point B.
4.  Alice will receive p[b] believing that it's p[j], and will use p[b] to
encrypt S(a,b) yielding E(a,b) which she will send to Jane.
5.  Alice will receive p[j] and will discard it as a duplicate since the
sequence numbers match that of the packet containing p[b].
6.  Bob will see E(a,b) at point B, copy the packet into memory, decrypt
E(a,b) with s[b], encrypt the result with p[j] yielding E(b,j) which he
introduces into the network at point C3.
7.  Jane will receive E(b,j), decrypt it will s[j], and use the value to
authenticate packets to and from Alice.
8.  Jane will receive E(a,b), but will discard it as a duplicate.

Note:  Bob does not have to send false ACKs to Alice and Jane for the
packets he introduces into the network, because Alice and Jane will ACK the
packets appropriately.

    If Alice and Jane use the secret to encrypt data, Bob only needs to sniff
the data off the network at point B or C.  But to send packets as Alice or
Jane, he has to sniff the packet at either B or C and introduce them at the
opposite end to keep the sequence numbers synchronized.

4.0  The Grand Chessmaster Attack

    Using the same method as above, a Chessmaster attack can also be
implemented against two entities in a network using a reliable transport
layer such as TCP or SPX.  The normal protocol (when not interrupted)
proceeds as follows:

1.  Alice broadcasts a request for a service.
2.  Jane responds indicating she can provide the service.
3.  Alice sends a connect request to Jane
4.  Jane responds by sending her public key.
5.  Alice encrypts some secret with Jane's public key and sends it to Jane.
6.  Jane decrypts the secret, and Alice and Jane use the secret for secure
communication over the network.

    If Bob would like to appear to provide this service without actually being
capable of doing so, he could use the following procedure:

1.  Alice broadcasts a request for a service.
2.  Both Bob and Jane respond indicating they can provide the service.
3.  Alice arbitrarily chooses to use the service provided by either Bob or
Jane and sends a connect request4 (we'll assume she chooses Bob).
4.  Bob responds by sending his pubic key to Alice.
5.  Alice encrypts some secret with Bob's public key and sends it to Bob.
6.  Bob decrypts the secret and uses the secret to communicate with Alice.
7.  Bob sends a connect request to Jane.
8.  Jane responds by sending Bob her public key.
9.  Bob encrypts some secret with Jane's public key and sends it to Jane.
10.  Jane decrypts the secret and uses it to communicate with Bob.

    When Alice makes a request:

1.  Alice sends the request to Bob.
2.  Bob sends the request to Jane.
3.  Jane sends the reply to Bob.
4.  Bob sends the reply to Alice.

    This attack has several advantages over the Man in the Middle Attack: (1)
it is much easier to implement (doesn't require packet filtering or address
spoofing), (2) Less resources are required to implement the attack, (3) Bob
does not have to be on a network between Alice and Jane, he can be on any
network Alice is attached to which is closer to Alice than the network Jane
is attached to.
    There are also disadvantages to this attack: (1) Bob must identify himself
to everyone on the network (and may get requests from other stations on the
network), (2) Bob has to continuously forward all traffic between Alice and
Jane.  As a result, this attack is detectable, and the attack will trip
alarms on some NetWare servers on the network.

5.0  Attacking the NetWare Login Protocols

5.1  The NetWare 3.x Login Protocol

    Bob can use a combination of the Man in the Middle Attack and the
Chessmaster attack to log in to a NetWare 3.x server without knowing the
password of the user he is logging is as, and without revealing his
intentions to other stations on the network (or even Alice).  Bob can use
the following procedure to do so (this requires the resources as described
in the Man in the Middle Attack).

1.  Alice sends a login request as Alice to the server.
2.  Bob sees the request at either point B or C and sends a login request as
Alice to the server.
3.  The server will respond by generating two random values (Ra and Rb) and
send them to with Alice's UID to Alice and Bob respectively.
4.  Bob will receive Rb at point C, and then send Rb to Alice, introducing
the packet into the network at point B.
5.  Alice will receive Rb, compute X'=hash(password,UID) and Y'=hash(X`,Rb)
and will send this value to the server.
6.  Bob will see Alice's Y' at either point B or C, and copy it from the
network and send it to the server.  This will effectively authenticate Bob
as Alice.
7.  The server will receive two identical Y' values, the value Alice sent
will most likely be wrong, while Bob's will be correct.  As a result, Bob
will be granted access while Alice will be denied.
8. a.  If the server is configured to request packet signing, it will
request Bob to sign his packets.
b.  If the server is  configured to require packet signing, it will require
Bob to sign packets.
9.   a.  Bob will not accept the request and will not sign packets.
b.  Bob cannot compute the hash(X,Rb,c) so will not be able to log in.

    Note that steps eight and nine have no bearing on whether or not Alice has
her workstation set up to deny, request, or require packet signatures.  A
few other things are worth noting:  (1)  If Alice uses the same password on
more than one server, Bob can log into any server she uses the same password
on as the server she is attempting to log in to by also replacing the UID in
step three, and (2) Bob logs in to the server without packet signatures
which opens Alice's account up to spoofing attacks.

6.0  Packet signature attacks

6.1  Spoofing the LOGIN.EXE file

    A higher level view of the login sequence can be presented as follows:

1.  Alice finds the nearest (or preferred) server and attaches to it.
2.  Alice downloads the LOGIN.EXE file and executes it.
3.  The login handshake is carried out and Alice is authenticated.

    One problem:  Packet signatures aren't enforced until after the user logs
in.  Thus it is possible to any workstation to spoof the LOGIN.EXE file and
replace it with any program.
    When Alice attempts to download the login.exe file, she first sends a
request to the server to open it.  The server then responds by sending
information about the file back to Alice (such as the file length).  She
will then submit read requests to the server until she has read in the
entire file.
    Bob can obviously use the Man in the Middle Attack configuration to replace
the server's login.exe with his own trojan login.exe.  He would listen for a
response to the open request from the server at point C, and replace a
modified packet on to the network at point B.  He would do the same for each
subsequent READ response.  The trojan login.exe could then log Alice in as
normal and broadcast her password on to the network.  In this case, neither
Alice nor the server can detect that anything has gone wrong.
    Simply enforcing packet signatures while the login.exe file is being
downloaded is not enough to secure against this attack.  When Alice first
connects to the network, she broadcasts a request for the nearest server.
Bob could use the Chessmaster Attack to have Alice attempt to connect to Bob
rather than to Jane (the real server)5 using the following procedure:

1.  Alice sends a request to find the nearest (or preferred) server.
2.  Bob responds before Jane stating that he is closer to Alice than Jane.
3.  Alice downloads the login.exe file from Bob.
4.  Bob's trojan login.exe logs Alice into Jane (and breaches security in
some way).

    Any signature keys would have been retrieved from Bob at first and then
renegotiated with Jane during the login sequence.  So Alice will not be able
to detect that anything has gone wrong.  However, any intelligent station on
the network which knows Bob is not a real server can detect what has
happened.  If Bob is confident that he will be gone by the time anyone can
act on the detection, then he can still "safely" use the attack.

6.2 Modifying any File in Transit

    Novell added packet signatures with a specific goal in mind:  to prevent
the use of address spoofing to grant privileged access to users.  In order
to accomplish this goal, Novell designed the packet signatures in NetWare to
only sign the first 52 bytes of each packet.
    Bob can use the same method used to spoof the login.exe program, but can
only change data beyond the signed 52 bytes.  Notice that this flaw is not
derived from the zero-knowledge state, but is a general flaw in NetWare
security.

7.0  Predicting SPX Sequence Numbers

    To predict SPX sequence numbers, one only needs to know how to count.  The
sequence numbers start at zero when the connection is established, and
increment +1 for each packet.  In fact, the sequence number field is
described as a counter in [CHA94].
    Since Bob can reliably predict the sequence numbers, he does not need two
separate entry points into the network when he only needs to know the
sequence numbers.  The only attack this has any effect on is the spoofing of
the login.exe file.  It allows Bob's entry points B and C to be equal.
Since it is possible that A=B and C=D, it follows that that A=B=C=D as long
as Bob can respond to the requests faster than Jane.

9.0  References

[CHA94] "Novell's Guide to NetWare LAN Analysis", Laura A. Chappell and Dan
E. Hakes, Sybex 1994.

[JON95] "Simple Active Attack Against TCP", Laurent Jonchery, Proceedings of
the Fifth USENIX UNIX Security Symposium, Salt Lake City, Utah, June 1995.

1 The delay between the time when Jane receives a request and the time she
responds should also be considered in the propagation delay.
2  It is possible that A=B and C=D for just about any topology.
3 Here Bob has chosen to make S(a,b) = S(b,j).  This reduces the effort Bob
has to implement to allow Alice and Jane to communicate.  By allowing these
two values to be equal, he does not have to continually encrypt and decrypt
all traffic between Alice and Jane.
4 Bob can normally ensure Alice will choose him over Jane by responding to
the request first.  If not, Bob can indicate that he can provide this
service better than Jane.  In NetWare, Alice will request the address of the
nearest server, as long as Bob is closer than Jane, he will be chosen over Jane.
5  The server Alice initially attaches to is independent of the server Alice
wishes to log in to (unless she has configured her workstation to attach to
a preferred server).