Site Specific Vulnerabilities
Posted by jkouns
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.
Despite not including them in the main database, OSVDB does catalog site specific vulnerabilities informally. We currently have notes on over 160 sites/services dating back to 1998 that have been posted about on various mailing lists. It is very interesting to see the history of these types of issues, the stated motivation for disclosing the vulnerabilities, and the perceived severity and popularity of the sites.
you have absolutly right about determine vuln. in my case i did checked scripts that dont use not vendor site and dont offer demo´s … But mostly they have case studies/clients are listed by vendor. To get correct version, mostly is enough to find admin panel for that script … and you will get a correct version.
“input passes to the search module paremter” - yes i know its not enough information to be correct, but if you dont have that source and you dont see elso by live example wich paramter isnt properly santized?.,.. better is to say, i dont care will try another one… no even its poor dangeours level like by XSS in “right” hands it will be enough for attacker to get what he wants. I had spoken about this also with guys form secunia, cauz they had same problems to prove , in my case i can always poffer life example if its needed, you can always contact me and i will give you.
i have big respect to that what you do here and i think osvdb is one of correctest VDB on net.
sorry for my english.
There are half a dozen or more proxy packages specifically designed for testing web sites. They will let you see exactly what pages and variables are being accessed. They can also let you change the data you send after it leaves your browser, before it hits the web site. If you use such a tool, you could include the exact script name and variable for each of your postings. This may also let you find additional vulnerabilities as well as more thoroughly research the ones you do find.