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

Who dropped the glove?

When performing one of the penetration testing projects, we came across a virtual machine at the Customer’s public IP address. From the set of open ports on the host we got the feeling that this is Bitrix. The link discusses the assignment of 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 go to the ip_addr : 80 URL, the primary configuration page of the 1C-Bitrix site has opened, and the “Restore a copy” link that goes to the restore.php module. Clicking opens instructions for creating a backup copy of the existing 1C-Bitrix site, links to documentation and the “Next” button. And then the interesting begins, you can do the following:


')
It is clear that once the administrator has not completed the procedure for setting up the site and VM 1C-Bitrix. Here it would be possible to enter this jamb in the report (then to try to sell the infrastructure monitoring system to the Customer, SIEM or something like that) and go further. But we are not one of them.

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

Hi distant sites

The restore.php module, in addition to representing the interface, performs the functions of checking and downloading files, and expanding backup copies of the site. If you choose to download files from a local disk, then nothing prevents you from choosing not a backup copy, but let us say download the phpinfo.php script.

And here Bitrix gave a leak. We expected that the check of files at the loading stage or post-check of the file contents would work. It did not work ... the transferred file was in the home folder of the web application!

Began to understand that "under the hood" and why the script loads everything? To satisfy curiosity and to report to the Customer, they deployed in their lab 1C-Bitrix: Virtual Machine version 7.2.

Initial configuration of the server when connecting via SSH is performed in two steps:

1. Change root user password
2. Change the bitrix user password

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



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 download anything except backups. We looked into the source code of restore.php and found the condition for checking the downloaded 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 uploaded file: if the value is not divisible by 512 without a remainder, then the file is not a tarball. This check ends.

It turns out that you need to bypass only the first condition. OK! We took for tests a simple cmd.php script (there is a ready-made from “The Dark Raver”). In cli, the system passed the identifier symbols with the contents of the cmd.php file to the new file with the name 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 as a hex table:

 cat cmd_boom.php | xxd 

Conclusion:



That's it, the file is ready for uploading to the “far server”. Download cmd_boom.php to your GitHub repository and paste the script URL 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 is broken on the way or inconsistent? But the authors of the restore.php script, apparently, considered it unnecessary to clear the home directory of the site from garbage. So, what about the loaded shell? So here he is, dear!



Now the fun part. Pressing the button “Skip” and “Try again” on the form with an error message we received a page with the button “Delete local backup copy and service scripts”. Clicked - the files were deleted!

As a result, the home directory will be cleared from the restore.php, bitrixsetup.php scripts and the loaded cmd_boom.php file. After that, nothing decisive can be done with the site - and the backup copy has not been restored and no need to switch to the installation of the new site.

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

Have set aside!

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

“Talking about vulnerabilities in restore.php does not make sense, this script is designed to deploy a content management system. It is necessary in its essence in order to upload php scripts to the site. ”

Well, in general, that's right, we successfully uploaded the scripts to the “left” customer site and received a local shell.

The position of technical support is clear: "You did not complete the configuration of the site - you are your own evil Buratina." The ticket was closed by technical support without an answer from the developers directly.

We didn’t find out how many “abandoned” VM 1C-Bitrix published on the Internet, just a couple found on the query “intitle:“ Welcome! ”Intext:“ Welcome to Bitrix Virtual Appliance ”” at Google

Epilogue

Do not publish VM 1C-Bitrix before the site is deployed. Keep track of your company's resources published on the Internet. Abandoned sites are almost always bad.