Foundations of Network and Computer Security

hotbroodSecurity

Nov 2, 2013 (3 years and 7 months ago)

80 views

Foundations of Network and
Computer Security

J
ohn Black


Lecture #23

Nov 22
th

2005

CSCI 6268/TLEN 5831, Fall 2005

Announcements



Today is “Thursday” (weird, I know)


Tomorrow is “Friday”



No class on Thurs



Project #2 is due on Nov 29
th




Quiz #3 is due on Dec 1
st



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

Lay of the Land


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


We’re short of time; same theme as buffer
overruns


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
human

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


DES
25
(pass, 0
64
) = digest


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

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
cracked

Password Crackers: example

word

digest

alabaster

xf5yh@ae1

&trh23Gfhad

Hj68aan4%41

7%^^1j2labdGH

albacore

alkaline

wont4get

Pasword file

/etc/passwd

jones:72hadGKHHA%

smith:HWjh234h*@!!j!

jackl:UwuhWuhf12132^

taylor:
Hj68aan4%41


bradt:&sdf29jhabdjajK22

knuth:ih*22882h*F@*8haa

wirth:8w92h28fh*(Hh98H

rivest:&shsdg&&hsgDGH2

Making Things Harder: Salt


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


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

word

digest

alabaster

xf5yh@ae1

&trh23Gfhad

U8&@H**12

7%^^1j2labdGH

albacore

alkaline

wont4get

Pasword file

/etc/passwd

jones:72hadGKHHA%
H7

smith:HWjh234h*@!!j!
YY

jackl:UwuhWuhf12132^
a$

taylor:
Hj68aan4%41
y$


bradt:&sdf29jhabdjajK22
Ja

knuth:ih*22882h*F@*8haa
U%

wirth:8w92h28fh*(Hh98H
1&

rivest:&shsdg&&hsgDGH2
*1

Table for Salt Value:
A6

no match

Fighting the Salt: 4096 Tables


Crackers build 4096 tables, one for each
salt value


Build massive databases, on
-
line, for each
salt


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


Indexed for fast look
-
up


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
vulnerabilities


Often this is all an attacker is after


Very likely to find weak passwords and get on the
machine


Of course if you are a
local

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
Strings


Ingres, 1990


2
nd

largest database company behind Oracle


Authorization Strings


Encoded what products and privileges the user had
purchased


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

Moral


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
information”


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@http://www.colorado.edu is
supposed to send you to www.colorado.edu


Can be used to disguise a URL:


http://www.ebay.com
-
SECURITYCHECKw8grHGAkdj>jd7788<Account

Maintenace
-
4957725
-
s5982ut
-
aw
-
ebayconfirm
-
secure
-

23985225howf8shfMHHIUBd889yK@www.evil.org


Notice feel
-
good words


Length of URI exceeds width of browser, so you may not see
the end


www.evil.org could be hex encoded for more deception


%77%77%77%2e%65%76%69%6c%2e%63%6f%6d =
www.evil.com


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
and

URL
window to show “www.paypal.com” even though
you had been sent to a different site


Very scary


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

Digression: Character Encodings


Normally web servers don’t allow things like this:


http://www.cs.colorado.edu/~jrblack/../../etc/passwd


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


…/~jrblack/%C0AE/%C0AE/%C0AE/%C0AE/etc/passwd

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


Ugh

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
-
to
-
use and Perl
-
like server
-
side scripting
language


A “study in poor security”


Gary McGraw


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


if(isset($page))

{



include($page);

}


Now we call this script with:


script.php?page=/etc/passwd

Javascript


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!

Filtering


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 www.google.com/badurl%0a%5C...

»
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 :


http://www.amazon.com@service02.com/exec/obidos/subst/home/?EnterConfirm&UsingSSL=0
&pUserId=&us=445&ap=0&dz=1&Lis=10&ref=br_bx_c_2_2


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.


Amazon.com

Earth's Biggest Selection


Where does the info go?


service02.com maps to IP 66.218.79.155


% whois 66.218.79.155


OrgName: Yahoo!

OrgID: YAOO

Address: 701 First Avenue

City: Sunnyvale

StateProv: CA

NetRange: 66.218.64.0
-

66.218.95.255



Defenses Against Phishing


Spoofguard


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
network


The “parking lot attack”

Wireless Security Challenges


Further challenges:


Many wireless devices are resource
-
constrained


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
widely
-
used in the world


Ok, PCS might be a close contender


Also called “Wi
-
Fi”


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


Infrastructure


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
war
-
driving


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


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


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

Non
-
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
-
cryptographers
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
needed


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
unkeyed

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
-
random
bits


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))
©

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
not

a MAC!

Goals


Security Goals of WEP:


Privacy


Integrity


What we also have called “authenticity”


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


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

k

IV

40 bits

24 bits

k

IV

104 bits

24 bits

Recall: IV is
public
, 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
-
used?


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
repeats

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
around


1500
-
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
24

IVs


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


But this approach works against the 104
-
bit key as well

Authentication


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
©


Hunh?


Function c has the following property:


c(x
©

y) = c(x)
©

c(y)


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)
©

(M
©


, c(M)
©

c(

))


= 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
Mechanism


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


If we know
one

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)
©

(M,
c(M))


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