Challenge yourself to get rid of insecure software.

[InfoSec News <isn () c4i org>]

+------------------------------------------------------------------+
|  Linux Security: Tips, Tricks, and Hackery                       |
|  Published by Onsight, Inc.                                      |
|                                                                  |
|  02-June-2003                                                    |
|  http://www.hackinglinuxexposed.com/articles/20030602.html       |
+------------------------------------------------------------------+

This issue sponsored by Gibraltar Software, Inc., your best source
for Secure Patch Management.

With Gibraltar Software's flagship security product, the Everguard
(tm) System, sysadmins can now run one tool to keep a network of
Linux, Windows, and Solaris machines completely patched and
up-to-date. Everguard 2.0 features remote deployment capabilities,
automated software discovery and tracking, centralized management, a
variety of reporting tools, and rated priority to patches. Everguard
2.0 is the most secure cross-platform patch management system
available today.

For more information, visit our website at http://www.dvpm.com/

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

Challenge yourself to get rid of insecure software.
By Brian Hatch

Summary: System setups that are known to be buggy can persist for far
too long unless you force yourself to take the time to revisit them
periodically.

I'm on a lot of mailing lists, including one for my local LUG (Linux
user's group) and tend to respond to a lot of questions from complete
strangers.[1] For some reason it seems that in the last few weeks
I've fielded an increased number of emails that I don't want to help
out on, for example

 1. "I can't get telnet to my machine - how can I disable the
    firewall?"
 2. "I can telnet fine, but not as root, I need to su. How can I let
    root log in from the network directly over telnet?"
 3. "I'm trying to change the password for a user, but it only let's
    me choose passwords that are longer than 4 characters, what's
    wrong?"

Each time I hear questions like this I take a deep breath. I know the
answers.[2] The problem is that they want to do things to which I
personally object, things that decrease the security of their
systems.

People like to use the tools they're familiar with. Retraining people
to do things in a new (more secure) way is very difficult. For
instance when I took over a cluster of SGIs years ago I installed SSH
across the board, but needed to leave telnet enabled for the PC users
who needed to be able to log in.[3] However even those with Unix
boxen on their desk, on which ssh was installed, didn't want to use
SSH. I'd even set up users with passwordless logins and host-based
trust across the machines. I noted the savings of three characters in
"ssh" vs "telnet". Nothing worked until I replaced /usr/bin/telnet
with a shell script that looked something like this:

  #!/bin/sh
  
  quit () {
          echo "glad you came to your senses."
          exit 0;
  }

  # If user specifies a port or no host at all, run real telnet binary.
  # Yes, this lets them type 'telnet host 23' - oh well.
  if [ $# -gt 1 ] ; then
          exec /usr/bin/telnet.real "$@"
  elif [ $# -eq 0 ] ; then
          exec /usr/bin/telnet.real
  fi
  
  # See if SSH is available on the target.  If not,
  # then invoke telnet.  (nc -z can be used as a poor man's port scan.)
  if ! `nc -z $1 22>/dev/null 2>&1` ; then
          echo running telnet - ssh not running
          exec /usr/bin/telnet.real "$@"
  fi

 
  # OK, they're using 'telnet hostname' to a machine that's running SSH.
  #
  # Forcibly instigate "worker retraining".

  echo "Are you sure you'd like to use telnet?"
  echo "We've installed SSH on this machine, which is much better."
  echo -n "use telnet anyway?  (yes/n)  "
  read a
  if [ "x$a" != "xyes" ] ;  then
          quit
  fi

  echo "Are you *really* sure you'd like to use telnet?"
  echo "SSH will encrypt your sessions.  That's good..."
  echo -n "Should I stop and let you ssh? (nothanks/y)  "
  read a
  if [ "x$a" != "xnothanks" ] ;  then
          quit
  fi
  
  ...
  # About three more yes/no questions, alternating the
  # response they must provide to make it harder.
  ...

  # give up, let them use telnet if they're so darned sure...
  exec /usr/bin/telnet.real "$@"

Everyone had become set in their ways. They were used to telnet, and
even though a more secure, robust, and in this case even easier
method was available, they wanted to stick to the old system.

Unfortunately, inertia is very common in any organisation. You need
to be sure to periodically question the methods your organisation
uses to do it's business. Any time you put functionality in place
that isn't the most secure thing in the world, make sure to revisit
it in three months time to see if there's a better way to do it
later.[4]

For example, say your software push system requires that the software
push account on the distribution server is able to rcp files to any
machine in the company. This was common back in the days before SSH.
The remote machines would trust connections coming from the IP
address of the dist server. However that meant any machine that could
steal the dist server's IP could connect to any other machine.
Nowadays you could mirror that functionality using SSH and it's
host-key based trust, or using SSH identities/pubkeys. Now someone
would need to compromise the actual server, not just knock it
offline.

Similarly, say you've got a webserver where people log in, fill out
forms, and the form data emailed to the person in charge. It would be
pretty trivial for a cracker to forge an email to look like the
official emails. Instead, you could have the authenticated form data
written to a database on the webserver, and create an SSL-encrypted
authenticated web front end for the human to access the data. No
longer is the (potentially sensitive) data going across the wire to
be sniffed, or worse, manipulated or forged.

It's especially hard to justify taking the time to reinvent processes
that are 'working'. However removing vulnerabilities in your setup
will prevent you from looking the fool when someone breaks a system
you set up ages ago which you know isn't secure.

NOTES:

[1] Note I said 'respond to' instead of answer, since I can be wrong
just as much as the next guy. But if you've been reading my
newsletter for a while, you already knew that.

[2]

 1. ipchains -F or iptables -F, assuming the default policy is
    "ACCEPT".
   
 2.  for tty in `perl -e 'print join " ", 1..30, "\n"'`
      do
       echo "/dev/pts/$tty">> /etc/securetty
      done
   
 3. Edit /etc/pam.d/passwd, remove the min= argument from the
    password required line.

[3] This was a long time ago, before SSH clients were available for
windows/mac, long before OpenSSH existed.

[4] Of course, it's always best to do it right the first time.

                            -------------                            
Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking
Linux Exposed and Building Linux VPNs. None of his systems have any
old, crufty, historical methods of operation. Really. None of his
systems operate at all. Brian can be reached at
brian () hackinglinuxexposed com.

--------------------------------------------------------------------
This newsletter is distributed by Onsight, Inc.

The list is managed with MailMan (http://www.list.org). You can
subscribe, unsubscribe, or change your password by visiting
http://lists.onsight.com/ or by sending email to
linux_security-request () lists onsight com.

Archives of this and previous newsletters are available at
http://www.hackinglinuxexposed.com/articles/

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

Copyright 2003, Brian Hatch.



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.