Realtime Intrusion - Forensics A First Prototype Implementation (based on a stack-based NIDS) Udo...

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: [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

http://www.watson.ibm.com/


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

[email protected]

Realtime Intrusion - Forensics A First Prototype Implementation (based on a stack-based NIDS) Udo...

Documents

Transcript of Realtime Intrusion - Forensics A First Prototype Implementation (based on a stack-based NIDS) Udo...