Sealing the Patch Gap

Autore: David Asraf, Software Developer at Vicarius

Condividi    

“Patch Tuesday” is a term widely used between IT and security teams to describe the time when Microsoft releases the latest updates. The ones who participate in it know the true cost of the patching cycle, whether it’s getting the approval, designing the plan, or dealing with the outcome.

Not all patches are related to security, but the ones that are usually trigger a patching cycle. How do security patches emerge? And why so frequently?

The increase in vulnerabilities and new techniques to identify security issues at scale result in an increase of security patches vendors are forced to release. A responsible disclosure process was designed to ensure vendors get a chance to fix the issue before hackers take advantage of it. A security researcher who unveiled a flaw could report it to the vendor before it’s misused.

Once reported, the vendor needs to validate the flaw (usually by reproducing it), identify the insecure code, fix it, and release a new and (hopefully) secure update. This secure update—aka patch—needs to be deployed wherever the vulnerable version resides.

While some vendors respond quickly to disclosed threats, others show delayed response and even retire some of their versions and claim they are no longer maintained. Assuming the vendor is responsible, and the version is maintained, the average time to patch is estimated to last between 2 to 5 months. This gap leaves companies exposed to known vulnerabilities.

Throughout this blog, we’ll explore various ways to close this exposure and reduce the risk of exploitation.

Pre-release

Development guidelines

There are many ways a vendor can make its software more secure. Following simple guidelines in the development process can help. When the software interacts with the world, all external input should be validated. Checking that the received input matches the expected input pattern can limit the amount of attacks that exploit inner issues in the software. Extensive testing of the product in various scenarios can detect issues that do not appear at first glance. Using static code analysis can provide an input pointing to problematic areas in the code. When using external libraries, it’s important to use proven and trusted libraries, and it’s even more important if it’s used for cryptography.

Secured compilation

An area that vendors can focus on is the compilation process. For example, exploits that are abusing stack overflow could potentially be prevented using stack canaries. Another example is blocking exploits that are based on modifying the global offset table (GOT) with the enabling of RELRO. When RELRO is enabled, all of the entries in the GOT are resolved at the start of the application. From there, the GOT is set to be read-only instead of the default lazy population of the GOT. Even though these security features can be easily added, many vendors still choose not to enable them during compilation.

Post-release

Even if a vendor followed the secure development guidelines and enabled all of the security features during compilation, it does not guarantee that the software is secure. New vulnerabilities are discovered every day, and new techniques to attack digital assets are always found in an endless battle between attackers and defenders.

When a new vulnerability is discovered and reported back to the vendor, the patch cycle (as described before) begins. But it is much too long. While we wait for a patch to be released, we are exposed to attacks exploiting this vulnerability. In many environments, it’s not possible to patch all of the products right when the vendor releases it due to business considerations. Still, we can’t afford to leave these environments vulnerable.

What can be done? Let’s review some new ways to protect our environments from exploits.

Network protection

Many companies route all of the incoming traffic through a stateful firewall, which sometimes is enhanced with IPS/DPI capabilities. One of their techniques is designed to recognize attack patterns and block them before they exploit the vulnerable asset. This kind of protection offers great value by preventing the attacker from unrestricted access. However, there are shortcomings. A missing pattern, a false positive, or a false negative identification may result in disruption of services to companies worldwide.

OS protection features

Another post-release option is to use the security features native to the operating system. Modern operating systems offer features for running applications under certain limitations. Under these limitations, even a successful exploit may be limited in gaining access to other resources in the asset or other devices in the network (e.g. insufficient permissions, process execution mode, etc.). Another tactic is to use ASLR to prevent an attacker from reliably knowing where exactly a specific resource is located in the memory of an application, thus making the application harder to exploit.

In-memory protection

There are security solutions that offer patches for specific vulnerabilities outside of the vendor’s development cycle. Instead of recompiling the binaries, the patch is injected into the vulnerable application, changing the behavior of it. After applying this kind of patch, the application will continue running, but it will no longer be vulnerable to that specific threat. The main advantages of this type of patch is that the patched application is protected without any permanent modifications, and there is no need to restart the application. On top of it, many patches include both security updates and new features, which may alter the application’s behavior and result in interoperability issues.

The same idea of injecting a patch into a running application also exists in a different set of security solutions. In these solutions, the application is analyzed, and a list of possible vulnerabilities and appropriate patches are generated and prioritized using various algorithms. The algorithms take into consideration the environment in which an application is running and create patches for exploitable vulnerabilities. Patches that aren’t needed are ignored. Only the minimal changes required for making the applications secure are implemented. In addition, the research and knowledge that was acquired for one vulnerability type is automatically transferred to other applications with similar characteristics, thus offering protection to some vulnerabilities before they are publicly known.

Staying ahead of the curve

Statistics show 60% of breaches that were related to vulnerabilities could have been prevented with the appropriate patch. But security teams have difficulties keeping track of the important ones. Add to that the stress of downtime and causing outages. Patching is no picnic. It’s a heavy load to bear.

A new generation of technologies has emerged from the Vicarius lab to prevent exploitation without changing the binaries on the disk. TOPIA applies in-memory virtual patches that mitigate exploitation. Once the system administrator defines a policy, the vulnerable application is protected on the memory level, both externally and internally. It harnesses various memory protection techniques, including Dynamic Binary Instrumentation (DBI).

Based on the defined policy, when an exploitation attempt triggers one of the protection layers, the relevant layer will either log or prevent it. The protection mechanism blocks the malicious system call, stopping the exploitation attempt.

In the dashboard, the system administrator can review the attempt, origin, target, and other information that can be useful for further investigation.

Go ahead, lighten your load. You don’t need to bear that patching burden alone.

Roi and David join Paul for a live discussion and demo! Featuring The Patchless Horseman.

 

You can read the original article in Vicarius website.