When Hackers and Vendors Both Benefit, Your System May be the Biggest Loser
“If you see something, say something” is a catchphrase widely promoted by the U.S. Department of Homeland Security. In a similar vein, most “white hat” cyber engineers seem to be driven by a sense of social responsibility best expressed as, “If you find something, say something.”
Across the industry, the ethos is to share information quickly, whether the problem is a newly discovered exploit or an evolving cyber threat. The goal is to impel the affected vendor—hardware or software—to take quick action and produce a fix.
Disclosing too much, too soon
There are good and bad ways to make vulnerabilities known. A premature “full disclosure” of a previously unknown issue can unleash the forces of evil, and the “black hats” often move faster than vendors or enterprise IT teams.
One example is Mirai, a botnet that hit internet-connected devices in 2016. Originally, it was used in brute-force attacks targeted at embedded devices listening on Telnet. Then, Mirai source code was released to open-source communities, spawning copycat versions that aimed brute-force attacks at hardware listening via Secure Shell (SSH). To increase the rate of compromise, these attacks exploited a variety of flaws in weakly secured Internet-of-things (IoT) devices.
Today, Mirai derivatives remain a persistent and evolving threat to embedded Linux systems. Figure 1 shows a recent trend in the ongoing risk from this attack. As recently as June 2019 additional variants were reported.
Figure 1: First spotted in wild in 2016, Mirai saw another surge in activity during 2018. (Source: Ixia 2019 Security Report)
Buying time for preventive action
The preferred path is a “responsible” or “coordinated” disclosure that happens behind the scenes. Public announcements occur after a specified period of time—typically 90 or 120 days—thereby allowing the affected vendor to develop an effective patch or fix and make it available to its customers.
Drupalgeddon is a SQL injection vulnerability that targets the free, open-source Drupal content-management framework. In 2018, a researcher uncovered two similarly dangerous flaws dubbed Drupalgeddon 2 and 3, respectively. Variant 2 was responsibly disclosed: the researcher warned the development team, giving them time to create and issue a patch before the exploit details became public.
Once the patch was made available, the researcher released exploit information to the public on April 12 and 25, 2018. As shown in Figure 2, exploit attempts flared up in April and May 2018. Then, interest quickly faded, mainly because a fast patching process reduced the number of available targets.
Figure 2: After thousands of attacks in April and May 2018, Drupalgeddon 2 and 3 quickly subsided. (Source: Ixia 2019 Security Report)
Banding together for the common good
To facilitate info sharing, “open” and “closed” communities of cyber professionals have sprung up around the world. Many well-known open communities admit everyone, and black hats are certainly members. That’s why we see widespread spikes in hacking activity within a few days or weeks after a flaw is made public.
The safer choice is a closed community. Your in-house computer emergency readiness team (CERT) may already be connected to one or more trusted resources. If not, consider starting a closed community in your local area or region to serve the common good. For this to succeed, any potential members should be investigated and vetted before being granted entry.
Staying ready
Rumors continue to circulate about potentially devastating vulnerabilities in the IT world, in electronic voting systems, and beyond. Forewarned is forearmed, and a closed community of trusted peers can be the best way to gain time, reduce risk, and preempt the next wave of attacks.
Related: Zero-day Conundrum: Keep or Disclose Vulnerability Stockpiles?
Related: Responsible Disclosure – Critical for Security, Critical for Intelligence
