lecture 12 denial of service...

Lecture 12

Denial of Service Attacks (cont’d)

Sunday 8/5/2016

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

Review: IP Header format

• Connectionless

– Unreliable

– Best effort

• Min size around 20 bytes

Review: TCP Header format

• TCP:

– Session based

– Congestion control

– In order delivery

• Min size of TCP header around 20 bytes (assuming zero data)

Review: TCP Handshake

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

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)

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

Syncookies • Idea: use secret key and data in packet to generate

server SNS

• Server responds to Client with SYN-ACK cookie: – T = 5-bit counter incremented every 64 secs.

– L = MACkey (SAddr, SPort, DAddr, DPort, SNC, T) [24 bits] • key: picked at random during boot

– SNS = (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= SNS , SN= SNC +1) – Server allocates space for socket only if valid SNS

SYN floods: backscatter

• SYN with forged source IP ⇒ SYN/ACK to random host

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 ???

Prolexic/CloudFlare

• Idea: only forward established TCP connections to site

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 ???

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

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

DoS via route hijacking • YouTube is 208.65.152.0/22 (includes 210 IP addr) youtube.com is 208.65.153.238, … • Feb. 2008:

– Pakistan telecom advertised a BGP path for 208.65.153.0/24 (includes 28 IP addr)

– Routing decisions use most specific prefix – The entire Internet now thinks 208.65.153.238 is in

Pakistan

• Outage resolved within two hours … but demonstrates huge DoS vuln. with no solution!

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

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.

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


(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


(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


(b) Traceback

Better idea

• DDoS involves many packets

on same path

• Store one link in each packet

– Each router probabilistically stores

own address

– Fixed space regardless of path length

Attackers

Victim

Routers

Mobile Platform Security Models

Mobile Phone Market Share

Mobile Operating Systems

Mobile OS Vulnerabilities

Source: IBM X-Force, Mar 2011

Two Attack Vectors

• Web browser

• Installed applications

Both increasing in prevalence and sophistication

Mobile Malware Attacks

• Unique to phones: – Identify location

– Record phone calls

– Log SMS

• Similar to desktop/PCs: – Connects to botmasters

– Steal data

– Phishing

– Malvertising

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

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

Apple iOS

From: iOS App Programming Guide

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

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

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.

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

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

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

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

Windows Phone OS 8 security model

Services and Application all in chambers

WP8 has a richer capabilities list

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

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

Simple Quiz 1) When constructing a password you should:

– a. You should use your family member name, sports name, pet name and add a number on the end

– b. Use phrases or misspelled words with embedded numbers and special characters

– c. Use sequenced letters and numbers from your keyboard – d. All of the above

2) What are your responsibilities for the protection of company assets – a. Assist with the protection and proper use of information assets – b. Know the processes to protect information assets – c. Build proper security practices into your day – d. All of the above

3) You are sending confidential information to a colleague across the internet. How can you protect this message from being read by individuals other than the intended recipient ?

4) How can you protect against viruses?

Simple Quiz (Answer)

1) When constructing a password you should: – a. You should use your family member name, sports name, pet name and add

a number on the end – b. Use phrases or misspelled words with embedded numbers and special

characters – c. Use sequenced letters and numbers from your keyboard – d. All of the above

2) What are your responsibilities for the protection of company assets – a. Assist with the protection and proper use of information assets – b. Know the processes to protect information assets – c. Build proper security practices into your day – d. All of the above

3) You are sending confidential information to a colleague across the internet. How can you protect this message from being read by individuals other than the intended recipient ?

4) How can you protect against viruses?

lecture 12 denial of service...

Documents