Injecting simplicity not SQL BSides Las Vegas 2010

David RookInjecting simplicity not SQLSecurityBSides, Las VegasTuesday, 27 July 2010

if (slide == introduction) System.out.println("I’m David Rook"); • Security Analyst, Realex Payments, Ireland CISSP, CISA, GCIH and many other acronyms • Security Ninja (www.securityninja.co.uk) • Speaker at many security conferences • Nominated for blog awards for Security Ninja • A mentor for the InfoSecMentors project • I like to make, break and fix thingsTuesday, 27 July 2010

About this Presentation • What this presentation isn’t – A technical discussion about one specific vulnerability – No 0 days, new attacks or new vulnerabilities – Just a moaning session • What this presentation is: – A look at a simpler approach to secure development – A positive approach to secure development education – How other companies have implemented this approachTuesday, 27 July 2010

Agenda • It is broken so lets fix it • The current approach • The Principles of Secure Development • The principles approach is workingTuesday, 27 July 2010

It is broken so lets fix it • Secure development is broken, we aren’t progressing • SQL Injection, 10 years old? • Cross Site Scripting, 11 years old? • Still major problems in 2010 and for years to comeTuesday, 27 July 2010

It is broken so lets fix it SQLi & XSS = 33.90% 29.30% 31.65%700060005000 CVEs Total SQLi4000 XSS 3000 2000 1000 0 2010 2009 2008 2007 2006 2005 2004 2003 2002 2001 2000Tuesday, 27 July 2010

It is broken so lets fix it • CVE statistics only show publicly known vulns • They do show a lack of app sec progress though Around 30% of all vulnerabilities in 2005, 2006, 2007, 2008, 2009 and 2010 XSS or SQL Injection • Only one source, lets look at another one Source: http://www.cvedetails.com/vulnerabilities-by-types.phpTuesday, 27 July 2010

It is broken so lets fix it • WASC Web Application Security Statistics • Sanitised data from pen tests, audits etc • Still a tiny sample size (0.006% of all websites) • These stats also show a lack of app sec progress • 2008 report has less sites but more vulnerabilities Source: http://projects.webappsec.org/Web-Application-Security-StatisticsTuesday, 27 July 2010

It is broken so lets fix it1000009000080000 Sites 70000 Vulns 60000 50000 40000 30000 20000 10000 0 2008 2007Tuesday, 27 July 2010

The current approach (And why I think it fails to deliver secure applications) • We put the cart before the application security horse • Security guys tell developers about specific vulnerabilities • We hope they figure out how to prevent them • Inevitably security flaws end up in live code • Security guys complain when data gets stolenTuesday, 27 July 2010

The current approach (And why I think it fails to deliver secure applications) • What if we taught drivers in the same way? • Instructor tells driver about the different ways to crash • We hope the driver figures out how not to crash • Inevitably the driver will crash • People complain when they get crashed intoTuesday, 27 July 2010

The current approach (And why I think it fails to deliver secure applications) • Many lists of vulnerabilities • OWASP Top 10 • White Hat Sec Top 10 • SANS Top 25 • Others??Tuesday, 27 July 2010

The current approach (And why I think it fails to deliver secure applications) Failure to Preserve Web Page Structure Failure to Preserve SQL Query Structure Reliance on Untrusted Inputs in a Security Decision Missing Encryption of Sensitive Data Incorrect Calculation of Buffer Size Improper Control of Filename for Include/Require Statement in PHP ProgramURL Redirection to Untrusted Site Buffer Copy without Checking Size on Input Content Spoofing Allocation of Resource Without Limits or Throttling Cross Site Request Forgery Information Leakage Injection Flaws Cross Site Scripting Improper Check for Unusual or Exceptional ConditionsInsufficient Transport Layer Protection Failure to Preserve OS Command StructureInsufficient Authorisation Improper Limitation of a Pathname to a Restricted Directory Improper Access Control Insufficient Authentication Insecure Cryptographic Storage Race Condition Use of Hard-coded Credentials Session Management Insecure Direct Object Reference Improper Validation of Array IndexInformation Exposure Through an Error Message Abuse of FunctionalityPredictable Resource Location Download of Code Without Integrity Check Failure to Restrict URL Access Unvalidated Redirects and ForwardsBuffer Access with Incorrect Length Value Security Misconfiguration SQL Injection Unrestricted Upload of File with Dangerous TypeBroken Authentication Missing Authentication for Critical Function Integer Overflow or Wraparound Use of a Broken or Risky Cryptographic AlgorithmIncorrect Permission Assignment for Critical ResourceTuesday, 27 July 2010

The current approach (And why I think it fails to deliver secure applications) • Many lists of vulnerabilities • OWASP Top 10 • White Hat Sec Top 10 • SANS Top 25 • Others?? • != Secure development guidance • 45 vulnerabilities, 41 unique names • Training courses etc based on these listsTuesday, 27 July 2010

Philosophical Application Security Give a man a fish and you feed him for a day, teach him to fish and you feed him for a lifetime. I want to apply this to secure application development: Teach a developer about a vulnerability and he will prevent it, teach him how to develop securely and he will prevent many vulnerabilities.Tuesday, 27 July 2010

