From: rfranken@mcs213i.cs.umr.edu (Richard Brett Frankenberger)
Subject: Re: Protection from KNOCK.EXE
Date: Sun, 27 Sep 1992 03:14:05 GMT
Organization: University of Missouri - Rolla
Keywords: Protection, KNOCK, security

In article <1992Sep27.022437.238@usl.edu> jmfres11@ucs.usl.edu (Karthikeyan Gurnswamy) writes:
>In article <1992Sep25.235605.7537@umr.edu> rfranken@mcs213e.cs.umr.edu (Richard Brett Frankenberger) writes:
>>In article <1992Sep25.212613.5640@usl.edu> jmfres11@ucs.usl.edu (Karthikeyan Gurnswamy) writes:
>>>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.
>> 
>>(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
>
>Sorry - Changing the MAC address on the fly will not help you to get into
>supervisor mode. The reason is - the client and server are state driven
>that is maintains tables and numbers in NET3 (Please refer to old articles
>on Netware Techincal Journals on 'Cracking the NET3' shell..) and just
>rerouting packets to a new station will not work at all. (a) and (b) do
>guarantee 100 % reliability !
>
>Karthik
>| Karthikeyan Guruswamy                  |                          |
>| Email: jmfres11@ucs.usl.edu            |                          |

First, I said that (a) and (b) will not prevent KNOCK.EXE from working, which
use an older flaw (which has many other solutions, including patches for older
versions of netware, and it doesn't exist on newer versions).
 
I curious what your NETx shell could possible know that my snooper / MAC changer
program could not know.  I do not know all the details of how the NETx works, 
and if the states are sufficiently complicated, it may be necessary for me to 
monitor the session for a long time to determine exactly what state it is in.
It may even be necessary for me to monitor the ENTIRE session to know, and it
may be impossible for me to get in if I don't start my monitor before the
supevisor station first runs NETx (although I doubt it).  However, If I monitor
the entire session, I shouldn't have much trouble.  
 
(I am aware that there are public/private key encryption algorithms that make
it impossible for a snooper to determine whe values of all the tables in either
the client or server just by monitoring the converstaion.  NETx does, to my
knowledge, NOT use any of these).
 
I should also mention that it appears that neither of us works for Novell
(I certainly don't) and so we are having a hypothetical discussion here because
all the details of this new flaw are not being made public.  If they were made
public, then we would know EXACTLY what it would take to get in.  Is it
essential to montior the ENTIRE converstaion between NETx and the server to
break in? If so, it may be beneficial to remain logged in as supervisor
all the time (of course, there are lots of reasons not to remain logged in all
the time).  The point is that  system administrators are being hampered
here by our limited understanding of the loophole.  

       - Brett    (rfranken@cs.umr.edu)

Newsgroups: comp.sys.novell,comp.protocols.tcp-ip.ibmpc