Preparation Phase
The significance of adequately utilizing the preparation phase in respect of virtual patching can’t be overstated. Before dealing with a discovered vulnerability, or respond to a live web application intrusion, you have to take some actions to set up the virtual patching processes and frameworks. It is not the perfect time to be proposing the installation of a WAF or the concept of a virtual patch during the real-time compromise. 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. During real incidents, the tension is high and time is of the essence. Lay the base of virtual patching when everything is good enough and ready to take action if an issue occurs.
During the preparation phase, some critical items that need to be addressed are given below:
(a) Public/Vendor Vulnerability Monitoring
Make sure that every list of vendor alert mail has been signed up for commercial software that you are using. This will help you to get notified if the vendor releases a piece of new vulnerability information or patching of data.
(b) Virtual Patching Pre-Authorization
The Virtual Patch has to be deployed immediately so the normal processes and authorization steps for the standard patch need to be expedited. The virtual patches do not need regression testing as the same amount as normal software patches, because the source code is not getting altered here. Classifying virtual patches, Anti-Virus updates, Network IDS signatures in the same group ensure to speed up the authorization process and minimize extended testing phases.
(c) Deploy Virtual Patching Tool In Advance
At the peak time in incident response, it could be a bad time to have to get permission for new software installation. The advantage of deploying WAF in embedded mode in the Apache server is that it can create fixes for non-Apache back-end servers also.
(d) Increase HTTP Audit Logging
The standard Common Log Format (CLF) utilized by most web servers does not provide adequate data for conducting proper incident response. You need to have access to the following HTTP data:
(i) Request URI (including QUERY_STRING)
(ii) Full Request Headers (including Cookies)
(iii)Full Request Body (POST payload)
(iv) Full Response Headers
(v) Full Response Body
Consider the following Apache access_log entry:
80.87.72.6 – – [22/Apr/2007:18:55:53 –0400] \ “POST /xmlrpc.php HTTP/1.1” 200 293
Here the request used a POST Request Method, which means that critical data such as the Request Body (where the client is passing parameter data) is not logged. It is impossible to precisely verify an intrude attempt or a successful compromise, without the full request payloads. Prophaze WAF has a robust logging engine for auditing which is capable of capturing the entire payloads, for request and response.
The following audit log entry is for the same xmlrpc.php request we showed from the Apache access_log file.
–ddb9bf17-A– [22/Apr/2007:18:55:53 –0400] dGgsYX8AAAEAABJkpY8AAACG 80.87.72.6 41376 192.168.1.133 80 –ddb9bf17-B– POST /xmlrpc.php HTTP/1.1 TE: deflate,gzip;q=0.3 Connection: TE, close Host: www.example.com User-Agent: libwww-perl/5.805 Content-Length: 201 –ddb9bf17-C–
<?xml version=”1.0”?>
test.method’,”));echo’_begin_’;echo \`id;ls/;w\`;echo ‘_end_’;exit;/\*</param>
Here, from the request body contents, we can see that the client is making an effort to exploit the application and is trying to execute OS command injection
Identification Phase
Whenever an organization comes conscious of a vulnerability within its web application, then the Identification Phase takes place. Vulnerabilities can be identified using two methods: Proactive and Reactive
Proactive Identification
If an organization can handle themselves to assess their web security posture and conducts the following tasks, such identifications are said to be Proactive.
(a) Dynamic Application Assessments –
Simply we can say, internal or external Vulnerability assessment and penetration tests. That is, Whitehat attackers or ethical hackers perform penetration tests or automated web assessment tools are run against the live web application to determine security bugs.
(b) Source code review
This task is very crucial for custom-coded web applications. Since these applications are unique and there would be an external entity that has the same application code. To inspect the web application’s source code, ethical hackers use manual or automated means to determine the security flaws.
Reactive Identification
The three main reactive methods for identifying vulnerabilities are:
(a) Vendor contact (e.g. pre-warning)
Happens when a vendor discloses a vulnerability for commercial web application software that you are using.
(b) Public disclosure
Disclosure of Public vulnerability for commercial or open-source web application software that you are using. The public disclosure threat level rises as many people know about the vulnerability.
(c) Security incident
If the attack is active, this can be considered as a very emergency situation. In such a scenario, immediate remediation must be required. Normal network security response measures such as blocking the source IP of the attack at a firewall or edge security device do not work as well for web application attacks. This may prevent genuine users from accessing the application. Here virtual patch is more flexible as it is not necessarily where an attacker is coming from but what they are sending.
Analysis Phase
Several tasks need to be completed during the analysis phase. Here are some recommended steps to start the analysis phase:
(a) Decide the Virtual Patching Applicability
Virtual patching is suited for injection-type vulnerabilities. A thorough examination of the underlying flaw should be conducted to identify whether the virtual patching tool has sufficient logic capabilities for detection.
(b) Determine the patch availability
The vulnerabilities are usually announced without an accompanying patch and leaves organizations exposed. If there is a patch available, then the company itself can initiate the proper patch management processes and concurrently creates a virtual patch.
(c) Utilize Bug Tracking/Ticketing System
Insert the vulnerability data into a bug tracking system for tracking purposes and metrics. It would be better to use ticketing systems such as Jira.
(d) Verify a workaround available without patching or upgrading
It is a temporary workaround that will buy organizations time while they implement actual source code fixes.
(e) Confirm the vulnerability name
It would be good enough to have the proper public vulnerability identifier like CVE name/number specified by the vulnerability announcement, vulnerability scan, etc. If the vulnerability is identified proactively, then you should assign your unique identifier to each vulnerability.
(f) Designate the impact level
It is necessary to know the criticality level involved with a web vulnerability. Information leakages might not be treated in the same manner as an SQL Injection issue.
(g) Specify which versions of the software are impacted
You should identify which versions of the software are listed so that you can identify whether any of the version(s) you have installed are affected.
(h) List what configuration is required to trigger the problem
Some vulnerabilities may only manifest themselves under certain configuration settings.
(i) List Proof of Concept (PoC) exploit code or payloads used during attacks/testing
Most of the vulnerability announcements have taking exploit code that shows how to illustrate the vulnerability. If this data is available, ensure to download it for investigation. This will be useful in the future when both developing and testing the virtual patch.
Read More:
