View
224
Download
0
Category
Tags:
Preview:
Citation preview
Realtime Intrusion - ForensicsA First Prototype Implementation
(based on a stack-based NIDS)
Udo PayerInstitute of Applied Information Processing and
CommunicationsUniversity of Technology, Inffeldgasse 16a, A-8010 Graz,
Austriaemail: Udo.Payer@iaik.at
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 ChallengeForensic Analysis
Heisenberg’s Principle of System Analysis Real - impossible to know both momentum and
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
Werner von Heisenberg
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
NIDSa good place for forensicinvestigation
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
due to missing alternatives …
NIDSa good place for forensic investigation
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
due to missing alternatives …
Wietse Venema IBM T.J. Watson Research Center
Candidates for the Integrationinto 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.1. SYN_RCVD Method
measures the RTO values of the SYN_ACK responses
2. LAST_ACK Method measures the RTO values of the FIN_ACK responses
3. FIN_WAIT_1 Method measures the RTO values of the FIN_ACK responses after a normal
exchange of data.
SYN
SYN/ACK
SYN/ACK
SYN/ACK
SYN/ACK
SYN
SYN/ACK
ACK
FIN/ACK
FIN/ACK
FIN/ACK
1. 2.3.
Δt1
Δt
Δt
SYN
SYN/ACK
ACK
PSH/ACK
ACK
PSH/ACK
ACK
FIN/ACK
FIN/ACK
Δt2
Δt3
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.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 HP-UX 11.x:U(Resp=Y, Tos=!192, IP_LEN=112)I2(Resp=N)
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)
Fingerprint Linux 2.4.5+ :U(Resp=Y, Tos=192, IP_LEN=126)I1(Resp=Y, IP_ID=!0, IP_OFF=!1)
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 portT2 is a NULL packet w/options to open portT3 is a SYN|FIN|URG|PSH packet w/options to open portT4 is an ACK to open port w/optionsT5 is a SYN to closed port w/optionsT6 is an ACK to closed port w/optionsT7 is a FIN|PSH|URG to a closed port w/optionsPU 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?
S1 S2 S3 S4 hit
SafeTSeq T1 T2
S8…..
T3 T7 PU
any other …
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);
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 attacksDefault: 0 (false)Recommendation: 2
TcpMaxConnectResponseRetransmissions, controls the number of SYN-ACK replies.
TCPMaxPortsExhausted, controls the point at which SYN-ATTACK 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 callexecve("/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\x80but it can be modified and embedded in a polymorph frame:
FAKENOP decipherroutine
encryptedshellcode
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 argumentSTC #one-byte instructionsDAADASNOPSAHF
… or by starting from the second byteADC %eax,%edxCMP %ecx,$0x272F909E
Source: „Polymorphic Shellcode Engine Using Spectrum Analysis”
x15, x27, x90, x11, …
xf9, x2f, x9e, x81, x90, …
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
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.
Detailed analysis has to be done offline Suitable protocols exists:
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
Udo.Payer@iaik.tugraz.at
Recommended