[ISN] Challenge yourself to get rid of insecure software.

From: InfoSec News (isnat_private)
Date: Mon Jun 02 2003 - 23:18:38 PDT

  • Next message: InfoSec News: "[ISN] Clancy Urges CIOs: Seek Out the 'Smart People'"

    +------------------------------------------------------------------+
    |  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
    brianat_private
    
    --------------------------------------------------------------------
    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-requestat_private
    
    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 majordomoat_private with 'unsubscribe isn'
    in the BODY of the mail.
    



    This archive was generated by hypermail 2b30 : Tue Jun 03 2003 - 01:05:41 PDT