Transcript Realtime Intrusion-Forensics A First Prototype

Realtime Intrusion - Forensics
A First Prototype Implementation
(based on a stack-based NIDS)
Udo Payer
Institute of Applied Information Processing and
Communications
University of Technology, Inffeldgasse 16a, A-8010 Graz,
Austria
email: [email protected]
Forensic Computing


Gathering and analyzing data in a manner as
free from distortion or bias as possible to
reconstruct data or what has happened in the
past on a system.
The challenges:






Systems are HUGE & complex, change rapidly
Things can hide anywhere
Knowledge & experience are important
Anything you do to a system disturbs it
You can never trust the system
We can never know the past
 Even the present is tricky
Dan Farmer and Wietse Venema
IBM T.J. Watson Research Center
The Challenge
Forensic Analysis

Heisenberg’s Principle of System Analysis



Real - impossible to know both momentum and
Werner von Heisenberg
location; examining one affects the other.
Computers - examining or collecting one part of the
system will disturb other components. It is impossible
to completely capture the entire system at any point in
time.
How Can You Trust Your Data if You Can’t Trust
Your Tools?




Compromised kernel?
Chain of Trust
Dragging your own toolkit around
Online vs. Offline
Dan Farmer and Wietse Venema
IBM T.J. Watson Research Center
The Challenge
Forensic Analysis

Chain of Trust (What happens when you run a
binary)


Shell, command, library, device driver, kernel, …
Online vs. Offline




Many things can be done (active countermeasures)
Working with original data/system
No errors in replication or interpretation of data
But:
 We cannot go back in time, so be careful with decisions…
 ... and we have tight timing constraints
NIDS
a good place for forensic
investigation
due to missing alternatives …





Packets traversing network stack
Gathering local network information
Important nodes on network (Router, Gateway, …)
Initial vs. subsequent connections
Deleting network traces (evidences) is impossible



in most cases (at least)
We know where data was saved (remote log server)
Destroying all information there is (almost)
impossible
NIDS
a good place for forensic
investigation
due to missing alternatives …

A first attempt:

TCP wrapper’s booby trap
user@trustix> cat /etc/hosts.allow
# Finger is allowed by everyone – but root is informed
# about this per mail
# daemon_list : client_list [ : shell_command ]
ALL: ALL: spawn (/usr/sbin/safe_finger -l @%h | \
mail -s "finger from %h" root)
%h … name or IP address of the remote host
Wietse Venema
IBM T.J. Watson Research Center
Candidates for the Integration
into the TCP/IP Stack:





IP spoofing detection (TCP hijacking)
OS detection (OS fingerprinting)
Blinding a sensor (SYN-, FIN-flooding)
(Polymorphic) Shellcode detection
(Many) more …
Some Candidates:
'IP Spoofing' and ‘TCP Hijacking'

… used to hide the origin, or for indirect attacks





The best way is to monitor the reply to the SYN+ACK
packet (sent by the victim)
 If the spoofed (faked) IP is alive it returns a NACK
(RST flag set)
Checking the acknowledge number of the ACK packet
arriving after the SYN+ACK is sent.
 If it doesn’t fit with the initial sequence number sent 
the attacker is trying to guess the sequence.
MAC/IP pair matching
 Linux kernel has had a simple MAC-matching module for
some time (just used to rate the trustability)
Ingress/egress checks
Active packet tracing (TTL)
Some Candidates:
OS-Fingerprinting

There are many tools today that are used for
remote active operating system fingerprinting:


…having their own fingerprinting techniques.
Some of them:





Nmap,
iQ,
RINGv2, and
Xprobe2
...
Some Candidates:
OS-Fingerprinting - RINGv2
designed to determine the target OS with minimal target disturbance.
SYN_RCVD Method
1.

measures the RTO values of the SYN_ACK responses
LAST_ACK Method
2.

measures the RTO values of the FIN_ACK responses
FIN_WAIT_1 Method
3.

measures the RTO values of the FIN_ACK responses after a normal
exchange of data.
SYN
1.
2.
SYN
SYN/ACK
SYN
ACK
SYN/ACK
Δt1
SYN/ACK
Δt2
SYN/ACK
Δt3
SYN/ACK
SYN/ACK
PSH/ACK
ACK
ACK
FIN/ACK
PSH/ACK
FIN/ACK
Δt
ACK
FIN/ACK
FIN/ACK
Δt
FIN/ACK
3.
Some Candidates:
OS-Fingerprinting - Xprobe2
Sequence of 5 tests:





