Атака на DreamHost, продолжавшаяся с августа, привела к краже клиентских файлов, содержимого почтовых ящиков и учётных данных. Под удар попала, по словам компании, существенно меньшая доля чем 10% её примерно 400 тысяч платящих клиентов — но для любого хостинга это не «локальный инцидент», а риск для сайтов, почты, резервных копий и бизнес-процессов.
DreamHost раскрыл информацию о взломе на прошлой неделе, после нескольких дней сбоев и сброса паролей у части пользователей, сообщает TechCrunch. Компания указала в уведомлении для генпрокурора Калифорнии: атакующие воспользовались уязвимостью в файловом менеджере хостинга и получили токены сессий. Такой токен позволяет оставаться авторизованным после ввода пароля; в руках злоумышленника он может стать пропуском в аккаунт без необходимости подбирать или красть сам пароль.
Точный характер уязвимости DreamHost не раскрыл. Представитель компании также отказался объяснить, почему активность атакующих не заметили раньше, сославшись на продолжающееся расследование. При этом хостер отдельно заявил, что инцидент не связан с недавно обнаруженными уязвимостями в PHP. В публичном сообщении нет и точного числа пострадавших: формулировка «значительно меньше 10%» при заявленной клиентской базе всё равно оставляет диапазон до десятков тысяч аккаунтов.
Сценарий особенно неприятен сочетанием трёх типов доступа. Файловый менеджер нередко содержит исходники сайтов, конфигурации, архивы и экспорт баз данных. Почтовый ящик — это переписка, счета, документы, ссылки на сброс пароля и одноразовые коды, если организация всё ещё получает их по email. А сессионные токены дают возможность обойти даже хороший пароль, пока сессия не отозвана. Сброс пароля в такой ситуации нужен, но сам по себе не всегда закрывает все активные сессии и не отменяет уже скопированные данные.
Для разработчиков и администраторов здесь нет экзотики: общий хостинг часто превращается в точку концентрации секретов. В домашней папке проекта могут лежать .env-файлы, ключи к облачным сервисам, доступы к базам, SMTP-пароли, токены CI/CD и старые бэкапы. Даже если атакующие не получили прямой доступ к продакшен-серверу, такой набор данных может помочь им двигаться дальше — например, войти в сторонний сервис или убедительно атаковать сотрудников через фишинг от имени знакомого контакта.
Пользователям DreamHost разумно исходить из того, что затронутый аккаунт мог быть полностью просмотрен. В приоритете — сменить пароль хостинга и пароли, которые совпадали с ним, завершить активные сессии в критичных сервисах, перевыпустить ключи и токены из конфигураций, проверить правила пересылки почты и журналы входов. Владельцам сайтов стоит отдельно проверить файлы на незнакомые изменения, пользователей CMS, задания cron и параметры почтовой отправки. Если в почте хранились ссылки на восстановление доступа или документы клиентов, полезно предупредить команду о возможных правдоподобных фишинговых письмах.
Атака на DreamHost — ещё одно напоминание, что пароль давно перестал быть единственной границей аккаунта. Компания пока не назвала уязвимость, не объяснила задержку обнаружения и не уточнила масштаб. Главный вопрос теперь не только в том, сколько клиентов пострадало, но и в том, насколько быстро хостинг сможет показать, что пересмотрел контроль за доступом к файлам, сессиям и подозрительной активности.
