Path: alphanet.ch!imp.ch!news.imp.ch!rill.news.pipex.net!pipex!news-peer-east.sprintlink.net!news.sprintlink.net!nntp.abs.net!feed2.news.erols.com!erols!howland.erols.net!cs.utexas.edu!utnut!utcsri!dgp.toronto.edu!flaps
Newsgroups: alt.security,comp.security.misc,comp.security.unix
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: comp.security.unix and comp.security.misc frequently asked questions
X-Nntp-Posting-Host: explorer.dgp.toronto.edu
Message-ID: <1998May28.122113.29516@jarvis.cs.toronto.edu>
Followup-To: comp.security.unix,comp.security.misc
Summary: VERY frequently asked q's with straightforward answers
X-Newsreader: NN version 6.5.0 #3 (NOV)
Date: 28 May 98 16:21:14 GMT
Lines: 209
Xref: alphanet.ch comp.security.misc:29048 comp.security.unix:26950

Archive-name: comp-security-unix
Posting-frequency: monthly

This is the early stages of a faq file for comp.security.misc and
comp.security.unix.  It is cross-posted to alt.security because I think it
will be useful there, too.  Yes, I know that syntactically, these are not all
"questions".

------------------------------

Subject: Table of contents

- This faq

- Can anyone here tell me how to exploit the {whatever} bug?
  or Can anyone here tell me how to break in to my ISP?

- Is there a newer version of cops/tripwire/satan?

- Tripwire fails the self-test.

- Cops won't "make" in some recent versions of linux.

- SATAN doesn't display right in my web browser; it asks me to save the file.

- How do I find all setuid and setgid files?

- I can't get .rhosts/.shosts to work with ssh.
(Note: there is a newsgroup comp.security.ssh)

------------------------------

Subject: This faq

This is not supposed to be a statement of group consensus.  This is simply
supposed to be a few VERY frequently asked questions and their answers, so
that we can snidely say "see the faq" when people ask them.  The answers
supplied are supposed to be completely uncontroversial amongst people who know
what they're talking about.  My first answer might be a bit borderline in this
respect but I don't recall ever having seen a contrary opinion here.

Contributions of questions are welcome (with or without answers); however, the
idea is that they are supposed to be things we see very frequently, and things
which have straightforward answers.  If your answer is long, it might not
belong in this document, at least as I see the purpose of this document.
For example, it is intentional that this document doesn't contain firewall
recommendations, even though that's a frequently-asked question here.

Thanks to Juan Gallego and Lamont Granquist for additional suggestions re
finding setuid files.

Disclaimer: The posting of this file is not to be construed as a commitment to
provide free consulting to people I don't know.  Post your questions to the
newsgroup and I might answer them there, or someone else might do it better.
(Although if you say "please send e-mail copies", I'm going to ignore your
message.)

Disclaimer 2: There ARE errors in this file, but at the time of writing, I
didn't know what they were.  (If I knew, I would have fixed them.)  This
document is offered on an "as-is" basis, no warranty is implied, blah blah blah.

------------------------------

Subject: Can anyone here tell me how to exploit the {whatever} bug?
	or Can anyone here tell me how to break in to my ISP?

No.  We're security professionals.  We try to secure systems.  We think that
securing systems and fixing bugs are more intellectual activities than running
a program which someone else wrote which you don't understand.

You should only attempt "penetration testing" of a system with the consent
of its administrators and/or owners.  They will only be interested in your
services if you know something.  You can start your education by learning
some general computer science and computer programming, and by reading
computer security textbooks and/or newsgroups.

------------------------------

Subject: Is there a newer version of cops/tripwire/satan?

No.

------------------------------

Subject: Tripwire fails the self-test.

You have to slow it down (just the self-test scripts, not the tripwire binary
itself).  The test scripts create and then update a file, and then detect that
the timestamp has not changed.  Because it hasn't, because this all happens
within a second on modern machines.  This happens in a few places.  If a
second-boundary happens to be crossed during this brief interval, then that
particular test will succeed, but another one will fail soon.

In the tests directory, edit 3 of the 4 files named test.*.sh:
in test.escape.sh, add "sleep 1" on line 46 (in the cert version), just before
running tripwire; in inter and update, un-comment-out the "sleep 1".
If this isn't good enough, use "sleep 2".  See
ftp://coast.cs.purdue.edu/pub/COAST/Tripwire/README-fix-Oct.1996

