Software Security

Topics 1. The problem of software security 2. System security standards 3. Secure development lifecycle 4. Simple Web Server 5. Economics of Security

Traditional Security is Reactive Perimeter defense

(firewalls) Intrusion detection Over-reliance on

cryptography Penetrate and patch Penetration testing

The Problem is Software “75% of hacks happen at the application.” - Theresa Lanowitz, Gartner Inc. “92% of reported vulnerabilities are in apps, not

networks.” - NIST “64% of developers are not confident in their ability to

write secure code.” - Bill Gates

CSC 482/582: Computer Security Slide #5

Why is Software Security poor? 1. Security is seen as something that gets in the way of

software functionality. 2. Security is difficult to assess and quantify. 3. Security is often not a primary skill or interest of

software developers. 4. Time spent on security is time not spent on adding

new and interesting functionality. 5. Characteristics of modern software: the trinity of

trouble.

Trinity of Trouble Connectivity

Ubiquitous Internet; wireless & mobile computing. Complexity

Networked, distributed code that can interact with intermediate caches, ad proxies, etc.

Extensibility Systems evolve in unexpected ways, e.g. web browsers,

which support many formats, add-ons, plugins, programming languages, etc.

Software Security Objectives 1. Dependability: software functions only as

intended; 2. Trustworthiness: No exploitable vulnerabilities

or malicious logic exist in the software; 3. Resilience: If compromised, damage will be

minimized, and it will recover quickly to an acceptable level of operating capacity;

4. Conformance: to requirements and applicable standards and procedures.

System Security Certifications Software system security certifications

Orange Book ISO 15408 Common Criteria PCI Data Security Standard (PCI DSS)

Many standards indirectly impact SSE FISMA (supersedes CSA of 1987) HIPAA (health information privacy) Gramm–Leach–Bliley Act (GLB) SOX (Sarbanes-Oxley)

Orange Book Trusted Computer System Eval Criteria

Issue in 1983 by NSA. Replaced by Common Criteria in 2005.

System classification levels D: failed evaluation for higher level classification C: discretionary protection Authentication, DAC, basic auditing

B: mandatory protection MAC, security policy requirements, auditing incl covert channels

A: verified protection Formal specification and design techniques with proofs

Common Criteria ISO standard 15408

International standard, used by US and others.

Protection Profile (PP) Description of system, e.g. anti-virus, firewall, smartcard

Evaluation Assurance Level (EAL)

PCI DSS PCI Data Security Standard (PCI DSS)

Proprietary security standard for organizations that handle card payment information for major credit and debit card companies.

Requirements Network security Cardholder data security Access control and auditing Security policy Vulnerability management, and Develop and maintain secure systems and

applications

Secure Development Processes CLASP (Comprehensive, Lightweight Application

Security Process) Correctness-by-Construction (formal methods

based process from Praxis Critical Systems) MS SDL (Microsoft Secure Development Lifecycle) SSE CMM (Secure Software Engineering Capability

Maturity Model) TSP-Secure (Team Software Process for Secure

Software Development) Touchpoints

Security Development Lifecycle 1. Code Reviews 2. Risk Analysis 3. Penetration Testing

Security Operations

Requirements Design Coding Testing Maintenance

Risk Analysis

Abuse Cases

Code Reviews + Static Analysis

Penetration Testing

Security Testing

4. Security Testing 5. Abuse Cases 6. Security Operations

Code Reviews A code review is an examination of source code by developers other than the author to find defects. Benefits

1. Find defects sooner in the lifecycle. 2. Find defects with less effort than testing. 3. Find different defects than testing. 4. Educate developers about vulnerabilities.

Static analysis tools can assist in finding security bugs.

Security in Design 1. Apply secure design principles throughout design

process, such as 1. Least Privilege 2. Fail-Safe Defaults 3. Defense in Depth 4. Separation of Privilege

2. Use secure design patterns where applicable. 3. Perform an architectural risk analysis to evaluate the

security of your design and to identify design changes that need to be made to improve security.

Designing-In Security Design features with security in mind

Not as an afterthought Hard to “add-on” security later

Define concrete, measurable security goals. Ex:

Only certain users should be able to do X. Log action. Output of feature Y should be encrypted. Feature Z should be available 99.9% of the time

Bad Examples: Windows 98, Internet

The Internet All nodes originally university or military (i.e. trusted) since it grew out of DARPA.

Security architecture of Internet designed for trusted env. With commercialization, lots of new hosts, all allowed to connect to existing hosts regardless of whether they were trusted.

