The long and winding road…
… that leads to your door will never disappear…
Sorry about The Beatles lyrics, but the last couple of months have seemed like a rather long and winding road as far as posting new vulnerabilities is concerned. Many hours (days/weeks/months) of combined effort went into making OSVDB 2.0 a reality. When that finally happened, we were faced with another new challenge: clear out what appeared to be a huge backlog of vulnerabilities stacked up in what we refer to as “NDM”, or the New Data Mangler queue. Cliffs Notes: the NDM queue is a backend stash of vulnerabilities that haven’t yet been added to the front-end database; those entries generally need basic information added such as disclosure dates, external references, and titles that clearly reflect the nature and impact of a vulnerability. At the time OSVDB 2.0 was released, we were looking at a queue of over 1,000 entries in the main NDM queue that each needed at least a couple of minutes of attention.
I’m taking a few minutes away from the NDM queue to type this post. When I started typing, the NDM queue was sitting at 331. As of this sentence, it’s now at 325 as Jericho works on pushing more vulns to “new” status. That doesn’t include the new vulnerabilities that come into NDM on a daily basis, so the drop of 700 vulns is NET, not gross. On or about January 5, 2008, OSVDB’s database gathered its 40,000th vulnerability. In the last 52 days, over 2,200 vulnerabilities have been added to the database. We would like to thank everyone who has supported OSVDB by taking their time to add references, vendors, credits, and descriptions, but we have a little surprise…
There’s another 2,000 vulnerabilities or so to go until we can say we’re “caught up”. We also have a very large stash of CVE-listed vulnerabilities dating back to at least 2002 that require data entry and inclusion into the database. For now, we’re focusing on getting the most recent vulnerabilities into the database, but we will DEFINITELY need more help going forward. If you’re interested in being involved, please let us know; OSVDB is a COMMUNITY project and we would like to have more people involved to help improve data quality, data quantity, and security awareness as a whole. For any questions or comments, please mail us at firstname.lastname@example.org
back to NDM… down to 324… ;)
This time, it happened to the OSVDB blog. Unfortunately, WordPress doesn’t have a very good track record on security. During the migration from the old OSVDB to 2.0, we noticed a problem with the blog and several ‘spam’ posts appearing. We attributed it to one of the many previous wordpress bugs. We cleaned out the tainted posts, upgraded to the latest wordpress, and went on our merry way.
Shortly after, a blog reader contacted us to point out that existing posts we made had “noscript” advertisements embedded in them. Our expansive development team (the overworked Dave) looked into it. He started looking through the files for any obvious signs of a compromise – checked the plugins, etc. All seemed normal. Next he checked the web logs and noticed Chinese addresses POSTing to xmlrpc.php at various times throughout the day, most often at night. He then enabled XMLRPClogging inside of the script, cleaned out the database again, and noticed lots of just this:
2008-01-31 04:04:00 Input:
2008-01-31 05:01:43 Input:
2008-01-31 19:29:01 Input:
Posts continued to be altered during his investigation. Suspecting user account compromise, he checked the WordPress users, noticed a good chunk of new users had been added in recent months, mostly all obvious spam users. Spam users aren’t uncommon, but usually a small percentage. In the past few months, the vast majority of users were spam users.
When OSVDB 41136 came out, it all became clear. Since fixing the vulnerability, no posts have been edited.
I know this post is late, but we wanted to clear up any confusion and set the record straight on what occurred. We can definitely say this vulnerability was discovered in the wild.
In a recent discussion on the security metrics mailing list, Pete Lindstrom put forth a rough formula to throw out a number of vulnerabilities that have been discovered versus undiscovered. One of the data points that he cited lead me to his page on “undercover vulnerabilities”, his term for “0-day” in a certain context. Since the term “0-day” has been perverted to mean many things, he clearly defines his term as:
Undercover Vulnerability: A vulnerability that was generally unknown (e.g. not published on any lists, not discussed by “above ground” security folks) until it was actively exploited in the wild. The vulnerability was discovered through evidence of tampering or other means, not through the usual bugfinding ritual.
In my reply challenging some of his numbers, I specifically said that “if we consider that your number 20 is off by at least half, and I would personally guess it’s more like a small fraction, how does this change your numbers?” Pete took this in stride and offered to buy me a case of beer if I could find half a dozen that he didn’t have. Not one to pass up free booze and vulnerability research (yes, i’m weird) I spent several hours Friday doing just that. I ended up with 24 vulnerabilities that seemed to match his definition, roughly half of them in his time frame (“in the last two years”).
Pete’s page got me wondering just how many vulnerabilities classified as ‘undercover’ by his definition. Further, I thought about another question he asked on his page:
I am open to suggestions on an easy way to do this with TypePad (TypeLists, maybe?). Else, I’ll just periodically update as new vulns become available.
I cornered our lead developer Dave and said “make it so” while I mailed Pete asking if OSVDB could help in this effort. As a result, we now have a new classification that we call “Discovered In the Wild” that means the same thing as Pete’s “undercover vulnerability”. I have updated the 20 vulnerabilities listed on his page and added the flag to the ones I researched. This now shows 43 results which is good progress.
Not content with that, I asked a fellow geek who has a world more experience with IDS, NOC management and various devices that would be prone to catching such vulnerabilities “how many do you think were found this way last year”, to which she replied “at least 50”. So vulnerability researchers and OSVDB contributors, it’s up to you to help out! We’re looking for more instances of vulnerabilities being discovered “in the wild”, being exploited and subsequently disclosed (to mail list, vendor, whatever). Please cite your source as best as possible.
To see what we have so far:
- Under “Vulnerability Classification” and “Disclosure”
- Check “Discovered in the Wild”
Thanks to Pete Lindstrom and the Security Metrics mailing list for the input and great idea for a new classification!
New Database Export Formats & OSVDB Personal Edition
We just introduced 3 new database export formats:
- MySQL (mysqldump)
The easiest of the three to download and dive into is SQLite, though the MySQL dumps take a close second. The CSV tarball also includes a SQL script to import the data into MySQL simply for reference. Perhaps someone can contribute a Postgresql CSV import script?
All of these are available at the database info page – along with an updated visual representation of the Schema. The old XML dumps are still there and continue to run, but the scripts used to process them are now officially deprecated. Simple reason being that they don’t work any longer, and given the above new methods of getting your hands on the data, the old scripts are obsolete anyways.
Also, as a sample of how one can utilize the new export formats, we’re releasing OSVDB Personal Edition. OSVDB Personal edition is a very small Ruby on Rails application that utilizes the SQLite database export to give you your own, albeit relatively feature-less, local OSVDB instance.
It’s quick and easy to setup (requires a few dependencies be installed, all documented in the README), and has been tested on Linux, Windows XP, Windows Vista, and Mac OS X Leopard. There are some minor issues running on Tiger, which are somewhat documented in the README.
OSVDB Personal Edition is not intended to really be a new offering by OSVDB, as aforementioned, it is primarily a way to showcase our new database exports. You can grab it from our tools section.
In less exciting news, the vendor dictionary has been rid of the annoying ajax popups, and the search engine has received some mild tweaking.