🚀 go-pugleaf

---------- Forwarded message ----------
Date: Mon, 16 Dec 1996 18:42:34 -0800 (PST)
From: Nachos served with butter <nachos@dis.org>
Reply-To: best-of-security@suburbia.net
To: best-of-security@suburbia.net
Subject: BoS:  Long Post... Is Microsoft Asking for Trouble or Is it in Denial?
Resent-Date: Sat, 21 Dec 1996 13:55:51 +1100 (EST)
Resent-From: best-of-security@suburbia.net

Microsoft is in a habit of continous self denial defending NT as the most 
secure OS but here we catch them with their pants down.

Article from Information Week

Windows NT Security Questioned

Experts says hackers could gain entry to system 

By Stuart J. Johnston
Issue date: Dec. 16, 1996 

Microsoft's Windows NT continues to gain momentum as an enterprise 
server. But security experts last week cautioned that current versions 
contain critical security flaws. And those flaws are not scheduled to be 
fixed until NT 5.0 ships, which may not be until 1998. 

A group of security professionals recently discovered holes that could 
let a hacker gain complete access to the system. The invader could then, 
for example, write a program that changes passwords, thus locking 
everyone out of the network. 

Microsoft officials doubt such a breach could happen, but the security 
experts say they have written demonstration programs that prove it can be 
done, though they do not plan to release the code. Yobie Benjamin, 
associate director at Cambridge Technology Partners, a consulting firm in 
Cambridge, Mass., and one of the experts who discovered the holes, says 
the information is already available among hackers. 

"Even if these guys don't release their [programs], there are people who 
know about [the weaknesses] and it's going to be done," adds Jeff Moss, 
president of Def Con Communications, a Seattle security consulting firm, 
who believes Microsoft can solve the problem by accelerating its plans to 
use Kerberos authentication security, scheduled to be part of NT 5.0. 

But that's not likely. "[Kerberos] is not something you can just plop 
onto NT [4.0]," says Mike Nash, director of marketing for NT Server. Even 
if it did, he notes that other network operating systems don't support 
Kerberos, so heterogeneous networks would still be vulnerable. 

Users reacted with guarded optimism. "The message that needs to get sent 
is 'Be careful'," says Michael Wolfe, network software engineer at 
Chevron Information Technology Co., in San Ramon, Calif. A security 
problem is "a real concern, but we haven't experienced anything like 
that." 

Now folks, let's take a look at their own publication.

========

Even Microsoft Admits NT's Weakness.  Look at the section 8 except from 
this publicly available draft.  Nothing has been added or deleted.  These 
weaknesses are in the current implementation of Windows NT 4.0.

You will note that all of these allow for various "hacks and attacks" on 
an enterprise NT system.

-----------------------

Network Working Group                                      I. Heizer
Request for Comments: DRAFT                                P. Leach
Category: Informational                                    D. Perry
Title: draft-heizer-cifs-v1-spec-00.txt                    Microsoft
June 13, 1996                                                          

Common Internet File System Protocol (CIFS/1.0)

Section 8

8. Security Considerations

There are four authentication mechanisms, each with their own strengths 
and weaknesses, as well as attacks that are independent of the 
authentication protocol.

8.1 Share level protection
In share level protection, there are no per-user passwords; knowledge of 
the read or write password is what gives read or write access. Since the 
passwords must be disclosed to be used, and hence known by many people, 
the scheme is quite weak.
In addition, the passwords are sent in the clear over the network, so 
they have all the weaknesses of clear text passwords in user level security.

8.2 Plaintext Password Authentication
This authentication protocol sends the client's password in the clear. It 
should be used only when needed for backwards compatibility, and only 
where the chances of eavesdropping is deemed acceptable, such as 
relatively isolated networks. Passwords sent to such servers should never 
be the same as passwords used for more secure servers.

8.3 LANMAN 2.1 (and earlier) Challenge/Response
This authentication protocol is subject to the following vulnerabilities:
o Known plaintext attack
o Small key space
o Chosen plaintext attack
o Dictionary attack
o Badly chosen passwords

These attacks, if successful, compromise the client's password, and allow 
the attacker access to the client's files even after the client's session 
has ended. Because of these attacks, it should be used only when needed 
for backwards compatibility, or where the chances of eavesdropping are 
deemed acceptable, such as relatively isolated networks. It is more 
secure than plaintext password authentication, because passwords are 
never seen in the clear on the network. Whenever possible, the use of the 
NT LM 0.12 authentication is to be preferred.