What we need to do • Put the application security horse before the cart • Security guys tell developers how to write secure code • Developer doesn’t need to guess anymore • Common vulnerabilities prevented in applications • Realistic or just a caffeine fueled dream?Tuesday, 27 July 2010

The current approach Principles of Secure Development (And why I think it fails to deliver secure applications) Failure to Preserve Web Page Structure Failure to Preserve SQL Query Structure Reliance on Untrusted Inputs in a Security Decision Secure Communications Missing Encryption of Sensitive Data Incorrect Calculation of Buffer Size Output Validation Improper Control of Filename for Include/Require Statement in PHP ProgramURL Redirection to Untrusted Site Buffer Copy without Checking Size on Input Content Spoofing Allocation of Resource Without Limits or Throttling Input Validation Cross Site Request Forgery and Logging Auditing Information Leakage Injection Flaws Cross Site Scripting Improper Check for Unusual or Exceptional ConditionsInsufficient Transport Layer Protection Failure to Preserve OS Command Structure AuthorisationInsufficient Authorisation Improper Limitation of a Pathname to a Restricted Directory Session Management Insecure Cryptographic Storage Improper Access Control Insufficient Authentication Race Condition Use of Hard-coded Credentials Session Management Insecure Direct Object Reference Improper Validation of Array Index Error Handling Secure Resource AccessInformation Exposure Through an Error Message Abuse of FunctionalityPredictable Resource Location Download of Code Without Integrity Check Failure to Restrict URL Access Unvalidated Redirects and ForwardsBuffer Access with Incorrect Length Value Security Misconfiguration SQL Injection Authentication Unrestricted Upload of File with Dangerous TypeBroken Authentication Missing Authentication for Critical Function Integer Overflow or Wraparound Secure Storage a Broken or Risky Cryptographic Algorithm Use ofIncorrect Permission Assignment for Critical ResourceTuesday, 27 July 2010

