Malware to Vulnerability Mappings.. Anyone?

[This was originally published on the OSVDB blog.]

Unbeknownst to many of us, MITRE’s Common Malware Enumeration (CME) project was declared dead, and apparently has been for a while. What is CME? From their site:

CME was created to provide single, common identifiers to new virus threats and to the most prevalent virus threats in the wild to reduce public confusion during malware incidents. This community effort was not an attempt to replace the vendor names used for viruses and other forms of malware, but instead to facilitate a shared, neutral indexing capability for malware.

With the demise of CME, are there any projects or companies that perform the same role? Specifically, do any maintain mappings between malware and the exploit they use for propagation? Are there any anti-virus vendors that are specifically good about cross-referencing CVE identifiers (or any VDB) to malware?

OSVDB maintains a classification to denote if a vulnerability has been “wormified”, but does not have a mechanism to map more details. When readily available, we will include the malware’s name in keywords, but that is not a flexible solution either. With CME gone, and no obvious vendors or projects that perform this, OSVDB is considering enhancements to fill this void. Before we begin, we’d really like to be sure we aren’t re-inventing a wheel, just replacing a lost wheel (R.I.P. CME). To be clear, we’d only seek to track malware that had a ‘vulnerability’ component to it, not every variation of “CLICKMESTUPID.EXE”. We’ll leave that to the malware detection shops.

What features are sorely lacking from VDBs?

[This was originally published on the OSVDB blog.]

For over ten years, most Vulnerability Databases (VDBs) have done little to evolve. In some cases, they appear to be devolving. OSVDB recognized this many long ago but has struggled for years with a lack of resources, particularly developers. Now that we have saved up enough money, we have hired our only developer part time. Within weeks, Dave has implemented CVSSv2 scoring, enhancements to search, fixes dozens of bugs and already has working mock ups of several additional new features that should fully demonstrate our commitment to evolution. That lead me to think.. while we have dozens of ideas for enhancements and features, what do the users want? Or more to the point, for people who don’t use our database, what features do you find missing from OSVDB or your favorite VDB? What could a VDB do differently, or do better, to make it a (more) valuable resource? No promises on what we can or will implement, but we are all ears. Mail moderators[at]!

OSVDB – Search Enhance: by CVSS Score or Attribute

[This was originally published on the OSVDB blog.]

Using the ‘Advanced Search‘, you can now search the database by entering a CVSSv2 score range (e.g., 8 to 10) or by a specific CVSSv2 attribute (e.g., Confidentiality : Partial). To search for entries with only a 10 score, use the search range 10 to 10.

Using this search mechanism, we can see there are 3,217 entries in the database with a score of 10 and 9,266 entries that involve a complete loss of availability.

We hope this flexibility allows for even more refined searches to better help your project or organization. Stay tuned, this is one of many new search features planned.

OSVDB – Metasploit Reference Support Added & More

[This was originally published on the OSVDB blog.]

This week, HDMoore of Metasploit and OSVDB moderators discussed cross-reference support for each product. As many are now seeing, Metasploit has a search module that allows for fast searches by a number of external references, including OSVDB.

On the OSVDB side, we now support a ‘Metasploit ID’ that currently uses the corresponding OSVDB ID to link and auto-search their database. Based on our testing, this is working great and offers cross-references to 400 Metasploit exploit modules! At the risk of pre-empting HDMoore, I am happy to announce that this is only the first step in the support each project will offer.

In the coming weeks, Metasploit will migrate to a numeric ID scheme to catalog their exploit archive. Each exploit will have it’s own page with what you see now, plus a lot more. With those unique IDs, OSVDB will change the way we link to Metasploit so there is a 1:1 mapping between projects. This will allow us to have accurate coverage for 100% of the Metasploit modules. When this happens, we will display these links under “Tools & Filters” instead of “References” along with a Metasploit logo.

If you weren’t aware, HDMoore created the concept of OSVDB and participated in the original design (~ Aug 2002). That means he has been supporting OSVDB for over seven years now. We’re pretty sure that means we owe him a beer.

OSVDB – Classification: Exploit Status Overhaul

[This was originally published on the OSVDB blog.]

OSVDB’s classification system is designed to categorize certain attributes of a vulnerability. This facilitates custom searches by a specific attribute, helps researchers develop metrics and gives a better picture of the vulnerability landscape. Until now, we’ve tracked if an exploit is ‘available’, ‘unavailable’, ‘rumored / private’ or ‘unknown’. While this was a good start for exploit status, it has quickly outgrown usefulness. Today, OSVDB overhauled the exploit classification to use the following:

  • exploit public – A working exploit is publicly available.
  • exploit rumored – An exploit is rumored to exist, but cannot be confirmed.
  • exploit private – An exploit exists, but is not available to the public or in a commercial framework (e.g., vulnerability pre-disclosure groups like iDefense or ZDI, researcher developed but unreleased).
  • exploit commercial – An exploit has been created and is available to customers in a commercial framework such as Canvas or CORE Impact.
  • exploit unknown – The status of a working exploit is unknown.

