How to use this template

Credit to Michal Gavin, H. Thompson, A. Yong, Farkas, J. Walden

Agenda • Security & Software • Challenges • Software Testing • Software Security Practices

• Security Testing - Strategies • Implementation Insecurities & Failures

• Severity Ranking • Vulnerabilities • Tools, References & Online Resource

Security and software • Secure software provides: » Confidentiality – Access is only allowed if authorized » Integrity

– Assurance that data is complete and accurate » Availability – Assets are available when needed

• Security testing must find where confidentiality, integrity, and availability can be defeated

Challenges • Attacking the client • Attacking the server • Attacking both — AJAX! • Attacking Web authentication and authorization

• Attacking application datastores • Attacking Web application management systems • Improved man in the middle attacks • Attacking Web services • The OWASP Foundation http://www.owasp.org

• Web applications are a primary target. » Sensitive information » Defacement

» Malware distribution

• Software Security ≠ Security Features » SSL will not make your site secure.

» Firewalls will not make your site secure.

• Improving software development » Code reviews.

» Risk analysis. » Security testing.

Software Testing • Running a program or system with the intent of finding errors • Evaluating capability of the system and determining that its requirements

• Physical processes vs. Software • Testing purposes » To improve quality » For Verification & Validation (V&V) » For reliability estimation

Quality Assurance • External quality: correctness, reliability, usability, integrity • Interior (engineering) quality: efficiency, testability, documentation, structure

• Future (adaptability) quality: flexibility, reusability, maintainability

Intended vs. Implemented

Software Security Practices 1. Code Reviews

4.

2. Risk Analysis

5.

3. Penetration Testing Abuse Cases

Requirements

Risk Analysis

Design

6.

Security Testing Abuse Cases Security Operations

Code Reviews + Static Analysis

Coding

Security Testing

Testing

Penetration Testing

Security Operations

Maintenance

Code Reviews Fix implementation bugs, not design flaws. Planning

Prep

Meeting

Rework

Follow-up

Author Moderator

Everyone

Everyone

Author

Author Moderator

Abuse Cases

Requirements

Risk Analysis

Design


Coding

Security Testing

Testing

Penetration Testing

Security Operations

Maintenance

Benefits of Code Reviews 1. Find defects sooner in development lifecycle. (IBM finds 82% of defects before testing.) 2. Find defects with less effort than testing. (IBM—review: 3.5 hrs/bug, testing: 15-25 hrs/bug.) 3. Find different defects than testing. (Can identify some design problems too.)

4. Educate developers about security bugs. (Developers frequently make the same mistakes.)

Static Analysis Automated assistance for code reviews Speed: review code faster than humans can

Accuracy: hundreds of secure coding rules

Results

Architectural Risk Analysis Fix design flaws, not implementation bugs. 1. Develop an architecture model. 2. Model threats and attack scenarios. 3. Rank risks based on probability and impact. 4. Develop mitigation strategy. Abuse Cases

Requirements

Risk Analysis

Design


Coding

Security Testing

Testing

Penetration Testing

Security Operations

Maintenance

Threat Modeling 1. Identify System Assets. » System resources that an adversary might attempt to access, modify, or steal. » Ex: credit cards, network bandwidth, user access.

2. Identify Entry Points. » Data or control transfers between systems. » Ex: network sockets, RPCs, web forms, files

3. Determine Trust Levels. » Privileges external entities have to legitimately use system resources.

Penetration Testing Test software in deployed environment by attacking it. Allocate time at end of development to test. » Time-boxed: test for n days. » May be done by an external consultant. Abuse Cases

Requirements

Risk Analysis

Design


Coding

Security Testing

Testing

Penetration Testing

Security Operations

Maintenance

Security Testing Different from penetration testing • White box (source code is available.) • Use risk analysis to build tests. • Measure security against risk model.

Abuse Cases

Requirements

Risk Analysis

Design


Coding

Security Testing

Testing

