Understanding The Known: OWASP A9 Using Components With Known Vulnerabilities
A presentation at c0c0n 2015 in in Kochi, Kerala, India by Anant Shrivastava
UNDERSTANDING THE KNOWN A9 : USING COMPONENTS WITH KNOWN VULNERABILITIES BY ANANT SHRIVASTAVA
ANANT SHRIVASTAVA Information Security Consultant Admin - Dev - Security null + OWASP + G4H http://anantshri.info and @anantshri Trainer / Speaker : Blackhat USA, NullCon, g0s, c0c0n, Clubhack, RootConf
WHAT IS A COMPONENT Any piece of code that is reusable Paid or OpenSource Either by same developer or other developers Its lot more then what you know
PYTHON PACKAGES Programming Language
RUBY GEMS Programming Language
MICROSOFT .NET PACKAGES Programming Language
WORDPRESS PLUGINS Web Application
CISCO SECURITY MANAGER Cisco Security Manager
CISCO ASA Cisco ASA Hardware
AND MANY MORE
WHY COMPONENTS Unix Philosophy : Do one thing and do it well Code Reuse : “Less Development Overhead” “Potentially” Combined and Faster evolution Higher cost to develop from scratch
IN SHORT Any component which is not developed by you is a 3rd party package in use
NOT DEVELOPED BY YOU
NOT DEVELOPED BY YOU 1. 2. 3. 4. OpenSSL Bash Apache NGINX and many more
UNDERSTANDING THE KNOWN USING COMPONENTS WITH KNOWN VULNERABILITIES
TWO DISTINCT PROBLEMS 1. Component has known vulnerability 2. Licensing Policies Talk focus only on the first part
COMPONENT WITH KNOWN VULNERABILITY Marked as 9/10 in OWASP Top 10 Vulnerabilities in 2013 Attacks can range from basic web attacks to Remote Code Execution
SOME EXAMPLES
HEARTBLEED
VULNERABLE VENDOR Credits: Jake & Kymberlee : Stranger Danger! What Is The Risk From 3rd Party
Libraries? : Blackhat USA 2015 MORE Credits: Jake & Kymberlee : Stranger Danger! What Is The Risk From 3rd Party Libraries? : Blackhat USA 2015
REMEMBER We rely on 3rd party to 1. 2. 3. 4. patch maintain security accept security issues in short “NOT SCREWUP”
WHAT ARE THE CONCERNS 1. Open Source Software 1. Developer has scratched his itch and will not want to work on it 2. Developer doesn’t understand security implications and ignore reports 3. Developer is genuinely not in a position to work on project 2. Closed Source Software 1. Company shifted focus 2. Not enough money
WHAT IF THEY DO ALL THE FIXES IN TIME
PATCH PROCESS 1. Someone disclosed a vulnerability 2. 3rd party vendor fixes code 3. A public advisory is released informing about the update and hopefully security issue 4. Developer has to update the dependencies in actual project (believe me when i say its not easy task) (backword compatibility, regression, feature support etc) 5. Sysadmin / user has to update the software to receive the update
LOOKS COMPLEX
ANDROID OTA PROCESS 1. 2. 3. 4. 5. 6. Google released PDK to Vendor for evaluation Google Announces new version Google send source code to Chipset manufacturer and Vendor Chipset manufactures provides drivers and BSP or stops support Vendor evaluates requirement for device if no driver then no update Vendor updates its own softwares (SENSE, TouchWiz etc) Cont.
ANDROID OTA PROCESS… 1. 2. 3. 4. Vendor works with carrier for modification Final build is submitted for Lab Entry and testing If bug found patch and resubmit. Take approvals from 1. Regulatory 2. Industry 3. Google 5. Prepare OTA for the Device 6. User Downloads OTA and updates the device
BIGGEST QUESTION WHAT WE CAN DO
3 KEY PLAYERS 1. Component Code Developer 2. Programmer reusing component 3. Enduser/sysadmin using the final program
THEN THERE IS PENTESTER
LETS EVALUATE ONE BY ONE
SYSADMIN / ENDUSER Monitor your software feeds to ensure you do not miss security updates never ignore update from shared library Keep an eye on how shared resources are holding up
DEVELOPERS (SOFTWARE AND 3RD PARTY) 1. Identify and catalogue your components 2. Never ignore pull requests and security issue bug report 3. Proactively test software and at-least if a fix is released publicly accept security issue
ANY AVAILABLE TOOLS
VULNERABLE COMPONENT IDENTIFICATION
IDENTIFICATION
IDENTIFICATION
IDENTIFICATION
IS THIS ENOUGH 1. Not yet 2. We still lack method to track it for every third party library 3. Manual tracking is still required
COMPONENT CODE DEVELOPER 1. Be clear about support status 2. If out of support, release and updated version clearly stating support status 3. Clearly accept the security issues and inform about fix
PENTESTER 1. Follow steps for Admin to identify all components 2. Cross reference with known disclosures (use dependency trackers) 3. Profit
REFERENCES 1. BlackHat 2015 : Stranger Danger! What Is The Risk From 3rd Party Libraries? : DO CHECK VTEM 2. The Unfortunate Reality of Insecure Libraries: Jeff Williams,Arshan Dabirsiaghi : March 2012 3. https://www.gov.uk/service-manual/making-software/dependencymanagement.html 4. http://swreflections.blogspot.in/2013/10/dont-let-somebody-elses-technicaldebt.html
REFERENCES 1. https://prezi.com/g-01vdbth1co/sonatype-survey-2013/ 2. http://blog.softfluent.com/2011/08/19/leveraging-third-party-components-orreducing-dependencies/ 3. https://img.en25.com/Web/SonatypeInc/%7Bb2fa5ed8-938d-4bce-8a9cd08ebeba826d%7D_Executive_Brief_-_Study_Understanding_Security_Risks_in_OSS_Components-1.pdf
ANY QUESTIONS
ANANT SHRIVASTAVA Information Security Consultant Admin - Dev - Security null + OWASP + G4H http://anantshri.info and @anantshri Trainer / Speaker : Blackhat USA, NullCon, g0s, c0c0n, Clubhack, RootConf
THANK YOU
c0c0n 2015 Presentation. This talk discussed about the impact of using components with known vulnerabilities along with various tips and tools for software developer or administrator to facilitate identification of vulnerable components.
