From: rfranken@mcs213e.cs.umr.edu (Richard Brett Frankenberger)
Subject: Re: Protection from KNOCK.EXE
Date: Fri, 25 Sep 1992 23:56:05 GMT
Organization: University of Missouri - Rolla
Keywords: Protection, KNOCK, security

In article <1992Sep25.212613.5640@usl.edu> jmfres11@ucs.usl.edu (Karthikeyan Gurnswamy) writes:
>Hi Netters!,
>
>Some ways to save your network from KNOCK.EXE (Netware 3.x ) are:
>(a) Limit the concurrent logins to 1 for the supervisor. Login in
>as supervisor on your pet node. Lock the computer when you get out.
>(b) Station restrictions: Make sure that the supervisor can login from
>some node x and you have the room or computer key.
>
>***  Don't ever logout from this node...
> 
>In the above cases, it will work with unencrypted passwords.
>Snooping password packets will not help because the server will not
>allow more than one login and no program on earth can crack this
>setup. Programs retrying with password combinations will not work
>even if it gets the password - You don't even need INTRUDER DETECTION.
>
>For 2.x and 3.x: 
>Here's one more way to save yourself from programs like KNOCK.EXE snooping
>packets. Well, I haven't looked through the binary myself, but assuming
>it snoops - Create a user who has got a security equivalence of
>SUPERVISOR and use only that to login. NEVER-EVER login as supervisor.
>Might work. It'll never see the name SUPERVISOR on any NCP packet
>going around. 
>
>| Karthikeyan Guruswamy                  |                          |
>| Email: jmfres11@ucs.usl.edu            |                          |
>

Not to beat this topic to death, but some things need clarification here:
 
(1) KNOCK.EXE works to exploit a bug whereby logging in with no password will
sometimes let you in on certain versions of Netware.  (nuff said - this
hole has been discussed at length in the past.)  It does NOT snoop the network
at all.
 
(2) The (a) and (b) do not guarantee 100% that KNOCK.EXE will not work.  First,
the MAC address (and thus the IPX address) of a workstation can be changed.
On token ring , quite easily, using parameters documented in Novell's ODI  
manual; and I'm told its not too tought to do on E-Net either, although I use
TR only.  In many cases, you can log out the supervisor from his first
connection simply by bringing up a second PC with the same MAC address.
(Token-Ring fans: this can be done quite easily on Token-Ring - it is not hard
to defeat the duplicate address check during insertion, and there is no such
check on E-Net).
 
(3) It was my understanding that this latest loophole was not snooping on the
wire for passwords (which has been around just about forever) but involved 
finding a workstation logged on a supervisor (or supervisor equivalent) and
then changing your MAC address to that address and sending a packet to the
server that looked like a packet from him (harder to do than it sounds -
I believe Novell has some checks to prevent this, but that listening to a
server/workstation converstaion on the wire for long enough will give you
sufficient info to get around this).  If a administrator wanted to make this
harder, he could never log on as supervisor, but then all the snooper would
have to do is find out what Id the supervisor was using (it would probably
be the ID that was making SUPERVISOR type calls to the server (add user,
change rights, etc.)).  Of course, this is not easy to implement, but neither
is the original way of trying to emulate the supervisor workstation.
 
     - Brett   (rfranken@cs.umr.edu)