In addition, we are moving one existing classification to the ‘exploit’ column since it is relevant to this category:

  • exploit wormified – An exploit has been crafted to spread via ‘worm’ or ‘virus’.

As always, if you have suggestions or questions about the classification system, please mail moderators[at]!

OSVDB – Classification: Minor Touch-ups and Reorganization

[This was originally published on the OSVDB blog.]

In addition to overhauling the ‘exploit’ classification, additional touch-ups and reorganization has been done to the classification system. For volunteers that help mangle entries, watch out as items have shifted in flight. For users of OSVDB, these will be mostly cosmetic changes and should not impact searching.

  • Disclosure column has been re-ordered
  • Location column has been re-ordered
  • Several locations have been touched-up. Use of ‘required’ is consistent now.
  • Context-dependent – Moved from OSVDB to Location
  • Mobile Phone expanded to include ‘Hand-held’ devices that may not be a phone
  • Patch now includes RCS as some fixes are only available from CVS, SVN, etc.
  • Removed ‘best practice’, no longer useful. We do not support SANS Top 20 x-refs any longer, since they don’t support the “20” in the Top 20.
  • Removed ‘no solution’. Until we have more volunteers and timely updates for all entries, ‘solution unknown’ is more accurate.
  • Removed ‘hijacking’ attack type. Obsolete, not really an attack type of its own.

Boxes on the Porch

On Thursday, I lost Figlet. After six months of diagnosis with two doctors, we finally determined she had Hyperthyroidism, which is extremely rare in piggies. The doctor I was taking her to was an exotic specialist who had specifically done research on Hyperthyroidism in guinea pigs. In all of his time, he had six confirmed cases, so Figlet was only his seventh. Blood work showed Figlet had no kidney damage, which is a byproduct of HT. The options before the blood work were to have the mass removed now, before complications occurred in her heart and kidney (if the BW came back good), or let her live out the rest of her life with HT if she had signs of kidney damage (because HT ‘treats’ some of the problems it can lead to). The clean blood work and urinalysis meant surgery was the best option.

After the mass was removed, Figlet’s body didn’t react well. Between her already high blood pressure due to HT, and the body rejecting the change in her thyroid, blood pressure and several other things, it couldn’t adapt. She passed on the surgery table. She was completely under at the time, she did not suffer at all. That doesn’t help me though, as she would have lived out another year or two with HT before having serious complications with heart and kidney. Complications that may have lead to having to choose to let her pass before she started suffering. Instead of that year or more, in trying to do the right thing to make her healthy and ‘normal’, I lost her.

got home today, found a box on the doorstep from the University that I was taking Figlet to. I had a bad feeling I knew what it was. I opened it to find two things; a clay disc with four
paw prints and ‘Figlet’ at the top and a small ziplock bag with her infamous butt plume hair.

I understand keepsakes from departed pets, but i am not one for that. This box annoyed the living hell out of me because the last conversation I had with one of the doctors there went
like this:

Megan: Afraid I have bad news..


Megan: We will do a necropsy, free of charge of course..
Me: Yes, I do that for all of my pigs, I’d like to know exactly what happened.


Megan: Would you like the body or for us to send it to Whoever Keepsakes?
Me: No, dispose of normally, I don’t do any keepsakes or memory items.


For them to do turn around and do that anyway is disheartening.

Figlet Pictures
Extensive write-up of her diagnosis

OSVDB Now Supports CVSSv2 Scoring

[This was originally published on the OSVDB blog.]

OSVDB now displays CVSSv2 scores, mostly as calculated by the National Vulnerability Database (NVD):


Along with the score, we display the date that NVD generated it and give users a method for recommending updates if they feel the score is inaccurate. While this is long overdue, this is one of many CVSS related features we will be adding in the near future. For those wondering about the delay in adding CVSS support, the cliff notes answer is “we had reservations about the scoring system”. Back in 2005, Jake and I had a long chat with a couple of the creators of CVSS and brought up our concerns. Our goal was to create our own scoring system, but internal debate (and procrastination) lead to neither being implemented. Rather than creating our own system, we finally opted to use what has become an industry standard. Some of our planned CVSS score enhancements on the to-do list, no particular order:

  1. Method for adding our own CVSS score. There are thousands of entries in OSVDB that do not have a CVE assignment, and as a result, no NVD based CVSS score.
  2. A more robust moderation queue to handle proposed changes. This may optionally have a one-click method for us to notify NVD of our change so they may consider revising their score.
  3. Ensure the CVSSv2 score is part of the database dumps, available for download.
  4. Method for tracking CVSS score historically. As NVD revises their score, or we do, a user should be able to see the history of changes.
  5. Compare our/NVD scores with other public tools, display discrepancy if different. For example, if a Nessus plugin scores an issue differently than NVD, show both scores so users may consider which is more accurate.
  6. Track researcher generated CVSS score. While infrequent, some advisories provide scoring. If different than NVD, display the discrepancy.

As always, if you have ideas on how we could better handle CVSS scoring, or have additional ideas for features, please contact us!