From: jph@cc.ruu.nl (Peter Hasperhoven)
Newsgroups: comp.sys.novell
Subject: Re: Leak in Novell
Date: 2 Oct 92 09:08:20 GMT
Organization: Rijksuniversiteit Utrecht

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
Newsgroups: comp.sys.novell