C0c0n Owasp A9

This presentation at c0c0n 2015 examines OWASP A9: Using Components with Known Vulnerabilities, arguing that the problem extends far beyond traditional web application libraries to encompass everything from programming language packages (Python, Ruby, .NET) to WordPress plugins, Cisco network appliances, and the Android OTA update chain. Anant Shrivastava breaks down the complex patch lifecycle, identifies the three key stakeholders (component developers, application developers, and end users/sysadmins), and provides actionable guidance for each role in managing third-party dependency risk.

Key Topics Covered

• What Constitutes a Component: Any reusable piece of code — paid or open source — developed by someone other than you. Examples span Python packages (PyPI), Ruby gems, .NET NuGet packages, WordPress plugins, and even firmware on hardware like Cisco Security Manager and Cisco ASA appliances. The scope is deliberately broad: OpenSSL, Bash, Apache, and NGINX are all third-party components.

• Why Components Are Used: Unix philosophy of doing one thing well, code reuse to reduce development overhead, potentially faster combined evolution, and the high cost of developing equivalent functionality from scratch.

• The Two Distinct Problems: Known vulnerabilities in components and licensing policy issues. The presentation focuses exclusively on the security vulnerability aspect, ranked 9th in the OWASP Top 10 2013 with attack potential ranging from basic web attacks to remote code execution.

• Real-World Examples: Heartbleed as a flagship case of a component vulnerability with massive impact, plus data from BlackHat USA 2015 research by Jake and Kymberlee (“Stranger Danger! What Is The Risk From 3rd Party Libraries?”) demonstrating vulnerable vendor dependencies.

• Concerns with Third-Party Dependencies: For open-source software — developers may lose interest after scratching their initial itch, may not understand security implications and ignore reports, or may genuinely lack capacity to maintain the project. For closed source — companies may shift focus or lack resources for maintenance.

• The Patch Process Complexity: A multi-step chain where someone discloses a vulnerability, the vendor fixes the code, a public advisory is released, the application developer must update dependencies (complicated by backward compatibility, regression, and feature support concerns), and finally the sysadmin or end user must deploy the update.

• Android OTA as a Case Study: Illustrates extreme patch complexity — Google releases PDK to vendors, sends source to chipset manufacturers, chipset makers provide drivers or drop support, vendors update their custom software (SENSE, TouchWiz), work with carriers on modifications, submit for lab testing, obtain regulatory/industry/Google approvals, prepare OTA, and finally users download and install. This multi-stakeholder chain means security patches can take months to reach devices.

• Three Key Stakeholders and Their Responsibilities:

  • Sysadmins/End Users: Monitor software feeds for security updates, never ignore shared library updates, track how shared resources are holding up.
  • Developers (Application and Component): Identify and catalogue all components in use, never ignore pull requests or security bug reports, proactively test software and publicly accept security issues when fixes are released.
  • Component Code Developers: Be clear about support status, release updated versions with clear support status statements, and transparently accept and communicate security issues and fixes.

• Vulnerable Component Identification Tools: The presentation references tools for scanning and identifying known vulnerable components, though notes that comprehensive tracking across all third-party libraries still requires manual effort.

• Pentester’s Approach: Follow the same identification steps as administrators to catalogue all components, cross-reference findings with known vulnerability disclosures using dependency trackers, and leverage the results.

Actionable Takeaways

1. Maintain a comprehensive inventory of all third-party components used in your projects — including transitive dependencies, server software, and firmware — as the first step toward managing A9 risk.
2. Monitor vulnerability feeds and security advisories for every component in your dependency tree, and never ignore updates for shared libraries even if they appear to be minor.
3. As a component developer, be transparent about support status and security issues — publish clear advisories when vulnerabilities are fixed and update version metadata to reflect end-of-life status when maintenance stops.
4. Recognize that the patch lifecycle involves multiple stakeholders with competing priorities — build update processes that can handle dependency updates quickly when security advisories are released, despite backward compatibility and regression concerns.
5. Use automated dependency scanning tools to identify known vulnerable components, but understand that manual tracking is still required for comprehensive coverage across all library types.
6. When performing security assessments, always check the versions of all third-party components against known vulnerability databases as a standard part of the testing methodology.