Поиск по сайту

Небольшой пост об интересном бэкдоре, который мы нашли в плагине для Joomla. Этот бэкдор был так умело сделан, что сначала мы даже не понял, был ли это бэкдор или нет, хотя и знали, что здесь что-то не так. Вот как выглядел код плагина: На первый взгляд ничего подозрительного не видно. Ничего не зашифровано, ничего не обфусцировано, нет ни каких странных комментариев. Просто нормальный код плагина для Джумлы. Если посмотреть более внимательно, то вы увидите, что конструктор класса не является тем, чем кажется на первый взгляд. Первое, что можно заметить — это то, что die(); стоит в конце кода. Эта функция завершает выполнение текущего скрипта. Однако, это плагин для Joomla, что означает, что die(); убьет все процессы в Joomla. Как вы понимаете это не очень хорошо для плагина, особенно на стадии инициализации. Теперь вы можете заметить это: /123/e. Напоминает регулярное выражение с evalфлагом, которое мы постоянно видим в различных бэкдорах с "preg_replace". Видно, что если заменить $option на preg_replace, то получается типичный бэкдор с "preg_replace": preg_replace(«/123/e», $auth, 123); Поскольку 123 всегда равно 123, то код всегда будет принимать значение переменной $auth. Для того, чтобы наша гипотеза была верна, $option должно быть равно "preg_replace", а $auth должна содержать PHP код. Давайте посмотрим, возможно ли это. Видно, что обе переменные заполняются из Cookie, так что да — это вполне возможно. Как работает бэкдор. Описанный код предполагает, что бэкдор работает следующим образом: После того, как плагин был установлен на Joomla, он запускается каждый раз при загрузке любой страницы и конструктор класса в плагине всегда запускается на выполнение. P3 – этот триггер вызывает выполнение бэкдора. Без него Джумла работает как обычно. P2 — этот кук должен быть "preg_replace", P3 — здесь передается произвольный PHP код. Не все плагины вредоносны. В отличие от WordPress плагинов, о которых мы недавно писали, где вредоносный код был подсажен «пиратами»(которые пересобрали коммерческий плагин уже со своим бэкдором) этот случай не выглядит так, будто владелец сайта скачал на каком-то подозрительном ресурсе этот плагин для Joomla. Плагин InstantSuggestявляется бесплатным и едва ли широко известен (менее 400 загрузок ). Его реальный код не содержит функцию _counstruct(). Более вероятный сценарий заключается в следующем. Бэкдор был добавлен хакерами после взлома сайта, чтобы сохранить доступ к нему, даже если исходный дыра в безопасности была бы закрыта. Более того, похоже, что хакеры не встраивали бэкдор в уже существующий плагин, а просто установили свой плагин с бэкдором. Это проще, чем изменять существующие файлы, что может нарушить работу сайта и раскрыть попытку взлома. Кроме того, такой способ требует более сложного инжектора. В качестве доказательства этой гипотезы мы искали в Интернете бэкдор коды и всегда обнаруживали его внутри кода instantsuggest. Кстати, этот код также используется вне контекста Joomla с Joomla API запросами, подменяемыми простым вызовом @$_COOKIE. Даже в этих тех случаях он по-прежнему окружен кодомinstantsuggest. Похоже, злоумышленники считают, что это делает код менее подозрительным :) Оригинальный текст статьи здесь.