Download Network Hacking: Exploits, Intrusions and Defenses

Network Layer
Attacks and Defenses
Last updated: Thursday, 25 May 2017
© Prof. Amir Herzberg
(except where noted)
Computer Science Department, Bar Ilan University
http://AmirHerzberg.com
25/05/201704/10/06
http://AmirHerzberg.com
1
Lecture Outline

Vulnerabilities and Patches

Reconnaissance / Scan attacks

Packet filtering and firewalls

Intrusion Detecting Systems (IDS) and Evasion


Decoys / Honeypots
Not in scope (next topic):
Application vulnerabilities, attacks and defences
Complexity Breeds Vulnerabilities




Computer and network systems are complex
Everybody cares about security
But more about usability, functionality
Competitive market with limited penalty to bugs





Multi-vendor systems result in ‘finger pointing’
Bugs and vulnerabilities are common, expected
Limited risk of liability, impact on reputation
Fix security in new release/system  increase
revenues
Result: Many vulnerabilities, exploits and attacks
Knowledge is Power: Bug, Exploit, Fix


Many vulnerabilities, exploits and attacks
Myth: All systems have bugs, attackers find bugs
quickly



Patch/new version quickly after exploit detected
But then attackers find new bug…
Mythical timeline:
NewOS/App ver1.0
NewOS/App ver1.1 (patch)
Detected
Bug found, exploited
Time
Detected
Bug found, exploited
Time
Knowledge is Power: Myths & Reality



Many vulnerabilities, exploits and attacks
Myth: hackers easily break any system, defense
Reality: vulnerabilities are exceptions, easy fix



Bugs due to complexity, size, negligence
Patches often installed late (why? Lazy/reliability)
Most exploits btw warning & patch install
NewOS/App ver1.0
Vuln. Detected
NewOS/App ver1.1
Time
Patch available
Exploit
Attack using Exploit
Time
Example: Some DNS Exploits History

1990: Poisoning by out-of-bailiwick glue RR or by spoofed
responses (with fixed port, incrementing ID) widely known






Bellovin writes on it, also notes that Berkley’s r-utils (rsh etc.)
depend on domain name from rDNS tree. Does not publish.
1995: Vixie, Bellovin publish attacks, propose in-bailiwick
restriction.
1997: In-bailiwick restriction, random ID fixed in Bind.
1999: Bernstein motivates, implements port randomization.
2005: Windows attacks exploiting poor validation. Patch.
2008: Kaminsky identifies attack (Feb). Patches: ~June.
Exploits: ~July. Official disclosure: August.


Patch only adds port randomization (like Bernstein)
 This isn’t enough (as pointed out by Bernstein at 2002).
Many servers not patched yet!
What of Auto-Install Patches?


Authenticated, signed download, version checking
Concerns:


Reliability
Convenience


Security



Windows: forced re-boot (if not admin)
Attacks by vendor (or malware/insider at vendor)
Increased risk (why?)
 Other approaches:


Disable feature till patch is `stable`
Install patches… but later

04/10/06
Tradeoff reliability vs. security
System/Net Management Vulnerabilities



So far we discussed product vulnerabilities
But often the weakness is due to poor management
Few (of many) examples:


Not installing patches (we just discussed)
From previous topic (sniffing & poisoning):




Open proxy (next)

04/10/06
Not invoking options, e.g. `port security` (prev. topic)
Placing DNS behind Sequential port assigning NAT
Open recursive DNS service
Generalizes open recursive DNS service
Open Proxy Vulnerability





Proxy: connects between client and server (e.g. HTTP)
Forwards responses to client’s IP address
Normally: service only to internal clients
Open proxy: connects any client
Two-way (send/receive) internal client spoofing

Goals: obtain access, use as `attack base`
6.6.6.x
10.0.0.x
127.5.5.x
Eve
Alice
Bob
(web server)
25/05/201704/10/06
http://AmirHerzberg.com
10
Summary: Knowledge is Power

Many vulnerabilities, exploits and attacks


Unrealistic to block all on all machines
Patch installation lag:


Attackers:



Due to unawareness, reliability, usability concerns …
Reconnaissance/scan: detect vulnerabilities, targets
Exploit
Defences: Detect and Block


Esp.: block scan!
Eve’s 1st Law: Avoid Detection!

Remove traces/logs…
Reconnaissance / Scan Attacks

Identify vulnerable configurations, applications, OS,
applications… and later exploit

Attacker’s goals: efficiency… and stealth


Intrusion Detection’s `Cry Wolf` Dilemma

Too many (false) alarms will reduce attention
External scans: only block & log
Most scans require just valid IP address

Even better: using (mostly) spoofed IP addresses



Eve’s first law: avoid detection
Examples – how to detect by scan:

Open recursive DNS servers

`unpatched` DNS servers
 Or behind Sequential port assigning NAT
25/05/201704/10/06
http://AmirHerzberg.com
12
Network Scans

Goal: detect connected computer (IP)



Or: detect `reachable’ application (by port)
Or: detect OS, appl, configuration, etc.
Network scanning cues…


Explicit self identification, e.g. HTTP header
Implementation differences, bugs




TTL, TCP init window size, MSS,…
Existence of response?
IP Scan / Sweep: Ping (ICMP), SNMP, other
Services and ports scans:


04/10/06
TCP Scans (normal or `stealth`, e.g. Syn -> SynAck -> abort)
UDP Scans; reply of ICMP `dest port unreachable` (if unused)
Detecting Services Scan

UDP / ICMP Scans:



TCP scans:





Send request, get reply – logged, load noticed
Or, send junk – ignored or ICMP ‘port unreachable?
Find open & exploitable TCP ports
Regular TCP connection – logged, load noticed, slow
Stealth scans: half-open connection scans or FIN
scans – not always logged
Log and detect also these events
MITM attacker can use random source IP

But spoofer must use real IP to get response
TCP Scans

Valid TCP connection scans



Connect, or `SYN-only’ (SYN-SYN/ACK-RST)
Responses: none (no machine), RST (closed), ICMP
Port Unreachable (blocked), Ack
Stealth TCP scans: try to avoid detection…





NULL (no flag)
FIN
XMAS (URG, PSH and FIN all set)
Standard response: RST if port closed, none if open
Windows: always sends RST


Cannot detect open port
But may detect Windows machine…
Predictable Challenge Scans

Detect, then exploit use of sequential identifier


Allows blind attacker to spoof responses




TCP: initial sequence number

If predictable, blind attacker can spoof data in TCP connections!
DNS: identifier, port in queries
IP: identifier field, used for defragmentation
Scan to detect sequential identifier (by old, buggy systems)



Perform (limited) MITM attack
Identifiers used to ensure `fresh` responses in:


In place of random identifier
Send two requests,
Validate sequential identifiers in responses
How can we exploit sequential IP ID?

04/10/06
Allows spoofed (dumb) port scan
Spoofed (dumb) port scan
• Scan by blind attacker (spoofed src IP)
– Against server (Bob), using sequential IP ID
Bob
Eve
“HTTP GET x.htm…”, SenderIP=6.6.6.6
“first packet of x.htm”, IP ID = 345
H
“second
packet of x.htm”, IP ID = 346
H NULL/XMAS, SRC=1.2.3.4 (spoofed)…
TCP
RST or none, ID=347
“HTTP GET x.htm…”, SenderIP=6.6.6.6
“first packet of x.htm”, IP ID = 348
H
“second
packet of x.htm”, IP ID = 349
04/10/06
The Net is Always Scanned!

IP addresses are constantly scanned




By attackers
By `good guys` (checking, selling security…)
Vulnerable PC `captured` in <1min
1st line of defense: NAT and/or Firewall

Placed between internal network (or PC) and Internet


NAT: most scan probes use unallocated port , ignored


Most NATs remember external IP, map to internal IP only
if external IP and dest port match entry
Firewalls: block suspect packets (next topic)

04/10/06
Prevent attacks on internal network (or PC)
Often firewall is also NAT
Lecture Outline

Vulnerabilities and Patches

Reconnaissance / Scan attacks

Firewalls


Definition, motivation

Packet filtering firewall: rules

Application firewalls
Intrusion Detecting Systems (IDS) and Evasion


Decoys / Honeypots
Not in scope (next topic):
Application vulnerabilities, attacks and defences
Firewalls – Keeping Attackers Out (1)





A secure / trusted machine
Placed on the communication path from a protected
network to the Internet
Controls, inspects and filters the communication
Attempts to prevent attacks from outside
Read RFC 2979, Behavior of and Requirements for
Internet Firewalls
04/10/06
Defense in Depth

Military term for multiple lines of defence



Allows detection




External firewall + inter-department firewalls
Intrusion Detection System (IDS) behind firewall
Cannot alert on each scan from Network (too many)
Redundancy
Damage control
Beyond blocking: resiliency, backup, recovery
Firewalls – Keeping Attackers Out (2)
Firewall (improved definition):
A secure / trusted machine, or module on a machine
 On the path between two or more networks / host(s)



Controls, inspects and filters the communication


One or both networks are protected by firewall
Can be used between departments to limit damage
Also: fixes common vulnerabilities, e.g. NAT,
randomizes ports and ISNs
To prevent / limit reconnaissance, exploits
04/10/06
Packet Filter: Router-Firewall

A router: forwards packets between two networks

Or even a bridge (no routing): `transparent FW`



No IP address, subnet…; less overhead, visibility
Most basic and common firewall
Filters packets to block/detect attacks
• Stateless filtering (simpler, fast) or stateful filtering

