phpBB 3.2.3: Phar Deserialization to RCE

A new PHP exploit technique affects the most famous forum software phpBB3. The vulnerability allows attackers who gain access to an administrator account to execute arbitrary PHP code and to take over the entire board.

Impact

phpBB is one of the oldest and most popular board software. If an attacker aims to take over a board running phpBB3, he will usually attempt to gain access to the admin control panel by means of bruteforcing, phishing or XSS vulnerabilities in plugins that the target site has installed. But plugins cannot be installed directly in the admin panel and there is no other feature that can be abused by administrators to execute arbitrary PHP code. However, the vulnerability described here allows the attacker to break out of the admin panel, execute arbitrary PHP code on the underlying server and then to perform a full site takeover.

The issue in the phpBB3 code base (300 KLOC) is a Phar deserialization vulnerability. It was fixed in version 3.2.4. Our leading SAST solution RIPS automatically detected this vulnerability in 3 minutes scan time.

Technical Details

Phar deserialization vulnerabilities occur if user input is passed unsanitized to any file system function in PHP, such as file_exists(). We have detailed how the new exploitation technique discovered by Sam Thomas works in our previous blogpost.

The vulnerability in phpBB3 lies in a feature that allows administrators to edit images that were uploaded to the forum. The feature utilizes an image editor binary called Imagick. Administrators are able to set the absolute path to the image editor binary on the server running phpBB3. Before updating this setting, phpBB3 tries to validate the new path with the function validate_config_vars(). The function performs this validation by checking if the file actually exists.

/includes/functions_acp.php

568569570571572573574575576577578579

function validate_config_vars($config_vars, &$cfg_array, &$error)
{
    ⋮
  case 'absolute_path':
  case 'absolute_path_writable':	
  case 'path':
  case 'wpath':
    ⋮
    if (!file_exists($path)) {
        $error[] = sprintf($user->lang['DIRECTORY_DOES_NOT_EXIST'], $cfg_array[$config_name]);
    }
    ⋮

Exploitation

For exploitation, the following steps are neccessary. Please note that we left out some details on purpose.

Uploading a malicious Phar file

In order to trigger the Phar deserialization, the local path to the Phar file on the target server must be supplied.

Example of triggering a phar deserialization

1

file_exists('phar:///var/www/phpBB3/files/evil.phar');

This means an attacker must upload the malicious Phar file to the target board. Since phpBB3 allows users to upload attachments and add them to threads and posts, uploading the malicious Phar file is trivial. Although only a whitelisted set of extensions, such as .jpg or .pdf is allowed, an attacker can still upload a valid Phar file to the server. This is because Phar files are extension independend. If the evil.phar file was renamed to evil.jpg, the above example of triggering the Phar deserialization would still work. There are also Polyglot files that are valid JPG and Phar files at the same time.

Phar files are extension independend

1

file_exists('phar:///var/www/phpBB3/files/evil.jpg');

Defeating filename randomization

When files are uploaded to the phpBB3 forum (e.g. post attachments or images), their filename is randomized. When evil.jpg is uploaded, it will be stored in the /phpBB3/files/ directory as a randomly generated md5 hash, for example2_08cc076da659b5b30de5fbfe10c05270. In order to exploit the Phar deserialization, an attacker must know the exact file path of the file on the server. The filename randomization of phpBB3 is cryptographically secure, so bruteforcing the filename is not a liable option. This means that the first step of uploading the malicious file can be done easily, but the second step of triggering the Phar deserialization fails because the attacker does not know the path to the Phar file.

However, a weakness in the file uploading process of attachments allows attackers to predict the filename on the server. phpBB3 offers users to upload files in chunks, which means that a large file can be uploaded in multiple requests. All upload chunks are written to a temporary file. Once all chunks have been appended to the file, its filename is randomized and moved to the /phpBB3/files directory. The temporary filename is generated by the temporary_filepath() function. The function takes one argument, which is the filename of the malicious Phar file the attacker wants to upload, in this case evil.jpg.

/includes/functions_acp.php

568569570571572573574575576577

protected function temporary_filepath($file_name)
{
	// Must preserve the extension for plupload to work.
	return sprintf(
		'files/plupload/%s_%s%s',
		$this->config['plupload_salt'],
		md5($file_name),
		\phpbb\files\filespec::get_extension($file_name)
	);
}

The function then returns the filename, which consists of an upload salt, the md5 hash of the $filename, which is evil.jpg and the extension of the $file_name, which is .jpg. Since $file_name is under control of the attacker, the only part of the filename that is unknown is the plupload_salt. This salt is a cryptographically secure, random hash that is unique to each phpBB3 board and is generated when the target board was installed. However, the hash is stored in the database in the phpbb_config table. Administrators with founder privileges can download MySQL database backups from within the admin control panel. This means an attacker can simply download a backup and extract the plupload salt from it. This allows the attacker to predict the full path of the Phar file on the server.

The temporary file will be stored on the server until all chunks are sent. An attacker can initiate a file upload and tell phpBB3 that two chunks will be sent. By uploading the Phar file with the first chunk but never sending the second, he can trick phpBB3 into waiting until the second chunk arrives and not deleting the temporary file. This way he can upload a file and know the local filename.

Triggering the exploit and executing code

The last step of exploiting the Phar deserialization is finding POP gadgets that can be abused to perform malicious actions. We managed to find a POP chain that allows attackers to create arbitrary files on the server and inject PHP code into the file. This means an attacker can easily create a shell.php and then execute arbitrary code on the target server, leading to a full site takeover.

Time Line

Summary

Phar deserialization is a new exploitation technique in PHP and occurs in many popular CMS systems. Our leading PHP security solution RIPS was able to detect this type of vulnerability in phpBB3 within minutes. The vulnerability allows authenticated attackers to execute arbitrary PHP code on the server. We would like to thank the phpBB security team for their very fast responses, as well as the competent and professional handling of the security issue.