CRAVEX: Collect and normalize exploit pointers

[pombredanne]

We want to collect data about exploits.

• Collect exploits from exploitdb #1453
• Collect exploits from metasploit #1454
• Collect CVE tagged with CERTCC fork of Metasploit Framework #1455

PacketStorm #1452 is now descheduled and removed from plan as explained in #1452 (comment) for why

See discussion document at https://docs.google.com/document/d/1XtMmxthmANhr-IqXsyMgFnrOq5fTGfsE/edit?usp=sharing&ouid=117241222429542576816&rtpof=true&sd=true

See work-in-progress normalized model spreadsheet at https://docs.google.com/spreadsheets/d/1J2t2T_s015pnAouy5ss-AA0SI4e2xjT4uICjlL_Aa38/edit?usp=sharing and these fields are also in this CSV:
Vulnerability-Model - ExploitFields.csv

[armijnhemel]

exploitdb has moved to https://gitlab.com/exploit-database/exploitdb

[pombredanne]

This is a nice dataset:

• https://github.com/nomi-sec/NVD-Exploit-List-Ja the license is TBD though license? nomi-sec/NVD-Exploit-List-Ja#1

Also:

• https://github.com/Patrowl/PatrowlHearsData is Apache-licensed
• https://github.com/CERTCC/labyrinth/ by @ahouseholder now has a license and already aggregates the above.

[pombredanne]

And also https://github.com/nomi-sec/PoC-in-GitHub

[ahouseholder]

We're tagging vul IDs (more than just CVE) at

• https://github.com/CERTCC/exploitdb
• https://github.com/CERTCC/metasploit-framework

We pull updates from their respective repositories every few hours, crawl the diffs for IDs we recognize, and then tag the commit in which the ID first appeared.

• https://github.com/CERTCC/metasploit-framework/tags
• https://github.com/CERTCC/exploitdb/tags

The ID patterns we look for are here:
https://github.com/CERTCC/git_vul_driller/blob/dd49cec61aac5ee9e84d57313a7876145e0b1522/git_vul_driller/patterns.py#L15-L56

[ahouseholder]

• https://github.com/CERTCC/labyrinth/ by @ahouseholder now has a license and already aggregates the above.

Just to set expectations on data quality: Please be aware of the notes about signal-to-noise in the Labyrinth README. An ID that shows up in Labyrinth might be because there's an exploit repo that mentions it, or it could be a number of other relatively benign reasons because our code isn't smart enough to tell the difference. Labyrinth's findings are meant to serve as input to an analysis process, not a production exploit feed.

[ahouseholder]

On the other hand, we're more confident about the exploitdb/metasploit tags indicating exploits because there's a human vetting process involved (i.e., their developers decide what to include in their product).

[pombredanne]

@ahouseholder Thank you for the valuable insights. In the end, I want to know if my code is vulnerable. So the idea here with exploits is this, inc combination with reachability:

1. Using scancode to detect packages (PURL) or any of the many other tools that use PURLs and a lookup in VulnerableCode or in any other vulnerability DB that uses PURL I know I am potentially vulnerable
2. The I would like to automate as much as possible things to find out if my usage of the vulnerable package is exploitable. For this there are two tracks that I think can help:
   2.1. Static reachability: given knowledge of a fix commit and a static analysis of the vulnerable library interaction with my code, do I use any of the vulnerable code paths?
   2.2. Dynamic exploitability: given an exploit script (eventually curated to conform to a common interface and setup), is my configuration exploitable?

And if I am either exploitable or the vulnerable code is reachable, then I need to patch (possibly with the fix commit)

[armijnhemel]

Related: #655

[DennisClark]

See discussion document at https://docs.google.com/document/d/1XtMmxthmANhr-IqXsyMgFnrOq5fTGfsE/edit?usp=sharing&ouid=117241222429542576816&rtpof=true&sd=true

See work-in-progress normalized model spreadsheet at https://docs.google.com/spreadsheets/d/1J2t2T_s015pnAouy5ss-AA0SI4e2xjT4uICjlL_Aa38/edit?usp=sharing