Foundations of Network and Computer Security


Nov 2, 2013 (4 years and 5 months ago)


Foundations of Network and
Computer Security

ohn Black

Lecture #23

Nov 22


CSCI 6268/TLEN 5831, Fall 2005


Today is “Thursday” (weird, I know)

Tomorrow is “Friday”

No class on Thurs

Project #2 is due on Nov 29

Quiz #3 is due on Dec 1

Project #3 is due on Dec 8
, last day of class

Lay of the Land

I normally talk about off
ones and
format string vulnerabilities and other

We’re short of time; same theme as buffer

I want to talk about other well
known and
highly relevant security issues in the
remaining three lectures

Password Crackers

Unix approach: store one
way hash of password
in a public file

Since hash is one
way, there is no risk in showing the
digest, right?

This assumes there are enough inputs to make
exhaustive search impossible (recall IP example from
the midterm)

There are enough 10
char passwords, but they are
NOT equally likely to be used

HelloThere is more likely than H7%$$a3#.4 because we’re

Password Crackers (cont)

Idea is simple: try hashing all common
words and scan for matching digest

Original Unix algorithm for hash is to iterate
DES 25 times using the password to derive
the DES key

(pass, 0
) = digest

Note: this was proved secure by noticing that this
is the CBCMAC of (0

under key ‘pass’ and
then appealing to known CBCMAC results

Why is DES iterated so many times?

Password Crackers (cont)

Note: Actually uses a variant of DES to
defeat hardware
based approaches

Note: Modern implementations often use
md5 instead of this DES
based hash

But we can still launch a ‘dictionary attack’

Take large list of words, names, birthdays,
and variants and hash them

If your password is in this list, it will be

Password Crackers: example











Pasword file










Making Things Harder: Salt

In reality, Unix systems always add a two
character “salt” before hashing your

There are 4096 possible salts

One is randomly chosen, appended to your
password, then the whole thing is hashed

Password file contains the digest and the salt
(in the clear)

This prevents attacking all passwords in
/etc/passwd in parallel

Password Crackers: with Salt











Pasword file










Table for Salt Value:

no match

Fighting the Salt: 4096 Tables

Crackers build 4096 tables, one for each
salt value

Build massive databases, on
line, for each

100’s of GB was a lot of storage a few years ago,
but not any longer!

Indexed for fast look

Most any common password is found quickly by
such a program

Used by miscreants, but also by sysadmins to find
weak passwords on their system

Getting the /etc/passwd File

Public file, but only if you have an acct

There have been tricks for remotely fetching
the /etc/passwd file using ftp and other

Often this is all an attacker is after

Very likely to find weak passwords and get on the

Of course if you are a

user, no problem

Removing the /etc/passwd from global view
creates too many problems

Shadowed Passwords

One common approach is to put just the
password digests into /etc/shadow

/etc/passwd still has username, userid, groupid, home
dir, shell, etc., but the digests are missing

/etc/shadow has only the username and digests (and
a couple of other things)

/etc/shadow is readable and writeable for root only

Makes it a bit harder to get a hold of

Breaks some software that wants to authenticate users with
their passwords

One might argue that non
root software shouldn’t be asking for
user passwords anyhow

BSD does things a little differently

Last Example: Ingres Authorization

Ingres, 1990


largest database company behind Oracle

Authorization Strings

Encoded what products and privileges the user had

Easier to maintain this way: ship entire product

Easier to sell upgrades: just change the string

Documentation guys

Needed an example auth string for the manual


There’s no defending against stupidity

Social engineering is almost always the easiest
way to break in

Doesn’t work on savvy types or sys admins, but
VERY effective on the common user

I can almost guarantee I could get the password of
most CU students easily

“Hi this is Jack Stevens from ITS and we need to change
your password for security reasons; can you give me your
current password?”

Social Engineering: Phishing

Sending authentic looking email saying
“need you to confirm your PayPal account

Email looks authentic

URL is often disguised

Rolling over the link might even pop
up a valid
URL in a yellow box!

Clicking takes you to attacker’s site, however

This site wants your login info

Disguising URLs

URI spec

Anything@ is
supposed to send you to

Can be used to disguise a URL:


Notice feel
good words

Length of URI exceeds width of browser, so you may not see
the end could be hex encoded for more deception

%77%77%77%2e%65%76%69%6c%2e%63%6f%6d =

Disguising URL’s (cont)

This no longer works on IE

Still works on Mozilla

In IE 5.x and older, there was another trick
where you could get the toolbar

window to show “” even though
you had been sent to a different site

Very scary

Moral: don’t click on email links; type in URL

Digression: Character Encodings

Normally web servers don’t allow things like this:

The “..” is filtered out

Character encodings can sometimes bypass the filter

Unicode is a code for representing various alphabets

. = C0 AE

/ = C0 AF


= C1 9C

In Oct 2000, a hacker revealed that IIS failed to filter
these encodings


Segue to Web Security

The web started out simple, but now is
vastly complex

Mostly because of client
side scripting

Javascript, Java applets, Flash, Shockwave,
VBScript, and more

And server
side scripting

CGIs (sh, C, perl, python, almost anything), Java
servlets, PHP, ASP, JSP

All of these are security


We Can’t Hope to Survey all
Possible Web Security Issues

Too many to count

Goal: look at a few thematic ones

Cataloguing all of them would not be very
instructive, most likely

Typical Server
Side Vulnerability

PHP: Personal HomePage (?!)

An easy
use and Perl
like server
side scripting

A “study in poor security”

Gary McGraw

Variables are dynamically declared, initialized, and
global by default; this can be dangerous:





Now we call this script with:



Javascript (and VBScript) can do bad things

Get your cookies, for one, which may include
sensitive information

You don’t want to run scripts unless the site you
are visiting is “trustworthy”

Javascript has had a large number of security
problems in the past; dubious sites might take
advantage of these

If you set your security level high in IE, it turns off
Javascript; that should tell you something

Javascript (cont)

Turning it off in your browser is one solution

But often you lose a bunch of functionality

How can an attacker get you to run his malicious
Javascript code?

Gets you to visit his website

But you might know better

Old trick: post something to a bulletin board with
<script>…</script> in it

When you view his post, you run his script!


To prevent this, a correct bulletin board
implementation always filters stuff that
others have posted

You can post <b>YES!</b> but not
<script> evil stuff… </script>

But until recently we didn’t worry about
filtering stuff from you to yourself!

XSS Attacks

XSS: Cross Server Scripting

Not CSS (Cascading Style Sheets)

Idea: you open a website, passing a value, and the
site echoes back that value

What if that value has a script embedded?!

Example: 404 Not Found

Suppose you see a link (in email, on IRC, on the web)
saying, “Click here to search Google”

The link really does go to google, so what the heck…

However the link is

Above contains an embedded, hidden script

Google says, “badurl%0a%5C…” not found

Just displaying this to you, executes the script

XSS Vulnerabilities

They’ve been found all over the web

Fairly new problem

Lots of examples still exist in the wild

Very tricky to find them all

Solution is to filter, of course

Need to filter inputs from users that server will
be echoing back to the user

Phishing Revisited

Dear Amazon User,

During our regular update and verification of the accounts, we could not verify your current information.
Either your information has changed or it is incomplete.

As a result, your access to buy on Amazon has been restricted. To continue using your Amazon
account again, please update and verify your information by clicking the link below :

Thank you very much for your cooperation!

Amazon Customer Support

Please note: This e
mail message was sent from a notification
only address

that cannot accept incoming e
mail. Please do not reply to this message.

Earth's Biggest Selection

Where does the info go? maps to IP

% whois

OrgName: Yahoo!


Address: 701 First Avenue

City: Sunnyvale

StateProv: CA


Defenses Against Phishing


Product out of Stanford

Doesn’t work for me (ugh!)

Detects various suspicious behaviors and flags them

Red light, green light depending on threshold

There are others as well

Bottom line:

Don’t believe emails from “legitimate companies”

This is frustrating for companies!

Wireless Security

Why is wireless security essentially
different from wired security?

Almost impossible to achieve physical
security on the network

You can no longer assume that restricting
access to a building restricts access to a

The “parking lot attack”

Wireless Security Challenges

Further challenges:

Many wireless devices are resource

Laptops are pretty powerful these days but PDAs
are not

Sensors are even more constrained

RFIDs are ridiculously constrained

Paradox: the more resource
constrained we
get, the more ambitious our security goals
tend to get

IEEE 802.11a/b/g

A standard ratified by IEEE and the most
used in the world

Ok, PCS might be a close contender

Also called “Wi

802.11 products certified by WECA (Wireless
Ethernet Compatibility Alliance)

Bluetooth is fairly commonplace but not really
used for LANs

More for PANs (the size of a cubicle)

Connect PDA to Cell Phone to MP3, etc.

Wireless Network Architecture

Ad Hoc

Several computers form a LAN


An access point (AP) acts as a gateway for
wireless clients

This is the model we’re most used to

Available all through the EC, for example

My Access Point

War Driving

The inherent physical insecurity of
wireless networks has led to the “sport” of

Get in your car, drive around, look for open
access points with you laptop

Name comes from the movie “War Games”

Some people get obsessed with this stuff

You can buy “war driving kits” on line

Special antennas, GPS units to hook to you laptop,
mapping software

More War Driving

People use special antennas on their cars

It used to be Pringles cans, but we’ve moved
up in the world

People distribute AP maps

War driving contest at BlackHat each year

Next Time You’re in LA

What’s the Big Deal?

My home access point is wide

People could steal bandwidth

I’m not that worried about it

People could see what I’m doing

I’m not that worried about it

There are ways to lock
down your access point

MAC filtering

signalling APs and non
default SSIDs

Wired Equivalent Privacy (WEP)

MAC Filtering

Allow only certain MACs to associate

Idea: you must get permission before joining
the LAN

Pain: doesn’t scale well, but for home users
not a big deal

Drawback: people can sniff traffic, figure out
what MACs are being used on your AP, then
spoof their MAC address to get on

Signalling APs

802.11 APs typically send a “beacon” advertising
their existence (and some other stuff)

Without this, you don’t know they’re there

Can be turned off

If SSID is default, war drivers might find you anyway

SSID is the “name” of the LAN

Defaults are “LinkSYS”, NETGEAR, D
Link, etc

Savvy people change the SSID and turn off beacons

SSID’s can still be sniffed when the LAN is active
however, so once again doesn’t help much

Let’s Use Crypto!

WEP (Wired Equivalent Privacy)

A modern study in how not to do things

The good news: it provides a wonderful
pedagogical example for us

A familiar theme:

WEP was designed by non
who knew the basics only

That’s enough to blow it

WEP Protocol

One shared key k, per LAN

All clients and APs have a copy of k

We are therefore in the symmetric key setting

Very convenient: no public key complexities

Has drawbacks, as we’ll see later

In the symmetric key model, what do we do
(minimally) for data security?

Authentication and Privacy!

(MAC and encrypt)

WEP Protocol

For message M, P = (M, c(M))

c() is an

CRC (cyclic redundancy check)

Compute C = P

RC4(v, k)

RC4 is a stream cipher

Think of a stream cipher as a “randomness stretcher”: give it n
random bits and it produces (essentially) infinite pseudo

The input is variously called the “seed” or the “key”

Seems a lot like a pseudo
random number generator!

We will look at RC4 in more detail later

v is an IV

As usual, the IV should never be repeated over the life of the key

Sender transmits (v, C)

WEP Decryption

Receiver obtains (v’, C’) and knows k

Computes C’

RC4(v’, k) = (P’


RC4(v’,k) = P’

Then checks integrity with P’ = (M’, c’) and
asking whether c’ = c(M’)

If not, reject the frame as inauthentic

Looks familiar, but we should be suspicious: a
keyless function is

a MAC!


Security Goals of WEP:



What we also have called “authenticity”

It should be “hard” to tamper with ciphertexts without being

It should be “hard” to forge packets

Access Control

Discard all packets not properly encrypted with WEP
(optional part of the 802.11 standard)

WEP Document:

Security “relies on the difficult of discovering the
secret key through a brute
force attack”

WEP Keys

802.11 was drafted when 40 bits were all
we could export

This restriction was lifted in 1998, but the
standard was already in draft form

Some manufacturers extended the key to an
optional 128
bit form

This is misleading: the 128 form uses a 104 bit key
because the IV is 24 bits

WEP Keys

Two forms: the 40 bit key

The “128” bit key



40 bits

24 bits



104 bits

24 bits

Recall: IV is
, so shouldn’t count as “key”

Entering WEP Keys

Note: Four keys allowed to encourage key
rotation, but this has to all be synchronized

among all users of the WLAN.

Goals Achieved:

Let’s start with the Privacy goal

WEP is using an encryption pad; what is the
cardinal rule of encryption pads?

So how might a pad be re

If the IV repeats, the pad will repeat:

Pad is RC4(v, k)

k is fixed for all communications

Since IV is public, an attack sees when the IV

IV repeats

It’s bad:

Some cards fix IV=0, end of story

(This is 802.11 compliant, by the way!)

Some cards re
initialize IV to 0 each time they are
powered up

So each time you insert a PCMCIA card into your laptop, or
power up your laptop

IV repeats in the lower range far more likely here

The IV is only 24 bits, so eventually it will wrap

byte packets, 5Mbps, IV wraps in less than 12 hours

With random IVs, the birthday effect says we expect a repeat
within 5000 packets (a few mins in the scenario above)

What to do with repeated IVs?

Build a “decryption dictionary”

Once we figure out the plaintext

Because it’s broadcast in the clear and encrypted

Because it’s part of a standard transmission

Because you injected the message from the outside

…then we know the keystream

Put keystream and IV into a table for later use

Allows quick decryption of any ciphertext where we know the
keystream of its IV

About 24 GB to store 1500 bytes for each of the possible 2


Note: it would probably be easier to brute
force the 40

But this approach works against the 104
bit key as well


Recall c() was a CRC

CRC’s are polynomials over a Galois Field of
characteristic 2; therefore they are linear over
addition, which in this field is


Function c has the following property:


y) = c(x)


This property lets us modify any ciphertext such that
the WEP integrity check will still pass

C = RC4(v, k)

(M, c(M))

We want to change M to M’

Altering WEP Ciphertext

Suppose we want M’ = M

instead of M

Compute C’ = C


, c(


Let’s check:

C’ = C


, c(


= RC4(v, k)

(M, c(M))


, c(


= RC4(v, k)


, c(M)



= RC4(v, k)

(M’, c(M


= RC4(v, k)

(M’, c(M’))

Note: we don’t need to know what M is to do
this; we can blindly modify M as we desire

Defeating the WEP Access

Recall that mal
formed WEP packets are
discarded (optional feature)

If we know

plaintext and its corresponding
ciphertext, we are able to inject arbitrary traffic into
the network

Suppose we know M, v, and C = RC4(v, k)


Then we know c(M) // c() is public and unkeyed

So we know RC4(v, k)

Now we can produce C’ = RC4(v, k)

(M’, c(M’))

Note: we are re
using an IV, but that’s ok according to
the WEP specification

Summary: WEP is no good

A tenet of security protocol design: “don’t
do it”

And after all this, I actually recommend
running WEP

It does create a barrier to the casual hacker

It doesn’t add much of a performance hit

It does give you legal recourse