Дмитрий Харитонов (Все сообщения пользователя)

новые попытки взлома через /bitrix/services/main/ajax.php

в логах:
2025-05-27 17:20:20 - Host: XXX - UNCAUGHT_EXCEPTION - [Bitrix\Main\SystemException]
Could not find component by name bitrix:imopenlines.correction (0)
/var/www/html/bitrix/modules/main/lib/engine/router.php:210
#0: Bitrix\Main\Engine\Router->includeComponentAjaxClass(string)
       /var/www/html/bitrix/modules/main/lib/engine/router.php:169
#1: Bitrix\Main\Engine\Router->getComponentControllerAndAction()
       /var/www/html/bitrix/modules/main/lib/engine/router.php:138
#2: Bitrix\Main\Engine\Router->getControllerAndAction()
       /var/www/html/bitrix/modules/main/lib/httpapplication.php:110
#3: Bitrix\Main\HttpApplication->run()
       /var/www/html/bitrix/modules/main/services/ajax.php:17
#4: require(string)
       /var/www/html/bitrix/services/main/ajax.php:1
----------
2025-05-27 17:20:21 - Host: XXXX - UNCAUGHT_EXCEPTION - [Bitrix\Main\SystemException]
Could not find component by name bitrix:imopenlines.livechat (0)
/var/www/html/bitrix/modules/main/lib/engine/router.php:210
#0: Bitrix\Main\Engine\Router->includeComponentAjaxClass(string)
       /var/www/html/bitrix/modules/main/lib/engine/router.php:169
#1: Bitrix\Main\Engine\Router->getComponentControllerAndAction()
       /var/www/html/bitrix/modules/main/lib/engine/router.php:138
#2: Bitrix\Main\Engine\Router->getControllerAndAction()
       /var/www/html/bitrix/modules/main/lib/httpapplication.php:110
#3: Bitrix\Main\HttpApplication->run()
       /var/www/html/bitrix/modules/main/services/ajax.php:17
#4: require(string)
       /var/www/html/bitrix/services/main/ajax.php:1


Никто еще не сталкивался?

И долбят с одного IP практически у меня такой же был в логах, забанил через iptables
Народ и все-таки по вопросу расположения секций.
Вот для примера скидывали тут конфиг:
https://github.com/Wladimir-N/ispconfig/blob/debian12/Bitrix

в нем сначала идёт секция location / {...}
а уже за ней
location ^~ /bitrix/modules { internal; }
location ^~ /bitrix/php_interface { internal; }
location ^~ /bitrix/updates { internal; }
и т.д.

но, как я писал ранее, в моем случае игнорировались директивы после location / {..}
после переноса их ДО location / {..} они начали работать.
у меня прописано:
       location / {
            try_files       $uri $uri/ @bitrix;
       }
и далее блоки
       location ~ \.php$ {
               try_files       $uri @bitrix;
               include fastcgi_params;
               fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
               fastcgi_pass    $php_sock;
         
       }
       location @bitrix {
               rewrite ^/(.+[^/])$ /$1/ permanent;
               include conf.d/settings.sub;
               include fastcgi_params;
               fastcgi_param SCRIPT_FILENAME $document_root/bitrix/urlrewrite.php;
               fastcgi_pass    $php_sock;

       }
и т.д.
получается, что запрос /bitrix/modules/name.module/script.php в моём случае попадает в location / {..}, а в примере по ссылке - нет?

Алексей, а секция с location / {...} у вас идет ДО или ПОСЛЕ указанных правил?

Поменял местами - поставил его перед секцией location / {...} - начало работать. как-то странно, конечно. в вашем примере секция с /bitrix/modules тоже идёт ниже location / {...}

может от версии nginx зависит. т.е. в моем случае получалось, что секция location / {..} шла раньше и запросы к modules обрабатывались ей.

Нет, nginx + php-fpm
Хотя в конфиге задано:
       location ~* ^/bitrix/(modules|local_cache|stack_cache|managed_cache|php_interface) {
         deny all;
       }

Народ, в тему про дырку в include/mainpage/comp_catalog_ajax.php

Сегодня опять увидел левые файлы на сайте, по логам помониторил - оказалось, что сломали через установщик.
Так, что, если кто не сделал, то вставьте фикс, о котором писалось ранее и в файл в папке:
bitrix/modules/aspro.allcorp2/install/wizards/aspro/allcorp2/site/public/ru/inclu­de/mainpage/comp_catalog_ajax.php

ну, и , соответственно, с другими файлами, где была уязвимость.

только не забываем, что нужно тогда обновляться до php7.4, чтобы работал новый функционал, это если говорить о глобальном обновлении. а , если обновить до php 7.4 сервер, где установлена версия <=20, то отвалится функционал этой версии и надо будет вручную там править файлы. вот такая дилема

,

Ну, из приведенных Вами изменений можно отметить только проверку имени класса  - то, что это экземпляр Connector, которая проводится до создания класса. Но, мне кажется, что если это все изменения в vote, то дело было явно не в нем.

Как по мне, то решением невыполнения скриптов в upload является его перенос выше директории, где прописано обрабатывание скриптов(обычно /var/www/Папка_С_Битрикс) и создание символической ссылки @upload в корне сайта на эту директорию.  

Понял, спасибо, у меня nginx постарее, может из-за этого.

аналог для nginx из поста выше с описанием комплекса мер по предотвращению атак.

   location ~* ^/bitrix/tools/(html_editor_action|mail_entry|upload)\.php$ {
     deny all;
   }

   location ~* ^/bitrix/tools/vote/uf\.php$ {
          deny all;
   }

    location ~* ^/bitrix/components/bitrix/sender\.mail\.editor/ajax\.php$ {
          deny all;
    }


    location ~* ^/bitrix/admin/site_checker\.php$ {
        deny all;
    }