The Principles of Secure Development • Input Validation • Identify the data your application must accept and all input points • Create regex’s to validate each data type (content and size) • For example, a credit card number data type: d{12,16}$ • Use whitelisting for validation where possible • Blacklisting approach harder and potentially less secure • Blacklist example, replacing single quotes: s.replaceAll(Pattern.quote(" "), Matcher.quoteReplacement(" " "))Tuesday, 27 July 2010

Demo 1 • Lack of input validation • SQL injection in FreeRealty can be used to bypass authentication • Credit to Sid3^effects, April 2010Tuesday, 27 July 2010

The Principles of Secure Development • Output Validation • Identify and define the data your application must output • Understand where (i.e. in a URL) your data should end up • Choose the correct output encoding for the datas destination • Proper encoding means this attack: www.examplesite.com/home.html?day=<script>alert(document.cookie)</script> Becomes: day=%3Cscript%3Ealert%28document.cookie%29%3C/script%3ETuesday, 27 July 2010

Demo 2 • Lack of output validation • Stored XSS in DBHcms can be used to steal user cookies • Credit to ITSecTeam, May 2010Tuesday, 27 July 2010

The Principles of Secure Development • Error Handling • Even the best apps will crash at some point, be prepared! • Crashes/errors can help an attacker if you don’t handle them • Handle error conditions securely, sanitise the message sent • No error handling == information leakage Microsoft OLE DB Provider for ODBC Drivers(0x80040E14) [Microsoft][ODBC SQL Server Driver] [SQL Server]Invalid column name /examplesite/login.asp, line 10Tuesday, 27 July 2010

Demo 3 • Lack of error handling • Lack of error handling leads to information leakage • Sample page by David RookTuesday, 27 July 2010

Tuesday, 27 July 2010

The Principles of Secure Development • Authentication and Authorisation • Even simple apps often have a need to authenticate users • Often at least two levels of authorisation • Need to prevent horizontal and vertical privilege escalation • Implement strong passwords and management systems • Ensure A+A is secure, not a false sense of security (CAPTCHA?) • Don’t rely on fields that are easily spoofed (referrer field) • Re-authenticate users for sensitive actions (i.e. funds transfer)Tuesday, 27 July 2010

The Principles of Secure Development • Session Management • Used to manage authenticated users, no need to re-auth • You need to ensure that your sessionID’s have sufficient entropy • SessionID’s must not be predictable or reusable • Never build your own session management, it will fail • Protect sessionID’s when in transit (i.e. SSL/TLS!) • Issue a new value for sensitive actions (i.e. funds transfer)Tuesday, 27 July 2010

The Principles of Secure Development • Secure Communications • Protect data (i.e. CC no, passwords, sessionID’s) in transit • As with all crypto, don’t create your own • Don’t use broken protection mechanisms (i.e. SSLv2) • Don’t just use SSL/TLS for logon pages, protect the session! • Try to avoid mixing secure and insecure traffic on a pageTuesday, 27 July 2010

The Principles of Secure Development • Secure Storage • Protect data (i.e. CC no, passwords, sessionID’s) when stored • As with all crypto, don’t create your own • Don’t use broken protection mechanisms (i.e. DES) • Don’t store data in places where you can’t confidently secure it • Strong protection mechanisms, how strong should it be? • Store, rotate and destroy encryption keys securelyTuesday, 27 July 2010

Demo 4 • Lack of secure storage • Passwords hashed and stored insecurely in Flat File Logon • Credit to ViRuSMaN, February 2010Tuesday, 27 July 2010

Admin password hash - no saltTuesday, 27 July 2010

Admin password hash - saltedTuesday, 27 July 2010

The Principles of Secure Development • Secure Resource Access • Obscurity != security, don’t try to hide sensitive resources • Least privilege users for all tasks • Store library, include, and utility files outside of the web root • Securely harden servers including filesystem ACL’sTuesday, 27 July 2010

Demo 5 • Lack of secure resource access • Local file include vulnerability in Bit Weaver 2.7 • Credit to John Leitch, July 2010Tuesday, 27 July 2010

The Principles of Secure Development • Auditing and Logging • Logs will be created by your application for many events • These logs must not contain sensitive data (i.e. CC numbers) • They must contain sufficient information for auditing purposes • Logs should be sent to a central server and not locally stored • If possible the logs should be stored “read only” • Retain logs for as long as required by laws/regulatory standardsTuesday, 27 July 2010

But I need to prevent vulnerability "X"Tuesday, 27 July 2010

Lets redefine what secure development means • Follow a small, repeatable set of principles • Try not to focus on specific vulnerabilities • Develop securely, not to prevent "hot vuln of the day" • Build security into the code, don’t try to bolt it on at the endTuesday, 27 July 2010

The principles approach is working • Private banking development company, Switzerland • Application Security lead saw the secure development principles • Re-designed secure development training for his company • Security training costs down, quicker "spin up" of developers • Security within their SDLC now based on the principles • In his own words: You released the "secure development principles" at a time I had issues with my dev teams in how to teach them secure development. Your approach convinced me to look in another direction, not trying to teach every vulnerability but finding the basic principles that help prevent their existence. At that time, this was genius for me: most of my training since has been inspired by your secure development principles.Tuesday, 27 July 2010

The new approach is workingThey modified the principles matrix to match their own terminologyTuesday, 27 July 2010

The principles approach is working • Fortune 500 financial services company, USA • One developer tasked with training local developers • Had tried the “teach all the vulns” approach and it failed • Implemented principles based training with .NET examples • CISO has now implemented this approach company wide • In his own words: I have given a training in the past but I think I gave too much details about example vulnerabilities such a XSS, SQL Injection, etc... While I think it educated the developers about vulnerabilities I dont think they changed how they code. My goal this time was to simplify. The plan is to give the basics such as the principles and then since we are a .NET shop I would give some example slides of how to do things in .NET.Tuesday, 27 July 2010

The new approach is working • They use .NET code examples for each principle Input Validation <form id="WebForm" method="post" runat="server"> <asp:TextBox id="txtName" runat="server"></asp:TextBox> <asp:RegularExpressionValidator id="nameRegex" runat="server" ControlToValidate="txtName" ValidationExpression="^[a-zA-Z.s]{1,40}$" ErrorMessage="Invalid name"> </asp:regularexpressionvalidator> </form> Output Validation Response.Write(HttpUtility.HtmlEncode(Request.Form["name"]));Tuesday, 27 July 2010

Evolution, not revolution • Don’t make things more difficult than they need to be • This isn’t a new wheel, its just a smoother, easier to use wheel • Don’t treat security as something separate, integrate it • By integrating security fully a security bug is just another bug • Secure development doesn’t have to be hard, KISS it!Tuesday, 27 July 2010

We knew how to fix this in 1978! • What happened in 1978 that is so special? • IBM released a video discussing information security • Remember what I said about not reinventing the wheel?Tuesday, 27 July 2010

We need to learn from 1978 • Those ideas from 1978 are still valid in 2010 • 1st Video – Authentication and Authorisation • 2nd Video – Secure Communications • 3rd and 4th Videos – Validation and Error HandlingTuesday, 27 July 2010

Talk is cheap...... • What am I doing to promote this approach? • Producing more principles of secure development documentation • Helping companies who have adopted this approach • The Security Ninja security code review toolTuesday, 27 July 2010

Security Ninja security code review tool • A tool based on the principles for code reviews • Tool for performing security code reviews based on the principlesTuesday, 27 July 2010

Security Ninja security code review tool • A tool based on the principles for code reviews • Tool for performing security code reviews based on the principles • First version will be released soon • It will be free for anyone to download and use • See me today if you want a demo or a play with the tool!Tuesday, 27 July 2010

QUESTIONS? www.securityninja.co.uk @securityninjaTuesday, 27 July 2010

Injecting simplicity not SQL BSides Las Vegas 2010

by Security Ninja

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 85

Statistics

Injecting simplicity not SQL BSides Las Vegas 2010 Presentation Transcript

http://www.securityninja.co.uk	84
http://test.securityninja.co.uk	1