Scribd
Upload
8 views

Attack02 Vulnerable Components

Uploaded by

Tzar Umang
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
8 views

Attack02 Vulnerable Components

Uploaded by

Tzar Umang
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 15

Attack 02

Vulnerable Components
Concept
• This lesson will walk through the difficulties with managing
dependent libraries, the risk of not managing those dependencies, and
the difficulty in determining if you are at risk.
• Testing and handling vulnerabilities from old components and or
plugins and security them in chances that there are no updates
available.
Goals
• Gain awareness that the open source consumed is as important as your
own custom code.
• Gain awareness of the management, or lack of management, in our
open source component consumption.
• Understand the importance of a Bill of Materials in determining open
source component risk
The Open Source Ecosystem
• 10+ Million GitHub code repositories
• 1 Million Sourceforge code repositories
• 2500 public binary repositories
• Some repositories have strict publisher standards
• Some repositories enforce source code distribution
• No guarantee the published source code is the source code of the published binary
• Some repositories allow the republishing of a different set of bits for the same
version
• Some repositories allow you to remove published artifacts
• Many different packaging systems; even for the same language
• Different coordinates systems and level of granularity
Knowing the OSS "Bill of Materials" is the
starting point
Questions we should know the answer to:
• How do we know what open source components are in our applications?
• How do we know what versions of open source components we are using?
• How do we define the risk of open source components?
• How do we discover the risk of open source components?
• How do we associate a specific risk to a specific version of an open source component?
• How do we know when a component releases a new version?
• How do we know if a new vulnerability is found on what was previously a "good"
component?
• How do we know if we are using the authentic version of an open source
component?
How do I generate a Bill of Materials
• There are several open source and paid-for solutions that will identify
risk in components. However, there are not many tools that will
deliver a complete list of "ingredients" used within an application.
OWASP Dependency Check provides the ability to generate a bill of
materials and identify potential security risk.

• Tools that can be used is Burp Suite and Zen Owasp


Security Information Overload
What’s important?
• Is my component exploitable?
• Is my component an authentic copy?
• Do I understand why my component is modified?
Security information is scattered everywhere
• Multiple sources of security advisories
• 80,000+ CVEs in the National Vulnerbility Database
• Node Security Project, Metasploit, VulnDB, Snyk, …​
• Thousands of website security advisories, blogs, tweets, …​
• 600,000 GitHub events generated daily
• 700 GitHub security related events
• Release notes, change logs, code comments, …​
Security Information Overload
Summary
• It is not reasonable to expect a developer to continually research each
component.
• Developers are not security experts; they already have a day job.
License Information Overload
What’s important?
• Can I use this component within the context of distribution of my software?
• Are there license incompatibilities?
• If using a modified component, did I addressed additional license obligations?
License information is scattered everywhere
• Projects declare a license:
• In a project metadata file.
• On the project website or source code repository page.
• Using a link to a license file in their own source code repository.
• In a license file within the project source tree.
• In the binary META-INF folder.
• Projects include licenses as headers in the source code.
License Information Overload
Summary
• It is difficult to determine the scope of a license.
• A project often has license discrepancies.
• Developers are not lawyers .
Architecture Information
• What’s important?
• Is my component old or is it stable
• Is my component unpopular
• Was my lack of upgrade a deliberate choice or a lack of knowledge
• Summary
• It’s difficult to keep components up to date
For the components analyzed in 25,000 applications it was found that:
• 8% of 2 year old components did not have a newer version
• 23% of 11 year old components did not have a newer version
• Older components make up the majority of the risk
OSS Risk: Commons Collections
• In November of 2015, the Apache Commons Collections component
latest release was 8 years old. Commons Collections was considered a
reliable and stable component. A researcher found a way to exploit a
deserialization issue in Commons Collections resulting in a remote
code execution. The next day…​everyone using Commons
Collections was in a panic.
• Ref:
Thousands of Java applications vulnerable to nine-month-old remote code exe
cution exploit
OSS Risk
• Dinis Cruz and Alvaro Munoz exploit of XStream
• XStream, a relatively common XML and JSON parsing library, has a nasty
little remote code execution.
Ref: Dinis Cruz Blog
pwntester/XStreamPOC

You might also like