Why is it important not to delay the installation and configuration of Bitrix CMS based on “1C-Bitrix: Virtual Machine”

Who dropped the glove?

Carrying out one of the penetration testing projects, we came across a virtual machine on the public IP address of the Customer. From the set of ports open on the host, we got the feeling that this is Bitrix. The link discusses the purpose of the ports. Below is a list of ports that are open on the VM “out of the box”:

• 22 / tcp
• 80 / tcp
• 443 / tcp
• 5223 / tcp
• 8893 / tcp
• 8894 / tcp

When you click on the ip_addr : 80 URL, the 1C-Bitrix site initial configuration page opens, and the “Restore a copy” link that goes to the restore.php module. When clicked, instructions for creating a backup copy of the existing 1C-Bitrix website, links to documentation and the "Next" button are opened. And then the fun begins, you can do the following:



It is clear that once the administrator did not complete the procedure for setting up the site and VM 1C-Bitrix. Here it would be possible to enter this cant in the report (in order to then try to sell the Customer an infrastructure monitoring system, SIEM or something similar) and go further. But we are not one of those.

The human factor, or the lack of customer control over the infrastructure, is not so important. The important thing is how this error can cause hacking.

Hello to distant sites

The restore.php module, in addition to presenting the interface, performs the functions of checking and downloading files, and deploying site backups. If you choose to download files from a local disk, then nothing prevents you from choosing not a backup, but say to load the phpinfo.php script.

And then Bitrix let it flow. We expected that the verification of files at the download stage or the post-verification of the contents of the file would work. It didn’t work ... the transferred file was in the home folder of the web application!

They began to understand what is “under the hood” and why does the script load everything in a row? For satisfaction of curiosity and for reporting to the Customer, they deployed “1C-Bitrix: Virtual Machine” version 7.2 in their lab.

The primary server configuration when connecting via SSH is performed in two steps:

1. Change root password
2. Change user password bitrix

Next, access to the local command interpreter will be available. We are trying to upload files with the extension .php to the “experimental” server - no problem, they are recorded in the home directory '/ home / bitrix / www': We



began to dig further into restore.php. Next was the function “Download backup from a distant site” (“distant site” is a very peculiar term, but okay). This script does not allow you to download anything other than backups. We looked at the restore.php source code and found the condition for checking the uploaded file:

$f = fopen($_SERVER['DOCUMENT_ROOT'].'/'.$arc_name, 'rb');
$id = fread($f, 2);
fclose($f);
if ($id != chr(31).chr(139)) // not gzip
{
$s = filesize($_SERVER['DOCUMENT_ROOT'].'/'.$arc_name);
if ($s%512 > 0) // not tar
{
unlink($_SERVER['DOCUMENT_ROOT'].'/'.$arc_name);
$res = false;
}
}

The first condition: if the beginning of the file does not contain characters with the code 0x1f and 0x8b of the ASCII + extended table, then the downloaded file is not a .gz archive.

The second condition checks the size of the downloaded file: if the value is not divided by 512 without a remainder, then the file is not a tar archive. This is where the verification ends.

It turns out that you need to bypass only the first condition. OK! We took a simple cmd.php script for tests (there is a ready-made one from “The Dark Raver”). The system cli passed identifier characters with the contents of the cmd.php file to a new file called cmd_boom.php:

echo -e "\x1f\x8b\n$(cat cmd.php)" > cmd_boom.php

Using the xxd utility, you can see the contents of the file in the form of a hex table:

cat cmd_boom.php | xxd

Conclusion:



Everything, the file is ready for upload to the “distant server”. We upload cmd_boom.php to our GitHub repository and insert the URL of the script on the 1C-Bitrix recovery form. As a result, after a short contemplation of the download progress bar, we received an error message:



Well, maybe the file was deleted from the home folder due to an error? What is the point of storing it if the file crashes in transit or is inconsistent? But the authors of the restore.php script apparently found it unnecessary to clean up the site’s home directory from garbage. So, what about the loaded shell? So here he is, dear!



Now the fun part. By clicking the “Skip” and “Try again” buttons on the error message form, we received a page with the “Delete local backup and utility scripts” button. Clicked - the files are deleted!

As a result, the home directory will be cleared of restore.php, bitrixsetup.php and the downloaded cmd_boom.php scripts. After that, you can’t do anything decisive with the site - and the backup copy has not been restored and you can’t proceed to installing the new site.

Of course, you could hide the cmd.php script in a subdirectory or rename it to index.php. We rested on our laurels.

There is set aside!

We reported to 1C-Bitrix technical support about a problem with the restore.php script, and we received the following answer:

“There is no point in talking about vulnerabilities in restore.php, this script is designed to deploy a site management system. In its essence, it is needed in order to upload php scripts to the site. ”

Well, in general, everything is correct, we successfully uploaded the scripts to the“ abandoned ”customer site and received a local shell.

The position of technical support is clear: "You haven’t finished the site configuration - you’re an evil Buratina yourself." The ticket was closed by technical support with no response from the developers themselves.

We did not begin to find out how many “abandoned” VM 1C-Bitrix VMs were published on the Internet, just a couple found by searching for “intitle:“ Welcome! ”Intext:“ Welcome to Bitrix Virtual Appliance ”on Google.

Epilogue

Do not publish BM 1C-Bitrix before the site is deployed. Keep track of your company’s resources published online. Abandoned sites are almost always bad.