Attacking both â AJAX! ⢠Attacking ... Attacking Web application management systems. ⢠Improved ... Find defects sooner in development lifecycle. (IBM finds ...
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
Code Reviews + Static Analysis
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
Code Reviews + Static Analysis
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
Code Reviews + Static Analysis
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
Code Reviews + Static Analysis
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
Code Reviews + Static Analysis
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
Code Reviews + Static Analysis
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
Based upon “The Software Vulnerability Guide,” Thompson & Chase, Charles River Media, 2005
Data parsing vulnerabilities • Buffer and heap overflows
• Proprietary formats and protocols • Format string vulnerabilities • Integer overflow vulnerabilities
Based upon “The Software Vulnerability Guide,” Thompson & Chase, Charles River Media, 2005
Information disclosure • Plain text password storage
• Accessible temporary files • Data left in memory • Swap file contents and incomplete deletion
Based upon “The Software Vulnerability Guide,” Thompson & Chase, Charles River Media, 2005
Network communications vulnerabilities • Impersonation, spoofing, and man-in-the-middle
• Race conditions • Network based information disclosure
Based upon “The Software Vulnerability Guide,” Thompson & Chase, Charles River Media, 2005
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.