curityPHAR Deserialization: Exploiting Hidden Vulnerabilities in PHP

Understanding the Risks and Techniques to Safeguard Your Web Applications

When discussing deserialization vulnerabilities in PHP, the focus often falls on the explicit use of the unserialize() method to process user input. However, PHP applications can be vulnerable to deserialization attacks even without directly using this method. One particularly insidious vector for such attacks involves the PHP Archive (PHAR) format. This article explores the concept of PHAR deserialization, the inherent risks, and techniques for exploiting this vulnerability.

PHAR is a file format used to package PHP applications and libraries. It includes serialized metadata within its manifest files. PHP provides several URL-style wrappers for handling different protocols when accessing file paths, and one of these is the phar:// wrapper. This wrapper allows developers to interact with PHAR files through a stream interface.

The critical issue arises because any filesystem operations performed on a phar:// stream implicitly deserialize the PHAR metadata. This means that a phar:// stream can be exploited to trigger insecure deserialization if it can be passed into a filesystem method.

Bypassing Obvious Protections

Websites typically implement countermeasures to prevent the misuse of dangerous filesystem methods like include() or fopen(). However, less overtly dangerous methods, such as file_exists(), may not have the same level of protection, making them potential targets for exploitation.

Upload a Malicious PHAR File:The attacker needs to upload a PHAR file to the server. This can be done by exploiting an image upload functionality, for example.A polyglot file, which is a PHAR masquerading as a JPG, can be used to bypass validation checks.

2. Invoke the PHAR Stream:

Once the PHAR file is uploaded, the attacker needs to force the application to access it through a phar:// stream.This can be achieved by passing the phar:// URL into a method like file_exists() that does not appear dangerous at first glance.

3. Implicit Deserialization:

When the application performs a filesystem operation on the phar:// stream, the PHAR metadata is implicitly deserialized.If the metadata contains malicious serialized objects, these objects will be deserialized and can execute harmful actions.

Here’s a hypothetical example to illustrate the process:

Creating a Malicious PHAR File:<?php
class Exploit {
public function __destruct() {
system('rm -rf /'); // Dangerous payload
}
}

$phar = new Phar('exploit.phar');
$phar->startBuffering();
$phar->setStub('<?php __HALT_COMPILER(); ?>');
$phar->setMetadata(new Exploit());
$phar->addFromString('test.txt', 'test');
$phar->stopBuffering();
?>

2. Uploading the PHAR File as a JPG:

Rename exploit.phar to exploit.jpg and upload it using the website’s image upload functionality.

3. Triggering Deserialization:

file_exists(‘phar://path/to/uploaded/exploit.jpg/test.txt’);

When file_exists() is called with the phar:// URL, the PHAR metadata is deserialized, triggering the payload in the Exploit class.

1. Avoid Untrusted Data in Filesystem Functions

Ensure that user-supplied data is never passed directly to filesystem functions that can interact with phar:// streams.

2. Validate Uploaded Files

Implement strict validation checks on uploaded files. Use libraries that can accurately verify the file’s content type and structure, not just its extension.

3. Disable PHAR Handling

If PHAR functionality is not needed, disable it in the php.ini configuration:

4. Use Secure Coding Practices

Adopt secure coding practices and perform regular code reviews to identify and mitigate potential security issues related to deserialization and file handling.

5. Employ Web Application Firewalls (WAFs)

Utilize WAFs to detect and block malicious payloads and suspicious activities related to file uploads and deserialization.