company_banner

Расследование об информационной безопасности в Яндексе. Rdomn – скрытая угроза

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

    Злоумышленники постоянно совершенствуют методы внедрения вредоносного кода на веб-страницы зараженных сайтов. Если раньше это бывала модификация статического контента или php-скриптов CMS, то сейчас прибегают к использованию более сложных техник.



    В наши дни чаще всего заражению подвергается веб-сервер: устанавливаются вредоносные модули, внедряются вредоносные shared objects, либо же исполняемый файл перекомпилируется с вредоносной функциональностью. Для внедрения вредоносного JavaScript активно используется, например, Flash.

    В конце 2013 года наш робот начал детектировать большое количество вредоносных сайтов, на страницы которых был внедрен вредоносный Flash-объект. На странице размещался вот такой код.

    NB: Весь вредоносный код в посте дан в виде скриншотов для того, чтобы роботы не сочли и эту страницу заражённой.



    Этот flash-ролик загружался в браузер посетителя сайта и выполнял ActionScript, отправлявший запрос на адреса вида:
    hxxp://rdomn1394028305.hopto.me/gray-bg.png?img=<random_number>,
    например:
    hxxp://rdomn1394089507.hopto.me/gray-bg.png?img=0.28730966709554195

    В ответе на данный запрос передавались данные:



    Они представляли собой зашифрованный JavaScript-код, который расшифровывается и выполняется оператором eval. В итоге flash-ролик формировал iframe c URL’ом вида zzbdbqs.podzone.net/ytydhdy9.html.

    В iframe загружался frameset, подгружающий в браузер пользователя landing page от Neutrino Exploit Kit:



    Далее landing page работала следующим образом. Скрипт fshciym.js — это фреймворк jQuery версии 1.9.1. Он активно участвовал в процессе деобфускации, которая выполнялась в компактном теле главной подпрограммы скрипта:



    Функция wdb() возвращала разные js-операторы в зависимости от поданых на вход параметров. Таким образом, главная подпрограмма преобразовалась в код:



    Этот код подгружал с хостинга эксплойт-пака документ amnjzvktkqdbj и передавал его на вход функции ijvb, которая выполняла decodeURIComponent и последующее расшифрование документа. В итоге формировался комплексный скрипт из PluginDetect и кода:





    Этот код определял, какие программы установлены у пользователя (MS Office, VLC Player, Java, Flash), и в зависимости от результатов подгружал страницу с подходящими эксплойтами. Помимо интересной структуры вредоносного кода, выполняющегося в браузере пользователя, этот случай интересен способом заражения сервера.

    Несколько вебмастеров, обратившихся в нашу техподдержку, согласились дать нам root-доступ к тем своим серверам, которые были заражены. Мы выяснили, что для этого был использован вредоносный модуль для Apache. Он представляет собой отдельный .so (как правило, с именем mod_status.so), который прописывается в конфигурацию веб-сервера Apache. Для того чтобы его было сложнее обнаружить и удалить злоумышленники прописали загрузку модуля в конфигурационные скрипты других модулей (например, perl.conf). Измененным файлам конфигурации при помощи утилиты chattr устанавливались атрибуты, запрещающие изменение этих файлов. Саму же утилиту chattr после использования удаляли. Вместо нее записывался пустой файл с таким же названием и атрибутами, которые запрещают его удалять.

    В ходе инициализации модуль устанавливал несколько хуков, путем вызова функций:
    ap_hook_log_transaction,
    ap_hook_post_config,
    ap_hook_insert_filter,
    ap_register_output_filter




    При вызове процедуры post_config_hook (устанавливается вызовом ap_hook_post_config) происходила расшифровка и загрузка конфигурации модуля. Также создавался file mapping, который в дальнейшем использовался для межпроцессного взаимодействия. После этого этапа проверялись привилегии процесса и, если он имел права root, то происходил его fork и запускался бесконечный цикл. В нём модуль проверял наличие в системе сессии пользователя с правами root и запрещенных процессов, а при необходимости производил backconnect к удаленному серверу, давая злоумышленникам возможность удаленного управления.

    Внедрение вредоносного кода в HTTP-ответы сервера происходило в функции, которая устанавливается в качестве output filter веб-сервера Apache. Непосредственно перед внедрением вредоносный модуль проверял является ли HTTP-запрос управляющим, разрешено ли удаленное управление модулем вообще и нужно ли обновить его конфигурацию. Затем происходила серия проверок: не истекло ли время внедрения вредоносного кода и содержится ли он в конфигурации.

    Если результаты были положительными, следом проверялись флаги, сигнализирующие об активной сессии пользователя с правами root или о запрещенном процессе в системе. После проверялись параметры запроса и ответа – User-Agent, Content-Type, Referer, наличие подстрок, до или после которых происходит внедрение вредоносного кода. Если все эти проверки проходили успешно, то вредоносный код внедрялся в HTTP-ответ.
    Вредоносный модуль также позволял злоумышленникам осуществлять удаленное управление сервером. Для этого необходимо было послать HTTP запрос, который содержит заголовок “Pragma” со специальным значением. В ходе обработки такого запроса это значение декодировалось при помощи алгоритма Base64, расшифровывались первые 8 байт значения и первые 4 байта проверялись на равенство константе 0xDEADBEEF. Вторые 4 байта этого 8ми байтового блока представляли собой команду. Типы команд и их описание в таблице:
    Значение команды Описание
    10001h Получить статус
    10002h Обновить конфигурацию
    10003h Возобновить внедрение кода в HTTP ответы
    10004h Приостановить внедрение кода в HTTP ответы
    10005h Сделать бэкконнект к удаленному серверу

    Остальная часть значения Pragma — это полезная нагрузка для команды. Данные передавались в открытом виде за исключением пакета с обновлением конфигурации, который зашифрован при помощи алгоритма XTEA (11 раундов) в режиме ECB.
    Помимо этого, вредоносный модуль содержал функции для мониторинга выполняющихся в системе процессов и наличия сессии пользователя с правами root.

    В процессе мониторинга нежелательных процессов модуль читалсодержимое директории /proc/ и получал командную строку запущенных процессов путем чтения /proc/%d/cmdline. Полученные значения командных строк проверялись на наличие названий запрещенных процессов, которые перечислены в конфигурации вредоносного модуля. В случае обнаружения нежелательного процесса внедрение вредоносного кода в HTTP-ответы сервера временно прекращалось.

    Похожим образом происходила проверка сессии пользователя с правами root. Вредоносный модуль получал ID запущенных процессов, а для каждого процесса — его статус путем чтения /proc/%d/status. Далее из полученных данных модуль получал UID-ы и сравнивал их с 0. В случае, если процесс удовлетворял этому условию, то модуль смотрел его /proc/%d/fd и искал подстроку pts. Для тех файловых дескрипторов, для которых эта подстрока была найдена, получалось время последней модификации. Если разница текущего времени и полученного меньше значения, определенного в конфигурации, модуль считал, что в системе есть сессия пользователя root и также временно прекращал внедрение вредоносного кода.


    Начальная конфигурация вредоносного модуля


    Обновленная конфигурация вредоносного модуля (внутри виден вредоносный код для внедрения в HTTP-ответы)

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

    Следите за своими веб-серверами и сайтами на них, чтобы избежать заражения, потери посещаемости, а в случае хостинга – массового оттока клиентов. Наблюдайте за разметкой сайтов на выдаче – для этого можно зарегистрировать сайты в Яндекс.Вебмастере, а также читать письма о заражении, которые мы присылаем на стандартные email-адреса. В случае, если ваша компания является хостингом или разрабатывает соответствующее ПО, возможно, вам будет удобнее пользоваться Safe Browsing API, для которого мы недавно выпустили новый PHP SDK, или параметром «virused» в API Вебмастера.

    Берегите своих пользователей, сайты и серверы!

    Яндекс

    462,00

    Как мы делаем Яндекс

    Поделиться публикацией

    Похожие публикации

    Комментарии 33
      +8
      А самое интересное не написали — как модуль попадает на сервер?
        +2
        Очевидно что раз добавляются модули apache и вносятся изменения в конфиг, то для этого нужен root-доступ, то есть путём кражи данных пользователей. Либо, как вариант, exploit для серверного софта, того же apache + повышение привилегий.
          +23
          Скачать модуль ускорения apache бесплатно без регистрации и смс здесь
            +8
            Прочитавшие этот комментарий делятся на два типа: кликнувшие по слову здесь и некликнувшие.
              +77
              Ещё есть те, кто навел мышь. чтобы узнать куда ведёт ссылка
                +1
                Они относятся к некликнувшим.
                • НЛО прилетело и опубликовало эту надпись здесь
                    +3
                    Не хотевшим, а интересующимися. К тому-же весьма проблематично словить виндовый или линуксовый эксплойт под OS/2. ;)
                    • НЛО прилетело и опубликовало эту надпись здесь
                        0
                        Да, да. Мы вот сидим и думаем, нужен-ли отдельных хаб про OS/2 — eComStation — osFree на хабре или ну его нафиг?
            –4
            ключ по ssh подобрали
              +20
              «Запусти апач от рута! Это модно! Это круто!»
                0
                Прав же много никогда не бывает.
              +2
              Есть несколько простых советов, которыми, к сожалению, не все пользуются, поэтому у злоумышленников и есть возможность устанавливать вредоносные модули Apache.

              Нужно очень тщательно беречь свои реквизиты для FTP- и SSH-доступа, а также доступа к системам настройки веб-серверов:
              1) предоставлять root-доступ только тем, кому доверяете;
              2) пароль должен быть по-настоящему сложным, его нужно регулярно менять и нельзя отправлять в открытом виде;
              3) если сервер настраивается с компьютера или устройства, на котором Microsoft Windows, MacOS, Android – нужно, чтобы на нём обязательно были антивирус и firewall;
              4) необходимо, чтобы соединение было зашифрованным, нужно обращать внимание на валидность сертификатов и сообщения об ошибках, связанных с ними, с осторожностью пользоваться прокси транспортного уровня.
                +6
                И это все оказывается бесполезным в результате не обновленной Убунты с php-cgi и дырявым ядром) После чего приходит ботнет, через пару дней приходит ботовод, получает рут и делает зло.
                blog.imperva.com/2014/03/threat-advisory-php-cgi-at-your-command.html

                Это я к тому, что вариантов проникновения много, и Ваши советы не полные и не учитывают наиболее частые сценарии.

                Далее: ваши советы можно и нужно улучшить.

                1) Не представлять рут доступ. Если нужно, то только через SUDO.
                2) Никакой аутентификации по паролям. Ключи.

                ФТП — зло, противоречит пункту 4, только если не VPN или FTPS. И то, зачем FTP, если есть SSH?
                  +1
                  Плюс ко всему, часто заражение начинается с эксплуатации уязвимости в скриптах какой-нибудь популярной CMS. Далее осуществляется загрузка на сервер php shell'а, а там уже как получится.
                  В этой связи, необходимо следить за актуальностью версий используемых CMS. Если по каким-то причинам обновить CMS до актуальной версии не представляется возможным, как показывает практика, довольно эффективной мерой является максимальное ограничение прав на запись в поддиректориях таких сайтов (хотя, это, конечно, не панацея).
                    +1
                    Более полное описание, как не допустить заражения сайта в общем случае, тоже есть, help.yandex.ru/webmaster/security/protecting-site.xml. Но даже если самые простые меры выполнять, не вызывающие больших неудобств и не требующие глубоких технических знаний, то вероятность, что сайт попадёт под автоматизированное, массовое заражение, уже существенно снижается. К сожалению, не все даже это делают.
                      0
                      Все равно это советы для «широкой, неподготовленной аудитории кастомеров, которых не надо загружать излишней и 'сложной' информацией». Но вообщем это сойдет для определённой целевой аудитории.
                  0
                  5) На продакшн-серверах отключить SSH доступ на интерфейсах, смотрящих «в мир». Если сервер у провайдера, тогда SSH для его управления прикручивается только к интерфейсам за VPN.
                  6) Отказаться от FTP, перейдя на FTPS, SFTP, SCP.

                  В идеале на продакшн-сервере нет VPN сервера, есть только VPN клиент. Т.е. нет приложения, слушающего входящие порты. В данном случае VPN клиет подключается к VPN серверу, инициируя соединение и создавая защищённый канал. По этому каналу можно ходить на SSH, SFTP, etc. В результате сканеры портов на исследуемом сервере будут видеть со стороны мира открытым только 80 HTTP порт. Ничего сверхзаурядного. Просто и надёжно.
                  +21
                  Обычно такие посты читаем от ESET, но никак не от Yandex, было очень интересно.
                    +2
                    Роботы яндекса начали кушать swf файлы? Иначе как они определяют какая флешка хорошая а какая плохая?
                      0
                      Какая разница, какой объект проверять? Сигнатурному анализатору все равно.
                      Иногда вредоносный код в графические объекты инжектят (правда, это серверный вредоносный код, но тем не менее). Таким образом, все что отдает веб-сервер имеет смысл проверять.
                        0
                        Ну тут вы ошибаетесь. А если у меня на сайте 100 фильмов по 50 гигов? робот тоже регулярно будет их проверять? Я абсолютно уверен что робот кушает только определенные файлы.
                          0
                          Очевидно, есть ограничение на размер проверяемого объекта (в т.ч это могут быть ограничения движка). Но исключать объекты из проверки только по типу было бы крайне неэффективно в современных условиях.
                      +2
                      Этот код определял, какие программы установлены у пользователя

                      Помимо того, что доступ к navigator.plugins позволяет выполнять такие вот скрипты, по нему можно составить отпечаток, увеличивающий уникальность данного браузера в несколько раз. Сколько не искал, как можно ограничить доступ к списку плагинов из JS в различных браузерах — так и не нашел.
                      • НЛО прилетело и опубликовало эту надпись здесь
                          0
                          Хром даже при отключении плагинов в настройках продолжает выдавать их список скриптам на странице. Это смешно.

                          С другой стороны, сразу виден уровень современного разработчика. «Какой дурак будет отключать плагины? А JS? У нас половина браузера на нём написана, ха-ха-ха!»
                            0
                              0
                              А вот так заработало:

                              navigator.__defineGetter__("plugins", function() { return []; });
                              

                              Надо сделать расширение.
                                0
                                Обходится с помощью delete navigator.plugins;
                          +4
                          NB: Весь вредоносный код в посте дан в виде скриншотов для того, чтобы роботы не сочли и эту страницу заражённой.


                          Странный у вас алгоритм, не различающий чистый HTML-код от экранированного.

                          Получается, если я перепечатаю то, что на скриншоте и вставлю этот код на страницу какого-нибудь сайта, который корректно заменит символы < и > на соответствующие чаркоды, то при следующем индексировании данной страницы роботом Яндекса, тот посчитает её вредоносной?

                          Забавно :)
                            +1
                            Интернет обходится не только роботами Яндекса.
                              +1
                              Думаю, что чаркоды тут особой роли не играют. Если бы я писал такого рода парсер, то уделял внимание только словам и словосочетаниям с определенными характеристиками, и «мусор» типа %7С или & nbsp не учитывал бы.

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

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