Небольшое погружение внутрь взломанного сайта

    Не секрет, что большинство сайтов в наши дни взламываются не вручную. Есть большая армия ботов, которые ищут уязвимость в скриптах сайтов, брутфорсят админ-панели CMS, FTP/SSH аккаунты, затем загружают небольшие скрипты-загрузчики или бэкдоры, через них внедряют в скрипты сайта несколько десятков управляющих «агентов», а также раскидывают по случайным каталогам, открытым на запись, веб-шеллы, спам-рассыльщики и другие вредоносные php (и иногда perl) скрипты. Изнутри зараженный сайт выглядит примерно так (фрагмент отчета сканера AI-BOLIT):



    Паттерны заражения (число, состав и назначение вредоносных скриптов) могут меняться. В данном случае статистика по заражению следующая:

    • 41 вставка бэкдора
    • 5 WSO веб-шеллов
    • 4 скрипта, внедряющих вредоносный код в .php файлы
    • 7 mail() спам-рассыльщиков
    • 2 спам-рассыльщика, работающих через SMTP
    • 1 бэкдор
    • 1 скрипт, внедряющий вредоносный код в wordpress/joomla скрипты

    Среди “вредоносов” есть всякие интересные экземпляры. Но речь сегодня пойдет не о них. Интереснее анализировать не столько статический вредоносный код в файлах, сколько процесс работы с «вредоносами» в динамике: какие запросы и в каком формате шлют командные центры внедренным бэкдорам, с какой интенсивностью, с какими параметрами и т.п. Кроме того, статический анализ для современных зловредов работает плохо, потому что некоторые скрипты не содержат payload’ов.

    Возьмем популярный бэкдор:



    Он состоит из одной-двух строк и служит для приема и исполнения PHP-кода. Payload «прилетает» в параметрах POST запроса и исполняется в тот же момент. Естественно, код payload'а нигде не сохраняется, поэтому процесс динамического анализа обычно упирается в отсутствие данных: нет логов с телом запросов, которые содержали бы исследуемый код.

    Чтобы проанализировать общение командного центра со своими «агентами», нужно логгировать HTTP запросы к вредоносным скрипта, а для этого нужно своевременно настроить протоколирование тела POST запроса в файл, что никогда не делается на shared-хостингах. На выделенных серверах, врочем, POST запросы с данными тоже не логгируются. Связано это с экономией ресурсов сервера и, в общем случае, отсутствием необходимости. Но это еще не все. Вторая проблема, связанная с анализом взлома и заражения сайта — это позднее обращение владельца зараженного сайта к специалистам.
    Почти всегда «пациенты» обращаются спустя 2-3 недели после появления первого вредоносного скрипта. То есть когда загруженный код уже внедрен, “отлежался” и начинает активно эксплуатируется злоумышленниками, а сайт блокируется хостингом по причине спам-рассылки, фишинговых страниц или атак на сторонние ресурс. Кстати, “отлеживается” код для того, чтобы замести следы взлома и сразу не вызвать подозрений у владельца сайта. Недели через две ротация логов делает свое «грязное» дело, стирая информацию о том, каким образом вредоносный код был загружен на сайт, и внедренные зловреды начинают создавать вредную «полезную» нагрузку: атаковать другие ресурсы, загружать на сайт дорвей-страницы, спам-рассыльщики, внедрять код редиректов на связки сплойтов, рассылать тонны спам писем с фишинговым контентом и пр.

    Но время от времени все-таки удается настроить логгирование на зараженном сайте и собрать внутренности запросов к вредоносным скриптам. Итак, что же скрыто от чужих глаз?

    Достаточно типично для такого заражения – это внедрение в корневой .htaccess редиректа на pharm-партнерку (продажа “виагры”, и т.п), wap-click партнерку (подписка на медиа-контент за SMS) или вредоносный ресурс (для проведения drive-by атак или загрузки трояна под видом обновления flash-плейера или антивируса).



    Редирект в данном случае внедряется следующим образом: в POST запросе передается php-код, который обернут в base64. Код исполняется с помощью бэкдора на взломанном сайте и добавляет свой обработчик 404 ошибки, при которой перебрасывает посетителей на сайт злоумышленника. Причем, достаточно иметь на какой-нибудь странице сайта отсутствующую картинку, скрипт или .css файл, чтобы у посетителя сработал редирект. Домены, на которые перенаправляются посетители, периодически меняются.

    Еще один пример лога запросов к внедренным бэкдорам и загруженным скриптам для спам-рассылки:



    Здесь также все данные передаются в base64 кодировке через POST- и COOKIE-переменные. Причем, исполняемые фрагменты дважды обернуты в base64 кодировку, дабы обойти WAFы и веб-сканнеры, которые в курсе про base64 и умеют ее декодировать. В раскодированном варианте запрос к бэкдору выглядит так:





    В payload’е выполняется обход каталогов и инжектирование кода, который будет искать wordpress файлы в доступных каталогах и делать одну из двух вещей: или внедрять в них вредоносный контент, или восстанавливать оригинальный контент файлов (так командный центр внедряет вредоносы на время или по-расписанию). Чтобы было сложнее найти измененные скрипты, дата модификации (mtime) у файлов выставляется по дате изменения одного из wordpress скриптов. В дополнение, выставляются атрибуты “только для чтения”, чтобы неопытные веб-мастера не смогли их отредактировать (многих это действительно озадачивает).

    Что касается другой «полезной» нагрузки — рассылки спама — контент дважды заворачивается в base64 и передается в параметрах POST запроса к спам-рассыльщику. А время от времени могут отсылать какие-то проверочные письма со служебной информацией:



    Интересное наблюдение: если с сайта удалить все вредоносные скрипты, то через несколько неудачных запросов процесс общения с «агентами» останавливается. То есть командный центр не пытается сразу же повторно взломать сайт и загрузить на него бэкдоры, видимо по той же самой причине – скрыть процесс первичной загрузки бэкдоров. Но если оставить при лечении хотя бы один бэкдор, то через него снова загрузят целую “вязанку” хакерских шеллов, бэкдоров и спам-рассыльщиков.
    Поэтому лечить сайт всегда нужно очень аккуратно.
    Метки:
    Поделиться публикацией
    Похожие публикации
    Комментарии 36
    • 0
      А есть ли в природе какие либо программы (shell/bash/perl скрипты) для анализа популярных CMS на предмет сверки того что на сайте с эталонным архивом этой CMS по контрольным суммам?
      Я это к тому, то если откинуть факт модификации исходных файлов установленной CMS самими разработчиками сайта, то зная версию CMS можно сравнить основные файлы с эталонными на предмет различий. Конечно если CMS нашпигована плагинами + менялся код, то тут все сложнее.
      • 0
        Если CMS оформить например в виде docker-контейнера, то там нет никаких проблем откатить систему к исходному виду.
        • 0
          Там можно и read-only сделать, чтобы сам код приложения нельзя было менять. Так же запретить загрузку скриптов из других папок.
        • +4
          Если после настройки сайта положить его под git (или другую систему контроля версий), то git status быстро покажет все изменения. В некоторых CMS есть встроенные механизмы контроля за изменениями системных файлов (ядра CMS). Также можно поискать плагины для своего "движка", они делают эталонный слепок файловой системы и регулярное слежение за изменениями файлов и их атрибутов.
          При желании можно найти системы контроля целостности под ваш сервер или установить хостовую систему обнаружения вторжений (HIDS), одним из элементов которой является integrity checker.
          • 0
            git как раз и используем на своем хостинге для контроля за особо важными сайтами, но для того же netcat к примеру, где почти вся рабочая часть php-кода в БД такой финт с git не сильно прокатит, а делать каждый день dump БД и ложить его в тот же git — сомнительно в плате контроля, будет огромная мешанина php-кода и sql кода.
            • 0
              Кладите только таблицы со скриптами в дамп.
              • 0
                Обновите уже неткат. Там давно уже не так.
                • 0
                  Мы то с радостью бы обновили, но клиенты не хотят за это платить деньги и сидят на старых неткатах аж еще версии 2.2. Так что работаем с тем что есть.
                  • 0
                    Ну, собственно, это одна из причин, по чему ломают сайты. 2.2 — этому релизу уже лет 10. Не хотят обновляться до свежих версий.
                    Хотя стоит это смешных денег.
                    • 0
                      Не знаю как там в Неткат. Но в 1С обновление с 7.7 на 8.х стоит безумных денег. И не потому что лицухи новые нужны, нет. И не потому что данные надо портировать, нет. Данные более-менее автоматически можно портировать. Просто уж очень много у людей которые всё еще (за столько лет то) не перешли — уж очень много собственной бизнеслогики. Плагинчики всякие, собственные документы, бизнеспроцессы и т.п… Повторюсь что не знаю Неткат, но судя по вашему обсуждению о том, что архитектура другая и т.п., думаю переход на свежак будет с потерей совместимости…
                      • 0
                        Нет, неткат очень хорош тем, что вы можете обновиться с 2.2, которой уже 10 лет, то свежей 5.7 и у вас ни чего не должно сломаться. При условии, что в исходный код не вносили изменений.

                        Т.е. все это время поддерживается обратная совместимость. А продление техподдержки на 2 недели (как раз, чтобы обновиться) стоит 25% от стоимости лицензии (от 1500 до 10 000 где-то, в зависимости от редакции) Т.е. если у вас сайт для бизнеса, то такая экономия — это обычное жлобство, которое потом выливается в гораздо большие траты.

                        У меня прямо сейчас есть клиент, у него сайт — дырявое решето, которого хостер блокирует за вредоносную активность каждую неделю. Каждую неделю регулярно начинаются простои, при этом сайт — центральный элемент бизнеса, он продавать должен.

                        На мое предложение взять и все сделать заново (единственное верное решение для того, что там есть) клиент думает уже месяц. При этом я понимаю, что он судорожно ищет где это сделать подешевле. И также понимаю, что с таким подходом он будет продолжать страдать и бизнес загнется все равно.
              • 0
                Главная проблема — большое количество мелких сайтов хостится на shared-хостингах, где нет возможности использовать Git. Как примеры — это Wordpress, Joomla, которые можно запустить практически везде. Усугубляет проблему, что они достаточно популярны и имеют огромное количество расширений разного качества, в том числе и плохого.
              • 0
                знаю только за Битрикс. Там есть инструмент "контроль целостности". Он позволяет и ядро и публичку по контрольной сумме проверять.
                Но проблема в том, что такие инструменты не закрывают весь сегмент возможных модификаций. Например, у того же битрикса если используется кеширвоание не в мемкеш, а в файлах, то следить за ними нереально (постоянная ротация же), а вот сложить между ними что-нибудь эдакое — за милое дело...
                Думаю, у других CMS ситуация схожая.
                • –2
                  Не совсем то, о чем Вы спрашиваете, но что то похожее. Не реклама.
                  Антивирус Санти, который сканирует файлы сайта на целостность. В случае изменения файлов, отправляет уведомление на почту пользователя.
                  • 0
                    Таких решений если не вагон, то тележка. Проблема в том, что они не гарантируют защиту от неизвестного типа заражения и не гарантируют защиту от вредоносного ПО, внедренного раньше подсчета контрольной суммы
                  • 0
                    Для сайтов на фреймворке WordPress — http://wp-cli.org/commands/core/verify-checksums/ — проверка контрольных сумм
                    • 0
                      Вордпресс стал фреймворком? Можно я это развижу?..
                      • 0
                        WordPress — уже давно вырос из движка для бложиков в полноценный фреймворк, девелоперскую платформу, каркас, на основе которого можно разработать проект любой сложности, а развидеть или нет дело ваше)
                        Не нужно так категорически относится к тому, о чем знаете поверхностно. Спасибо за понимание
                        • 0
                          Все мы не без греха. Я даже в 2015 говнокодил под ВП.
                          Все мы умные, брезгливые и т.п. Но всякое бывает.
                          Но в ВП простенький портал на десяток кастомных таксономий да дюжину кастомных типов записей, пятком шорткодов, пятком своих виджетов и дюжиной чужих плагинов — превращается в адов ад.
                          Задача на неделю в условиях простейшего MVC в ВП превращается в задачу на месяцы.
                          Но это то и ладно. Среду обитания можно создать и в рамках темы ВП (темы, Карл!).
                          Ад начинается когда ты берешь готовые темы и плагины. Ведь 2/3 из них уязвимы а то и впрямую содержат бекдоры.

                          Движок без DRY, SOLID, KISS и стандартов кодирования не может называться фреймворком.
                          Я не требую ООП или MVC (хотя SOLID обычно подразумевает ООП, но по большому счету эти принципы худо-бедно можно применить и в других парадигмах). Это во многом вкусовщина. Но есть некоторые основы основ.

                          Черт, вот простейшая задача сейчас стоит. В устаревшем но еще живеньком фреймворке сделана CRM. Полсотни контроллеров всего. Нужно интегрировать в нее телефонию. Интеграция с биллингами нескольких видов АТС (облачных и не очень). Проброс биллинговой информации в CRM, инициализация звонков из CRM. В общем более менее типовая задачка на дюжину классов.
                          Представляю себе это всё на ВП))))
                          • 0
                            Ад начинается когда ты берешь готовые темы и плагины

                            Все зависит от квалификации разработчика в конкретной области, я специализируюсь на WP, использую только проверенные временем плагины (в большинстве своем платные), остальные плагины мы пишем сами, соблюдая code-style и прочие премудрости.
                            Я не требую ООП или MVC

                            WP постепенно переходит на ООП, но в связи с обратной совместимостью — сделать это не так просто. MVC можно получить за счет какого-нибудь WP-MVC.
                            Движок без DRY, SOLID, KISS и стандартов кодирования

                            Стандарты кодирования WordPress
                            Проброс биллинговой информации в CRM

                            В моих проектах есть и биллинг и CRM и интеграция с 1С — все написано на базе WP, особых затруднений не наблюдаем.
                            Среду обитания можно создать и в рамках темы ВП

                            Так делать не нужно)
                            PS: я защищаю WordPress, потому что он мне близок, я его понимаю и принимаю таким какой он есть на данном этапе и слежу за его развитием, за развитием RestFull API, WP-CLI.
                            Удачного вам кодинга, коллега
                            • 0
                              WP не перейдет на ООП. Авторы могут. Движок нет.
                              Наследие такое, что это невозможно.
                              Сделать там можно всё, но это каша из топора. Нужно только не использовать петлю (только для основного цикла), отделям вью от контроллера, т.е. шаблоны становятся контроллерами, вьювы делаем отдельно, для простоты работы добавляем построитель запросов, активрекорд, валидацию. Вешаем какой-то автозагрузчик, чтобы хоть как-то разгрузить память. Пару классов заготовок под виджеты (у меня они даже есть вроде), под админку… пару хелперов чтобы более нативно и красиво управлять менюшкой в админке ибо при росте колва сущностей становится сложно… Всё это сделать можно. Для много чего уже есть даже плагины (будь они неладны). Но только есть нюанс. Если среда для себя состоит на 80% из внешних надстроек, то это каша из топора. Ядро тут не помогает а только мешает навязывая устаревшую архитектуру и обратную совместимость. Проще уйти туда где всё это нативно. Один черт учить современные принципы. Так лучше на живом чем-то а не на эмуляции. Для поддержки старых проектов? Блин, ну у каждого же всё свое. Это болезнь движков «из коробки ничего нет, но можно поставить». Плагины где в пять кликов создаешь новый тип записи или таксономии и хранишь его в базе — таких есть вагон и маленькая тележка. Заходишь такой в чужой проект перламутровые пуговицы пришить, а там уже свой велосипед стоит. Тащить проверенный в довесок к нему? Изучать чужой?
                              Всё что не нативно — не существует.

                              У Вас куча проверенных временем плагинов? Ой) Это неуловимый Джо и не более. Каждый пятый плагин из популярных имеет XSRF или прямую инъекцию. Но это как правило целенаправленный вектор. Нужно знать что этот пользователь админ именно этого сайта, и у него стоит именно этот плагин. Ну и да, признаюсь, большинство уязвимостей при этом позволяют лишь вандалить, уронить функционал, поудалять там и т.п. Получить контроль, повышать права и т.п. обычно не выйдет. Но это чертов авось, и ради чего? Нет, я понимаю, знаешь только ВП и ничего больше, учить лень потому то заказов хватает и денег достаточно, чего же более? К примеру один мой знакомый миллионер ездил на старенькой Таврии. Рабочая машина приличная, жене купил приличную, а сам на Таврии. Спрашивал мол в чем фишка. Сказал «а нафига? Машина еще не выработала свой ресурс. Начнет ломаться, продам, куплю новую.» Так собственно и сделал.

                              Вордпресс это как Битрикс и другие пережитки древности или необразованности. Но как Таврию не называют чудомашиной, так и тут — рухлять она и есть рухлять)
                  • –2
                    Спасибо. Любопытно наблюдать то, на что хакеры тратят свое время. Их бы навыки да в мирное русло…
                    • 0
                      Зараженный Wordpress это хорошо, но как быть с самодельными продуктами без git, с регулярно обновляющимся кодом скриптов? Вижу только один вариант — иметь локальную копию и регулярное сравнение контрольных сумм.
                      • 0
                        "но как быть с самодельными продуктами без git, с регулярно обновляющимся кодом скриптов"
                        git обязательно нужно в данном случае. Без git и разработка и обновление кода?
                      • 0
                        Подскажите пжлст инструменты для мониторинга джумлы.
                        • –1
                          возможно вам хватит Manul от Yandex?
                          yandex.ru/promo/manul#about
                          • 0
                            Спасибо, посмотрю. Софт типа) burp'a и Acunetix'a я знаю, но вот некоторые из инструментов ниасилил, т.к. не владею (достаточно) собственно теорией да у разных cms разные структуры сайтов.
                            • 0
                              эммм. боюсь я ввел вас в заблуждение поддавшись теме топика — взлому сайтов, а не контроля за структурой сайта.
                              • 0
                                Нуу… и это тоже оттуда. Прежде чем ломать, нужно определиться что и где, и тогда уже — чем и как. Ну и первая задача — спрятать и не отдавать )
                            • 0
                              Забавно, но криво. Запустил на двух сайтах, на обоих сканер умирает на каких-то безобидных файлах по разным причинам, один раз права файла (хостер создает закрытую папку внутри рабочей) второй не совсем понятно почему. В общем доходит до файла и глохнет. Сколько не перезапускай — застревает в одном месте. Глупо застревать. В результате даже проверить функционал не выходит.
                              Второе это то, что хотелось бы иметь лог всех мд5 всех файлов, и информацию о том какие папки в прошлый раз админ считал неизменяемыми, какие изменяемыми и т.п. Есть ли это — непонятно, но думаю нет…
                              Остается только форкать и писать свое) Выходит останется в основном только база сигнатур. А насколько она хороша не ясно…
                              • 0
                                ну по сути своей это всегда выход :) только кроме базы «сигнатур» нужен еще контроль за появившимися файлами. жаль что на shared хостингах git невозможен.
                                • 0
                                  Ну если сохранять базу сигнатур межбу сессиями сканирования, то новые файлы будут видны. Новые или модифицированные проверяются по белому/черному списку или вручную. Перед и после обновлений, установок плагинов и т.п. сообщаем об этом сканеру. Видя историю с хешами всегда можно понять динамику. Единственное что — базу сигнатур надо держать в надежном месте :)
                                  • 0
                                    да то что придумать систему можно это как-раз понятно. может быть даже кто-то уже делает такую систему.
                                  • 0
                                    Хватит уже пользоваться shared-хостингами без git. Эта экономия «у нас тариф за двадцать центов» — она потом приводит к попыткам судорожно изобрести собственные велосипеды и самопальные скрипты (это ещё ладно), но главное — это то, что не настоящая экономия, а псевдоэкономия. Вы потом в двадцать раз больше заплатите тем, что у вас нет нормальных инструментов.

                                    PS Как-то довелось попасть на экскурсию по закрытой части московского кремля. Много там красивых вещей, но запомнилась мне одна стена: простая, деревянная — покрыта витиеватым узором. Чтобы сделать узор размером 2х2 сантиметра — нужно было полдня сидеть аккуратно и тщательно выпиливать. А там эта стена огромных размеров — годы труда вложены, сидели с утра до вечера при лучине не разгибаясь.
                                    Но там это — искусство! И — не было у мастеров других инструментов, более производительных. А тут люди добровольно годами сидят и стругают самопальные скрипты, хотя рядом лежат высокопроизводительные эффективные, принятые в отрасли инструменты. Как так?? Зачем??
                                    • 0
                                      Вы наверное пишите на фреймворке который я очень не люблю. Его любители такие же категоричные :)
                                      Я не люблю проекты в которых обязательное требование «свой сервер или ВДС» по той причине что этим сервером кто-то должен заниматься. И если я отдаю проект клиенту, у клиента нет ИТ-штата, и клиент не заказывает хостинг у меня, то это должен быть шаред-хостинг от приличного хостера. Микросервисы для пятистраничной визитки и гит для деплоя этой визитки с обязательными нестандартными расширениями пхп для фич которые МОЖЕТ БЫТЬ понадобятся, это извините идиотизм.

                                      Второй кейс — у меня есть клиент, у которого под различные сервисы обеспечивающие рекламную поддержку основного проекта заведено около 20 аккаунтов у разных хостеров. Бюджет там приличный, так что первое время 50/100 баксов в год на акк никто не считал. Но объединив некоторые аккаунты, поменяв регистратора, отказавшись в половине случаев от ВДС/дорогих тарифов удалось не только 1,5к$ в год экономить, но и уменьшить з/п админа в два раза заменив ставку аутсорсом.
                                      • 0
                                        вы в целом говорите о коммерческих проектах, а когда проект делает обычный человек, можно сказать ученик на поприще? ему проще найти копеечный, а-то и бесплатный хостинг с php/mysql и запускать там свои штуки. этот человек еще не освоил unix shell, он далек от apt get или yum install не говоря уж о ./configure и make install. ну не сисадмин он и не advanced unix user. но контроллировать свой проект — хочется. вот и вынуждены люди пилить свои инструменты, скрипты и прочее. я уже не говорю о хостинге достаточном для работы скромного сайтика без особенной разработки и т.п нужного для скромной компании без it персонала и аутсорса.

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