HTTP сессия зараженного сайта выглядит так:
Вредоносные редиректы замечены на следующие сайты:
- myfilestore.com
- filestore72.info
- file2store.info
- url2short.info
- filestore123.info
- url123.info
- dollarade.com
Причиной поискового редиректа является вирусный PHP код в базе данных. Данный «вредонос» можно обнаружить только просматривая базу данных (таблица datastore, запись plugins) или поиском по файлу дампа.
Код приклеивается к одному из хуков vBulletin — headinclude_javascript (плагину, который отвечает за вывод скриптов в блоке <head />.
Если открыть код данного плагина в интерфейсе vBulletin (там, где редактируется код плагинов), то вредоносный инжект не отображается. Это связано с символом, который добавлен перед вредоносным кодом.
Не рекомендуем удалять код напрямую из дампа или записи plugins, так как это нарушит структуру объекта plugins, который является сериализованным массивом. Достаточно найти инфицированный хук в интерфейсе vBulletin и пересохранить его. Этим вы удалите вредоносный код из базы. И уже после этого следует добавить сайт в консоль Google (панель вебмастера) и отправить на повторную проверку.
Теперь посмотрим на код вредоносного инжекта:
Скрипт состоит из двух логических блоков: бэкдор в строке 10 (к нему мы вернемся чуть позже) и непосредственно код, который внедряет редирект.
Как и в случае с Invision Power Board, редирект внедряется в два этапа (сначала в коде появляется скрипт, который обращается к misc.php, а затем уже происходит редирект на filestore72.info), и чтобы произошло перенаправление, должно выполнится несколько условий (строки 24-28, 38, 40). Хотя, с точки зрения сценария ручного обнаружения редиректа, все не так уж и сложно. Чтобы воспроизвести редирект на зараженный сайт:
- очистите куки браузера,
- откройте Google,
- введите имя домена и
- кликните по любой странице в результатах поиска —
А вот с автоматическим обнаружением все несколько сложнее: с ним может справиться только продвинутый веб-сканер, такой как , так как требуется эмулировать открытие сайта в браузере, сохранять контекст страницы при обнаружении двухэтапного внедрения и подставлять правильное значение поля Referer при формировании запроса к скриптам. Например, ни sucuri.sitecheck.ru, ни quttera.com не смогли обнаружить данный инжект. Они показывали только то, что сайт находится в блэклисте Google (что было понятно и без проверки).
В ходе расширенного мониторинга зараженного сайта мы также обнаружили интересный запрос к бэкдору (строка 10). Payload в него передается в зашифрованном виде (rot13 + base64).
Обнаружить данный запрос в обычном логе веб-сервера (access_log) практически невозможно, так как он отправляется методом POST, а адрес выглядит вполне легитимным (/register.php). Как будто произошла регистрация пользователя.
Если код расшифровать, то становится очевидным, что данный запрос вытаскивает пароли администратора, базы данных и другие технические параметры, которыми может пользоваться хакер для взлома и заражения сайта:
Если вы столкнулись с данным взломом и самостоятельно справиться не получается, для лечения сайта от вируса и защиты от взлома.
