Похоже, сотрудник поддержки Рег.ру взломал мой сайт (много текста и скринов с доказательствами версии)
Несколько дней назад перенесли все наши сайты на замечательный виртуальный хостинг reg.ru, на отличный быстрый тариф VIP.
Сижу спокойненько занимаюсь настройкой сайта на битрикс и попутно создаю несколько заявок в тех.поддержку. Одна из заявок касалась ошибок при выполнении cron заданий. Мне некий сотрудник техподдержки Владислав ровно в 18:59 (похоже, время важно) отвечает:
Тут же мне на почту прилетает уведомление от битрикса о том, что под логином admin авторизовано новое устройство (чудо, что битрикс недавно внедрили эту функцию и чудо, что я её активировал несколько дней назад). Я тут же захожу в админку и вижу следующее:
Файла new.php у меня на хостинге не было. Бегом захожу на хостинг и смотрю что за файл. Вижу, что создан он ровно в 18:58:02 с таким содержимым:
То есть при открытии ссылки "сайт.ру/new.php" любой тут же получает права суперпользователя.
Я быстро переименовываю этот файл, ограничиваю права доступа к нему и на всякий случай, думая, что сайт заражён вирусом, выключаю полностью сайт.
Создаю заявку в поддержку о том, что сайт взломан и нужно посмотреть что случилось. Уточняю, что у меня установлены все последние обновления битрикс.
Получаю отписку:
Лезу в логи сайта и вижу, что некий IP 95.79.11.115 (по whois бьётся как динамический ip нижегородского дом.ру) зашёл на сайт через 10 секунд после размещения файла new.php, а ещё через пару секунд открыл его и получил доступ к админке.
Сканирую сайт на вирусы. Чисто. Пишу в поддержку:
Я начал проверять даты создания/изменения всех папок и файлов на сервере, пересматривать логи всех своих сайтов на этом хостинге за последние несколько дней в поисках того, как именно этот файл создался. Я даже поискал что могло его создать поиском по содержимому всех файлов. Всё чисто, никакого намёка на бэкдор или что-то подобное.
Думаю "вдруг хостинг дырявый?" (но оказалось, что дырявая поддержка).
Смотрю ещё раз логи и бросается в глаза, что первая строчка непосредственно перед взломом – это запрос тем же IP адресом 95.79.11.115 панели управления ISPmanager по адресу vip***.hosting.reg.ru:1500. Думаю "странно"... Проверяю журнал посещений ISPmanager и вижу кучу входов за последние 2 дня с неизвестных мне IP, но поддержка сразу успокаивает:
Я отметаю эти два адреса и начинаю изучать другие входы и нахожу только один ip 88.212.194.51 накануне в 5 утра. Поддержка отвечает, что он не их:
В журнале операций несколько действий в панели управления за последние два дня, по ничего критического.
Меняю все возможные пароли и вижу, что этот IP продолжает быть авторизован в панели управления хостингом и что-то в ней делает. Пишу сапорту в чатик:
Смотрю ещё внимательнее логи и вижу, что ровно в 18:58:02 (время создания файла для взлома на сервере) в логах есть вызов обычного скрипта сайта. Проверяю этот скрипт, он чист.
Развязка
И тут меня дёрнуло проверить весь журнал операций, по всем IP в панели управления хостингом. Нахожу строчку ровно в 18:58:02 с функцией file.upload, смотрю на IP и охреневаю:
Файл загружен именно тем IP, который принадлежит поддержке reg.ru!
Пишу им сообщение:
И тут я понял, что убил весь драгоценный вечер пятницы, сайт был в простое почти 5 часов в самое перспективное время его тематики, сайт может потерять позиции в выдаче, яндекс прислал уведомление о том, что мои товары больше не участвуют в поиске... И всё из-за каких-то нехороших людей в техподдержке.
За последние несколько дней у меня было много вопросов в техподдержку и, судя по логам, каждый раз при решении моего вопроса сотрудник техподдержки заходил в мою панель управления. То есть он получает доступ в момент принятия задачи и может делать на хостинге что угодно. К счастью, благодаря своевременному уведомлению от битрикс и моей реакции, так и осталось загадкой что именно хотел сделать сотрудник рег.ру получив доступ к админке моего сайта. Судя по всему, ничего сломать и разместить вредоносный код он не успел. Но мне предстоит ещё в этом убедиться проверив все настройки и базу данных.
Конечно, он может сказать, что хотел убедиться в правильности настройки моего сайта после изменения настроек на хостинге. Но что-то мне подсказывает, что это не так.
Теперь в раздумьях не перенести ли сайты в более безопасное место запросив возврат оплаченных вперёд 3 лет хостинга. При заражении сайтов вирусами можно хотя бы откатиться из бэкапа, а от ушлых сотрудников такой ненадёжной техподдержки вообще никак не защититься.
Объяснение сотрудника Рег.ру
P.S. Тот самый сотрудник техподдержки в 8 утра ответил на мой тикет:
И после этого Владислав находит ранее закаченный им файл, но который я переименовал и защитил атрибутами доступа, и так же молча его удаляет. То есть проводит операции с файлами на моём хостинге даже не считая нужным меня поставить в известность.
Прикольно. То есть для рег.ру это нормально заходить в админку сайта таким образом, не предупредив ни до ни после. А сотрудник техподдержки считает, что скрипт нужно теперь скорректировать, чтобы клиент вообще ничего не узнал.
P.S. Для меня осталось загадкой как можно проверить cron задания в панели битрикса. Вроде, там можно проверить только то, что агенты вообще переведены на cron. Настроек заданий я там не вижу.
Лет 20 назад, когда интернет был относительно свободным и люди не параноили по поводу и без повода было обычным делом по жалобе клиента на проблемы с сайтом - зайти к нему в админку на сайт, проверить и исправить настройки его сайта, чтобы решить проблему и всё это называлось "проактивное решение проблем у клиентов" - не спрашивая клиента ни о чём, так сказать "транспарентно". И вирусы бывало удаляли и шеллы и трояны и всё бесплатно.
Допускаю, что эта история всего лишь рецидив тех времён.
В целом ТС молодец. Даже, если в данном случае действия предпринимались с добрыми целями, внимательность к безопасности своих данных важна. На 1 случай добрых намерений приходится 100500 недобрых. Времена сейчас другие и интернет сейчас это не сообщество фриков-мемберов, а обиталище злобных и неприятных людей зачастую от которых можно ожидать чего угодно.
В глубине души я надеюсь, что всё было именно так.
Смущает только то, что по факту проблема выполнения заданий cron была очевидна (Fatal Error Insufficient shared memory) и решена сотрудником поддержки до того, как кто-то зашёл в админку. Ну и не представляю что настраивать в админке битрикса по крону.
Было у меня и другое обращение в поддержку, но там не было проблемы. Там был мой глупый вопрос что за warn`ы с upstream`ами я вижу в логах. Я получил ответ, что всё ок, переходите на VPS и закрыл тикет за 10 минут до всего этого.
Его комп может быть затроянен, в теории. И кто-то через него ломает. Либо даже не его комп, а что-то сидит в локалке, с общего айпишника.
Может быть. Но, по идее, у такой крупной компании должно быть всё отлично с локалкой и компами сотрудников. Слишком много у них клиентов и вирус давно бы наделал много шуму. А так хитрый, не очень опытный сотрудник потихоньку получает доступ к некоторым сайтам некоторых клиентов, быстренько прячет шелл или копирует ключики битрикса, а потом заметает следы. В это мне больше верится.
Чем дело кончилось?
Рег.ру считает нормальным таким образом заходить в админку клиента. Обещают доработать регламент. Надеюсь, что будут хотя бы предупреждать о таких вещах.
Добрый день, Александр!
Сожалеем, что вы столкнулись с подобной проблемой.
Многие наши пользователи менее опытны, чем вы. Поэтому для оперативного решения вопросов от клиентов в ряде случаев использовались инструменты для авторизации в CMS клиентов.
После проверки системы файл доступа удаляется автоматически, в этот раз, к сожалению, этого не произошло. Сотрудник действий никаких не совершал, ему нужно было лишь проверить наличие ошибок в админ-панели, которые могли возникнуть по вашему вопросу.
Со своей стороны мы внесли корректировки в регламенты работы службы поддержки, для предотвращения подобных случаев.
Надеемся, вы еще дадите нам шанс проявить себя с лучшей стороны.
В любом случае, благодарим, что помогли сделать наш сервис лучше!