A CISO recently told me “If the NSA [or other nation-state supported organization] wants to hack me, they will. If a 16-year-old hacks me using a known exploit, I’ll lose my job.”
The news is filled with stories on what we assume are targeted attacks. The victimized organizations include Sony, the Office of Personnel Management, Adobe and Home Depot. These occur when an adversary preselects a victim (target) with a specific goal. We often think of these as attempts to steal data (credit card data, health information, company secrets and even personal information from fishing licenses). However, the attacker’s goal can also be service disruption in critical infrastructure, or business disruption (particularly in cases of “hacktivism”).
Targeted attacks require planning. This usually includes a reconnaissance phase, where attackers learn all they can about the target’s IT stack and application layers, or profiles from social media such as Facebook and LinkedIn. Next the attacker may do further probing of the target’s perimeter to determine its security defenses. Once the attacker has identified specific weaknesses, the actual attack can commence against the perimeter, applications, individuals or the supply chain (as in the case of Target).
What many don’t realize is that our adversaries motivations are the same as legitimate businesses. The homework and preparation for a targeted attack obviously requires effort, time and money. In the case of targeted attacks, the attacker has determined that the “reward” is worth the effort. If there was a simpler, less costly method of achieving their goals, they would logically take that path.
This brings in another type of threat – non-targeted attacks. In this case, the attacker is less discriminate about whom he victimizes. The goal is to find and steal “something” of value that can be leveraged or sold on the dark web.
A perfect vehicle for non-targeted attacks is a known vulnerability in an application or commonly used component.
Every IT and security professional knows that applying vendor-supplied patches is both necessary and an operational problem. While Microsoft’s “Patch Tuesday” is well known and often anticipated (for planning purposes), other vendors release updates, point releases and security patches on an unpredictable schedule.
The volume of patches issued multiplied by the number of applications large organizations run makes this difficult to manage, and often expensive to implement across all devices. Studies show that even critical applications are often missed, either through improper prioritization, limited resources or lack of awareness. Need proof? The 2016 Verizon Data Breach Investigations Report found that “99.9% of the exploited vulnerabilities had been compromised more than a year after the associated CVE was published.”
Known vulnerabilities are not restricted to commercial applications, of course. Open source, which can comprise over 70% of an application, has its share of vulnerabilities as well. The difference with open source is that nobody is “pushing” updates or patches to the users of vulnerable open source components. You elect to use open source. Therefore you’re responsible for monitoring those components and applications for updates, vulnerabilities and patches.
The ubiquity of popular open source components and applications means that when a vulnerability is disclosed, it’s a target-rich environment for attackers. Rather than focus on a specific organization, some will (in the interest of economy) elect to run non-targeted attacks. In this scenario, an exploit for a commonly used component is run against a broad range of IP addresses. The initial goal is simply to identify those that are vulnerable to the exploit.
Once the attacker has an inventory of vulnerable locations, they can run reconnaissance to determine which organizations these represent, and which are worth the effort to continue the attack.
Non-targeted attacks exploit a weakness in software, but also a weakness in an organization’s defenses. Namely, awareness to the existence of vulnerable components in the applications organizations build and deploy. Simply maintaining an inventory of the open source in your applications, tracking them for new vulnerabilities and updating components when fixes are available reduces exposure to opportunistic, non-targeted attacks.
You might not be able to protect your organization from a determined, well-funded adversary. They have time and a variety of tools at their disposal. However, protecting yourself, and your job, from non-targeted attacks using public exploits is simpler, and should be part of every organization’s fundamental security program.