8.3.1 Known Plaintext Attacks
Because the challenge is plaintext, an eavesdropper can acquire known 
plaintext/ciphertext pairs. It can then test a guess at a password by 
using it to generate a key, encrypting the plaintext, and comparing it to 
the corresponding ciphertext.

8.3.2 Small Key Space
The combination of the use of only uppercase characters, the usual user 
practice of  choosing passwords that have alpha and perhaps numeric 
characters, plus the fact that the protocol treats the upper and lower 
halves of the 14 bytes key almost identically means that the key space is 
rather small. Enumerating 7 uppercase characters and digits leads to a 
key space of 36**7, or 78.3 billion combinations. When this mechanism was 
introduced nearly a decade ago, this was probably an adequately large key 
space, but with today's much more powerful systems, it is now small 
enough to make a brute force search feasible upon a plaintext/ciphertext 
pair obtained via a known plaintext attack.

8.3.3 Chosen Plaintext Attacks
A "main-in-the-middle" or a counterfeit server can choose the challenge 
"C8" which the client will then encrypt using a key derived from the 
client's password. The ability to choose the plaintext to be encrypted is 
known to make breaking many ciphers much easier.

8.3.4 Dictionary Attacks
The attacker can precompute the response for many common passwords to a 
challenge of its choice, and build a dictionary of (response, password) 
pairs. It can then use the chosen plaintext attack to acquire a response 
corresponding to that challenge, and just look up the password in the 
dictionary.

8.3.5 Badly Chosen Passwords
Passwords that are not long enough, or that are words in the language of 
the clients, make the above attacks even easier by reducing the key space 
even more. 

8.4 NT LM 0.12 Challenge/Response
Because it uses MD4 to generate the keying material from the password, 
and because it preserves the password's case, the key space of this 
protocol is essentially the full 56 bits that single DES allows; this is 
probably an acceptable length for most purposes (although future dialects 
may use triple-DES for more assurance). However, it is still subject to 
the same chosen plaintext and dictionary attacks as LANMAN 2.1 
challenge/response if passwords are badly chosen. The only cure is to 
make sure that passwords are well-chosen, and long enough to have at 
least 56 bits of randomness.

Other considerations:
o Transforming the password into Unicode leaves a pattern of alternating 
zeros and characters in the input to MD4.  This may allow MD4 to be 
reversed much more easily, although there is currently no known way to 
exploit this.
o MD4 is known to be weak with respect to collisions.  There may be a way 
to exploit this to attack its one-wayness, or to exploit the collision 
properties to limit key search time, although there is currently no known 
way to do so.

8.5 Other attacks

8.5.1 Hijack connections
Any attacker that can inject packets into the network that appear to the 
server to be coming from a particular client, can hijack that client's 
connection. Once a connection is set up and the client has authenticated, 
subsequent packets are not authenticated, so the attacker can inject 
requests to read, write, or delete files to which the client has access. 
Doing so require that the injected packets have the right transport level 
sequence numbers, which can be tricky, especially if the client is 
sending packets at the same time. It is significantly more difficult to 
hijack a connection than to eavesdrop, and doing so only permits the 
attacker to access files as the client for the duration of the session.

8.5.2 Downgrade attack
A "man-in-the-middle" can remove the bit in the SMB_COM_NEGPROT response 
that says the server supports challenge/response, thus fooling a client 
into thinking that it should supply a plaintext password. This attack can 
be mitigated if clients are able to be configured to require 
challenge/response, either in general or for particular servers.

------------
THIS IS A BIG WEAKNESS
------------

8.5.3 Spoofing by Counterfeit Servers
A counterfeit server is one that spoofs the DNS name resolution process 
so that the client gets the counterfeit's IP address instead of the 
genuine server's IP address, thus fooling the client into connecting to 
the counterfeit while believing it is connecting to the genuine server. 
Counterfeit servers are not detectable by the challenge/response 
authentication mechanism, which only authenticates clients. A counterfeit 
server can use the downgrade attack above to obtain a client's password; 
it can also execute a denial of service attack by denying the client's 
requests or returning bogus results. Counterfeit server attacks can be 
mitigated by deployment of DNSSEC.

8.5.4 Storing Passwords Safely
The passwords used in any of the authentication mechanisms used by this 
protocol have to be protected from access from over the network and from 
physical access. If the server does not support access control at the 
individual file level, but only at the file tree level, then password 
files can not be placed in a file tree that is accessible from the 
network, as all files in such a tree have to be at least equally readable.

================

I guess this inspires some code writing from folks @ dis.org and 
10pht.com.  I have a funny feeling that we will see a slew of NT hacks in 
the near future.

Nachos