Спасибо Elasticweb
Предыстория
Имеется у меня один сайт, перенесенный с данного задолго до обнаружения уязвимости, разработанный двумя разными компаниями, названий которых не назову по непонятным понятным причинам. Сайт претерпел значительные изменения, как по структуре интерфейса, так и по переезду на другую систему управления (значимый момент в данной истории).
Живет себе сайт своей жизнью, никому не мешает, как вдруг получаю я запросы на определенную директорию, с периодичностью ровно в 1 минуту, с одного и того же ip. Плюс редкие запросы с разных ip, направленные на поиск административной панели сайта. Разумеется ip я заблокировал, но он продолжал настаивать на своем.
Просмотрев логи ошибок и визитов, решил проверить, что же это за ip такой и кому принадлежит. Недолгими манипуляциями узнаю, что ip принадлежит компании Elasticweb, предоставляющей услуги провайдера, у которой и была расположена предыдущая версия сайта, но аккаунт был неактивен и заброшен.
Недолго думая решил позвонить в их техподдержку и узнать в чем собственно дело, кто автор запросов и как долго это будет продолжаться (продолжалось это больше 12 часов). К сожалению номера телефона я не обнаружил ни на сайте данной компании, ни в открытых источниках, что и сподвигло меня написать тикет в техподдержку.
Завязка
Первое, что мне бросилось в глаза, это нежелание поддержки подробно разобраться в ситуации и просто закрыть тикет, после буквально первого же сообщения.
Так как у меня были подозрения на то, кто может стоять за данным деянием, я решил уточнить у техподдержки про конкретный аккаунт (тот самый, на котором был когда то расположен сайт). Немного подождав, на самом деле довольно долго, получил ответ, что действительно, с данного аккаунта проводились все манипуляции, но доступ к аккаунту можно получить по Email который указан в учетной записи.
Я решил связаться с предыдущим разработчиком и получить от него информацию по доступам к учетной записи, на что получил однозначный ответ о том, что учетная запись удалена по причине неуплаты .
После небольших разъяснений с техподдержкой на тему “Доступа нет потому, что”, выяснилось что аккаунт вроде как удален за неуплату и доступа к нему нет, но он все таки существует и продолжает работу в качестве бекап версии (что полность противоречит предыдущим ответам).
Решил уточнить как может быть такое, что учетная запись удалена, доступа к ней из Web версии нет, но все же кто то смог поставить задачу на Cron.
Порыскав в историях переписок, нашел доступы к FTP этого , к данной учетной записи.
Чем черт не шутит подумал я и запустил FTP клиент.
Каково же было мое удивление, когда на экране я увидел содержимое корневого каталога и файлы с бэкапом? Сказать, что я был удивлен, ничего не сказать. При якобы удаленной учетной записи и отсутствии доступа к ней, каким то чудесным образом, я получил все содержимое аккаунта и смог спокойно его перенести на свой компьютер. Проанализировав последние записанные логи, выяснилось. что не только FTP работает, но и SSH открыто и через данную уязвимость и был запущен Cron.
Написал еще один запрос в техподдержку, я получил весьма интересный ответ. По словам хостера, предыдущий разработчик установил Cron задачу уже после того как они все удалили, никакой проблемы в этом они не видят и тикет закрывают.
Если перефразировать, то получится следующее:
- Мы знаем, что у нас есть дыра, которая позволяет подключиться к заблокированному, неоплаченному и неактивному аккаунту, произвести манипуляции с ним и получить вполне себе рабочий результат. Но делать мы с этим ничего не будем, потому, что потому. Разбирайтесь сами, а мы закрываем тикет и не хотим больше Вас слушать.
Собственно на этом общение с техподдержкой было завершено, а тикет был принудительно завершен.
Причина и следствие
Исходя из данной истории, я выяснил для себя следующее:
- При переносе сайта, смене владельца, разработчика или просто смене хостера — обязательно меняйте все доступы, пароли, названия директорий, ставьте доступ в панель управления по IP или подобное, а еще лучше сменить систему управления если есть возможность. Именно смена системы управление и обеспечила мне защиту моих данных, потому как по пути к которому обращался злоумышленник, на прошлом лежал файл настроек, а возможно и вшитый shell для удаленного доступа, который оставил прошлый разработчик.
- Не доверяйте хостеру наслово. Проверяйте уязвимости сами, читайте отзывы и делайте бэкапы! Последний пункт очевиден, но не все его выполняют.
- Выбирайте хостера, у которого доступ к SSH как минимум открывается на определенное время, когда вам нужно. Ставьте разные данные для FTP, SSH, sFTP и прочих учетных записей, поверьте именно такой подход поможет не только спасти данные, но и определить с какой учетной записи производились манипуляции, если таковые были.
P.S. Данная статья никоем случаем не нацелена на принижение чьих бы то нибыло прав. Все описанное выше имело место быть, о чем я хотел бы предостеречь всех кто читает данную статью. Будьте внимательны, да прибудет с Вами бэкап!
Автор: Bel0g0r
