Design Vulnerabilities: They Hide and You can’t Catch Them
June 13, 2016
Shah Sheikh (1294 articles)

Design Vulnerabilities: They Hide and You can’t Catch Them

Exploiting memory-corruption bugs to compromise computers and gain access to organizations is all too common and relatively simple. But what we haven’t heard much about are so-called design vulnerabilities in operating systems or other software that can provide other avenues of attack into an organization’s network.

Unlike memory-corruption bugs, they are typically more complicated to patch. Furthermore, security tools that look for the exploitation of vulnerabilities cannot always address these types of vulnerabilities.

Design vulnerabilities or “logic flaws” aren’t your typical security flaws or bugs. They are legitimate functions or features with unintended consequences that attackers seek out to exploit. By leveraging logic flaws in the functionality of existing systems, attackers are able to masquerade as legitimate operations and code, and thus evade detection by security solutions.

Design vulnerabilities are common to all operating environments. Attackers can exploit them to gain root access to highly secure systems, leading to data theft, disruption of critical infrastructure and other serious consequences. They also cannot be easily detected and typical anti-exploitation tools will fail to prevent them.

The fact that they are designed as part of legitimate functionality makes fixing them all the more difficult and cumbersome. In fact, it’s not unusual to see a “recall” on a fix for a certain design vulnerability in order to patch the so-called fix itself.

Take for example the Stuxnet .LNK vulnerability, which allowed an attacker to run code using a malicious .LNK file. This was the vulnerability Stuxnet used to infect the machinery of the Iranian nuclear program. Microsoft patched the .LNK vulnerability back in 2010, or so they thought. In 2015, Michael Heerklotz, a German student, found a way to bypass the fix resulting in CVE-2015-0096.

There are other attacks that were enabled by design vulnerabilities. In 2014, attackers exploited a design vulnerability called Shellshock to infect thousands of machines with malware. During that same year, the infamous Sandworm attack leveraged a design vulnerability in Office for its cyber-espionage campaign. Another such vulnerability, dubbedRootpipe, enabled user privilege escalation in OS X systems. There was even a design flaw installed by default as a component in Trend Micro’s PasswordManager.

These are just a few of the more well-known design vulnerabilities — there are many others – and they are dangerous. Because they exploit legitimate functionality, security systems often won’t catch attacks exploiting the flaws until it’s too late. There is no stopping design vulnerabilities, and undoubtedly, threat actors will continue to exploit them.

To deal with sophisticated cyber-threats, we need to assume that the threat actors are within. Several measures that organizations typically take to defeat against the cyber-attackers include:

1.      Segmenting the network.
The idea here is to block off communications from a threat actor to prevent lateral movement, or, in extreme cases, create air-gapped networks (networks that aren’t connected to the Internet). As such, a threat actor residing on one device isn’t able to move to another device on another network segment. In essence, the threat is contained to a single network segment. One of the downsides? Segmenting the network won’t help in cases of ransomware where the malware can block access to the computers on the network segment it resides on.

2.      Detecting the threat

Several technologies now offer threat detection solutions – whether via user or network behavior analytics or even through deception. Unfortunately, these measures are utilized too late in the race against the breach. For example, a threat actor’s goal may be to retrieve sensitive documents from a CEO’s device. In such a case where a threat actor is first detected on a CEO’s device, these measures become futile.

3.      Full Application Whitelisting
This measure prevents the introduction of malicious code into the system by allowing only a single pre-defined set of applications to run on the computer. Unfortunately, IT and security administrators quickly run into manageability issues trying to control all applications required by the organization, leading to limited deployment.

In summary, to counter design vulnerabilities, the benefits of each approach must be weighed, with a focus on preventative measures and diminishing the disadvantages of each measure.

For instance, although whitelisting the applications becomes a tedious process, it is possible to minimize the scope to what is really important – those applications that communicate outbound.

Once the scope of the threat has been reduced, it is possible to then block the malicious outgoing connections of those business-authorized applications. Similarly, it is possible to deal with ransomware by blocking malicious file handling processes.

Source | Infosecurity-Magazine