Monthly Archives: October, 2013

More tricks than treats with today’s Metasploit blog disclosures?

Today, Tod Beardsley posted part one and part two on the Metasploit blogs titled “Seven FOSS Tricks and Treats. Unfortunately, this blog comes with as many tricks as it does treats.

In part one, he gently berates the vendors for their poor handling of the issues. In many cases, they are labeled as “won’t fix” without an explanation of why. During his berating, he also says “I won’t mention which project … filed the issue on a public bug tracker which promptly e-mailed it back in cleartext“. In part two, the only disclosure timeline including a bug report is for Moodle and ticket MDL-41449. If this is the case he refers to, then he should have noted that the tracker requires an account, and that a new account / regular user cannot access this report. Since his report was apparently mailed in the clear, the ticket system mailing it back is not the biggest concern. If this is not the ticket he refers to, now that the issues are public the ticket should be included in the disclosure for completeness.

Next, we have the issue of “won’t fix”. Zabbix, NAS4Free, and arguably OpenMediaVault are all intended functionality by the vendor. In each case, they require administrative credentials to use the function being ‘exploited’ by the metasploit modules. I won’t argue that additional circumstances make exploitation easier, such as XSS or default credentials, but intended functionality is often a reason a vendor will not “fix” the bug. As you say in part one, a vendor should make this type of functionality very clear as to the dangers involved. Further, they should strive to avoid making it easier to exploit. This means quickly fixing vulnerabilities that may disclose session information (e.g. XSS), and not shipping with default credentials. Only at the bottom of the first post do you concede that they are design decisions. Like you, we agree that admin of a web interface does not imply the person was intended to have root access on the underlying operating system. In those cases, we consider them a vulnerability but flag them ‘concern’ and include a technical note explaining.

One of the most discouraging things about these vulnerability reports is the lack of version numbers. It is clear that Beardsley downloaded the software to test it. Why not include the tested version so that administrators can more easily determine if they may be affected? For example, if we assume that the latest version of Moodle was 2.5.2 when he tested, it is likely vulnerable. This matters because version 2.3.9 does not appear to be vulnerable as it uses an alternate spell check method. This kind of detail is extremely helpful to the people who have to mitigate the vulnerability, and the type of people who use vulnerability databases as much as penetration testers.

Finally, the CVE assignments are questionable. Unfortunately, MITRE does not publish the “CVE ID Reservation Guidelines for Researchers” on their CVE Request Page, instead offering to mail it. This may cut down on improper assignments and may explain why these CVE were assigned. When an application has intended functionality that can only be abused by an attacker with administrator credentials, that does not meet the criteria for a CVE assignment. Discussion with CVE over each case would help to ensure assignment is proper (see above re: implied permission / access).

As always, we love seeing new vulnerabilities disclosed and quickly fixed. However, we also prefer to have disclosures that fully explain the issue and give actionable information to all parties involved, not just one side (e.g. penetration testers). Keep up the good work and kindly consider our feedback on future disclosures!

We’re offering a bounty… of sorts!

In our pursuit of a more complete historical record of vulnerabilities, we’re offering a bounty! We don’t want your 0-day really. OK sure we do, but we know you are stingy with that, so we’ll settle on your ~ 12,775 day exploits!

First, the bounty. This is coming out my pocket since it is legacy and doesn’t immediately benefit people using us as a vulnerability feed. As such, this isn’t going to be a profit center for you. In addition to the personal satisfaction of helping preserve history, shout outs on this blog and multiple Twitter feeds, I will send you something. Want a gift card for Amazon? Something else I have that you want? I’ll make my best effort to make it reasonably worth your while. I know it isn’t a cool $1,337 Google style unfortunately, but I will try!

Now, what am I after. Not “a” vulnerability, but any of several lists of vulnerabilities from decades ago. These were maintained in the 1980’s most likely, one of which was internal at the time. I am hoping that given the time that has passed, and that the vulnerabilities have long since been patched and most products EOL’d, they can be disclosed. If you don’t have a copy but know someone might, send me a virtual introduction please! Any lead that results in me getting my hands on a list will be rewarded in some fashion as well. If you have a copy but it is buried in a box in the garage, let me know. I will see about traveling to help you dig through junk to find it. Seriously, that is how bad I want these historic lists!

The targets:

  • The Unix Known Problem List (this was not one of the vendor-specific lists, but those may be groovy)
  • UC Santa Cruz hack method list
  • Mt. Xinu bug list (later than 4.2 or with more details than this copy)
  • Matt Bishop’s UNIX Hole List
  • Sun Microsystems Bug-List (internal at the time no doubt)
  • ISIS mail list archive (one run by Andrew Burt in 80’s)
  • Bjorn Satedevas’ systems administration mailing list archive
  • The “inner” Zardoz mail list archive (split from the main one, less members)

Bonus bounty:

Any public-referenced vulnerability before 1980 that we do not have in the database. I know there has to be more out there, help us find them!

Bonus bonus bounty (for SCADA types):

