1) Evil Exists

• Computer security is a collective responsibility
  • A system is only as strong as its weakest component
  • If you are creating CGI scripts, or sending data over the web, you are putting others at risk as well as yourself
• Impossible to cover anything more than the basics in this lecture
  • [Schneier 2003] and [Schneier 2005] provide broad non-alarmist coverage
  • [Andrews & Whittaker 2006] and [Whittaker & Thompson 2004] are good practical guides to testing web software and security
  • [Thompson & Chase 2005] and [Skoudis 2004] go into more depth

2) You Can Skip This Lecture If...

• You understand the tradeoff between convenience and security
• You know that computer security is not primarily a technological problem
• You know what authentication, authorization, and access control are
• You never trust user input
• You know what public-key cryptography, HTTPS, and SSH are

3) What Are We Trying to Do?

• Goal: let everyone who should be able to do something do it easily...
  • ...while blocking people who shouldn't be able to...
  • ...and gathering information about their attempts
• Most people are trustworthy most of the time
  • Preventing legitimate users from doing things annoys them
  • If people are sufficiently annoyed, they'll turn security off, or find ways around it
• But we must account for the villainous minority
  • Any system that relies on trust will attract abuse
• Keeping track of how villains are trying to break in is (almost) as important as preventing them
  • You can't fix holes unless you know they exist
  • Often need an audit trail in order to take legal or disciplinary action

4) Technology Alone Is Not A Solution

• Many successful attacks rely on social engineering
  • Call up your bank, and see if you can get your credit card balance without your PIN
  • Helps if you sound like a grandmother who is close to tears because her poodle has just been hit by a car
• Second way to attack a system is to get a job with the company running it
  • Many companies choose not to press charges, rather than deal with bad publicity after a security failure
  • So burn an extra copy of credit card data while backing up the server...
  • ...or take notes of all the "to be fixed later" points that come up during the security audit of the web site

5) More Ways Security Can Fail

• And then there's carelessness
  • Many people don't bother to change the default password on their wireless router
  • Many more choose easily-guessed passwords
    • Where "easy" means "can be found by a clever program running for a couple of hours"
    • Remember: once one villain builds a tool, they can all use it
• In fact, technology can make systems less secure
  • Imagine a facial recognition system that works correctly 99% of the time
    • So one person in a hundred is mistakenly identified as a potential terrorist
  • 300,000 passengers a day in a busy airport means one false alarm every 30 seconds
  • Do you think the guards will still be paying attention to the alarms on Tuesday?

6) How to Think About Security

• Security systems are responsible for:
  • Authentication: who are you?
  • Authorization: who is allowed to do what?
  • Access control: how are authorization rules enforced?
• When analyzing security, look for ways to compromise the three A's
  • Convince the system you are:
    • Some other regular user (if you're trying to buy stuff with someone else's credit card)
    • An administrator (or someone else with special privileges)
  • Convince it that you're allowed to do something you're not
    • E.g., give yourself administrative privileges
  • Circumvent its enforcement of the rules
    • E.g., take advantage of a browser bug that lets Javascript in a page make copies of your cookies

7) Risk Assessment

• First step is always risk assessment
  • What could an attacker do?
  • How much would it cost?
• Example: WebDTR is a password-protected web interface to a database of drug trial results

Risk	Importance	Discussion
Denial of service	Minor	Researchers can wait until the system comes back up
Data in database destroyed	Minor	Restore from backup
Unauthorized data access	Major	If competitors access data, competitive advantage may be lost
Backups corrupted, so that data is permanently lost	Major	Redoing trials may cost millions of dollars
Data corrupted, and corruption not immediately detected	Critical	Researchers may make recommendations or diagnoses that lead to injury or death

Table 35.1: Risk Assessment

8) Thinking Like A Villain

• Good judgment comes from experience
  • But experience is just the name we give to our mistakes when talking to our grandchildren
• The books listed in the introduction describe attacks that have worked in the past
  • Use these to guide your analysis of your system

9) Example: Don't Trust Your Input

• Anyone who knows the URL of a web application can send it data
  • And can study its HTTP requests and responses
