Security

Tom Ferrin

April 9, 2012

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

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

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

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

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?

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

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 25.1: Risk Assessment

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

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

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…

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

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

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

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

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?

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

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

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

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

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 (link to figure)

Figure 25.1: Secure Communication with Asymmetric Keys

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 (link to figure)

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

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.?

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

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 (NIST standard - very secure)
- And RSA, DSA, or EC-DSA for public-key
Most important: security has to be designed in from the start
- And tested, tested, tested

BMI 280

Scientific Software Development