CSE 451

CSE 451

Section March 2

Distributed Systems & Security

Overview

• Project feedback• Questions on project 3• Distributed systems• System Security

Project 2 feedback

• Need to bullet proof OS– Can’t assume resources won’t run out: file IDs,

address space IDs– Shouldn’t use any parameter without validation

• Including buffer sizes

– Need to test corner cases:• Running out of file Ids• Running out of physical memory• Loading programs too large for physical memory

• Writeups: generally good– Add introduction/conclusion– Add hints for next quarter

Questions on project 3

• I need to meet with every group this week

Distributed Systems

• People have talked about it since the 70s – why aren’t there more?– The web– File / print servers– Databases– Clusters

• It’s really hard…– Machines fail– Messages get lost– Machines get corrupted

Distributed System Impossibilities

• Attacking Generals Problem:– Deciding to attack – if both attack, win, if one

attacks, lose. Can only send messengers that may be killed or subverted

Attacking Generals

• It is impossible with a fixed maximum # of messages– You can never tell if your acknowledgement was

heard– Suppose you had a protocol that took no more than

12 messages, but messages could get lost. • The last message could get lost• Ergo, you didn’t need the last message

– If messages always get delivered, but one general is faulty (may die during decision making), you still can’t do it

• This is important: consider transactions

Byzantine Generals Problem

• Have multiple general trying to decide to attack. One or more may be traitors. Can they agree to attack?

Transactions

• Distributed transactions use “two phase commit”– First phase: ask participants to vote– If all vote “commit”, send out commit message. If

any vote “abort”, send abort message.– After vote to commit, participant changes must

survive crashes– To continue after failure, reboot and ask what the

vote was, or ask other participants to vote on what the decision was.

• It is impossible to survive partitions (machines disconnected from other participants) and not “block”

Distributed systems

• These kinds of results make things hard– Message get lost, and you don’t know where

(on a request or reply)– Messages get delivered out of order– Messages can take a long time to get

delivered– A very slow machine may appear dead– Failures occur in a distributed system that

don’t occur on a single machine, so distribution isn’t invisible

Security

• Security is also hard in a distributed system– How do you prove who you are?– How do you determine what someone

is allowed to do?– How do you secure your system

against attackers?

Proving who you are

• This is Authentication– On a single computer, just store passwords

in a file– On a distributed system, you don’t want to

send passwords over the network: they could be “sniffed”

• Three general approaches:– Secret key encryption– Public key encryption– Hardware

Secret Key Authentication

• Each person has a key that is secret but known to the service.

• Challenge response style:– S->A: random number– A->S {random number}Ka

• Kerberos style: use “tickets”

Kerberos

• Keys are only shared with a key distribution center.

• To authenticate:– A ->KDC: A,B,time– KDC->A {B,time,k}Ka, {A,time,k}Kb– A->B {A,time,k}kb, {time}k– B->A {time}k– A->B

Public Key Encryption

• Public keys: (asymmetric encryption)– One key encrypts, one key decrypts– One key kept private, the other key is

public– To “sign” a message: encrypt with

private key– To “seal” a message: encrypt with

public key of recipient

Public Key Authentication

• Uses certificates:– A->KDC: A,B– KDC->A: (PKB,B) skdc : a certificate– A->B: (na, A)PKB– B->KDC: B, A– KDC->B: (PKA,A)skdc– B->A: (na, nb)pka– A->B: (nb) pkb

What are you allowed to do?

• Two approaches:– ACLs: have a list on each object of who is

allowed access, and how much– Capabilities: get a ticket from someone that

gives you access, and present the ticket

• Both are used:– In NT: ACLs stored on all objects, used to

grant a Handle to the object– The Handle is a capability: the ACL isn’t

checked during access (e.g. read/write)

What are the common methods of attack?

• Local exploits• Network Exploits• Root Kits

Intrusion Tools

• Port Scanners (SATAN)– Remotely scan a range of addresses– Report on available services

• NFS, NIS, Sendmail, TFTP, RSH, X, FTP

– Report any known security holes– Can be detected (Courtney, Gabriel)

• Monitor traffic with TCPDUMP

Intrusion Tools (2)

• Host-based scanners (Cops, Tiger))– Checks for known local problems

• Insecure configurations (ACLs, Passwords)

• Known bugs in services• Signs of intrusion (modified binaries)

Remote Exploits

• Used to penetrate a machine with no local access (no existing account)

• Drives deployment of firewalls• Services that perform operations based

on unsecured user requests present vulnerabilities

• Examples:– Sendmail– IP spoofing (for authentication by IP address

only)

Local Exploits

• Goal: gain unauthorized privileges for an existing account

• Getting an account:– Social engineering (asking people for

passwords)– Trading passwords– Sniffing traffic

• Exploits derived from bugs that execution of hostile commands at a privileged level– Eg. Scripts running with SUID– Cracking passwords

Physical Exploits

• Attach machine to network & sniff• Reboot machine with floppy• Remove hard drive• Walk up to logged-on machine• Modifying hardware, or convincing

others to modify hardware

What are the exploits?

• Domain errors – exposing data (e.g. passwords in pagefile)

• Validation errors – not validating parameters (e.g. finger exploit)

• Serialization – checking access asynchronously (e.g. allowing object to change after access check)

• Authentication / Authorization errors – e.g SUID bit

• Boundary condition violation – exhausting a resource (e.g. subst DOS)

• Exploitable logic errors

Attack Process

• Reconnaissance– DNS zone transfer – copies DNS database– Search newsgroups for email addresses –

learn patterns

• Probe– Port scan using SATAN – often logged– Distributed port scan – many clients scan

same host– Check services for known vulnerabilities

Attack Process (2)

• Attack the vulnerability– Attack code can be executed on the

host in untrusted account

• Find local exploit with COPS / TIGER– Become root

Attack Process (3)

• Stealth– Modify logs to hide signs of attack– Replace binary files with modified versions that

don’t report attack• Eg. modify PS, netstat to not report process &

connections• Ensure future unlogged access

• Listening– Sniffers - monitor local network traffic– Snoopers - monitor local I/o (keystrokes, etc.) to

learn more accounts & passwords

• Spread attack to related hosts

What next

• Machines are used for future attacks:– Tribe Flood Network– Trin00

• Hackers remotely control a large network of computers, use them to coordinate attacks– Port scanning– Denial of service