Training Security EMEA - II pptx

• Vulnerabilities are specific• The exact application must be identified • What works with apache won’t work on IIS • The version is also important • What works with apache 1.3.22 won’t

• Inline systems detection

Agenda – Part I : Identification

• Security policy bypassing

• DDoS & Worms

Agenda – Part III : DoS

Basic Identification

Port Scanning

About port scanning

• What scan sports for ?

• Identify running applications

• Quick and dirty

• scan 100s of ports in a short time

• Easily detected

PORTS

• 3-Way handshake based (SYN / SYN-ACK / ACK)

• Send SYN only :

• received SYN-ACK  open

• received RST  closed

• no answer to first SYN  filtered

Scanning TCP Ports

PORTS

• Anomaly based

• FIN Scan : FIN out of established session

• RFC : RST on open AND closed ports

• BSD based stacks : RST only on closed ports

• 90% of actual IP stacks

• FIN Scan variants

• X-mas tree : all TCP flags set

• Rely on TCP window size (0  closed, !0  open)

• Drawbacks

• Not very reliable : packet may be lost, filtered port as open

• Takes a lot of time as based on attacker stack timeout

Scanning TCP Ports

PORTS

• Only one method

• Packet sent on UDP ports

• ICMP Port unreachable  closed

• no response  open

• Drawbacks

• Same as FIN scan

• Not very reliable

• packet may be lost

• filtered port as open

• Takes a lot of time as based on attacker stack timeout

Scanning UDP Ports

PORTS

• Find FTP servers on the 192.168.202.0/24 network

• Identify open ports on 10.0.0.105 or 10.0.0.106

• Any idea on the possible OS running on this machine

Hands-on

PORTS

OS Fingerprinting

&

Application Scanning

• Banners

# telnet 10.0.0.1Fedora Core release 1 (Yarrow)Kernel 2.4.22-1.2115.nptlsmp on an i686login:

# nc 10.0.0.1 80

HEAD / HTTP/1.1

…

Date: Tue, 30 Nov 2004 18:19:27 GMT

Server: Apache/2.0.47 (Fedora)

Banners and commands

OS

• What is fingerprinting ?

• All TCP stacks respects RFC

• What about special cases ?

• SHOULD and MAY directives

• Unspecified behavior or values

• De facto standards

• Fingerprinting relies on each stack specificity

• Test each stack and establish a fingerprint

• Then compare results found on the field

• If an existing fingerprint is found then OS is identified

Fingerprinting

OS

• TCP based techniques

• ISN generation algorithm

• Initial TCP window size

• TCP options

• TCP SYN-ACK retransmit delay

 Tools : nmap, chronOS

• ICMP based techniques

• ICMP error message echoing (size + integrity)

• DF Bit echoing in error or replies messages

• IP ID and TTL values in ICMP messages

 Tool : Xprobe

Fingerprinting

OS

• Vulnerabilities are specific

• The exact application must be identified

• What works with apache won’t work on IIS

• The version is also important

• What works with apache 1.3.22 won’t work on apache 2.0.40

• Versions can reveal if application is patched or not

• Some applications may run on non standard ports

• Common for intranet web servers

• Remote management applications for security

• Banners may have been changed

Why scanning for applications

APPS

• Three points to analyze

• Each application has a specific behavior

• At most one unique method for identifying type, nature and

version

• A lot of research is necessary to find the way to

Problems with applications

APPS

• Banners

• As usual…

# 10.0.0.101Connected to 10.0.0.101

220 (vsFTPd 1.2.0)User (10.0.0.101:(none)):

• Commands are specific to most applications

• If the application running on port 11180 understand GET /, it is a

web server

• Errors are also specific to each type of applications

Generic Methods

APPS

• Most tools use banners

• Especially automated scanners such as nessus

• Some more advanced tools

• amap : application mapper based on specific triggers and

• httprint : HTTP server identification tool Based on fingerprints

Works under windows with a GUI!

On the field

APPS

• Identify by different ways

Advanced identification

Stealth Scanning

• Identification techniques

• On firewalls : dozens of red lines in logs = scanning

• IDS and the like : based on triggers…

• Ways to bypass detection

• Use techniques that cannot be detected by FW/IDS etc.

• Hide in a large load of logs

• Be discreet

• Find a goat

How not to get caught

STEALTH

Stealth scanning techniques

STEALTH

NO MORE

• Works with SYN and FIN scans