Any SCADA or ICS vulnerability before 1985-06-01!

That’s it! Pretty simple, but may require some digging mentally or physically.

An Open Letter to @InduSoft

InduSoft,

When referencing vulnerabilities in your products, you have a habit of only using an internal tracking number that is kept confidential between the reporter (e.g. ICS-CERT, ZDI) and you. For example, from your HotFix page (that requires registration):

WI2815: Directory Traversal Buffer overflow. Provided and/or discovered by: ICS-CERT ticket number ICS-VU-579709 created by Anthony …

The ICS-CERT ticket number is assigned as an internal tracking ID while the relevant parties figure out how to resolve the issue. Ultimately, that ticket number is not published by ICS-CERT. I have already sent a mail to them suggesting they include it in advisories moving forward, to help third parties match up vulnerabilities to fixes to initial reports. Instead of using that, you should use the public ICS-CERT advisory ID. The details you provide there are not specific enough to know which issue this corresponds to.

In another example:

WI2146: Improved the Remote Agent utility (CEServer.exe) to implement authentication between the development application and the target system, to ensure secure downloading, running, and stopping of projects. Also addressed problems with buffer overrun when downloading large files. Credits: ZDI reports ZDI-CAN-1181 and ZDI-CAN-1183 created by Luigi Auriemma

In this case, these likely correspond to OSVDB 77178 and 77179, but it would be nice to know that for sure. Further, we’d like to associate those internal tracking numbers to the entries but vendors do not reliably put them in order, so we don’t know if ZDI-CAN-1181 corresponds to the first or second.

In another:

WI1944: ISSymbol Virtual Machine buffer overflow Provided and/or discovered by: ZDI report ZDI-CAN-1341 and ZDI-CAN-1342

In this case, you give two ZDI tracking identifiers, but only mention a single vulnerability. ZDI has a history of abstracting issues very well. The presence of two identifiers, to us, means there are two distinct vulnerabilities.

This is one of the primary reasons CVE exists, and why ZDI, ICS-CERT, and most vendors now use it. In most cases, these larger reporting bodies will have a CVE number to share with you during the process, or if not, will have one at the time of disclosure.

Like your customers do, we appreciate clear information regarding vulnerabilities. Many large organizations will use a central clearing house like ours for vulnerability alerting, rather than trying to monitor hundreds of vendor pages. Helping us to understand your security patches in turn helps your customers.

Finally, adding a date the patch was made available will help to clarify these issues and give another piece of information that is helpful to organizations.

Thank you for your consideration in improving your process!

We’re doing the unthinkable.

Anyone who knows me in the context of vulnerability databases will find this post a tad shocking, even if they have endured my rants about it before.

For the first time ever, I am making it policy that we will no longer put any priority on Vulnerability Labs advisories. For those unfamiliar with the site, it is run by Benjamin Kunz Mejri who now has a new company Evolution Security.

If you read that web site, and even a history of his/VL disclosures, it looks impressive on the surface. Yes, they have found some legitimate vulnerabilities, even in high-profile vendors. Most, if not all, are pedestrian web application vulnerabilities such as cross-site scripting, traversals, or file upload issues. More complex vulnerabilities like overflows typically end up being what we call “self hacks”, and do not result in the crossing of privilege boundaries. Many of their published vulnerabilities require excessive conditions and offer no real exploit scenario.

During the past 10 months, I know of three other vulnerability databases that officially gave up on adding their advisories. Nothing public, but the internal memo was “don’t bother”. OSVDB was the holdout. We did our best to keep up with their stream of horrible advisories. I personally offered to help them re-write and refine their advisory process several times. I started out nicely, giving a sincere offer of my time and experience, and it went unanswered. I slowly escalated, primarily on Twitter, giving them grief over their disclosures. Eventually, their advisories became nothing but an annoyance and incredible time sink. Then I got ugly, and I have been to this day. No, not my proudest moment, but I stand by it 100%.

As of tonight, we are giving in as well. Vulnerability Lab advisories represent too much of a time sink, trying to decipher their meaning, that they simply aren’t worth adding. For cases where the software is more notable, we will continue to slam our head against the wall and figure them out. For the rest, they are getting deprioritized in the form of a “to do when we run out of other import sources”. Since we monitor over 1,100 sources including blogs, web sites, changelogs, and bug trackers, this is not happening for a long time.

I truly regret having to do this. One of my biggest joys of running a vulnerability database is in cataloging all the vulnerabilities. ALL OF THEM.

So this also serves as my final offer Benjamin. Search the VDBs out there and notice how few of your advisories end up in them. Think about why that is. If you are as smart as you think you are, you will choke down your pride and accept my offer of help. I am willing to sink a lot of time into helping you improve your advisories. This will in turn help the rest of the community, and what I believe are your fictitious customers. As I have told you several times before, there is no downside to this for you, just me. I care about helping improve security. Do you?

Follow

Get every new post delivered to your Inbox.

Join 5,408 other followers