		Windows NT Network Monitor Exploitation

		         NetMon Encryption Hammer
			
   		    by the Angel and Route (the Demon) 
			   for Phrack Magazine
		     May 1996 Guild productions, kid

		     comments to daemon9@netcom.com

	   Full exploit including binary dll's and execuatables:
    ftp.infonexus.com/pub/TooldOfTheTrade/Windows/NT/netMonExploit.tgz 


	[The intro]

	The Microsoft Network Monitor is a packet sniffer that runs under NT.  
It is a very robust and versatile packet sniffer, offering much more then
simple ethernet frame capturing.  It packs a robust capture/display filter
language, powerful protocol parsers, and one snappy GUI.  NetMon is 
delivered as part of the SMS package.  The user portion of the program 
calls upon the services of the Network Monitor Agent, which is a kernel driver
that ships with NT (3.5.x for sure, but I don't know about 3.1).  The Network 
Monitor Agent also provides an interface for a remote machine to connect and 
capture local data, provided it passes authentication. To restrict access, 
Network Monitor Agent utilizes a password authentication scheme.  Access has 
two tiers: priviledge to view previously captured sessions, and priviledge to 
actually use the sniffer to place the ethernet card in promiscuous mode.  The 
acutal encrypted password is stored as a 32-byte binary string in a 
dynamically linked library file called BHSUPP.DLL.  We have written code to 
extract this password from the dll and decyrpt it; we have broken the 
Microsoft Network Monitor password authentication system.


	[The low-down]

	The encrypted string is kept as binary data in: 
%SystemRoot%\system32\BHSUPP.DLL (in a default installation at least). 
BHSUPP.DLL is known to be different sizes between versions, so we cannot look 
for the encrypted string at a specific offset each time.  Instead we must 
search for a flag, and seek 32-bytes past this flag.  The flag is the 16-byte
string: "RTSS&G--BEGIN--".  (As a matter of note, there is a terminating 
footer also: "RTSS&G--END--".)


	[The encrypted truth]

	It is a simple encryption function, that takes random length string 
and returns 256-bit encrypted output.  It may appear to be a hash, rather 
than a block cipher, but it is not.  It does take a random length input,
and produce a fixed output, but the input is always padded to 32-bytes
(with nulls if necessary).  The input to the function is a user defined
arbitrary string.  The input is truncated to 16 bytes and then to pad 
out the array, the whole original password string is concatenated  on the 
truncated version, starting at the 16th byte.  It doesn't matter if the
resulting string is longer than 32 bytes, as the cipher ignores anything
past the 32nd byte.  So: "loveKillsTheDemon" becomes: "loveKillsTheDemo" 
and then: "loveKillsTheDemoloveKillsTheDemon".  If your password is  
smaller than 16  bytes, we get the 'hole-in-password' phenomena.  Since 
the array is intialized will nulls, and the password is still folded over to 
the 16th byte, these nulls remain.  This is easily visible from the first line
of output in our exploit code.  It also accepts empty password strings 
readily, without choking, which all Microsoft products seem willing to do all 
to easily.

	[The algorithm]

	The 32-byte string is put through 32 rounds of identical operations.
The outer for loop controls the value of the byte to be XORed with the
entire array that round (except for itself, see below).  The inner loop steps
through the entire byte array.  Each byte is permuted a total of 31 times 
(The discrepency comes from the test case where i must not be equal to j in 
order for a character to be permuted.  It would make no sense to XOR a byte 
with itself).  So, there are a total of 992 operations.  The actual 
encryption algorithm is quite simple:

In C:			if(i!=j)mix[j]^=mix[i]+(i^j)+j;

In English:		if i is NOT equal to j, the j indexed char of mix is 
			assigned the value of the j indexed char of mix XORed 
			with the i indexed char of mix PLUS i XORed with j 
			PLUS j.

Mathematically:		1) i ^ j = k
			2) k + j = l
			3) l + mix[i] = m
			4) m ^ mix[j] = x

			OR

			((i ^ j) + j + mix[i]) ^ mix[j] = x 


	The methods used for obscurity are exclusive OR (XOR) and binary 