Filtering policy is often called “Access Control List”


Typically: specified as a list of rules
Rules are pairs: <Selector, Action>

Selector identifies which rule applies to the packet
Packet Filtering Policy and Rules

Packet filtering policy is often a list of rules




Each rule is a pair – selector and action


Often called Access Control List (ACL)
ACL:= Rule || ACL, Rule
Rules are usually processed by order
Rule:= Selectors  Actions
Selectors defines if the rule applies to the packet
As a function of values of fields in the packet
• Example: protocol=UDP, SrcPort=7 (Echo)


Actions defines what to do with the packet
• Example: silently discard (block echo requests)
Packet Filtering: Selectors

Selectors defines if the rule applies to the packet

Selectors:= Selector || Selectors {AND/OR} Selectors ||
(Selectors) || NOT Selectors

Allows composite selectors (with AND, OR, etc.)
A selector: = field operator value


Field := {SrcIP, DstIP, SrcPort, DstPort, Protocol, Flags,
ICMPType}, TTL, Length, Interface_in}

Operator := { =///>/…}
Value:= IPADDR || PORT || Protocol || Flag || Types|| Hops
Selector is a function of field in packet



Stateless rule: value is constant

Stateful rule: value can be variable, or: selector a function
Examples of Stateless Selectors

selector: = field operator value

Field := {SrcIP, DstIP, SrcPort, DstPort, Protocol, ICMPType},
TTL, Length, Interface_in}

Examples 1 [2]: protocol=UDP [AND DstIP=*.*.*.FF]


Example 3: Protocol=UDP AND DstPort=7 (Echo)


Block all UDP traffic [to broadcast address]
Block incoming UDP Echo requests (`smurf` attack)
Example 4: Protocol=ICMP AND ICMPType=8
(Echo)

Block incoming ICMP Echo requests (`fraggle` attack)
Internet Control Message Protocol







ICMP: Internet Control Message Protocol
Status, control between routers, hosts
Error handling and debugging protocol
Unauthenticated protocol
0
Echo Reply
Encapsulated in IP header
3
Destination
40 assigned types
Unreachable
4
Source Quench
Many exploits


04/10/06
E.g. DoS Amplification
attack, by echo request
to broadcast address
Details follow…
5
Redirect
8
Echo
11
Time Exceeded
Broadcast Amplification DoS Attacks

DoS attack using broadcast capability of UDP / TCP




Amplification: (blind) attacker sends 1 packet, victim
gets many
Implementations: Fraggle (UDP), Smurf (ICMP), etc.
Sending spoofed request ‘from’ victim’s IP address
Responses are sent to the victim
Src=192.3.3.5
Dst=193.5.6.255
Victim
192.3.3.5
Subnet 193.5.6.0/8
04/10/06
Packet Filtering – Actions

Actions define what to do with the packet:








Allow
Log
Alert response team
Discard (silently) [aka deny, drop]
Reject (e.g., send RST for TCP, or Port Unreachable)
Apply IP-sec tunneling (encryption, authentication)
(more)
Examples:


Block smurf and fraggle attack packets (UDP, ICMP broadcasts)
Block stealth TCP scans
Block TCP Stealth Scans

Recall: TCP stealth scans detect open TCP ports




NULL / FIN / XMAS segment
Standard response: RST if port closed, none if open
Windows: send RST to all
Possible firewall actions:




Reject (RST)
Discard (drop)
If (StlthCtr[SrcIP]++)>MaxStlth: add SrcIP to BlockIPList
 Reset StlthCtr[ ] periodically
 Another rule blocks all traffic with SrcIP in BlockIPList
Compare: the good, the bad and the ugly! [see notes]
Example: Anti-Scan, Broadcast Rules
Rule name / Intfc Src Src Dst DPort Protocol Flags Action
goal
IP Port IP
Stealth TCP
Scans (In)
Stealth TCP
Scan (out)
Block UDP
broadcast
Block ICMP
broadcast
in
156.6.7.6
04/10/06
156.6.7.7
144.4.4.4
out
Internet
Service Blocking Rules



Problem: Many attacks exploit vulnerable services
Solution: Block incoming requests
Also block outgoing requests to exploitable services



Identify by protocol (TCP/UDP/ICMP…), port
May fail for new services or non-default ports
Better: Allow only specific and essential services



And only to designated servers (often in DMZ, see later)
Block new and rogue services (e.g., P2P networks)
Really rogue services may hide

E.g. bot-nets use IRC but use port 80 (like http)
Some Vulnerable Services

A few (of many) examples of vulnerable services
Port
Service
Exploit
7
Echo
Denial of Service, with spoofed
source as victim
19
CharGen (random
character generator)
Denial of Service, especially by
sending from port 7 of victim
11
SysStat – list of
processes
Identify vulnerabilities
79
Finger
Bug lets attacker control (some)
machines
137-139
NetBIOS
Access to files, printers, etc
Block Outgoing Spam

