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

[This was originally published on the OSVDB blog.]

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!

OSVDB – We’re offering a bounty… of sorts!

[This was originally published on the OSVDB blog.]

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

[This was originally published on the OSVDB blog.]

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!

Quit volunteering my time.

Every week someone, or several people, think their 140 characters is worth me spending an hour+ writing an article for them. They noticed some plagiarized text or think someone is a fraud, and they turn around and expect me to research and document it. For years now, I get mail to Errata with a single link or a couple lines of commentary, along with the expectation that is all that is needed. Voila! An article will magically appear. These days, I don’t even get an email, just a Tweet or two.

I’ve said it before, many times. I’ve given an entire presentation on the project twice. I’ve told people in person, in email, and on Twitter. For the last time:

Errata was designed to be a community project. That’s “crowd-sourced” for you new people. A couple people serve as a clearinghouse for well-written, well-documented articles. No names on the articles because if they are properly referenced then attribution is not an issue. Then the clearinghouse stands up to defend the work as needed. Simple concept.

If you are in the security industry and cannot write an Errata article, get the fuck out now. You are simply too stupid and too dangerous to be advising anyone on something so important as security. Sure the articles take a little time because they have to be solid on making logical points, being organized, and citing public information that justifies any accusations or conclusions. But anyone that does penetration testing or auditing or system maintenance should be familiar with documentation along these lines. They are not difficult to write, they are time consuming.

If it bothers you that someone plagiarized or is selling snake oil, and it should, then take the time to write your own blog. Enough of us have stood up and defended our work. We’ve shown that you can do it, quite safely, if you are responsible in your work. If you still feel it risky, write the article and send it over. Do the leg work, we’ll provide the safety net.

Until you send such articles, don’t volunteer me to write them.

Any wonder why people use images without attribution?

Found the perfect image for my @BSidesDE talk. Noticed in the corner a tiny ‘GettyImages’ watermark, so I went to their site to see how much it would cost to license. Because I happen to know they require a license… which I imagine 99.9% of the modern Internet world does not. The auto-pricing options did not seem to match my intended use, a regional talk to maybe 75 people. I chatted with a rep to ask if there was a better price than $495 quoted by the web site.

Welcome! A representative will be with you shortly. For your security, do not give out your credit card number or other sensitive personal data during a Live Chat session.
You are now chatting with Andy.
Andy: Hello! How can I help you today?
Brian Martin: When selecting the pricing options, the drop down listing possible uses does not include anything close to what I want to use the image for.
Andy: How do you plan to use the image?
Brian Martin: For a regional public conference (free to attend), I am not being compensated for the talk.
Andy: Okay, will it be in a presentation?
Brian Martin: Correct
Andy: Okay, we do have a license for that. What image were you interested in?
Brian Martin: http://www.gettyimages.com/detail/photo/woman-at-computer-control-panel-1960-high-res-stock-photography/10153785#
Brian Martin: That is an IBM 7094 if you would like to update the information =)
Andy: Michelle Williams at Beyonce’s bday party?
Brian Martin: No…
Andy: Okay, I must have pulled up the wrong image
Brian Martin: http://www.gettyimages.com/detail/photo/woman-at-computer-control-panel-1960-high-res-stock-photography/10153785#
Brian Martin: “woman at computer control panel 1960 high res”
Andy: Okay, woman at her computer panel?
Brian Martin: yes
Andy: yes, I see it.
Andy: Okay, so this usage will fall under our External Presentation license
Andy: You can find that under our Marketing Use category
Brian Martin: OK, that was not on the drop down list. How much is it to use the image for such a purpose?
Brian Martin: OK, but this is not marketing at all. Just a talk about the history of software vulnerabilities. I am with a 501c3
Andy: How many people do you think will be ata this conference?
Andy: Right, but it’s a public conference right? Not just your company?
Brian Martin: think they are expecting 150 max across two days, maybe 75 max in my presentation
Brian Martin: Correct
Andy: Okay. Even though it isn’t marketing, that is the correct license for this use.
Brian Martin: OK, how much is that?
Andy: Pricing for that license comes out to be $685
Brian Martin: Unbelievable
Andy: Is that anywhere near your budget for this project?
Brian Martin: Since GettyImages hates 501c3 non-profit work for the advocacy of better computer security, I will have to find an alternate image. Thank you for your time.
Andy: No problem. Enjoy the rest of your evening!
Andy: Thank you for chatting today. We value your feedback. Please click the “Close” button at top right to answer a few questions about your experience with us today.
Thank you for chatting with us. Please click the “Close” button on the top right of the chat window to tell us how we did today.

I understand they want to make a profit, but without more granular licensing, do they have any doubt people freely use their images in presentations or web sites, simply cropping out the watermark?

If I had used GettyImages for each image in my presentation, I would be looking at a convenient rate of about $34,250.

Seeing those EULAs in a different context.

Many years ago I realized that the End User License Agreements (EULA) that we are forced to endure for web sites and software was out of hand. There have been a lot of good points made in the past about them and how they are rarely read. I had written notes about an article but wanted to add something that I had never seen before. What do all those EULAs look like if they are printed? I made a list of all the software on my computer at the time, and a handful of web sites. Ultimately, I never got around to doing it but I mentioned it in discussions with various people.

Recently, Andrea Matwyshyn and I discussed it as well. Some months later, she and some of her students did exactly what I wanted. Pictured below are printouts of some of the many EULAs you have “read”, or at least agreed to. That is a whole lot of legalise you are bound to. Be scared.

Wharton EULAs

Wharton EULAs2

We’re Doing the Unthinkable

[This was originally published on the OSVDB blog.]

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?