Прочитал тут одну статью , где речь шла про уязвимости сайтов на Bitrix (которые, к слову, Bitrix даже опровергала - мол, нет никаких уязвимостей - это все выдумки). Но как бы то ни было - полный разбор кто виноват и что делать шел на форуме самого битрикса, и идет до сих пор.
Как человек, который сталкивался с этой проблемой непосредственно (и успешно вылечивший добрые пару сотен сайтов за последние пару лет) – Я заинтересовался вопросом, а насколько велика эта проблема на самом деле сейчас, спустя почти 2.5 года после первичного появления 0-day уязвимости?
Да, сайты были взломаны из-за уязвимости, но прошло уже почти 3 года - не может же быть, что кто-то до сих пор хранит свой сайт на устаревшей версии CMS с открытыми уязвимыми файлами, приглашая любого встречного полакомиться ресурсами?! Быть не может. Или...?!
Автор там пишет много и в целом правильные мысли, резюмируя при этом несколько абстрактно:
Но цифр при этом не приводит. Вот и задался я этим вопросом – а сколько еще вообще сайтов, которые живут с уязвимостями и ждут когда их вылечат взломают?
Давайте разбираться.
Шаг 1. Ищем сайты на Bitrix
Итак, собираем пучок сайтов, у которых есть симптомы наличия Битрикса.
На самом деле найти сайты оказалось не так сложно.
В моем случае я даже не стал смотреть открытые каталоги сайтов, где прямо указано что сайты собраны на Bitrix. Пойдем сложным путем. Я всего-навсего взял 226 000 (двести-двадцать шесть тысяч) самых посещаемых сайтов русскоязычной части интернета и посмотрел из них 100 000 с верхушки, с целью определить где есть первичные половые признаки Bitrix.
Результат был примерно такой:
Расшифровываем:
- 25330 сайтов отдали 200 код ответа на запрос к внутренним файлам битрикса (внутри ядра папки bitrix).
- 65148 сайтов, вероятно, не являются Bitrix
- 8716 сайтов отдали 403 код ответа (заблокировали нашего бота), т.е. доступ к внутренним страницам папки был закрыт как это требует рекомендует информационная безопасность. Или, возможно, это не Битрикс и настроен 403 код ответа.
- 787 сайтов отдали 500 код ошибки при обработке запрашиваемой – это можно списать на погрешность
Итак, в активную зону аналитики попали 25330 сайтов. В целом, неплохо. Это черновая база, с которой мы будем работать.
Шаг 2. Смотрим версии Bitrix
Напомню проблему: автор сетовал на то, что многие сборки битрикса не были обновлены, как того предписывал поставщик продукта.
Саму версию битрикса без доступа к сайту найти не так просто, однако (!внезапно!) можно найти дату последнего обновления.
Легким движением руки делаем массовый тест:
- Последнее обновление системы на сайте
- Доступность внутренних файлов для доступа
- Наличие теоретической уязвимости сборки
Нет, взламывать мы ничего не будем. Просто посмотрим.
Итак, собираем данные на добрые 25000 сайтов и ... барабанная дробь:
Видим, что обновления:
- В 2023 году поставили 45.3% сборок.
- А в 2024 году – только 14,1%.
- Общее число закрытие уязвимостей через обновление – порядка 59,6%.
В целом видим что реакция на взлом 2022 года по состоянию на сегодня имеет результативность информационной безопасности в почти 60%. Не так и плохо, на самом деле.
Но больше нас интересуют другие сборки, а именно те, обновления которых последний раз датированы в 2021-2022 и тем более те, которые последний раз обновлялись еще раньше (в 2016-2020 годах).
К слову, сборки без обновления 2021-2022 года и содержали ранее ту самую 0-day уязвимость , выпущенную в бюллетене ALRT-20220303.2 о которой писал автор.
Т.е как мы видим, как минимум 40.4% сборок до сих пор (по состоянию на 14.11.2024) имеют могут иметь признаки уязвимости, вызванные, как минимум отсутствием рекомендованного обновления.
Тут, к слову, нужно отвлечься от статистики. Да, некорректно сразу обвинять владельца сборки (и тем более производителя продукта) в наличии «дырки на сайте» – вполне возможно, что он, или программисты, обслуживающие сайт – почистили все и закрыли уязвимости без обновления ядра.
Да, такое возможно. Как говорится - «Да ты успокойся. Я так тыщу раз делал» (с)
Тем не менее масштаб вызывает закономерные вопросы.
Шаг 3. Определяем наличие уязвимости
Как еще определить уязвимость? На самом деле владельцу это сделать довольно просто – если уязвимость есть, то, вероятно, сайт уже может быть скомпрометирован и его работа нарушена тем или иным способом. Ибо свято место пусто не бывает.
В случае наличия доступа на сайт – достаточно выйти на FTP и глянуть в нужные места.
Как в том анекдоте – стукнуть в нужное место не сложно, но нужно знать в какое место стучать
Чем гадят?
Кроме совсем радикальных методов (вроде показа мгновенно блокируемых баннеров, или же удаления всего сайта целиком) - на текущий момент популярны следующие внедрения:
1. Размещение скриптов SAPE и продажа ссылок на вашем сайте
2. Размещение дорвеев во внутренних папках:
3. Размещение фишинговых страниц (копий банков)
4. Фишинговые ссылки и редиректы (JS / .htaccess)
5. Замена главной страницы (и файла index.php)
6. И другие. На сколько хватит фантазии.
Пункты 1-3 вы можете не замечать долгое время (т.к. они не всегда влияют напрямую на работу сайта), а на 4-5 признаки вы должны заметить сразу. Кроме отсутствия работы сайта может ругаться антивирусная программа, поэтому эти признак обычно является наиболее популярным сигналом к обращению владельца ресурса за помощью. Именно на этом пункте большинство пользователей замечают наличие вируса на сайте и предъявляют претензии тем, кто сайт обслуживает.
Тот, кто разбирается в вирусах – при входе на Ftp сайта, видит все следы, оставшиеся от злонамеренной активности.
К примеру:
Если доступа нет - то все-равно можно посмотреть на степень защищенности сайта. Например, типичный признак слабого отношения к администраторам сайта к информационной безопасности – это наличие у адреса /bitrix/modules/fileman/classes/general/html_editor.php вот такого ответа:
Помимо того, что внутренние файлы открыты к доступу, отсутствует обновление - так же включен показ ошибок, который позволит получить как минимум полные пути на сервере, как максимум - благополучно отлаживать злоумышленнику процесс взлома.
Разумеется, это не значит безусловного наличия уязвимости в нем, но говорит нам о том, что сайт стоит проверить. А при отсутствии обновления - вероятность того, что сайт был скомпрометирован - гораздо выше нуля.
Для тех, кто не первый раз знакомится с закрытием дыр в популярной CMS Bitrix – знает этот файл, т.к. уязвимость в нем правится одной из первых, и появилась она там одной из первых (вторичное распространение уязвимости после массовых дефейсов сайтов с модулем vote). В нем размещался скрипт подобного вида:
У нормального (обновленного) сайта при открытии данной страницы должно выводиться логичное содержимое, например, так:
Т.е. даже при наличии уязвимости не должно быть возможности ее активировать без доступа к сайту.
Отвлечемся и проверим – сколько сайтов имеют прямой доступ к этому файлу.
Анализируем открытость ядра для доступа извне
Для этого - смотрим процент сборок, у которых разрешен прямой доступ к исполнительным файлам ядра. Довольно простой тест, не требующего ничего лишнего.
Проверка осуществлялась опять же по всем сборкам битрикс (включая обновленные). При проверке 5511 сайтов на битрикс мы имеем примерно такую статистику:
Т.е. как минимум от 15% до 20% сайтов являются потенциально уязвимыми перед взломом и требующими дополнительных действий по закрытию уязвимостей.
Такая уязвимость либо закрывается вручную, либо – через обновление.
К слову, это только одна из уязвимостей, которые массово реплицировались на сайтах битрикс. Есть и другие. Например, злосчастный модуль VOTE, с которого, вероятно, все и началось (включая реплицирование дополнительных уязвимостей, как с файлом html_editor.php).
Или другой файл - /bitrix/modules/fileman/admin/fileman_html_editor_action.php
В нем содержалась уязвимость, позволяющая выполнить любое действие от администратора без авторизации.
Этот файл тоже не должен открываться свободно, при его открытии должен показываться 403 код.
ВАЖНО: Пока не закрыть все уязвимости – смысла в лечении не будет.
Разумеется, попытки чистки сайтов проводятся постоянно – т.к. нормальная эксплуатация зараженного ресурса, мягко говоря, затруднена.
Например, на одном сайте я обнаружил даже такую защиту на внутренней папке /bitrix/:
Т.е. какие-то «специалисты по информационной безопасности» (в простонародье - «компьютерщики») пытались закрыть доступ «ботам» к уязвимости через «капчу». По сути – забили сыром вход в мышиную нору.
Возможно решали другую проблему (обилия ботов) и перегрузку ресурсов сервера, но, есть немалая вероятность что обилие ботов в этом случае как раз являются не причиной нагрузки, а следствием уже проведенного взлома сайта.
Т.е. нередко кроме адекватных решений – мы видим много попыток бороться со следствием, а не с причиной.
Решит ли обновление проблему?
Очевидным ответом на вопрос «Что делать» кажется ответ: «Обновиться».
И это действительно так, но лишь отчасти: не все так просто, как кажется.
Обновление закроет уже имеющиеся базовые уязвимости в ядре, однако ничего не сделает с уязвимостями, которые уже были загружены на сайт в процессе первичного взлома.
Так мы встречаемся со стандартной проблемой:
Мне все почистили, все заработало – а через 3 дня появилось вновь.
Что делать?
Уязвимые сайты можно разделить на два вида:
- Имеющие уязвимость, но куда еще не ступала рука злоумышленника.
Здесь решение простое – обновляемся, проверяем, и все. Отделались легким испугом. - Имеющие уязвимость, куда рука уже ступала (взломанные).
Здесь решение сложнее и зависит от степени внедрения зловредного кода.
Общий порядок действия:
1. Краткий аудит безопасности.
Выяснить, есть ли на сайте вирусы, есть ли уязвимости и определить порядок действий (требуется ли чистка, обновление и тп). Это может сделать любой специалист по информационной безопасности. Если сайт находится на платном обслуживании - рекомендую заставить организацию провести аудит безопасности и обновить все системы.
2. Бекап текущей версии сайта (даже с вирусами)
В процессе чистки могут возникнуть сложности, поэтому нам нужна точка восстановления, когда все работало (в которую нам можно вернуться).
В случае, если это возможно – откатиться на версию без вирусов средствами хостинг-провайдера.
3. Восстановление целостности ядра (по возможности)
Этот механизм позволяет перегрузить все файлы ядра на исходные. Это штатный механизм Битрикса, и грех им не воспользоваться: таким образом все вредоносные включения в ядро будут перезаписаны исходным кодом производителя ПО.
Одно но: работает только при активной техподдержке (лицензии).
Еще одной проблемой является то, что ядро могло модифицироваться программистами, при перезаписи все изменения пропадут. Поэтому бездумное применение данного инструмента лично мной крайне не рекомендуется.
4. Непосредственно чистка от вирусов и уязвимостей.
К сожалению, эту процедуру можно проводить только вручную. Все инструменты хостинга (Всевозможные защиты, AI-сканеры и прочие маркетинговые инструменты - покажет не самую большую эффективность, т.к. определяет лишь малую часть залитых уязвимостей и шеллов). Можно пользоваться плагинами и инструментами поиска уязвимостей, шеллов и подозрительных файлов (например, Bitrix.Xscan, AI-bolit, CLAVAM и др.) – но анализировать их результаты так же придется руками.
Проблемы все те же – в битрикс очень большая структура углубленности файлов, и вредоносный файл может быть загружен так глубоко, что визуально (без сканеров) найти его невозможно, даже если знаете что ищете.
5. Обновление системы на текущей версии PHP
После чистки системы необходимо провести обновление, чтобы закрыть известные уязвимости. Здесь могут возникнуть проблемы с версиями PHP: Bitrix на сегодня настоятельно рекомендует использовать современную версию PHP 8.1+ (к слову - небезосновательно), при этом я встречался с сайтами, до сих пор работающими на PHP5.4 (!). Разумеется, смена на сервере PHP5 на PHP8 приведет к тому, что сайт не будет работать вообще. 100%.
Процесс перехода решается индивидуально – поэтапно, через тернии к звездам: через PHP5 -> PHP7.1 -> PHP7.4 -> PHP8.1 -> PHP8.3. С правками возникающих ошибок «на лету» на каждом этапе. Разумеется, каждый проект индивидуален.
Обращу внимание, что все обновления проводятся также только при активной техподдержке (лицензии). Ибо нечего!
Так же обращу внимание, что не все платные модули работают на PHP8 без обновления. Т.е. платные модули могут так же потребовать покупки новой лицензии.
6. После обновления системы нужно проверить работоспособность сайта.
После всех работ по обновлению (особенно это касается смены версий PHP) возможно появление артефактов и ошибок шаблонов, плагинов и в целом многих модулей. Решение проблем – только по мере поступления.
7. Настройка контроля целостности ядра и отслеживание изменений.
Это нужно, чтобы отслеживать изменения внутри файлов на сервере – при появлении новых файлов или изменении старых придет уведомление, которое будет содержать информацию об изменении. Если оно не безопасно – значит, на сайте осталось уязвимость. Которую элементарно можно выявить и устранить немедленно, как говорится – по горячим следам.
Итого:
Если у вас есть подозрения на то, что ваш сайт подвергся взлому или вы никогда его не обновляли – необходимо обратиться к специалисту, который поддерживает сайт (либо интернет-агентству, которое поддерживает его и настоять на проведении всех профилактических процедур).
Но, как показывает практика, без должного опыта полностью избавить сайт от вирусов получается далеко не с первого раза.
Вызвано это тем, что технические специалисты удаляют явный вредоносный файл (например - про который им сказали в техподдержке хостинга), однако основные уязвимости остаются открытыми.
Лучше обращаться к техническим специалистам, которые специализируются на информационной безопасности и имеют положительный опыт решения проблем с конкретной CMS.
Если у вас есть подозрения, что ваш сайт был взломан или вы давно (или никогда) не проводили обновление - вы так же можете обратиться ко мне.
- Более 200+ искалеченных сайтов на Битрикс прошли через восстановление моими руками.
- Аудит - бесплатно.
- На все работы по нейтрализации вирусов и уязвимостей предоставляется гарантия 6 мес.
- Сотрудничаю с Digital-агентствами
На нашем сайте вы найдете так же экспресс-проверку:
Форма экспресс проверки сайта Bitrix »
Там можно кратко проверить сайт на уровень текущей безопасности вашей сборки и немного на типичные признаки взлома или уязвимости.
Повысим безопасность ваших сайтов вместе!
Почта для обратной связи – bitrix@sysadmin-note.ru
Телеграм для быстрой связи - @bitrixsafe