Slashdot Mirror
Why Sharing Ransomware Code For Educational Purposes Is Asking For Trouble (betanews.com)
Mark Wilson writes: Trend Micro may still be smarting from the revelation that there was a serious vulnerability in its Password Manager tool, but today the security company warns of the dangers of sharing ransomware source code. The company says that those who discover vulnerabilities need to think carefully about sharing details of their findings with the wider public as there is great potential for this information to be misused, even if it is released for educational purposes. It says that 'even with the best intentions, improper disclosure of sensitive information can lead to complicated, and sometimes even troublesome scenarios'. The warning may seem like an exercise in stating the bleeding obvious, but it does serve as an important reminder of how the vulnerability disclosure process should work.
Martin Roesler, Trend Micro Senior Director for Threat Research says...
We need to share knowledge that creates understanding about potential damage, but not the ability to create it. We need to share knowledge about 'who exploits work', but not 'how to make use of them'. We need to share knowledge 'how malware works', but sharing 'sample code' is not needed for that.
i wouldn't consider him a reliable source considering he allowed them to write a password manager in javascript.
Anons need not reply. Questions end with a question mark.
This is the second story in as many days arguing for limitation of disclosure for an indeterminate period. The first was the story lauding GM for doing the same, when it made it's list of the types of disclosure for which it will not go after you legally.
You have to put a clock on these things; the only thing a company executive cares about is keeping the board happy, and the only thing that the board cares about is fiduciary responsibility to the stockholders, including themselves and the company executives.
This is what we incentivize with how we have built these systems to operate. And it incentivizes behaviours which are not in a customers/consumers best interest, in most cases.
If someone had come up with the GM ignition problem as a potential disclosure, and then gave them a three month clock to public disclosure, it would have been handled through a rather immediate recall. Instead, it was handled by accepting the lawsuit payouts as a "cost of doing business", and then determined that the highest actuarial benefit was to simply eat those costs while imposing gag orders, rather than taking the more expensive option of fixing all the ignitions in all the vehicles. It was less expensive, overall, to the company, that some people die in order that the company make a marginally higher profit.
While I doubt that many software vulnerability disclosures will result in deaths, the same principle holds true. Both GM and Trend Micro would like apriori restrictions -- one through veiled threat of legal action, with a bounty carrot, and one through guilt shaming for those who disclose.
Responsible disclosure is really the only ethical -- and moral -- option.
Put a clock on it. Always.
If a company is (arguably) already treating security reasonably seriously, then spreading details on how to hurt their customers does not achieve anything.
That kind of assumes there aren't malicious people already exploiting the bug.
Sometimes it's better to let people know so they can defend themselves: either by closing a port, changing a configuration, turning off a service, fixing the bugs themselves and recompiling, or switching to another software system.
Of course, corporations don't like the last two options, but being able to recompile is a very real benefit of open source software.
"First they came for the slanderers and i said nothing."
No, selling stuff is the goal of many places that among other things care very little or not at all about security. Your bit about "If a company is (arguably) already treating security reasonably seriously" is very much the exception instead of the rule. I've reported gaping security holes that were left open for years and they were not taken seriously because nobody on the outside had been caught exploiting them - and that was on a cash handling system FFS!
I don't condone those making the bugs public but I can see why they do it. Reporting a serious security problem to some places can both land the reporter in deep shit and still result in nothing being done to fix the actual problem. Management in such places sees taking action against the reporter as the complete solution to the problem. Their reaction to an open farm gate would be to shoot each cow on the way out instead of shutting the gate.
1) Making malware code public helps malware programmers (current and aspiring) write better malware programs.
This request is specific to ransomware, not generic malware. Anyone with poor ethics can deploy either, but ransomware has the potential to make an irreversible impact on victims. Yes, malware can reformat a drive and wipe data, but ransomware provides greater motivation to attackers because of the potential for direct profit.
2) Making malware code public helps anti-malware programmers (current and aspiring) write better anti-malware programs.
Anti-malware code is a specialized field, and there are fewer than 50 companies who have much marketshare. Entry into this field is a high bar, requiring the trust of many people. Even then, many of the products are of poor quality, and/or have their own unethical behavior. An aspiring anti-malware author will have much greater difficulty breaking into the field than an ordinary app developer. There isn't much of a market for specialized anti-ransomware.
Who benefits more? I honestly don't know. However, my bias is towards openness over secrecy, and I think it needs to demonstrated that the risks of making malware code public outweigh any potential benefits.
Publishing the ransomware code creates very specific risks. If perfectly executed, ransomware results in absolute hijacking of the user's data. But as we know from legions of flawed security software, writing perfect code and implementing cryptographic algorithms perfectly is very difficult. Recent ransomware made the news because it was imperfect, allowing investigators to recover the encrypted data for all clients without paying the extortionists. The fear is that publishing the ransomware code will give a working example of properly executed encryption that researchers can't break.
You also have to consider how anti-malware code typically works. Much of it is still signature based, meaning that a working copy of the code can simply be tweaked or recompiled to evade signature detection, and the recompiled code will remain effective. Source code won't help the anti-malware authors much.
So overall, publishing the code will greatly benefit the attackers, and will be of only marginal benefit to anti-malware authors. It is hoped that anyone in possession of ransomware source code already understands these points, and will not be compelled to release the code for "noble purposes", as there would be virtually no nobility in the gesture.
If you are still interested in how ransomware works, I would recommend "Malicious Cryptography: Exposing Cryptovirology", by Drs. Young and Yung (Wiley, 2004.) This book was one of the first scholarly works on ransomware. You don't need the source code to learn about it.
John
Many of open source projects I'm involved in use a responsible disclosure model. It has worked very well, getting most users patched a few days or a few hours BEFORE the bad guys knew how to exploit it, rather than soon AFTER they got exploited. I'll use as two examples issues I found in Wordpress and PowerDNS (used by wikipedia and other large sites).
I found an issue with Wordpress and opened a security ticket describing the issue and my proposal for a solution. As a security ticket, it was initially visible only to the security team. Over the next 24 hours or so, it was discussed and consensus was developed regarding the right solution. Over the next 24 hours, it was tested and (quietly) pushed to the repository. On the third day, everyone who had Wordpress set to automatically update got the fix, and admins with many, many Wordpress users such as Wordpress.com were notified. So maybe 80%-90% of the Wordpress users had the update on day three. On day 4, the information became public - 24 AFTER the updates had already happened.
Note it took a couple of days between the time the patch was ready and the time most users were protected. Had we released the patch and the information together, that would have been a day or two that the bad guys could have infected servers with persistent malware.
Power DNS was similar, except distros needed time to compile and package the fixed version. So the issue was discussed privately, and the fix tested. Had the vulnerability been public, someone would probably have used it to take down Wikipedia, so Wikipedia was notified of the fix along with a few other very large sites. While Wikipedia was patching, Redhat, Debian, and the other distros were preparing updated packages for their users. This was roughly day three. On the morning of day #4, Debian mailed their users to let them know that a security fix was available and that had information about the vulnerability- AFTER the update was already available from Debian's servers, which was a day or two after the source patch was privately distributed to the appropriately people.
Something else happened that day too. About an hour after the Debian security alert email went out, I had a job interview. When I told the interviewer I worked mostly with Red Hat systems, he seemed disappointed. The conversation continuedg
"We use Debian. Do you know anything about Debian?", he asked. ..." :)
I replied "did you see that Debian security alert about an hour ago?"
"Yeah, this one right here?" he said as he opened the email.
Looking at the first line of the email, he saw it said "Ray Morris discovered a vulnerability
Suddenly he seemed less concerned about my knowledge of Debian.