A: In this test an ICMP packet with an ICMP echo request
message is sent.
B: In this test an ICMP packet with an ICMP timestamp request
message is sent.
C: In this test an ICMP packet with an ICMP address mask
request message is sent.
D: In this test an ICMP packet with an ICMP information
request message is sent.
E: In this test a UDP packet acting as a DNS query result is
sent.
Some Candidates:
OS-Fingerprinting – iQ

The traditional OS fingerprinting is too noisy (9 tests required in
NMAP). iQ does not use any malformed packets, and performs
only 1 to 5 tests (most fingerprint uses only 2 tests). It is therefore
very stealthy.
5 types of packets:
U: UDP (icmp unreachable) on a closed port
I1: ICMP ECHO REQUEST
I2: ICMP TIMESTAMP
I3: ICMP INFO REQUEST
I4: ICMP MASK REQUEST
Fingerprint Linux 2.4.5+ :
U(Resp=Y, Tos=192, IP_LEN=126)
I1(Resp=Y, IP_ID=!0, IP_OFF=!1)
Fingerprint HP-UX 11.x:
U(Resp=Y, Tos=!192, IP_LEN=112)
I2(Resp=N)
Fingerprint Linux 2.2.x:
U(Resp=Y, Tos=192, IP_LEN=126)
I1(Resp=Y, IP_ID=!0, IP_OFF=1)
Fingerprint Linux 2.4.5+ :
U(Resp=Y, Tos=192, IP_LEN=126)
I1(Resp=Y, IP_ID=!0, IP_OFF=!1)
Fingerprint Windows NTsp4+:
U(Resp=Y, Tos=!192, E_ILEN=98, IP_LEN=!112)
I1(Resp=Y, ICMP_CODE=0, Tos=!0)
I2(Resp=N)
I4(Resp=N)
Some Candidates:
OS-Fingerprinting – Nmap




TCP/UDP: NMAP uses these protocols to determine (or estimate)
the OS
RTO: (Retransmission TimeOut): The time distance between each
successive SYN-ACK retransmission is OS depending.
IP/UDP/ICMP: ICMP is an error message protocol. This will be
used to distinguish between the different operating systems.
NMAP-Test Packets:
Tseq is the TCP sequenceability test
T1 is a SYN packet with a bunch of TCP options to open port
T2 is a NULL packet w/options to open port
T3 is a SYN|FIN|URG|PSH packet w/options to open port
T4 is an ACK to open port w/options
T5 is a SYN to closed port w/options
T6 is an ACK to closed port w/options
T7 is a FIN|PSH|URG to a closed port w/options
PU is a UDP packet to a closed port
Some Candidates:

OS-Fingerprinting – Nmap
This a typical response from a WinXP
machine:
TSeq(Class=RI%gcd=<16%SI=<25AEE&>6B%IPID=I)
T1(DF=N%W=402E|7D78|FAF0%ACK=S++|O%Flags=AS|A%Ops=MNWNNT|NNT)
T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
T3(Resp=Y%DF=N%W=402E|7D78|FAF0%ACK=S++|O%Flags=AS|A%Ops=MNWNNT|NNT)
T4(DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(DF=N%W=0%ACK=S++%Flags=AR%Ops=)
PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

How to Catch Fingerprinting Attacks?
any other …
Safe
TSeq
S1
T1
T2
S2
T3
S3
PU
T7
S4
…..
S8
hit
Some Candidates:
OS-Fingerprinting - Nmap
Some Candidates:
OS-Fingerprinting - Nmap
// If it doesn't have a SYN (and only a SYN), we'll send a
// reset.
if ((RcvInfo.tri_flags & (TCP_FLAG_SYN | TCP_FLAG_ACK |
TCP_FLAG_RST)) == TCP_FLAG_SYN) {
AddrObj *AO;
//
// This segment had a SYN.
//
#ifdef NT
CTEGetLockAtDPC(&AddrObjTableLock, &TableHandle);
Some Candidates:
OS-Fingerprinting - Nmap
Blinding the Sensor




flooding the network with dummy traffic to mask the real
attack
The recently published “stick” attack was able to blind
the industry leading NIDS
 … making it possible for another attack to be sent
through completely undetected.
some NIDS sensors don’t reassemble fragmented
packets
 Some claims to reassemble packets but actually only do
partial reassembly
 Do not cause extra costs (if performed by the stack)
advanced intrusion detection technologies like stateful
inspection, multi-path packet reassembly are more
resilient and effective at avoiding blinding sensors
Windows:
Tuning TCP/IP Responses to Attacks


Windows 2000 TCP has also been hardened against a variety
of attacks (but not enabled by default)
DoS attacks “prevention” can be added by enabling:

SynAttackProtect key in the registry.

Allows several levels of protection against SYN attacks
Default: 0 (false)
Recommendation: 2




TcpMaxConnectResponseRetransmissions, controls the
number of SYN-ACK replies.
TCPMaxPortsExhausted, controls the point at which SYNATTACK protection starts to operate. .
TCPMaxHalfOpen, controls the number of connections in the
SYN-RCVD state before SYN-ATTACK protection begins to
operate
TCPMaxHalfOpenRetried, controls the number of connections
in the SYN-RCVD state for which there has been at least one
retransmission of the SYN sent, before SYN-ATTACK attack
protection begins to operate.
Linux:
Tuning TCP/IP Responses to Attacks

SYN Cookies
 Panix, an ISP in New York, was shut down by a SYN flood
on 6 September 1996




Large SYN queues and random early drops make SYN
flooding more expensive but don't solve the problem
SYN cookies use cryptographic techniques
They are, unfortunately, not enabled by default under Linux
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
SYN cookies are particular choices of initial TCP sequence
numbers by TCP servers



top 5 bits: t mod 32, where t is a 32-bit time counter
next 3 bits: encoded MSS (server) as response to client's MSS;
bottom 24 bits: secret function of the client IP address and port
number, the server IP address and port number, and t. .
Some Candidates:
(Polymorphic) Shellcode Detection
A simple instruction call
execve("/bin/bash",["/bin/bash",null],null)
is normally coded as:
\x6A\x68\x68\x2F\x62\x61\x73\x68\x2F\x62\x69\
x6E\x89\xE3\x31\xD2\x52\x53\x89\xE1\x6A\x0B\
x58\xCD\x80
but it can be modified and embedded in a polymorph frame:
FAKENOP
decipher
routine
encrypted
shellcode
bytes to
cram
return
address
Source: „Polymorphic Shellcode Engine Using Spectrum Analysis”
Some Candidates:
(Polymorphic) Shellcode Detection
By looking at the string
\x15\x11\xF8\xFA\x81\xF9\x27\x2F\x90\x9E
we can read:
ADC $0x11F8FA81 #instruction demanding 4-bytes argument
STC
#one-byte instructions
x15, x27,
DAA
x90,
DAS
x11, …
NOP
SAHF
… or by starting from the second byte
ADC %eax,%edx
CMP %ecx,$0x272F909E
xf9, x2f, x9e,
x81, x90, …
Source: „Polymorphic Shellcode Engine Using Spectrum Analysis”
Implementation

Integration into the network stack:


Windows:
 Self-explanatory code for the network stack
 No information about the implementation
 Tricky device driver building, signing, debugging, …
 Some information about kernel programming, but no
documentation about the rest
Linux
 A big mess!!!
 Less information about the network stack
 Great number of tools (easy to use, since good
documentation exists)
Conclutions



Stack based threats are still out there.
The stack based approach takes very little resources
Can be integrated into any OS network stack




Detailed analysis has to be done offline
Suitable protocols exists:





Even on small devices { lwIP stack (Adam Dunkels) – uses just tens of
kBs of free RAM, 40kB ROM code }
I’m thinking about : Cell phones, PDAs, ... and simple blinding
mechanisms.
Simpled Network Markup Language (SNML)
Intrusion Detection Message Exchange Format (IDMEF),
(IDXP), (BEEP), …
Monitoring an logging has to be performed offline
Set of suitable attacks is limited
Effectivity of active countermeasures is limited
[email protected]