Kerberos, Software Flaws and Malware

CS166

Chris Pollett

Nov 26, 2012

Outline

Kerberos
Quiz
Software Flaws and Malware

Kerberos

We begin today by reviewing some material on Kerboros we started before Thanksgiving.
In Greek mythology, Kerberos is 3-headed dog that guards entrance to Hades.
In security, Kerberos is an authentication protocol based on symmetric key crypto
- Originated at MIT
- Based on work by Needham and Schroeder
- Relies on a Trusted Third Party (TTP)

Motivation for Kerberos

Authentication using public keys... `N` users implies `N` key pairs
Authentication using symmetric keys... `N` users requires (on the order of) `N^2` keys
Symmetric key case does not scale
Kerberos based on symmetric keys but only requires N keys for N users
- Con: Security depends on TTP
- Pro: No PKI is needed

Kerberos KDC

Kerberos Key Distribution Center or KDC
- KDC acts as the TTP
- TTP is trusted, so it must not be compromised
KDC shares symmetric key `K_A` with Alice, key `K_B` with Bob, key `K_C` with Carol, etc.
And a master key `K_(KDC)` knownn only to KDC
KDC enables authentication, session keys. -- Session key for confidentiality and integrity
In practice, crypto algorithm is DES

Kerberos Tickets

KDC issue tickets containing info needed to access network resources
KDC also issues Ticket-Granting Tickets or TGTs that are used to obtain tickets
Each TGT contains
- Session key
- User's ID
- Expiration time
Every TGT is encrypted with `K_(KDC)`
So, TGT can only be read by the KDC

Kerberized Login

Alice enters her password
Then Alice's computer does following:
- Derives `K_A` from Alice's password
- Uses `K_A` to get `TGT` for Alice from `KDC`
Alice then uses her TGT (credentials) to securely access network resources
Plus: Security is transparent to Alice
Minus: KDC must be secure -- it's trusted!

Kerberized Login