No “Open Relay / Proxy / Port 25” service

Often blacklisted

Need to block both outgoing and incoming port 25


Some ISPs block only outgoing… spammer circumvent – how?
Send only authenticated mail:

From (authenticated) users


Rule
Per user quotas
Relay mail only from authenticated & trusted SMTP-sender
Intrfce
SrcIP
Dialup (1Mb/s)
156.6.7.6
25/05/201704/10/06
SPort
in
DstIP
DPort
Flags
Action
144.4.4.4
156.6.7.7
1Gb/s
(c) Amir Herzberg,
http://AmirHerzberg.com
38
Block, but how: Discard or Reject?

How to block suspect request?



Discard (silently)
Reject (send RST)
Discard better if packet was malicious



Don’t waste resources
Don’t expose existence
Source IP is often spoofed – don’t ‘attack’ it (victim)


Or risk being labeled as attacker, blacklisted…
Reject better if connection may be legitimate

04/10/06
Not to delay it
Example: Blocking Ident Protocol


IDENT protocol (to port 113) – resolves IP  Name
Invoked by many applications, e.g. rlogin, Windows


Rule
If fails, they (usually) use reverse DNS
Block: incoming? Outgoing? Discard or reject?
Intrfce SrcIP
SPort
in
156.6.7.6
04/10/06
156.6.7.7
DstIP
DPort
144.4.4.4
out
Flags
Action
Block Incoming Requests




How to block incoming requests?
First: TCP (connection-based services)
Later: UDP & ICMP (connection-less services)
To send a TCP request, must initiate connection





Usually the client initiates the connection
Note: FTP – server also initiates `data` connection
Internal clients initiate from inside
Attackers initiate from outside
Block incoming TCP connection requests
Block Incoming TCP Requests




TCP initiation is always by sending a SYN packet
Responder sends back a SYN-ACK packet
SYN bit is only set in these first two packets
Hence: Block incoming SYN packets without an ACK


Similarly: block (and alert!) outgoing SYN _with_ Ack
Exception: public servers (e.g., external Web servers)


Place them on separate subnet: De-Militarized Zone (DMZ)
We discuss DMZ later on…
Responder
SYN
Initiator
SYNACK
Block Incoming TCP Requests

Block incoming SYN packets without an ACK

And: if some OS also allows SYN with Ack (as 1st packet)?
Rule
Intrfce SrcIP
SPort
DstIP
DPort
Responder
SYNACK
SYN
Initiator
156.6.7.6
in
156.6.7.7
144.4.4.4
out
Flags
Action
Block UDP/ICMP Requests

Many UDP & ICMP vulnerabilities and attacks
How to block incoming UDP and ICMP requests?
Connectionless

Can use spoofed IP addresses (don't need reply)

Solution 1: Block all UDP, ICMP traffic




But some are critical (e.g. DNS)
Solution 2: Stateful filtering

Allow responses for limited time (after request)
Anti-Spoofing Rules (ingress/egress filtering)
IP source address spoofing threat
 ISPs and organizations should prevent spoofing
[Read: RFCs 2827, 3013, 3704]
• Ingress filtering: spoofed packets from customers




Not using assigned IP address
Block outgoing broadcasts ?
Many ISPs don’t ingress-filter, esp., for hosted servers,
domains

Legitimate use of unassigned IP (e.g. multihoming)
• Egress filtering: spoofed incoming packets from Net


Incoming packet using an ‘internal’ IP address
Incoming broadcasts
Legitimate Use of Unassigned IP
st
Source Addr: 1 example:
multihomed corporation
USA-ISP.net
Foo.com’s
Private
Net
The
Internet
MexISP.net
Legitimate Use of Unassigned IP,
2nd example: Mobile IP `triangle routing`
[See notes…]
DstIP: 132.3.3.4
Home IP
132.3.3.4
SrcIP: 132.3.3.4
DstIP: 156.4.5.6
Temp IP
156.4.5.6
DstIP: 132.3.3.4
MobileIP behind Ingress Filter:
Must Tunnel via Home
Server
144.5.5.6
DstIP: 144.5.5.6
Home IP
132.3.3.4
SrcIP: 156.4.5.6
DstIP: 132.3.3.4
Temp IP
156.4.5.6
DstIP: 144.5.5.6
Anti-Spoofing Rules (ingress/egress filtering)
• Egress filtering: packets from Net with internal src IP
• Ingress filtering: customer packet with unassigned IP
 Incoming and outgoing broadcasts
Rule
Intrfce SrcIP
SPort
in
156.6.7.6
04/10/06
156.6.7.7
DstIP
DPort
144.4.4.4
out
Flags
Action
Aggressive Ingress Filtering

When we really care



Firewall-to-firewall tunnel (often IP-Sec)



Under (DoS) attack
Against IP spoofing (of special hosts / networks?)
Identify by `code` attached to packets
Cryptographic MAC or random identifier
One sided filtering? Some ideas, e.g., using TTL...




Lengths of paths are almost fixed
Few initial choices of TTL, often same in a network
Fixed TTL in packets from network
Other TTL: suspect spoofed packet
Stateful Packet Filtering

Need state for many filtering tasks





We’ve seen: UDP requests/responses
Statistical identification of attack, source
Rate control – disconnect from DoS attacker (by IP)
Filtering fragmented IP packets
Blocking application-specific vulnerabilities

Requires application awareness



Must reconstruct and analyze application messages
Malicious content, e.g. viruses, spoofed web sites,
web attacks, etc.
Often done by application-level gateway (firewall)
Content Filtering by Appl Gateway /FW

Packet filter cannot identify application attacks



Solution: use separate module / machine





Messages may span multiple packets
Too complex, much processing, stateful
Application Gateway / Firewall
Content-filtering server
Web Application Firewall (WAF) – e.g. as proxy
Intrusion detection / prevention system (IDS/IPS)
Use packet filter to enforce content filtering /
application firewall

04/10/06
Prevent bypassing
(Web) Application Firewall: Goals

Virtual patching


Positive filtering




Input sanitization: remove control chars, restrict length
Allow only `clean` inputs (scripts)
Prone to interfere with usage
Negative filtering



Block specific vulnerability `outside` application
Block known attacks
Prone to miss new attacks
Intrusion prevention / detection [later]
04/10/06
Enforcing Application Gateways / WAF

Method 1: WAF (Web Application Firewall) as proxy





Client connects to gateway & gateway connects to
server
Simple to implement gateway
Client side WAF: requires configuration
Two TCP connections (overhead)
Method 2: Transparent application gateway / WAF



04/10/06
Client connects to server & gateway ‘captures’
connection
Usually a single TCP connection
Harder to implement but easier to deploy, faster…
WAF/Application Gateway as Proxy


Application gateway is ‘visible’ to client
Client application is configured to use gateway




Requires configuration
Sometimes automated
Example: HTTP proxy
Firewall prevents direct access
04/10/06
Application
Gateway
Rules Enforcing Use of HTTP Proxy


Force use of (filtering) web proxy
Allow only outgoing connections
Rule
Intrfce SrcIP
SPort
DstIP
DPort
Flags
Action
In2Prx
In2Net
P2Net
…
CNN.com
1.2.3.4
Proxy: 156.7.8.9
156.6.7.6
04/10/06
in
144.4.4.4
out
Internet
HTTP Transparent WAF Rules


Enforce WAF (& HTTP proxy) transparently
Allow only outgoing connections
Rule
Intrfce SrcIP
SPort
DstIP
DPort
144.4.4.4
04/10/06
156.6.7.7
in
Action
CNN.com
1.2.3.4
Proxy: 156.7.8.9
156.6.7.6
Flags
out
De-Militarized Zone (DMZ)

Blocking incoming requests is a good practice


But we may need to provide some public services:





Most vulnerabilities result from service exploits
External web
FTP servers
Incoming mail server
Domain name service, Others
Solution: De-Militarized Zone (DMZ)



04/10/06
DMZ is a network protected by firewall
DMZ contains public-accessible servers
DMZ is less secure, but it is separate
from the ‘Internal’ network
DMZ with Two Firewalls

First packet filtering firewall protects internal +DMZ



Preferably on different interfaces
Second firewall protects only the internal network
DMZ is ‘in border’ area
WWW
DMZ
WWW
04/10/06
Mail
DMZ with a Single Firewall


DMZ: separate interface of packet filter
Allow incoming connections:



Only from outside
Maintain separate internal servers (e.g. web, mail, DNS)
Except: sys-admin, (web)mail [separate DMZ?]
Mail
DMZ
WWW
04/10/06
WWW
Delivery
Agent
DNS
Incoming Mail Transfer Agent
Enforcing of Spam Blocking
MTA A:
outgoing
border
MTA
A
MTA
B
MSA
MDA
Alice
MUA
Bob
MUA
Domain
a.com
Domain
b.com
MTA of
a.com
MTA B:
incoming
border
MTA of
b.com
• Firewall rules force SMTP to / from domain
to pass via border MTA
04/10/06
(c) Amir Herzberg,
http://AmirHerzberg.com
Incoming SMTP Rules

Incoming SMTP (port 25)  to incoming border MTA

Allow SMTP (TCP port 25) from Internet to 144.4.4.4

Originator must be border MTA 144.4.4.4

Discard any other incoming TCP port 25 (probable attack)

Do not log / alert – expect many such attempts
Subnet 144.4.5.*
66.6.6.6
SMTP-Sender
MTA
25/05/201704/10/06
144.4.4.4
Incoming
Border
MTA
144.4.4.2
Local
DNS
(c) Amir Herzberg,
http://AmirHerzberg.com
144.4.5.1
Internal
MDA / MTA
65
Outgoing SMTP Rules

Outgoing SMTP (port 25): By outgoing border MTA

Allow TCP/25 from out-MTA 144.4.4.5 to Internet

Allow TCP/25 from MSA to out-MTA (144.4.5.5 to 144.4.4.5)

Discard and alert: any other TCP/25 from 144.4.5.*

DNS rules?

Any other traffic from out-MTA: alert
Subnet 144.4.5.*
WWW
144.4.5.5
MSA/MTA
25/05/201704/10/06
144.4.4.2
Local
DNS
(c) Amir Herzberg,
http://AmirHerzberg.com
144.4.4.5
Outgoing
Border
MTA
68
DMZ: Outgoing Connections

Block outgoing connections and alert



DMZ servers never open connections
Few exceptions (e.g. outgoing border MTA, NNTP)
May allow specific connections to internal servers


E.g., incoming mail (SMTP MTA) [but better `pull`]
To / from specific IP & port: can place on separate DMZ
DMZ
WWW
04/10/06
DNS
Mail
WWW
Delivery
Agent
Incoming Mail Transfer Agent
DMZ Rules…
Rule
Intrfce SrcIP
SPort
DMZ
WWW
04/10/06
DNS
DstIP
DPort
Flags
Mail
Action
WWW
Delivery
Agent
Incoming Mail Transfer Agent
Limitations of Firewalls



Firewalls are very important
Firewalls are the first (external) line of defense
But – Firewalls cannot block all attacks


Firewalls cannot filter encrypted traffic (e.g., IPSec)




Unknown bug of useful application (e.g. Web)
Many firewalls support IP-Sec tunnel mode
Many firewalls use IP-Sec tunnel between Firewall
and Net
This fails if host also encrypts
Filtering depends on use of standards


04/10/06
Ports (to identify services), protocols and applications
Filtering fails if both ends collude
Firewall cannot Isolate Insiders, Trojans!
Corrupted
Internal PC
(Zombie)





Attacker
Consider malware behind the firewall (‘inside’):
Initiate communication to attacker’s site
Use port-spoofing or encapsulation to hide the communication
protocol
Encrypt if firewall scans content
If firewall monitors statistics to limit traffic:



firewall
Use multiple internal addresses
Sniff to pick up replies
Result: Firewall cannot protect against Insiders & Trojans
25/05/201704/10/06
http://AmirHerzberg.com
72
Intrusion Detection Systems


Content-filtering is hard, resource intensive
Very hard: blocking attack at real time


Performance (buffering) costs
Better: detect and respond to intrusion attempts



Intrusion Detection System
Preferably at reconnaissance (scan) stage
Or: to abort attack – Intrusion Prevention System (IPS)




Typically: filter out packets with suspect strings
Careful: avoid false-positives
At least: post-mortem analysis, evaluation of defences
Why is content-filtering so hard?

Attacker uses evasion techniques…
Content Filtering and Evasion

Content and application filtering:




Critical for security (block, detect)
Resource-intensive
Filter: known/suspect attacks (`signatures`), addresses
(`blacklist`), or attack-mechanisms
Evasion: avoid filtering, by…




04/10/06
Content morphing and encoding
 Content changes  signature mismatch
Content editing attacks
 FW/IDS sees one content, victim sees different
 Insertion/deletion attacks
 Fragmentation tricks, Request smuggling, …
Encrypted content
Overloading the IDS system (DoS)
Evasion by Morphing


Goal: prevent recognition of `attack signature`
How? `Morphing`– change attack string…

Object code (e.g. virus):




Scripts, etc.: easier… :




Most of its code is `encrypted` (randomized)
A tiny `loader` to decrypt, execute (too small to identify)
And/or: add no-ops, etc. (`obfuscate`)
Add spaces, change capitalization, e.g. `< ScRiPt >`
Different encodings for `same’ characters
Better: filter control chars (`<`) [except permitted tags]
 Identifying attacks by `signature database` is not
long-term viable !!
04/10/06
Evasion by Encoding Tricks





Non-standard encoding
UTF-8 encodes unicode as 1 to 4 bytes
Unicode 00000000 0xxx xxxx (Ascii)  1B UTF8 :
(0xxx xxxx)
Unicode: 00000yyy yyzzzzzz  2B UTF8: 110yyyyy
10zzzzzz
How to decode UTF-8 1100000y 10zzzzzz ?


04/10/06
WAF, standard: allow only shortest encodings
But server/client may accept also longer encodings!

E.g. IIS 4.0 / 5.0 Extended UNICODE Directory Traversal Vulnerability.

Decode as 0yzzzzzz
Evasion via UTF-7 Auto-Encoding


Another evasion technique: hidden UTF-7 encoding
Char-set of HTTP response defined by:

Explicit charset attribute in header or body



Content-Type: text/html; charset=3D[encoding]
Implicit, auto-encoding on detecting UTF-7 chars
Attack:




04/10/06
Response contains no explicit charset
WAF assumes no encoding, finds no script
Browser finds UTF-7 char, auto-decodes
Decoding reveals mal-script
Domain Blacklist Evasion

Domain blacklist: suspect domains, block request


Popular (IEv7, FF, … ), (currently?) effective
Domain Blacklist Evasion:


Change domains frequently
Redirect to IP address




From free web page, or even Google archive…
Negligible costs
 domain blacklists may not be a long term solution
What of IP blacklists?


04/10/06
Dynamic DNS, dynamic IP-address redirect
Zombies, dial-up
Evasion by `Content Editing` Attacks

Idea: filter (FW) sees `sanitized/edited` stream


Insertion: IDS sees `attXack`, victim sees `attack`


E.g. packet with `wrong` IP version (e.g. 2)
Merge/split, e.g. request smuggling



E.g.: packet with short TTL (dropped before victim)
Deletion: IDS sees `ack`, victim sees `attack`


Yet, victim receives `real` requests/responses
Victim (server) gets two requests
FW sees one request (2nd becomes part of 1st)
Fragmentation/partitioning tricks
04/10/06
IDS Evasion by Request Smuggling






Different parsing between WAF and application
server
E.g. IIS limits requests to 48KB
 Fixed/patched
Web Application Firewalls (usually) allow longer
requests
IIS considers data after 48KB as new request
Web Application Firewall considers it as body
(ignore)
Due to no separation between requests!

04/10/06
See: http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf
Evasion by Fragmentation/Partitioning


IP packet fragments, multi-packet request/response
Filters may fail to detect multi-fragment/packet
signature



Or: exploit implementation differences


Requires state, reconstruction by filter
If done… may be abused for DoS (waste state)
If receiving packet/fragment with already-received ID…
Use older or newer contents?
Common solution: block all fragments

`fragmentation considered harmful`
04/10/06
Evasion by Encrypting Content

Send attack over encrypted connection




Download over SSL/TLS (https://)
Attack over SSH
Filter sees only encrypted contents  can’t filter
`Solutions`:

MITM SSL content-filtering


04/10/06
(details)
Forbid encrypted traffic (e.g. SSH)
Intrusion Detection Systems (IDS)

Goals: detect, log, alert

Detect known attack signatures / patterns

Detect other attacks – based on heuristics & statistics

Critical: Must exhibit few false alarms


Otherwise they will be ignored
Basic types of IDS [compare?]:

Network-based IDS

Host-based IDS

Decoy IDS
Types of IDS – comparison



Network-based IDS:

+ Sees (all net) traffic (multiple dest, low-level)

- evasion techniques

- performance/cost (how to see traffic?)

- evasion techniques
Host-based IDS

+ detect attacks from within host

- only detect attacks to/from single host, visible to monitor

- Fooled by (smart) attacker controling machine!
Decoy IDS: great detection… of attack on the decoy…

Complements other tools… and must avoid detection!
Distributed Intrusion Detection System
App
GW
Remote
IDS
WWW
Host-based
IDS
Network
IDS
Decoy
IDS
DMZ
IDS
Mail
Manager
Intrusion Detection System monitor / manager
Intrusion Detection – Basic Approaches
• Detect Attack Signature



Analyze attacks, find identification marks/patterns
Example: CharGen (port 19) used only for attacks
Detects only identified attacks
• Detect Anomaly & Statistical Deviation




Learn (automatically) patterns of normal operation vs.patterns of
attacks
Use to detect attack or deviation from normal behavior
Challenge: acceptable false alarm rate
Limited success at detecting new attacks
• Decoy / Honeypot IDS

Detect any activity…
Anomaly Detection

Goal: Detect new attacks





Attack signatures are clearly better for known attacks
Learn patterns of normal operation vs. patterns of
attacks
Use to detect attack or deviation from normal
behavior
Much research – tools of machine learning
Problems:



Too few samples of `attacks`
Worse: would learning find new (other) attacks?
Can we test / benchmark?
False Alarms
• False Alarm

IDS alert on Non-Attack event: eNA
• False Positive Rate
• FP = Prob(IDS(e)=Alert) for eNA
• Number of false alarms is FP * |Log|
 Realistic numbers:






Log events: 1 million / day (even for small systems)
With FP of 0.1%, this gives 1000 false alarms (!)
Number of real (attack-related) events is much lower
System admin likely to ignore alerts
Must minimize log events & false positive rates
Limited success, especially for new attacks
Minimize Log Events


Focus on events after the firewall
Problem:





So why IDS?
Detect attacks by malware / insiders
Detect firewall failures (e.g. wrong rule)




Firewall blocks known attacks
And IDS is not too good on unknown attacks
May also use inner firewall to block these
But not the same firewall & rules
Post-mortem analysis and security evaluation
Correlate information and decoy/honey-pot IDS
Decoy / Honeypot IDS

Decoy / Honey-pot / Bait:





Decoy has no legitimate traffic





An object whose (only) goal is to:
Appear to be a desirable target for attack
Allow easy detection of attacks on it
Waste attacker’s resources in meaningless attacks
Traffic & modification  alert, log, analysis
Except: camouflage traffic
Decoys have few (or no) false alarms
Decoys detect new attacks
There are different types of decoys
Types of Decoys

Decoys for different objects






Email mailbox (for spam)
Addresses in address-book (detect abuse by malware)
Programs on computer (detect virus contamination)
File or records in DB (detect access / modification)
Host, router, application (detect access / change)
Real or virtual



Dedicating real subnet, host, router is expensive
Detecting access / modification is easier for a virtual
host or a virtual subnet
But – attacker may detect that this a virtual decoy
Using Decoys

Network Decoys

Waste attacker resources by simulating many hosts




Early detection
Detect new attacks
Detecting new malware




`Intrusion Prevention` (IPS)
Viruses – contaminating decoy program
Email parasites– decoy entry in address book
Worms – contaminate decoy programs, OS
Capture Spam and submit to filtering systems


Decoy mailbox or decoy host (e.g. HoneyD)
Danger of abuse by adversary for DoS
Zombies, BotNets and Worms

Zombies: compromised, controlled hosts


BotNet: Communication, Command and Control:




Often self propagating code: worms
Attacker control of Zombies
Often/usually use Internet Relay Chat (IRC)
IRC can efficiently send command to lots of hosts
Block IRC by packet filtering?

04/10/06
Fails for IRC over HTTP
Detecting and Blocking Worms


Worms are malicious programs (malware)
Propagates automatically between computers


Exploits enabling vulnerability in target computer


No human interaction needed to spread
Usually, in an application, e.g. buffer overflows
Three steps / elements:



04/10/06
Penetration: exploiting vulnerabilities (which?)
Infect: select and (try to) penetrate new victims
Payload: perform attacker’s function [optional]
Worm Attack, begin: 08:00
Immune
(e.g. Unix)
worm
Vulnerable
infected
04/10/06
Worm Attack, 1st wave: 08:01
Example: fan out = 3
04/10/06
Worm Attack, 1st wave results
Example: fan out = 3
04/10/06
Worm Attack, 2nd wave: 08:02
Attack about complete
Blocking now? Too late!
04/10/06
Worms: Need Automated Defense

Propagates automatically between computers


Can rapidly infect vulnerable hosts




No human interaction needed to spread
Slammer scanned 90% of Internet in 10 minutes
Fast worms: high infection rates loads, detection
Stealth worms: infect slowly avoid detection
Need: proactive defense against new worms



04/10/06
Automated Detection
Automated blocking (for fast worms)
Automated recovery (if we can)
Example: Code Red Worm


Conceals itself in HTTP Packets.
Exploits vulnerabilities in IIS






Microsoft’s Internet Information Server (IIS) v4&5
Specifically: buffer overflow vulnerability
By sending special URL
Installs itself, then infects other hosts
Multiple versions: CRv1, CRv2, Code Red II
Results:


04/10/06
DDoS attack, network latency
Backdoor installation
Attack with Detecting Hosts
Detecting host
worm
infected
04/10/06
1st Wave, 08:01
Upon detection:
Address blocking or Content filtering?
04/10/06
2nd Wave with Address Blocking
04/10/06
3rd Wave with Address Blocking
Attack complete: all vulnerable
hosts are infected
04/10/06
2nd Wave with Content Filtering
2nd wave – same results as with
Address blocking.
04/10/06
3rd Wave with Content Filtering
Attack Blocked!
04/10/06
Need Hi-Speed Detection & Recovery


Manual detection, recovery: too slow
Time is critical:



Hi-speed detection (and blocking):



To block – preferably, by content
To minimize damages, restore services
Automated – statistical (?), specific (e.g. buffer overflow - next)
Community-based, service ?
Hi-speed recovery:


04/10/06
Hardware remote re-boot
Software re-boot: using virtual machine
 e.g. Windows over Linux / `hardened` operating system
 Also to limit damages
Summary



Operating system and networks are complex
Complexity  vulnerabilities
Defense in depth


Separate




Block, detect & react, survive (redundancy), recover
Firewall: intranet vs. Internet, and inside intranet
Separate code from data, validate code
Separate between requests, responses, …
Understand adversary model
04/10/06