Rootkits and Incident Response

Lesson 6 Basics of Incident Response

Overview Hacker Lexicon Incident Response UTSA IS 6353 Security Incident Response

Hacker Lexicon Rootkit - a collection of tools an intruder loads onto a compromised computer Usually Consists of: trojanized utilities network sniffers log-cleaning scripts UTSA IS 6353 Security Incident Response

Root Kits Three primary types: traditional loadable kernel modules (LKMs) for Unix/Linux kernel -level rootkit for Windows Hundreds of Root-kits in existence Hackers sites contain click and choose smorgasbord (KNOW THY ENEMY) UTSA IS 6353 Security Incident Response

Rootkit History 1989: First log cleaners on hacked systems 1994: Early SunOS rootkits detected 1996: First Linux Rootkits seen publicly 1997: LKMs proposed in Phrack 1998: non-LKM patching proposed by S. Cesare 1999: Adore rootkit released by TESO 2000: T0rnkit V8 libproc Trojan released 2001: KIS trojan and SucKit released 2002: Sniffer backdoors start to show up

Basic RootKit Functionality Maintain Access Attack other Systems Destroy Evidence UTSA IS 6353 Security Incident Response

Traditional Rootkit Tools Backdoors - programs that listen on TCP/UDP ports that allow intruder stealthy access Log wipers - utility which erases log files to hide signs of intruders presence Packet sniffers - software designed to monitor network traffic to capture packets of interest Internet Relay Chat (IRC) utilities for comms DDOS agents - S/W that sends UDP/ICMP floods UTSA IS 6353 Security Incident Response

LKM Rootkits Most rootkits used against Unix/Linux systems are Loadable Kernel Modules (LKMs) Kernel is transparently modified: Execute Redirection: remaps system utility calls Remote execution: commands transmitted via the net Promiscuous mode hiding: hides sniffers Task hacking: changing the user id (UID), effective user id (EUID), and file system user id (FSUID) of any process UTSA IS 6353 Security Incident Response

LKM Rootkits Kernel is transparently modified (contd): Real-time process hiding -sending the following: kill -31 process id allows kernel to suppress all info about the given process Kernel Module Hiding: LKMs can actually mask their own presence (stealthy LKMs) UTSA IS 6353 Security Incident Response

WINDOWS Rootkits Contains: Kernel Mode Device Driver: _root_.sys Launcher program: deploy.exe Capabilities: Back doors Hide files: files with _root_ will be hidden from dir Hide processes and registry entries Keystroke Intercept UTSA IS 6353 Security Incident Response

Incident Response Overview Goals Methodology Preparation Detection Initial Response Strategy Formulation Investigation Monitoring Recovery Reporting UTSA IS 6353 Security Incident Response

SANS in The Fight Started as SANS/FBI Top 20 Vulnerabilities 20 Critical Security Controls UTSA IS 6353 Security Incident Response

General Vulnerabilities 1. Default installs of OSs and applications 2. Weak or non-existent passwords 3. Incomplete or non-existent backups 4. Large number of open ports 5. Lack of packet filtering 6. Incomplete or non-existent logging 7. Vulnerable CGI programs Source: The SANS Institute UTSA IS 6353 Security Incident Response

Windows Vulnerabilities 8. Unicode Vulnerability 9. ISAPI Extension Buffer Overflows 10. MS Remote Data Services Exploit 11. NETBIOS Unprotected Windows Networking Shares 12. Leakage via Null Session Connections 13. Weak Hashing in SAM (Lan Manager Hash) Source: The SANS Institute UTSA IS 6353 Security Incident Response

Unix Vulnerabilities 14. Buffer Overflows in Remote Procedure Call Services 15. Sendmail Vulnerabilities 16. Bind Weaknesses 17. R Commands 18. LPD Remote Print Protocol Daemon 19. Sadmind and Mountd 20. Default SNMP Strings Source: The SANS Institute UTSA IS 6353 Security Incident Response

