Somewhere out there is a point-and-click web application that allows neophyte “security researchers” (yes, that is a joke) to quickly whip up their very own Bugtraq or Full-Disclosure post. I’m sure others have noticed this as well? More and more of the disclosures have too much in common, and unfortunately for VDBs, more and more are completely bogus reports. I feel bad for the vendors as much as I feel for those of us trying to track vulnerabilities. Anyway, some of the many things these disclosures have in common:
- Title (example: EasyBannerFree (functions.php) Remote File Include Exploit)
- # Everything is commented as if this is supposed to be a script
- The remote file inclusion is http://shell.txt or SHELLURL.COM
- It has a single line of source code quoted to “validate” the finding (example: rrequire ( $path_to_script.”globals.inc.php”);
- May have 80 lines of perl code to exploit a single http:// line, because it looks cool
- Contains more greets/thanks than vulnerability information
- If their disclosure is proven false, they never seem to reply to explain themselves
Odds are strong they won’t include the vendor or give enough information to find it via extensive searching. Odds are good it will not contain the version supposedly affected and contain typos in the script or variable names. And worst of all, it is a glorified “grep and gripe” disclosure. Meaning, they grep out the ‘require’ line, don’t bother to check any other portion of the code, and assume it is vulnerable. Some will go so far as to say stuff like “ (tested on Version 1.13)” even though it is quickly proven false.
So, “security researchers” disclosing all these remote file inclusion bugs. Test your finds before you publish, no more grep and gripe crap please.
January Set As ‘Month Of Apple Bugs’
The “Month of Apple Bugs” project, which will be similar to November’s “Month of Kernel Bugs” campaign, will be hosted by the kernel bug poster who goes by the initials “LMH,” and his partner, Kevin Finisterre, a researcher who has posted numerous Mac vulnerabilities and analyses on his own site.
More interesting this time, Landon Fuller has begun using his own blog to release unofficial patches for the MOAB vulnerabilities as they are released.
No, not a typo. A couple weeks back, Argeniss “was proud to announce that we are starting on December the “Week of Oracle Database Bugs” (WoODB).” A couple days ago they abruptly called off the WoODB with the following message:
We are sad to announce that due to many problems the Week of Oracle Database Bugs gets suspended.
We would like to ask for apologizes to people who supported this and were really excited with the idea, also we would like to thank the people who contributed with Oracle vulnerabilities.
It’s hard to ignore the obvious possibility (especially with so many other people saying the same) that they solicited the community to support their effort by submitting unpublished Oracle vulnerabilities, then arbitrarily shut the effort down while keeping all the information and not sharing it as stated. Argeniss, why not give us the full story? Were you threatened by Oracle? Drastic change of ethical stance? Pure greed when you realized the value of a hundred contributions?
First it was the Month of Browser Bugs (MoBB), now it is the Month of Kernel Bugs (MoKB). When I first read about it, I immediately thought of thirty odd entries about Linux Kernel Local DoS conditions. My pessimism is born out of the numerous local DoS attacks against the Linux Kernel. Microsoft fans use this to say that Linux has so many more bugs than Microsoft, but i’m sure if we documented every way to make any version of Windows blue screen, we’d be cutting ourselves.
Fortunately, the MoKB has started out very well by offering vulnerabilities in Mac OS X Kernel Wireless Drivers, Linux, FreeBSD, Solaris, and Windows. Only 11 days in, and all of that! The folks putting this together are doing an outstanding job putting this together, researching the vulnerabilities and presenting them.
In the months and years to come, what else will we see? What would you like to see the most.. Month of ______ Bugs.
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.
Paul Clark, Systems Librarian at the Wilderness Coast Public Libraries, has created an excellent timeline of Full Disclosure related articles. Unfortunately, mail to him is bouncing and it hasn’t been updated since 2004. Would be great to see someone pick this up.
Ever wondered what some of the bigger vendors do in response to vulnerability Disclosure? Federico Biancuzzi has written an article on his Disclosure survey which may answer the question for you. Apple, Computer Associates, Google, IBM, Microsoft, Novell, Oracle, Red Hat, SAP, Sun Microsystems and Yahoo all answered to one degree or another. As always, some of the vendors are a bit weak in the description. Take Oracle for example, who says they want researchers to wait for their patch before disclosing. Next he asks the two big vulnerability purchasing shops iDefense and TippingPoint’s ZeroDayInitiative (ZDI) their thoughts. Finally, he asks three prominent researchers; David Litchfield, H D Moore and Michal Zalewski.
No, this isn’t some odd contest with a disappointing reward. Date an OSVDB moderator! *shudder*
Think of dates in the context of vulnerability disclosure. Think of how many dates we don’t know, even in the more formal advisories (some with time lines even). OSVDB currently tracks three dates: Vulnerability Published, Vulnerability Discovered, Exploit Published. We have additional dates that we will add to the system as developer time permits, but unfortunately most vulnerabilities don’t come with the information we need. In a perfect disclosure world, each vulnerability posted would come with a robust timeline:
- Vulnerability Discovered
- Disclosed to Vendor
- Vendor Acknowledgement
- Vendor Patch
- Public Disclosure
This would allow VDBs to track better metrics, including vendor response time, patch development time and more. Are there more dates that would be relevant and of interest?
I’ve mentioned the sociology aspect of the hacker, vuln researcher and security companies before, specifically how they interact, how one will influence another and more. The list of fun ideas I have on these topics is great, and maybe some day i’ll find the time to write more on them. In the mean time, this obvious one popped up and focuses on vulnerability researchers, how they find bugs, and how some feed off the work of others. We see this often where ResearcherA will find a vulnerability in one script, disclose the information, and ResearcherB will followup shortly after with the same type of vulnerability in a different script of the same product.
Recently we’ve seen a rash of remote file inclusion bugs in various add-ons to Mambo and Joomla. These add-ons are typically not written by the same developers nor are they distributed with the base installation of each product. However, they all seem to have one thing in common: “mosConfig_absolute_path” (or sometimes “absolute_path”). The same variable is being exploited in dozens of different add-ons and being found by different people. If we examine the chain of disclosure, can we see patterns in who consistently does followup research (low hanging fruit) instead of finding original vulnerabilities? Are there more observations in the way they are disclosed such as reporting to exploit sites vs Bugtraq or Full Disclosure? Are there misplaced signs of ego that accompany what amounts to trivial vulnerability finds while others are more modest and take it for what it is? Is it surprising that as people jump on the bandwagon, more and more reports end up being inaccurate and not a real vulnerability?
While skimming the list,
strike-out text indicates the vulnerability has been disputed or proven false. The names of the researchers who didn’t fully check their find are in bold (and I’m curious if the other disclosures hold up under scrutiny). There is one occurrence of italics that potentially shows this type of “research” being used in the wild.
2006-08-21 bigAPE-Backup for Mambo – mdx
2006-08-20 Display MOSBot Manager for Mambo – O.U.T.L.A.W (Aria-security)
2006-08-20 EstateAgent for Mambo – O.U.T.L.A.W (Aria-security)
2006-08-19 CatalogShop for Mambo – O.U.T.L.A.W (Aria-security)
2006-08-18 Joomla x-shop – Crackers_Child
2006-08-18 Joomla Rssxt – Crackers_Child
2006-08-18 Kochsuite for Joomla – camino (Insecurity Research Team)
2006-08-18 mtg_myhomepage For Mambo – O.U.T.L.A.W (Aria-security)
2006-08-18 mambo-phphop Product Scroller – O.U.T.L.A.W (Aria-security)
2006-08-17 contentpublisher for Mambo – Crackers_Child
2006-08-17 MambelFish for Mambo – mdx
2006-08-17 JIM for Joomla – XORON
2006-08-17 mosListMessenger for Mambo – Crackers_Child
2006-08-17 anjel for Mambo – Crackers_Child
2006-08-16 Coppermine for Mambo – k1tk4t
2006-08-16 Reporter for Mambo – Crackers_Child
2006-08-16 com_lm for Mambo – Crackers_Child
2006-08-14 MMP for Mambo – mdx
2006-08-14 PeopleBook for Mambo – Matdhule
2006-08-10 Remository for Mambo – camino (Insecurity Research Team)
2006-08-07 JD-Wiki for Joomla – jank0 (hackbsd crew)
2006-07-31 Mambatstaff for Mambo – Dr.Jr7
2006-07-30 UHP for Mambo – Kurdish Security
2006-07-29 artlinks for Mambo – Dr.Jr7
2006-07-29 Colophon for Joomla – Drago84 (Exclusive Security Italian Security)
2006-07-28 Security Images for Joomla – Drago84
2006-07-28 MGM for Mambo – A-S-T TEAM
2006-07-28 Guestbook for Mambo – Matdhule
2006-07-24 PrinceClan Chess for Mambo – Tr_ZiNDaN
2006-07-20 MultiBanners for Mambo – Blue|Spy
2006-07-17 Mambo-SMF Forum – ASIANEAGLE
2006-07-17 VideoDB for Mambo – h4ntu (#batamhacker crew)
2006-07-17 LoudMouth for Mambo – h4ntu (#batamhacker crew)
2006-07-17 PollXT for Joomla – vitux
2006-07-17 Calendar for Mambo – Matdhule
2006-07-17 New Article for Mambo – Ahmad Maulana a.k.a Matdhule
2006-07-13 perForms for Joomla – “Vuln founded in a log file: lazy 0day!!! :D”
2006-07-12 Hashcash for Joomla – Ahmad Maulana a.k.a Matdhule
2006-07-12 SiteMap for Mambo – Ahmad Maulana a.k.a Matdhule
2006-07-12 HTMLArea3 for Mambo – Ahmad Maulana a.k.a Matdhule
2006-07-10 PccookBook for Mambo – Ahmad Maulana a.k.a Matdhule
2006-07-07 ExtCalendar for Mambo – Ahmad Maulana a.k.a Matdhule
2006-07-03 Galleria for Mambo – sikunYuk
2006-06-26 CBSMS Mambo Module – Kw3[R]Ln (Romanian Security Team)
2006-06-13 Jobline for Mambo – SpC-x
While all of this not necessarily useful to many, this line of research and observation is fascinating.
Symantec posted a message to Bugtraq earlier this month announcing the availability of a new advisory. The advisory presumably covers a vulnerability or issue in Symantec On-Demand Protection. If you are reading this blog entry a year from now, that is all you may find on it. Yes, even in this day and age, not everything is archived in Google cache or archive.org! In December of 2000, Elias Levy (moderator of Bugtraq at the time) said that such posts were not acceptable because security company web sites had a habit of disappearing, leaving no trace of the information behind. Years later, Symantec bought SecurityFocus (who hosts/moderates the Bugtraq mail list) and we see this rule being ignored, and of course the approved post comes from their owner. Some may argue that Symantec is huge and won’t disappear like those other companies. Many said the same about @stake but shortly after they were purchased, their new owner (Symantec) opted to yank all of the old advisories off the web site making Elias Levy’s concerns reality. As Chris Wysopal said in reply, Symantec needs to post their advisories to the list just like everyone else. While Symantec may stick around, their web site may change or corporate policy may be altered, and that information may not be readily available in the future.