Penetration Testing

Security Operations

Maintenance

Security Testing

Functional testing will find missing functionality.

Intendended Functionality

Injection flaws, buffer overflows, XSS, etc.

Actual Functionality

Abuse Cases Anti-requirements Think explicitly about what program shouldn’t do. A use case from an adversary’s point of view.

Abuse Cases

Requirements

Risk Analysis

Design


Coding

Security Testing

Testing

Penetration Testing

Security Operations

Maintenance

Security Operations Deploying security » Secure default configuration. » Web application firewall for defense in depth.

Incident response » What happens when a vulnerability is reported? » How do you communicate with users? Abuse Cases

Requirements

Risk Analysis

Design


Coding

Security Testing

Testing

Penetration Testing

Security Operations

Maintenance

Security Testing • Look for unexpected but intentional misuse of the system • Must test for all potential misuse types using » Architectural risk analysis results » Abuse cases

• Verify that » All intended security features work (white hat) » Intentional attacks cannot compromise the system (black hat)

Security Testing Strategies • Most software testing attempts to prove that software works as intended, meets certain criteria. • Security testing attempts to prove that software can be made to do something unintended. • When you find a security issue, keep testing! Determine what you can break from there. • Developers try to build things, testers validate built software and try to break it in certain ways. » Both should understand common vulnerabilities and attacks, and learn how to break software security.

Implementation Insecurities • Perfect design means nothing if Implementation is flawed • Man-in-the-middle attack » Attacker gets between time application checks security and when the application uses information » Xterm – can be exploited to allow a restricted user to append data to the password file

Severity Rankings • Urgent » System crash, Unrecoverable data loss, jeopardizes personnel

• High » Impairment of critical system functions and no work-around exists

• Medium » Impairment of critical system functions and work-around exists

• Low » Inconvenience, annoyance

• None » None of the above or an enhancement

Dependency Insecurities & Failures • Software resides in co-dependent environment

• Two Security Concerns » Application may inherit insecurities » External security service resource may fail

• Internet Explorer’s Content Advisor » Content advisor password protects classes of sites

» If the library fails to load, Internet explorer permits access to any previously blocked site » http://www.symantec.com/connect/articles/basicsecurity-checklist-home-and-office-users

Unanticipated User Input • Inputs that cause undesirable side effects and require special testing » Reserved words » Escape characters » Long strings » Boundary values

• Most well known side-effect: Buffer Overflow

• Input that can be interpreted as commands • https://buildsecurityin.us-cert.gov/articles/tools/sourcecode-analysis/source-code-analysis-tools---overview

Design Insecurities • Many Security Vulnerabilities designed into application » Seeing high-level impact on an application or host is difficult

• Test Instrumentation » Many applications shipped with it » Bypassing security controls for ease of testing

• Ports left open • Insecure default values and configurations

• http://www.computerweekly.com/opinion/Technologies-forapplication-level-security

Correctness Testing • Black box: » Test data are derived from the specified functional requirements without regard to the final program structure » Data-driven, input/output driven, or requirementsbased » Functional testing » No implementation details of the code are considered

Correctness Testing • White box: » Software under test are visible to the tester » Testing plans: based on the details of the software implementation

» Test cases: derived from the program structure » glass-box testing, logic-driven testing, or designbased testing

Performance Testing • Goal: bottleneck identification, performance comparison and evaluation, etc. • Explicit or implicit requirements • "Performance bugs" – design problems • Test: usage, throughput, stimulus-response time, queue lengths, etc. • Resources to be tested: network bandwidth requirements, CPU cycles, disk space, disk access operations, memory usage, etc.

Reliability Testing • Probability of failure-free operation of a system

• Dependable software: it does not fail in unexpected or catastrophic ways • Difficult to test • (see later lecture on software reliability)

Security Testing • Test: finding flaws in software can be exploited by attackers • Quality, reliability and security are tightly coupled • Software behavior testing » Need: risk-based approach using system architecture information and attacker’s model

