Initially, the article planned to review the security tools of the 1C-Bitrix CRM system. However, during the research, some nuances related to this security arose. According to user question statistics, this topic is quite relevant.
The system developers claim a high degree of protection for Bitrix, but users face some problems that need to be solved to avoid negative consequences.
Let's consider the essence of the problem, namely - weak spots of Bitrix that require enhanced protection of any eCommerce resource.
Important! The solutions that will be discussed will be useful for Bitrix developers. To implement them, it is necessary to understand the specifics of building CRM. If you are not confident in your abilities, we recommend contacting specialized professionals. The slightest inaccuracy in the code content can lead to serious consequences and unjustified expenses.
XSS attack
If we believe the results of the Bitrix Hub research, XSS attacks (cross-scripting) are the most significant problem that web projects based on 1C-Bitrix: Site Management face. This refers to the presence of scripts in the code of the website that provide hackers with access to potentially harmful operations through the use of variable calls.
What is the problem related to?
Usually, such a scenario occurs when there is no or insufficiently reliable filtration of parameters read by scripts. In other words, the browser accepts user data as-is (without prior filtering).
What can be the consequences?
An XSS attack can lead to changes in the HTML pages of an unprotected resource in the context of a target visitor's browser, leakage of COOKIE data, and subsequent injection into the user's session. That is, an attacker can gain access to their account.
Not only Bitrix sites face this problem, since it is not so much related to the system itself as to the poor quality of user code. It is recommended to entrust the management of the site only to trusted specialists, since the costs of solving the problem and its consequences can be significant.
How to solve?
To protect the resource from unauthorized cyber-attacks, it is recommended to use: htmlspecialchars. To limit tags with dynamic values, use double quotes. If necessary, add the http protocol when configuring href/src tags.
Goals of Cross-Site Scripting
This method allows a hacker to gain access to a user's cookies using an integrated script to collect the necessary data. These cookies are used in subsequent attacks and hacks.
The attack is not performed on the user directly. Weak points of the site that contains malicious JavaScript are used for this purpose. In the browser, it is disguised as an organic part of the web resource.
XSS hacking does not pose a direct threat to the server, but if an attacker obtains administrative cookies, they can easily gain access to the administrative part.
The vulnerability should be sought in the site's contact forms. To check for potential threats, simply enter the following request into the form:
<script>alert("cookie: "+document.cookie)</script>
It is noteworthy that the basic installation of 1C-Bitrix with ready-made solutions excludes the possibility of such a problem. As a rule, it arises due to modifications and implementation of additional functional features, if the Bitrix standards and security rules are not followed when writing the code.
This same line can be entered as a GET parameter for pages that generate them (for example, on pagination pages of catalogs or in filters of online stores).
http(s)://{your_domain}/catalog?p=2 (instead of the number 2)
If the page contains a vulnerability, the script will be executed.
To protect against such factors, it is necessary to configure filters for incoming and outgoing information according to the criteria: method of setting screen for characters and conversion of special characters to HTML format. There are special functions for working with PHP: htmlspecialchars()/htmlentities()/strip_tags().
Let's give a few examples:
$name = htmlspecialchars($_POST['name'], ENT_QUOTES);
$name = strip_tags($_POST['name']).
When working with Bitrix, you can also use the CDatabase::ForSql method.
For example:
$name = CDatabase::ForSql($_POST['name'])
The encoding of the pages must be clearly specified:
Header("Content-Type: text/html; charset=utf-8")
Another solution is to prohibit the transmission of quotes and brackets through forms (these characters must be added to the blacklist). But this action may lead to blocking real requests if they contain forbidden characters.
Users of any CMS face this vulnerability. It is not typical specifically for Bitrix.
Here is a list of other common problems that are characteristic of any system:
- obtaining data by brute force;
- logical inconsistencies in the code;
- execution of system commands;
- file name correction;
- SQL injections;
- spoofing CSRF requests;
- phishing, etc.
Redirects: click.php/rk.php/redirect.php
Many Bitrix users face the problem of open redirects. This topic began to be actively discussed on the official developers' forum back in 2014, but it is still relevant today.
What is the vulnerability about?
The hosting provider sends a message indicating a significant increase in load on MySQL.
This problem arose due to a large number of requests (30,000 in 4 days for one user). The requests looked like this:
/bitrix/rk.php?=goto=http...
Suspicious websites usually followed goto.
The same phenomenon was recorded in analytical systems, where links (both internal and external) were displayed as such urls.
This construction is an open redirect. It allows fraudsters to set an arbitrary URL link so that the user is redirected to a malicious resource.
Regarding this vulnerability for Bitrix, it is most often caused by three system files:
For example:
{victim_domain}/bitrix/rk.php
?id=17&site_id=s1
&event1=banner&event2=click
&goto= {target_domain}/
Who does this and what can it lead to?
The first goal is to create trusted links. A few years ago, such a tool was at the peak of popularity for increasing the citation index during promotion.
Note: trusted sites are those that are considered trustworthy and reliable by the algorithms of Google and Yandex search engines. Such sites have a high rating, so they appear in response to relevant search queries at the top of the list. But such a situation is often the result of artificial rating boosting.
Moreover, many optimizers openly use the vulnerability strategy.
Guides for indexing links and their mass mailing are freely available. That is, anyone who wishes can use such tactics. Aggressive optimizers offer services to increase requests on a vulnerable site.
All these factors are the cause of an unreasonably high load on the site.
Let's take a visual example:
These are the data for 2017, but many redirects continue to function successfully.
Questions about redirects became actively discussed by the Bitrix audience only in 2018, and the reason for this was the massiveness of the problem.
The second goal is phishing. Links leading to the sites of attackers are often encountered in email newsletters, messengers. When clicking on them, hackers gain access to contact information, payment data, etc.
Another goal is spam, which reduces the site's reputation in search engines. A huge number of links to suspicious resources are viewed negatively by search engine algorithms. Restoring a site's position after spamming activity is a long and laborious process, so it's better to prevent the problem.
How does it work?
This is related to Bitrix's system files, which generate statistics on clicks and redirects to advertising banners and links. The use of a website as a conduit for suspicious redirects is present in the boxed version.
How to solve the problem?
According to user feedback, the problem is common. There are several discussions on the forum, but there is currently no system solution.
Developers recommend setting maximum security in proactive protection settings, and configuring HTTP header verification for redirects.
Nevertheless, none of the solutions provided guarantees 100% protection against phishing. The same applies to third-party tools. If the vulnerability reoccurs, it is recommended to delete the system files.
This solution may seem silly, but it really works. After this action, the administrator will not be able to monitor statistics on clicks on banner links and redirects.
The rk.php/click.php files work on the advertising system module. If this module is not used, it can and should be removed. The files will be deleted automatically.
There is another solution for the .htaccess file on the developer forum:
This is not a universal solution, but it is useful for those who do not use redirects and the specified files.
There is a more targeted code:
However, it also does not take into account the click.php file.
restore.php
The vulnerability was discovered during a penetration test. Let's briefly consider its essence.
The set of open ports indicated that the Bitrix virtual machine was installed on a public IP.
In response to accessing ip_addr:80, the browser opened the system setup page and a link to restore a copy. After clicking on it, the restore.php module was launched with a proposal to upload a backup copy.
This scenario can be explained by an incomplete configuration procedure for the resource and the virtual VMBitrix system from the administrator's side. Such a harmless error can lead to hacking.
restore.php performs the function of checking and loading files, deploying backups. A hacker can use the module to gain access not to the backup, but to the phpinfo.php file. Based on the analysis, it became clear that the file check did not work, and the script was unloaded from the computer to the web application.
A similar scenario was repeated in the laboratory using the Bitrix 7.2 virtual machine.
When trying to upload a script using the function of downloading a backup from a remote source, the system started checking.
restore.php contains the relevant code:
Nevertheless, the first condition was bypassed. The test was carried out with the cmd.php script. Identifying characters (the contents of the cmd.php file) were passed to the cli.
The new file is cmd_boom.php:
echo -e "x1fx8bn$(cat cmd.php)" > cmd_boom.php
Its tabular view:
After uploading the file, its link was passed to restore.php, after which the bar-loading began. Then came the notification:
Despite this, the file was not deleted from the root and is ready to run.
After selecting the Skip option, a retry was made. This time, an option appeared to delete the local backup along with the service scripts. Deleting all files was done after clicking.
The scripts restore.php/bitrixsetup.php, as well as the cmd_boom.php file, are deleted from the home directory. The file cannot be acted upon: if the backup is not restored, new ones cannot be installed.
Theoretically, you can rename the cmd.php file to index.php or move it to a subdirectory.
The message to Bitrix technical support was unsuccessful. Specialists replied that searching for weak spots in restore.php is pointless, since the function of the script is to upload php files to the resource.
The need to complete installation and configuration is quite logical. However, the problem is quite common. According to the results of a quick superficial check, there were more than 600 sites with VMs.
The massiveness of the problem should force the creators to find ways to increase protection within the identified area. Currently, users need to be vigilant, not to place VMs until the project is hosted on the server. It is also important to regularly check all publicly available pages and resources.
Arbitrary registration
The vulnerability was discovered about a year ago. In early 2020, developers began receiving reports that users were registering massively, bypassing captcha, after which spam mailings began.
This factor is related to the massive deployment of bots on Bitrix sites. If you look at the event log, you can see the registration address: /auth/?register=yes. The thing is, there is no /auth/ section on such resources, and the registration form is completely absent.
It is noteworthy that a similar situation was recorded on projects where registration is not provided (landing pages, business cards). Bots were introduced even on sites where the registration procedure is carried out using main.register or Bitrix API code written manually with reCaptcha, validation rules, and a list of fields for mandatory filling.
What is the problem related to?
The problem lies in outdated components:
- auth.registration;
- auth.authorize;
- auth.forgotpasswd;
- auth.changepasswd.
They are displayed on pages with the value true (the constant NEED_AUTH):
define("NEED_AUTH", true)
The nuance is that even if the constant is not set, outdated components still respond to the corresponding request (POST). This means that any page on the site, even without a registration form, can receive a request from a user to register.
A Postman employee created a universal request for investigation:
The request worked even on sites where registration is not provided, with bypassing the captcha. In other words, attackers have the ability to set up the process for their own purposes.
How to solve?
This vulnerability can be addressed in several ways:
1. If using custom registration, it is recommended to go to the settings of the main module (Authorization tab), uncheck the option for self-registration of users, and enable the use of a captcha. This will reduce bot activity. This method is not suitable for resources with SMS registration.
2. Check the fields of new users after registration using the event processing tool (OnBeforeUserAdd). You can avoid duplicating validation in the code where the registration procedure is possible.
3. Set the correct settings for the system.auth components.
The Bitrix support service is aware of this problem, but developers cannot offer anything except for installing a captcha. Perhaps a solution to the problem is a matter of time. The only thing left is to rely on your own strength.
Tools for website checking
If you need a quality check of website scripts and code, contact our specialists. We will help you identify weaknesses, as well as determine shortcomings in the performance, find potential errors in the operation of resource tools. A comprehensive approach will allow us to find solutions for optimizing the site's performance and further flourishing.
Please note: if your project has caught the attention of attackers, they can use a set of tools to hack it. To avoid losing valuable information, remember to make backups and control the quality of codes, especially custom ones.
Conclusion
Despite the numerous weak spots, Bitrix provides opportunities for their elimination. This CMS has all the necessary tools to increase the security of the website from hacker attacks. For serious projects, this system is considered the most reliable.
Don't forget about:
- timely updating of the CMS (installation of the latest releases);
- quality of development and customization (codes and scripts must be written in accordance with CMS canons).
In the basic CMS system, the risks are practically absent. Most problems are related to unqualified intervention, incorrect approach to programming pages, options, templates.
Security issues in the web space are particularly relevant now. The higher the popularity of the chosen CMS, the higher the risks of hacker attacks. Nobody is immune to this.
Recommendations that will help ensure the protection of your project:
- timely updating of CMS (outdated components can cause serious damage);
- cooperation with qualified specialists (errors related to the human factor can increase the vulnerability of the resource);
- regular creation of backups (backup will help prevent the loss of important information);
- timely identification and elimination of identified problems;
- periodic site check for protection (at least once every three months).
Have questions? We'll help you find the answer!