IBM: Yes, it's true. We leaned on researchers to censor exploit info

Big Blue says this isn't normal practice as infosec bods take down proof-of-concept code

IBM successfully pressured security researchers into yanking offline part of a published vulnerability advisory – even after patches had been distributed to customers.

Last Friday, Italian infosec bod Maurizio Agazzini published details of an exploitable bug in the latest four builds of IBM's WebSphere middleware. He posted details about running a resource-exhaustion denial of service attack that can potentially lead to remote-code execution on a vulnerable system.

Agazzini practiced responsible disclosure and worked with IBM privately to help develop a patch. He held off on publishing full details of the flaw with proof-of-concept exploit code until a software fix had been released.

Thus, it was a bit of a surprise to him and his colleagues at vulnerability research outfit @Mediaservice.net S.r.l. to receive an email from Big Blue asking them to censor parts of his final report.

"Please remove Sections 2 and 5 which list the exploit details," the message states. "IBM does not want to put customers at risk and so we do NOT like the details of an exploit to come out since it puts all our customers at risk."

Section five is a ZIP file of exploit code attached to Agazzini's advisory – the ZIP archive's contents have been removed at IBM's request. Section two reads:

The attack can be reproduced as follows:

• create an application with custom form authentication
• after user login, the LtpaToken2 is set by the application server
• make a HTTP GET request that contains the WASPostParam cookie with one of these contents:
• • 01_BigString_limited_base64.txt: it's a string object; the server will reply in a normal way (object size similar to the next one).
  • 02_SerialDOS_limited_base64.txt: the application server will require about 2 minutes to execute the request with 100% CPU usage.
  • 03_BigString_base64.txt it's a string object; the server will reply in a normal way (object size similar to the next one).
  • 04_SerialDOS_base64.txt: the application server will require an unknown amount of time to execute the request with 100% CPU usage.

IBM's out-of-the-blue email is definitely not the way to do things. Security research is like any other area of academia. Publishing details of a vulnerability with a proof-of-concept exploit is important, as it allows programmers, users and admins to see exactly what the problem was, to see how reliable exploitation is, to test exploits against their environments to make sure the patches are sufficient, to learn lessons from coding mistakes, and so on.

There have been cases where researchers have found a particularly egregious and widespread hack and decided not to include a proof of concept. But for something this minor, IBM's heavy-handed response was unusual. When Agazzini's coworker Marco Ivaldi revealed the pushy email on Twitter, the security community got distinctly peeved.

IBM trying to censor researchers in 2016 deserves to be publicly shamed 🙊 pic.twitter.com/a8iYoUbeu5

— raptor (@0xdeadb) October 13, 2016

Dear @IBM,
Your customers were already at risk. You put them there through insecure programming. Please stop shaming researchers and fix. https://t.co/SF43vySbFM

— Jonathan Zdziarski (@JZdziarski) October 13, 2016

Big Blue has told The Register that it is a big believer in responsible disclosure and recognized the value of flaw publication. It worked with Agazzini on the issue, but sent the private email to him because it was concerned people weren't going to patch in time to fix the problem.

"Though the patch is now available, we understand many organizations can't always apply patches immediately," IBM told The Reg in a statement.

"While not the normal IBM practice, in this specific case, we asked for some of the exploit details to be redacted to protect vulnerable users and allow them time to patch."

We note that Agazzini's advisory is still online in full albeit without its proof-of-concept code. ®