Technical support for vulnerabilities: CMS. Part 1

1C-Bitrix is ​​one of the most popular CMS systems. It includes many interesting solutions, starting from the site of a business card, ending with high-load systems. We often encounter this product during pentest and note that most of the detectable security problems can be seen in self-written modules, and not in the very core of Bitrix. Once, analyzing the security of a single system built on the basis of a boxed solution, we spotted a number of interesting vulnerabilities. It’s a pity, but you can’t talk about everything, but you can already tell about remote code execution and privilege escalation on the server.

By the way, the developers of RCE refused to correct.

Evil cat

If you are familiar with the integration of Bitrix and 1C Accounting, then you probably met a script called “1c_bx_import.php”. In short: this is a debug script for diagnostics, more details on its capabilities can be found at the link from the developers . In addition to a number of specific actions, it implements the ability to download and upload files to the server, unpack archives, delete arbitrary files.
')
The situation with this script is ambiguous: according to the developers, it is not an official part of the CMS, but it is located on the company's resources and is sometimes used by technical support to solve customer problems. Ultimately, this means that it is quite possible to meet on various resources, sometimes right at the root of the site. The developer honestly pointed out that this product should be used only at your own peril and risk, but users certainly believe that everything is safe and good, because authentication and authorization are present in the script. Unfortunately, this is not entirely true.

Let's see how authentication is implemented in the script:

if ((@$_REQUEST['mode']!='query' && @$_REQUEST['mode']!='exchange')) define('NEED_AUTH',true); require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php"); 

Most likely, it was originally intended that if the “mode” parameter in the URI is “query” or “exchange”, the login form is given to the user, and the script is terminated. However, if you look closely, you can see that an error has crept into the logical operators. It turned out to be absolutely the opposite: authentication will be requested only if “mode” is not equal to “query” or “exchange” !

Now check that in the script with authorization. The developer assumed that the script should be run only by administrators:

 if ((!$USER->IsAdmin())&&(@($_GET['mode']!='query'))) { echo ' .    .  .'; localredirect("/404.php"); } 

If both conditions are not met, the script will end. Let's look again carefully:

If the user is not an administrator, and if mode is not equal to query, then output “Access denied”.

It turns out, you can not be an administrator, the first condition will not be true, we don’t get to the section “Access Denied”, and the script will continue to work successfully. It turns out that if an anonymous user specifies the value “query” as the “mode” parameter, all actions inside the script will be available to him (the “action” parameter is responsible for choosing the type of function). Considering that the file functionality allows you to download files from the server and upload them to an arbitrary directory, public access to this script is a very big security threat.

Full list of commands available for execution:

• createfile - create a file with the text “success” in the specified path
• setsession - adding a custom cookie to the current user session
• createiblocktypeform - create information block type
• download - download an arbitrary file from the server
• xmlgetinfo - download arbitrary file from server
• deletefile - delete an arbitrary file from the server
• getfile - getting a list of files on the server
• unzip - archive unpacking
• upload - upload a file to an arbitrary directory
• search - file search on the server
• show_bxmltree - output directory structure as an xml file

Here, for example, is a request that allows you to download a configuration file containing an account to access the database:



And with such a request, an attacker can get a listing of files on the server:



Finally, you can download arbitrary code:



We reported the vulnerability to both the client and the CMS developers. Unfortunately, the developers of Bitrix refused to correct the error, since this script is not an official component of the CMS, as noted above.

Local privilege escalation

The developers of 1C-Bitrix Web Cluster made a mistake that allows getting superuser privileges (root) on all servers of the cluster, having access to the system user of bitrix on one of the cluster servers.

In 1C-Bitrix Web Cluster, Ansible server management system is used, authentication between servers is performed via SSH keys. Access to key files is only available to the superuser. In order for Ansible to read the keys and execute commands on remote servers, use the sudo utility, which increases the privileges to the root user.

The cluster system installer adds the following line to the sudo / etc / sudoers command configuration file:

 bitrix ALL=NOPASSWD: /usr/bin/ansible * -m setup 

Instead of the asterisk character, the system scripts substitute the name of the server in the cluster.

The sudo utility looks for occurrences of a substring in a string, rather than separating arguments, as would be the case with the system commands of the execv class. The asterisk character in the string above allows you to insert an arbitrary number of characters, which will be divided into separate arguments. Therefore, you can easily increase your privileges with one command:

 $ sudo /usr/bin/ansible 127.0.0.1 -m shell -a 'whoami; echo -m setup' 127.0.0.1 | success | rc=0 » root -m setup bitrix@test: ~ 

For sudo itself, the arguments are as follows:

 ["sudo", "/usr/bin/ansible", "127.0.0.1", "-m", "shell", "-a", "whoami; echo -m setup"] 

And this is consistent with the sudoers rule written by the developers. With this vulnerability, the developers have agreed, and at the moment it has already been fixed.

Conclusion

What do we get in the end? Vulnerabilities are fairly simple and do not require specific operating conditions.

We list our actions when looking for opportunities to gain control over the test site:

1. We define the host, run the procedure for selecting files and directories (dirbuster).
2. Met “bx_1c_import.php”. We download source codes from a site of the developer for the analysis.
3. Found the ability to download arbitrary files from the server.
4. First of all we download the configuration file for access to the database - dbcon.php. Alas, MySQL waits for connections only from “localhost”. Analyzing the source further.
5. Found the ability to upload your own code. We get backconnect to our server, however, the current user, under which the web server is running and on whose behalf we are working, has a limited set of rights.
6. As a result of the analysis of the tested host, it becomes clear - this is a whole cluster. Yes, and would not do the integration with 1C at the site-cards.
7. We are exploring the possibility of interaction with “Ansible”.
8. Raise privileges to root already on the whole cluster.
9. ...
10. We are looking for new vulnerabilities.