Impact of Malicious Attack • What happens when the software fails? » Safety critical systems

• Track risk over time • Security relative to » Information and services protected » Skills and resources of adversaries » Cost of protection

• System vulnerabilities

Malicious Input • Software: takes input

• Trust input? » Malformed or malicious input may lead to security compromise

» What is the input? – Data vs. control

• Attacker toolkit

Traditional Software Development • No information security consideration

• Highly distributed among business units • Lack of understanding of technical security risks

Software Practice • Best Practices » Manageable number of simple activities » Should be applied throughout the software development process

• Problem: » Software developers: lack of security domain knowledge  limited to functional security

» Information security professionals: lack of understanding software  limited to reactive security techniques

Deployment and Operations • Configuration and customization of software application’s deployment environment • Activities: » Network-component-level

» Operating system-level » Application-level

Deployment and Operations • Configuration and customization of software application’s deployment environment • Fine tuning security functionality • Evaluate entire system’s security properties • Apply additional security capabilities if needed

Attacker: • Amateurs: regular users, who exploit the vulnerabilities of the computer system » Motivation: easy access to vulnerable resources

• Crackers: attempt to access computing facilities for which they do not have the authorization » Motivation: enjoy challenge, curiosity

• Career criminals: professionals who understand the computer system and its vulnerabilities » Motivation: personal gain (e.g., financial)

Attacker Identity: • Insider » Understand organizational data, architecture, procedures, etc. » May understand software application

» Physical access

• Outsider » May not understand organizational information » May have software specific expertise » Use of tools and other resources

Vulnerability Monitoring 

Identify security weaknesses  Methods: – Automated tools

– Human walk-through – Surveillance – Audit

– Background checks

System Security Vulnerability 

Software installation – Default values – Configurations and settings  Monitoring usage – Changes and new resources – Regular updates  Tools – Look for known vulnerabilities

Red Team 

Organized group of people attempting to penetrate the security safeguards of the system.  Assess the security of the system  future improvement  Requested or permitted by the owner to perform the assessment  Wide coverage: computer systems, physical resources, programming languages, operational practices, etc.

Testing Team • Software security experts should help in all phases of security testing. • Developers can, and usually should, validate the use of secure program techniques during builds. • Developers can, and usually should, test for security when doing unit testing. • Anyone who does integration testing or system testing should also perform security testing. • QA should also test for security prior to sign-off.

Testing Goals • Flaws in software dependencies.

• Software design flaws and design decisions with security consequences. • Software implementation flaws and choices with security consequences. • Ways to bypass security controls, e.g., authentication, authorization, encryption, and logging. Based upon “How To Break Software Security,” Whittaker & Thompson, Addison-Wesley, 2004

Targets • System level attacks

• Data parsing vulnerabilities • Information disclosure • Network communications vulnerabilities • When appropriate: Web application vulnerabilities

Based upon “The Software Vulnerability Guide,” Thompson & Chase, Charles River Media, 2005

System level attacks • Permission problems

• Default or weak passwords • Shells, scripts, and macros • Dynamic linking and loading


Data parsing vulnerabilities • Buffer and heap overflows

• Proprietary formats and protocols • Format string vulnerabilities • Integer overflow vulnerabilities


Information disclosure • Plain text password storage

• Accessible temporary files • Data left in memory • Swap file contents and incomplete deletion


Network communications vulnerabilities • Impersonation, spoofing, and man-in-the-middle

• Race conditions • Network based information disclosure


Web application vulnerabilities • Cross-site scripting • Forceful browsing • Parameter tampering, cookie poisoning, and hidden field manipulation

• SQL injection vulnerabilities • Additional server side security issues • Additional client side security issues Based upon “The Software Vulnerability Guide,” Thompson & Chase, Charles River Media, 2005

Learn how, when, and where to find security issues • How: » Fault injection, malicious inputs, etc.

