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!
Early in 2006, I posted about HP using multiple identifiers for the same vulnerability. Recently, Sun Microsystems has done a little overhaul to their advisory pages and I noticed that they too now use entirely too many tracking numbers.
For example, this Sun advisory has the following:
- Document ID: 200582
- Old Document ID: (formerly 103143)
- Bug ID: 6497289
- SA Document Body: PPGNRLA Internal ID use only.
Why is one tracking number so difficult?
Nutshell What you see here is the output of the ”arfis project”, a simple perl script. It automatically downloads and extract PHP projects from sourceforge.net and checks for Remote File Inclusion vulnerabilities. It then post’s the potential (now it’s -potential-, cause the script is in an early stadium) vuln to this blog.
The idea behind this tool was joked about by several VDB managers over a year ago due to the growing trend of false vulnerability reports popping up in 2006 and 2007. The style of many posts to mail lists were becoming the same, several signatures suggesting a tool or group was involved appeared and it was speculated that many remote file inclusion (RFI) vulnerabilities were the result of a very primitive “grep and gripe” style vulnerability ‘research’. Jump to today and we have this script doing what we suspected all along. Some will proclaim “genious!” and others may be quick to download and taste the fame of being a “vulnerability researcher”. Before you plan your victory party and brush up your resume to include vulnerability research, consider that this script is blindly searching projects for specific lines that suggest an application is vulnerable to RFI. Without looking at the source code manually, there is no way to accurately determine if it is a legitimate vulnerability or a false positive. The people using this script don’t seem to fully understand that and blindly use the tool w/o consideration.
Recently, 8 or so of these arfis-found vulnerabilities were reported to milw0rm for inclusion in their database. Upon examination, 6 of the 8 were not legitimate vulnerabilities. Of the 2 that were, one had been reported two years prior. This is a good indication of how trustworthy the tool is, early release or not, and what kind of burden it places on VDBs who do their best to vet vulnerability disclosures to a limited degree.
Yes yes, yet another “Month of..” campaign. If you track the mail lists, you may have seen a post about a “Month of [something]” Bugs. Despite little follow-up, this campaign is going strong on the 17th day demonstrating a variety of vulnerabilities in lycos.com, search.myway.com, images.google.com, mamma.com, metacrawler.com, ezilon.com, ask.com, ftpsearch.rambler.ru, searcheurope.com, blogs.yandex.ru, clusty.com, autos.msn.com, shopping.msn.com, gigablast.com, hotbot.com, search.yahoo.com and meta.ua.
Definitely an interesting project to follow.
A while back I wrote about VDBs and site specific vulnerabilities. The general concensus is that VDBs should not track site specific vulnerabilities, even though some do for bigger sites that provide services (i.e. Google, Gmail, Yahoo). While OSVDB does not, we recently ran across a site that is now tracking Cross-Site Scripting (XSS) vulnerabilities in web sites. Interesting watching various high profile sites that don’t appear to properly test their applications before deployment.
It was bound to happen, now we get to see a Month of Search Engine Bugs. It would be nice if this effort included some bugs with meat rather than relatively obscure cross-site scripting issues.
The time has come for announcement of my new project – Month of Search Engines Bugs. This project will be in the next month. So June is a month of bugs in search engines. Purpose of this Month of Bugs is a demonstration of real state with security in search engines, which are the most popular sites in Internet. To let users of search engines and web community as a whole to understand all risks, which search engines bring to them. And also to draw attention of search engines~R owners to security issues of their sites. During the month everyday will be publish vulnerabilities in most popular search engines of the world. Cross-Site Scripting vulnerabilities in particular. Everyday will be publish vulnerabilities in different engines (minimum one publication at a time, but there will be bonus publications also).
I saw this article the other day, IBM Scolds TippingPoint Over Hacking Contest and figured now what? But I decided it would be an interesting read.
A couple quick blurbs from the article:
IBM’s ISS division has torn into rival TippingPoint for sponsoring the hacking contest that led to the disclosure of a QuickTime vulnerability in Apple’s Safari browser. “IBM Internet Security Systems agrees with Gartner’s assessment that “public vulnerability research and ‘hacking contests’ are risky endeavors, and can run contrary to responsible disclosure practices.” It is for this reason that IBM ISS strongly adheres to its well-established responsible disclosure guidelines.”
Once I read the article it was then that I realized…. that it really wasn’t IBM, but ISS (who IBM purchased recently) that was scolding TippingPoint for sponsoring this contest. Immediately I thought about all the drama that went on when ISS disclosed their Apache Chunked Encoding Overflow back in 2002.
http://lwn.net/Articles/2756/ It all looks like a fairly normal response to security problems in the free software community, until you look a little more closely. It turns out that the Apache group was already aware of the problem and was working on a fix. The Computer Emergency Response Team (CERT) also was already involved. It also turns out that the ISS patch does not completely fix the problem. ISS, in its hurry to publicise the vulnerability, had not checked with either CERT or the Apache Software Foundation.
Does anyone remember all of this?
ISS took quite a bit of criticism for this disclosure and responded publicly to clean up any confusion and misunderstanding.
The very last portion of this posting is what I find real interesting:
ISS has made these decisions based on our mission to provide the best security to our customers and being a trusted security advisor.
For me personally.. It is kind of funny that disclosure almost always seems to come back to the argument of… we did it for the greater good… we did it for the benefit of others… we did it for the right reasons…
But you on the other hand…
In the final days of March, a “week of Vista bugs” was announced. As some suspected, it turned out to be a hoax. For the full story on how it was carried out, check the breakdown from the perpetrators.
All in all, not a very impressive hoax by any means. Even looking at the screenshot they include of Google, you can see that the top ten hits weren’t anyone seriously buying into it.
One of the most often used, and later debated, analogies used for actions in the security/hacker industry is that of comparing port scanning to walking down a road checking doors and windows to see which are unlocked. This is fundamentally flawed because port scanning looks for open services that your computer is offering other people on the network. There is no expectation of ‘services’ offered when walking down a neighborhood street, regardless of checking doors and windows. A slightly better analogy would be walking down a street full of shops that have no power (no lights, no neon open signs) checking doors to see which are open.
Earlier today, someone (likely troll) on Full-Disclosure used an analogy i have heard before but didn’t give thought to. he tried to compare aspects of the vulnerability disclosure debate to other virtual events as well as the ‘real world’.
And while you might think these efforts are noble, the reality of the situation is simple – this is absolutely no different than a bunch of Russians with botnets, forcing businesses to comply with their demands if that business wishes to continue existing on the Internet.
Bad analogy #1. A vendor who writes code resulting in an exploitable flaw is at fault for doing so. A vendor who is taken offline due to bandwidth saturation attacks is not at fault.
When was the last time an auto manufacturer was humiliated publicly because their car windows can easily be broken and contents of the car stolen? When have chain manufacturers been chastised by the mass media for the existence of bolt cutters? What about the serious threat of hacksaws?
Bad analogy #2a. Breaking windows and cutting locks is better compared to your beloved Russians with botnets. Software can be written not to be vulnerable to well published attacks while still being practical and functional. Glass can not be designed to be unbreakable while still being practical (the cost associated with it isn’t). Locks can be designed fairly securely if they are heavy enough and well done (and costly), but chains suffer the same problem as windows.
Bad analogy #2b. When was the last time we saw a manufacturer give credit to the people who discovered the problem? You see a jeep vendor giving props to the thirty two people that had theirs tip over when it shouldn’t? Do you see the vendor give a timeline and coordinate disclosure with the news outlets? No.
In general, I find it amusing that security professionals spend so much time coming up with poor analogies to describe simple actions we should all be familiar with, that are already morally ambiguous to begin with.