75470.3414@CompuServe.COM (Suzanne Villemaire) (04/27/91)
What's a good way to make a back door for a netware 386 v.3.1 single server lan. Distribution: Novell Newsgroup >internet:comp-sys-novell@ucbvax.berkeley.edu Novell Listserver >internet:novell@suvm.acs.syr.edu Novell Data Comm Conf. >internet:comp-dcom-lans@ucbvax.berkeley.edu
jeffd@csd4.csd.uwm.edu (Jeffrey Alan Ding) (04/27/91)
In article <"910426181402.75470.3414.EHL28-1"@CompuServe.COM> 75470.3414@CompuServe.COM (Suzanne Villemaire) writes: >What's a good way to make a back door for a netware 386 v.3.1 single >server lan. > Add Supervisor to the managed users or groups field for your name. That way, you can make yourself a supervisor any time you want. I also don't think the security program picks it up. The v2.15 security doesn't. This trick works even better with v2.15 because the current v2.15 that has been shipping doesn't include a syscon that uses the work group manager stuff. Of course, you have to be supervisor in the first place to do what I suggest. But if you ever subsequently lose supervisor privilage, there is your quick back door. I know this trick works with v2.15 but it would be interesting to see it also works with 3.11. I don't have 3.11 so anyone out there want to try it out? This is a grave bug in security if you ask me, cause nothing reveals it and the only way you can find out is to look at every user individually. jeffd@csd4.csd.uwm.edu
douglas@wybbs.mi.org (Douglas Mason) (04/30/91)
In article <"910426181402.75470.3414.EHL28-1"@CompuServe.COM> 75470.3414@CompuServe.COM (Suzanne Villemaire) writes: >What's a good way to make a back door for a netware 386 v.3.1 single >server lan. > Leave the supervisor account unpassworded. Tie a trip-wire to the power switch of the server. Log in as supervisor and never log out. Mirror the server from a remote async 2400 line and then change the passwords and swap servers during the night. Post a message on your favorite hacker BBS and say "A Zillion dollars to anyone that can break into this new, secure system running Unix version XXXIV." Geeze.
keith@ca.excelan.com (Keith Brown) (05/08/91)
The News Manager) Nntp-Posting-Host: ca Reply-To: keith@ca.excelan.com (Keith Brown) Organization: Novell, Inc. San Jose, California References: <"910426181402.75470.3414.EHL28-1"@CompuServe.COM> <11467@uwm.edu> Date: Tue, 30 Apr 1991 20:14:36 GMT In article <11467@uwm.edu> jeffd@csd4.csd.uwm.edu (Jeffrey Alan Ding) writes: >Add Supervisor to the managed users or groups field for your name. That >way, you can make yourself a supervisor any time you want. >......... >This is a grave bug in security if you ask me, cause nothing reveals it >and the only way you can find out is to look at every user individually. > Don't forget that you have to be SUPERVISOR (or equivalent) to add any managed users to an accounts flock so this is hardly a "grave bug in security". You are however correct in pointing out that the security checker should probably rat on users who have SUPERVISOR as a managed account. I'll suggest this internally and take the credit for having thought of it. Thanks..... :-) Keith - Keith Brown Phone: (408) 473 8308 Novell San Jose Development Centre Fax: (408) 433 0775 2180 Fortune Dr, San Jose, California 95131 Net: keith@novell.COM
tony@mantis.co.uk (Tony Lezard) (05/09/91)
keith@ca.excelan.com (Keith Brown) writes: > In article <11467@uwm.edu> jeffd@csd4.csd.uwm.edu (Jeffrey Alan Ding) writes: > >Add Supervisor to the managed users or groups field for your name. That > >way, you can make yourself a supervisor any time you want. > >......... > >This is a grave bug in security if you ask me, cause nothing reveals it > >and the only way you can find out is to look at every user individually. > > > > Don't forget that you have to be SUPERVISOR (or equivalent) to add any > managed users to an accounts flock so this is hardly a "grave bug in > security". You are however correct in pointing out that the security > checker should probably rat on users who have SUPERVISOR as a managed > account. It's worse than that. While security equivalences are non-transitive (ie. If A is security equivalent to SUPERVISOR and B is equivalent to A then B does not get supervisor rights) It is the case that If I manage someone who manages someone else then I can have access to the final person in the chain and have their rights. The chain of managers could be indefinitely long. Furthermore, the person at the end of the chain need not be SUPERVISOR itself but merely security equivalent. Thus SECURITY.EXE needs to be somewhat more sophisticated than might be expected. -- Tony Lezard <Lazy Rodent>. E-mail: tony@mantis.co.uk, Snail: Mantis Consultants, Unit 56, St. John's Innovation Centre, Cambridge, CB4 4WS, UK.