This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Virtual Patching Cheat Sheet
|
Last revision (mm/dd/yy): 09/11/2017
IntroductionThe goal with this cheat Sheet is to present a concise virtual patching framework that organizations can follow to maximize the timely implementation of mitigation protections. Definition: Virtual PatchingA security policy enforcement layer which prevents and reports the exploitation attempt of a known vulnerability. The virtual patch works when the security enforcement layer analyzes transactions and intercepts attacks in transit, so malicious traffic never reaches the web application. The resulting impact of virtual patching is that, while the actual source code of the application itself has not been modified, the exploitation attempt does not succeed. Why Not Just Fix the Code?From a purely technical perspective, the number one remediation strategy would be for an organization to correct the identified vulnerability within the source code of the web application. This concept is universally agreed upon by both web application security experts and system owners. Unfortunately, in real world business situations, there arise many scenarios where updating the source code of a web application is not easy such as:
The important point is this - Code level fixes and Virtual Patching are NOT mutually exclusive. They are processes that are executed by different team (OWASP Builders/Devs vs. OWASP Defenders/OpSec) and can be run in tandem. Value of Virtual PatchingThe two main goals of Virtual Patching are:
Virtual Patching ToolsNotice that the definition above did not list any specific tool as there are a number of different options that may be used for virtual patching efforts such as:
For example purposes, we will show virtual patching examples using the open source ModSecurity WAF tool - http://www.modsecurity.org/. A Virtual Patching MethodologyVirtual Patching, like most other security processes, is not something that should be approached haphazardly. Instead, a consistent, repeatable process should be followed that will provide the best chances of success. The following virtual patching workflow mimics the industry accepted practice for conducting IT Incident Response and consists of the following phases:
Example Public VulnerabilityLet's take the following SQL Injection vulnerability as our example for the remainder of the article - http://www.osvdb.org/show/osvdb/88856 88856 : WordPress Shopping Cart Plugin for WordPress /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php reqID Parameter SQL Injection Description: WordPress Shopping Cart Plugin for WordPress contains a flaw that may allow an attacker to carry out an SQL injection attack. The issue is due to the /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php script not properly sanitizing user-supplied input to the 'reqID' parameter. This may allow an attacker to inject or manipulate SQL queries in the back-end database, allowing for the manipulation or disclosure of arbitrary data. Preparation PhaseThe importance of properly utilizing the preparation phase with regards to virtual patching cannot be overstated. You need to do a number of things to setup the virtual patching processes and framework prior to actually having to deal with an identified vulnerability, or worse yet, react to a live web application intrusion. The point is that during a live compromise is not the ideal time to be proposing installation of a web application firewall and the concept of a virtual patch. Tension is high during real incidents and time is of the essence, so lay the foundation of virtual patching when the waters are calm and get everything in place and ready to go when an incident does occur. Here are a few critical items that should be addressed during the preparation phase:
Identification PhaseThe Identification Phase occurs when an organization becomes aware of a vulnerability within their web application. There are generally two different methods of identifying vulnerabilities: Proactive and Reactive. Proactive IdentificationThis occurs when an organization takes it upon themselves to assess their web security posture and conducts the following tasks:
Due to the fact that custom coded web applications are unique, these proactive identification tasks are extremely important as you are not able to rely upon 3rd party vulnerability notifications. Reactive IdentificationThere are three main reactive methods for identifying vulnerabilities:
Analysis PhaseHere are the recommended steps to start the analysis phase:
Virtual Patch Creation PhaseThe process of creating an accurate virtual patch is bound by two main tenants:
Care should be taken to attempt to minimize either of these two rules. It may not be possible to adhere 100% to each of these goals but remember that virtual patching is about Risk Reduction. It should be understood by business owners that while you are gaining the advantage of shortening the Time-to-Fix metric, you may not be implementing a complete fix for the flaw. Manual Virtual Patch CreationPositive Security (Whitelist) Virtual Patches (Recommended Solution)Positive security model (whitelist) is a comprehensive security mechanism that provides an independent input validation envelope to an application. The model specifies the characteristics of valid input (character set, length, etc…) and denies anything that does not conform. By defining rules for every parameter in every page in the application the application is protected by an additional security envelop independent from its code. Example Whitelist ModSecurity Virtual PatchIn order to create a whitelist virtual patch, you must be able to verify what the normal, expected input values are. If you have implemented proper audit logging as part of the Preparation Phase, then you should be able to review audit logs to identify the format of expected input types. In this case, the "reqID" parameter is supposed to only hold integer characters so we can use this virtual patch:
#
# Verify we only receive 1 parameter called "reqID"
#
SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter - Duplicate Parameters Names Seen.',logdata:'%{matched_var}'"
SecRule &ARGS:/reqID/ "!@eq 1"
#
# Verify reqID's payload only contains integers
#
SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:2,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'"
SecRule ARGS:/reqID/ "!@rx ^[0-9]+$"
This virtual patch will inspect the reqID parameter value on the specified page and prevent any characters other than integers as input.
Negative Security (Blacklist) Virtual PatchesA negative security model (blacklist) is based on a set of rules that detect specific known attacks rather than allow only valid traffic. Example Blacklist ModSecurity Virtual PatchHere is the example PoC code that was supplied by the public advisory - http://packetstormsecurity.com/files/119217/WordPress-Shopping-Cart-8.1.14-Shell-Upload-SQL-Injection.html: http://localhost/wordpress/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php?reqID=1' or 1='1 Looking at the payload, we can see that the attacker is inserting a single quote character and then adding additional SQL query logic to the end. Based on this data, we could disallow the single quote character like this:
SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'"
SecRule ARGS:/reqID/ "@pm '"
Which Method is Better for Virtual Patching – Positive or Negative Security?A virtual patch may employ either a positive or negative security model. Which one you decide to use depends on the situation and a few different considerations. For example, negative security rules can usually be implemented more quickly, however the possible evasions are more likely. Positive security rules, only the other hand, provides better protection however it is often a manual process and thus is not scalable and difficult to maintain for large/dynamic sites. While manual positive security rules for an entire site may not be feasible, a positive security model can be selectively employed when a vulnerability alert identifies a specific location with a problem. Beware of Exploit-Specific Virtual PatchesYou want to resist the urge to take the easy road and quickly create an exploit-specific virtual patch. For instance, if an authorized penetration test identified an XSS vulnerability on a page and used the following attack payload in the report: <script>alert('XSS Test')</script> It would not be wise to implement a virtual patch that simply blocks that exact payload. While it may provide some immediate protection, its long term value is significantly decreased. Automated Virtual Patch CreationManual patch creation may become unfeasible as the number of vulnerabilities grow and automated means may become necessary. If the vulnerabilities were identified using automated tools and an XML report is available, it is possible to leverage automated processes to auto-convert this vulnerability data into virtual patches for protection systems. Three examples include:
Implementation/Testing PhaseIn order to accurately test out the newly created virtual patches, it may be necessary to use an application other than a web browser. Some useful tools are:
Testing Steps
Recovery/Follow-Up Phase
ReferencesAuthors and Primary EditorsRyan Barnett (Main Author) Other Cheatsheets |