» Help is available — publications and Web references. See bibliography slides. Also tools and consultants.

• When: » Throughout the software development life cycle. See slide regarding who should perform security testing.

• Where: » Ideally in the lab, but in production is sometimes necessary » Preferably as close to the source code as possible

Software Security Action Plan: • Security design review, threat modeling, abuse and misuse cases • Secure coding checklists and secure code reviews • Security assessments and penetration tests

Recommendations • Perform periodic penetration tests and/or security assessments against software programs • Periodically review application users and privileges • Stage and test application updates prior to deployment • Assign responsibility for security testing in each phase of the SDLC

• Create a virtual software security team consisting of those responsible individuals

Testing Tools • Network tools » Scanners to find software running in the environment » Sniffers to observe and manipulate software communications

• Protocol implementation test tools • Source code tools » Development tools, e.g. strict compiler warnings » Source code analysis tools

Tools • Debugging and reverse engineering tools » Decompilers, disassemblers, hex editors, debuggers, interpreters » Binary scanners,

» API and system monitors

Testing Tools • Penetration testing tools » Password crackers » Fuzzers » Security scanners

– OS, service, network, application, database » Proxy servers

• Automated penetration testing tools • Exploit development tools

Tools • Protocol testing tools » Codenomicon

• Source code scanners » Compuware, DevPartner SecurityChecker » Coverity, Prevent » Fortify, Source Code Analysis » Klocwork, Klocwork K7

» Ounce Labs, The Ounce Solution » Parasoft, JTest, C++test, .TEST » Secure Software, Code Assure Workbench

Tool vendors and products (continued) • Debuggers » DataRescue, IDA Pro Disassembler and Debugger » NuMega SoftIce » OllyDbg

• Reverse engineering » Imagix 4D

» Sabre Security, BinDiff, BinNavi, BinAudit » See http://www.woodmann.com/crackz/Tools.htm

Tools • Penetration testing tools » Numerous:

» 1) http://www.securityfocus.com/tools » 2) http://www.datastronghold.com/ » 3) http://sectools.org/

• Automated penetration testing tools » Core Security, Core Impact » Immunity Security, Canvas » Open Source, MetaSploit – MetaSploit is actually an exploit development tool but it also excels at automated penetration testing

New Tools • Regmon and Filemon – monitor application interactions with registry and file system » www.sysinternals.com

• App-Sight – monitors environmental interactions » www.identify.com

• Holodeck – Fine grain control over interactions between application and environment » www.sisecure.com

More Tools • Software scanners » Application Security, AppDetective (Database programs) » Compuware, DevPartner Security Checker » Coverity, Extend » Fortify, Tracer and Tester

Practical Tools • Web application scanners » Acunetix, Web Vulnerability Scanner » Cenzic, Cenzic Hailstorm » Compuware, Security Checker? » NT Objectives, NTO Spider » Open Source, nikto, wikto, Paros proxy » Parasoft, WebKing, SOAtest

» SPI Dynamics, WebInspect » Watchfire, AppScan » WhiteHat Security, WhiteHat Sentinel

References • The Art of Software Security Assessment: Identify and Prevent Software Vulnerabilities, Addison Wesley, 2007. • May 27, 2005, Best Practices “To Secure Web Applications, Start With The OWASP Top Ten” • May 16, 2005, Best Practices “Software Quality Is Everybody’s Business” • The Art of Software Testing 2nd edition, Wiley

Recommended Web sites • OSSTMM Open Source Security Testing Methodology Manual, http://www.isecom.org

• Professional Security Testers, http://www.professionalsecuritytesters.org/ • Application Security, http://SearchAppSecurity.techtarget.com • OWASP (Open Web Application Security Project), http://www.owasp.org • WASC (Web Application Security Consortium), http://www.webappsec.org • Web Site Security, http://www.cgi.com

More references • “The Software Vulnerability Guide,” Thompson and Chase, Charles River Media, 2005

