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

[DennisClark]

The proposed normalized Exploits model spreadsheet at https://docs.google.com/spreadsheets/d/1J2t2T_s015pnAouy5ss-AA0SI4e2xjT4uICjlL_Aa38/edit?usp=sharing is ready for review.

[DennisClark]

The proposed normalized Exploits model spreadsheet at https://docs.google.com/spreadsheets/d/1J2t2T_s015pnAouy5ss-AA0SI4e2xjT4uICjlL_Aa38/edit?usp=sharing has been reviewed and ready for implementation.

[ziadhany]

@DennisClark I’ve been working on the Exploit model but encountered a few challenges:

• The resources_and_notes in Metasploit is a set of options like this:

"notes": {
  "AKA": ["Zerologon"],
  "Stability": ["crash-safe"],
  "Reliability": [],
  "SideEffects": ["config-changes", "ioc-in-logs"]
}

should we store it as a JSON or just a string?

• I'm also unsure about what should be stored in source_url for Metasploit, as references can include multiple URLs. Any guidance on this?

[pombredanne]

The content of the google referenced in the body of this issue at:
https://docs.google.com/document/d/1XtMmxthmANhr-IqXsyMgFnrOq5fTGfsE/edit?usp=sharing&ouid=117241222429542576816&rtpof=true&sd=true

is below for reference:

CRAVEX: Exploits in VulnerableCode

Ready for comments and additions. Essential related details are in: https://docs.google.com/spreadsheets/d/1J2t2T_s015pnAouy5ss-AA0SI4e2xjT4uICjlL_Aa38/edit?usp=sharing

CRAVEX project: See https://github.com/orgs/nexB/projects/56/views/1

Background

Objective: collect and normalize published exploit data in the VulnerableCode “Vulnerabilities” model. In addition to providing “references” to various exploit catalogs, store selected exploit details in VulnerableCode using normalized field names.

Related issues/PRs:

• CRAVEX: Vulnerability exploitability: Identify and store a vulnerability exploitability dejacode#98
• CRAVEX: Rank vulnerability exploitability: integrate KEV and EPSS dejacode#101
• CRAVEX: Collect and normalize exploit pointers #95

Exploit Sources:

• KEV: VCIO: Collect CISA Known Exploited Vulnerabilities #1028 and Add a basic model for Known Exploited Vulnerabilities  #1422
• exploitdb: Collect exploits from exploitdb #1453
• packetstorm: Collect exploits from Packet Storm #1452
• metasploit: Collect exploits from metasploit #1454
• CERTCC fork of metasploit: Collect CVE tagged with CERTCC fork of Metasploit Framework #1455

CRAVEX project: See https://github.com/orgs/nexB/projects/56/views/1

VulnerableCode model

KEV fields

The CISA-managed Known Exploited Vulnerabilities (KEV) catalog is now being extracted and stored in VulnerableCode, pending final confirmation.

See issue #1028 and PR #1422

Field details: https://docs.google.com/spreadsheets/d/1J2t2T_s015pnAouy5ss-AA0SI4e2xjT4uICjlL_Aa38/edit?usp=sharing

exploitdb fields

See issue #1453

ExploitDB doesn’t provide any PURLs, but it does include an alias like CVE-xxxx-xxxx ( codes column). We can iterate over these aliases and update the reference list by appending the exploit URL, PoC source URL, and other relevant links.

Field details: https://docs.google.com/spreadsheets/d/1J2t2T_s015pnAouy5ss-AA0SI4e2xjT4uICjlL_Aa38/edit?usp=sharing

metasploit fields for packetstorm, metasploit, and CERTCC

The metasploit-framework provides the field structure for multiple export catalogs:

Metasploit: https://metasploit.com/download

Source: https://github.com/rapid7/metasploit-framework

See issues:

• Packet Storm: Collect exploits from Packet Storm #1452
• metasploit: Collect exploits from metasploit #1454
• CERTCC fork of metasploit: Collect CVE tagged with CERTCC fork of Metasploit Framework #1455

Exploit files from packetstorm are available for download at https://packetstormsecurity.com/files/tags/exploit/

[pombredanne]

We have a decent coverage now. I am closing, and we have secondary issues available for later.