Lecture 10. Denial of Service Attacks (cont d) Thursday 24/12/2015

Transcription

1 Lecture 10 Denial of Service Attacks (cont d) Thursday 24/12/2015

2 Agenda DoS Attacks (cont d) TCP DoS attacks DNS DoS attacks DoS via route hijacking DoS at higher layers Mobile Platform Security Models Apple ios Security Android OS Security Windows 7, 8 OS Security

3 Review: IP Header format Connectionless Unreliable Best effort Min size around 20 bytes

4 TCP: Review: TCP Header format Session based Congestion control In order delivery Min size of TCP header around 20 bytes (assuming zero data)

5 Review: TCP Handshake

6 TCP SYN Flood I: low rate (DoS bug) Single machine: SYN Packets with random source IP addresses Fills up backlog queue on server No further connections possible

7 SYN Floods (phrack 48, no 13, 1996) Backlog timeout: 3 minutes Attacker need only send 128 SYN packets every 3 minutes Low rate SYN flood (around 102 Kbytes/s)

8 Low rate SYN flood defenses Non-solution: Increase backlog queue size or decrease timeout Correct solution (when under attack) : Syncookies: remove state from server Small performance overhead

9 Syncookies Idea: use secret key and data in packet to generate server SN S Server responds to Client with SYN-ACK cookie: T = 5-bit counter incremented every 64 secs. L = MAC key (SAddr, SPort, DAddr, DPort, SN C, T) [24 bits] key: picked at random during boot SN S = (T. mss. L) ( L = 24 bits ), mss: maximum segment size Server does not save state (other TCP options are lost) Honest client responds with ACK (AN= SN S, SN= SN C +1) Server allocates space for socket only if valid SN S

10 SYN floods: backscatter SYN with forged source IP SYN/ACK to random host

11 SYN Floods II: Massive flood Command bot army to flood specific target: (DDoS) 20,000 bots can generate 2Gb/sec of SYNs (2003) At web site: Saturates network uplink or network router Random source IP attack SYNs look the same as real SYNs What to do???

12 Prolexic/CloudFlare Idea: only forward established TCP connections to site

13 DNS DoS Attacks DNS runs on UDP port 53 DNS entry for victim.com hosted at victim_isp.com DDoS attack flood victim_isp.com with requests for victim.com Random source IP address in UDP packets Consequences Takes out entire DNS server What to do???

14 DNS DoS Solutions DoS resistant DNS design: (e.g. CloudFlare) With CloudFlare s authoritative DNS (serving 43 billion DNS queries per day): Built-in security including rate limiting, filtering, and blocking. (against DDoS web attacks) Global coverage Powerful functionality

15 DNS DoS solutions DoS resistant DNS design: CoDoNS: [Sirer 04] Cooperative Domain Name System P2P design for DNS system: DNS nodes share the load Simple update of DNS entries Backwards compatible with existing DNS

16 DoS via route hijacking YouTube is /22 (includes 2 10 IP addr) youtube.com is , Feb. 2008: Pakistan telecom advertised a BGP path for /24 (includes 2 8 IP addr) Routing decisions use most specific prefix The entire Internet now thinks is in Pakistan Outage resolved within two hours but demonstrates huge DoS vuln. with no solution!

17 DoS at higher layers SSL/TLS handshake [SD 03] RSA-encrypt speed 10 RSA-decrypt speed Single machine can bring down ten web servers RSA Encrypt RSA Decrypt

18 DoS Mitigation (1) CAPTCHA: Completely Automated Public Turing test to tell Computers and Humans Apart Idea: verify that connection is from a human CAPTCHAs are often used to stop bots and other automated programs from using blogs Applies to application layer DDoS [Killbots 05] During attack: generate CAPTCHAs and process request only if valid solution Present one CAPTCHA per source IP address.

19 DoS Mitigation (2) Source identification Goal: identify packet source Ultimate goal: block attack at the source (a) Ingress filtering Big problem: DDoS with spoofed source IPs Ingress filtering policy: ISP only forwards packets with legitimate source IP

