Спасибо, Elasticweb.
Фон
У меня есть один сайт, перенесенный с этого хостинга задолго до обнаружения уязвимости, разработанный двумя разными компаниями, названия которых я не буду называть по неизвестным причинам.Сайт претерпел существенные изменения, как в структуре интерфейса, так и в переходе на другую систему управления (значимый момент в этой истории).
Сайт живет своей жизнью, никого не беспокоит, как вдруг мне приходят запросы на определенный каталог, с периодичностью ровно в 1 минуту, с одного и того же ip. Плюс редкие запросы с разных IP, направленные на поиск административной панели сайта.
IP я, конечно, заблокировал, но он продолжал настаивать на своем.
Посмотрев логи ошибок и посещений, я решил проверить, что это за IP и кому он принадлежит. После некоторых манипуляций я узнаю, что айпи принадлежит Elasticweb, компании хостинг-провайдера, где располагалась предыдущая версия сайта, но аккаунт был неактивен и заброшен.
Недолго думая, я решил позвонить в их техподдержку и узнать, в чем собственно проблема, кто автор запросов и как долго она продлится( это длилось более 12 часов ).
К сожалению, ни на сайте этой компании, ни в открытых источниках я не нашел номера телефона, что и побудило меня написать тикет в техподдержку.
Начало
Первое, что бросилось в глаза, это нежелание поддержки детально разобраться в ситуации и просто закрыть тикет буквально после первого сообщения.
Так как у меня были подозрения, кто может стоять за этим поступком, я решил уточнить в техподдержке по поводу конкретного аккаунта( тот самый, где когда-то располагался сайт ).
Подождав немного, на самом деле довольно долго, я получил ответ, что действительно все манипуляции проводились с этого аккаунта, но доступ к аккаунту можно получить через Email, указанный в аккаунте.
Я решил связаться с предыдущим разработчиком и получить от него информацию о доступе к аккаунту, на что получил четкий ответ, что аккаунт удален из-за неоплаты хостинга.
После небольшого уточнения с техподдержкой на тему «Нет доступа потому что» выяснилось, что аккаунт вроде бы удалили за неуплату и доступа к нему нет, но он все равно существует и продолжает работать как резервная версия (которая полностью противоречит предыдущим ответам).
Решил уточнить, как могло быть, что аккаунт удалили, доступа к нему из веб-версии нет, но все же кто-то смог поставить задачу на Крон.
Покопавшись в истории переписки, я нашел доступ к FTP этого хостинга, к этому аккаунту.
Что это за черт, подумал я и запустил FTP-клиент. Каково же было мое удивление, когда я увидел на экране содержимое корневого каталога и файлов резервной копии? Сказать, что я был удивлен, это ничего не сказать.
При якобы удаленном аккаунте и отсутствии доступа к нему каким-то чудесным образом я получил все содержимое аккаунта и смог легко перенести его на свой компьютер.
Проанализировав последние записанные логи, стало ясно.
что не только FTP работает, но и SSH открыто и Cron запускался через эту уязвимость.
Написал еще один запрос в техподдержку, получил очень интересный ответ. По словам хостера, предыдущий разработчик установил задание Cron после того, как все удалили, они не увидели в этом никакой проблемы и закрыли тикет.
Если перефразировать, то получится следующее:
- Мы знаем, что у нас есть дыра, позволяющая подключиться к заблокированному, неоплаченному и неактивному аккаунту, манипулировать им и получить вполне рабочий результат. Но мы ничего с этим делать не будем, потому что.
Разбирайтесь сами, но мы закрываем тикет и больше вас слушать не хотим.
Собственно, на этом общение с техподдержкой было завершено, и тикет был принудительно оформлен.
Причина и расследование
На основании этой истории я для себя узнал следующее:- При переезде сайта, смене владельца, разработчика или просто смене хостера обязательно измените все права доступа, пароли, имена каталогов, настройте доступ к панели управления по IP или тому подобное, а еще лучше смените систему управления.
если возможно.
Именно смена системы управления обеспечила мне защиту моих данных, поскольку по пути, к которому обращался злоумышленник, находился файл настроек на предыдущем хостинге, а возможно и встроенная оболочка для удаленного доступа, которая была оставленный предыдущим разработчиком.
- Не верьте хостеру на слово.
Проверяйте уязвимости сами, читайте отзывы и делайте резервные копии! Последний пункт очевиден, но не все ему следуют.
- Выбирайте хостера, который хотя бы предоставляет доступ к SSH на определенное время, когда он вам нужен.
Введите разные данные для учетных записей FTP, SSH, sFTP и других; поверьте, такой подход поможет не только сохранить данные, но и определить, с какого аккаунта были произведены манипуляции, если таковые были.
Все описанное выше имело место, о чем хотелось бы предупредить всех, кто читает эту статью.
Будьте осторожны, да пребудет с вами ваша поддержка! Теги: #информационная безопасность #Хостинг #Администрирование серверов #подарки по безопасности #веб-хостинг #доступ к серверу #безответственное отношение
-
Wow Аккаунты – Эпоха Портняжного Дела
19 Oct, 24 -
Поповский Николай Никитич.
19 Oct, 24 -
Java Преступно Недооценена
19 Oct, 24 -
Управляемая Капсула Против Рака
19 Oct, 24 -
Пятничный Разгон
19 Oct, 24 -
Zend Framework 1.0.0 Rc1 — Выпущена
19 Oct, 24