Attempted to backport security with firewalls. Firewalls let in only traffic from trusted IPs to trusted ports. But can be bypassed by spoofed IPs, tunneling via allowed

ports, reverse-shells, etc.

Architectural Risk Analysis Fix design flaws, not implementation bugs. Risk analysis steps

1. Develop an architecture model. 2. Identify threats and possible vulnerabilities. 3. Develop attack scenarios. 4. Rank risks based on probability and impact. 5. Develop mitigation strategy. 6. Report findings

Black Box Testing Advantages of Black Box Testing

Examines system as an outsider would. Tester builds understanding of attack surface and

system internals during test process. Can use to evaluate effort required to attack system. Helps test items that aren’t documented.

System Test Input Test Output

White and Grey Box Testing White Box

Tester knows all information about system. Including source code, design, requirements. Most efficient technique. Avoids security through obscurity.

Grey Box Apply both white box and black box techniques.

Test Input Test Output

Penetration Testing Black box test of deployed system. Allocate time at end of development to test.

• Often time-boxed: test for n days. • Schedule slips often reduce testing time. • Fixing flaws is expensive late in lifecycle.

Penetration testing tools • Test common vulnerability types against inputs. • Fuzzing: send random data to inputs. • Don’t understand application structure or purpose.

Security Testing

Intendended Functionality

Actual Functionality

Functional testing will find missing functionality.

Injection flaws, buffer overflows, XSS, etc.

Security Testing Two types of testing

Functional: verify security mechanisms. Adversarial: verify resistance to attacks generated during

risk analysis. Different from traditional penetration testing

• White box. • Use risk analysis to build tests. • Measure security against risk model.

Security in Software Requirements Robust, consistent error handling always needed. Share requirements w/ QA team for security testing.

Handle internal errors securely – don’t provide useful

information via error messages to attackers!

“Security or Bust” Policy Microsoft delayed ship of .NET server in ’02 because

security requirements not met by “code freeze” deadline

Measurable Security Requirements

Access Control Security: Only certain users can perform specified functions

Auditing: Maintain log of users’ sensitive actions Confidentiality: encrypt certain functions’ output Availability: Certain features should be available

almost always (99.99%) or within specified time

Include these requirements in design docs!

Abuse Cases Anti-requirements

Think about what software should not do. A use case from an adversary’s point of view.

• Obtain Another User’s CC Data. • Alter Item Price. • Deny Service to Application.

Developing abuse cases Informed brainstorming: attack patterns, risks.

Security Operations User security notes

• Software should be secure by default. • Enabling certain features may have risks. • User needs to be informed of security risks.

Incident response • What happens when a vulnerability is reported? • How do you communicate with users? • How do you send updates to users?

Hypertext Transfer Protocol

Web Browser Web Server

Request document at URL

Return requested document

HTTP Request

GET http://www.google.com/ HTTP/1.1 Host: www.google.com User-Agent: Mozilla/5.0 (Windows NT 5.1) Gecko/20060909 Firefox/1.5.0.7

Accept: text/html, image/png, */* Accept-Language: en-us,en;q=0.5 Cookie: rememberme=true; PREF=ID=21039ab4bbc49153:FF=4

Method URL Protocol Version

Headers

Blank Line No Data for GET method

HTTP Response

HTTP/1.1 200 OK

Cache-Control: private

Content-Type: text/html

Server: GWS/2.1

Date: Fri, 13 Oct 2006 03:16:30 GMT

<HTML> ... (page data) ... </HTML>

Protocol Version HTTP Response Code

Headers

Blank Line

Web Page Data

Simple Web Server (SWS)

To illustrate what can go wrong if we do not design for security in our web applications from the start, consider a simple web server implemented in Java.

Only serves documents using HTTP

Walkthrough the code in the following slides

SWS: main

/* This method is called when the program is run from the command line. */

public static void main (String argv[]) throws Exception {

/* Create a SimpleWebServer object, and run it */

SimpleWebServer sws = new SimpleWebServer();

sws.run();

}