20 DoS Mitigation (2) Source identification (b) Traceback Goal: Given set of attack packets Determine path to source How: change routers to record info in packets Assumptions: Most routers remain uncompromised Attacker sends many packets Route from attacker to victim remains relatively stable

21 DoS Mitigation (2) Source identification (b) Traceback Simple method Write path into network packet Each router adds its own IP address to packet Victim reads path from packet Problem: Requires space in packet Path can be long No extra fields in current IP format Changes to packet format too much to expect

22 (2) Source identification (b) Traceback Better idea DoS Mitigation DDoS involves many packets on same path Store one link in each packet Attackers Each router probabilistically stores own address Fixed space regardless of path length Routers Victim

23 Mobile Platform Security Models

24 Mobile Phone Market Share

25

26 Mobile Operating Systems Mobile OS Vulnerabilities Source: IBM X-Force, Mar 2011

27 Two Attack Vectors Web browser Installed applications Both increasing in prevalence and sophistication

28 Mobile Malware Attacks Unique to phones: Identify location Record phone calls Log SMS Similar to desktop/pcs: Connects to botmasters Steal data Phishing Malvertising

29 Comparison between Mobile Platforms Operating system Unix Windows Approval process for applications Market: Vendor controlled/open App signing: Vendor-issued/self-signed User approval of permission Programming language for applications Managed execution: Java,.Net Native execution: Objective C

30 Comparison between Mobile Platforms ios Android Windows Unix x x Windows x Open market x Closed market x x Vendor signed x Self-signed x x User approval of permissions x 7-> 8 Managed code x x Native code x

31 Apple ios From: ios App Programming Guide

32 Apple ios Security Device security Prevent unauthorized use of the device Strong passcodes Passcode expiration Data security Protect data at rest; device may be lost or stolen Hardware encryption Network security Networking protocols and encryption of data in transmission App security Secure platform foundation Runtime protection App sandbox prevents access to other app s data

33 ios Sandbox Limit app s access to files, preferences, network, other resources Each app has own sandbox directory Limits consequences of attacks Same privileges for each app

34 Android Platform outline: Linux kernel, browser, SQL-lite database Software for secure network communication Open SSL, Bouncy Castle crypto API and Java library C language infrastructure Java platform for running applications Also: video stuff, Bluetooth, vibrate phone, etc.

35 Android Security Features Isolation Multi-user Linux operating system Each application normally runs as a different user Communication between applications May share same Linux user ID Access files from each other May share same Linux process and Dalvik VM Communicate through application framework Intents, based on Binder, discussed in a few slides Battery life Developers must conserve power Applications store state so they can be stopped (to save power) and restarted helps with DoS

36 Android Security Features Application sandbox Each application runs with its UID in its own virtual machine Provides CPU protection, memory protection Authenticated communication protection using Unix domain sockets Applications announces permission requirement Create a whitelist model user grants access But don t want to ask user often all questions asked as install time Inter-component communication reference monitor checks permissions

37 Comparison: ios vs Android App approval process Android apps from open app store ios vendor-controlled store of vetted apps Application permissions Android permission based on install-time manifest All ios apps have same set of sandbox privileges App programming language Android apps written in Java; no buffer overflow ios apps written in Objective-C

38 Windows Phone OS 7.0 security model Principles of isolation and least privilege Each chamber Provides a security and isolation boundary Is defined and implemented using a policy system The security policy of a chamber Specifies the OS capabilities that processes in that chamber can access

39 Windows Phone OS 8 security model Services and Application all in chambers WP8 has a richer capabilities list

40 Overview of Four Chambers Trusted Computing Base (TCB) chamber unrestricted access to most resources can modify policy and enforce the security model. kernel and kernel-mode drivers run in the TCB Minimizing the amount of software that runs in the TCB is essential for minimizing the Windows Phone 7, 8 attack surface

41 Overview of Four Chambers Elevated Rights Chamber (ERC) Can access all resources except security policy Intended for services and user-mode drivers Standard Rights Chamber (SRC) Default for pre-installed applications that do not provide device-wide services Outlook Mobile is an example that runs in the SRC Least Privileged Chamber (LPC) Default chamber for all non-microsoft applications LPCs configured using capabilities