X-Envelope-to: NOVELL@SUVM.BITNET
X-VMS-To: IN%"NOVELL@SUVM.BITNET"
X-VMS-Cc: JRD
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Newsgroups: bit.listserv.novell
Date:         Fri, 2 Oct 1992 19:52:02 -0600
Reply-To:     Novell LAN Interest Group <NOVELL@SUVM.BITNET>
From:         Joe Doupnik <JRD@USU.BITNET>
Subject:      Re: Some questions about the Dutch NGN security problem.

>I think I understand the theory behind the security problem the Dutch NGN
>group found.  I want to see what others think about the following:
>
>Basic theory:  The thief waits until a supervisor or other targetted
> user is logged on.  They then fake a request at a very low network
> level from the user to tell the server to grant them various authorities.
> E.g., set an account to supervisor status or change directory access rights.
>
>Some Assumptions:
>
>1) The thief must be on the same subnet or a subnet between the targetted
>   user and server.  This is so packets from the target can be examined.
>   Also, there may be problems sending fake packets across Novell routers
>   (then again, IPX is "connectionless" and this may not be a problem).
>
>Is this true?  If so, that means that subnet physical security could help
>greatly.  (Doesn't solve the problem, just helps keep out the only slightly
>dishonest folks).
        No, it's not true, alas. It is possible to pull this trick from
another segment (on the other side of a NW router). We think NW should
do stronger checks in this area.

>2) Since, the break in consists of granting more authority, the thief
>   needs an existing account for most things.  However, they could possibly
>   change a logged in user's password to gain access.  But changing it
>   back would be impossible so the theft would be obvious.  Also, if the
>   supervisor was logged on, the thief could possibly create an id to
>   gain access.
>
>I guess the question here is how much can a packet-faker get away with
>undetected?  In other words, if the server needs to respond to the request,
>would the actual user would see the response and be alerted?  What are the
>limits to security changes by fake packets?

        Depending on what's done the real supervisor can be unaware of the
intrusion, but I won't discuss how. The intrusion is, as you say, normally
one of gaining priviledges or extracting some vital piece of information.
These operations are short network events and can slip past. The catcher
is Bart Mellink's SHOWEV.ZIP material which logs changes to the bindery,
where the most interesting things are stored. It is a post-facto situation
but better than not knowing. Couple this with the accouting log and one can
usually pin down a station producing the anomoly.
        The current recommendation on hack (the name of the latest item)
is to not use supervisor or equivalent until really needed, then go back
to peon status when done. This way an intrusion is to an ordinary priv level
and nothing very disasterous will happen.
        Fake packets can be deadly things. My loose thinking is when a
sensitive command is issued then the server should request confirmation,
and then check carefully for more than one response (and of course for
a "not me" reply too). This is a three way handshake in the network jargon:
client says "#S, do this, I'm #C", server says "did #C just ask for something
special?, reply to #S", client responds "I'm #C and yes I did, thanks #S.
What's more it is the last thing I said so you are probably responding to
my request." Server pauses for 100's of millisec or more to get all possible
replies then executes. A real client will say no if the request originated
with an intruder. A second level can be applied on really sensitive things,
though protection does not double. Lost/repeated packets need to be accomodated
gracefully here, with a do-only-once criterion applied to the transaction.
        Btw, the Dutch group developing hack has just passed my threshold
for respectability, going down. A person in that group went on News with
enough information to let the third rate crazies develop hacks. Until today
I thought they had controlled things. No more. This is unacceptable behavior.

>If we are to properly assess our risks, we need enough information to have
>a valid model.  After all, a totally secure system with easy access is
>currently only a dream, like the burglar proof house.  What we can do
>is to properly assess the risks and take appropriate actions to achieve
>the best balance for our particula situation between ease of use and security.
>
>Greg Monroe  <Monroe@DukeFSB.BitNet>
>Duke's Fuqua School of Business
>Durham, NC  27708-0114
        Well, let me add another risk. Some utilities which access servers
do so with unencrypted passwords. Novell sells the encryption code for shells
but these pgms don't use it. Thus eavesdropping can yield not only passwords
but the contents of sessions. This is the oldest insecurity in the business
and can't be detected easily at all. Bridges can help isolate sensitive
traffic, routers are even better. This aspect is causing some of us to have
a careful look at Kerberos style operations, despite the awkwardness of it,
because all the traffic is encrypted.
        Joe D.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU