Спасибо Elasticweb
Предыстория
Имеется у меня один сайт, перенесенный с данного хостинга задолго до обнаружения уязвимости, разработанный двумя разными компаниями, названий которых не назову по
Живет себе сайт своей жизнью, никому не мешает, как вдруг получаю я запросы на определенную директорию, с периодичностью ровно в 1 минуту, с одного и того же ip. Плюс редкие запросы с разных ip, направленные на поиск административной панели сайта. Разумеется ip я заблокировал, но он продолжал настаивать на своем.
Просмотрев логи ошибок и визитов, решил проверить, что же это за ip такой и кому принадлежит. Недолгими манипуляциями узнаю, что ip принадлежит компании Elasticweb, предоставляющей услуги хостинг провайдера, у которой и была расположена предыдущая версия сайта, но аккаунт был неактивен и заброшен.
Недолго думая решил позвонить в их техподдержку и узнать в чем собственно дело, кто автор запросов и как долго это будет продолжаться (продолжалось это больше 12 часов). К сожалению номера телефона я не обнаружил ни на сайте данной компании, ни в открытых источниках, что и сподвигло меня написать тикет в техподдержку.
Завязка
Первое, что мне бросилось в глаза, это нежелание поддержки подробно разобраться в ситуации и просто закрыть тикет, после буквально первого же сообщения.
Так как у меня были подозрения на то, кто может стоять за данным деянием, я решил уточнить у техподдержки про конкретный аккаунт (тот самый, на котором был когда то расположен сайт). Немного подождав,
Я решил связаться с предыдущим разработчиком и получить от него информацию по доступам к учетной записи, на что получил однозначный ответ о том, что учетная запись удалена по причине неуплаты хостинга.
После небольших разъяснений с техподдержкой на тему “Доступа нет потому, что”, выяснилось что аккаунт вроде как удален за неуплату и доступа к нему нет, но он все таки существует и продолжает работу в качестве бекап версии (что полность противоречит предыдущим ответам).
Решил уточнить как может быть такое, что учетная запись удалена, доступа к ней из Web версии нет, но все же кто то смог поставить задачу на Cron.
Порыскав в историях переписок, нашел доступы к FTP этого хостинга, к данной учетной записи.
Чем черт не шутит подумал я и запустил FTP клиент.
Каково же было мое удивление, когда на экране я увидел содержимое корневого каталога и файлы с бэкапом? Сказать, что я был удивлен, ничего не сказать. При якобы удаленной учетной записи и отсутствии доступа к ней, каким то чудесным образом, я получил все содержимое аккаунта и смог спокойно его перенести на свой компьютер. Проанализировав последние записанные логи, выяснилось. что не только FTP работает, но и SSH открыто и через данную уязвимость и был запущен Cron.
Написал еще один запрос в техподдержку, я получил весьма интересный ответ. По словам хостера, предыдущий разработчик установил Cron задачу уже после того как они все удалили, никакой проблемы в этом они не видят и тикет закрывают.
Если перефразировать, то получится следующее:
- Мы знаем, что у нас есть дыра, которая позволяет подключиться к заблокированному, неоплаченному и неактивному аккаунту, произвести манипуляции с ним и получить вполне себе рабочий результат. Но делать мы с этим ничего не будем, потому, что потому. Разбирайтесь сами, а мы закрываем тикет и не хотим больше Вас слушать.
Собственно на этом общение с техподдержкой было завершено, а тикет был принудительно завершен.
Причина и следствие
Исходя из данной истории, я выяснил для себя следующее:
- При переносе сайта, смене владельца, разработчика или просто смене хостера — обязательно меняйте все доступы, пароли, названия директорий, ставьте доступ в панель управления по IP или подобное, а еще лучше сменить систему управления если есть возможность. Именно смена системы управление и обеспечила мне защиту моих данных, потому как по пути к которому обращался злоумышленник, на прошлом хостинге лежал файл настроек, а возможно и вшитый shell для удаленного доступа, который оставил прошлый разработчик.
- Не доверяйте хостеру наслово. Проверяйте уязвимости сами, читайте отзывы и делайте бэкапы! Последний пункт очевиден, но не все его выполняют.
- Выбирайте хостера, у которого доступ к SSH как минимум открывается на определенное время, когда вам нужно. Ставьте разные данные для FTP, SSH, sFTP и прочих учетных записей, поверьте именно такой подход поможет не только спасти данные, но и определить с какой учетной записи производились манипуляции, если таковые были.
P.S. Данная статья никоем случаем не нацелена на принижение чьих бы то нибыло прав. Все описанное выше имело место быть, о чем я хотел бы предостеречь всех кто читает данную статью. Будьте внимательны, да прибудет с Вами бэкап!
Комментарии (44)
porutchik
03.12.2017 23:00А дыра-то в чём состоит?
Bel0g0r Автор
03.12.2017 23:53Дыра в том, что даже если аккаунт заблокирован, соответственно он не должен функционировать, то к нему все равно можно подключиться по FTP и SSH и выполнить какие то манипуляции. Плюс на неактивном ноде активно работал Cron и слал Wget.
Jef239
04.12.2017 03:00Если ключ от входной двери утерян — надо срочно залить бетоном всю квартиру?
Логичней просто занести квартиру в список пустующих, а при нехватке квартир — сменить дверь.
JohnnyBlack
04.12.2017 03:47Странная аналогия. В исполнении хостера за неуплату должно быть что-то вроде «no money, no honey», и это было бы более чем уместно. А тут сильно веет пофигизмом, мол, «Ну работает, ну и что? Подумаешь, кто-то балуется с cron'ом, сидя по SSH.»
Jef239
04.12.2017 11:44Цены на диски такие, что удалять и использовать освободившееся место — дороже выйдет. Контакт уже 10 лет работает по такой схеме, У него удаление — лишь исключение внешних ссылок. Но по прямой ссылке -удаленные фотки точно доступны. Вроде и удаленное видео — тоже.
Странно, что инстанс не остановили. Но, видимо, писать остановку инстансов — им дороже, чем терпеть лишнюю нагрузку.
Loki3000
04.12.2017 12:24А я вот не вижу в этом проблемы. Неоднократно встречал что после ухода, аккаунт еще достаточно длительное время поддерживается в относительно рабочем состоянии. Удобно — ушел, не понравилось — вернулся. Ну или по просрочкам платежей — не на следующий день аккаунт грохают, а постепенно отключают сервисы (или не отключают), предоставляя клиенту своеобразный кредит. Если не раздавать данные от аккаунта кому попало, то никакой проблемы в этом нет. В данном же случае проблема именно в том, что доступ к аккаунту был не пойми у кого.
mrkaban
04.12.2017 16:00ну да, с одной стороны, вопрос сколько времени прошло с перехода. И он сам не сменил пароли, и не очистил директорию. С другой, ТС сказал, что заблокировали… но часть функций продолжала работать.
kprohorow
04.12.2017 16:55Бетон лить не надо, а сменить личинку замка не мешало бы. Или заставить сдать ключи.
А то выходит так, что бывший постоялец может спокойно прийти обратно в квартиру, и делать там что угодно. В данном случае гадить на головы соседям и кидаться мусором в окна соседних домов.Jef239
05.12.2017 03:17Да не, ключей от входной двери нету. Зато есть окна, лоджия, мусоропровод, канализация, вентиляционный канал… — хороший червь через любую дырку пролезет, даже через газовую трубу. А уж спящему демону-убийце — можно и в стенку кирпичом постучать.
Так что все, кроме заливки бетоном, малоэффективно. Кто его знает, какой демон там в кладовке спит.
ambientos
03.12.2017 23:30Ничего не понял. Точнее, логике развития событий.
ambientos
03.12.2017 23:37Судя по скринам — у вас не сложились отношения с предыдущим разработчиком, вы ему не оплатили работу (или остаток), а в отместку они прекратили с вами сотрудничество? Что-то вы не договариваете.
Bel0g0r Автор
03.12.2017 23:51Разработчиков было 3. Я тот самый третий. Недоговариваю только то, что предыдущие разрабы взяли деньги (неплохие) и не выполнив около 30% работы слились кинув клиента.
А я на всякий случай решил перенести сайт на новый хост, так как от старого были доступы у предыдущих разрабов (первый вообще оформил хост на себя а не клиента), ну а дольше случилось что случилось.ambientos
04.12.2017 00:02Самое главное, что у заказчика есть доступ к домену, а остальное, по сути, ерунда…
dartraiden
03.12.2017 23:40Как я понял:
— есть два разных человека: владелец сайта и разработчик.
— владелец сайта перенёс сайт к другому хостеру, при этом, думая, что аккаунт у старого хостера отключён (поскольку платить за хостинг, естественно, перестали).
— но все логины-пароли, позволявшие подключиться к учётке по SSH и FTP, действуют, то есть, хостер почему-то не стал отключать аккаунт (и об этом косяке хостера нам и рассказывают).
— этим доступом воспользовался человек, разрабатывавший сайт — он знал пароль, зашёл по SSH и настроил автоматический запрос wget-ом на новый адрес сайта (возможно, таким образом он пытался DoS-ить ресурс в отместку за что-то).Bel0g0r Автор
03.12.2017 23:48Все верно, сайт был перенесен, и была смена CMS сайта. Ддоса не вышло, хоть и лог файлы плодились на протяжении суток.
JohnnyBlack
04.12.2017 00:41Сложно себе представить уровень знаний человека, пытающегося организовать таким образом DoS: 840 запросов за 14 часов. Даже не говоря про то, что параллельно с ежеминутными запросами в лог-файлы писались попытки найти админпанель (возможно, это уже был не он).
Evgeniy112
03.12.2017 23:46который раз убеждаюсь что лучше юзать какой нибуть hetzner или aws
batyrmastyr
04.12.2017 08:52В хецнере ребята не менее весёлые: пару раз в выходные наглухо зависала виртуалка (т.е. из их админки ни одним из трёх способов она даже не выключалась, не говоря о перезагрузке). Так они отвечали в середине понедельника что-то в духе «у меня фсё работает, не знаю чё у тебя, дорогой клиент, зависало» (после этого виртуалка и правда оживала, но в итоге решил свалить подальше)
evgenWebm
03.12.2017 23:49За картинки хочется отдельное спасибо сказать. Нет.
По истории. Не надо сорится с разработчиками. надо всегда контролировать ресурсы которые даете доступ.
В этой истории, вы сами себя наказали.ambientos
03.12.2017 23:54В этой истории не увидел вообще ничего особенного. Вместо того, чтобы тратить время на тёрки с техподдержкой — можно было просто ограничить доступ к сайту с конкретного ip и забыть об этом. А лучше настроить что-то вроде fail2ban один раз, чтобы не добавлять ip ручками.
Bel0g0r Автор
03.12.2017 23:57Блокировка ip конечно сразу же была настроена. Но запросы то поступать не перестали. Логи то пишутся по запросам даже с BanIP. Вот и пришлось написать тикет
JohnnyBlack
04.12.2017 00:35В этой истории не Bel0g0r себя наказал, а клиент, допустивший регистрацию чего-либо на разработчика и не взявший под личный контроль вопрос доступов/владения ресурсом. Автор же, как я понял, столкнулся с некоторыми последствиями такого упущения.
JohnnyBlack
03.12.2017 23:59Без обид, но тут
тридва момента:
1 — название статьи и её содержимое живут каждое немного своей жизнью;
2 — статья, по сути, о том, что были допущены ошибки с обеих сторон.
3 — куча всевозможных ошибок, как в тексте статьи, так и на скриншотах.
Доступ у вас и так был, то есть вы его не получали, просто никто не озаботился сменой паролей/закрытием тех же FTP/SSH. И смена CMS, как я понял, — чистой воды удача, т.к. в руках недоброжелателей оказались и конфигурационные файлы системы управления, и дампы БД при необходимости, и пароли от старой админкиWordpress.
При переносе сайта, смене владельца, разработчика или просто смене хостера — обязательно меняйте все доступы, пароли, названия директорий, ставьте доступ в панель управления по IP или подобное, а еще лучше сменить систему управления если есть возможность.
Так и хочется продолжить мысль: «сжигайте паспорт, уезжайте из страны, делайте хирургическое изменение лица». Это я к тому, что изменение директорий и смена CMS — явный перебор. Кто-то, не сильно разбирающийся в вопросе, может последовать этому совету и получит ещё большие проблемы, чем просто перенос сайта и смена доступов. Вполне хватит смены всех паролей хостинга, в том числе и от учёток в системе управления, обязательное удаление аккаунтовпредыдущихразработчиков и проверка системных файлов на целостность и кода темы на тот самый «левак» в виде шеллов, небольших хаков, позволяющих быстро сбрасывать пароли админа и т.п.
Подобных хостеров вообще лучше стороной обходить, и как можно дальше: там костыль на костыле, зачастую полное отсутствие какого-либо интереса к проблемам клиентов со стороны саппорта, ужасные настройки пресловутых шаредов и т.д. и т.п. В общем, себе дороже.
За информацию о такомубогомхостинге спасибо. Пожелаю вам в дальнейшем никак не соприкасаться с подобными компаниями :)Bel0g0r Автор
04.12.2017 00:01Согласен, возможно с рекомендациями перебрал немного. Но суть смены CMS в моем случае была такой, что старый хостинг, как бы странно не звучало, был оформлен не на клиента а на первого разработчика и восстановить доступ он мог по щелчку мышки. Поэтому и сменил хостера и перенес все и вся, а тот аккаунт перестал оплачиваться и был якобы заблокирован.
JohnnyBlack
04.12.2017 00:29У клиентов, считаю, обязательно нужно воспитывать некоторую грамотность в подобных вопросах и взывать к логике
по мере возможности. Сначала всё регистрируется на Васю, потом этот Вася пропадает по неизвестным причинам или отношения каким-либо образом портятся, и в итоге клиент остаётся с кучей проблем и головной болью — это классика жанра. В любом случае, хорошо, что вовремя со всем разобрались.Bel0g0r Автор
04.12.2017 00:34Как раз есть история по поводу зарегистрируйте на Васю он мой друг, а потом Вас пропадает а аккаунт блокируют за спам.
paluke
04.12.2017 07:53Я правильно понял, что можно иметь бесплатный ssh, с доступом в сеть? Расскажите, где дают такое.
batyrmastyr
04.12.2017 09:02Я однажды у Digital Ocean такое получил. У них панель в тот день как-то глюкнула, так что виртуалка из учётки удалилась, но не выключилась. Правда они после пинка ёё грохнули, вроде как.
Близкое к бесплатному: jino (услуги «50 гиг места» + «ssh доступ» за 46 рублей в месяц) или Aruba Cloud (там за евро уже полноценный VPS)
SystemXFiles
04.12.2017 09:33Помнится мне, у меня аналогичный прикол был с моим сайтом. Я одно время его сбэкапил и поставил заглушку, ибо постоянно были атаки на него и попытки взлома, аккаунт спустя время протух и на балансе было 0 рублей.
Естественно сайт был выключен уже самим хостинг-провайдером и полностью недоступен.
Потому спустя пару месяцев я случайно открываю ссылку на свой сайт и вижу, что он работает о_0.
Заглушка отображается, сайт подает все признаки жизни. Я конечно удивился, зашел в Личный кабинет и обнаружил, что там все выключено и на балансе денег по прежнему нет.
Я немного похалявил, недельку так, потом обратился в ТП и оказалось, что у них относительно недавно была миграция сайтов и вообще изменения в инфраструктуре, потому сайт неожиданно включился. В общем попросил их все же вырубить сайт =) Мне за активность сайта ничего не сделали, даже спасибо сказали.
С тех пор периодично захожу на аккаунт и смотрю состояние.
pligin
04.12.2017 10:21Пользовался услугами различных хостеров — у всех персонал поддержки не пытается помочь и считает тебя дибилом. Очень часто приходится общаться с REG.RU, т.к. большинство тех, с кем работаю, используют его — можно написать подробный тикет с фотографиями и скриншотами, описать все до мелочей… Но в итоге ответ "Зравствуйте. Вот вам страничка — почитайте..." А я как будто не читал… Поэтому лучше быть самому администратором своего сервера… пускай даже это будет VPS — они быстро удаляются при неуплате.
Bel0g0r Автор
04.12.2017 10:22Тут ситуация как раз в том, что это и был VPS. Его отключили за неуплату, но доступ к нему по FTP и SSH все равно был открыт.
bebeka
04.12.2017 11:20Так и не понял в чем собственно дыра. Не удалили аккаунт вовремя, возможно удалят позже. Если вы хотите сделать что-то плохое, это можно сделать и через новый аккаунт.
> Тут ситуация как раз в том, что это и был VPS.
Просмотрел тарифы провайдера, это шаред хостинг. На шареде доступ ограниченный, много чего не выйдет сделать.
Agel_Nash
04.12.2017 20:05Прочитав заголовок статьи сразу и не понял, что под удаленным аккаунтом подразумевается не активный/отключенный аккаунт
Konachan700
05.12.2017 18:31Сталкивался с таким поведением хостинга. Стоял сайт-визитка, стал не нужен, я просто перестал оплачивать хостинг. Сайт висел после прекращения оплаты больше года (домен я продлевал), ftp был доступен…
AkshinM
я конечно не поддерживаю хостера, уязвимость очевидно имеет место быть, но судя по данной истории хостер думает по другой логике:
«то что вас пытаются взломать эта ваша проблема с разработчиками. мы то тут при чем»
Однако подайте в суд на прошлых разработчиков за намеренное добавление шеллов, дыр в созданную ими ПО. это вполне наказуемо. в топку таких разработчиков