Explaining and Recovering from Computer Intrusion: Status 97
Douglas B. Moran
Artificial Intelligence Center
SRI International
333 Ravenswood Avenue
Menlo Park CA 94025
2/26/97
- Apply AI Technology to Network-based Intrusions
- diagnosing
- explanation and reporting
- repair and recovery: automated security manual
- Tool:
- manages other tools (esp. OTS) for data collection
- rule-base to guide/advise user
- add additional tools as agents
- add intrusion scenarios
- Approach: start with common cases and build outward and
upward
- Widely available, commonly used cracker tool
- Involves many of the technical issues for diagnosis of intrusions
- Multiple entry points to diagnosis
- Alternative sources of information
- Cheap vs expensive
- Direct vs inferred
- Incomplete information
- attack may not use all components of Rootkit
- tools to delete and hide information
- Modified Commands
- process listings (ps)
- file listings (ls, du)
- network status (ifconfig, netstat)
- Modify log files
- Modify file info
- Example 1:
- user found hidden process
- suspect PS substitute
- confirm
- suspect Rootkit
- look for other substituted commands
- suspect log files modified
- "Forward": hidden process -> look for its name within PS binary
(strings command) either directly or indirectly (find config file)
- "Backward": substituted PS -> use strings to find
config file or process name -> find process or file (executable or
source)
- Different costs: "forward" easier: finding known name of process easier
than finding that name among miscellaneous strings
- Note: finding config file name is common to both
- Limitation: each direction coded separately
- Example: substituted commands
- Other commands producing similar output:
- eg PS, SPS, TOP
- common extensions, but not in official release
- Dates: compare to siblings and parent
- Strings (compare to "official" copy)
- Checksums: cheap if on-line, expensive (time delay) if they need to be
mounted, especially if on tape
- Example: altered log file
- cheap: wtmp start-end mismatches
- cheap: lastlog vs wtmp inconsistencies
- more expensive: various more sophisticated analysis
- Example: to hide objects (processes, files)
- modified command
- modified string comparison routines in library
- Example: hidden process
- Declaring "Rootkit suspected" is only a guide for what else to look
for
- Variants of Rootkit
- Incomplete use of components
- Similar functionality in other attack kits/scripts
- Level of confidence
- suspicious process with 4 letter name, strings command finds
name in PS, but dates OK, and checksum info off-line.
- Enough to trigger search for related evidence, but defer costly steps
to confirm
- Middle-out
- Initially:
- Assume that user is suspicious that there has been an intrusion and has
supplied starting point to system (eg, hidden process)
- Data requests to very low-level system components are stubs (hand
simulated by developer)
- Low-level components
- Prefer: borrow, reuse, modify
- Otherwise: create (keep simple)
- Design for portability to other platforms
- Prototype to be experimental testbed
- Tradeoff on size of procedures (Acts)
- efficiency vs reusability
- comprehensibility to and customizability by end-user
- Tool boundaries
- Primary reasoning engine may be mismatch for some of the diagnosis
- Multiple reasoning engines?
- Split of rules natural?
- Scheduling: cost, benefit, priority
- automatically/dynamically determined?
- extent of human interaction
- Coordinating rules for bi-directional analysis
- automatically generated: stubs, templates?
- automatically check: presence, parallelism
- Bundling expensive operations:
- from queue
- from rules, but not on queue
- Example: retrieving checksum data from tape
- In early phase of building prototype
- Local expertise being incorporated into rules
- Even "simple" example of Rootkit has produced a complex web of
relationships and alternatives
- Many tools: OS, third party (OTS), custom multiple way of finding
evidence:
- Incomplete evidence
- intentionally deleted
- overwritten by normal operation
- Inexperienced SysAdmins
- which tools to use when
- what does output really tell you
- speed
- prioritization
- Based on Acts (procedures) instead of rules
- Declarative acts and meta-acts
- Based on Beliefs-Desires-Intentions model
- Pre-emptable scheduling
- Supporting tools (e.g. editor)
- Control application of other tools to collect evidence
- Alternative sources of evidence
- Handle missing evidence (deleted, overwritten, or truly not there)
- Other application of tools to minimize destruction of evidence
- Get data quickly
- Reduce load on normal system
- Report evidence and ambiguities to SysAdmin
- Present ramifications
- Seek guidance
- Individual site often has incomplete evidence on intrusion
- Clearinghouse pieces together info from multiple reports
- Problem: how much to trust what SysAdmin say and don't say about what
they did and what they found
- Automated report generation
- credibility level
- facilitate automatic filtering and routing
- Goal: reduce effort and downtime to repair
- Prioritize repairs based on known scope of intrusion
- Automatically invoke any available tools (upon confirmation)
- Intrusions achieved by spreading components of attack over multiple
hosts in cluster (distributed file system)
- Share information between computers
- Within cluster
- Outsiders
- reduced info
- intruder or tracker?
- Multilevel, compositional procedures
- Build on previous, reuse
- Methods (get-root, Trojan Horse)
- Goal (install password sniffer)
- Camouflage
- During normal operation and during crisis, intruders will develop new
tactics
- Propagate rapidly
- Propagate confidentially (if reasonable): aid catching intruders
- Propagate securely: don't become vehicle for intrusions
- Trend: external sources represent wide range of organizations with wide
range of requirements towards security
- Each site must have substantial freedom and capability to specify own
policy
- all-or-nothing = nothing
- support tools critical
- provide baseline policy (augmented by each level of hierarchy)
- Dimensions
- type of attack
- category of attacker: capabilities and resources
- tolerance for loss
- Start with intrusion scenarios
- Test against multiple variants of attack
- Test for multiple site configurations
- Test for false positives
- Incrementally expand coverage
- tools
- intrusion scenarios
- Partner site (TBD) attempt to extend
Security Project Home Page
AI Center Home Page
SRI International Home Page
Pauline M. Berry berry@ai.sri.com