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

In article <1992Oct1.181307.13152@umr.edu> rfranken@mcs213i.cs.umr.edu (Richard Brett Frankenberger) writes:
>From: rfranken@mcs213i.cs.umr.edu (Richard Brett Frankenberger)
>Subject: Re: Leak in Novell
>Date: 1 Oct 92 18:13:07 GMT

>In article <SKLEPZI.1.0@SSB1.SAFF.UTAH.EDU> SKLEPZI@SSB1.SAFF.UTAH.EDU (Steven Klepzig) writes:
>>There has been and most likely will be alot of heat on this subject; whether 
>>or not hacks into systems should be publically posted, vendor 
>>responsibilities for notification and fixing, etc, etc, etc.
>>
>>For what I consider to be an excellent example of how this sort of thing 
>>should be handled please check in on comp.virus.  The discussions of virii 
>>are quite frank and open and honest - but NO virus code is posted.  By all 
>>means problems and (hopefully) solutions should and must be discussed.  
>>Novell needs to respond, both with band aids and more permanent solutions.  
>>But to post hacks into systems to a public list is the same as posting virus 
>>infected files and saying "here's a Stoned infected file for your inspection 
>>and infection pleasure".
>>
>>I want to know the details of holes in my system, what they are, what they 
>>do, and how to stop them.  I don't want to see the code that exploites them 
>>made publically accessable.
>>
>>Steven (sklepzi@ssb1.saff.utah.edu)

>I agree totally.  I never said I wanted HACK.EXE posted (I just said I would
>not have any objections if it was).  
> 
>I feel novell has NOT given us a good explanation of the security hole that
>HACK.EXE exploits, and I am not convinced that their patches are 100 percent
>effective.  I would like to see a complete description of how HACK.EXE
>works and what it does (if the only way to do this is to give out enough 
>details to allow anyone with the Netware c libs to write their own HACK.EXE,
>so be it.  Most hackers that sophisticated probably have enough sources
>or connections that they can get HACK.EXE anyway.).
> 
>I would like to see someone (preferably someone from Novell with
>technical background) provide us with more details, and specifically,
>confirm or deny the hypothesis that I will state below.  I do not consider
>NO IT IS NOT TURE to be acceptable.  If I am wrong, tell be where I went
>wrong, and provide an alternate means of how HACK.EXE works or how
>the secuirty patches work.  Remember, NOVELL itself told us that we could
>protect ourselves from KNOCK.EXE by enabling intruder lock-out, and as most
>are now aware, that is absolutely not the case.
> 
>THE FOLLOWING IS MY HYPOTHESIS ABOUT HOW HACK.EXE WORKS AND HOW THE PATCHES
>FROM NOVELL WORK TO STOP IT.  IT IS NOT 100% FACTUAL, AND IT MAY NOT BE
>TRUE.  PLEASE, NO ONE START SPREADING RUMORS THAT THE PATCHES DO NOT
>WORK UNTIL SOMEONE KNOWS FOR SURE.  I believe there is a good chance that
>I am correct, but I do not have sufficient information to be sure.
> 
>I believe that hack needs several pieces of information to successfully
>send a packet that appears to have come from another workstation. I believe
>that some of this information is readily available to anyone on the server
>(regardless of their access privileges)).  This would include, connection
>number, MAC address, etc.  (anyone can see it with USERLIST /A and HACK.EXE
>could make the same calls that userlist makes). I also think that some of the
>information that it requires, specifically, something I will call a
>"secret number" is NOT AVAILABLE.  

>So, my hypothesis is that HACK.EXE takes a guess as to what the secret number
>might be, and tries to send a packet that appears to have come from
>the workstation it wants to emulate.  The odds of this working are small,
>because its guess of the secret number is probably not correct.  So it
>tries a new secret number, repeating this until it works.  
> 
>I think that the patches from Novell detect packets with an invalid
>secret number, and clear the connection that they appeared to come from.  Once
>that connection is cleared, HACK.EXE can no longer try to emulate packets from
>it.
> 
>For example, If I try to emulate connection #2 (say, for example, I am #3),
>my first try will probably have an invalid "secret number" and so the server
>will detect a packet (that appeared to be) from Connection #2, with an invalid
>secret number.  Instead of ignoring the packet (like I think it normally
>does), the patch clears connection #2.  My attempt has been foiled, as I
>can no longer try to send a pakcet that looks like it came from connection 2,
>becasue there is no connection 2.
> 
>WHAT IF HACK.EXE seceeded in guessing the correct secret number on its first
>try.  If my hypotheses above are correct, that the patches would not detect
>this, and HACK.EXE would succeed.  
> 
>So, assuming that the secret number is a 16-bit number (I doubt it is much
>larger, because otherwise HACK.EXE would take a long time to run - it 
>would have to try (if the number were 32 bits) 4 billion combinations, and
>that would take a very long time), then HACK.EXE will suceed even with the
>patches loaded once in every 65536 tries.  Personally, I'm willing
>to live with those odds, but I would like to know if this is correct
>or not. 
> 
>So, can anyone confirm or deny this theory (with more than a simple YES or NO).
> 
>AGAIN, There is no guarantee that this is correct.  Please don't get all
>excited about another secuirty flaw, or start spreading this around, until
>it is confirmed or denied.
> 
>     - Brett    (rfranken@cs.umr.edu)

You are very close. It is 8 bits instead of 16/32 ...
On behalf of the developer of HACK.EXE,

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