Доброго времени суток, уважаемые хабрапользователи. Наконец-то у меня появился ещё один клиент позволивший на условиях анонимности описать решение его проблемы. Под катом рассказ о том, как происходила борьба с вредоносным кодом, появляющемся на сайтах заказчика несколькими путями одновременно. В связи с тем, что статьи большого объёма много кому не нравятся, в этот раз я постарался изложить всё как можно короче.
Исходные данные были следующими. Есть виртуальный сервер под управлением Ubuntu 10.04. Заказчик администрирует его своими силами. На сервере расположены 13 сайтов, 12 из которых развёрнуты на WordPress, а один состоит из статичных html-страниц. Управление их файловым содержимым идёт через FTP, причём только с 2 компьютеров. Один Mac, второй PC с Win7 и лицензионным KAV.
Регулярно, раз в 1-2 недели, происходит их заражение — в коде php-скриптов появляются обфусцированные вставки. При первой беседе клиент сказал что в скриптах постоянно появляется один и тот же iframe-код, но, как выяснилось позже, вредоносов там было несколько. В конце концов сайты повылетали из выдачи Google и Yandex, и постепенно количество посетителей стало равным нулю.
После первого осмотра выяснилось ещё несколько интересных деталей:
- Все блоги работали с MySQL от root`а.
- Для управления сайтами изнутри на был создан один пользователь, в чьей домашней папке и находились сразу все веб-директории.
- PHP был установлен в качестве модуля Apache, из-за чего последний работал со всеми сайтами от одного имени — www-data. Следовательно, для воздействия на каждый ресурс достаточно было найти изъян хотя бы на одном из них.
- В каждом блоге было установлено множество плагинов связанных с безопасностью — какие-то WP-сканеры, проверяльщики контрольных сумм и много чего ещё.
- Во многих файлах вредоносный код занимал места больше чем родной — при повторном заражении роботы не проверяли наличие в скриптах своего кода.
Всё это серьёзно прибавляло хлопот. На этом этапе стало ясно что проблема не простая, и чтоб избавить клиента от этой беды необходимо работать не только с паролями FTP и защитой клиентских машин (как это часто бывает в подобных ситуациях).
Далее был составлен список возможных путей заражения, каждый из которых нужно было проверить. В первую очередь, просто из-за своей распространённости, рассматривался вариант инфицирования с помощью украденных ранее паролей от сервисов удалённого доступа. Конечно свежий KAV на Win-машине является хорошим аргументом, но пароли могли быть украдены до того как антивирус был установлен. И не факт что администратор их сразу сменит.
На второе место поставили заражение через всевозможные бэкдоры. Допустим что когда-то администратор не вовремя обновил WP и на сайт был залит какой-нибудь шелл, через который вредоносный код теперь постоянно даёт о себе знать.
И в качестве третьего варианта рассматривалось заражение через уязвимость в скриптах сайтов. В связи с невозможностью обновления по техническим причинам на некоторых ресурсах стоял WP 2.9.2. В момент выполнения работ для этой версии была известна только SQL-инъекция в функции TrackBack`а, которая клиентом ни на одном сайте не использовалась. Но не нужно забывать о плагинах и темах. В них тоже часто находят ошибки. Кроме того, на одном из сайтов был установлен форум phpBB версии 3.0.8. Он не был рабочим (нет соединения с БД, не верные данные в конфигурационном файле), но всё же решено было его проверить. В публичных источниках информации об уязвимостях данной версии я не нашёл, зато на официальном форуме есть тема (http://www.phpbb.com/community/viewtopic.php?f=46&t=2119662) в которой описывается её взлом. При этом подробностей изъяна нет, как и нет гарантии того, что форум этой версии не может быть взломан при отсутствии соединения с БД.
После этого были проверены логи веб- и ftp-сервера за последние несколько дней. Выяснились любопытные вещи. Один робот раз в день проходил авторизацию на FTP и тут же отключался. Видимо проверял валидность аккаунта. Ещё один ежедневно заходил на FTP, скачивал 12 всегда разных скриптов и, если в них не имелось вредоносных вставок, исправлял ситуацию. В логах веб-сервера засветился дорвей, куда люди приходили преимущественно с Яндекса. Нашёлся и странный редирект пользователей мобильных браузеров происходивший из разных точек сайтов. Он был реализован через корневые .htaccess. Кроме того, было обнаружено 3 веб-шелла к которым иногда шли POST-запросы. Вообщем все 12 сайтов просто кишили разного рода вредоносами.
Сперва клиентом предлагалось не трогать текущие опасные вставки и просто накатить чистую, как он думал, резервную копию, которая была сделана ещё до того как были замечены все эти неприятности. Но после детального изучения оказалось что она тоже имеет в себе всё вышеперечисленное, просто в меньшем количестве. Поэтому решено было разбираться с каждой проблемой отдельно.
Тут необходимо сделать отступление и сказать о том, что подобная борьба бесполезна если источники заражения не устранены. Можно чистить код хоть сколько — вредоносные вставки всё равно вернутся. Поэтому была проделана следующая работа:
- Для каждого из сайтов был создан отдельный MySQL-пользователь с правами доступа только на его БД.
- Для каждого сайта был создан отдельный пользователь в ОС и на его директорию были выставлены соответствующие права. Ни о каких 777 для директорий, указанных в документации WP по установке не шло и речи. Максимум права записи были только у владельца.
- Связка Apache и PHP была переделана с mod_php на php-cgi+suPHP для того, чтоб обеспечить отдельные php.ini и работу интерпретатора со скриптами сайтов от имени пользователей-владельцев.
- Доступ по FTP был разрешён только с сетей провайдера которым пользуется клиент.
- В БД каждого сайта были проверены таблицы с аккаунтами на наличие не весть откуда взявшихся администраторов.
- Удалены, по причине бесполезности, все плагины связанные с безопасностью WP.
- Закрыт доступ к упомянутому выше форуму.
- Установлены новые пароли на root`а MySQL, на пользователя ОС, который до этого использовался в целях администрирования, а также на администраторские аккаунты каждого из 12 сайтов.
Расчёт, после всех этих действий, был следующий. Как только вредоносный код и шеллы будут вычищены, мы станем просто ждать. Если что-то было упущено и заражение снова произойдёт, его источник можно будет вычислить мгновенно, ведь все сайты изолированы друг от друга как в файловой системе так и в БД.
Теперь следовало произвести чистку. Сперва был сделан простой скрипт, представляющий из себя сигнатурный сканнер кода. Последовательно собирались одна за другой обфусцированные вставки и помещались в его базу. Скрипт, в свою очередь, должен был по команде разом очистить все повреждённые файлы. Благодаря этой работе было найдено несколько вариантов редиректоров (работали по людям пришедшим с поисковиков) и один iframe, про который заказчик и говорил в самом начале. Затем был написан крон, регулярно проверяющий с помощью консольных утилит исходные коды сайтов на наличие в них фраз типа «system(», «base64_decode(» и т. д. В случае обнаружения таковых он должен был рапортовать на почту мне и администратору. Здесь нужно сказать что не всё то вирус что обфусцированно. В темах WP (а на каждом сайте они были не стандартные) было обнаружено множество таких вставок. Они представляли из себя своеобразную защиту от удаления копирайтов. Пришлось их привести в нормальный вид, дабы избежать ложных срабатываний.
После этого коды сайтов были разом почищены, дорвеи и шеллы удалены, .htaccess`ы исправлены. По истечению нескольких дней никаких изменений в файлах не наблюдалось, так что проблему можно было считать закрытой.
И ещё один момент. В процессе исследования дорвеев был найден хост, с которого по http грузился их контент. На этом хосте, на веб-сервере, было несколько директорий названных именами других взломанных сайтов. Быстренько убедившись в том, что на обнаруженных доменах тоже присутствуют дорвеи я написал их веб-мастерам и администраторам. К сожалению ни одного ответа я не получил. Начинка дорвеев на них сохраняется до сих пор. Зато удалось справиться с сервером-раздатчиком. Он оказался , арендованным у украинской компании, которая, получив жалобу, пару дней проводила свою проверку, а затем отключила этот сервер от сети.
Основываясь на всём вышесказанном, хотелось бы дать следующие рекомендации веб-мастерам, а также администраторам веб-ресурсов:
- Разделяйте сайты друг от друга как в БД, так и на уровне ОС — в случае заражения вы сразу определите уязвимый сайт, а значит быстрее будет найден изначальный изъян, через который вредоносный код попал на сервер.
- Если работаете в связке Apache2+PHP, то устанавливайте её так, чтоб скрипты каждого сайта запускались от имени его владельца (fcgi, cgi+suPHP, apache2-mpm-itk и т. д.) — так вредоносный код не сможет попав на один сайт заразить другие.
- Разрешайте FTP-доступ только для тех адресов, с которых вы работаете с сервером. Если вдруг вы отправитесь в поездку или смените провайдера, всегда можно подкорректировать белый список IP по SSH.
- Помните про стойкие пароли. В сети постоянно действует масса роботов подбирающих реквизиты доступа к FTP-серверам по стандартным связкам — admin:admin, имя_сайта:ftppassword и т.д.
- При установке веб-приложений не ставьте бездумно 777 на те директории, которые указаны в документации. Если веб-сервер запускает скрипты от имени владельца, и что-то в эти директории пишет, то разрешение на запись в них нужно не всем под ряд, а только владельцу скриптов (как правило это и владелец директорий, так что даже прав 700 вполне может хватить).
- Ну и стандартная фраза (говорят, если одни и те же слова много раз повторять человеку, то они попадут в подсознание) — следите за обновлениями установленных на ваших сайтах веб-приложений. По возможности подписывайтесь на их security-рассылки или соответствующие разделы форума поддержки. Там вы можете узнать о приближающейся проблеме на много раньше выхода патча.
Благодарю Вас за потраченное время. Надеюсь вы вынесли из этой статьи для себя что-нибудь полезное.
Автор: AntonKuzmin