Можно скомпоновать с постом https://dev.1c-bitrix.ru/support/forum/messages/forum6/topic147346/message711306/#message711306, проверяя еще типа запроса.

Почитайте pdf, тут страницей ранее выкладывали ссылку на него - там все прекрасно расписано.

ну, так всё - день конституции отпраздновали теперь ждем следующих крупных дат

а .htaccess есть в /upload?
если да, то указано, что не давать выполнять скрипты?
<IfModule mod_mime.c>
<Files ~ \.(php|php3|php4|php5|php6|phtml|pl|asp|aspx|cgi|dll|exe|shtm|shtml|fcg|fcgi|fpl|asmx|pht|py|psp|rb|var)>
SetHandler text/plain
ForceType text/plain
</Files>
</IfModule>

Это прокатит, если у вас связка nginx+apache

если php-fpm, то прописывать надо в nginx

в какой-то мере помогает избежать выполнения скриптов в /upload/

мартовское вроде было обновление это.

причем, битрикс рассылал всем письмо, что нужно обновиться, ибо обнаружена уязвимость бла-бла-бла.

Но, вот выпустить заплатку, видимо, не судьба. А обновиться даже с 19 на последнюю версию - это обновить сервер, если у вас php 7.2 или ниже, накатить siteupdate, обновить кучу модулей. Работа не на один час.

Только это для файла /bitrix/tools/html_editor_action.php

А для /bitrix/tools/vote/uf.php
<?
if ($_SERVER['REQUEST_METHOD'] === 'POST')
{
header("Status: 404 Not Found");
die();
}
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/vote/tools/uf.php");
?>


Но, как по мне, всё это не панацея, поменял запрос на GET и ломай.
Сейчас просто это помогает, чтобы временно решить проблему , т.к. скрипт для внедрения стандартный и используется одинаково для всех сайтов. потом поднапрягутся ребята, поменяют логику работы и опять будут сломанные сайты.

так что, может быть, лучшим все-таки является вставка die() прямо в начало файлов, а потом уже разбираться что и как можно поправить.

выше, на 1 странице было решение:

location = /bitrix/tools/vote/uf.php {
       if ($request_method = POST) {
               return 404;
       }
       try_files return @php;
}


смотрите, что у вас в /etc/nginx/sites-available/

и прописываете в *.conf

прописывается в секцию server { }

посмотрите, наверняка у вас там есть уже секции с location

Ну, вот вариант, что у меня старая версия Битрикс и не получается ее обновить. Тут люди и ищут варианты закрыть дырку, без обновления siteupdate и модуля.

Смысла добавлять ПОСЛЕ require нет никакого, весь код уже выполнится.

Поэтому, либо добавлять непосредственно в модуль этот код, либо как я написал чуть выше ПЕРЕД require чистым php

iptables -A INPUT -s 185.180.199.209  -j DROP

и вас больше не побеспокоят с этого IP

Чуть исправленный вариант для вставки перед require, если я правильно понял идею

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
          header("Status: 404 Not Found");
          die();
}

Вадим, поправьте:
добавьте -mtime 0

Иначе, он просто у вас ищет все файлы и выводит дату модификации.
Хотя, конечно можно и так. Все равно он сортирует от большего к меньшему(-r).

Для запуска из консоли - ищем все модифицированные сегодня файлы, с раширением php в папке /var/www/html(папку ставим свою). Список будет в файле:
/var/log/daily_modify_php_files.log


find /var/www/ -type f -name "*.php" -mtime 0 -printf '%TY-%Tm-%Td %TT %p\n' | sort -r >>/var/log/daily_modify_php_files.log

Если прописать его перед require, то словим исключение , т.к. невозможно найти класс.

https://1c.1c-bitrix.ru/ecommerce/download.php

Вот здесь модули обмена.

Добрый день, может кто подскажет.

Работает мультисайт на разных доменах - site1.ru, site2.ru
Настраивали уже давно - через создание симлинков на папки bitrix,local,upload основного сайта(site1.ru).
В принципе, все работает, но вот решил проверить единую авторизацию - но, тут возник затык.
Настройки вроде бы все верные - стоят галочки "распространять куки на все домены" и "Распространять авторизацию на все домены".

Авторизуюсь на первом сайте(site1.com), вижу, что формируется тэг IMG вида:
<script>new Image().src='https://site2.ru/bitrix/spread.php?s=QklUUklYX1NNX0FCVEVTVF9zMQEBMTY2ODIzOTI1MAEvAQEBAg%3D%3D&...;

Открываю второй сайт, пробую получить $GLOBALS["USER"]->GetID() и облом. Объект USER  - пустой.

Проверяю на втором сайте тэг IMG:
https://site1.ru/bitrix/spread.php?s=QklUUklYX1NNX0FCVEVTVF9mZAEBMTY2ODIzOTU2MAEvAQEBAg%3D%3D&a...;

Параметр s - совпадает на обоих сайтах, а вот второй параметр k - разный.


Если посмотреть консоль с куками в Хроме на второй сайте, то вижу, что есть параметр BITRIX_SM_LOGIN равный логину на первом сайте, параметр PHPSESSID различается для двух сайтов.
Т.е., как я понимаю, по идее данные авторизации с первого сайта передаются на второй, но тем не менее, объект USER пустой на втором сайте.


В чем может быть проблема?

Сайты живут на хостинге reg.ru, учетная запись общая, сайты разведены по собственным директориям.