| Цитата | ||
|---|---|---|
написал:
|
|
|
Разработчикам |
Заражение сайтов
Заражение сайтов
|
|
|||||
|
|
|
|
|||
|
|
|
|
|
|||||
|
|
|
|
|||
|
|
|
Если что-то не так будет - напишите и посмотрю чтобы работало. на PHP 5-ку сразу говорю делать не буду  а с 7.0 до 8.4 чтобы работало - это да.
|
|
|||||
|
|
|
|
с модулем аккуратно надо - там сингатуры довольно широкие по вхождению в тело запроса, например echo
сингатуры в модуле "прибиты" хардкодом - не "порулить" к примеру если бы этот модуль был активирован на этом сайте - это пост бы не прошел в целом идея хорошая - хакерские запросы рубит, только нужно понимать куда подключать но если сайт уже заражен, тут только ручная чистка ... т.к. пролог может и не подключаться |
|
|
|
|
|
Алексей,
возник такой вопрос, если у Битрикса стоит свежее обновление , то не будет ли конфликтов по модулю Ammina StopVirus с Битриксом или наоборот? |
|
|
|
|
|
|
|||
|
|
|
|
Выпущено обновление модуля:
## 1.1.0 * Добавлена возможность задания своих сигнатур поиска вирусов * Добавлены правила для отдельных страниц и IP адресов (в т.ч. использование индивидуальных сигнатур, включение/отключение детектирования вирусов, установление лимита памяти) * Сохранение информации о сработавшй сигнатуре поиска вирусов * Добавлен автоматический мигратор базы данных модуля при обновлении версий * Добавлены новые системные сигнатуры * Проверка наличия устаревшего кода защиты (с форума битрикс)
|
|
|
|
|
|
|
Друзья, сталкивался кто-нибудь с развитием атаки в установку apk с сайта?
Т.е. пользователь заходит на сайт с мобильного, и ему предлагают установку с сайта фирменного приложения. |
|
|
|
|
|
Добрый день. есть три сайта на разных хостингах:
php 7.3.2 1С-Битрикс: Управление сайтом 20.200.300 php 7.3.2 1С-Битрикс: Управление сайтом 20.0.1198 php 7.4.33 1С-Битрикс: Управление сайтом 18.0.9 Поставил модуль с гитхаба. При включении строки в init.php выдает следующее (пример с первого в списке): [ParseError] syntax error, unexpected 'array' (T_ARRAY), expecting function (T_FUNCTION) or const (T_CONST) (0) /home/httpd/vhosts/turistprofi.ru/httpdocs/bitrix/modules/ammina.stopvirus/lib/Migrator.php:12 #0: Bitrix\Main\Loader::autoLoad(string) #1: spl_autoload_call(string) /home/httpd/vhosts/turistprofi.ru/httpdocs/bitrix/modules/ammina.stopvirus/lib/Detector.php:57 #2: Ammina\StopVirus\Detector->run() /home/httpd/vhosts/turistprofi.ru/httpdocs/bitrix/modules/ammina.stopvirus/run.php:8 #3: include_once(string) /home/httpd/vhosts/turistprofi.ru/httpdocs/bitrix/tools/ammina.stopvirus.php:8 #4: include_once(string) /home/httpd/vhosts/turistprofi.ru/httpdocs/bitrix/php_interface/init.php:1 #5: include_once(string) /home/httpd/vhosts/turistprofi.ru/httpdocs/bitrix/modules/main/include.php:139 #6: require_once(string) /home/httpd/vhosts/turistprofi.ru/httpdocs/bitrix/modules/main/include/prolog_before.php:14 #7: require_once(string) /home/httpd/vhosts/turistprofi.ru/httpdocs/bitrix/modules/main/include/prolog.php:10 #8: require_once(string) /home/httpd/vhosts/turistprofi.ru/httpdocs/bitrix/header.php:1 #9: require(string) /home/httpd/vhosts/turistprofi.ru/httpdocs/catalog/index.php:2 #10: include_once(string) /home/httpd/vhosts/turistprofi.ru/httpdocs/bitrix/modules/main/include/urlrewrite.php:159 #11: include_once(string) /home/httpd/vhosts/turistprofi.ru/httpdocs/bitrix/urlrewrite.php:22 А с отключенной строкой в init.php если делать настройки по модулю, переходить по его меню, то также вываливается в ошибки |
|
|
|
|
А так - поправил мигратор. типизированное поле класса проскочило Скачайте заново архив с гитхаба, либо можно в файле модуля /bitrix/modules/ammina.stopvirus/lib/Migrator.php поправить строку 12 (убрать слово array). Т.е. было:
|
|
|||||||
|
|
|
|
Народ, в тему про дырку в include/mainpage/comp_catalog_ajax.php
Сегодня опять увидел левые файлы на сайте, по логам помониторил - оказалось, что сломали через установщик. Так, что, если кто не сделал, то вставьте фикс, о котором писалось ранее и в файл в папке: bitrix/modules/aspro.allcorp2/install/wizards/aspro/allcorp2/site/public/ru/inclu ну, и , соответственно, с другими файлами, где была уязвимость. |
|
|
|
|
|
Дмитрий Харитонов,
очень странно ... у Вас аппач? посмотрите ./bitrix/modules/.htaccess там должно быть Deny for All соответственно, через него не должны были взламывать, 403 на любой скрипт в /bitrix/modules/ должен отдавать |
|
|
|
|
Хотя в конфиге задано: location ~* ^/bitrix/(modules|local_cache|stack_cache|managed_cache|php_interface) { deny all; } |
|||
|
|
|
|
Дмитрий Харитонов,
ну значит не срабатывает правило - проверьте в чём дело у меня такое правило location ^~ /bitrix/modules { internal; } если что тут для nginx хороший конфиг - его юзаю если точнее тут |
|
|
|
|
может от версии nginx зависит. т.е. в моем случае получалось, что секция location / {..} шла раньше и запросы к modules обрабатывались ей. |
|||
|
|
|
|
|
|||||||
|
|
|
|
по хорошему еще папку /bitrix/wizards нужно закрывать аналогично, т.к. там тоже код не безопасный может быть. если нужен запуск мастера и будет заблокирован - проще временно открыть и потом закрыть
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|||||||
|
|
|
|
|||
|
|
|
|
Сейчас посмторел логи, хареры не унимаются...
194.190.153.24 - - [18/May/2025:21:11:17 +0300] "POST /bitrix/admin/esol_import_excel_cron_settings.php 194.190.153.24 - - [18/May/2025:21:11:17 +0300] "POST /bitrix/admin/esol_export_excel_cron_settings.php 194.190.153.24 - - [18/May/2025:21:11:17 +0300] "POST /bitrix/admin/esol_import_xml_cron_settings.php 194.190.153.24 - - [18/May/2025:21:11:18 +0300] "POST /bitrix/admin/esol_export_xml_cron_settings.php 194.190.153.24 - - [18/May/2025:21:11:19 +0300] "POST /bitrix/admin/kda_import_excel_cron_settings.php 194.190.153.24 - - [18/May/2025:21:11:20 +0300] "POST /bitrix/admin/kda_export_excel_cron_settings.php 194.190.153.24 - - [18/May/2025:21:11:20 +0300] "POST /bitrix/admin/esol_allimportexport_cron_settings.php 194.190.153.24 - - [18/May/2025:21:11:23 +0300] "POST /bitrix/admin/esol_massedit_profile.php 194.190.153.24 - - [18/May/2025:21:11:24 +0300] "GET /6940ecae5880.php Лично у меня ломали Битрикс с самыми последними обновлениями решений и платформы, для себя проблему решил кардинально - помимо фильтрации в nginx от греха подальше удалил оригинальный модуль от esol и вместо него установил переимнованый, в результатее имеем например /bitrix/admin/esoool_import_xml_cron_settings.php и хакеры лупят в пустоту... |
|
|
|
|
|
И что довольно важно, в секции server выше !!! всех location желательно прописать следующее:
# block SQL injections set $block_sql_injections 0; if ($query_string ~ "uni on.*select.*\(") {set $block_sql_injections 1;} if ($query_string ~ "union.*all.*sel ect.*") {set $block_sql_injections 1;} if ($query_string ~ "concat.*\(") {set $block_sql_injections 1;} if ($block_sql_injections = 1) {return 444;} # block base64 decode if ($query_string ~* "(file_put_contents|file_get_contents|base64_decode|js_error.txt|base64_|fwrite)") {return 444;} if ($http_referer ~* "(file_put_contents|file_get_contents|base64_decode|js_error.txt|base64_|fwrite)") {return 444;} if ($request_body ~* "(file_put_contents|file_get_contents|base64_decode|js_error.txt|base64_|fwrite)") {return 444;} # block file injections set $block_file_injections 0; if ($query_string ~ "[a-zA-Z0-9_]=http://") {set $block_file_injections 1;} if ($query_string ~ "[a-zA-Z0-9_]=(\.\.//?)+") {set $block_file_injections 1;} if ($query_string ~ "[a-zA-Z0-9_]=/([a-z0-9_.]//?)+") {set $block_file_injections 1;} if ($block_file_injections = 1) {return 444;} # block common exploits set $block_common_exploits 0; if ($query_string ~ "(<|%3C).*script.*(>|%3E)") {set $block_common_exploits 1;} if ($query_string ~ "GLOBALS(=|\[|\%[0-9A-Z]{0,2})") {set $block_common_exploits 1;} if ($query_string ~ "_REQUEST(=|\[|\%[0-9A-Z]{0,2})") {set $block_common_exploits 1;} if ($query_string ~ "proc/self/environ") {set $block_common_exploits 1;} if ($query_string ~ "mosConfig_[a-zA-Z_]{1,21}(=|\%3D)") {set $block_common_exploits 1;} if ($query_string ~ "base64_(en|de)code\(.*\)") {set $block_common_exploits 1;} if ($block_common_exploits = 1) {return 444;} Подобный конфиг не нов, но в тех что видел в случае атаки сервер отдает атакующему 403 ошибку, я же прописал 444 - при выполнении условий соединение закрывается без отправки данных клиенту, дабы хакеры не получали никакой инфы от атакуемого сервера |
||||
|
|
|
|||