SimpleWebServer Object public class SimpleWebServer { /* Run the HTTP server on this TCP port. */ private static final int PORT = 8080; /* The socket used to process incoming connections from web clients */ private static ServerSocket dServerSocket; public SimpleWebServer () throws Exception { dServerSocket = new ServerSocket (PORT); } public void run() throws Exception { while (true) { /* wait for a connection from a client */ Socket s = dServerSocket.accept(); /* then process the client's request */ processRequest(s); } }

SWS: processRequest (1)

/* Reads the HTTP request from the client, and responds with the file the user requested or a HTTP error code. */ public void processRequest(Socket s) throws Exception { /* used to read data from the client */ BufferedReader br = new BufferedReader (new InputStreamReader (s.getInputStream())); /* used to write data to the client */ OutputStreamWriter osw = new OutputStreamWriter (s.getOutputStream()); /* read the HTTP request from the client */ String request = br.readLine(); String command = null; String pathname = null;

SWS: processRequest (2) /* parse the HTTP request */ StringTokenizer st = new StringTokenizer (request, " "); command = st.nextToken(); pathname = st.nextToken(); if (command.equals("GET")) { /* if the request is a GET try to respond with the file the user is requesting */ serveFile (osw,pathname); } else { /* if the request is a NOT a GET, return an error saying this server does not implement the requested command */ osw.write ("HTTP/1.0 501 Not Implemented\n\n"); } /* close the connection to the client */ osw.close();

SWS: serveFile (1) public void serveFile (OutputStreamWriter osw, String pathname) throws Exception { FileReader fr=null; int c=-1; StringBuffer sb = new StringBuffer(); /* remove the initial slash at the beginning of the pathname in the request */ if (pathname.charAt(0)=='/') pathname=pathname.substring(1); /* if there was no filename specified by the client, serve the "index.html" file */ if (pathname.equals("")) pathname="index.html";

SWS: serveFile (2)

/* try to open file specified by pathname */ try { fr = new FileReader (pathname); c = fr.read(); } catch (Exception e) { /* if the file is not found,return the appropriate HTTP response code */ osw.write ("HTTP/1.0 404 Not Found\n\n"); return; }

SWS: serveFile (3) /* if the requested file can be successfully opened and read, then return an OK response code and send the contents of the file */

osw.write ("HTTP/1.0 200 OK\n\n"); while (c != -1) { sb.append((char)c); c = fr.read(); } osw.write (sb.toString());

DoS on SWS Example processRequest(): /* read the HTTP request from the client */ String request = br.readLine(); // empty string String command = null; String pathname = null; /* parse the HTTP request */ StringTokenizer st = new StringTokenizer (request, " "); command = st.nextToken(); // EXCEPTION: no tokens! /* SERVER CRASHES HERE – DENIAL OF SERVICE! */ pathname = st.nextToken();

How Do We Fix This?

Requirement: The web server should immediately disconnect from any web client that sends a malformed HTTP request to the server.

The programmer needs to carefully handle exceptions to deal with malformed requests.

Solution: Surround susceptible String Tokenizing code with try/catch block.

Try/Catch Solution

/* read the HTTP request from the client */ String request = br.readLine(); String command = null; String pathname = null; try { /* parse the HTTP request */ StringTokenizer st = new StringTokenizer (request, " "); command = st.nextToken(); pathname = st.nextToken(); } catch (Exception e) { osw.write (“HTTP/1.0 400 Bad Request\n\n”); osw.close(); return; }

Economics of Security How much does it cost to break a system?

All systems have vulnerabilities. How much time, expertise, & resources needed to exploit?

If value of assets > cost to break system, then Threats motivated to conduct a successful attack. Defenders need to invest in more security to raise the cost

of breaking system or need to remove assets.

Key Points 1. Problem of software security

1. Trinity of trouble: connectivity, complexity, extensibility

2. System security certifications 1. Orange book, Common criteria, PCI DSS

3. Security lifecycle 1. Abuse cases 2. Architectural risk analysis 3. Code reviews 4. Penetration and security testing 5. Operations

4. Economics of security 1. If value of assets > cost to break, then threats motivated to take assets.

References 1. Aleph Null, “Smashing the Stack for Fun and Profit,”

Phrack 49, 1996. 2. Brian Chess and Jacob West, Secure Programming with

Static Analysis, Addison-Wesley, 2007. 3. Goodrich and Tammasia, Introduction to Computer

Security, Pearson, 2011. 4. Koziol, et. al, The Shellcoder’s Handbook: Discovering

and Exploiting Security Holes, Wiley, 2004. 5. Robert C. Seacord, Secure Coding in C and C++,

Addison-Wesley, 2006. 6. John Viega and Gary McGraw, Building Secure Software,

Addison-Wesley, 2002. 7. David Wheeler, Secure Programming for UNIX and

Linux HOWTO, http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/index.html, 2003.