Всем привет.
Сегодня я хотел бы поговорить о безопасности хостингов и о том, насколько все плохо в этой области. В середине 2014 года я читал очередную модную на тот момент статью о защите сайтов от вирусов и задался вопросом, насколько безопасны хостинги, и можно ли использовать уязвимости для массового взлома сайтов. Если коротко, то все гораздо хуже, чем я ожидал, а эта история растянулась на 3 года.
Большая часть хостингов выглядит примерно так
В далеком 2014 году я начал с проверки , которым пользовался в то время, и сразу же нашел CSRF на смену данных учетной записи. Если рассказывать о CSRF максимально просто, то эта уязвимость позволяет подделывать запросы от имени пользователя. Когда вы отправляете HTML-форму с одного домена на другой, браузер автоматически добавит в запрос ваши куки, установленные для целевого домена. Это позволяет злоумышленнику, не имея доступа к вашим кукам, отправить запрос на целевой домен от вашего имени с вашими куками. Для защиты от этой атаки используются CSRF-токены, проверка заголовка referer или ввод пароля для подтверждения важных запросов (это очень странное и небезопасное решение). Более подробно можно прочитать об этом в Википедии.
Я быстро проверил еще 10 крупных хостингов, больше, чем на половине нашлась такая уязвимость. Фактически, я мог создать специальную страницу, после перехода на которую авторизованного пользователя его адрес электронной почты менялся на мой, а я мог восстановить пароль по почте и доступ к аккаунту и всем файлам. Звучит страшно, но это не смертельно. Для успешного выполнения атаки необходимо найти пользователя, заманить его на специальную страницу, при этом пользователь должен быть авторизован в панели управления . Это значительно уменьшает шансы на успешный массовый взлом.
Однако, большая часть хостингов использует готовые панели управления. При этом администратор — это такой же аккаунт пользователя с кучей дополнительный прав: часто он имеет доступ ко всем аккаунтам на сервере. Для успешной атаки достаточно было создать страницу, код на которой автоматически отправит запрос на смену почты администратора, создание новой учётной записи с дополнительными правами или выполнение любого другого действия, которое возможно в панели управления. При желании можно сменить расширение такой странице на .jpg и разместить на ней скриншот, чтобы скрыть то, что происходит на ней на самом деле. После этого можно создавать тикет «Помогите, сайт не работает, вот скриншот ошибки» и прикладывать ссылку на страницу. После перехода администратора на эту страницу злоумышленник получает доступ ко всем аккаунтам пользователей .
Для выбора хостингов я объединил данные от нескольких рейтингов, после этого проверял цели на наличие CSRF-уязвимостей. Обычно я проверял только на наличие CSRF, так как это требует не очень много времени, но если случайно находил что-то еще, то сообщал об этих уязвимостях тоже.
Результаты и технические подробности
Как я писал выше, из десяти крупных хостингов больше половины были уязвимы. Всего из 100 хостингов, проверенных в 2014 году, 63 были уязвимы. Обычно это были простые CSRF, хотя встречались удивительные уязвимости, о которых я расскажу чуть позже.
В случае с самописными панелями обычно можно использовать CSRF для смены почты, а уже через почту восстановить пароль. Наиболее популярными из уязвимых панелей оказались ISPmanager, DirectAdmin, WHMCS и RootPanel. Я не могу назвать себя экспертом в панелях управления , поэтому могу ошибиться с версиями или другим тонкостями.
Это очень популярная панель, при этом ее актуальная версия не содержит CSRF. Однако, очень часто используется крайне устаревшая и дырявая старая версия панели.
После нахождения CSRF на разных хостингах, использующих эту панель, я написал разработчикам панели об этом. Однако, они сообщили, что достаточно давно существует защита от CSRF в виде проверки заголовка referer, однако у большинства хостингов она была отключена.
Похожая проблема была и у WHMCS. По какой-то удивительной причине CSRF-токен не проверялся на многих хостингах, защиты от подделки запросов не было. Возможно, кто-то что-то неправильно настраивал.
А в этой панели присутствовали CSRF изначально, уязвимость была исправлена разработчиком после того, как я написал ему.
Реакция хостингов
Возможно, самым правильным было бы опубликовать эту информацию в 2014 году и наблюдать за массовыми взломами и жалобами на хакеров. Но тогда я решил, что лучше сообщить об уязвимостях хостингам, и начал это делать. Я сообщил 63 уязвимым хостингам о проблеме, ответили всего 52. Через некоторое время 48 хостингов уязвимость у себя исправили, остальные ничего делать не стали.
Самое интересное началось потом. Через некоторое время я снова проверил эти хостинги, на части из них уязвимости волшебным образом появились снова. В 2015 и в 2016 я выбирал еще по 20-30 хостингов, проверял их и писал компаниям об уязвимостях. Ситуация похожая: больше половины хостингов уязвимы, через некоторое время после исправления часть уязвимостей появляется снова.
В какой-то момент все это начало напоминать цирк: я отправляю информацию, уязвимость исчезает. Часто, особенно в случае с самописными панелями, через полгода уязвимость возвращается в том же или похожем виде.
Некоторые компании были готовы исправлять уязвимость только путем установки обновления используемой панели управления («Мы используем последнюю версию панели, это проблема разработчиков»). При этом используемое ими поколение панели давно уже не обновляется.
В какой-то момент я решил заканчивать этот цирк и публиковать информацию о существующих проблемах.
Масштаб проблемы
Количество сайтов, которые могли быть взломаны с использованием этих уязвимостей, подсчитать довольно сложно. Если исходить из числа уязвимых хостингов (порядка 90-100) и минимального числа размещаемых сайтов в 1000 на каждом (я практически уверен, что реальное число намного больше), то это не менее 100 000 сайтов. Однако, косвенные признаки (ID аккаунтов и сайтов в системе, собственные заявления хостингов и информация из рейтингов) позволяют предполагать, что больше нескольких миллионов сайтов были в опасности. Понятно, что большую часть сайтов посещает пара человек в месяц, но даже при этом ситуация пугает.
Краткие результаты и состояние на сегодняшний день
В 2014 и 2015 году ситуация была пугающей: больше половины хостингов, в том числе и часть самых крупных на тот момент, имели простые уязвимости, которые позволяют получить доступ к данным пользователей. В худшем случае, сразу ко всем аккаунтам. Постепенно ситуация стала улучшаться: те, кто планировал закрыть уязвимости, их исправили, новые хостинги наконец-то стали использовать более новые панели управления.
Однако, есть бочка дегтя: даже сейчас ряд крупных хостингов, входящих в топ 10-20 самых популярных, содержат простые CSRF, которые позволяют получить доступ к аккаунту пользователя. Есть подозрение, что похожим способом можно выполнять запросы от имени администратора, но это отдельный вопрос (они используют свои панели управления, формат запросов администратора я не знаю). Среди менее крупных хостингов еще достаточно много тех, кто по каким-то причинам не исправил уязвимости. Кроме того, есть очень много сопутствующих уязвимостей, уровень безопасности в сфере удивительно низкий.
Несколько замечаний и забавных ситуаций
* Вознаграждения. Обычно предлагали бесплатный , при этом условия очень отличались: от действительно адекватных 10 000 — 20 000 тысяч на лицевой счет, до скидки в 120 рублей на 1 месяц, я впечатлен этой щедростью. Денежные вознаграждения предлагали гораздо реже, обычно это были символические 1000-2000 рублей, хотя было два намного более приятных случая. Но это единичные ситуации, большинство не предлагали ничего.
* Адекватность. Я ни разу не столкнулся с грубостью или угрозами. Самое неприятное — игнорирование сообщений или ответ «Мы не считаем это уязвимостью».
* Гениальные решения проблем с безопасностью. Несколько компаний решили бороться с угрозой CSRF странным образом: «администраторы не будут переходить по ссылкам от пользователей», а пользователи должны «позаботиться о себе сами».
* Другие уязвимости. Я искал только CSRF, но иногда находились и другие уязвимости. Самое частое — неправильная настройка HTTPS, иногда он отсутствовал вовсе, встречалась куча XSS, были странные утечки данных. Забавно, что у , который позиционировал себя, как самый безопасный (надежные системы, контроль доступа, круглосуточный мониторинг), можно было получить доступ к любому аккаунту, просто перебрав идентификаторы. Видимо, затраты на пиар слишком велики, чтобы делать безопасные сервисы.
* Публикация названий компаний. Я долго не мог решить, публиковать ли полные результаты проверки со всеми названиями компаний и детальным описанием уязвимостей. Однако, учитывая проверку только на CSRF, ее выборочность, все еще уязвимые хостинги и некоторые условия получения вознаграждения, я не стал публиковать эту информацию.
Если после прочтения статьи у вас возникло желание что-то сделать, то я настоятельно призываю не совершать противоправные действия и не ломать хостинги.
Надеюсь, что на следующей неделе я расскажу еще что-нибудь интересное, например про незакрытые уязвимости в Телеграме.
UPD: В комментариях прозвучала просьба предоставить пруфы. Под спойлером находятся скриншоты нескольких ответов хостингов (на скриншотах я постарался скрыть все данные, позволяющие однозначно идентифицировать компанию) и ответ разработчиков DirectAdmin.
2)
3)
4)
5)
6)
Автор: pyrk2142