• There is therefore no guarantee that the HTTP request you receive was generated from your form
  • The input provided for a selection list may not be one of the values you offered
  • The input for a text field may be longer than the maximum you specified
  • Some parameters may be missing from QUERY_STRING, while unexpected ones may be present
  • QUERY_STRING may not even be formatted according to the HTTP specification

10) Attacking URLs

• Attacker looks at WebDTR URLs
  • Before logging in: http://www.webdtr.com
  • After logging in: http://www.webdtr.com/display.py?user=cdarwin
• Looks for a cookie from webdtr.com : none present
• Conclusion: user ID is being stored in the URL
  • Try surfing to http://www.webdtr.com/display.py?user=bmcclintock
  • Yup, we're in...

11) Leaking Information

• Now try http://www.webdtr.com/display.py?user=nobody?
  • Result is an error page saying "no such user"
  • Which means we have a way to see who's authorized to use the system
    • I.e., whose password it might be worth cracking
• What about the URL http://www.webdtr.com/display.py?user=?
  • Result is a page containing a stack track
    • Developer left cgitb (or its equivalent) enabled in the production system
  • Doesn't help normal users: stack trace doesn't tell them what they did wrong
  • But it does help attackers by telling them what functions are being called, what libraries are in use, etc.
• Every piece of information that leaks out of the application helps attackers find vulnerabilities

12) SQL Injection

• New version of WebDTR uses secure connections and encrypted cookies to close the holes identified above
• The URL used to look up a result is http://www.webdtr.com/display.py?testid=178923
  • What if the CGI looks something like this:

# marker:vdots
form = cgi.FieldStorage()
test_id = form.getvalue('testid')

query = "SELECT date,result FROM Results WHERE (id=%s)" % test_id

cursor = connection.cursor()
cursor.execute(query)
results = cursor.fetchall();
cursor.close();
# marker:vdots

• Set testid to "1);UPDATE Results SET result=FALSE WHERE (id=*"
  • Whole query is then "SELECT date,result FROM Results WHERE (id=1);UPDATE Results SET result=FALSE WHERE (id=*)"
  • Oops
• Mistake #1: CGI program has a capability (updating the database) it doesn't actually need
  • Good applications use the principle of least privilege
• Mistake #2: application failed to validate its input
  • Should have checked that testid's value was an integer, and in range

13) Attacking Defaults and Denial of Service

• Another attack is to see if default accounts or passwords are still enabled
• Try logging in with "admin" and "admin", or "guest" and "guest", etc.
  • Better yet, write a small script to try this
  • Helps (the attacker) if the results distinguish between "no such user" and "invalid password"
• Can use a script like this to run a denial of service (DoS) attack
  • Flood the server with login requests, so that legitimate users can't get access
  • Or their connections time out even if they do

14) Phishing

• Phishing is increasingly common
  • Trick users into giving away sensitive information
• Email someone you believe is a user of the system
  • "System crashed last night, click here to reset your password"
• The link actually sends them to http://www.webbdtr.com
  • Did you notice the difference in the host name?
• Phony site shows them the same login page as the real one
  • Records their password, then redirects them to the real system

15) Attacking Data Entry

• How is the database updated?
  • Files mailed in by clinicians are formatted and concatenated by a Python script
  • Results temporarily stored in /tmp/webdtr/0001.tmp, /tmp/webdtr/0002.tmp, etc.
  • Administrator periodically runs another Python script to load this data into the database
  • Backups are run twice a week
• Attack #1: mail in a file full of fake data
  • Administrator "authenticates" messages just by looking at sender address
  • Which is very easy to fake
• Attack #2: modify or replace one or the other Python script
• Attack #3: create a file /tmp/webdtr/9999.tmp
  • Does the script that loads the database check that sequence numbers are consecutive?
  • Does it check who created or owns the file?

16) Timed Attacks

• See a message on the WebDTR mailing list saying that the program now checks for attack #3 above

def read_file(filename, required_uid):
    '''Read submission data from a file, checking that the file
    is owned by the specified user.'''
    owner = os.stat(filename)[ST_UID]
    if owner != required_uid:
        raise SecurityException('%s has incorrect owner' % filename)
    stream = open(filename, 'r')
    data = stream.read()
    stream.close()
    return data

