04:53 AM
Vincent Liu
Vincent Liu
Connect Directly

Fighting 0days With Fundamentals

How to pre-emptively secure systems against 0day attacks that, by definition, we know nothing about

What we propose is a “return to fundamentals” for defending against zero-day attacks. While you might argue that our approach isn’t groundbreaking, that is exactly the point. In an industry where tired and beaten technologies are continually being given makeovers and trotted out under a new banner, we believe that basic best practices are too often overlooked. In the context of 0day defense, the discussion of basic best practices is almost nonexistent. When compared to the abysmal failure of traditional 0day defenses, it’s worth repeating and reiterating the effectiveness of fundamental security controls.

The failure of traditional 0day protections, such as antivirus, anti-malware, and network IDS, stems from the fact that they are built around a lagging defensive model that depends on signatures. Using signatures is a lagging approach because in order to create a signature, one must have firsthand knowledge about the attack.

However, in the case of a 0day, firsthand knowledge usually only arrives after the initial wave of attacks has succeeded and overwhelmed the unprepared defenses. Only then can countermeasures be created and deployed (and enabled) on all the defensive tools. If this model seems reactive and unbalanced, that’s because it is. You’re trying to defend against attacks that you’ve never seen before and for which you have no signatures. You’re always playing catch up.

A close analogy in the real world is influenza. Over successive infections, the virus mutates into a new form that must be identified and analyzed before a vaccine can be created. After the mutation, the influenza virus is like a 0day because it has a new pattern that no immune system has previously encountered. So it easily infects thousands of people -- even those who had previously been inoculated -- before a vaccine can be created.

Lagging security controls are reactive, and, quite frankly, reacting is awful. Reacting means you’re chasing after an attack and playing clean-up instead of stopping it. Most product vendors would like you to think that the only defense against a 0day attack is to apply a patch or install a tool that utilizes signatures, but that’s not the case. As we discussed earlier, there are several environmental conditions that must first be met in order for a 0day to work successfully. Just like washing your hands and not touching your eyes, nose, or mouth helps you avoid catching the flu, you can proactively defend against most 0day attacks.

The first defensive technique is the reduction of your systems’ attack surface. This is the easiest and most impactful change and can be accomplished by simply turning off and removing server components that aren’t necessary. All too often, we see vulnerabilities being identified in esoteric modules or features of a product that are enabled by default but not required by the product’s core functionality. Disabling or removing these components means they can’t be a target even if they contain one or more serious vulnerabilities.

Applying strict firewall rules to minimize exposed ports and services is another way to reduce attack surface. If the attacker can’t reach the vulnerable service, then the game is over before it even started. Strict firewalling can’t be applied in all situations, such as for a Web server that must be exposed to the public. In many cases, however, your Web application doesn’t need to be exposed to the several billion IP addresses on the Internet. As an example, administrative Web interfaces can be quickly secured by permitting only a very specific set of trusted networks and IPs to access the interface. Applications designed for a limited audience, such as a B2B application, can also be secured by intelligent firewalling.

Proper configuration of existing security features is another way to defend against 0day attacks. Many pieces of software include security options that allow you to apply stronger authentication, authorization, or accounting features. Requiring a trusted certificate before allowing a communication channel to be established with the service is one way of enforcing stronger authentication and can also be used to secure the transmission medium. If an attacker can’t connect to the service, then it’s highly unlikely that they’ll be able to attack it.

Features such as URL authorization on Web servers pose another barrier that attackers must overcome to trigger their 0day attacks. Stronger accounting options, specifically detailed logging, should be enabled and rolled up into alerting engines to enable security teams to quickly identify attacks against a system. While this is technically a reactive measure, it allows security teams to be proactive in stopping subsequent attack attempts against the same system or neighboring systems. Attacks seldom work on the first attempt, so multiple rounds are usually required as hackers fine-tune their exploit to the target’s environment.

Finally, applying operating system-level security controls can prevent 0day attacks and mitigate the impact of any successful exploits. Patching the operating system software (and all other software) quickly is a best practice, but you can also take advantages of available system-wide configurations. In the spirit of least privilege, reducing admin access and only granting services the minimum set of privileges necessary will significantly reduce the impact of any attacks. Strong file system permissions will also stymie many local 0day attacks, but don’t overlook the use of application whitelisting, which also limits what an attacker is able to repurpose on a given operating system.

Individually, each of these techniques will make it difficult for an attacker to successfully exploit a 0day vulnerability. When properly combined, they can make it nearly impossible. Unfortunately, too much of today’s 0day defense is focused on the hype of the latest in a long line of marginally effective signature-based defensive tools.

The good news is that raising the bar could be easier than you think, and a proper defense against 0day attacks doesn’t have to involve trusting the inner workings of yet another black box security tool marketed as a one-size-fits-all silver bullet. Applying and layering effective defenses based on fundamental security principles is an immediately effective strategy and will continue to be for generation after generation of 0day vulnerabilities. Doing so will break the chain of weaknesses needed for a successful compromise, thereby securing your environment from even the most deadly attacks known -- or as it happens, unknown.

Vincent Liu, CISSP, is a Managing Partner at Stach & Liu, a security consulting firm providing IT security services to the Fortune 1000 and global financial institutions, as well as U.S. and foreign governments. He has coauthored several books including Hacking Exposed Wireless, 1st and 2nd editions, Hacking Exposed Web Applications, 3rd edition, and the upcoming Web Application Security, A Beginner's Guide. Vincent Liu (CISSP) is a Managing Partner at Stach & Liu, a security consulting firm providing services to the Fortune 500, global financial institutions, and high-tech startups. In this role, he oversees firm strategy, practice development, and client matters. Vincent is ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2014-07-11
Dahua DVR 2.608.0000.0 and 2.608.GV00.0 allows remote attackers to bypass authentication and obtain sensitive information including user credentials, change user passwords, clear log files, and perform other actions via a request to TCP port 37777.

Published: 2014-07-11
Cumin (aka MRG Management Console), as used in Red Hat Enterprise MRG 2.5, does not include the HTTPOnly flag in a Set-Cookie header for the session cookie, which makes it easier for remote attackers to obtain potentially sensitive information via script access to this cookie.

Published: 2014-07-11
The REST API in the ovirt-engine in oVirt, as used in Red Hat Enterprise Virtualization (rhevm) 3.4, allows remote authenticated users to read arbitrary files and have other unspecified impact via unknown vectors, related to an XML External Entity (XXE) issue.

Published: 2014-07-11
Docker 1.0.0 uses world-readable and world-writable permissions on the management socket, which allows local users to gain privileges via unspecified vectors.

Published: 2014-07-11
Apache Syncope 1.1.x before 1.1.8 uses weak random values to generate passwords, which makes it easier for remote attackers to guess the password via a brute force attack.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.