Lesson 5 Introduction to Incident Response

UTSA IS 6353 Incident Response Overview Hacker Lexicon Incident Response

UTSA IS 6353 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 Incident Response Root Kits Three primary types: –traditional –loadable kernel modules (LKMs) for Unix/Linux –kernel -level rootkit for Windows NT/2000 Hundreds of Root-kits in existence –Hackers sites contain “click and choose smorgasbord” (KNOW THY ENEMY)

UTSA IS 6353 Incident Response Traditional Unix/Linux Rootkits Backdoors - programs that listen on TCP/UPD 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 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 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 Incident Response WIN NT/2000 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 Incident Response Incident Response Overview Goals Methodology Preparation Detection Initial Response Strategy Formulation Investigation Monitoring Recovery Reporting

UTSA IS 6353 Incident Response What is an Incident? Incident - an event in an information system/network Time based security: Protection time >> detection time + reaction time Some say its all about vulnerability management

UTSA IS 6353 Incident Response SANS/FBI Top 20 List 20 MOST CRITICAL INTERNET VULNERABILITIES UP TO 800 POSSIBLE SANS Institute 20 Most Critical Internet Security Vulnerabilities

UTSA IS 6353 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 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 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 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 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 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 All for legal/civil recriminations Provide accurate reports/recommendations

UTSA IS 6353 Incident Response Incident Response Methodology Pre-incident preparation Detection Initial Response Strategy formulation Duplication Investigation Security measure implementation Network monitoring Recovery Reporting Follow-up See page 18, Fig 2-1

Pre-Incident Preparation Detection of Incidents Incident Response Team FormedNotification Checklist Completed Initial Response Formulate Response Strategy Is it really an Incident? Yes No Follow-Up Pursue and accumulate evidence and/or secure system Secure System Reporting Implement Security Measures Forensic Duplication Investigation Forensic duplication? Accumulate Evidence Yes No Perform Network Monitoring Isolate and Contain Can Pursue Both Paths Simultaneously Page 18, Fig 2-1

UTSA IS 6353 Incident Response Detection Firewall Logs IDS Logs Suspicious User Sys Admin DETECTDETECT Notification Checklist Completed Response Team Activated

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

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

UTSA IS 6353 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 Incident Response Common Incidents Denial of Service Attack Unauthorized Use Vandalism Information Theft Computer Intrusion Type of incident + response likely outcome Management Support network downtime user downtime legal liability publcity theft of intellectual property

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

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

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

UTSA IS 6353 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 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 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