Exploits that target vulnerabilities in widely used protocols and software libraries present a potent threat to organizations. These need special attention from developers and security testers.
The WannaCry ransomware, which took advantage of an implementation error in the Server Message Block (SMB) transport protocol used by Windows systems, is a recent example. Others include 2014's infamous Heartbleed bug in the OpenSSL cryptographic library, the GHOST vulnerability in the Linux GNU C Library (glibc), a flaw in SSL 3.0 that enabled the so-called POODLE attacks of 2014, and the Factoring Attack on RSA-EXPORT Key (FREAK) flaw in some SSL/TLS implementations.
Unlike application- and product-specific vulnerabilities, security flaws in popular communications, encryption, and proprietary protocols give threat actors a way to strike deep at the infrastructure layer, affecting a much broader swath of victims.
Such flaws can also affect multiple products and services at once. The Heartbleed bug, for instance, either directly or indirectly affected websites, networked appliances, client-side software, and online services that use the Transport Layer Security (TLS) protocol to identify and authenticate.
Securing against such vulnerabilities can be problematic. Many organizations have little idea of the protocols and shared libraries in their environment, let alone the vulnerabilities within them.
The growing enterprise use of open-source components has only made matters worse. By some estimates, 90% of a typical application used by enterprises consists of third-party components, including open source. A stunning 44% of those applications contain critical vulnerabilities in the open-source components.
But there are things you can do about it. Here are five approaches shared by security experts for fighting against source code-level attacks.
1. Maintain an inventory
With an inventory of all your libraries and protocols, you can quickly identify the applications that need attention when something goes wrong. The right tools can help to scan your organization's source code and firmware, identify all the protocols, open-source components, and libraries in them and map them to known vulnerabilities.
Software composition analysis can help organizations get a clear picture of their vulnerability exposure and what they need to patch or do to mitigate disruption when something happens.
Craig Young, a computer security researcher for Tripwire’s Vulnerability and Exposures Research Team (VERT), said:
"Decreasing an organization’s time to patch is one of the best approaches to minimizing exposure to new exploits."
This is not always easy, however, and is especially challenging when considering the number of software packages and networked appliances that bundle in or link to shared libraries such as OpenSSL and glibc, Young says.
In the wake of disclosures such as Heartbleed and the Ghost vulnerability in the Linux glibc library, many infosec teams were left in the tricky position of having to quickly identify all the places within their network where affected libraries were used.
"Ideally, this is something which should be done in advance so that, when advisories are released, the organization can avoid spending precious time finding vulnerable hosts and instead focus just on obtaining and deploying patches."
—Craig Young
This is especially important for software compiled from source rather than from a software distributions' package manager; or when using opaque network appliances, Young says.
2. Fuzz testing
Fuzzing is a term used to describe the structured process of sending deliberately malformed or unexpected input to software to see if it will trigger a crash or failure condition.
Fuzzing can help identify vulnerabilities and weaknesses in your software, including those caused by vulnerabilities in the protocols, shared libraries, and common file formats in your software, says Chris Clark, principal security engineer at Synopsys.
The Heartbleed vulnerability in Open SSL, for instance, was uncovered as the result of fuzz tests conducted by a Synopsys research team in Finland.
Fuzz tests can be especially useful in industries that use a lot of immature or untested protocols in their software, Clark says. A recent Synopsys analysis of data from fuzz tests that had been conducted by its customers in 2016, for instance, showed that operators of industrial control systems (ICSs) were at highest risk from insecure protocols. Many of the protocols used in ICS systems are niche protocols and are therefore relatively untested, the Synopsys analysis revealed. The same was true of protocols used in Internet of Things devices.
Just because you implement a protocol that adheres to a formal Internet Engineering Task Force (IETF) format—or RFC—does not mean it is secure, Clark says. Protocols can be implemented differently and have varying quality levels.
"Not all of them are created equal, so you need to make sure to validate the core functionality of any protocol."
—Chris Clark
3. Harden your systems
Despite all the care you might put into testing, there's always something you are going to miss or that a threat actor will be able to exploit. So harden your systems to the greatest extent possible, Young says.
For example, make sure that all exploit mitigations are enabled and that any features or services not being utilized by your applications are shut down or are disabled, Young says.
Similarly, make sure that all your binaries are using full address randomization and that they take advantage of operating system protections such as the SELinux kernel security module for access control and Microsoft's EMET (Enhanced Mitigation Experience Toolkit) security toolkit for Windows, Young says. EMET works with all supported Windows versions and is designed to mitigate exploits that attempt to take advantage of memory corruption flaws.
Consider compiling your software with control flow integrity or deploying tools such as Grsecurity’s RAP for added protection against code reuse attacks and return-oriented programming (ROP) exploit chains, Young says. "While it is not possible to ever guarantee 100% security on any reasonably complex system, these suggestions aim to raise the cost for attackers, and these technologies certainly do that,” he says.
4. Minimize your attack surface
Software packages often have dependencies on specific versions of other software. Make it a point to understand and document those dependencies and keep that information up to date, says Liam Crilly, director of product management at NGINX.
Many attacks leverage already-patched vulnerabilities, so you need to make sure your software dependencies are not leaving you open to attack, Crilly says. Follow all Common Vulnerabilities and Exposures notifications for your dependent products so you can apply patches in a timely manner, he says.
Be specific about which pieces of a particular protocol you need to use, Crilly says. For instance, if you develop and deploy products that use SSL/TLS to protect your web and VPN traffic, you need to know which specific SSL/TLS protocol versions and cipher suites to allow. Many widely used SSL/TLS versions have known vulnerabilities that require a specific configuration or workaround. While configuring SSL/TLS libraries, you need to be aware of these issues so you can know what versions to enable or disable.
Crilly seconds that it is vital for organizations to have a firm handle on the libraries and the protocols they are using.
"This requires developers to register components and libraries just as they might already do for FOSS license compliance."
Also consider offloading security workloads to a dedicated system. For instance, use a load balancer or a reverse proxy to handle SSL so that your application developers do not have to deal with it, Crilly says. "This gives you one place to patch, and a smaller list of what's in use."
5. Test, test, and test again
To minimize risk, test your products frequently, Clark says. A penetration test or vulnerability assessment can give you a snapshot of the security readiness of your environment at a single point in time.
But threat actors might discover a new vulnerability in something that you have already tested, or their ability to leverage a patched vulnerability might evolve. Also, the tools used for testing might get better over time, allowing you to find holes that you previously missed.
"You have to put a program in place that looks at a product and goes through the testing process in a cyclical manner."
—Chris Clark
When evaluating the security status of a product, do not assume anything. Often, protocols and libraries that you might think are safe and stable because they have been around for a long time are vulnerable. As one example, Clark points to the ModBUS proprietary serial communications protocol used in ICS equipment, which Synopsys' analysis showed was still vulnerable to certain attacks.
Said Tod Beardsley, research director at Rapid7:
"Testing defenses routinely through penetration testing, red teaming, and other offensive techniques also goes a long way toward making sure that detection and remediation strategies are current and practiced."
In addition to doing static analysis during the development stage, it is important for organizations to do dynamic analysis of the code in a production setting.
"Creating controlled security events in production helps to test the resiliency of network defenses that would otherwise only get exercised under truly disastrous circumstances."
—Tod Beardsley
Reliable sources
Ultimately, due diligence is key, says Clark. Vulnerabilities in your source code and in the protocols you use can expose you to serious risk. You need a multi-part strategy for mitigating those risks that begins with a thorough understanding of all the components in your software and network stack that you might have sourced externally.
You need to understand the risks posed by vulnerabilities in those components and have formal, top-down processes for ensuring that anything you use conforms to security requirements or has the necessary mitigations—such as patches—in place.
Have specific processes in place to ensure that all source code brought in from outside is fully tested and validated through the supply chain, and have testing measures in place to ensure that it remains that way throughout the application lifecycle.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
