.png)
One of the most important functions within the cybersecurity industry is the freedom to share research data and collaborate with other industry players in an effort to inform, warn, and hopefully mitigate and outright avert potential security threats before they occur.
As anyone in the industry can attest, hackers never seem to run out of new ideas. As soon as one door closes, there is a race to develop some new sophisticated method to open another under the radar, and we don’t hear about it until researchers have detected the new attack being implemented in the wild.
This isn’t anything new. We already know that it’s the duty of any competent security researcher to discover and address vulnerabilities before threat actors find them. On the other hand, is it possible that industry researchers are inadvertently causing security risks through the public disclosures of the vulnerabilities they find?
Public Disclosure - Hacker’s Best Friend?
This was precisely the case in recent events, which ensued immediately after the security researcher from Alibaba Cloud’s security team privately disclosed the team’s discovery of the Log4j 0-day vulnerability on Nov. 24, 2021, to the Apache Software Foundation. Though the vulnerability existed under the radar since 2013, it potentially posed a possible risk of harming millions of Apache software users.
However, after the research was made into a public disclosure, the possible attack vector became an imminent risk to millions of users impacted by the disclosure, expanding beyond the software itself and affecting Minecraft, Apple iCloud, Twitter, Cloudflare, Steam, as well as numerous software packages from VMWare, to name a few.
Additionally, the public release vulnerability has endangered critical system architecture involving SCADA systems, as well as systems handling matters pertaining to national security. News has already surfaced that the Zero Day exploit has been used to attack and spy on systems associated with the Belgium Defense Ministry.
Essentially, the public disclosure created a nightmare scenario that could have been avoided if the integrity of the research had been managed in a secure manner among those in the know.
Local policies could have been enforced around a non-disclosure agreement that would have protected the millions of users that are now at the receiving end of every hacker with a Log4j scanner looking for vulnerable systems to break into. This is a lesson in causality.
In the aftermath of the disclosure, it seemed that every code slinger on the Github repository began to build scanners and online tutorials to help explain to anyone how to scan, detect, and open a shell on systems impacted by the vulnerability.
Allegedly, Chen Zhaojun himself publicly released the discovery over Twitter on Dec. 9, in addition to a sample code of the vulnerability on Github. However, the disclosure on Github now returns an Error 404, and the Twitter profile itself seems hard to pin down.
When The Industry Directs The Next Cyber Attack
A similar instance unfolded back in September when a public disclosure involving a shelved and forgotten proof-of-concept vulnerability - that had the ability to impact the Windows Subsystem for Linux (WSL) on Windows 10 operating systems - had been discovered by Check Point researchers back in 2017.
The attack had never been implemented in the wild before, and Microsoft dismissed the research as not bearing any immediate security concern because WSL did not come with Windows 10 systems enabled by default, nor with any preinstalled Linux cross-compatibility.
Because the ordeal was made public, threat actors eventually stumbled across the proof-of-concept on the internet and developed advanced malware allowing them to make full use of the information described in the proof-of-concept. Following these new cyber attacks, threat researchers at Black Lotus Labs spotted the malicious activities.
The more publicity, the more public surface the information reaches. Vulnerability disclosure is a sensitive matter.
In times past, vulnerability disclosures have ostensibly been handled with little discretion. I remember reading an article several years ago about how two researchers discovered vulnerabilities in the widely used Medtronic MiniMed and MiniMed Paradigm insulin pump lines.
Hackers could possibly upload malware to these devices and trigger lethal doses of insulin to people with diabetes. The researchers’ initial public disclosure was launched at the annual Black Hat Security conference in Las Vegas.
After publicly disclosing this possible cyber attack scenario that could endanger public health and safety to a room full of hackers, the researchers strove back and forth for two years with the manufacturer of the medical equipment, pressing them to remediate the issue. The company did manage to fix some of the issues.
Nearly a decade before that, researchers at the Medical Device Security Center disclosed a wireless attack vector that could potentially affect pacemakers. Many of these devices rely on radio signals designed to allow physicians to interface with the device in order to reprogram them.
The reports specified that the radio signals are unencrypted, and could allow threat actors in close proximity to disable a pacemaker or deliver a shock to the heart, which could cause ventricular fibrillation, and finally, cardiac arrest.
Researchers discovered potential exploits that could allow hackers to seize control of smart vehicles and publicly explained the attack vector at the Black Hat Security conference in 2014. A researcher decides to experiment with home smart devices and discloses the hackability of popular brand devices as being ripe targets for hackers.
Now there’s killware to take into account, and aside from the hacker related attacks that have put lives at stake, the hypothetical scenarios that will ever continue to roll out as if cybercriminals do and will aspire to commit these sorts of crimes seemingly exist as a form of parody and might be better suited in a novel or television show.
"Tomorrow's Cyberattacks"
Nevertheless, now we know how to hack cars, pacemakers, insulin pumps, and Garrett Walk-through metal detectors. If it wasn't for researchers, hackers might have never found out that they can now ping Apple and Tesla servers to test for Log4j vulnerabilities simply by altering the device name of an Apple iPhone or Tesla to a particular exploit string.
After all, if it wasn’t for the public disclosure of the Log4j vulnerability, it could be said that virtually no one would have jumped to the occasion, and companies whose software was impacted by the bug could have fixed it without inadvertently escalating the risk factor.
After all, it was a newspaper article way back in the day when I started my journey as a hacker, which taught me everything I needed to know about voice mailbox hacking. It explained which mobile phone carriers were susceptible to caller ID spoofing. It explained which service I could use to spoof my caller ID and the exact method for gaining access.
Perhaps it is time for the industry to begin to collaborate and strive to develop a secure solution for discussing sensitive cybersecurity events, with policies aimed at protecting the integrity of sensitive security matters in order to mitigate any possible escalation from threat actors.
Without a policy, it seems this same pattern will ensue, where threat actors multiply their efforts when new sensitive information is publicly disclosed, which puts everyone at risk.
The security disclosures by researchers today will become tomorrow's cyberattacks.
An article by
Jesse McGraw
Edited by
Ana Alexandre
Like this content? Subscribe to our newsletter to get weekly cybersecurity insights and top news - straight to your mailbox!
Comments