Today, The Register wrote an article on MITRE’s announcement of a new CVE ID scheme, and got many things wrong about the situation. As I began to write out the errata in an email, someone asked that I make it public so they could learn from the response as well.
From The Register:
The pilot platform will implement a new structure for issuance of Common Vulnerabilities and Exposures numbers. MITRE will directly issue the identifiers and bypass its editorial board.
The old system bypassed the Editorial Board. The Board isn’t there to give input on assignments, not for over 10 years. The criticism right now is that the new system was rolled out without consulting the Board, which the board is supposedly there for:
The MITRE Corporation created the CVE Editorial Board, moderates Board discussions, and provides guidance throughout the process to ensure that CVE serves the public interest.
The last ID scheme change was after more than a year of discussion, debate, and ultimately a vote by the board (11/2/2012 Start –> 6/7/2013 End). This ID scheme change was a knee-jerk response to recent criticism (only after it became more public than the Editorial Board list), without any board member input. From The Register article:
The CVE numbers are the numerical tags assigned to legitimate verified bugs that act as a single source of truth for security companies and engineers as they seek to describe and patch problems.
No… CVE IDs are assigned to security issues, period. Alleged, undetermined, possible, or validated. Many IDs are assigned to bogus / illegitimate issues, which are generally discovered after the assignment has been made. There is no rule or expectation that IDs are only assigned to legitimate verified bugs. To wit, search the CVE database for the word “REJECTED”.
More importantly, the notion it is a “single source of truth” is perhaps the worst characterization of CVE one could imagine. Many companies use alternate vulnerability databases that offer more features, better consumption methods, and/or much better coverage. With MITRE falling behind other VDBs by as many as 6,000 vulnerabilities in 2015 alone, it isn’t a single source for anything more than training wheels for your vulnerability program.
The platform will exist alongside the current slower but established CVE system.
At this point, with what has been published by MITRE, this is pure propoganda in line with the platitudes they have been giving the Editorial Board for the last year. The new format does not make things easier for them, in any way. The ‘old ID scheme’ was never the slowdown or choke point in their process. In fact, read their press release and they say they will be the only ones issuing federated IDs, meaning the same problem will happen in the interim. If it doesn’t, and they start issuing faster, it wasn’t the new scheme that fixed it. More important to this part of the story is that it wasn’t just about assignment speed. The last six months have seen MITRE flat out refuse assignments to more and more researchers, citing the vulnerable software isn’t on their list of monitored products. Worse, they actually blame the Editorial Board to a degree, which is a blatant and pathetic attempt at scape-goating. The list they refer to was voted on by the board, yes. But the list given to the board was tragically small and it was about arranging the last chairs on the Titanic so to speak.
He says MITRE is aiming for automated vulnerability identification, description, and processing, and welcomed input from board members and the security community.
This is amusing, disgusting, and absurd. MITRE, including the new person in the mix (Sain) have NOT truly welcomed input from the board. The board has been giving input, non-stop, and MITRE has been ignoring it every single time. Only after repeated mails asking for an update, do they give us the next brief platitude. Sain’s title, “MITRE CVE communications and adoption lead”, is also ironic, given that just last week Sain told the board he would contact them via telephone to discuss the issues facing CVE, and never did. Instead, there was no communication, and MITRE decided to roll out a scheme that was horribly designed without any input from the Board or the industry.
For those who want a better glimpse into just how bad MITRE is handling the CVE project, I encourage you to read the Editorial Board traffic (and hope it is updated, as MITRE still manually runs a script to update that archive).
As we approach the pinnacle of U.S. sportsball, I am reminded of the complete scandal from a past Superbowl. No, not the obviously-setup wardrobe malfunction scandal. No, not the one where we might have been subjected to a pre-recorded half-time show. The one in 2013 where
hackers terrorism who-knows-why caused the stadium lights to go out for 34 minutes. That day, and the days after, everyone sure seemed to ‘know’ what happened. Since many were throwing around claims of ‘hacking’ or ‘cyber terrorism’ at the time, this incident caught my attention.
Here’s what we know, with selected highlights:
- February 3, 2013: Superbowl happened.
- February 3, 2013: Anonymous takes credit for the blackout.
- February 3, 2013: Because theories of hacking or terrorism aren’t enough, Mashable comes up with 13 more things that may have caused it.
- February 4, 2013: A day later, we’re once again reminded that “inside sources” are often full of it. Baltimore Sun initial report claimed a “power-intensive” halftime show might have been a factor.
- February 4, 2013: The FBI makes a statement saying that terrorism was not a factor.
- February 4, 2013: We learn that such a failure may have been predicted in 2012.
- February 4, 2013: Of course the outage doesn’t really matter. A little game delay, and it is a “boon for super bowl ratings“, the most critical thing to the corrupt NFL.
- February 4, 2013: By this point, people are pretty sure hackers didn’t do it. They probably didn’t, but they could have!
- February 4, 2013: Oh sorry, it could still be hackers. The Christian Science monitor actually covers the likely reason, yet that isn’t sexy. Chinese hacker ploy seems more reasonable to cover…
- February 4, 2013: Not only Anonymous, but ‘Rustle League’ claimed to hack the super bowl. A day later we learn that notorious Rustle League trolls were … wait for it … trolling.
- February 5, 2013: Officials at Entergy, who provide power for that property clearly state “There was no Internet or remote computer access to the piece of equipment inside the stadium that sensed an abnormality in the electrical system and partially cut power to the Superdome…”
- February 6, 2013: While the Superdome was not hacked on Sunday, the U.S. Federal Reserve was.
- February 8, 2013: Multiple sources begin covering the real reason for the Superdome outage.
- February 8, 2013: We now have a good idea what caused it, but let the blame game begin. Manufacturer error, or user error?
- March 21, 2013: The official Entergy report is released (PDF), giving a very technical analysis and summary of what happened. Everyone but conspiracy theorists can sleep well.
The reason for this blog is that Chris Sistrunk, a noted SCADA security researcher, pinged me the other day about the report. We were curious if the failure described could be considered a vulnerability by OSVDB standards. After reading the report and several questions for him, this seems like a simple case of device malfunction / failure. Quoting relevant bits from the report:
During the testing, behavior of the relay was not entirely consistent with the function described in the instruction manual. Under some circumstances, when the current exceeded the trip
setting and then decreased below the trip setting even after the timer had expired, the relay did not operate.
This instability was observed on all of the relays tested (during testing by this engineer, ENOI, and others in coordination with S&C at Vault 24 on March 1, 2013), including the subject
(Bay 8) relay and two identical (exemplar) relays. Behavior of the device in a manner contrary to the published functionality of the device constitutes a design defect.
Interesting read and glimpse into the world of SCADA / ICS. While the notion that the outage was due to hackers, the reality is far more mundane. We could certainly learn from this case, along with thousands of others… but who am I kidding. News covering the mundane and real doesn’t sell.
Recently, we got feedback via Twitter that we come across as “immature”. On the surface, perhaps. Not all of our Tweets are critical of CVE though. I replied pretty quickly that said criticism is also us “pushing for them to improve since so much of the industry relies on them.” When I Tweeted that, a post to the CVE Editorial Board wasn’t public on the web site, so I couldn’t quote it. But it was a great and timely example of one way our team is pushing CVE to improve.
That said, let me better explain our criticism. It isn’t the first time, it won’t be the last time, but I am not sure if some of these thoughts have been published via blog before. Put simply, we would not be so critical of CVE if it wasn’t a crumbling cornerstone of the Information Security industry. Countless organizations and products use CVE as a bible of public vulnerabilities. A majority of security technology, including firewalls, vulnerability scanners, IDS, IPS, and everything else is built on their database. Our industry assumes they are doing their job, doing their best, and cataloging public vulnerabilities. That simply is not the case, and it hasn’t been for more than a year. Everyone uses it as a benchmark, trusts it, and relies on it. Yet no one questions it except us. Last I checked, our profession was built on “trust but verify“. We verify, thus, we’re critical.
That said, we have a long history of sending corrections, feedback, and improvement ideas to all of the major VDBs including CVE, BID, Secunia, ISS, SecTracker, EDB, PacketStorm, and more. We currently have a great relationship with ISS and EDB. We have had a great-to-courteous relationship with CVE. SecTracker has been receptive of our feedback in the past, but given their minimal output we don’t try to provide cross-references to them anymore. PacketStorm is bad about approving our comments on their published disclosures. BID is and has been a lost cause for almost a decade. Further, we have decent relationships with US-CERT, IBM PSIRT, CERT (CM), and other companies teams. We give continued feedback to some of these organizations that are designed to help their process, help their disclosures, and thus help the industry. I mention this because for the most part, a majority of them are competitors to us. We have a commercial model, it is the only way to fund the database. Despite that, and a decade of disillusionment of the ‘open source’ model, we still give away a significant portion of our data. Until recently, our biggest competitor in licensing our data was ourselves, as potential customers would freely admit they could take our data from osvdb.org. Next to ourselves? CVE and NVD. It is astounding and scary how many companies will pass up on superior vulnerability intelligence because what they are using is free. In many cases, they tell their customers they provide the best intelligence, provide the most security, and a wide variety of other platitudes. In reality, they don’t want to spend a sliver of a fraction of their profits, to truly help their customers. It is a level of greed and unethical behavior that is absolutely disgusting. If I could expose them, I would, but they fall under dreaded NDAs.
Point is, we strive to push all of these organizations to be better. Jake and I gave a presentation back in 2005 at CanSecWest where we said that VDBs need to evolve. They still do. Ten years later, we’re still pushing them to do so while they resist with every ounce of their being. Fortunately, we have been pushing ourselves to be better during that time, and it shows. We’re no more critical of the other VDBs than we are of ourselves. It doesn’t help us one bit. In fact, it only serves to hurt us. Yet, it is the right thing to do for the industry, so we do it.
CVE, managed by MITRE, a ‘sole-source’ government contractor, who gets as much as one million dollars a year from the government (or more) to run the project, is a confusing entity. Researchers who have reached out to CVE for assignment or clarification on current assignments, have gone 10 days without answer (as of 2014-11-15 late night). Yet look at their actual assignments the past week:
X N 924 Nov 10 firstname.lastname@example.org (22K) [CVENEW] New CVE CANs: 2014/11/10 06:00 ; count=17
X N 931 Nov 11 email@example.com (25K) [CVENEW] New CVE CANs: 2014/11/11 17:00 ; count=32
X N 932 Nov 11 firstname.lastname@example.org (18K) [CVENEW] New CVE CANs: 2014/11/11 18:00 ; count=18
X N 938 Nov 12 email@example.com (7514) [CVENEW] New CVE CANs: 2014/11/12 11:00 ; count=5
X N 962 Nov 13 firstname.lastname@example.org (12K) [CVENEW] New CVE CANs: 2014/11/13 10:00 ; count=9
X N 986 Nov 13 email@example.com (7139) [CVENEW] New CVE CANs: 2014/11/13 19:00 ; count=4
X N 995 Nov 14 firstname.lastname@example.org (7191) [CVENEW] New CVE CANs: 2014/11/14 10:00 ; count=3
X N 1015 Nov 14 email@example.com (6076) [CVENEW] New CVE CANs: 2014/11/14 21:00 ; count=3
X N 1035 Nov 15 firstname.lastname@example.org (5859) [CVENEW] New CVE CANs: 2014/11/15 15:00 ; count=2
X N 1037 Nov 15 email@example.com (9615) [CVENEW] New CVE CANs: 2014/11/15 16:00 ; count=7
X N 1043 Nov 15 firstname.lastname@example.org (9034) [CVENEW] New CVE CANs: 2014/11/15 19:00 ; count=4
X N 1045 Nov 15 email@example.com (7539) [CVENEW] New CVE CANs: 2014/11/15 20:00 ; count=3
X N 1046 Nov 15 firstname.lastname@example.org (5885) [CVENEW] New CVE CANs: 2014/11/15 21:00 ; count=2
Impressive! Until you read between the lines. Mon, 17 entries. Tues, which is MS (32) / Adobe (18) release day, and those numbers are obvious… as it only covers those two vendors. Then 5 on Wed, 13 on Thurs, 6 on Friday… and then 21 on the weekend? Why is a government contractor, who has a long history of not working or answering mails on the weekend, doing what appears to be overtime on a weekend?
Meanwhile, the 10th we have 32 entries, 11th we have 100 entries, 12th we have 92 entries, 13th we have 56 entries, 14th we have 42 entries, and the 15th we have 11 entries. That is 109 entries this week from CVE, where 50 of them (almost half) were Microsoft and Adobe. Meanwhile, we have 337 entries over those same days. That doesn’t count our backfill for historical entries, from those ‘old days’ back in earlier 2014 or 2013, that we are constantly doing.
Tonight, when matching up the Nov 15 CVE entries, we had 100% of the CVE assignments already. Remind me, where is the value of CVE exactly? They are assigning these identifiers in advance, that is obvious. But for most disclosures they are simple and straight-forward. They aren’t being used to coordinate among multiple vendors. The researchers or vendors are including the CVE identifier *before* CVE actually publishes them.
What led me to this post is that CVE is actually working on a weekend, which is very odd. Unless you mail Steve directly you generally don’t hear back from CVE until later in the week. OSVDB / RBS has outstanding mail to both Steve and CVE regarding previous assignments and other things, un-answered for 10 or more days currently. The entire purpose of CVE is to provide this ID for coordination and clarity. When they ignore such a mail, especially from a ‘trusted’ source, it speaks poorly on them. Given the level of government funding they receive, how are they not keeping up with disclosures throughout the week and instead, turning to a Saturday?
And please remember, the Saturday CVE assignments mentioned above won’t appear on CVE’s site for another day, and won’t be in NVD for at least 24 hours. Once NVD gets them, they won’t have a CVSS score or CPE data for a bit after. By a ‘bit’ I mean between a few hours and a few weeks.
This is fail on top of fail. And your security solutions are built on top of this. Yeah, of course this is a losing battle.
After John Cartwright abruptly announced the closure of the Full Disclosure mail list, there was a lot of speculation as to why. I mailed John Cartwright the day after and asked some general questions. In so many words he indicated it was essentially the emotional wear and tear of running the list. While he did not name anyone specifically, the two biggest names being speculated were ‘NetDev’ due to years of being a headache, and the more recent thread started by Nicholas Lemonias. Through other channels, not via Cartwright, I obtained a copy of a legal threat made against at least one hosting provider for having copies of the mails he sent. This mail was no doubt sent to Cartwright among others. As such, I believe this is the “straw that broke the camels back” so to speak. A copy of that mail can be found at the bottom of this post and it should be a stark lesson that disclosure mail list admins are not only facing threats from vendors trying to stifle research, but now security researchers. This includes researchers who openly post to a list, have a full discussion about the issue, desperately attempt to defend their research, and then change their mind and want to erase it all from public record.
As I previously noted, relying on Twitter and Pastebin dumps are not a reliable alternative to a mail list. Others agree with me including Gordon Lyon, the maintainer of seclists.org and author of Nmap. He has launched a replacement Full Disclosure list to pick up the torch. Note that if you were previously subscribed, the list users were not transferred. You will need to subscribe to the new list if you want to continue participating. The new list will be lightly moderated by a small team of volunteers. The community owes great thanks to both John and now Gordon for their service in helping to ensure that researchers have an outlet to disclose. Remember, it is a mail list on the surface; behind the scenes, they deal with an incredible number of trolls, headache, and legal threats. Until you run a list or service like this, you won’t know how emotionally draining it is.
Note: The following mail was voluntarily shared with me and I was granted permission to publish it by a receiving party. It is entirely within my legal right to post this mail.
From: Nicholas Lemonias. (email@example.com)
Date: Tue, Mar 18, 2014 at 9:11 PM
Subject: Abuse from $ISP hosts
I am writing you to launch an official complaint relating to Data
Protection Directives / and Data Protection Act (UK).
Therefore my request relates to the retention of personal and confidential
information by websites hosted by Secunia.
These same information are also shared by UK local and governmental
authorities and financial institutions, and thus there are growing
concerns of misuse of such information.
Consequently we would like to request that you please delete ALL records
containing our personal information (names, emails, etc..) in whole, from
your hosted websites (seclists.org) and that distribution of our
information is ceased . We have mistakenly posted to the site, and however
reserve the creation rights to that thread, and also reserve the right to
have all personal information deleted, and ceased from any electronic
dissemination, use either partially or in full.
I hope that the issue is resolved urgently without the involvement of local
I look forward to hearing from you soon.
Thanks in advance,
Update 7:30P EST: Andrew Wallace (aka NetDev) has released a brief statement regarding Full Disclosure. Further, Nicholas Lemonias has threatened me in various ways in a set of emails, all public now.
A week ago, I read an interesting blog post by Jeremiah Grossman of WhiteHat Security titled: “201x: The Year of the Security Industry Breach”, which discussed that security software may be the next big target for attackers to focus on
Some great points are presented and I especially appreciate how the fact is hammered in that attackers shift focus whenever required, but as Jericho pointed out when we discussed it, “The security industry does not.” I find, however, that the blog post lacking a couple of key points, which caused me to write this follow-up (not a rebuttal – Jericho handles those).
I agree that we have for decades been offered the same solution to all our security problems: Buy more/newer/subscription security software to deal with the threats. It is also certainly installed in abundance.
Security software does present problems however, and these concerns are not new. Researchers have voiced concerns for years over security software like firewalls and especially anti-virus (AV), pointing out that businesses are adding more (potentially flawed) code to protect themselves. It’s a common rule of thumb that the more lines of code, the more vulnerabilities. Reducing attack surface by adding an even greater attack surface is a paradox.
While security software in general presents an interesting target, it does, however, not necessarily mean that we will see it receiving the same heavy abuse as Java, Internet Explorer, and Flash, which are currently getting hammered by the bad guys.
When the bad guys were exploiting vulnerabilities in Adobe Reader, they were not targeting PDF viewers overall; they did not really care about e.g. Foxit Reader, PDF-XChange, nor Sumatra PDF. When Microsoft Office was hot, other office suites like OpenOffice and Corel Office did not feel the burn. And when 0-days are being dropped in Internet Explorer, browsers like Firefox, Opera, and Chrome can relax (relatively speaking) on the side.
These other products are not necessarily going free or only receiving limited attention because they are safer – they may just not have a user base that results in a profitable ROI.
If history is permitted to serve as a pointer, the bad guys do not target a whole class of products, but generally specific products with an extremely high user base allowing widespread attacks. It would, therefore, be more likely to see attacks focusing on products from a specific security vendor. That would, however, require a strong position with the vendor’s products being installed on a very large scale and while security software is prevalent, no single vendor dominates the market – especially not with a single product.
Another option would be if the security products start using the same codebase e.g. for file parsing or other common routines. Should security software e.g. use the same third-party parsing functionality, these parsers would certainly become of greater interest.
It should also be noted that while security software has not been targeted by the bad guys in the same manner as the previously mentioned products (and currently for good reason), it has still received a fair amount of attention over the years from researchers (myself included).
Looking at the OSVDB vulnerability database, it has at the time of writing 1,919 entries covering vulnerabilities in security software – in fact almost 2% of all our entries (yes, we have a specific classification flag, making it very easy to get a historical overview). These span from 2013 all the way back to 1995, when security software started gaining a foothold. I specifically remember when Alex Wheeler in 2005 was doing some serious work on the archive parsing functionality of many security software vendors’ AV solutions.
For the past 5-6 years, Symantec has also had their worries because they decided to implement very flawed parsers from HP/Autonomy/Verity Keyview in some of their security solutions, including their Mail Security and Data Loss Prevention products. Or Microsoft who on a related note made the questionable decision of implementing Oracle Outside In parsers in Microsoft Exchange Server 2007 and 2010. A vendor with a history of vulnerabilities, that they have worked very hard to overcome, deciding to implement a more notoriously insecure vendor’s software is certainly interesting.
Does this mean we won’t see any focus on security software in the future? Certainly not. Security software exposes a broad and tantalizing attack surface and is not necessarily built to impress (as Tavis Ormandy recently demonstrated for Sophos’ security solutions). It is an interesting target class of products that will continue to receive attention – and perhaps even an increasing focus once Oracle eventually sorts out Java, though that may take a while.
When the going gets tough, attackers just change to a different target with a better ROI, and it cannot be ruled out that the target ends up being the code actually intended to protect you.
So remember that 201x is already here and that while the bad guys may not go all-in against security solutions, vulnerabilities in these have been found consistently for many years. Consider what security software you really need – and certainly which features you need enabled.
Today, we pushed OSVDB 82447 which covers a backdoor in the Multics Operating System. For those not familiar with this old OS, there is an entire domain covering the fascinating history behind the development of Multics. OSVDB 82447 is titled “Multics Unspecified Third-party Backdoor” and gives an interesting insight into backdoors distributed by vendors. In this case, a third-party planted it, told the vendor, and Honeywell still distributed the operating system anyway. I encourage you to read the full paper by Lieutenant Colonel Roger R. Schell, a member of the tiger team that carried out the attack.
During a US Air Force sanctioned penetration test of mainframe computers, sometime before 1979, the tiger team ended up penetrating a Multics installation at Honeywell. In an account of what happened later, a paper said that the tiger team “modified the manufacturer’s master copy of the Multics operating system itself” and injected a backdoor. The backdoor code was described as being small, “fewer than 10 instructions out of 100,000” and required a password for use. The report continues, saying that even though Honeywell was told it was there and how it worked, their technicians could not find it. Subsequently, the backdoor was distributed in future installations of Multics.
It would be interesting to know why Honeywell didn’t ask for, or didn’t receive, the specific modified code from the Air Force tiger team, and why they opted to distribute it to customers. Perhaps they thought if their own technicians couldn’t find the backdoor, no one else could. Even more interesting is why a tiger team was sanctioned to carry out a penetration test that not only gave them access to the “master copy” of Multics, but why they were allowed to actually place the backdoor there. When they heard Honeywell couldn’t find it, why didn’t they insist on ensuring it was removed before installation at customer locations? This brings a new twist to the ethics of penetration testing, at least in a historical context.
The Open Security Foundation, providing independent, accurate, detailed, current, and unbiased security information to professionals around the world, announced today that it has launched Cloutage (cloutage.org) that will bring enhanced visibility and transparency to Cloud security. The name Cloutage comes from a play on two words, Cloud and Outage, that combine to describe what the new website offers: a destination for organizations to learn about cloud security issues as well as a complete list of any problems around the globe among cloud service providers.
The new website is aimed at empowering organizations by providing cloud security knowledge and resources so that they may properly assess information security risks related to the cloud. Cloutage documents known and reported incidents with cloud services while also providing a one-stop shop for cloud security news and resources.
“When speaking with individuals about the cloud, to this point it has been a very emotional conversation. People either love or hate the cloud,” says Jake Kouns, Chairman, Open Security Foundation. “Our goal with Cloutage is to bring grounded data and facts to the conversation so we can have more meaningful discussions about the risks and how to improve cloud security controls.”
Cloutage captures data about incidents affecting cloud services in several forms including vulnerabilities that affect the confidentiality and integrity of customer data, automatic update failures, data loss, hacks and outages that impact service availability. Data is acquired from verifiable media resources and is also open for community participation based on anonymous user submissions. Cloud solution providers are listed on the website and the community can provide comments and ratings based on their experiences. Cloutage also features an extensive news service, mailing lists and links to organizations focused on the secure advancement of cloud computing.
“The nebulous world of cloud computing and the security concerns associated with it confuses many people, even IT and security professionals,” says Patrick McDonald, a volunteer on the Cloutage project. “We want a clearinghouse of information that provides a clear picture of the cloud security issues.”
Sometimes when I read our past blog posts it seems like OSVDB moderators are a broken record. We seem to always say that we had these ideas a long time ago…. We seem to frequently say that VDBs need to evolve……. We say that we would love to do something about it but need resources…….. Times are changing for OSVDB. As you have seen over the past couple weeks, we are extremely thankful for our lead developer Dave as he is making a lot of these ideas happen!
OSVDB has publicly stated several times (e.g., SyScan04 , CanSecWest 2005 and OSBR) that we felt it was important to achieve active integration with security tools to streamline the process of identifying and setting priorities for the creation of vulnerability checks. Our goal is for OSVDB to assist tool developers to identify vulnerability checks or signatures that are not already represented in their products, and will provide a way to identify the high-priority vulnerabilities for immediate attention.
Today we took our first huge step forward to make this happen thanks to yet another improvement in our search engine. A couple days ago I was discussing this idea again with Jericho and the possibility of trying to finally bring it to life. To make it really happen we agreed we would need the search engine to function in a way it hasn’t yet done…. it would need to search for things that are NOT in OSVDB, and need to search based on CVSS scoring / criteria. After spending some time chatting with Jericho he said…… it may be complicated to implement. Well, he definitely underestimated Dave’s ninja development skills as this was knocked out in several hours over two days!
What is the big deal about this feature anyways?
What if for example….
- …you were wondering which vulnerability scanner / IDS / IPS has the best coverage?
- …you were trying to figure out which check you should write for your favorite scanner / IDS / IPS?
- …you were trying to figure out what are the most important vulnerabilities missing from a scanner?
OSVDB can now show you a listing of all vulnerabilities with certain characteritics that are missing a reference as well. Even more powerful, the ability to search by CVSSv2 score or specific attribute.
For example, we can have OSVDB show a listing of all vulnerabilties that have the following:
- CVSS score between 9 to 10
- are for Microsoft
- can be exploited from remote/network
- and do NOT have a Metasploit reference
Check out the results from OSVDB for the example above.
This search shows that there are 175 entries in OSVDB that Metasploit is missing a check for, that have a high impact. Perhaps this list would be useful to HD and the folks over at Metasploit to determine which exploits need to be included next. As you can see there is a lot more you can do with it. Check out the OSVDB Advanced Search and play with it a bit!
As mentioned this is just the first step and is what we believe will be the basis for much more to come. OSVDB is positioned to be the central source to help review and determine the completeness of commercial security solutions. We believe that OSVDB has an extremely high coverage of all disclosed vulnerabilities and will be able to provide insight into what vulnerabilities are covered (or missing) from a given scanner or tool. We will be able to show the gaps and even provide guidance to users as to which scanner or tool would be best for their organization. Instead of listening to a sales pitch that says “trust us we cover the most vulnerabilities!”, OSVDB will have real data to show that Product X has more coverage than Product Y. We will be in a position to allow a security practitioner to ensure that the products that are critical to their organization are covered in the scanner they are potentially purchasing. As shown above, we can show which vulnerabilities do not have checks (Metasploit, Nessus, Snort, etc) for critical vulnerabilities.
You know… when we find some time it would be a great idea for OSVDB to conduct a bake off on coverage between the top vulnerability scanners and IDS/IPS products. This of course relies on having vendors that are open and share their vulnerability mappings in a format that can be imported into OSVDB. So far, Nikto, Metasploit and Tenable’s Nessus have provided us with these mappings. Another upcoming feature will be a system that allows these vendors to automatically upload updated mappings to keep OSVDB current. Three vendors down, who will be the next to step up?
OSVDB is featured in the June issue of the Open Source Business Resource (OSBR) and is now available at the OSBR website. We were contacted and asked if we would like to include our original OSVDB Aims white paper in the issue. This was really the prompting that we needed to take the time to update the project’s successes since the launch and provide some additional information about the future of OSVDB.
We would like to thank Dru Lavigne and OSBR for their support and encourage you to take a look at the issue. The OSVDB article can be found at: http://www.osbr.ca/ojs/index.php/osbr/article/view/607/568
OSBR’s editorial theme for June is “Security” and here is a listing from the table of contents:
Jake Kouns, president of the Open Security Foundation, introduces the Open Source Vulnerability Database Project. David Maxwell, Open Source Strategist at Coverity, discusses the findings from Coverity’s analysis of over 55 million lines of open source code. Robert Charpentier from Defence Research Establishment Valcartier and Mourad Debbabi, Azzam Mourad and Marc-André Laverdière from Concordia University present a summary of their research into providing security hardening for the C programming language. Frederic Michaud and Frederic Painchaud from Defence Research and Development Canada describe their evaluation of automated tools that search for security bugs. Key messages from Carleton University’s Stoyan Tanev’s recent presentation on technology marketing trends and the Eclipse Foundation’s Ian Skerrett’s presentation on building successful communities. Michael Geist, Canada’s Research Chair of Internet and E-commerce Law, explains why the proposed Bill C-61 does not address the rights of Canadians. Alan Morewood from Bell Canada provides an example of open source meeting a business need.
Next months editorial theme is “Accessibility” – contact the OSBR Editor if you are interested in a submission.