Home User Guidelines Use strong passwords (alpha-numeric, over 8 characters) Make regular backups of critical data Use virus protection software Use a firewall as a gatekeeper between your computer and the Internet Do not leave computers online Do not open attachments from strangers Source: FBI UTSA IS 6353 Security Incident Response

The Worst Can Happen "Don't look at the past and assume that's the future. Look at the enemy's strengths and your vulnerability. You've got to realize that the worst case does sometimes happen." -Richard Clarke Special Advisor for Cybersecurity UTSA IS 6353 Security Incident Response

Goals of Incident Response Confirm or dispel incident Promote accurate info accumulation Establish controls for evidence Protects privacy rights Minimize disruption to operations Allow for legal/civil recriminations Provide accurate reports/recommendations UTSA IS 6353 Security Incident Response

Incident Response Methodology Pre-incident preparation Detection Initial Response Strategy formulation Duplication Investigation Security measure implementation Network monitoring Recovery Reporting Follow-up UTSA IS 6353 Security Incident Response

7 Components of Incident Response Investigate the Incident Formulate Response Strategy Detection of Incidents Pre-Incident Preparation Data Data Analysis Initial Response Reporting Collection Resolution Recovery Implement Security Measures UTSA IS 6353 Security Incident Response Page 15, Fig 2-1, Mandia 2nd Edition

Detection Firewall Logs D E T E C T IDS Logs Response Team Activated Notification Checklist Completed Suspicious User Sys Admin UTSA IS 6353 Security Incident Response

Initial Critical Details Current time and date Who/what is reporting the incident Nature of the incident When the incident occurred Hardware/software involved Point of contact for involved personnel UTSA IS 6353 Security Incident Response

INITIAL RESPONSE Success I R N E I S T P I O A N L S E Details from notification checklist Verified information about the incident Prepared response team Failure How much info is enough? UTSA IS 6353 Security Incident Response

Response Strategy Formulation Verified information about the incident Mgt Formulate Response Strategy Approved Action Plan Response Posture Goal: determine most appropriate response strategy UTSA IS 6353 Security Incident Response

Factors for Strategy How critical are the impacted systems? Data sensitivity Who are the perpetrators? Does the incident have publicity Level of access to the hacker Apparent skill of the attacker How much downtime can be tolerated Overall dollar loss involved UTSA IS 6353 Security Incident Response

Common Incidents Denial of Service Attack Unauthorized Use Vandalism Information Theft Computer Intrusion Management Support network downtime user downtime legal liability publcity theft of intellectual property Type of incident + response likely outcome UTSA IS 6353 Security Incident Response

Investigation Stage Live System Network Logs Investigation Investigative Report Forensic Duplicate UTSA IS 6353 Security Incident Response

Security Measure Implementation Stage Verified Info Implementing Security Remedies Network Logs Monitor Response Posture Isolate and Contain Prevent Same Exposure! Fishbowling the attacker UTSA IS 6353 Security Incident Response

Recovery/Reporting Process Recovery Conclusions backups hardening user education COOP Report Support Criminal Actions Lessons Learned Prevent Repeats Successful containment UTSA IS 6353 Security Incident Response

What Will You Do? We Need a Initial Response that: Supports the Goals of Computer Security Supports the Business Practices Supports Administrative and Legal Policy Is Forensically Sound Is Simple and Efficient (KISS) Provides an Accurate Snapshot for Decision Makers Supports Civil, Administrative, or Criminal Action. UTSA IS 6353 Security Incident Response

Common Mistakes Failure to Document Findings Appropriately. Failure to Notify or Provide Accurate Information to Decision Makers. Failure to Record and Control Access to Digital Evidence. Wait Too Long Before Reporting. Underestimating the Scope of Evidence that may be found. UTSA IS 6353 Security Incident Response

Common Mistakes Technical Blunders: Altering Time/Date Stamps on Evidence Systems Killing Rogue Processes Patching the System Not Recording the Steps Taken on the System Not Acting Passively UTSA IS 6353 Security Incident Response