addition, (see the appendix if you are umfamiliar with these bitwise 
operations) with completely known vectors.  The only unknown in the whole 
equation is the user entered password, fleshed out to 32-bytes.  These 32
bytes are taken through 32 rounds of permutations.  Simple and concise, 
with no key material dropped, this algorithm is not lossy.  Since it is not 
lossy it is 100% reversible, both in theory and practice.  In fact, since we 
know the values of the counters i and j, throughout the entire encryption 
process, decryption is simply a matter of reproducing these values in the 
proper order.  Since the output of the encryption process is the input, 
taken through 32 rounds of identical permutations, with known vectors, 
we simply need to reverse this process.

	[The code]

	There are two versions of the exploit available.  A Windows NT version
and, for those of you without access to an expensive NT-native compiler, 
there is a Unix version as well.  The NT version is a console-based app, as
GUI code would be a waste of time.  The full package of this exploit, along
with an NT exexcutable and sample DLL's is avaialble from:
    ftp.infonexus.com/pub/TooldOfTheTrade/Windows/NT/netMonExploit.tgz 


	[The discussion]

	The ramifications of this weak encryption in Network Monitor Agent are 
many.  First off, the developers of Network Monitor Agent *didn't* use the 
standard security mechanisms of Windows NT.  This may be because the driver is
a kernel mode driver, and in NT the kernel is a trusted enity, therefore 
the standard security API (of Win32) does not apply in the kernel making it 
harder to do user authentication.  It also appears that they were trying to 
achieve a mechanism based not on priviledge, but on knowledge.  It is very 
likely that in secured environment not all administrators should be able to 
sniff the network.  The problem is they did a *poor* job of securing a 
powerful utility.
	The most straight forward attack is use Network Monitor to sniff the 
network (where you weren't suppose to be able to) for priviledged user data or
passwords in a heterogeneous environment (since native NT networking does not 
send password information in the clear, but standard TCP traffic from Unix
is sent clear).  The rest of the attacks would come from shabby administration
, such as the administrator used the password for the admin account and the 
capture password in Network Monitor Agent (stupid, but likely) or the 
same password for Network Monitor Agent on all machines across the network.
	In order to use the exploit utility, one must have read priviledge for 
BHSUPP.DLL which is installed into %SystemRoot%\system32 by default.  This 
is not a remote attack, but rather a stepping stone to gain priviledged 
information when one is under-priviledged.

	[The moral]

	Time and time again we see either shody implementations of trusted
algorithms, or, like in this case, just plain bad cryptography.  Under ITAR,
most secure cryptographic algorithms are classified as munitions, and are not
exportable from this country.  The funny thing is, under current law, one-way
hashing functions are *not* restricted (that is why all Unix variants can ship
with the standard crypt(3) libraries and executables).  This authentication
scheme could have *easily* been replaced by MD5, the same one-way hash used
by PGP.  At least then, the complexity of an attack would be increased to
a brute-force known-plaintext sweep of key values...



	[The appendix]

	For the binary-declined...

Exclusive OR

The XOR operation is a bitwise operation with the following truth table:

	XOR| 1 | 0 |		The Exclusive OR operation simply says:
	-------------		"...Hmmm, if I have a 1 and a 0, I'll spit
	1  | 0 | 1 | 		out a 1.  Anything else, a 0..."
	-------------
	0  | 1 | 0 |


Binary addition

Binary addition is analogous to base10 addition.  However, each place holds
2^n instead of 10^n...

	add| 1 | 0 | 		base10:		base2:
	-------------		    11            1011
	1  |1 0| 1 | 		   + 5          + 0101
	-------------              ---          ------
	0  | 1 | 0 |                16		 10000




This exploit made possbile by a grant from the Guild corporation.

- May 07, 1996 route/angel
