CVE-2014-2383: LFI/RFI Escalation to RCE

Executive Summary

In 2014, an arbitrary file read vulnerability was discovered in dompdf.php. 1The vulnerability allowed remote or local attackers to read local files using a special crafted http request. During a security assessment, Avertium’s Threat Labs team observed the presence of CVE-2014-2383 in a client’s environment. To protect client privacy, this report contains a proof of concept (PoC) and does not include the details from the initial discovery. The content in this report mimics the environment in which CVE-2014-2383 was exploited.

discovery

Many open source and enterprise level Web Vulnerability tools will detect CVE-2014-2383. After being placed behind the firewall, by using a tool called Nuclei we were able to discover the vulnerability. 2This kind of PoC will fail in most situations due to firewalls and load balancers blocking file system resources in URLs.

Image 1: Nuclei Screen Capture

DETAILS OF CVE-2014-2383

3As previously stated, “a vulnerability exists in dompdf.php, in dompdf before 0.6.1. When DOMPDF_ENABLE_PHP is enabled, it allows context-dependent attackers to bypass chroot protections and read arbitrary files by using PHP protocol and wrappers in the input_file parameter. This is demonstrated by a php://filter/read=convert.base64-encode/resource in the input_file parameter.” Take a look at the original PoC below.

Observe the “php://filter/resource” PHP wrapper being used to include the “/etc/passwd” file from the target.

Image 2: Original Payload for CVE-2014-2383

Image 3: Burp Suite Request and Response of Payload

Not only did the PHP wrapper allow for local file inclusions, but it allowed inclusions for remote files as well.

Image 4: Payload Highlighting Remote File Inclusion

Image 5: Remote File Inclusion Payload

Image 6: Target of the Remote File Inclusion

escalation to remote code execution (RCE)

Until this point, we have been using known information and proof of concepts to exploit CVE- 2014-2383. To further exploitation of the vulnerability, we used other protocols and PHP filters to obtain some type of pre-processing before the creation of the PDF.

A key distinction in this Local and Remote File Inclusion (LFI/RFI) vulnerability was that any file referenced in the LFI was rendered as a PDF document. Therefore, attempting to render a PHP file through the LFI would only convert that file to a PDF and would not execute the PHP in the file. Looking closer at our payload, we observed that the “php://filter/resource=” is the part of the payload that bypasses a restriction put in place by Dompdf.

When using a different PHP filter, the server pre-processes a POST request before executing the LFI. We use the “php://input” input stream to read the raw data from our POST request, while adding a parameter with the command we want to execute – defining it in our POST data. The new parameter looks something like this “php://input&cmd=id” and our POST data would look like this, . The result of the exploitation is below.

reproduction steps

Important Note: All steps are done from an unauthenticated perspective

Step 1 - Browse to the LFI once you have discovered a version of DOMPDF < 0.6.1

Image 7: The Original Payload for CVE-2014-2383

Step 2 - Capture this request in a proxy like BurpSuite so we can have a granular look at the request.

Image 8: Captured Request

Step 3 - Send the request to Repeater(ctrl+r).

Image 9: Request Sent to Repeater

Step 4 - Once you have the request in Repeater, right click the request and "Change Request Method". Doing this will change our request from a GET request to a POST request.

Image 10: Request Changed to POST Method

Step 5 - Next, we add POST data to the POST request and modify the input_file parameter. We change the input_file parameter in the URL. Remember, input_file is one of the parameters that we see in the original PoC.

Image 11: Original Payload

Image 12: Modifying to RCE

Image 13: Modified Request to Create the RCE

Step 6 – Add the below to the body of the POST request: (Sometimes the single quotes need to be retyped).

Image 14: Post Data to Inject System Commands vis PHP

Image 15: Body of Post Request for the RCE

Step 7 - The entire Request should look close to something like the next code block, which is the whole request after it has been modified to an RCE.

Step 8 - If using BurpSuite, send the request before using the search bar to search for "BT". Observe that the command has executed, and the response is being written into the byte level data of the PDF that Dompdf is attempting to generate. When doing this kind of exploit, it fails to generate the PDF. However, the data comes back like the image below.

In this case the user is "daemon", which is the output of the command.

Image 16: The Response

Step 9 - A python script was created to automate most of the PoC.

Image 17: Python Script

A video of the RCE can be found here.

conclusion

When penetration testers are given web applications to test, most of the time, effort can be throttled due to basic PoC payloads being blocked (for example: “/etc/passwd”). There should always be an effort to put a penetration tester past the firewall in order to get the most in-depth assessment of the web application. Unfortunately, when you introduce a firewall or a load balancer, you could be introducing a single point of failure when critical vulnerabilities exist on the web server. If there is a critical vulnerability on the web server being blocked by the firewall, we miss an opportunity to create a more “defense-in-depth” approach by fixing the root of the problem.

Note: The author of this blog entry is Associate Threat Labs Consultant, Dan Groner, with editorial contributions by Emergent Threat Researcher, Portia Cole.

Supporting Documentation

dompdf 0.6.0 - 'dompdf.php?read' Arbitrary File Read - PHP webapps Exploit (exploit-db.com) https://github.com/projectdiscovery/nuclei

https://www.cvedetails.com/cve/CVE-2014-2383/

APPENDIX II: Disclaimer

This document and its contents do not constitute, and are not a substitute for, legal advice. The outcome of a Security Risk Assessment should be utilized to ensure that diligent measures are taken to lower the risk of potential weaknesses be exploited to compromise data.

Although the Services and this report may provide data that Client can use in its compliance efforts, Client (not Avertium) is ultimately responsible for assessing and meeting Client's own compliance responsibilities. This report does not constitute a guarantee or assurance of Client's compliance with any law, regulation or standard.

COPYRIGHT: Copyright © Avertium, LLC and/or Avertium Tennessee, Inc. | All rights reserved.