• “Gray Hat Hacking,” Harris, et. al., Osborne, 2005 • “Exploiting Software: How to Break Code,” Hoglund and McGraw, Addison-Wesley, 2004

• “Hacking Web Applications Exposed,” Scambray, et. al., Osborne, 2006 • “How To Break Web Software: Functional and Security Testing of Web Applications and Web Services,” Andrews and Whittaker, Addison-Wesley, 2006

References & Useful Links • Fuzzing for Software Security Testing and Quality Assurance, ISBN-10: 1596932147, Artech House; 1 edition (June 30, 2008) • OWASP – Software Quality Assurance https://www.owasp.org/index.php/Software_Quality_Assurance • Vulnerability as a Function of Software Quality https://www.giac.org/paper/gsec/647/vulnerability-function-softwarequality/101493 • Why QA Doesn't Do Security Testing http://www.infosecisland.com/blogview/10736-Why-QA-Doesnt-DoSecurity-Testing.html • Are Security and Quality Assurance Part of Your Software Development Life Cycle? http://www.educause.edu/ir/library/powerpoint/WRC0667.pps

Resources • » Enhancing the Development Life Cycle to Produce Secure Software”, DHS SwA Forum Process and • Practices Working Group, 2008; at https://buildsecurityin.us-cert.gov/swa/procwg.html • » “Software Security Assurance: A State-of-the-Art Report”, Goertzel, Karen Mercedes, et al,

• Information Assurance Technology Analysis Center (IATAC) of the DTIC at • http://iac.dtic.mil/iatac/download/security.pdf • » “Multi-perspective Application Security Risk Analysis: A Toolbox Approach”, Sean Barnum, et al, March 2009. • » “OWASP Testing Guide v3”, The Open Web Application Security Project at • http://www.owasp.org/index.php/Category:OWASP_Testing_Project#OWASP_Testing_Guide_v3 _2. • » “Fundamental Practices for Secure Software Development: A Guide to the Most Effective Secure Development Practices in Use Today”, The Software Assurance Forum for Excellence in Code (SAFECode), 2008 at http://www.safecode.org/publications/SAFECode_Dev_Practices1008.pdf • » ‘Microsoft Security Development Lifecycle (SDL) – Process Guidance” at • http://msdn.microsoft.com/en-us/library/84aed186-1d75-4366-8e61-8d258746bopq.aspx • » “Software Security: Being Secure in an Insecure World”, Mano Paul, (ISC)2.

Resources • “Source Code Analysis Tools – Overview”, Michael, et al, Cigital, Inc., at al, at • https://buildsecurityin.us-cert.gov/daisy/bsi/articles/tools/code/263-BSI.html . • » The NIST Software Assurance Metrics And Tool Evaluation (SAMATE) project at • http://samate.nist.gov/index.php/Main_Page.html . • Ollmann, Gunter. “Second-order Code Injection: Advanced Code Injection Techniques and Testing Procedures”. Undated whitepaper posted on his Weblog at http://www.technicalinfo.net/papers/SecondOrderCodeInjection.html • » Wysopal, Chris, et al. “Testing Fault Injection in Local Applications”. SecurityFocus, 23 January 2007 (excerpt from The Art of Software Security Testing) at http://www.securityfocus.com/infocus/1886

• » Du, Wenliang and Aditya P. Mathur. “Vulnerability Testing of Software Systems Using Fault Injection”. Technical Report COAST TR98-02, 6 April 1998 at • https://www.cerias.purdue.edu/tools_and_resources/bibtex_archive/archive/98-02.pdf

Case Studies: Is your web site secure? Credit to James Walden

Yes, we deployed SSL, firewall, etc. » Does SSL protect all communications? » What about stored data? » What about injection attacks and XSS?

Firewalls don’t protect web apps telnet

Firewall

ftp

Application

Web Client

HTTP Traffic

Web Server

Port 80

Application

Database Server

Is your web site secure? Yes, we’re certified as being secure. » PCI scans quarterly; apps change weekly. » Geeks.com, certified HackerSafe by McAfee, lost thousands of CCs in 2007.

Is your web site secure? Yes, we have logs of blocked attacks. » Better, you have some real evidence. » Did you log non-blocked requests too?

Is your web site secure? Yes, we have a SDLC and record network, host, and application-based logs. » Secure Development LifeCycle – Risk analysis – Secure design

– Code reviews – Security testing » Correlate logs for multi-perspective picture.

Topics 1.

The Problem of Software Security

2.

Web Application Vulnerabilities

3.

SQL Injection

4.

Software Security Practices

Reasons for Attacking Web Apps

A Growing Problem Software Vulnerabilities 9000 8000

Vulnerabilities

7000 6000 5000 4000 3000 2000 1000 0 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006

Year

The source of the problem “Malicious hackers don’t create security holes; they simply exploit them. Security holes and vulnerabilities – the real root cause of the problem – are the result of bad software design and implementation.”

John Viega & Gary McGraw

Web Application Vulnerabilities

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.

SQL Injection 1. App sends form to user.

Attacker User ‘ or 1=1--

2. Attacker submits form with SQL exploit data.

Pass

3. Application builds string with exploit data.

4. Application sends SQL query to DB.

Firewall

5. DB executes query, including exploit, sends data back to application. 6. Application returns data to user.

Web Server

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);

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.

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 ‘%’

SQL Injection Demo

SQL Injection Demo

Impact of SQL Injection SELECT SSN FROM USERS WHERE UID=‘$UID’ INPUT

RESULT

5

Returns info for user with UID 5.

‘ OR 1=1--

Returns info for all users.

‘ UNION SELECT Field FROM Table WHERE 1=1--

Returns all rows from another table.

‘;DROP TABLE USERS--

Deletes the users table.

‘;master.dbo.xp_c Formats C: drive of database server if you’re mdshell ‘cmd.exe running MS SQL Server and extended format c: /q /yes’ -- procedures aren’t disabled.

Impact of SQL Injection 1.

Leakage of sensitive information.

2.

Reputation decline.

3.

Modification of sensitive information.

4.

Loss of control of db server.

5.

Data loss.

6.

Denial of service.

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.

Mitigating SQL Injection Partially Effective Mitigations Blacklists Stored Procedures

Effective Mitigations Whitelists

Prepared Queries

Conclusions • Web applications are a primary target. » Sensitive information » Defacement » Malware distribution

• Software Security ≠ Security Features » SSL will not make your site secure. » Firewalls will not make your site secure.

• Improving software development » Code reviews. » Risk analysis. » Security testing.

References 1.

Mark Dowd, John McDonald, Justin Schuh, The Art of Software Security Assessment, Addison-Wesley, 2007.

2.

Mitre, Common Weaknesses – Vulnerability Trends, http://cwe.mitre.org/documents/vuln-trends.html, 2007.

3.

Gary McGraw, Software Security, Addison-Wesley, 2006.

4.

J.D. Meier, et. al., Improving Web Application Security: Threats and Countermeasures, Microsoft, http://msdn2.microsoft.com/enus/library/aa302418.aspx, 2006.

5.

OWASP Top 10, http://www.owasp.org/index.php/OWASP_Top_Ten_Project, 2007.

6.

Ivan Ristic, Web Application Firewalls: When Are They Useful?, OWASP AppSec EU 2006.

7.

Joel Scambray, Mike Shema, and Caleb Sima, Hacking Exposed: Web Applications, 2nd edition, Addison-Wesley, 2006.

8.

Dafydd Stuttard and Marcus Pinto, Web Application Hacker’s Handbook, Wiley, 2007.

9.

WASC, “Web Application Incidents Annual Report 2007,” https://bsn.breach.com/downloads/whid/The%20Web%20Hacking%20Incid ents%20Database%20Annual%20Report%202007.pdf, 2008.