Software Security Engineering (Learnings from the past to fix the future) - BSides DE and OWASP Global Talk 2021
- 1. Software Security Engineering Learnings from the past to fix the future Debasis Mohanty Head of Technical Services SEQA Security BSides Delaware 2021 (13 Nov)
- 2. Who am I? How my experience is relevant to this talk? • Head of Security Services at SEQA Security (a New Zealand based company) • Over 20 years of Offensive and Defensive Security Experience (since 1997-1998) • The vast majority of the experience has been vulnerability research-focused and exploit development • Over 10+ years of Software Security Engineering Background • Led Security Engineering CoE of mid-sized and large Technology Companies • Worked closely with the multiple engineering teams to integrate security across SDLC (Waterfall / Agile / DevOps) • A simple security guy who likes to solve complex security problems using simple methods Personal Website: coffeeandsecurity.com Twitter: @coffeensecurity Email: d3basis.m0hanty@gmail.com
- 3. Overview • The History: Historical data shows we continue to see around two decades old security bugs • The Reason: Why do we still continue to see one to two decades old security bugs? • The Solution: The top two mitigation strategies to consider based on the past learnings • The Misconception: The Silver Bullet In Software Security Engineering
- 4. The History The Present State of Security Vulnerabilities Historical data shows we continue to see around two decades old security bugs
- 5. Top Application Security Vulnerabilities That has be around for over two decades • Cross Site Scripting (webapp ) As per Wikipedia: https://en.wikipedia.org/wiki/Cross-site_scripting • Microsoft security-engineers introduced the term "cross-site scripting" in January 2000 • XSS vulnerabilities have been reported and exploited since the 1990s • SQL Injection (webapp and OS-native apps) As per Wikipedia: https://en.wikipedia.org/wiki/SQL_injection • The first public discussions of SQL injection started appearing around 1998 (an article in Phrack Magazine) • Deserialization Issue (web-app, OS-native apps) • 01 Aug 2002: Integer overflow in xdr_array() function when deserializing the XDR stream https://www.kb.cert.org/vuls/id/192995
- 6. Top OS and OS-Native Apps Vulnerabilities That has be around for over one to two decades • Buffer Overflow As per Wikipedia: https://en.wikipedia.org/wiki/Buffer_overflow • Buffer overflows were understood and partially publicly documented as early as 1972 • The earliest documented hostile exploitation of a buffer overflow was in 1988 (Morris worm) • In 1996: Phrack magazine article "Smashing the Stack for Fun and Profit“ by Elias Levy (aka Aleph One) • Race Condition (OS, OS-Native apps and webapps) • May 1995: Publication title “A Taxonomy of UNIX System and Network Vulnerabilities” https://cwe.mitre.org/documents/sources/ATaxonomyofUnixSystemandNetworkVulnerabilities%5BBishop95%5D.pdf • CVE-2001-0317: https://nvd.nist.gov/vuln/detail/CVE-2001-0317 • Use-After-Free (UAF) (aka Dangling Pointer) and Double Free • Use-After Free (https://www.nrc.gov/docs/ML0634/ML063470583.pdf) June 1996: Publication title “Review Guidelines on Software Languages for Use in Nuclear Power Plant Safety Systems” • Double Free (https://cwe.mitre.org/data/definitions/415.html) CVE-2002-0059: Double Free - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0059
- 7. History of Few Common Bug Classes • Observations: • The majority of the bug classes in the list have been around two decades • This list relates to bugs affecting multiple applications and software. • The count of bugs across each year may not necessarily be accurate • However, you get an idea that these bugs have been around for a long period • Conclusion: Given that these bug classes have been around for two decades, it implies that something is not right with how the Industry has dealt with these bugs. This may not be the most comprehensive list but you get the overall picture.
- 8. The Big Question So, why do we continue to see one to two decades-old security bugs?
- 9. The Reason(s) There are many reasons, but here we will discuss the two most prominent reasons.
- 10. The Two Most Prominent Reasons The two most prominent reasons are obscured within the way the vast majority of the Organisation responds to a bug report of the applications and software • they are responsible for fixing and • they are not responsible for fixing The Reasons While there are many reasons, we will discuss the two most prominent reasons that have the maximum impact for the sake of time.
- 11. The Reason #1 The flawed approach towards mitigating software risks A common mitigation strategy of an Organisation or an independent developer upon receiving a bug report affecting the software that they are responsible for fixing: • Fix exactly what is reported • Fix exactly what is reported including any other instances of the same bug • Fix based on the bug’s risk rating but follow the second approach While this is fine, let's look at the disadvantages of each of these approaches.
- 12. Disadvantage of Such Mitigation Strategies You fix a reported bug but do not check for any bug instances or variants in the same application. You are likely to miss other instances and variants of the same bug in the application (if they exist). You fix all instances and variants of a particular bug in an application but do not check whether similar bugs exist in other applications you support. You are likely to miss instances and variants of the same bug if they exist in other applications. You follow the second approach but fix issues with relatively higher risk ratings (e.g. critical/high/medium) but do not fix any lower risk rating issue. Several historical evidence shows that bugs that look low hanging or trivial can be combined with other bugs to perform a more practical attack. Common Mitigation Strategies Disadvantages If your Organisation follows such bug mitigation strategies, you are far from making your application and software resilient against known security bugs.
- 13. Bug Instance(s) v/s Bug Variant(s) Bug Bug Instances Bug Variants XSS in a ‘Search’ functionality ❑ Same search functionality implemented in multiple areas of an application ❑ In other words, same piece of code used in multiple areas of an application For example: • Search for active users (in a store) • Search for active users (in live session) • Search for active users (in a chat room) ❑ A slightly different implementation of the search functionality in multiple application areas Example: • Search for authenticated users • Search for unauthenticated users • Search using basic filters • Search using advanced filters ❑ Various application functionalities echoing tainted user inputs without sanitization Example: • Form submit confirmation page displaying input texts • Login form showing invalid username entered in the resulting warning message • Chat room echoing entered texts
- 14. The Reason #2 Ignoring the security bug reports of other vendor’s or developer’s software Typical industry response towards a public security bug report affecting other vendor's or individual developer's software and applications: • This bug is not our problem; instead, it is someone else’s problem • The bug does not affect our software, hence not our problem While this seems like an obvious response, let's find out whether any external bug report relates to your software.
- 15. The Way “The Industry” Respond To Any Publicly Reported Security Bug The flow chart illustrates the most common industry response to a security bug report. Path A is the most common response to a security bug by the majority of the organisation. While Path B may look obvious, this is where is hidden one of the significant root causes of why we continue to see common security bugs that have been around for over 1-2 decades. Reason No.2
- 16. Understanding Bug Class and Bug Nature • Class of the bug can be described as the way a particular bug is exploited and/or it’s resulting impact. • Nature of the bug primarily relates to the root cause of the bug. • Example 1: Cross-Site Scripting in a file upload page • Here the bug class is Cross Site Scripting. • However, the nature of the bug is ‘missing sanitisation of tainted inputs’ • Example 2: SQL Injection in an authentication form • SQL Injection is a bug class name. • However, the nature of bug is insecure interpretation of tainted inputs as commands.
- 17. Translating A Bug Class To It’s Corresponding Root Cause and Bug Nature The above list is not comprehensive. Instead, these are few examples provided as a guideline to understand the difference between a bug class and the bug nature or the root cause. Bug Class / Type Root Cause Bug Nature Cross Site Scripting When unsanitised tainted input becomes output • Injection Flaw SQL Injection When unsanitised tainted input becomes a database/system command(s) • Injection Flaw • Insecure Interpretation of Input Cross Site Request Forgery Lack of server-side mechanism to differentiate between legit and forged HTTP(S) request • Trust Boundary Violation Broken Access Control Missing or inadequate check against required user/application permissions • Trust Boundary Violation • Inadequate Session Management Command Injection When unsanitised tainted user input becomes system command(s) • Injection Flaw • Insecure Interpretation of Input
- 18. Decoding The Nature of a Bug (MS00-083) CVE-2000-0817 (MS00-083): Buffer overflow in the HTTP protocol parser for Microsoft Network Monitor (Netmon) allows remote attackers to execute arbitrary commands via malformed data, aka the "Netmon Protocol Parsing" vulnerability.
- 19. Decoding The Nature of a Bug (More Examples) • File Parsing Vulnerabilities • MS04-007: ASN.1 parsing vulnerability (828028) • MS04-028: Buffer Overrun in JPEG Processing (GDI+) Could Allow Code Execution • Protocol Parsing Vulnerabilities • MS00-083: Netmon Protocol Parsing Vulnerability • CVE-2004-0054: Multiple vulnerabilities in the H.323 protocol implementation for Cisco IOS 11.3T through 12.2T • Path Parsing Vulnerabilities • MS00-017: DOS Device in Path Name Vulnerability • MS00-078: Web Server Folder Traversal Vulnerability All these examples imply that any parser can have such security problems. Therefore, if your goal is to eliminate all known classes of security bugs in your software, the way the industry must respond to external bug reports is provided in the next slide.
- 20. The Way “The Industry” Should Respond To Any Publicly Reported Software Bugs
- 21. • Reason #1: The flawed approach towards mitigating software risks • Depending upon your approach for fixing a bug, any unidentified variants or instances of a bug affecting your software could potentially get detected at a later stage, either through an authorised test or an unauthorised attack. • Each time your software goes through a security test, any previously reported bug class affecting the software keeps surfacing back implies that the initial mitigation approach did not adequately address all the bug instances or variants. • Regardless of whether your software is affected by a known bug class for the first time or it's variants/instances gets detected at a later stage, all these reports contribute to the overall global count of the bug class. • Reason #2: Ignoring the security bug reports of other vendor’s or developer’s software • Regardless of the business purpose or developer of a software/application used across the industry, they are likely to share standard functionality or implementation. • A bug affecting other vendors' or developers' software is likely to affect your software if similar implementations or variants of the affected functionality or design exist. • Decoding such external bug reports can aid in detecting any possible bugs in your software to ensure you are ahead in keeping your software resilient from the attack against known bug classes. • Therefore, ignoring other vendors' or developers' software bug reports means missing the opportunity to identify any potential bug that might be affecting your software. Summarising The Learnings From The Past
- 22. The Solution Tackling security vulnerabilities in the future based on the learnings from the past
- 23. Recommendations Based on the historical records of all the known bugs • Identify All Bug Instances and Variants (across all applications you support) • Upon identifying a bug in a particular application, identify all instances and variants across the same application and any other applications you support to apply appropriate mitigation consistently. • Combing Operation (to crack down on known security bugs) • Treat every security bug report as important regardless of whether it affects your or another company software and dissect the bug nature to take appropriate mitigation actions. • Thoroughly go through the historical bug records in the CVE databases (cvedetails.com and cve.mitre.org) or similar vendor databases, including the exploit databases (exploit-db.com), to identify all kinds of known bugs in your applications. • Attack Vector Database (Create and keep it up-to-date) • Keep the database updated with the intel obtained through the previous step regardless of whether the bug affects your or another company's software. • Refer to the database for identifying potential risks in your existing application and during future design changes. So these recommendations will take care of all known bug classes; what about unknown bug classes or 0-days?
- 24. Tackling 0-days or Unknown Bugs!!! Is it practical? 0-days are a bit overrated One must ask whether the industry has done enough to minimise the risk of 0-days to the extent that it is nearly impossible to exploit.
- 25. Shrinking The Attack Options Learnings from the way memory corruption bugs have been brought under control in OS, Web Browsers and OS-Native Apps Tackling 0-days or Unknown Bugs!!! Is it practical? Have you ever wondered why it is getting harder and harder to exploit memory corruption bugs on the modern operating system and web browsers? AND Why do we see a decline in successful memory corruption exploits for modern systems compared to web application exploitation? Let's find out how the modern Operating System / Web Browser mitigation approach excels as compared to web application mitigations.
- 26. Typical Exploit and Defense In Depth (Windows Edition) Trigger the bug Indirect Jump or call ROP Chain Shellcode (Payload) NOPSLED Typical Stack Based Exploit Building Blocks Trigger the bug Indirect Jump or call (jmp / call / Stack Pivot) ROP Chain Shellcode (Payload) NOPSLED ASLR DEP / NX Targeted Mitigation (behavioural v/s non-behavioural checks) ACG CFG / XFG Address Space Randomisation Mark memory pages as non- executable Prevents the ability to allocate new executable memory Prevent indirect jump or call. Note: CFG is deprecated, and an improved version called XFG will be introduced in future releases of Windows. Behavioural Check Non-Behavioural Check The example provided here is specific to modern Windows OS. However, a similar mitigation approach exists for all modern OS (Linux, macOS) and Web Browsers (Chrome, Edge, Firefox).
- 27. Targeted Exploit Mitigation (Windows Edition) https://docs.microsoft.com/en-us/microsoft-365/security/defender- endpoint/exploit-protection?view=o365-worldwide • Modern Operating Systems and Web Browsers focuses on killing all known techniques used in an exploit • The list includes both behavioural and non- behavioural checks Windows 10 Mitigation Available under exploit protection Arbitrary code guard (ACG) yes Block remote images yes Block untrusted fonts yes Data Execution Prevention (DEP) yes Export address filtering (EAF) yes Force randomization for images (Mandatory ASLR) yes NullPage Security Mitigation yes (Included natively in Windows 10) Randomize memory allocations (Bottom-Up ASLR) yes Simulate execution (SimExec) yes Validate API invocation (CallerCheck) yes Validate exception chains (SEHOP) yes Validate stack integrity (StackPivot) yes Certificate trust (configurable certificate pinning) Windows 10 provides enterprise certificate pinning Heap spray allocation Ineffective against newer browser-based exploits; newer mitigations provide better protection. See Mitigate threats by using Windows 10 security features for more information Block low integrity images yes Code integrity guard yes Disable extension points yes Disable Win32k system calls yes Do not allow child processes yes Import address filtering (IAF) yes Validate handle usage yes Validate heap integrity yes Validate image dependency integrity yes Windows 10 mitigation for various known exploit techniques
- 28. Limitation(s) of Web Application Mitigation The need for behavioural based checks • The widely used web application mitigation techniques primarily focus on non-behavioural checks against attacks • Example: Input Validation, Output Escaping, Parameterized Queries etc • There is limited or no focus on introducing behavioural based mitigation • The only available example of application-level mitigation using behavioural analysis leveraging ML is Google reCAPTCHA. • However, Google reCAPTCHA is limited in scope, addressing only a specific risk. Not sure, but thus far (Nov 2011), I have not seen any publicly available evidence of comprehensive behavioural based mitigation leveraging Machine Learning for web applications.
- 29. Introducing Behavioral Based Checks Leveraging Machine Learning for Applications and Softwares Image Source: chess.com • An adversary can only make a finite set of moves • Technically applications or software can be programmed to analyse infinite moves of an adversary and respond accordingly • Integrating Machine Learning (ML) with your critical application infrastructure can do such tasks with much ease. • ML/AI Technology has matured significantly over the years. • Any seasoned developer can leverage ML/AI technology to integrate with applications. Other than my talk at OWASP Global 2021, the concept of leveraging ML to perform behavioural based checks in web applications is likely never discussed or mentioned earlier. The goal is to create awareness in this direction and trigger some thoughts on implementing behavioural based checks for web applications/software.
- 30. Tackling 0-days or Unknown Bugs!!! Is it practical? Yes – To a larger extent • Kill All Known Bug Classes (Refer to the recommendations in the previous slides) • Refer to CVEs, exploit databases and other product vendors security advisory, to track the nature of bugs. • Map those bugs with your products/applications and address them if there are similar nature bugs • Continuously iterate over the above two methods to eliminate all known bug classes in your software ecosystem. • Introduce Machine Learning (ML) To Perform Behavioural Checks • Aside from the standard mitigation, introduce ML/AI technology to build behavioral checks within your application • Train the ML/AI to analyse and understand the nature of legit IN and OUT traffic. • Any deviation in use cases must be blocked and inspected. • Continuously train your ML with all good use-case and all known misuse cases to ensure that any deviation from good use cases gets blocked and inspected. • While achieving 100% resilience against 0-days may not seem practical. Still, with comprehensive defense-in-depth and leveraging ML, 0-days exploitation can be made very difficult to the extent that it becomes nearly impossible. Tackling 0-days in applications is a vast topic, and I'll expand over it in some other presentation later. However, the above steps are practical approaches to implement and start building defences against 0-days.
- 31. Integrating Machine Learning (in applications and software) ML Inference System ML Model Web Applications Application Logs Internet of Things Apache Kafka Web APIs Apache Kafka Data Source Data Destination ML Inference Host A simple design of ML integration with application
- 32. The Misconception The Silver Bullet In Software Security Engineering
- 33. The Paradigm Shift (in Software “Security” Engineering) Timeline 1985 1988 1999 2001 2002 2003 2004 2005 2006 2007 2009 2011 2012 2013 2014 2015 2017 2019 2021 Waterfall Initial Industry Adoption 1988: NIST SP 500-153 - Guide to Auditing for Controls and Security 2002: GIAC Paper - Security in the SDLC by Larry G 2004: IEEE Publication: Software Security by G. McGraw 2004: The OWASP Testing Project v1.0 2006 (May): Microsoft Secure Development Lifecycle by Michael Howard and Steve Lipner 2001 2002 2003 2004 2005 2006 2007 2009 2011 2012 2013 2014 2015 2017 2019 2021 Agile 2005 (Dec): Secure Software Development Life Cycle Processes by Noopur Davis (Brief mention of Security in Agile) 2006 (May): Microsoft Secure Development Lifecycle by Michael Howard and Steve Lipner 2006 (Aug): Department of Homeland Security - Security in the Software Lifecycle 2007 2009 2011 2012 2013 2014 2015 2017 2019 2021 DevOps Ideation Introduced Initial Industry Adoption 2012 (Jan): DevOpsSec: Creating the Agile Triangle (Gartner) 2012 (Apr): DevOpsSec Applying DevOps Principles to Security (DevOpsDays Presentation) 2015 (Oct): AWS re:Invent - Architecting for End-to-End Security in the Enterprise 2014 (Mar): OWASP Presentation - Continuous Security Testing in a DevOps World Security in Waterfall (Secure SDLC) Introduced Security in Agile (Secure SDLC) Security in DevOps (DevSecOps) The timeline indicates when the industry discussion or publication occurred regarding building security into various development lifecycles (i.e. Waterfall, Agile & DevOps).
- 34. The Paradigm Shift and The Rise In Misconception Snippets of Statements Extracted From Various Online Sources: • DevOps is better with security and security is better with DevOps • With DevOps, security gets to be introduced early in the development cycle and this minimizes risks massively • Apps Built Better: Why DevSecOps is Your Security Team’s Silver Bullet • Over the last few years, there has been a significant rise in the popularity of DevSecOps. • However, without proper clarity on when to go for DevSecOps, there has also been an increasing misconception about it. So, What Is Wrong With Such Statements? • These statements promote in a way that Secure SDLC works best only with DevOps • Similar statements can be found in several articles scattered all over the internet • While promoting DevSecOps is essential, overhype can be misleading
- 35. Applying Common-Sense Security In Each Engineering Lifecycle SDLC Security Stage-gate Activities Building Security into each software lifecycle = Common-Sense alignment of stage gate security activities Requirements Design Coding QA Release Requirements Review Design Review Code Review Penetration Testing Post-Release Testing Waterfall Next-Gen Cool Software Engineering Lifecycle Name?? ML/AI-Ops (DevOps+ML) DevOps Agile
- 36. Building Security into the SDL is always explicit, not implicit • Building security into the software engineering lifecycle (Waterfall, Agile or DevOps) is always explicit, not implicit. • A fixed set of common-sense security activities exists that remains the same across all types of development methodologies. • There is no such Silver Bullet in Software Security Engineering • The level of software security assurance largely depends on • how thorough the security assessment is done at each stage gate and • whether the vulnerabilities are mitigated timely
- 37. Migrating to DevOps / DevSecOps? Therefore, migrating to DevOps is only justified if it is a business requirement, not because you thought the entire industry was migrating toward it for better software security, and you must do the same.
- 38. The Herd Mentality (Going with the flow without rational thinking)
- 39. Final Words • Treat all known security vulnerabilities as a pandemic, especially if they have been around for over decades. • No one wants Covid-19 to last for the next 20 years. The same feelings apply to known security bug classes, particularly those around for over a decade or two. • If you use the suggestions made in this presentation to eradicate known bugs from applications and achieve success in eliminating them, then spread the word and talk about your success. • Your organisation's success story on eliminating all known bugs will inspire other organisations and potentially lead to a global ripple effect. • Let's reassess the state of known security bugs in about 20 years from now!!! ☺ Thanks for listening to this talk!!