New vulnerabilities are announced frequently that “break” the Internet infrastructure, web applications, or APIs (application programming interfaces). These are recorded as a vulnerability in the Common Vulnerabilities Enumeration database, which is a listing of vulnerabilities, what software versions are vulnerable to them, t
heir mitigation steps, and a score for criticality, or how much damage can it cause. This database is used by various security teams to stay up to date on the latest vulnerabilities and their mitigations.
Some of the more notable application vulnerabilities and CVEs include the following:
Heartbleed (CVE-2014-0160)
Shellshock (CVE-2014-6271)
Log4J (CVE-2021-44228)
MoveIT (CVE-2023-34362)
The patching cycle.
The vulnerability management community divides the processes into several types:
- Responsible disclosure is the process of reporting the vulnerability to the software maintainers, who are then given time to develop a patch or workaround.
- Full disclosure is the process of posting the vulnerability and Proof of Concept code in public or at a conference. This happens when the discoverer wants to
- Zero-day vulnerabilities are vulnerabilities that are previously unknown before they are used in an attack. Zero-day vulnerabilities rapidly escalate the impact and criticality of the vulnerability but also the timeline to mitigate.
The CVE lifecycle has a loosely defined process:
- The vulnerability is discovered and possibly made public. Sometimes the vulnerability is kept secret if it impacts a large amount of critical infrastructure or if the discovering organization wants to use the vulnerability to attack targets.
- If the vulnerability is found in critical infrastructure, trust communities are created to mitigate the vulnerability for software maintainers and major infrastructure providers.
- Proof of Concept code is created and either released publicly or used privately. This is a watershed event, as exploit code and tools allow attackers to use the vulnerability to compromise systems.
- The vulnerability is announced publicly as a CVE entry. This is where most organizations learn about the vulnerability. CVE serves as the system of record to hold information such as impacted software versions and vendors.
- CISOs and their staff perform asset discovery to determine where the vulnerability exists in their enterprise and what the impact to the business is. This might involve infrastructure vulnerability scanning, source code analysis, operating system data-gathering and policy agents, or aggregation of Software Bill of Materials information.
- A patch, workaround, or is released. This might be as simple as a change in a configuration file or a firewall rule. This might also be complex and require modifications to source code and redeployment to production.
- Information security and IT staff deploy patches to update their applications and infrastructure. They then monitor their environment to find unmanaged or unknown devices.
A critical web application CVE case study using Log4J.
In 2021, a critical vulnerability was announced, reporting a vulnerability in the popular Apache Log4j logging system that could allow arbitrary code execution on unpatched systems. Log4j is a popular logging utility, so the impact was on many vulnerable systems. Additionally, Log4j is used in a lot of other software, which inherits any vulnerabilities inside Log4j as an upstream dependency.
The news of the CVE sent many CISOs, security teams, and applications teams around the globe into a frenzy of activity. Overnight, they all had to become experts on Log4j development intricacies, Software Bill of Materials (SBOM), and Software Composition Analysis (SCA) solutions. They took inventory of their internet-facing systems, checked for uses of Log4j, checked revision levels, and put into effect their emergency patching processes. Many organizations took the appropriate proactive step of reaching out to business partners and vendors to assess the potential exposures existing in their supply chain.
The timing of the announcement of this threat came at a challenging time. Most organizations found out about the exposure on Friday, December 10th, a Friday during the peak holiday season when many people are taking personal time off, and networks and applications are entering change moratoriums. This makes timely remediation extremely difficult.
The good news is that for companies that had a cloud-based Web Application Firewall (WAF) solution, there was a quick and easy response to the unexpected and sudden CVE disclosure: virtual patching.
Understanding virtual patching.
Virtual patching is a capability of WAF solutions that will block any attempts to discover or exploit a vulnerability.
WAF solutions are deployed inline in front of web application servers and act as reverse proxies between the clients of the application and the authoritative applications servers, what people call a “backend” or “origin”. The WAF terminates the network connection with the client (including Transport Layer Security (TLS) if it is enabled), inspects the HTTP request to ensure that the client is not performing any malicious actions, and then creates a separate connection to the backend to forward the request. This allows a WAF the ability to deploy protections against classes of attacks such as SQL injection or Cross-Site Scripting, or to protect against a specific CVE with a signature.
When a new CVE is published, the WAF Cyber Threat Intelligence Team crafts a signature specific for that vulnerability and publishes it to the WAF’s update system. WAF administrators can then enable the signature, and the WAF will look for HTTP requests that attempt to discover or exploit the vulnerability and block that traffic. IT and security teams can easily turn on virtual patching for a specific vulnerability as soon as the signature is published, and this will protect all the servers behind the WAF until the team can patch them. This reduces the urgency and operational impact of newly discovered CVEs. Many WAF vendors receive advanced notice of a pending CVE through working groups formed during responsible disclosure. This allows them to craft a signature that is available as soon as the vulnerability is announced.
In addition to signatures for point vulnerabilities, WAFs also have countermeasures for broad categories of vulnerabilities. In some cases, this might block a vulnerability proactively and before it is discovered. IE, if a newly discovered CVE is a command execution vulnerability and you have the command injection countermeasure enabled, you could be protected already and do not need to enable the specific signature for that vulnerability.
Benefits of virtual patching include the following:
- Temporarily blocking vulnerabilities across all web applications to give your security and application teams time while you do asset discovery and triage to develop a plan.
- Blocking the vulnerability for a medium period (for example, 60-120 days) to fully test patches before they are deployed.
- Detecting and dropping exploit attempts for a longer time (for example, 180 days) to re-architecture or recode applications.
- As a temporary stopgap during a busy business cycle like the peak shopping season or holiday season to work within a change freeze or to reduce the labor demands of CVE response.
- Masking vulnerabilities long-term for applications where you are unable to patch them because the developers are not available.
- Gathering threat intelligence on endpoints that are actively scanning for application vulnerabilities.
- Blocking large classes of vulnerabilities to reduce the impact of specific point vulnerabilities requiring a specific signature.
Virtual Patching with Vercara UltraWAF.
Going back to our Log4j case study, Vercara’s cloud-based UltraWAF had a signature available shortly after the vulnerability was announced. Security teams and application owners using UltraWAF received a notification of the new signature available inside the UltraWAF portal. Protecting their web applications and supporting servers was as simple as logging into the portal, searching for the signature by CVE, and applying it with a BLOCK action. UltraWAF is fully hosted in the Vercara cloud and can ubiquitously protect assets deployed on-premises, in the cloud, in multi-cloud, or in hybrid environments, making it an easy option to gain comprehensive protection.
You can find more information about how UltraWAF can help protect your internet-facing web applications here. To speak to a Vercara UltraWAF Expert, please contact us.
Figure 1: CVE-2021044228 in the UltraWAF portal