• There's a tiny window of opportunity between when the program checks ownership, and when it opens the file
  • Write a script that loops over files, deleting them and creating new ones in their place
  • Low chance of success on any one try...
  • ...but computers are very patient

17) Securing HTTP

• HTTP sends data as cleartext
  • As is too often the case, security was ignored in HTTP's original design
• Netscape later developed HTTPS (Secure HTTP) to protect confidential information
  • Uses a different port (443 instead of 80) and protocol (https in URL instead of http)
  • Encrypts data between the browser and the web server
  • Does not guarantee secure storage on the server
    • Far too many web sites store sensitive information in databases as cleartext
    • Gives villains another point of attack

18) Cryptography 101

• Encryption is the process of obscuring information so that it can't be read without special knowledge
  • Recovering the information is called decryption
• An algorithm for encrypting and decrypting is called a cipher
• Original and encrypted messages are called plaintext and ciphertext respectively
• All classical (pre-1970s) ciphers are symmetric
  • Same key is used for both encryption and decryption
  • Which means that the key can only be shared among trusted parties

19) Public-Key Cryptography

• Asymmetric ciphers have two keys
  • Each undoes the other's effects
  • (Practically) impossible to determine one given the other
• Asymmetric systems are often called public key cryptography systems
  • Publish one key (called the public key)
  • Keep the private key secret
• Note: symmetric encryption is typically many times faster than asymmetric encryption
  • Usual scheme these days is to use asymmetric encryption (slow) to exchange a one-time symmetric key
  • Then use the symmetric key (fast) for the rest of the conversation

20) Sending and Receiving

• Anyone who wants to send a message to you encrypts it using the public key
  • You're the only one who can decrypt it
  • Look up their public key in order to encode your reply

Figure 35.1: Secure Communication with Asymmetric Keys

21) Digital Signatures

• Key pairs can also be used to sign messages
  • Encrypt message using your private key, and append the result to the original message
  • Recipients use your public key to decrypt the signature
  • If it matches the message, you must have been the sender
  • Also guarantees that the clear text was not changed
    • Which is better then for regular signatures.
• In practice, encrypt a digest of the original message
  • Practically impossible for someone to construct a message that has a given digest
  

  Figure 35.2: Signing a Message

22) Securing Login

• Another flaw in HTTP is its built-in password handling (called basic authentication)
  • Sends the user name and password as cleartext
• Solution is simple: never use HTTP basic authentication
  • And never have users submit ID and password via a form, since form data isn't encrypted
• Alternative:
  • Have user provide ID and password over secure connection
  • Use a random number as a cookie
    • Do not just use a sequence of integer session IDs: too easy for attackers to fabricate
  • Give that to the client to track the session
    • When it comes back, use it as a key into a dictionary of active sessions

23) Red Queen Race

• If villains can snoop on network traffic, they can hijack sessions
  • Insert a copy of your cookie into their message
• Also vulnerable to replay attacks
  • Copy the cookie (or an entire message) and re-send it later
  • Useful if the message means "open the vault door"
• Note: none of this helps if there is spyware on the client machine
  • These days, this is much more likely than someone sniffing network traffic
  • Keep your anti-virus protection and spyware monitors up to date, and run them regularly
    • What else is there for your machine to do at 3:00 a.m.?

24) It Isn't Just The Web

• (In)security isn't just a feature of web-based applications
  • How do you know the software you've installed on your machine is reliable?
  • How would you find out if it had been tampered with during production?
• C and C++ have vulnerabilities that other languages don't
  • Best-known are buffer overflow attacks:
    • Attacker sends more data than the program has allocated memory to receive
    • "Extra" bytes overwrite the program itself
    • If those bytes' values correspond to machine instructions, the attacker can change the program's behavior

25) Summary

• Remember that technology doesn't solve security problems: it just moves them around
• Never rely on keeping your techniques secret to ensure security
• Never design your own ciphers
  • Use 3DES or AES for symmetric encryption
  • And RSA, DSA, or EC-DSA for public-key
• Most important: security has to be designed in from the start
  • And tested