! "#$$ %$ $$! &'%$ Prof. Amir Herzberg. Last updated: Sunday, December 18, PDF Free Download

! "#$$ %$ $$! &'%$ Last updated: Sunday, December 18, 2005 Prof. Amir Herzberg Computer Science Department, Bar Ilan University http://amirherzberg.com

"#$! %$ So far we considered attacks on the messages flowing thru the Net Spoofing, eavesdropping (intercepting / sniffing), Today attacks on hosts / networks: Intrusion attacks: gaining unauthorized access / control over host or network (and other `bug exploit attacks`) Denial Of Service (DoS) attacks: preventing host / network from providing (network) services, by exhausting resources The most common network attacks in practice Easier (or: harder to prevent no `end to end` solution) Many incentives for attackers Intrusion: unauthorized (malicious) use, ego, DoS: ego, hate, disrupt competitor/defenses,

# "#$! %$ Intrusions Intruders & Defenses Firewalls Malware, viruses Vulnerabilities and Intrusion Detection Denial Of Service (DOS) Syn Clogging Cookies, DOS and DDOS Broadcast and Echo (Smurf) DOS Attacks on Routing and Forwarding Traceback & Zombies

"#!$ Important, common threat! Insider: abuse by a person with authorized access to the system. Hacker: attack the via communication links (e.g. Internet). Malicious software (`MalWare`, Trojan horse, Virus): attack on the system by software running on it. Hacking Rule: Routine, everyday defenses are automated, weaker Try to avoid detection of attack!!

Intrusion Detection System (IDS) Blocking / Filtering Resiliency (and Proactive Recovery) Remote IDS Vulnerability Assessment Remote Logs Alert Sec Incident Response Team SW/Sys Audit, Testing Alert Reports Update Other IRT/ CERT Decoy IDS Alert Damage Detection and Recovery Remote Alert