Key `K_A` = h(Alice's password)
KDC creates session key `S_A`
Alices computer decrypts `S_A` (so Alice knows `S_A`) and `TGT` then it forgets `K_A`
`TGT = E("Alice", S_A, K_(KDC))`

Alice Requests "Ticket to Bob"

REQUEST = (TGT, authenticator).
-- authenticator = `E(ti\me\stamp, S_A)`, Alice's machine knows `S_A` so computable
REPLY = E("Bob", `K_(AB)`, ticket to Bob, `S_A`)
-- ticket to Bob = `E("Alice", K_(AB), K_B)`
KDC gets `S_A` from TGT to verify timestamp

Alice Uses Ticket to Bob

ticket to Bob `= E("Alice", K_(AB), K_B)`
authenticator `= E(ti\m\e\stamp, K_(AB))`
Bob decrypts "ticket to Bob" to get `K_(AB)` which he then uses to verify timestamp.

Kerberos -- What's used for what

Key `S_A` used in authentication.
- For confidentiality/integrity
Timestamps for authentication and replay protection
Recall, that timestamps...
Reduce the number of messages -- like a nonce that is known in advance
But, "time" is a security-critical parameter
Clock skew is et to five minute by default. (Kinda long)

Kerberos Questions

When Alice logs in, `KDC` sends `E(S_A, TGT, K_A)` where `TGT = E("Alice", S_A, K_(KDC))`
Why is TGT encrypted with `K_A`? This inbolves extra work for no added security!
In Alices "Kerberized" login to Bob, why can Alice remain anonymous? (TGT only readable by KDC and says Alice)
Why is "ticket to Bob" sent to Alice?
Why doesn't KDC send it directly to Bob? (This way Bob does not need to remember it until Alice tries to connect)

Kerberos Alternatives

Could have Alice's computer remember password and use that for authentication?
- Then no KDC required
- But hard to protect passwords
- Also, does not scale
Could have KDC remember session key instead of putting it in a TGT
- Then no need for TGT
- But stateless KDC is major feature of Kerberos

Kerberos Keys

In Kerberos, `K_A = h(Alice's p\a\s\s\w\o\r\d)`
Could instead generate random `K_A`
- Compute `K_h = h(Alice's pa\s\s\w\o\r\d)`
- And Alice's computer stores `E(K_A, K_h)`
This alternative approach is often used -- but not in Kerberos

Quiz

Which of the following is true?

The ESP/AH phase of IPsec is used for mutual authentication
SSL guarantees mutual authentication
The Public Key variant of IKE phase 1 allows for plausible deniability.

Software and Security

Why is software as important to security as crypto, access control, protocols?
Virtually all of information security is implemented in software
If your software is subject to attack, your security can be broken
Regardless of strength of crypto, access control or protocols
Software is a poor foundation for security

Bad Software is Ubiquitous

NASA Mars Lander (cost $165 million)
- Crashed into Mars due to...
- ...error in converting English and metric units of measure
- Believe it or not
Denver airport
- Baggage handling system --- very buggy software
- Delayed airport opening by 11 months
- Cost of delay exceeded $1 million/day
- What happened to person responsible for this fiasco? (Promoted)
MV-22 Osprey
- Advanced military aircraft
- Faulty software can be fatal

Software Issues -- Good Guy/Bad Guy Roles

Alice and Bob
- Find bugs and flaws by accident
- Hate bad software...
- ... but must learn to live with it
- Must make bad software work
Trudy
- Actively looks for bugs and flaws
- Likes bad software...
- ...and tries to make it misbehave
- Attacks systems via bad software

Complexity

Some examples of numbers of lines of code

"Complexity is the enemy of security", Paul Kocher, Cryptography Research, Inc.
A new car contains more LOC than was required to land the Apollo astronauts on the moon

Lines of Code and Bugs

Conservative estimate: 5 bugs/10,000 LOC
Do the math
- Typical computer: ~3000 executables compiled from sources of over 100k LOC each
- Conservative estimate: 50 bugs/exe
- So, about 150k bugs per computer
- So, 30,000-node network has 4.5 billion bugs
- Maybe only 10% of bugs security-critical and only 10% of those remotely exploitable
- Then "only" 45 million critical security flaws!

Software Security Topics

Program flaws (unintentional)
- Buffer overflow
- Incomplete mediation
- Race conditions
Malicious software (intentional)
- Viruses
- Worms
- Other breeds of malware

Program Flaws

An error is a programming mistake.
An error may lead to incorrect state: a fault. A fault is internal to the program
A fault may lead to a failure, where a system departs from its expected behavior. A failure is externally observable
So we have: error --> fault --> failure

Example

char array[10];
for(i = 0; i < 10; ++i )
    array[i] = 'A';
array[10] = 'B';

This program has an error
This error might cause a fault, an incorrect internal state
If a fault occurs, it might lead to a failure -- Program behaves incorrectly (external)
We use the term flaw for all of the above

Secure Software

In software engineering, try to ensure that a program does what is intended
Secure software engineering requires that software does what is intended...
...and nothing more
Absolutely secure software is impossible. On the other hand, absolute security anywhere is impossible
How can we manage software risks?

Program Flaws

Program flaws are unintentional.
But can still create security risks
We'll consider three types of flaws:
- Buffer overflow (smashing the stack)
- Incomplete mediation
- Race conditions
These are the most common problems

Possible Buffer Overflow Attack Scenario

Users enter data into a Web form
Web form is sent to server
Server writes data to array called buffer, without checking length of input data
Data "overflows" buffer
- Such overflow might enable an attack
- If so, attack could be carried out by anyone with Internet access

Buffer Overflow

int main()
{
    int buffer[10];
    buffer[20] = 37;
}

What happens when this code is executed?
Depending on what resides in memory at location "buffer[20]":
- Might overwrite user data or code
- Might overwrite system data or code
- Or program could work just fine

Simple Buffer Overflow

Consider boolean flag for authentication
Buffer overflow could overwrite flag allowing anyone to authenticate
In some cases, Trudy need not be so lucky as in this example