RE: Red Hat compromise

From: Andrew Thomas (andrewat_private)
Date: Mon May 21 2001 - 00:19:19 PDT

  • Next message: Dave Dittrich: "Re: Red Hat compromise"

    Just a few comments...
    
    BE> Lisa,
    BE> 
    BE> Not sure if this is the exact exploit they used but I just 
    BE> worked a case
    BE> that had pretty much the same M.O.  The exploit is rpc.statd. 
    
    Blake, Lisa - I doubt rpc.statd would be an entry point, as both 
    TCP/111 and high ports are blocked. (Are you passing UDP packets? 
    The portmapper also runs on UDP/111. Also, I cannot find in 
    documentation offhand whether the statd service is available over
    UDP).
    
    CH> 1.  There are a large number of clear text authenticated protocols that
    are
    CH> traversing the wire in order to access the machine he speaks of.
    Telnet,
    CH> FTP, authenticated SMTP and POP3 can all have their passwords pulled
    right
    CH> off of the wire.  I would say the possibility that this guy is logging
    in as
    CH> ROOT with TELNET is a real possibility.  Do that from an untrusted
    network
    CH> and you might as well be asking for someone to own you.  ESPECIALLY with
    the
    CH> UNLIMITED availability and permeance of DSNIFF.
    
    Chris, Lisa - while I agree that there is a possibility that the
    infiltration may have been initiated via sniffed network traffic,
    this would imply that they were either already on a local LAN
    segment, or had owned a box that happened to be sitting between
    yourself and some of your traffic. An minor technical addition for
    the sake of clarity is also that most implementations of Telnet
    do *not* allow for root login. Last I checked dsniff did not
    pick up on 'su' statements in ongoing connections.
    
    Protecting machines against external intruders is a job in which
    a firewall *helps* - in that it prevents you from inadvertantly
    exposing vulnerable services to the outside world. The best way
    to secure a box would be to install it with the *minimal* number
    of services needed, restrict the rest with IPCHAINS or the like,
    and stay current on all patches for that particular release of
    software/services. Additional steps may be taken - particularly
    the installation of TCPWrappers and a file system integrity monitor,
    format string/non-exec stack patches (which, while not necessarily 
    keeping out determined/intelligent hackers, certaininly raises the 
    bar and should help in keeping the script kiddies at bay), and
    take other measures at hardening the kernel. (Of course, all this
    is from a technical perspective, and depending on the importance
    of the box in question you may want to way off cost/benefit of
    implementing all the available options).
    
    Security Focus has a wealth of resources and links to assist
    someone in their quest to make their box that much more secure,
    and, as always, staying current with the literature makes a world
    of a difference.
    
    Hope this helps.
    
    Take care,
      Andrew
    
    -
    Andrew Thomas
    office: +27 21 4889820
    facsimile: +27 21 4889830
    mobile: +27 82 7850166
     "One trend that bothers me is the glorification of
    stupidity, that the media is reassuring people it's 
    alright not to know anything. That to me is far more 
    dangerous than a little pornography on the Internet." 
      - Carl Sagan
    



    This archive was generated by hypermail 2b30 : Tue May 22 2001 - 08:07:40 PDT