An Evening with Berferd Bill Cheswick, USENIX 1990 Presented by Chris Grier

Outline 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 rlogin –Wants a shell, only has access to executing shell commands –Inserts an account into /etc/passwd and edits the.rhosts file accordingly 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 – s 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 locations 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 compromised 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 backdoors 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

Conclusions Transition from getting a login to root access is relatively easy 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