Data suggests that a staggering 99% of successful cyber-attacks exploit vulnerabilities that have been on the radar of cybersecurity professionals for at least a year.
As we move towards rapid digital transformation, we have 2 million+ apps available for downloads, and we write more than 111 billion lines of software code each year.
The speed at which new apps, software, and websites are created is generating a massive increase in the number of vulnerabilities available for attackers to exploit. Many of these vulnerabilities cannot be immediately remediated/ fixed.
This is precisely where virtual patching steps in, offering a crucial defense mechanism against potential exploits.
What is Virtual Patching?
Virtual patching is a security practice that employs fixes for vulnerabilities in a software system or application, without modifying the source code or making permanent changes.
Virtual patching protects a system from potential exploits while allowing organizations more time to develop and deploy proper, tested patches.
This technique is particularly useful when immediate patching is not feasible, such as when a vendor has not yet released an official patch or when applying a patch might disrupt critical business operations.
Virtual patching is often implemented through security measures at the network perimeter, such as IPS or WAFs. These security solutions can analyze incoming traffic, detect and block attempts to exploit vulnerabilities and provide a layer of defense until a permanent patch can be applied.
Virtual Patching Example:
The video demonstrates Indusface’s managed service team’s rapid response to a reported zero-day vulnerability in the Spring Framework. They promptly addressed the Spring4Shell Remote Code Execution (RCE) flaw by creating a custom rule for zero-day virtual patching, accomplishing this within a 24-hour timeframe.
How Does Virtual Patching Work?
Here is a systematic methodology that involves virtual patching best practices:
- Preparation
- Identification
- Analysis
- Virtual Patch Creation
- Implementation and Testing
- Recovery and Follow-up
Let’s take our previous example, Spring4Shell Vulnerability:
This zero-day vulnerability is assigned as CVE-2022-22965 and poses a critical unauthenticated Remote Code Execution (RCE) threat within the widely adopted Spring Framework, a prominent Java-based web application framework. The flaw is also known as SpringShell.
CVE-2022-22965 targets applications utilizing an Apache Tomcat server, especially those deployed as web application archives (WAR).
Preparation: Understanding the Landscape
Before delving into how to implement virtual patching, it’s vital to have a clear understanding of your system’s landscape. Conduct a comprehensive inventory of assets, applications, and potential vulnerabilities. To anticipate potential risks, stay abreast of the latest security advisories and threat intelligence.
For instance, in the case of Spring4Shell (CVE-2022-22965), by exploiting routing functionality, Spring4Shell injects user-controlled values into the diverse properties of Spring’s ClassLoader. This manipulation enables unauthorized access to local resources, facilitating RCE.
Certain Java-based applications leveraging the Spring library could be at risk of CVE-2022-22965. Identify areas where the Spring Framework is utilized, paying specific attention to versions susceptible to the vulnerability.
The versions 5.3.0 to 3.5.17, 5.2.0 to 5.2.19, and older versions no longer supported are vulnerable to this zero-day attack.
Identification: Spotting the Weak Links
The identification phase involves actively seeking vulnerabilities in your system. Regular security assessments, penetration testing, and continuous monitoring play a crucial role in recognizing potential points of exploitation.
The DAST Scanner within AppTrana WAAP monitors an organization’s overall security posture. It provides real-time insights into organizational risk by continuously identifying vulnerabilities, intelligently prioritizing them, and facilitating seamless remediation.
Users can leverage the actionable threat reporting dashboard to search for CVE-2022-22965 and identify potential weak links.
Analysis: Digging Deeper
Once vulnerabilities are identified, a thorough analysis is essential. Understand the potential impact of each vulnerability on your system’s confidentiality, integrity, and availability. Consider the context of your organization’s unique environment and business processes. This analysis lays the foundation for informed decision-making in subsequent phases.
In the context of the Spring4Shell vulnerability, if an application is susceptible, a malicious actor could potentially exploit it to gain unauthorized access to internal data, including databases.
If the vulnerable system is a critical database server, the risk of data exfiltration might be higher. This could further escalate into internal networks, allowing unauthorized access to valuable assets.
Virtual Patch Creation: Crafting a Shield
With a clear understanding of vulnerabilities and their potential impact, create virtual patches. Develop rules or signatures that can intercept and neutralize the malicious activity associated with these vulnerabilities. Collaborate closely with security experts and engage in threat intelligence sharing to enhance the effectiveness of your virtual patches.
As the Spring Framework is susceptible to the ClassLoader Manipulation, potentially leading to the RCE, we have created a WAF rule to block any malicious traffic attempting to exploit Spring4Shell vulnerabilities.
Rule: Block Spring4Shell Exploit
- Condition: Request contains a classloader function
- Action: Block the request and log the incident
In scenarios where the classloader function isn’t commonly accessed remotely, our rule springs into action, blocking requests containing the classloader function from reaching the application while logging crucial information for later analysis.
Implementation/Testing: A Vital Run-through
Conduct thorough testing in a controlled setting before deploying virtual patches in a live environment. Simulate real-world scenarios to ensure that the virtual patches effectively mitigate the identified vulnerabilities without causing disruptions to normal operations.
It’s essential to assess and address potential false positives during testing. This might involve refining the criteria for identifying classloader manipulation exploitation attempts to distinguish between malicious and normal activities.
Now, consider a specific use case for this zero-day virtual patching: Let’s say there’s a legitimate reason for calling this code from a particular remote server. In such cases, we employ a whitelisting mechanism for that specific IP, allowing exceptions for uncommon requests while maintaining strict blocking measures for common requests.
This approach ensures a virtual patching deployment with surgical accuracy tailored to the application’s specific needs rather than blindly blocking entire categories of requests.
Regularly revisit and update these patches as new threats emerge. If your organization lacks in-house security experts to write rules and manage them for false positives, opt for a WAAP solution that integrates virtual patching support seamlessly.
Recovery/Follow-Up: Continuous Improvement
Post virtual patching implementation, closely monitor the performance of your virtual fixes. Track the effectiveness of each rule and adjust as necessary. Establish clear communication channels between security teams, system administrators, and other relevant stakeholders. Treat this security strategy as an ongoing process rather than a one-time fix.
Why is Virtual Patching Important?
Common questions that arise are:
Why not just fix the code ? Is it that difficult to fix the code or release a patch?
In fact, it is. Data suggests that it takes anywhere between 50 and 140 days to fix/ remediate even critical and high-risk vulnerabilities. Leaving vulnerabilities unprotected for such a long time is like serving the attackers with the opportunity to attack the website/ application on a golden platter.
There are also other reasons why vulnerabilities cannot be fixed/ remediated immediately:
- The client or customer may lack the ability to fix the source code; developers must be the ones to address the coding issues. This becomes particularly evident when coding is outsourced, or organizations utilize third-party software or services.
- Vendors might not have an immediate patch or update ready when a vulnerability is disclosed, leading to longer waiting times for official releases.
- Not all vulnerabilities can be fixed owing to budgetary and financial constraints. There are a myriad number of vulnerabilities, and fixing all of them would be a big financial burden. So, organizations tend to prioritize and fix the critical and high-risk vulnerabilities first.
- The organization could use a legacy code or a product whose vendor is out of business, translating into no fixes or patches. Upgrading/ migrating from legacy systems or applications may be costly and time-consuming, and organizations cannot afford the disruptions from such a process.
In addressing these challenges, the choice between virtual patching vs. patching becomes paramount. Virtual patching shields the vulnerabilities externally and protects the application/ website from attacks, giving organizations and developers time to fix the vulnerability. Here are key distinctions:
Virtual Patching vs. Patching
| Virtual Patching | Traditional Patching | |
| Implementation | Implemented at various points in the network, such as firewalls or intrusion prevention systems. | It involves updating the actual software on the affected systems. |
| Flexibility | It offers more flexibility as it can be implemented quickly without downtime, providing greater adaptability to emerging threats. | It may require coordination and planning for scheduled maintenance windows, impacting operational flexibility. |
| Risk Management | Addresses immediate threats but doesn’t eliminate the root cause, requiring ongoing risk management to monitor. | Provides a comprehensive and permanent solution. |
| Dependency on Vendor | Offers independence from vendor release cycles. | Relies on software vendors to release and distribute official patches. |
| Adaptability to Zero-Day Threats | Offers a rapid response to zero-day threats by deploying rules to block known attack vectors, providing protection before official patches are released. | It relies on vendor response time and may be less effective against zero-day vulnerabilities until an official patch is available. |
Other Virtual Patching Benefits:
- Zero Downtime and Continuous Operation – Organizations do not face downtimes and can have their mission-critical components online while developing a fix or a permanent patch.
- Scalability and Resource Efficiency -One of the key virtual patching advantages lies in its resource-efficient deployment. It is scalable as it does not have to be installed on all hosts and can be implemented from a few locations, contributing to resource optimization and ease of management.
- Time, Cost, and Effort Savings for Low-Risk Vulnerabilities – In the case of low-risk vulnerabilities, virtual patching offers a practical and cost-effective solution without the need for extensive resources.
- Maintenance of Normal Patching Cycles– Virtual patching enables organizations to maintain normal patching cycles without disruptions. This consistency ensures security measures align with established schedules, enhancing overall system stability.
- Proactive Defense Posture – Virtual patching provides a valuable footprint of an attacker’s intent, offering insights into potential security threats. This data becomes a crucial point for organizations to improve their defense posture for the future proactively. Actions such as blocking users permanently or blocking specific IP addresses can be informed by this footprint.
Uncover insights in our whitepaper on integrating virtual patching as a fundamental element to enhance protection and gather real intelligence.
Downsides of Virtual Patching
- Latency Due to WAF Rule Complexity – Since the vulnerabilities are virtually patched using WAF rules, depending on the complexity of the rule, there may be a latency of a couple of milliseconds. So once the patch is done on the code, make sure to disable the rule on the WAF to mitigate this virtual patching disadvantage.
- False Positives – As with any rule on the WAF, false positives can occur. So, make sure that you test the application for false positives once you apply a rule. This is particularly addressed through managed services for virtual patching. With bundled managed services on AppTrana, our security experts do extensive false-positive testing for any virtual patch they write.
Conclusion
In today’s dynamic environment, where keeping up with growing numbers of vulnerabilities is challenging, virtual patching is a lifesaver. However, it is important to remember that these are emergency solutions to reduce risk, not actual ones. Virtual patching needs to be part of a comprehensive and managed security solution such as AppTrana to ensure a robust security posture.