------------------------------

Subject: Cops won't "make" in some recent versions of linux.

Remove the '#' from "BRAINDEADFLAGS" in the makefile.
(This adds a "-lcrypt" to the compilation of pass.c.)

------------------------------

Subject: SATAN doesn't display right in my web browser; it asks me to save
	the file.

Newer web browsers seem to use different algorithms in guessing mime types
when the web server doesn't supply it.  SATAN does not comply with the http
protocol in this one respect, but it's easily fixed.

Add, in perl/html.pl, in process_html_request before it sends anything
(actually I see I put it just before the "Make sure they gave us the right
magic number"):

	#
	# ajr addition
	#
	print CLIENT <<EOF
HTTP/1.0 200 Document follows
Content-Type: text/html

EOF
;

Make sure you include the blank line; this separates the headers (just one,
here) from the content.

There's a bunch of bad advice out there about adding a handler with the ".pl"
suffix in your netscape preferences.
1) This is wrong.  What's relevant about the satan response is that it is
indeed html code, not the fact that the requesting URL ends in .pl.  A web cgi
URL might end in .pl but the program might return a gif.  I think that some
people have decided that mime types are annoying and just to be kludged over.
They're only right about e-mail mime types.  Http mime types have an entirely
different function and usefulness, even though they use the same type values.
2) This is dangerous (the version of the advice which says to set it to
execute the perl interpreter).  You don't want to execute arbitrary perl code
off the net.  It also won't work, because it's html code, not a perl program.

The recommendation to deactivate an existing ".pl" handler is ok, but the
above is better imho, certainly easier.

------------------------------

Subject: How do I find all setuid and setgid files?

find / -local -type f \( -perm -4000 -o -perm -2000 \) -print

or to do an "ls -l" of them:

find / -local -type f \( -perm -4000 -o -perm -2000 \) -exec ls -ld '{}' \;

You may want to add the "-u" option to ls to see last-accessed times rather
than last-modified times (esp to help gauge how harmful it would be to
unsetuid the file).

Some versions of "find" don't have the "-local" option.  Its purpose is to
avoid searching nfs volumes.  If you don't have any nfs mounts, you can omit
the "-local".  If you do, here are some other possibilities:
    * Some systems have "-xdev", which prevents find from traversing mounts.
      But then you have to run it for each local filesystem separately.
    * On some systems you can say "! -fstype nfs".
    * Do the check with nfs filesystems unmounted (e.g. single-user mode).
    * "ncheck -s" will tell you all setuid and setgid files, plus all device
      files (which is something of equal interest).  It too must be run
      separately for each filesystem.

Please note that this is insufficient if you suspect backdoors have been
installed on your system.  The backdoor installation activity could have
included modifying the "find" command.  The purpose of the above is to find
locally-installed or vendor-supplied security bugs waiting to happen, not to
find backdoors.

------------------------------

Subject: I can't get .rhosts/.shosts to work with ssh.

For .rhosts or .shosts (or hosts.equiv or shosts.equiv) to take effect with
ssh with the default configuration, a few less obvious things must be the case.
These are all good restrictions and the rationale is included here.

    * The request must be coming in from a "privileged port"; thus, the ssh
      client must be setuid.  Without this restriction, any user could
      masquerade (for the purposes of passwordless login) as any other on the
      same source machine.  (Even with it, root can; but there's no way to
      restrict THAT without the user typing something or involving a third
      machine (i.e. some hardware which root doesn't have access to).)

    * .rhosts or .shosts must be owned by the appropriate user and not be
      writable by group or others.  Sshd does not check for the situation of
      single-user groups common on some versions of unix these days (esp some
      versions of linux); you have to chmod g-w .rhosts/.shosts if your umask
      is 2.  (There is no way for sshd to detect the single-user group
      situation; current membership of size one doesn't tell you its history.)

    * The source host must be in /etc/ssh_known_hosts or
      ~user/.ssh/known_hosts on the target machine.
      This is the difference between "RhostsRSAAuthentication" (allowed by
      default) and "RhostsAuthentication" (disallowed by default).  Without
      this, ssh is not gaining you any login security, although it is still
      gaining you anti-sniffing security.

"ssh -v" is useful in debugging this kind of problem.  Take further questions
to comp.security.ssh.