• Spoofed IP address

• Never mind the response

• Perform a lot of heavy scans

• They MUST be detected

• Performs exactly the same tests

• Will be detected

• BUT will be lost in the flood of fake systems

The use of decoys

STEALTH

• Fooling triggers

• Automated triggers

• Based on a ratio #of suspicious packets /s

• Just have to go slow

• -delay option on nmap

• Human triggers

• Based on visual detection in logs

• One packet from time to time with ≠ IP should be ok

Discretion

STEALTH

• The IPID

• Administrative field in IP header

• Use to handle fragmentation

• Increased by 1 each time a packet is sent

• A host that doesn’t talk

• Each time you send a syn to a closed port you get a RST

• RST packet IPID increase by one each time

Blame the goat

STEALTH

Blame the goat

STEALTH

Blame the goat

STEALTH

Inline detection

Playing with the IP Stack

Inline

• Inline security system

• May act as a proxy at different levels

• L2 : for layer 3 equipements (firewalls-like)

• L3 : mainly NAT

• L4 : SYNCookies, stateful inspection

• L7 : application proxies

• Should behave like the proxied IP stack / Application

• Detection relies on IP Stack behavior

• ISN generation algorithm

• TCP window size

• TTL

CPU savings

Inline

• Some operations are CPU consuming

• Inline systems don’t perform them to save CPU

• L4 checksums are not calculated

• IP Stack : packet silently dropped

• Inline systems : packet analyzed

• Obvious attack with bad L4 checksum

• REJECTED by an inline security device

 Can be identified

Inline

• NAT are L3/4 devices

• They perform routing

• They appear on traceroute output

• TTL must not be decreased when a packet goes through a NAT

• PING + Traceroute identification

• Ping provides TTL = n

• Traceroute shows n+1 gateways

Fragmentation

Tricks

Why use fragmentation

FRAG

• IP Fragmentation

• To bypass devices that don’t reassemble packets

• Usually a question of performance

• Routers with ACL

• Only analyze 1st fragment looking for SYN

• IPS…

• L4 checksums are not calculated

• Application fragmentation

• Non fragmented IP packets

• Data split in different packet

• To bypass IDS/IPS etc.

IP Fragmentation

FRAG

• Tiny Fragments

• Based on the RFC

• A packet can be as small as 62 bytes

= 20 (HP HDR) + 40 (IP OPTIONS) + 2 (TCP HDR : no flags)

• Fragment overlapping

• Based on BSD stack misbehavior

• When a fragmented packet overlaps a previous one

• The previous packets content should remain intact

• In BSD the upcoming packet content overlaps the previous

• Overlapping

1 packet with no SYN flag and more frags is sent

2 another one (not analyzed) with TCP header overlapping

L7 Fragmentation

FRAG

• Reassembly pitfalls

• Fragments are left in memory

• Analysis device may run out of memory

• Full L4 analysis is mandatory

• Packets with bad values (ex checksum) may be sent to hide

an attack (insertion attacks)

• Scramble a signatures

• Network environment awareness may be needed

• Packets that will not reach the target (because of TTL or MTU)

may be inserted to confuse the detection engine

ISN Prediction

&

Spoofing

Spoofing basics

SPOOFING

• Objective

• Bypass IP address based filters

• Use IP address based authentication credentials

• Hijack running session

• Local spoofing

• Simple IP configuration changes

• Need to DoS the “spoofed target”

• Need sniffing for hijacking (+ ARP poisoning on switches)

• Remote spoofing

• Usually blind spoofing

• Attack must be in one L7 command

Spoofing basics

SPOOFING

ISN Prediction

SPOOFING

• Theoretically impossible

• RFC says it should not be predictive

• Use of random functions should create a universe to large

• But…

• Stacks implementations differs

• Old TCP/IP stacks remain with vulnerable implementations

• Increased by fixed offset

• Based on time

• Additional SYN functionalities may be vulnerable

• SYNCookies …

OT : SYNCookies generation

SPOOFING

• SYNCookies prevent the use of connection tables

• No final ACK from source doesn’t mind anymore

• Final ACK out of time window is rejected

Evading Detection

Evasion techniques

EVASION

1 Insertion : add data to traffic to be analyzed

2 Elimination : kill the analyzer

3 Substitution : change/translate data

4 Fragmentation : split data

5 Confusion : mess the analyzer

• Can be applied

1 At network level

• Confuse stateful engines

