[Owasp-leaders] What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability. |

Kevin W. Wall kevin.w.wall at gmail.com
Tue Nov 10 03:32:37 UTC 2015


Stephen, et al,

First, I'm CC'ing this to the OWASP leaders list. Since I opened a can of
worms there, it's only fair to try to close it up somewhat in public view.
I at least owe Stephen that.

Second, @Tom, thanks for originally posting this to the leaders list and
making me aware of it and also for following up my questions to Stephen.

Thirdly, @Stephen, thanks for your quick reply and the fantastically well-
explained research. I shall attempt to follow up with the disclosure issue
in-line, below.


On Mon, Nov 9, 2015 at 11:35 AM, Stephen Breen
<Stephen.Breen at nttcomsecurity.com> wrote:
> Thanks for forwarding Tom.
>
> Unfortunately the situation with this vulnerability is a little bit complex
> and there is some disagreement on the subject of whether this was
> irresponsible disclosure.

Sigh; by no means did I intend to make it sound as though this were entirely
the fault of FoxGlove Security. IMO, the ball was dropped several places by
several groups. In the end, it really doesn't help matters to place "blame"
anywhere as long as we all learn from it. (Including myself in that!)

> In our opinion this is a 9 month old vulnerability that was completely ignored
> and we wanted to get the word out. I don't consider the exploits we released
> to be 0-day, and if you disagree, then I would concede that they are at least
> not 0-day worth keeping secret. Within TWO days of hearing about the Apache
> commons bug and exploit code released 9 months ago I had discovered and
> developed proof of concept exploits for the 5 products identified in the
> article. This is not because I'm particularly clever, but because the exploit
> identification and development is trivial given what was released previously.

Well, unfortunately, most development teams don't monitor security postings.
If there *was* an existing 8-9 month existing CVE filed against this, then
I could see your point. There very may have been, but I tried researching
that in the usual places (NVD, Mitre, cvedetails.com, Google, etc.) and
didn't really find anything specific to InvokerTransformer. In fact, as
near as I can tell, the news of this vulnerability seemed to catch the
Apache Commons-Collections development team by surprise as it was only
this past Saturday when they filed this bug ID on it:
    https://issues.apache.org/jira/browse/COLLECTIONS-580

I think, had they been aware of this and there had already been a bug open
for it, that this bug ID would have likely been closed as a duplicate. Thus,
I'm assuming there were not aware of this issue. Like the Jenkins team,
this seems to have caught them by surprise.

Also, as you can see by the comments in the bug ID, they have already
developed a proposed fix for this. So chances are good that had they
been informed back on Jan 28th when Gabriel Lawrence and Chris Frohoff
posted their presentation to Slideshare, we'd have a fix available today from
the Apache Commons-Collections folks and at least there would be some recourse
for the other vendors to patch their projects in a more proper manner than
simply tracking down all the jars where InvokerTransformer appears in and
deleting it from said jars. (Indeed, I think by your referring to it as a
"monkey patch" that even you agree this is a kludgy workaround at best.)

Note that I cannot speak to whether Gabriel or Chris attempted to contact
the Apache Commons-Collections development team or attempted to file a
candidate CVE with Mitre or not, but either way, what's done is done.
However, based on the wording of your blog, it appears as though you might
have thought there was an existing CVE for this vulnerability.

Furthermore (and this is important), even *if* Apache Commons-Collections
*had* made a patch avaiable 9 months ago, this still does not mean that
all the affected servers that you detailed would have been patched. I
have some level of confidence that all of the FOSS ones, such as Jenkins,
JBoss, and OpenNMS, would have been patched, but have much less confidence
about Oracle WebLogic (and if they had, it would have been rolled up with
several other vulnerability patches and discussed as "multiple undisclosed
vulnerabilities" so we wouldn't have really been sure; sigh).  But at least
we might have had a fighting change to do a more proper workaround.

> If we can do this with material already publicly available, so can anyone
> else. If I were running one of MANY affected products, I would prefer to know
> that it has had such a vulnerability outstanding for over 9 months and work
> toward a remediation. The attention this subject has gained also allows for
> affected products that were not listed in the post to work on this issue
> internally.

I agree. And also, now that those running an IDS know what to look for
(the hex string "aced0005" or the base64-encoding thereof), I wouldn't
be surprised if someone found attempts to use this at least on WebLogic
servers in their IDS logs. In other words, I think very few of us would
be surprised if this has been undetected and present in the wild for a
few months.

Having said all that, we are now in a situation where we going to have
Java web applications at additional severe risk until the affected vendors
deploy patches, which for some, may well be months. As you say, any pen
tester worth their salt could have probably put 2+2 together, done the
necessary research, and managed to duplicate your results. But unfortunately
what you have done, since apparently you assumed those affected were
aware of this issue, is to bring the exploitation of this vulnerability
within reach of all the script kiddies as well. (Okay, they technically
still have to implement a custom destructive payload--remotely executing
calc.exe or "touch /tmp/pwned" isn't going to be terribly useful except as a
test to see if this is patched or not--but even that does not seem completely
out of reach using ysoserial to develop a payload.)

Lastly, we still really need a CVE for this original Apache
Commons-Collections vulnerability in InvokerTransformer. If we
had that, then developers who are conscientious enough to use
OWASP Dependency Check will at least be made aware of the issue.
(Like I said, very few development teams monitor CVEs, but some
teams are starting to come around and use Dependency Check.) Having
a CVE for this base vulnerability (I imagine there will be separate
ones for WebSphere, WebLogic, JBoss, etc.) will also allow security
teams using SAST approaches to more easily identify potential issues
with those using unpatched versions commons-collections jar as they
too can use Dependency Check to check this. So is Apache going to
create a CVE for this? If not them, then how about Stephen or Gabriel
or Chris? If no one steps forward, I guess I can take a shot at it,
although I know based on creating two for ESAPI that it's a royal PITA.
Any takers???

Anyway, I've babbled on long enough. I'm sure that you didn't have any
malicious intent in not notifying the vendors of this issue and allowing
them time to patch. In hindsight, it all looks like miscommunication.
But what's done is done, so let's all move forward and offer suggestions
as to how we can address this. I apologize for opening that can of worms;
hopefully, this does a bit to reseal that can.

-kevin
-- 
Blog: http://off-the-wall-security.blogspot.com/
NSA: All your crypto bit are belong to us.


More information about the OWASP-Leaders mailing list