Allele Security Alert
ASA-2018-00052
Identifier(s)
ASA-2018-00052, CVE-2018-19274
Title
Authenticated remote code execution via Phar deserialization
Vendor(s)
phpBB Limited
Product(s)
phpBB
Affected version(s)
phpBB before 3.2.4
Fixed version(s)
phpBB 3.2.4
Proof of concept
Unknown
Description
Passing an absolute path to a file_exists() check in phpBB before 3.2.4 allows authenticated remote code execution through object injection by employing Phar deserialization when an attacker has access to the Admin Control Panel with founder permissions.
Technical details
Phar deserialization vulnerabilities occur if user input is passed unsanitized to any file system function in PHP, such as file_exists().
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.
For exploitation, the following steps are necessary.
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.
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 independent. 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.
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.
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.
Credits
Simon Scannell (RIPS Technologies) and Robin Peraglie (RIPS Technologies)
Reference(s)
phpBB 3.2.3: Phar Deserialization to RCE
https://blog.ripstech.com/2018/phpbb3-phar-deserialization-to-remote-code-execution/
phpBB 3.2.4 Release – Please Update
https://www.phpbb.com/community/viewtopic.php?f=14&p=15131871
Implementation and improvements of PharGGC, –output and –ascii-strings
https://github.com/ambionics/phpggc/issues/24
CVE-2018-19274
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19274
CVE-2018-19274
https://nvd.nist.gov/vuln/detail/CVE-2018-19274
If there is any error in this alert or you wish a comprehensive analysis, let us know.
Last modified: February 1, 2019