1 Start a legitimate session

2 Interrupt it (RST) with TTL or MTU that won’t reach the target

3 IDS/IPS thinks session is over and don’t inspect following

packets

EVASION

• Kill the box

• Perform DoS attacks targeted at the IDS/IPS

• Classical DoS attacks

• Fill system partitions with logs

• Physical access may help…

• May not be the best solution with inline devices

EVASION

• Rely on applications capacity to understand data

• Ex ASCII encoding

http://target/ / /etc/passwd http://target/%2E%2E/%2E%2E/%65%74%63/%70%61%73%73%77%64

• Even IP obscusation

• 1.2.3.4 = 1*256^3+2*256^2+3*256+4

• Translation

• Mostly use locally

• Use “other ways”

• Ex echo * = ls …

EVASION

Seen Before

Bouncing

Scanning behind firewalls

BOUNCE

• Use FTP servers

• Via anonymous connection

• Need proxy activated

• Issue PORT, LIST commands

• Response code 150+ 226 : port open

• Response code 425 : port closed

Connect on Intranet web servers

BOUNCE

• Use open HTTP proxies

• Just change your browser settings…

• Variant

• Use navigation empowered scripts

• Provides anonymous surfing

• Best if works with HTTPS…

Covert channels

BOUNCE

• Use relays to cover your tracks

• Data are in the packet sent by the relay

• Use multiple relays make difficult to trace back to the source

ICMP messages quoting

BOUNCE

TCP Sequence numbers

BOUNCE

Denial of Service

Floods

• THE very flood

• Has always existed

• Works perfectly well

• Hard to mitigate

1 Send SYNs

2 Server opens an entry in connexion tables

3 Server sends SYN-ACK and waits for ACK in TIME_WAIT mode

4 Never send the ACK

5 Server table becomes full

 Server don’t accept new connections and drop existing ones

FLOODS

# hping3 syn rand-source p 80 <target> flood

Pending sessions

• Similar to SYNFlood

• The objective is to flood connexion tables

• Doesn’t focus on IP stack

• Targets applications resources

1 Complete 3-way handshakes

2 Maintain session open with a minimum of load

3 Application max connection will be reached

 Application don’t accept new connections

FLOODS

# webdevil <target> 80 10000

Legitimate sessions

• Generate huge amount of legitimate sessions

• May crash a server

• May crash applications

• Due to large amount of operations with the middleware

• May fill ISP uplinks

• Cannot be filtered

• Traffic redirection is of no use

• The flood will follow the new pipe…

• Need a lot of resources

• Need high bandwidth

FLOODS

Protocol Anomalies

How it works

• Send weird packets

• Years ago : a single packet could crash the box

• Ping of Death : fragmented UDP packets

• Teardrop : reassembled packet was oversized

• Boink : fragment offset was above total packet length

• Today : still use more CPU than normal packets

1 Create weird packets

2 Send them with huge load

 CPU reaches 100% usage

ANOMALY

# hping3 -SAFRU -M 0 -L 0 -p 80 10.0.0.3 flood

Reflection

What is reflection ?

• Use external systems

• Save attacker’s resources

• Uses more powerful systems

• Can take advantage of load-balanced systems

• In some cases can leverage the attack power

• 1  n ratio

• Difficult to trace back to the attacker

• May create more CPU consuming operations on the target

REFLECT

REFLECT

SYN reflection

• Server receives a SYN-ACK on an unknown connection

• Uses CPU to check connection

• Server sends a RST back

• Uses network resources

Application reflection

• Use application behavior

• Usually 1 request = lot of data

• TCP sessions may be an issue

• Establishing spoofed sessions is always difficult

• Establishing 100s of is impossible

• Focusing on UDP based applications

• DNS is perfect

1 Find powerful SOA DNS servers

2 Send spoofed DNS requests for ANY record

3 Wait…

REFLECT

DDoS & Worms

Legitimate traffic leveraging

• Use other’s computers and links

• Mass hack networks

• Scripting a new vulnerability is often enough

• Target universities…

• Install a program waiting for your commands

• Called zombies

• Stealthy idle on the target system

• Order zombies to connect to a web site

Automated DDoS

• Specific to some worms

• Automatically mass hack networks

• Auto-install the load

• Stealthy idle on the target system

• Programmed to generate traffic at a given time

• Automatically starts the flood

• CodeRed

• Designed to flood the white house web site

Worms