An Evening with Berferd by juanagui


									An Evening with Berferd

 Bill Cheswick, USENIX 1990
   Presented by Chris Grier
• General Paper and Attack Overview
• A Simple Honeypot Design
• Why do any of this?

• Forensics: Evasion
• Forensics: Detection
                  Paper Overview
• Cheswick and Berferd play out a game
• Cheswick monitors an AT&T internet gateway machine
• Berferd attempts an exploit
   –   Old sendmail mis-configuration problem
   –   One of the bugs exploited by the Morris worm
   –   Reported in 1988 according to Securityfocus
   –   Allows remote command execution as root
• Cheswick is alerted to the attempt, and instead of
  denying plays along
   – Sends a bogus copy of a password file (for cracking)
   – Traces and notifies Stanford
 What’s necessary for this defense to work?
   – Infrastructure? Programs? Is Cheswick making some
     assumptions about the state of the system?
                Attack Continues
• Berferd continues the attack, and attempts to connect via
   – Wants a shell, only has access to executing shell commands
   – Inserts an account into /etc/passwd and edits the .rhosts file
• Cheswick is at the other end watching the logs
  produced, and eventually gives Berferd a shell
   – Customized shell, written for this purpose
   – Could contain bugs?
• Everything is setup in such a way that Berferd has no
  permanent impact on the running system
   – Visible aspects, fingerd
   – Emails and output
Chroot Jails and Simple Honeypots
•   Chroot changes the root directory
•   Essentially provides a user with a limited view of the system
•   System within a system type implementation, many programs won’t work
     – Devices don’t exist, some things need to be copied to the new environment
     – Easy to detect the chroot environment
     – Essentially a very simple honeypot

 What are some problems with this type of honey pot?

 A lot of effort to configure, what does Cheswick gain by doing this?

•   The initial honeypot required Cheswick to respond to commands, and
    execute them on the attackers behalf
•   Configured chroot system now handles the responses and logging for
    Berferd’s environment

 Problems with this?
                 Tracing Berferd
• Cheswick has a limited view of Berferd
   – Last hop before entering the network
   – Any behavioral information, such as time patterns
• Notifies Stanford, the previous hop, and CERT
• CERT is an incident response team at CMU
   – Tools and evaluations
   – Security releases
   – Education
• Contacting system administrators at incoming / outgoing
• Ends up that Berferd was not in the U.S. very little they
  can do that point other than watch
   – Identify other systems he has broken into and repair
  Why go through all this work?
• What information does Cheswick get out of
  fooling Berferd?
  – Other machines were compromised
  – Types of attacks were being performed
     • 0-day attacks lead to security notices
     • Configuration errors can be found and corrected
     • Level of automation
  – Some information could have been stolen or
     • Particularly important for corporations and government
                    Forensics: Evasion
•       All the information Cheswick saw came from logging
    –         Are all attacks going to leave logs?

•       Exploiting real machines
    –         Find the vulnerability and exploit it
    –         Use the vulnerability to get some type of backdoor, could be rlogin,
              creating a new account, installing a rootkit
          •      Code execution to spawn a shell, create a user
          •      Overwrite a file
    –         Login via backdoor, squash any logs that contain evidence
          •      Syslog entries, remove or obscure
          •      Lastlog, wtmp, utmp
          •      Shell history
          •      Service specific logs
•       What about Remote Logging?
•       Network IDS?
    Forensics: Network Evasion
• Proxies
   – Use a proxy to provide a layer of padding between the attacker’s
     computer and the victim
   – Pick proxies in other countries
   – Chain proxies together (this gets really slow)
• Anonymous networks
   – Tor is the main mix network used
   – Provides excellent resistance to end-to-end correlation based on
     watching connection information
   – Some services are intentionally blocked
• Blasting NIDS
   –   Most have some pattern type recognition
   –   Most are not automatic, notify an admin
   –   Simply provide the admin with thousands of lines of logs to look through
   –   NIDS typically won’t pick up an attack which is not violating the protocol
       and does not match a fixed signature
              Forensics: Detection
• Software and Hardware problems
   – Crashing, slowdown other odd symptoms are often viruses or
• Inconsistencies
   – Tripwire alerts to some change
   – Notice some change in /etc/passwd or other config file
• NIDS picks up suspicious connections
• Once you know you have been exploited what's next?
   –   Digging through logs for discrepancies
   –   Un-deleting files
   –   Open network sockets
   –   Root-kit detectors
• Law Enforcement won’t help much
• Using the law to help can be hard
   – Usually need to prove that there was significant monetary loss
• Transition from getting a login to root access is relatively
• Interactive honeypots like what trapped Berferd aren’t
  worth the effort
• A chroot environment does simulate a real system
  accurately enough
• Somewhat necessary at some level to monitor security
  incidents without letting attacker know
   – Need to know what is involved
   – What services are being exploited
   – CERT and other advisory groups will disseminate
• Allows for studying and identifying security
  vulnerabilities, still is some risk to the system

To top