From: vermeulen@rulwinw.LeidenUniv.nl (Hans Vermeulen)
Subject: Re: Leak in Novell: the sequel of the sequel
Keywords: Novell, HACK.EXE from Leiden
Organization: Department of Mathematics and Computer Science, University of Leiden
Date: Fri, 2 Oct 92 17:10:55 GMT

In article <jph.11@cc.ruu.nl> jph@cc.ruu.nl (Peter Hasperhoven) writes:
>From: jph@cc.ruu.nl (Peter Hasperhoven)
>Subject: Re: Leak in Novell
>Date: 2 Oct 92 09:08:20 GMT

>In article <1992Sep30.001353.17355@umr.edu> rfranken@mcs213i.cs.umr.edu (Richard Brett Frankenberger) writes:

>>So, assuming that this method does not invole monitoring the network, and
>>that it likely doesn't involve changing the MAC address (which would likely
>>also make it hardware dependant), does anyone have any idea how it works?
>>I'm not interesting in seeing HACK.EXE posted (I don't see anything wrong
>>with posting it, I just don't have any use for it), but I would like details
>>on how it works so that I can determine for myself exactly what the risk to
>>my servers is (Novell says that I can fix everything with an NLM, but Novell
>>also told me I had a secure operating system (and essentially it is - most 
>>loopholes are design flaws - KNOCK.EXE being one exception) in the first place).
>>It appears to me that this program gets the connection number and MAC address
>>of a SUPERVISOR connection (not difficult - just use the same calls that
>>USERLIST /A uses), and with that information sends a packet to the server
>>that looks like tit came from the SUPERVISOR workstation (although 
>>apparently not 100% just like it, as Novell's new security NLM can detect
>>the problem).  I'm curious specifically (1) What information the hacking 
>>workstation must have to get in (is Connection number and MAC address
>>sufficient), and (2) Does the hacking workstation HAVE to change its MAC
>>address to the MAC address of the SUPERVISOR workstation (or can it send
>>a packet from its MAC address with a FROM field in the IPX frame with the
>>Supervisors MAC address).  I tend to think the answers are, respectively,
>>YES and NO, as at appears the program works with only IPX calls (because he
>>said it only requires that IPX be loaded, and implied that it will work
>>over topoligies other than E-Net and TR (but that it had only been tested on
>>those two).  (But I could VERY EASILY be wrong - I don't have any of this
>>information because too many people here seem to believe that telling System
>>Administrators will let all the Hacker/Crackers in on the secret, never mind
>>that many of them probably already have HACK.EXE and are happily hacking into 
>>our servers already.  Novell did well in releasing its NLM, but I still would
>>like to know exactly what the problem is that I am fixing.  When I take my car
>>into the garage, I don't say fix it, then leave and come back when its done, I
>>also ask exactly what was wrong.  This is NOT intended as a flame, and I 
>>respect everyone's opinion, but I think this information would benefit
>>everyone.)    
>From the bits and pieces of information I found, this is the idea:
>The hacker fakes an IPX-packet with the SUPERVISOR connections number (or 
>any other user for that matter) in the header. The data in the packet is a 
>command to give the hacker, which is probably logged in as GUEST, trustee-
>rights on a volume of choice. This is fairly easy. I don't think the MAC-
>address has to be faked, but I'm not sure. 
>The only problem is sequence numbers. Every IPX-packet has a sequence-number 
>between 0 and 255 so server and staion can check and restore the order in 
>which packets are sent/recieved. The program has no way of finding out the 
>next sequence-number the server expects so it fires 256 packets with all 
>possible sequence-numbers at the server.
>This is the part that the Novell-fix uses. If it finds any out-of-sequence 
>packets, it sends a message to all stations and disconnects the offending 
>user. This is bad because there are a lot of perfectly legitimate reasons to 
>lose a packet somewhere. The people who installed the fix all reported 
>random disconnects of legitimate users. And when you get too many false 
>alarms, you neglect all alarms. In other words, you unload the fix.
>Besides this problem, within several hours after the release of this patch, 
>it got defeated again by two editors of LAN-magazine in the Netherlands. 
>They seem to use a somewhat different technique because they make the GUEST-
>user SUPERVISOR-equivalent. They told Novell about this and will not 
>disclose the program or techniques used. But still, they're not the only 
>ones who can find this out.
>All these have in common that the hacker and the SUPERVISOR need to be 
>logged in at the same time. So, while waiting for yet another fix, the 
>things to do are:
>- Get your regular users security tight. No GUEST-account and such.
>- Login as SUPERVISOR only when and as long as necessary.
>- On 3.11 load SHOWEVNT.NLM by Bart Mellink. This doesn't close the gap, but 
>it reports changes in the bindery and you can see if you have been hacked. 
>It's on novftp.rc.rug.nl in /nlm.

>Peter
	
You are quite right. The next version of HACK.EXE knows about the
sequence number and will send one (repeat: one) (the correct) packet
to the server. So the patch SECURE.ZIP by Novell will be useless ....

On behalf of the developer,

Hans Vermeulen.



Mr W.A. van Spronsen
Leiden University
Dep. of Computer Science
P.O. Box 9512
NL2300RA Leiden
The Netherlands
email: vspronsen@rulwinw.leidenuniv.nl
Newsgroups: comp.sys.novell