Perhaps it is the fine tequila this evening, but I really don’t get how our industry can latch on to the recent ‘Aurora’ incident and try to take Microsoft to task about it. The amount of news on this has been overwhelming, and I will try to very roughly summarize:
- News surfaces Google, Adobe and 30+ companies hit by “0-day” attack
- Google uses this for political overtones
- Originally thought to be Adobe 0-day, revealed it was MSIE 0-day
- Jan 14, confirmed it is MSIE vuln, shortly after dubbed “aurora”
- Jan 21, uproar over MS knowing about the vuln since Sept
Now, here is where we get to the whole forest, trees and some analogy about eyesight. Oh, I’ll warn (and surprise) you in advance, I am giving Microsoft the benefit of the doubt here (well, for half the blog post) and throwing this back at journalists and the security community instead. Let’s look at this from a different angle.
The big issue that is newsworthy is that Microsoft knew of this vulnerability in September, and didn’t issue a patch until late January. What is not clear, is if Microsoft knew it was being exploited. The wording of the Wired article doesn’t make it clear: “aware months ago of a critical security vulnerability well before hackers exploited it to breach Google, Adobe and other large U.S. companies” and “Microsoft confirmed it learned of the so-called ‘zero-day’ flaw months ago”. Errr, nice wording. Microsoft was aware of the vulnerability (technically), before hackers exploited it, but doesn’t specifically say if they KNEW hackers were exploiting it. Microsoft learned of the “0-day” months ago? No, bad bad bad. This is taking an over-abused term and making it even worse. If a vulnerability is found and reported to the vendor before it is exploited, is it still 0-day (tree, forest, no one there to hear it falling)?
Short of Microsoft admitting they knew it was being exploited, we can only speculate. So, for fun, let’s give them a pass on that one and assume it was like any other privately disclosed bug. They were working it like any other issue, fixing, patching, regression testing, etc. Good Microsoft!
Bad Microsoft! But, before you jump on the bandwagon, bad journalists! Bad security community!
Why do you care they sat on this one vulnerability for six months? Why is that such a big deal? Am I the only one who missed the articles pointing out that they actually sat on five code execution bugs for longer? Where was the outpour of blogs or news articles mentioning that “aurora” was one of six vulnerabilities reported to them during or before September, all in MSIE, all that allowed remote code execution (tree, forest, not seeing one for the other)?
|CVE||Reported to MS||Disclosed||Time to Patch|
|CVE-2010-0244||2009-07-14||2010-01-21||6 Months, 7 Days (191 days)|
|CVE-2010-0245||2009-07-14||2010-01-21||6 Months, 7 Days (191 days)|
|CVE-2010-0246||2009-07-16||2010-01-21||6 Months, 5 Days (189 days)|
|CVE-2010-0248||2009-08-14||2010-01-21||5 Months, 7 days (160 days)|
|CVE-2010-0247||2009-09-03||2010-01-21||4 Months, 18 days (140 days)|
|CVE-2010-0249||2009-09-??||2010-01-14||4 Months, 11 days (133 days) – approx|
|CVE-2010-0027||2009-11-15||2010-01-21||2 Months, 6 days (67 days)|
|CVE-2009-4074||2009-11-20||2009-11-21||2 Months, 1 day (62 days)|
Remind me again, why the “Aurora” conspiracy is noteworthy? If Microsoft knew of six remote code execution bugs, all from the September time-frame, why is one any more severe than the other? Is it because one was used to compromise hosts, detected and published in an extremely abnormal fashion? Are we actually trying to hold Microsoft accountable on that single vulnerability when the five others just happened not to be used to compromise Google, Adobe and others?
Going back to the Wired article, they say on the second to last paragraph: “On Thursday, meanwhile, Microsoft released a cumulative security update for Internet Explorer that fixes the flaw, as well as seven other security vulnerabilities that would allow an attacker to remotely execute code on a victim’s computer.” Really, Wired? That late in the article, you gloss over “seven other vulnerabilities” that would allow remote code execution? And worse, you don’t point out that Microsoft was informed of five of them BEFORE AURORA?
Seriously, I am the first one to hold Microsoft over the flames for bad practices, but that goes beyond my boundaries. If you are going to take them to task over all this, at least do it right. SIX CODE EXECUTION VULNERABILITIES that they KNEW ABOUT FOR SIX MONTHS. Beating them up over just one is amateur hour in this curmudgeonly world.
Reported Phishing/Vulnerable Site! The web site http://www.google.com has been reported as a vulnerable site that may pose a threat to your web browsing. Vulnerable sites do not prioritize security and don’t care about their users and customers. These sites may pose a risk to you, exploit the trust between you and their site and may cause your computer to perform actions you did not approve.
To carry on the scary wording in the style of others; Some web sites are high profile and may seem trustworthy, but you shouldn’t trust them at all. They are full of buggy code, don’t care about protecting their users (that’s you!) and generally suck. Despite using their site as a virtual crutch, you should clearly stay away from them unless it is to send nasty mails or mock them. Again, do not trust Google’s web sites or search engine, because they have been known to be vulnerable. What assholes!
On a more serious note, if anyone at Google is reading this, I hope you pass this on to the jackasses that develop Google Toolbar or whatever hook they use to integrate with Firefox. Not only is it worse than malware (every piece of software tries to get me to install it), it uses misleading wording to scare customers from visiting perfectly safe and innocent web sites (namely this blog). While it caters to morons, it doesn’t give users a real opportunity to learn why a site was ‘blocked’ other than vague wording.
My only guess as to why this warning occurs was an incident earlier this year, in which the OSVDB blog fell victim to a zero-day exploit in WordPress. I blogged about the incident to make our readers aware of the incident and clear up any confusion. I assume that Google’s crawl of the this blog noted the script code and subsequently declared us an “attack site”, even though that is hardly the case.
The discouraging part is the “diagnostic page” says that Google visited ONE page in the last 90 days and 0 of those pages resulted in malicious software being downloaded. Google, if you are going to play Lord of the Browser, visit more than one page before you make that determination. To do anything less is a disservice to your users and a fast way to miss obvious malware. The third question mentions “intermediary” which is technically accurate as far as the script code that was injected in a few blog posts. However, the big red warning says nothing about ‘intermediary’ and explicitly labels us as some kind of malware hosting site with the intent of attacking people. That is libelous to say the least. Under ‘How did this happen’, Google mentions that sometimes third parties can inject such code, but doesn’t take the time to help clear this up. If the previous script injection issue is the cause of this, the fact that the script loaded content from a third party domain (in China no less) should be a good indication that WE did not host the malware. Sure, most users are dumb as a rock, but the few smart cookies that click for details should get just that.. details.
What Google Toolbar users may see when visiting this blog:
Finally, I opened the blog post calling Google’s search engine a threat, and I was serious. Google has a track record of vulnerabilities far worse than OSVDB does. Not only in their popular search engine, but their various products too. Besides, the mechanism for reporting potentially dangerous sites is a bit dubious to say the least.
Update: Ends up, we had another iframe injection into one of our posts (which is now removed), and the hunt for how this is happening now begins. That said, while Google’s warning that this site is “dangerous” may have been accurate, their mechanism for warning users in a vague manner (as shown in the image linked off ‘vague warning’) and not warning the site administrator is far from friendly. I can see that Google doesn’t care about warning sites of issues before warning the public, a far cry from ‘responsible disclosure’, something that Google pretends to care about:
This process of notifying a vendor before publicly releasing information is an industry-standard best practice known as responsible disclosure. Responsible disclosure is important to the ecology of the Internet. It allows companies like Google to keep users safe by fixing vulnerabilities and resolving security concerns before they are brought to the attention of the bad guys. We strongly encourage anyone who is interested in researching and reporting security issues to observe the simple courtesies and protocols of responsible disclosure.
Next time OSVDB is informed of a vulnerability that impacts Google products or services, I sure hope it doesn’t slip our mind to contact them. Perhaps the apparent race condition between the vague wording and the not-so-vague wording that users may see constitutes a bug. If they can read this blog, they can see the bug in action and then contact us if they have more questions.
Update 2: Google apparently tried to send mail to our domain: From: Google Search Quality
We are pleased to report that OSVDB has been provided three projects for 2008. We would like to thank everyone that applied and encourage students that were not selected to still consider getting involved with the project. We had quite a few great applications but were unable to accept any more due to our limited mentoring resources this summer and the large number of new organizations taking part in SoC this year.
Here are the projects that were selected:
Patch Management Portal by Ronny Yabar Aizcorbe, mentored by David Shettler The system will provide a way to define when a patch should be in development, testing or production status. And will allow users the ability to select vulnerabilities and patches based on the OSVDB watch list. The main components of the tool will be: Prioritization and scheduling, Testing, Implementation and Compliance.
OSVDB Widgets and Gadgets by Marc Augustin, mentored by Chris Newby This project is intended to utilize the OSVDB as the main data source but should be a security dashboard for professionals via Gadgets and Widgets.
OSVDB Training Portal Framework by Sergios Pericleous, mentored by Jake Kouns This project will create a training framework which will aim to integrate as much as possible with the existing OSVDB portal. The portal will allow specific admin users to create training material and quizzes for end-users, and it will also allow end-users to read this training material and make comments on it, take the quizzes and receive a score, and to track their progress using a progress report and graphs.
Congrats Ronny, Marc and Sergios and we look forward to another successful summer!
OSVDB has been accepted for Google’s Summer of Code for 2008. Please help spread the word and encourage all eligible students to apply for an OSVDB project! Google will begin accepting student applications on Monday, March 24, 2008!
If you have any questions or would like some more details about our project ideas please get in touch with us!
Google Summer of Code 2008 is officially on. Full details at http://code.google.com/soc/2008/
OSVDB has submitted an application and has been accepted. With our Summer of Code project work, we hope to build off the release of OSVDB 2.0 and develop new enhancements to OSVDB’s public services. Here is this years list of ideas/important projects, however we are open to proposals for other projects and ideas.
OSVDB Port Listing Project – Preferred language is Ruby on Rails We are looking to create a project that will be a central repository for all known ports and protocols. This will be the foundation of many new features such as referencing ports/protocols to OSVDB IDs. This will then allow OSVDB vulnerabilities to be better mapped to firewall rules, IDS alerts and potential integrations to other security projects such as NMAP. -This project should detail all well known/default/registered ports -This project must have a automated feature that can import port information from iana.org as a baseline (PORT NUMBERS) -This project must allow users to submit updates/edits wiki style -This project needs to include fields for necessary tracking including: Keywords, Number, Transport (TCP, UDP, ICMP, etc), Application, Links, Description
OSVDB Training Portal Framework – Preferred language is Ruby on Rails This project is to create a flexible framework that can provide training on security issues. OSVDB is looking to not only provide information on vulnerabilities but be a repository for training information that will help educate end users on how to avoid security risks and developers on how to avoid coding insecure applications. -This project must be able to integrate with the existing OSVDB portal -This project must have an interface that allows users to create their own training material -This project must have an interface that allows users to create their own training quizzes -This project must have an interface to provide reports and track the results.
-A user needs to be able to creates a custom quiz or select from a list of OSVDB published quizzes. -A user needs to be able to send a quiz to multiple people by inputting email addresses. -The system will track the quiz and results based on the emails that are sent via the training portal. -This project should allow users to provide comments and coaching information in a wiki style to help educate -The project will ultimately cross reference OSVDB IDs: For example: when a user is viewing a specific vulnerability it will allow them to then take a training course and a quiz to test their knowledge
OSVDB Personal Edition Phase II – Preferred language is Ruby on Rails We released the OSVDB Personal Edition and it 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. This project is intended to take the OSVDB Personal Edition to the next level. -This project will provide improvements and a seamless installation package -This project will include new search features -This project will include new features defined by you!
OSVDB Widgets and Gadgets – Preferred language is open for discussion! OSVDB has a very strong online feature set but a user needs to be logged in to use the services. This project is intended to utilize the OSVDB as the main data source but should be a security dashboard for professionals.
-Gadgets and Widgets should work for OSX and/or Vista -Should provide security news updates from multiple sources -Should provide alerts when new alerts from vendors are released -Should provide alerts for new vulnerabilities added to the OSVDB database -Should provide search capabilities for OSVDB -Must be able to support OSVDB API functionality
OSVDB Statistics Project – Preferred language is Ruby on Rails This project is to create a flexible framework that can provide useful statistics on vulnerabilities from OSVDB. This project should take in consideration all of the fields and classifications in OSVDB. -Should create and generate standard/most popular graphs and charts each day and make available -Should create statistics that allows very flexible/detailed stats to be dynamically generated on demand by user -Some examples of statistics required: -# Vulns based on Disclosure Year -Detailed stats based on each vuln classification options (ALL OPTIONS) -# of vulns by Vendor -# of vulns by Product -# of vulns that do not have a solution (and by vendor) -Time from when a vuln was discovered and then disclosed -Create stats application that allows user to dynamically generate stats based on their own requirements. -Trend the number of vulns released per day
OSVDB Vulnerability Visual Mapping – Preferred language is open for discussion! This project is to create a visual mapping of all vulnerabilities in OSVDB. This will allow users to visually search the database and also to see the relationships between vulnerabilities. Have you ever seen music plasma? This could be pretty challenging but we have been wanting to see this project done for a long time!
Vulnerability and Patch Management Portal – Preferred language is Ruby on Rails This project is to create a flexible framework that can provide organizations the ability to track and manage vulnerabilities and patches. OSVDB is looking to not only provide information on vulnerabilities but be a service that can provide security professionals a way to track and ensure that vulnerabilities have been addressed at their organization. -This project must be able to integrate with the existing OSVDB portal -Should allows users to manage life cycle of vulns and patches -Should allow user the ability selects vulnerabilities or patches based on OSVDB watchlist -Should create a lifecycle that will alert a user when a new vulnerabilities or patch is released and goes into the portal -User then can track their organizations progress including: Research, Test, Implementation, Closure -The project should allows an organization to show compliance with vulnerabilities and patches
Vulnerability Cross References and Scraper – Preferred language is Ruby on Rails and open for discussion! OSVDB is a project that aims to have as many references to vulnerabilities as possible. Unfortunately, in most cases volunteers have to search by hand to find more information to add to an entry. The goal of this project to to create a module that can search multiple security resources and cross references OSVDB entries to other resources. -Cross reference OSVDB IDs and provide references that are missing -Search the following (all external references OSVDB uses) for a string: Bugtraq, Bugtraq Mailing List, CVE, Full-Disclosure Mailing List, ISS X-Force, Nessus, OSVDB, Packetstorm, Secunia, Securiteam, Security Tracker, Snort -Search the resources based on user supplied check boxes for refined/targeted searches -Offer simple search, pull back just a summary of findings -Offer recursive search for some sites. If the entry at another site (for example CVE) is known then it should be an option to pull back all of the other references in that entry as well -Should be a framework that allows new security sites to be added when they become available -Should run once a night and look at all entries (even old ones) to see if there are more references that can be added.
-There should be some kind of approval process or a quick way that we can automatically add the references to the appropriate IDs.
New security project? New security scanner? New OSVDB feature? – Preferred language is open for discussion! -Have an idea for a new security scanning tool? -Have an idea for a new features that is missing from OSVDB? -Have an idea that can use information from our web sacnning database? -Have an idea for a security scanner that searches local server for vulnerable scripts?
OPEN SOURCE VULNERABILITY DATABASE (OSVDB) 2.0
RICHMOND, VA, December 15, 2007 – OSVDB announced a major milestone in the cataloging, classification, description and management of software and hardware security vulnerabilities: The release of OSVDB 2.0, a complete rewrite of the web site using Ruby on Rails, provides substantial performance and reliability improvements for both developers and researchers. “OSVDB 2.0 will help evolve stagnant Vulnerability Databases and position OSVDB as the go-to security vulnerability database,” says Brian Martin, one of the project leaders.
OSVDB, a recognized leader in providing services to the security industry for the past five years, has cataloged nearly 40,000 vulnerabilities, with the help of over 300 volunteers, while gaining industry recognition and vendor support.
“The new Ruby on Rails MVC framework will allow for quick and efficient deployment of changes,” says Dave Shettler, Lead Developer of the OSVDB project. “This will provide greater flexibility to adapt to the changes in the vulnerability and security industry.”
Eighteen months ago OSVDB project leaders identified the need to provide more services, an easier interface for updating vulnerabilities and a way to make it simple for individuals and companies to integrate with the project. OSVDB 2.0 achieves these objectives.
OSVDB 2.0 enhancements include: greater detail about the overall nature of a specific vulnerability, a “Watch List” service that provides alerts for new vulnerabilities, consolidating external blogs by vulnerability, and new reporting metrics. The enhanced data will allow users to find vulnerabilities based on criteria such as attack type, solution status or if the vulnerability has been confirmed or disputed by the vendor. “We know that OSVDB 2.0’s new features will prove to be useful for the security community.” says Kelly Todd, one of the project leaders. “OSVDB is a team effort for improved security by the security community.”
Users of the old system will immediately notice that the project has implemented a customizable portal that fully integrates the old backend interface and the front end website. In addition, the method for updating vulnerabilities has been changed to a “Wiki style” system that allows contributors to edit individual fields when needed.
The enhanced classification system is now tracking the following additional fields: •Context Dependent •“Wormified” •Vulnerability Dependent •Security Software •Coordinated Disclosure •Uncoordinated Disclosure •Vendor Disputed •Vendor Verified •Solution Types •Wireless
The OSVDB project leaders–Jake Kouns, Brian Martin, Dave Shettler, Chris Sullo, Kelly Todd , and Steve Tornio– would like to thank all of the volunteers and organizations who help make the project a success. The full list of contributors to the project can be viewed at: http://osvdb.org/contributors
We would also like to thank our sponsors: •Google (google.com), for sponsoring OSVDB in the Google Summer of Code program in 2006 and 2007. •Layered Technologies (layeredtech.com), for web hosting. •GFI (gfi.com), for financial support.
“The OSVDB project will go as far as the community is willing to take it.”, says Jake Kouns, project lead. “We continue to encourage individuals to get involved and help shape the future of the project.”
If you would like to become involved with the project please contact us at email@example.com
OSVDB 2.0 can be found at www.OSVDB.org.
Jake Kouns Open Source Vulnerability Database Project +1.804.306.8412
For the second year now, OSVDB has been selected to participate in the Google Summer of Code program. It’s pretty neat to be in this program along with other relatively unheard of projects like Debian, FreeBSD, GNU, KDE, NetBSD, OpenSolaris, PHP, PostgreSQL, Python, Samba, Apache, EFF, Fedora and X.org. =)
As always, Google continues to give back to the community in ways most companies will never understand or appreciate.
Fall behind and someone will always beat you to the punch! Gadi Evron posted an entry over at Securiteam on the topic of using Google’s Codesearch to find vulns. Since he and others are writing about this, I don’t have to! However, i’ll post a few more thoughts before anyone else maybe!
First, we have this great ability to (ab)use Google’s Codesearch to find vulnerabilities through fast code analysis. Is this a fun but very short fad? Or will we see people use this to disclose vulnerabilities and give credit to their method? Will it lead to a lot of false positives> like we’re seeing with remote file inclusion? Several ‘researchers’ are grep’ing for a single stringle, finding it, and posting it as a remote file inclusion vulnerability without really analyzing the code or testing their own “proof of concept”. Hopefully, researchers will use this new tool to not only find vulnerabilities, but truly validate their finding before disclosing.
Second, who is going to be the first to create an interface that smoothly links the Google Codesearch with a robust static code analyzer? Imagine a web interface where you choose a few key things like what language, what types of vulnerabilities, and click click for all the results. The program would then use the Codesearch results to pipe into the code analyzer and spit out a list of high probability vulnerabilities.
Some of these ideas courtesy of email discussions with Chris Wysopal, Mudge and others.
We are very pleased to report that OSVDB was selected for Google’s Summer of Code! This is great news as we hope to get some of the services and projects that have been on the back burner due to lack of development resources finally launched!
You can read about Google’s SoC here: http://code.google.com/soc/
With our Summer of Code project work, we hope to make several exciting enhancements to OSVDB’s public services. We have provided a list of important projects we are currently planning for–however we are open to proposals for other projects and ideas.
You can read about OSVDB’s Project Ideas here: http://www.osvdb.org/summerofcode.php
OSVDB has been working very hard to provide many additional types of a services to the community. Unfortunately, as mentioned due to lack of development resources we have been unable to make much of this happen. We now have an opportunity to possibly deliver on the OVSDB Portal and OSVDB Ethical Disclosure Framework commitments that we made when the project first opened.
You can read the public announcements with our intentions to provide OSVDB portal and disclosure services:
OSVDB Objectives: http://www.osvdb.org/OSVDB-Objectives.php
Vendor Dictionary Announcement: http://www.osvdb.org/news.php#vendorDictSiteUpgrade
Personally, I am absolutely thrilled that we may have the resources to develop the OSVDB Ethical Disclosure Framework. This has been one of the projects that I have been wanting for years and is validated as we see more and more issues with the disclosure process! I have believed all along that OSVDB can be the service that helps to improve, streamline and more importantly removes the mystery of the breakdowns in the process.
OSVDB has been handling one-off disclosures for researchers over the past 3-4 years and it is not an easy task. The amount of time it takes to handle a disclosure process is huge. We realized early on that a lot of the process needed to be automated in order to be successful and repeatable. Hopefully, there are some students out there that want to be apart of creating this service and we can get it launched by the end of the year!
We plan to post updates to the OSVDB blog as we get further in the process. If you have other ideas for projects that we should post please feel free to contact us at firstname.lastname@example.org
The argument that Vulnerability Databases (VDBs) are evil because they provide the bad guys all of the information on how to hack has gone on for quite some time. Of course, this debate crosses over into the Full Disclosure argument, which asks the question, should the information be public at all? But for VDBs, the real question should not be about whether to provide information on vulnerabilities, but how specific the information cataloged should be?
Some believe that providing exploits or tools to make it easier to exploit a vulnerability is where it crosses the line on providing too much information. While there may be a few valid points on the topic, the real issue, in my opinion, is when resources provide vulnerability information in the context of a specific site/domain.
VDBs are not the only resource that may have site specific vulnerability information. Many search engines such as Google/Yahoo have come under fire as being a collection of security information to assist attackers. In fact, it could be argued that the search engines pose greater security disclosure problems than a VDB, since a search engine takes an attacker immediately to a vulnerable website. There is even a whole site (and following) centered around using Google to quickly find specific vulnerable software on web sites.
OSVDB has a policy that we do not catalog site specific vulnerabilities, and we make all efforts possible to avoid these entries being added to the database. In fact, quite a few VDBs follow this same practice. However, some VDBs will include sites specific vulnerabilities only for high profile websites. For example:
XSS vulnerabilities in Google.com: http://www.watchfire.com/securityzone/advisories/12-21-05.aspx
Google GMail ‘CheckAvailability’ Script May Disclose User Information to Remote Users: http://www.securitytracker.com/alerts/2004/Jul/1010647.html
Yahoo! Mail ‘order’ and ‘sort’ Field Input Validation Flaw Permits Cross-Site Scripting Attacks: http://www.securitytracker.com/alerts/2004/Mar/1009352.html
It is important to note that certain advisories make it very hard to determine if the issue is in a product or on a website. Recently, we have seen what appears to be more site specific issues being released by researchers. For example:
SpearTek Search Field Handling Cross Site Scripting Vulnerability: http://www.frsirt.com/english/advisories/2005/3052
There appears to be quite a few advisories released by r0t that may fall into the site specific category. If you look on r0t’s site, anything that says there is a XSS vulnerabillity in the “Search Module” may very well be a vulnerability in the company website, not in the product–even though he lists version numbers in the advisory.
Considering VDBs such as OSVDB do not have the resources to verify all advisories, we must rely on the information provided, and in some cases site specific vulnerabilities make it into VDBs by accident. In fact, dozens of entries in OSVDB currently have internal flags on them as we try to determine if they are site specific.
Providing a company website or an online service that has a security issue is not something that OSVDB believes to be appropriate, even though many contributors personally find it extremely interesting, and believe it is valuable. Many organizations that rely on online services may find great value in knowing about an issue with their online email provider. The fact that many businesses use sites like Google, Gmail, or Yahoo heavily suggests that vulnerabilities in the services are just as dangerous as vulnerabilities in the software deployed on their own network.
It may make OSVDB look incomplete compared to VDBs that include site specific vulnerabilities, but we are willing to accept that risk. The OSVDB project aims to provide useful information to help improve the level of security for the community, and site specific vulnerability do not fall in that category currently.