intrusion detection somesh jha university of wisconsin
TRANSCRIPT
Intrusion Detection
Somesh Jha University of Wisconsin
April 21, 2023 J. Giffin and S. Jha 2
Intrusion Detection
Goal: Discover attempts to maliciously gain access to a system
April 21, 2023 J. Giffin and S. Jha 3
Network Intrusion Detection Systems (NIDS)
• Inspects packets at certain vantage points– For example, behind the routers
• Look for malicious or anomalous behavior
• Much more fine-grained than firewalls– Example: drop a packet whose payload
“matches” a certain string
April 21, 2023 J. Giffin and S. Jha 4
Nomenclature
• Packet Classification– Typically only look at packet headers– Enough to determine which firewall rules
apply
• Deep packet inspection (DPI)– Have to also inspect packet payloads– Needed for intrusion detection systems
(IDS) and intrusion prevention systems (IPS)
April 21, 2023 J. Giffin and S. Jha 5
Classification of NIDS
• Signature-based– Also called misuse detection– Establish a database of malicious patterns– If a sequence of packets “matches” one of the
patterns, raise an alarm– Positives
• Good attack libraries• Easy to understand the results
– Negatives• Unable to detect new attacks or variants of old attacks
• Example– Cisco, Snort, Bro, Tippingpoint, NFR, …
April 21, 2023 J. Giffin and S. Jha 6
Network Intrusion Prevention System (IPS)
• NIDS are generally “passive”– Raise alerts if something suspicious
happens
• IPS are active– Drop suspicious looking packages– Route certain packets for further
inspection– Main challenge: have to work at line
speeds
April 21, 2023 J. Giffin and S. Jha 7
Classification of NIDS
• Anomaly-based– Establish a statistical profile of normal traffic– If monitored traffic deviates “sufficiently” from the
established profile, raise an alarm• Positives
– Can detect new attacks• Negatives
– High false alarm rate• High variability in normal traffic
– Intruder can go under the “radar”• Examples
– Mostly research systems
April 21, 2023 J. Giffin and S. Jha 8
Classification of NIDS
• Stateless– Need to keep no state– Example: raise an alarm if you see a
packet that contains the pattern “mellissa”
• Positives– Very fast
• Negatives– For some attacks need to keep state
April 21, 2023 J. Giffin and S. Jha 9
Evasion Attacks
• Insertion, Evasion and Denial Of Service: Eluding NIDS by T.H. Ptacek and T. Newsham
• Fragment the attack packet to break the keyword
• Reorder the packet• Any valid transformation that TCP
allows
April 21, 2023 J. Giffin and S. Jha 10
Classification of NIDS
• Stateful– Keeps state– Sometime need to do reassembly
• Reassemble packets that belong to the same connection, e.g., packets that belong to the same ssh session
• Quite hard! (out-of-order delivery)
– Positives• Can detect more attacks
– Negatives• Requires too much memory
April 21, 2023 J. Giffin and S. Jha 11
Typical Stages of a NIDS
• Limited TCP reassembly– Handle out-of-order packets and
fragmentation• Protocol Parsing and Normalization
– Various fields of a protocol (e.g., HTTP)– Normalize inputs (e.g., convert all URL
names to a standard form)• Signature matching
– Simple keywords (fast algorithms exist)– Full regular expression matching (slow)
April 21, 2023 J. Giffin and S. Jha 12
Snort
Filtered packet stream
April 21, 2023 J. Giffin and S. Jha 13
libpcap
• Takes the “raw” packet stream• Parses the packets and presents them
as a – Filtered packet stream
• Library for packet capture• Website for more details
– http://www-nrg.ee.lbl.gov/.
April 21, 2023 J. Giffin and S. Jha 14
Malicious Pattern Example
alert tcp any any -> 10.1.1.0/24 80 (content: “/cgi-bin/phf”; msg: “PHF probe!”;)
action pass log alert
protocolsource addresssource port
destination addressdestination port
April 21, 2023 J. Giffin and S. Jha 15
Malicious Patterns Example
• content: “/cgi-bin/phf”– Matches any packet whose payload
contains the string “/cgi-bin/phf”– Look at
http://www.cert.org/advisories/CA-1996-06.html
• msg: “PHF probe!”– Generate this message if a match happens
April 21, 2023 J. Giffin and S. Jha 16
More Examples
alert tcp any any -> 10.1.1.0/24 6000:6010 (msg: “X traffic”;)
alert tcp !10.1.1.0/24 any -> 10.1.1.0/24 6000:6010 (msg: “X traffic”;)
April 21, 2023 J. Giffin and S. Jha 17
How to generate new patterns?
• Buffer overrun found in Internet Message Access Protocol (IMAP)– http://www.cert.org/advisories/CA-1997-09.
html
• Run exploit in a test network and record all traffic
• Examine the content of the attack packet
April 21, 2023 J. Giffin and S. Jha 18
Notional "IMAP buffer overflow" packet
052499-22:27:58.403313 192.168.1.4:1034 -> 192.168.1.3:143
TCP TTL:64 TOS:0x0 DF
***PA* Seq: 0x5295B44E Ack: 0x1B4F8970 Win: 0x7D78
90 90 90 90 90 90 90 90 90 90 90 90 90 90 EB 3B ...............;
5E 89 76 08 31 ED 31 C9 31 C0 88 6E 07 89 6E 0C ^.v.1.1.1..n..n.
B0 0B 89 F3 8D 6E 08 89 E9 8D 6E 0C 89 EA CD 80 .....n....n.....
31 DB 89 D8 40 CD 80 90 90 90 90 90 90 90 90 90 1...@...........
90 90 90 90 90 90 90 90 90 90 90 E8 C0 FF FF FF ................
2F 62 69 6E 2F 73 68 90 90 90 90 90 90 90 90 90 /bin/sh.........
April 21, 2023 J. Giffin and S. Jha 19
Alert rule for the new buffer overflow
alert tcp any any -> 192.168.1.0/24 143 (content:"|E8C0 FFFF FF|/bin/sh"; msg:"New IMAP Buffer Overflow detected!";)
Can mix hex formatted bytecode and text
April 21, 2023 J. Giffin and S. Jha 20
Advantages of Snort• Lightweight
– Small footprint– Focused monitoring: highly tuned Snort for
the SMTP server• Malicious patterns easy to develop
– Large user community– Consider the IRDP denial-of-service attack– Rule for this attack available on the same
day the attack was announced• Commercial company (Sourcefire)
behind it
April 21, 2023 J. Giffin and S. Jha 21
Disadvantages
• Does not perform full stream reassembly– Attackers can use that to “fool” Snort– Break one attack packet into a stream
• Pattern matching is expensive– Matching patterns in payloads is expensive
(avoid it!)
• Rule development methodology is adhoc
April 21, 2023 J. Giffin and S. Jha 22
Host-based ID
• Monitor interaction between a specific program and OS
• Raise an alarm if suspicious “system calls” are observed
• Unlike NIDS monitoring happens at the end hosts
• Need to model– Unusual behavior– Normal behavior
April 21, 2023 J. Giffin and S. Jha 23
Goal: Discover attempts to maliciously gain access to a system
Specification-BasedMonitoring
•Specify constraints uponprogram behavior
•Ensure execution doesnot violate specification
•Our work; Ko, et. al.
•Specifications can becumbersome to create
Misuse Detection
•Specify patterns ofattack or misuse
•Ensure misuse patternsdo not arise at runtime
•Snort
•Rigid: cannot adaptto novel attacks
Anomaly Detection
•Learn typical behaviorof application
•Variations indicatepotential intrusions
• IDES
•High false alarm rate
April 21, 2023 J. Giffin and S. Jha 24
Specification-Based Monitoring
• Two components:
– Specification: Indicates constraints upon program behavior
– Enforcement: How the specification is verified at runtime or from audit data
April 21, 2023 J. Giffin and S. Jha 25
ExecutionObeys Static
Ruleset
Specification
Enforcement
ExecutionMatchesModel of
Application
Analyst orAdministrator
TrainingSets
StaticBinary Code
Analysis
StaticSource Code
Analysis
April 21, 2023 J. Giffin and S. Jha 26
Representative Work by Ko, et al.
• Specification: Programmers or administrators specify correct program behavior
• Enforcement: At runtime, only allow actions that match the specified policy
PROGRAM fingerdread(X) :-
worldreadable(X);bind(79);write(“/etc/log”);exec(“/usr/ucb/finger”);
END
April 21, 2023 J. Giffin and S. Jha 27
ExecutionObeys Static
Ruleset
Specification
Enforcement
ExecutionMatchesModel of
Application
Analyst orAdministrator
TrainingSets
StaticBinary Code
Analysis
StaticSource Code
Analysis
April 21, 2023 J. Giffin and S. Jha 28
Representative Work by Forrest, et al
• Specification: Learn correct program behavior with training– Record sequences of system calls
• Enforcement: Only accept behaviors similar to learned patterns
• Example system: STIDE
April 21, 2023 J. Giffin and S. Jha 29
Training
• Repeatedly run the program, varying the input
• For some n, record all sequences of n system calls observed– n depends upon the program
• End result: database of n-tuples of system calls
April 21, 2023 J. Giffin and S. Jha 30
cat (print file contents)geteuid, getuid, getegid, getgid, fstat, open, fstat, lseek, mmap, read, memcntl, write, lseek, munmap, lseek, close, close, exit
geteuid, getuidgetuid, getegidgetegid, getgidgetgid, fstatfstat, open / lseekopen, fstatlseek, mmap / munmap / closemmap, readread, memcntlmemcntl, writewrite, lseekmunmap, lseekclose, close / exit
April 21, 2023 J. Giffin and S. Jha 31
Enforcement
• Monitor system calls generated by application
• Ensure that the last n calls match a sequence in the database
• Option: Allow slight deviation from database– Training set may have been incomplete
April 21, 2023 J. Giffin and S. Jha 32
cat (print file contents)geteuid, getuid, getegid, getgid, fstat, open, fstat, lseek, mmap, read, memcntl, write, lseek, munmap, lseek, close, close, exit
Accepts incorrect system call sequences
geteuid, getuid, getegid, getgid, fstat, lseek, close, exit
geteuid, getuidgetuid, getegidgetegid, getgidgetgid, fstatfstat, open / lseekopen, fstatlseek, mmap / munmap / closemmap, readread, memcntlmemcntl, writewrite, lseekmunmap, lseekclose, close / exit
April 21, 2023 J. Giffin and S. Jha 33
Drawbacks
• Accepts incorrect call sequences– Due to window-based approach with
ambiguity– Opportunity for attack sequence to go
undetected
• Only learn behaviors exercised in training set– Not all execution paths followed
• Users must construct valid training sets• Users must determine window size
April 21, 2023 J. Giffin and S. Jha 34
Drawbacks
• Specification may over-fit the data• If training on real data, training set
may contain exploits– Learn exploit pattern as normal
April 21, 2023 J. Giffin and S. Jha 35
ExecutionObeys Static
Ruleset
Specification
Enforcement
ExecutionMatchesModel of
Application
Analyst orAdministrator
TrainingSets
StaticBinary Code
Analysis
StaticSource Code
Analysis
slide 36
• Main idea: pre-determine control flow graph (CFG) of an application– Static analysis of source code– Static binary analysis CFI– Execution profiling– Explicit specification of security policy
• Execution must follow the pre-determined control flow graph
CFI: Control-Flow Integrity[Abadi et al.]
slide 37
• Use binary rewriting to instrument code with runtime checks
• Inserted checks ensure that the execution always stays within the statically determined CFG– Whenever an instruction transfers
control, destination must be valid according to the CFG
CFI: Binary Instrumentation
CFI (Continued)
• Goal: prevent injection of arbitrary code and invalid control transfers (e.g., return-to-libc)– Secure even if the attacker has complete
control over the thread’s address space
April 21, 2023 Somesh Jha 38
slide 39
CFG Example
slide 40
• For each control transfer, determine statically its possible destination(s)
• Insert a unique bit pattern at every destination– Two destinations are equivalent if CFG
contains edges to each from the same source• This is imprecise (why?)
– Use same bit pattern for equivalent destinations
CFI: Control Flow Enforcement
CFI Enforcement
• Insert binary code – that at runtime will check whether the bit
pattern of the target instruction – matches the pattern of possible
destinations
April 21, 2023 Somesh Jha 41
slide 42
CFI: Example of Instrumentation
Original code
Instrumented code
Abuse an x86 assembly instruction toinsert “12345678” tag into the binaryJump to the destination only if
the tag is equal to “12345678”
slide 43
• Unique IDs– Bit patterns chosen as destination IDs
must not appear anywhere else in the code memory except ID checks
• Non-writable code– Program should not modify code memory
at runtime• What about run-time code generation and
self-modification?
CFI: Preventing Circumvention
CFI: Preventing Circumvention
• Non-executable data– Program should not execute data as if it
were code
• Enforcement: hardware support + prohibit system calls that change protection state + verification at load-time
April 21, 2023 Somesh Jha 44
slide 45
• Suppose a call from A goes to C, and a call from B goes to either C, or D (when can this happen?)– CFI will use the same tag for C and D, but this
allows an “invalid” call from A to D– Possible solution: duplicate code or inline– Possible solution: multiple tags
• Function F is called first from A, then from B; what’s a valid destination for its return?– CFI will use the same tag for both call sites, but this
allows F to return to B after being called from A– Solution: shadow call stack
Improving CFI Precision
slide 46
CFI: Security Guarantees
• Effective against attacks based on illegitimate control-flow transfer– Stack-based buffer overflow, return-to-libc
exploits, pointer subterfuge
• Does not protect against attacks that do not violate the program’s original CFG– Incorrect arguments to system calls– Substitution of file names– Other data-only attacks
April 21, 2023 J. Giffin and S. Jha 47
Questions?