Security

Evil Exists

• This may be the most important lecture in the course
  • Assuming you care about your data, your bank account, your reputation…
  • …and those of others
• 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
  • Please read [Schneier 2003] and [Schneier 2005] for broader, non-alarmist coverage
  • If you want the details, try [Thompson & Chase 2005] and [Skoudis 2004]
• Comment on this slide

What Are We Trying to Do?

• Security systems try to achieve many (often contradictory) goals
  • 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
• All three parts are important
  • 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
    • Example: best way to ensure villains can't access data is to erase it…
    • …which encourages people to write it down on scraps of paper
  • Have to design the system for the villainous minority
    • Any system that relies on trust will eventually be abused
    • Be honest: do you always put a quarter in the jar when you get a cup of coffee in the staff room?
  • Keeping track of how villains are trying to break in is (almost) as important as preventing them
    • A good way to find holes in your system
    • Often important to build an audit trail in order to take legal or disciplinary action
• Comment on this slide

Technology Alone Cannot Solve the Problem!

• This is the only exclamation mark in a topic title in the whole course
• Most successful attacks use social engineering, rather than technology
  • 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 most successful way to attack a system is to get a job with the company running it
  • Burn an extra copy of credit card data while backing up the server
  • Take notes of all the “to be fixed later” points that come up during the security audit of the web site
  • Many companies choose not to press charges, rather than deal with bad publicity after a security failure
  • Example: AOL employee sold 92 million customer records to a spammer for $100,000
    • Combination of inside job, and stealing the credentials of more privileged user
• Exploiting carelessness is the third
  • Many people don't bother to change the default password on their wireless router
  • Many more choose easily-guessed passwords
    • “Easy” if you have the right tools, that is
    • But remember: once one villain builds a tool, they can all use it
• In fact, technology often makes systems less secure
  • Example: facial recognition software 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
  • That's one false alarm every 30 seconds
  • How much attention do you think the guards will pay to the system after a week on the job?
• There is still a lot you can do, both as a user and as a programmer
  • This lecture concentrates on the latter
• Comment on this slide

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?
• Every exploit attacks one or more of these
  • Convince the system you are someone else
    • A 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
    • A browser bug lets Javascript in a page send copies of your cookies to a villain's site
• When analyzing security, look for ways to compromise the three A's
  • Use defense in depth
  • If your first security mechanism fails, is there another one behind it just in case?
  • Remember: the real purpose of a bicycle lock is to convince thieves to go and steal something else
• First step is always risk assessment
  • What is most important to you?
    • I.e., what will cause the most pain if it's broken, or broken into?
• Comment on this slide

Rule 1: Don't Trust Your Input

• Anyone who knows the URL of your web application can send it data
  • I.e., anyone who has a web browser, knows how to “View Source”, and can read HTML forms
• 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
• You must validate all of the input before using it
  • Check that all the parameters you expect, and only those, are present
  • Check that values meet constraints
    • You usually have to do this anyway
    • E.g., check that the string provided for “Atomic Number” actually represents an integer
    • Or that a villain hasn't replaced "price=399.99" with "price=3.99" in the query string
  • Make sure that special characters have been escaped
    • But watch out for double-escaping
    • And don't reinvent the wheel: every language's library has routines to do URL escaping, HTML escaping, etc.
• In practice, if input can't be validated, best to reject the request entirely
  • One exception: if your application is evolving, you might want to see if this input was meant for an old version
• Comment on this slide

Paths and I/O

• Always check filenames supplied by user
  • Just a special case of the preceding rule, but an important one
