In this article, we are going to explore the topic of PHAR deserialization php vulnerability that Dawid found in a white box testing. Before we continue, let’s talk about PHAR a little bit and after that what is the PHAR deserialization php vulnerability.

In this article you will find:

• What is PHAR?
• What is PHAR Deserialization PHP vulnerability?
• When should you worry?
• How does the exploitation of this php vulnerability look like?
• What exactly we found?
• Example scenario: Kafka integration exploitation case
• What is the impact of this php vulnerability?
• To prevent this vulnerability, organizations can take several steps
• Conclusion

What is PHAR?

PHP Archive (in short PHAR) is a functionality that allows putting several PHP files into a single archive file for easy distribution and installation. This is similar functionality to the one provided by JAR files in the Java ecosystem. In addition, the PHP engine implements a “phar://” stream wrapper to access specific files within a PHP Archive. For example, to load the file.php from the myphar.phar file, you can use the following PHP code:

Multiple default PHP functions that operate on files can parse PHP Archives and extract the desired PHP file. Examples of such functions include, file_exists, and fopen.

What is PHAR Deserialization PHP vulnerability?

When the PHP interpreter finds a phar wrapper in one of those functions, it loads the archive. Subsequently, the PHP interpreter deserializes the phar archive, which may result in executing a potentially dangerous action. Deserialization is the process of creating a PHP object from a stored representation. It allows translating a string or a file in a specific format to a PHP object. The deserialization process can be used in attacks when an attacker’s-controlled input is being deserialized. If the application does not implement sufficient protections, the attacker can craft the serialized object in a way to exploit the object instantiation and autoloading mechanisms of the PHP interpreter. This results in executing arbitrary PHP code on the vulnerable web application.

When should you worry?

A phar deserialization vulnerability occurs when mainly the following conditions are met:

• An application uses PHP functions operating on files with user-controlled input.
• The user controls the beginning part of the file path.
• The user can upload arbitrary files on the server.
• The user knows the absolute path of the uploaded file.
• The phar wrapper has not been unregistered.
• The attacker has internal knowledge about existing classes, which allows him to construct specific serialized objects.

How does the exploitation of this php vulnerability look like?

The following steps describe the typical exploitation process:

• The attacker learns about the classes loaded by the application. This happens either by reading the source code of the application if possible or by understanding what libraries or frameworks are used by the application. Another way would be to try classes of typical libraries that are used by other applications.
• The attacker crafts a malicious phar file and uploads it to the server.
• The attacker locates the absolute path of the previously uploaded file.
• The attacker sends the absolute path to the uploaded file prepended with the “phar://” prefix to the vulnerable application endpoint.
• The application uses the user-supplied path with the “phar://” prefix to conduct operations on the file such as checking if the file exists with the function “file_exists”.
• The PHP interpreter unpacks the phar file and reads its metadata.
• The PHP interpreter deserializes the metadata crafted by the adversary.
• During the instantiation, autoloading, or destruction of the object, the PHP interpreter conducts malicious actions based on the adversary’s-controlled data such as executing code on the operating system.

The exploitation of this vulnerability very often leads to remote code execution on the application’s server. This impacts the confidentiality, integrity, and availability of the application as the attacker gains internal access to the application’s operating system.

What exactly we found?

During the White box testing security assessment that we conducted for MISP open-source threat intelligence application, we discovered multiple areas of the application vulnerable to “phar deserialization”. The following table highlights these areas:

Another place vulnerable to “phar deserialization” was the CertAuth plugin. The method getRestUser of the class CertificateAuthenticate in the file “app/Plugin/CertAuth/Controller/Component/Auth/CertificateAuthenticate.php” at line 262 seems to load a file from an URL. This URL is provided in the configuration variable at line 223. The configuration variable could be potentially modified by an administrator, which could lead to the exploitation of this vulnerability.

Example scenario: Kafka integration exploitation case

If you’re familiar with MISP, you may have heard that there is a plugin for publishing events to Apache Kafka. But here’s something you may not know: if this certain plugin is enabled, a rogue MISP administrator could potentially use it to execute malicious code on the operating system.

Let’s break this down a bit to exploit this vulnerability before diving in to exploitation:

1. Generate a malicious phar file.
2. Upload phar file to the server.
3. Enable Apache Kafka plugin in MISP.
4. Provide a path to the uploaded phar plugin.
5. Setup a listener.
6. Publish any event.

Step 1 – Generating a malicious phar file

To generate the malicious phar file we used the PHPGGC software:

The command included in the “exploit.phar” file will initiate a reverse shell connection on port 1111, host dawid, which should be considered as a machine controlled by the adversary.

Note, the CLI php.ini file on the host where generation occurs needs to have the following line:

Step 2 – Uploading the generated phar file

During this white box security example, we choose to upload our malicious file as an organization logo. This can be done under the following URL: http://<MISP-SERVER>/admin/organisations/edit/1

Step 3 – Enabling the Kafka plugin in MISP

To enable the Kafka plugin, we conducted the following actions:

• Go to https://<MISP-SERVER>/servers/serverSettings/Plugin
• Expand the „Kafka” section.

• Enable the following settings:

o Plugin.Kafka_enable

o Plugin.Kafka_event_publish_notifications_enable

Step 4 – Setting the correct Kafka config path

The uploaded phar file was available under the URL: http://<MISP-SERVER>/img/orgs/1.png

MISP was installed under the default filesystem path. Because of that, the organization image was uploaded to the following absolute server path: phar:///var/www/MISP/app/webroot/img/orgs/1.png We provided this path in the following Kafka setting: Plugin.Kafka_rdkafka_config

Step 5 – Setting up a listener

To receive the connection from the server, we started listener on the attacker’s machine called dawid using the netcat command:

Step 6 – Publishing an event

We created an empty event in the Event Actions > Add events and published it using the “Publish Event” link in the event’s view.

As a result, the connection was established and we were granted shell access to the operating system where the MISP application was installed:

The source code file MISP/app/Model/AppModel.php is vulnerable in line 2590 (method getKafkaPubTool):

What is the impact of this php vulnerability?

It is very important to note that, the vulnerability can be exploited by MISP administrators only. This alone lower the severity of this vulnerability.

However, a similar vulnerability was discovered by Ianis Bernard from NATO Cyber Security Centre that can be exploited by non-administrator users. You can find more information under this link.

The impact of the MISP vulnerability is severe. As a critical application for threat intelligence sharing and collaboration, MISP is widely used by organizations and agencies in various industries including government, finance, healthcare, and defense. The vulnerability may allow attackers to gain unauthorized access to sensitive information stored in MISP, including details of ongoing investigations, vulnerabilities, and other sensitive data.

This php vulnerability might lead attackers to execute arbitrary code remotely, which can result in a complete compromise of the MISP instance and potentially lead to the compromise of other systems and networks connected to it. This can include the theft of confidential data, installation of malware or backdoors, and disruption of critical systems and services.

Moreover, the nature of MISP as a collaborative platform for sharing threat intelligence means that the impact of a compromise can extend beyond a single organization. If an attacker gains access to a MISP instance, they can potentially access and exfiltrate sensitive data from other organizations sharing information on the platform. This could have serious consequences for national security, public safety, and the privacy of individuals.

What can happen if your application is vulnerable to PHAR deserialization? Here I compose the list of impacts:

• Remote code execution: If an attacker exploits PHAR deserialization vulnerability, they can execute arbitrary code remotely on the vulnerable system. This could result in the attacker gaining control of the system, stealing sensitive data, or using the system to launch further attacks on other systems.
• Denial of service: Attackers can also use PHAR deserialization vulnerability to launch denial of service attacks. By exploiting this vulnerability, attackers can cause the system to crash or become unresponsive, rendering it unusable for legitimate users.
• Data theft: PHAR deserialization vulnerability can also lead to data theft, where attackers can gain access to sensitive data stored on the system, such as user credentials, credit card numbers, and other personally identifiable information depending on the target system.
• Malware infection: Attackers can use PHAR deserialization vulnerability to inject malware into the system, which can then be used to perform other malicious activities, such as spying on users, stealing data, or launching further attacks.
• Reputation damage: A successful attack on the system can lead to significant reputation damage for the affected organization. This can result in a loss of customers, revenue, and credibility.

To prevent this vulnerability, organizations can take several steps:

• Deregistering PHAR wrapper: To prevent potential security vulnerabilities, consider deregistering the PHAR wrapper if it’s not in use. This can be done using the stream_wrapper_unregister() function. 
• Limit access to PHAR files: Restrict access to PHAR files, both from the file system and the application code. Make sure that only trusted users can read and modify PHAR archives.
• Use only the base name of the path as input: When opening a PHAR archive, only use the base name of the path as input, rather than the entire path. This helps prevent directory traversal attacks and ensures that the PHAR archive is only opened from a known location.
• Prepend the path with a fixed string: Prepend the path to the PHAR archive with a fixed string to make sure it is opened from the correct location. This can also help prevent directory traversal attacks.
• Whitelist the path/URL extensions provided by the user: Whitelist the path or URL extensions provided by the user to ensure that only valid PHAR archives are opened. This helps prevent attackers from exploiting the application by injecting malicious payloads in the PHAR archive’s metadata.
• Keep software up to date: Always keep the software and all libraries used in the application up-to-date, as new patches and security updates are released regularly to address vulnerabilities like this.
• Monitor application logs: Monitor application logs to detect any suspicious activity, such as unauthorized attempts to access PHAR files or unusual use of the unserialize() function.
• Conduct regular security assessments: Regular security assessments can help identify vulnerabilities in the system and address them before attackers can exploit them. Organizations should conduct periodic security assessments of their applications to ensure that they are secure and up to date. 

By implementing these measures or disabling the PHAR stream wrapper, organizations can significantly reduce the risk of attackers exploiting this vulnerability and gaining unauthorized access to their sensitive information. Organizations need to take a proactive approach to security and implement a comprehensive security strategy to protect their critical applications and data.

Conclusion

In conclusion, this vulnerability is a serious issue that needs to be addressed by organizations using web applications based on PHP. It has the possibility of attackers gaining unauthorized access to sensitive data and potentially causing significant damage. It is important to mention that this kind of php vulnerability is not something we face every time we conduct white box testing examples or real-life tests.

To prevent such attacks, it is essential to keep applications up to date with the latest security patches and follow best practices for secure deployment. Organizations should also regularly audit their systems to ensure that there are no vulnerabilities that could be exploited by attackers. Finally, it is important to have a robust incident response plan in place to quickly identify and respond to any potential attacks.