('$ )%(! "#$

(' *!

+% ( (' Basic firewall function, at host or gateway Firewall filters packets, based on Access Control List (ACL ), e.g.: ACL:= Rule ACL, Rule; Rule:= Selector Action; Action {Deny / Pass / Log / Alert / IPSec(p) / Tunnel(t) / } * Selector:= Field {=///>/ } Value Selector {AND/OR} Selector (Selector) Field { SrcIP, DstIP, SrcPort, DstPort, Protocol, Flags, ICMPType}, TTL, Length, Interface_in, Interface_out } Value { {0,1,*} 32, {0, 2 16 }, {TCP / UDP / ICMP }, {SYN / ACK / FIN / RST } *, {8(echo), }, {0, 255} * }

(',-.-$ /#$0 First: define a security policy, e.g.: Block incoming TCP connections Except to public servers more later Block some/all UDP and ICMP packets, some outgoing TCP Based on application (ports), source/destination, time Block known vulnerabilities and unnecessary services, e.g. chargen Block possible attacks from within, e.g. spam (SMTP): block port 25 Anti-spoofing filtering: egress (outgoing), incoming External packet with internal IP address, internal packet with external IP Block ports based on application (personal FW only) Block short `Transport header` fragments (or reconstruct) Log some/all traffic Alert (CERT/other firewall) on suspect By statistics or by `signature` (attack pattern) Goals: correctness, efficiency, simplicity Usually processed sequentially specific first

# +% ( Stateless filtering rules are limited E.g.: can t block TCP data packet Dropped by TCP if no connection exists Even if connection exists if seq# not in window But: waste resources of internal network and host Worse for UDP (no source port, seq#) [block UDP?] Solution: Stateful packet filtering, e.g.: Pass only `good` TCP packets (within limits) Pass only UDP responses (identify by ports) Advanced firewalls: state may depend on payload Or: an application-level gateway solution

1'2$ Packet-filter allows appl packets only via GW Application-aware GW or transparent tunneling GW does appl-aware filtering. processing Example: virus-scan!!"# "#!! $% "# & 1. Allow only GW (e.g. to send http, ftp, smtp, requests) 2. Client app configuration (http proxy, socks, ) or transparent tunneling by packet filter 3. Gateway runs virus-scanner on incoming files

('! 34! 53 '( ) ( "! #!$ % $ "# SMTP WWW Intra DNS, WWW,. DNS ) (

,$ -%! 5 One packet-filtering FW is enough Use separate network to prevent sniffing, spoofing Server-only DMZ: e.g. WWW, incoming SMTP Not allowed to initiate traffic Mixed DMZ: e.g. SMTP, DNS Web Proxy SMTP WWW Incoming SMTP Intra DNS, WWW,. DNS ) (

-$ ('$ Firewalls are very important, visible first (external) line of defense from Net But Firewalls cannot block all attacks In particular can t block unknown bug of useful application (e.g. Web) Also: hard to block bug even with application GW: Need special code for each appl, vulnerability Sometimes, only `application fix` is reasonable Example of `unsafe software` and exploits

6$ $' #$! 7 $ Buggy application/system software may allow adversary to gain control, info or damage Solutions: Use safe programming methods, tools Use code inspected, certified by experts Notice: typical `code-signing cert` only identifies the source! Filter input to detect, block exploitation Typical bugs/exploits: Buffer overflow Server scripting / injection Cross-Site Scripting (XSS)

)# ' 8#$ Bug: no limit to input buffer size Attacker sends oversized input Causes buffer overflow Input overwrite other variables eventually also machine code Goal: replace existing machine code with Attacker s Thereby allowing attacker to install code at victim machine Problem: attacker does not know where existing code begins Solution: attack code begins with many NOPs (no-operation) Attack Input input: buffer NOP NOPOther variables NOP NOP NOP NOPExisting code NOP NOP NOP <`real` attack code>

"9 %$ Vulnerability: sites assume input is all textual, concatenate it `as is` to SQL query or script Attacker sends input with control characters, modifying the query/script Query: select?user=`&name` Abuse: input to &name is x` OR 1=1 Resulting query: select?user=`x` OR 1=1 Always true (e.g. returns first name in DB) Many sites vulnerable, many ways to exploit Solutions: Sanitize inputs before using them Suspect attack upon input with control characters

,$$.:0 %$ Vulnerability: sites allow attacker to send scripts, controls to user (browser) Inject script/controls e.g. by `File <filename> not found` Browser thinks this is code from server As JavaScript, VBscript, as <META> tag, Script may modify page, e.g. make it appear as login page May collect information from form, send to attacker May install or expose cookie And more Many sites vulnerable, many variants

4 -$ ('$ IP spoofing: router can t know if data really comes from claimed source Packet filtering is quite limited Can t understand app Can t identify initiator in UDP (disallow UDP traffic?) Gateways are hard No general rule: many app have unique vulnerabilities, need special gateway code New vulnerabilities exposed rapidly Can t filter encrypted traffic (SSL, IPSec, ) May use MITM SSL proxy (decrypt-scanencrypt) Insider attacks

(' "$ "$!$; <9$= & '& A corrupted internal PC (Trojan) can bypass firewalls: Initiate communication from inside Use port-spoofing or encapsulation to hide protocol Also application-spoofing to avoid local firewall (e.g. ZoneAlarm) Hide, encode `current attacker address` e.g. in public site Encrypt if firewall scans content (e.g. for known viruses) Use internal PC to `sniff`: passwords, port #, seq #... Firewall monitors statistics to limit traffic use multiple internal addresses to foil statistics, sniffing to pick up replies Other Trojans can be blocked / detected by firewall

>!$ % $ Prevent insider from sending\accessing information Content filtering (human, automated) and archival Often: prohibit & block encrypted traffic Attacker may use `covert channels` (stenography): Hide in image, text, etc. Random numbers (e.g. in authentication protocol), Timing Crypto-protocols w/o `covert (subliminal) channel` E.g. signing (for nuclear arms treaty inspections) Internet protocols with minimal covert channels Warden filtering at firewall active research, is it practical? & '& #

"$!.0 % 8#$$! 34'3 Malware: Malicious Software Goals: Trojan, Spyware, Adware, Spamware, Distribution: by user (bacteria), by instance in program and add to another (virus), by instance in one computer copied to another (worm), Execution: as object code; as macro/script; by user or automatically (e.g. by browser). Reality: most users, PCs are easily `infected` Protection? Easy and impossible

+ $ 34'3 Hoax, Bacteria: User (and sys-admin) awareness Proper warning by UI Filtering of known/suspect Worms Ideally: use secure OS, firewall to prevent & detect Worms scan for target (victim) machines avoid being target Hide IP address of internal servers / machines (using NAT) Stateful firewall: identify & block scan attempts (e.g. on DMZ) Restrict access to public servers (e.g. only TCP, no UDP) Prevent servers in DMZ from connecting outside (infecting) Trojans, Viruses: Detection vs. Prevention?

8#$$ #? Detection is computationally infeasible Identify malicious programs / viruses Identify programs that erase the disk, etc. Identify programs that may output programs Given programs P and Q, was Q output of P? Prevention could be easy with secure OS: Separation between `kernel` and `user` modes `User` mode apps use `kernel` API service Tricky part restrict outcome of `kernel` calls Restrict application operations (access control) Can t change OS, gain `kernel` mode, etc. Can t access data of other app, format disk, communicate Java: very limited `sandbox` for untrusted applets on JVM Use only signed, certified software Certification of identity (accountability) or of content (CVC)

+ $ 8#$$ Scan for known viruses (in PC, gateway, mail server) Problem: new viruses? Mutating (changing) viruses? Answer: try to detect mutating viruses by running them in `sandbox` and then scanning But: virus can mutate only randomly, on certain date/event, after much time or after some action, defeating scan. Prevent/detect changes to executables Problem: what about legitimate changes (e.g. by compiler)? Answer: most users never/rarely legitimately change But: prevention/detection not available in popular OS And: hard to add; harder to prevent virus from disabling Better: store OS, apps in read-only storage Periodical (proactive) re-installation of executables Preferably automated from read-only storage (e.g. CD-ROM) Usually managed by operator/server over network

' <9$? Dumb Trojan horses: use fixed port/pattern If listen - easy to block, attacker needs to scan to find it If sending - easy to detect use specific ports, patterns Published, `Readymade` Trojans: identify by `signature` Smart Trojans Act as http clients / browser, no fixed pattern / port Communicate back via `random` computer/server Attacker posts `talkback` IP address in public forums Even when mechanism is known, can t identify post Custom-built, very hard to identify Especially if not acting as virus/worm Don t let it inside `Trusted Computing Base`! Block new/suspect servers, with manual override

, %$ Malicious Software (e.g. Virus) Hacking (network attack) Penetration Often Easy May be hard Adversary Control Hard Easy Typical attack: Inject malware to victim organization (by Virus, Trojan) Virus initiates communication back to Adversary (over Firewall) Adversary now has access to internal network and hacks it

#2 3)# >3 Reality: insecure computers, OS, negligent users Virus/Malware can expose keys, disable security mechanisms Put security functions in external, dedicated device Authentication and encryption/decryption keys Filtering (access control, firewall, egress) Monitoring, log of events Management (updates, monitoring of PC, support) Use crypto (e.g. IP-Sec, SSL) to secure management of device Optionally: device appears as `drive` of computer (PC) E.g. PC `boots` from the device via USB port $ + Boot src:b dest:a,-. payload *

8#2 $$$$ 2$$ Intrusion Detection System (IDS) Blocking / Filtering Remote IDS Vulnerability Assessment CERT (Central Emergency Response Team) Reality: many security `holes`; exploited (mostly) after announced E.g. Blaster: 200,000 infection (8/2003), patch available for almost a month Too many vulnerabilities, patches for manual administration, penetration testing Monthly testing/scanning may have failed to stop Blaster `Hot` area (Gartner: most important security technology) Recommend: announce fix (disabling!) before announcing problem/patch Allows fix announcements by non-manufacturer experts VA system: detect known vulnerabilities, install (only) needed patches/updates/fix Automated, frequent update, install and scan (daily?) Problem: how to decide which updates/patches to install? Signed patch/fix, with identity and/or attribute certificates (define policy!) Problem: system reliability after patches (test/production???) Recommended: pre-defined graceful disable plan

"#$ 2$$ Intrusion Detection System (IDS) Blocking / Filtering Remote IDS Vulnerability Assessment CERT (Central Emergency Response Team) Goal: detect attack, alert CERT, VA, remote IDS, and maintain logs Detect known attack `signatures` (patterns) Signatures provided by CERT (secure how?) Detect other attacks heuristics, statistics Critical: low false positive rate (or: ignored by sys-admin) Sensitivity level set by CERT, alerts from remote IDS Consists of multiple IDS monitors, one or few IDS managers Exercise: how to authenticate communication between IDS manager, IDS monitors, CERT and remote IDS? Need `keep alive` to detect disconnection/disabling attacks

"#$ Identify known attack patterns (`signatures`) Attack patterns identified by operator Or sent from trusted source (e.g. CERT) authenticate! Identify access to `decoy` files, machines Detect unusual activity (statistical detection) Once attack is detected: Raise alarm to local administrator, CERT Block suspected / non-critical activities Counter-attack? tempting, but Attack may unintentionally damage third party Source of attack is often a victim (framed / broken) Serious attacker will be prepared much harder to attack Liability, ethics, exposure of techniques Identify source of attack (trace-back)

<%!2 % $# Problem: attack packets use fake source IP hide source of attack Prevent IP-spoofing: Sites should do egress filtering (in router) Authenticate source IP of locally-generated packets ISPs should do egress + ingress filtering Authenticate source IP of packets from customer Authenticate packets e.g. with IP-Sec ISPs rarely do any of these (performance/benefit) Traceback (when IP spoofing is possible) Random, active trace-back information from routers, or Request-based trace-back info from routers, or `Tricks` (unmodified routers), e.g. hop-count (TTL)

% ' 5$ Attacker uses multiple controlled machines (`Zombies`): To hide origin of attack / communication To foil defenses; e.g. avoid statistical detection of attack Denial of Service (later) Capture Zombies: Malware (virus etc.) Known vulnerabilities To identify attacker: Analyze Malware Attacker (Eve) Super- ZombieA Super- ZombieB Analyze (identified) Zombie messages Zombie1 Zombie2 Zombie3 Zombie4 Zombie5 Use statistics, load, known signatures, decoys Vic ( (

' %$ + 5$ Threat to hacker: exposure of (Super)Zombie Exposure of Attacker / Super-Zombie Subordinate Zombies Solution: Limit information in Super Zombies: Segregation Super-Zombie keeps only one key, no other data Identities, Zombie-keys sent (encrypted) to Super-Zombie Preventing trace-back from Zombie: Spoofed source address in command from Super-Zombie Anonymous posting Public anonymizers

2! < +$ Detect who talks to / buys from whom Prevent by aliasing, communicating via anonymizers Overhead; mainly for e-mail Gateway may delay, modify communication to prevent identification by timing, length etc. Use multiple gateways for added security Eve An (Anonymizer) Don Alice An An Bob Bob

2#$ $ Anonymizers may be traced back (subpoena) Alternative: post in one of the Net s public forums Semi-anonymous, short-term storage Using noisy medium to secure, hide messages Can t even detect message was sent / received Each posting appears innocent cf. to stenography, GPS Destination samples forums (medium), detects msgs Delayed action (so traces disappear, correlation hard) Use MAC to identify MAC k (msg) `Good` Applications: battlefield communication, hidden sensor network, privacy (e.g. ID tags)

+ <% 5.@0 Anonymous posting Public anonymizers Spoofed source address Spoofed e-mail address Attacker (Eve) Easy but allows IP trace-back Special `public e-mail anonymizer Spoofed IP address Easy for Eve to initiate Super- ZombieA Super- ZombieB Firewall should block incoming connections Zombie1 Zombie2 Zombie3 Zombie4 Zombie5 Harder for public servers in DMZ (ongoing work) Spoofing reply/connection: only MITM adversary Vic (#

# "#$! %$ Intrusions Intruders & Defenses Firewalls Malware, viruses Vulnerabilities and Intrusion Detection Denial of Service (DoS) Syn Clogging Cookies, DoS and DDoS Broadcast and Echo (Smurf) DoS Attacks on Routing and Forwarding Traceback & Zombies

%$ Attacker tries to disconnect communication or exhaust resources of host / server / router / user While wasting less resources (attacker usually weaker!) Resources include: Time (user s spam!), Computations (CPU time) Bandwidth (queue in router, token/frequency in MAC layer, ) Storage (e.g. for state of requests/connections) Open TCP connections

$ % +%, Sending excessive number of packets / requests Solution: when under attack Accept (new) packets/requests only from trusted sources Limit resource-use for each existing connection/source Problem: attacker use spoofed source IP address Solutions: For spoofing (not MITM) adversary: TCP handshake Identify packets of connection (no SYN, correct port, seq#) Spoofed packets discarded by TCP or by (smart) firewall For delayed-eavesdrop adversary `port hopping` Works (also) for UDP For MITM adversary: IP-Sec or TCP MD5 (MAC) extension

<,+ A& (! % A spoofing (not MITM) attack on TCP handshake Victim: a server accepting connections from Internet E.g. web server Attack: exhaust number of open TCP connections Limited to 10s to several thousand connections (depending on hardware, operating system) Which is why Servers `never` keep open connections In TCP session teardown, server closes fast (client waits) SYN flooding attack: attacker (as client) sends `SYN` flow (open connection); server waits

A&!.0 % Recall TCP connection setup process Spoofing Adversary sends many SYN requests (using different client IP addresses), no ACK Uses up server s capacity for open connections Q: what about intercepting (MITM) adversary? Server SYN with fake IP source address Hacker Sends SYN-ACK and waits

A&!,#$#$ Several ideas: SYN-cache, random drop, SYN-cookies [http://cr.yp.to/syncookies.html]: Server initial TCP seq# = client s seq# + top 5 bits: t mod 32, where t counts minutes; next 3 bits: identifies one of 8 Max-Segment-Sizes bottom 24 bits: MAC k (clnip,clnport,srvip,srvport,t) Prove spoofing req O(2 24 ) guesses (assume MAC is PRF) Accept SYN even if table is full, simply don t keep state reconstruct using cookie (seq#) Shipped with Linux and FreeBSD

,%$! %$ In general, cookies against spoofing adversary: MAC k (clnip,clnport,srvip,srvport,t) `Hashcash` cookies against intercepting adversary: Request w/o cookie: server sends back the cookie Idea: client `pays` for server resources, cookie is proof Example: cookie=x s.t. h(x, req, time)=*00000 But: recall attacker can use many Zombies Distributed Denial of Service (DDoS) Attack Also: attacker may simply send many requests by echo and broadcast amplification attacks Attacker Super- ZombieA Super- ZombieB Zombie1 Zombie2 Zombie3 Zombie4 Zombie5 Bob (victim)

)!$! B %$ IP convention: xx.xx.xx.255 broadcast Amplification Attack Abuse: Reach many computers with one broadcast% Waste more resources by making them echo Worse: use spoofed source IP address of `echo victim`, flooded by replies from `broadcast victims` Low-bandwidth source can kill high-bandwidth connections Third party hosts unwittingly aid attack a bit like Zombies% but without controlling them (yet)!

C#D*! B % ",4+ ICMP echo (spoofed source address of victim) Sent to IP broadcast address ICMP echo reply Internet Attacker Echo Victim Broadcast Victims

+ %$ Prevent attacks from/via your network : Apply filters to each customer network Apply filters to packets `bypassing` thru your Net Prevent being a broadcast victim ()bounce site*): Turn off directed broadcasts to networks Default in new routers Filter (drop) incoming ICMP echo requests Configure hosts to not reply to broadcast ICMP echo Prevent being an echo victim% Filter out ICMP echo replies, other known attacks Connect only to `filtering routers/networks/isps`

/$$ %$ Sufficient capacity, redundancy Multiple sites (distribution network) This is hard: insecure computers, viruses and Trojans distributed by spam, spam generated from zombies, a vicious cycle! Identify and filter attack packets (by `attack pattern/signature`) Identify source, use ingress filtering Network of DOS-resistant routers/isps Requires DOS-resistant routing and forwarding Next topic

# "#$! %$ Intrusions Intruders & Defenses Firewalls Malware, viruses Vulnerabilities and Intrusion Detection Denial Of Service (DOS) Syn Clogging Cookies, DOS and DDOS Broadcast and Echo (Smurf) DOS-Resistant Routing and Forwarding Traceback & Zombies

%$ /#! ('! DOS attacks can focus on host, network, gateway (firewall) or router/routing Router/routing attacks May go unnoticed (`silent disconnect`) May be easier (attack any router; TCP sensitivity to loss) Are on router routing or on forwarding functions Routing attacks: cause bad routing By spoofing router messages: prevent by auth By broken router: easy in theory, but BGP is robust Due to sending policies, limited topology Theoretical solutions also Distributed Algorithms course Or: disable routing completely How?

<,+ $ % )1+ TCP disconnects a connection if it receives RST/SYN packets with seq# (32 bits) in window TCP Disconnection Attack requires: Know/guess IP addresses and ports Server port and IP often known, source port & IP sometimes Some protocols (e.g. BGP) use fixed source port (179) Long-lived and critical connection over TCP Using large window (as in fast, reliable link with large RTT) Some claim this holds for Border Gateway Protocol (BGP) But does it (need to) use a very large window? And: prevent by proper filtering rules in BGP router Other spoofing-dos attacks on BGP, e.g. insert bad route Solutions: Use IP-Sec or TCP MD5 Option [RFC2385] Use ONLY TTL=255 on BGP packets (since they are one hop)

/#$ (! +!!,$ Robust (limited) bandwidth - no packet drop due to congestion Emergency and recovery applications Routing protocol itself (`Robust flooding`, [Perlman88]) How? Reserve one buffer for each <task,host> Hosts sign (numbered/dated) messages using special task key Can co-exist with `regular` routers But `regular` bandwidth still subject to DDOS Flooding is expensive Can we forward packets along efficient route? Router D Secure - Router A Router C Secure Router B Secure Router E Secure Router F

./#0 ('! (#$ Suppose attacker controls router in path Or: performs DOS attack on router (overload it) Forwarding fault: router simply drops packets! Currently: no detection/fix (silent disconnection) TCP: only end-to-end detection Also: after O(n TIMEOUT), not O(n DELAY+f TIMEOUT) Ack from every router along route [Perlman88] O(n 2 ) acks substantial overhead Ack intervals [HK] O(n log (n)) acks, but requires state in routers Research problems Make Ack intervals practical for ongoing connections More efficient authentication - randomly verify filtering by upstream routers

#2,#$#$ Filter suspected packets Based on known attack signatures (profile) Based on statistics, heuristic identification of attack Src-IP reported by servers (e.g. listen queue, random) Extend to whole prefixes if necessary Cookies: spend resources only if client did Trace-back to source of DOS attack (most likely an innocent, compromised machine) Maintain secure connections operative even when other connections are clogged Router network doing authentication and filtering Minimal guaranteed capacity for special hosts and (emergency, recovery) applications

,#$ TCP/IP designed to survive host/router crash, but No built-in authentication and confidentiality mechanisms Spoofing is easy Most connected hosts are insecure Potential for many zombies Vulnerable to DOS (esp. DDoS) attacks Including user-level DoS i.e. spam!!

! "#$$ %$ $$! &'%$ Prof. Amir Herzberg. Last updated: Sunday, December 18, 2005