• Example: controlling access to documents
  • All your documents live below /web/docs
  • When you get a URL, you check that url[:9] == '/web/docs' to prevent people from accessing /home/dknuth/grades.xsl
  • So someone sends you /web/docs/../../home/dknuth/grades.xsl
  • Solution: normalize paths before using them, and then check whether the result lies in or below the directories you want to open up
  • Analysis: circumventing access control
    • But also using a weakness in authorization
    • The web server (which is running the CGI on the client's behalf) shouldn't have permission to read anything it doesn't absolutely need to
• Example: temporary files
  • While handling requests, a CGI creates a temporary file /tmp/1728397.cgidata (where 1728397 is a random number)
  • A villain with an account on the system writes a Python script that repeatedly looks in /tmp for *.cgidata files
    • When it finds one, it makes a copy for the villain to inspect later
    • Or overwrites its contents with fabricated data
  • Analysis?
• Comment on this slide

Rule 2: Never Run User Commands

• Suppose you want to build a search engine
  • Can't be bothered to look for strings in files yourself, so you run grep in a sub-process

  • #!/usr/bin/env python
    import os, cgi
    
    form = cgi.FieldStorage()
    term = form['term']
    cmd = 'grep %s data.txt' % term
    instream = os.popen(cmd, 'r')
    results = instream.readlines()
    instream.close()
    
    print 'Content-type: text/html\n'
    print '<html><body>'
    for line in results:
        print '<p>', cgi.escape(line), '</p>'
    print '</body></html>'
    

• What happens if someone sends a URL with "term=dummy /dev/null;rm -rf *"?
  • cmd becomes grep term=dummy /dev/null; rm -rf * data.txt
  • grep produces no output (since /dev/null is always empty)
  • Then the web server deletes everything it can, recursively
  • Oops
• Adding quotes around terms and escaping special characters hide the problem rather than eliminating it
  • Right solution: don't rely on external programs
  • More specifically, if there's a layer of interpretation between you and what you're running, then there's one more weak spot for a villain to attack
• Note that the same thing can happen even if you don't rely on outside programs
  • If expr is a string, eval(expr) interprets it as if it had been typed in then and there
  • Sometimes used to let people specify complex search criteria
    • HTTP request contains "criteria=record.left+record.right<0"
    • CGI plugs it into a standard loop

    • #!/usr/bin/env python
      import os, cgi
      
      form = cgi.FieldStorage()
      criteria = form['criteria']
      results = []
      for record in readRecords():
          keep = eval(criteria)
          if keep:
              results.append(record.title)
      
      print 'Content-type: text/html\n'
      print '<html><body>'
      for title in results:
          print '<p>', cgi.escape(title), '</p>'
      print '</body></html>'
      

  • But it has the same problem as using the shell
    • Exercise for the reader: construct an HTTP query string that will do something evil
• SQL injection is a variation on the theme
  • Your program expects a user name
  • Constructs SQL to query the database like this:

  • query = "SELECT * FROM Data WHERE Username='%s'" % username
    cursor.execute(query)
    results = cursor.fetchall();
    

  • But someone enters this as their user name:

  • fred'; UPDATE Employees SET Salary = 1000000 WHERE username = 'me

  • The resulting SQL is legal (all the quotes match), but probably isn't what the programmer wanted
• Cross-site scripting is the same problem in another guise
  • If a bulletin board or discussion forum lets you post HTML, you can include Javascript in it
  • When someone views what you wrote, their browser runs that Javascript
  • It can harvest information from your machine, and post it to the attacker
• Comment on this slide

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
• 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 systems
  • Publish one key, keep the other secret
    • The published key is called the public key, the unpublished one is called the private key
    • If you know how the underlying modulus is built you can relatively easily derive one key from the other.
  • Anyone who wants to send a message to you encrypts it using the public key
    • You're the only one who can decrypt it
  • Asymmetric systems can be used sign a message.
    • You send a text and append cypher of it encrypted with your private key.
    • Everybody can decript the cypher text with the public key and if it must be identical with the clear text.
    • Then it is guaranteed that the message was encrypted with the private key (unless the system is cracked).
    • It is also guaranteed that the clear text was not changed, e.g. to not buy 10 cars instead of 1.
    • Which is better then for regular signatures.

  • Figure 24.1: Secure Communication with Asymmetric Keys

• 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 transaction
• Comment on this slide

How Asymmetric Cryptography Works?

• Best know algorithm is RSA
  • Invented by Ron Rivest, Adi Shamir and Len Adleman in 1977 at MIT.
  • Where might the name RSA come from?
• Bases on Fermat's little theorem
  • For every a it is a ** (p-1) % p == 1 if p is a prime number.
• Now choose two large prime numbers p and q.
• Compute n = p*q.
  • How n is factorized is actually the important secret.
• Choose an integer e != 0 which is not disible by (p-1) and by (q-1).
• Compute an integer d such that d*e % ((p-1)(q-1)) == 1.
  • Therefore (a ** e) ** d == (a ** d) ** e == a (modulo n).
    • In other words, some text encrypted with e and than encrypted again with d returns to the original.
    • Same way, first encrypted with d and then with e gives the original.
• n and e are published.
• Factorizing n allows you to generate d.
  • If you can do this you get immediately an A in this course.
  • And most likely a Turing Award, a Fields Medal or a Nobel Prize.
  • And probably some trouble from secret services.
• Most people consider cracking RSA as complicated as factorization.
  • But there is no proof that you cannot crack RSA in another way.
• Which computers can factorize numbers in polynomial time?
• Comment on this slide

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) 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
• Another flaw in HTTP is its built-in password handling (called basic authentication)
  • Sends the user name and password as cleartext
    • Actually, encoded using base-64…
    • …but that's not a cipher
  • Never use HTTP basic authentication
  • Note: having users submit ID and password via a form is also insecure
    • 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
• Still not perfect
  • 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.?
• Comment on this slide

How do you login remotely?

• Data are send as cleartext in "rlogin" and "telnet".
  • Even account names and passwords are sent in clear text.
  • Everybody on the same sub-net can easily track them.
• Use "ssh" instead whenever possible.
  • Most machines these have only ssh, anyway.
• For the same reasons use "scp" instead of "ftp".
• Comment on this slide

Do and Don't

• Always consult an expert when designing a system that relies on encryption
  • Easy to use a perfectly good cipher in a way that either weakens the crypto, or provides no real security
  • Example: 802.11 wireless networking took a cipher that is secure when used correctly…
  • …and created a system which gives away both your data and your private key to eavesdroppers
    • Then they burned it into ROM on millions of devices
• Never rely on keeping your algorithm secret
  • Security must depend only on secrecy of keys
• Never design your own ciphers
  • Unless you have a Ph.D. in cryptography, in which case you should be teaching this section of the course
  • Use the best well-known ciphers—they have been thoroughly tested, and are more secure than anything you could invent
    • 3DES or AES for symmetric encryption
    • RSA, DSA, or EC-DSA for public-key
• Comment on this slide

Summary

• This lecture has only scratched the surface
  • Have discussed only a tiny fraction of the issues that programmers face
  • Haven't talked about user-level issues at all
• If you are going to do anything that's even a little bit complicated, please talk to a professional
  • The guy down the hall who once read an O'Reilly book on Perl doesn't count
• Comment on this slide