From gregmi@galileo.mis.net Sat Oct 12 23:31:23 1996 Date: Sat, 03 Aug 1996 22:39:21 -0400 To: netware-hack@dey-systems.com From: Greg Miller Message-ID: <2.2.32.19960804023921.00673238@mis.net> 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).