Поговорим о безопасности хостингов: как я мог взломать десятки тысяч сайтов

    Всем привет.

    Сегодня я хотел бы поговорить о безопасности хостингов и о том, насколько все плохо в этой области. В середине 2014 года я читал очередную модную на тот момент статью о защите сайтов от вирусов и задался вопросом, насколько безопасны хостинги, и можно ли использовать уязвимости для массового взлома сайтов. Если коротко, то все гораздо хуже, чем я ожидал, а эта история растянулась на 3 года.

    image

    Большая часть хостингов выглядит примерно так

    В далеком 2014 году я начал с проверки хостинга, которым пользовался в то время, и сразу же нашел CSRF на смену данных учетной записи. Если рассказывать о CSRF максимально просто, то эта уязвимость позволяет подделывать запросы от имени пользователя. Когда вы отправляете HTML-форму с одного домена на другой, браузер автоматически добавит в запрос ваши куки, установленные для целевого домена. Это позволяет злоумышленнику, не имея доступа к вашим кукам, отправить запрос на целевой домен от вашего имени с вашими куками. Для защиты от этой атаки используются CSRF-токены, проверка заголовка referer или ввод пароля для подтверждения важных запросов (это очень странное и небезопасное решение). Более подробно можно прочитать об этом в Википедии.

    Я быстро проверил еще 10 крупных хостингов, больше, чем на половине нашлась такая уязвимость. Фактически, я мог создать специальную страницу, после перехода на которую авторизованного пользователя его адрес электронной почты менялся на мой, а я мог восстановить пароль по почте и доступ к аккаунту и всем файлам. Звучит страшно, но это не смертельно. Для успешного выполнения атаки необходимо найти пользователя, заманить его на специальную страницу, при этом пользователь должен быть авторизован в панели управления хостинга. Это значительно уменьшает шансы на успешный массовый взлом.

    Однако, большая часть хостингов использует готовые панели управления. При этом администратор — это такой же аккаунт пользователя с кучей дополнительный прав: часто он имеет доступ ко всем аккаунтам на сервере. Для успешной атаки достаточно было создать страницу, код на которой автоматически отправит запрос на смену почты администратора, создание новой учётной записи с дополнительными правами или выполнение любого другого действия, которое возможно в панели управления. При желании можно сменить расширение такой странице на .jpg и разместить на ней скриншот, чтобы скрыть то, что происходит на ней на самом деле. После этого можно создавать тикет «Помогите, сайт не работает, вот скриншот ошибки» и прикладывать ссылку на страницу. После перехода администратора на эту страницу злоумышленник получает доступ ко всем аккаунтам пользователей хостинга.

    Для выбора хостингов я объединил данные от нескольких рейтингов, после этого проверял цели на наличие CSRF-уязвимостей. Обычно я проверял хостинг только на наличие CSRF, так как это требует не очень много времени, но если случайно находил что-то еще, то сообщал об этих уязвимостях тоже.

    Результаты и технические подробности


    Как я писал выше, из десяти крупных хостингов больше половины были уязвимы. Всего из 100 хостингов, проверенных в 2014 году, 63 были уязвимы. Обычно это были простые CSRF, хотя встречались удивительные уязвимости, о которых я расскажу чуть позже.

    В случае с самописными панелями обычно можно использовать CSRF для смены почты, а уже через почту восстановить пароль. Наиболее популярными из уязвимых панелей оказались ISPmanager, DirectAdmin, WHMCS и RootPanel. Я не могу назвать себя экспертом в панелях управления хостинга, поэтому могу ошибиться с версиями или другим тонкостями.

    image


    Это очень популярная панель, при этом ее актуальная версия не содержит CSRF. Однако, очень часто используется крайне устаревшая и дырявая старая версия панели.

    image


    После нахождения CSRF на разных хостингах, использующих эту панель, я написал разработчикам панели об этом. Однако, они сообщили, что достаточно давно существует защита от CSRF в виде проверки заголовка referer, однако у большинства хостингов она была отключена.

    image


    Похожая проблема была и у WHMCS. По какой-то удивительной причине CSRF-токен не проверялся на многих хостингах, защиты от подделки запросов не было. Возможно, кто-то что-то неправильно настраивал.

    image


    А в этой панели присутствовали 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.
    Скриншоты
    1)
    2)
    3)
    4)
    5)
    6)
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 25
    • +2
      Хотелось бы прочитать про Telegram. А по поводу статьи — я вам конечно верю и все такое.
      Но ничто не мешает мне написать такой же текст, возможно даже с заголовком «Как я мог сломать все сайты мира», не приложить к этому никаких пруфов и выложить это Хабр.
      • 0
        Было бы странно выдумывать такой текст. Если я приложу в качестве пруфов скриншоты ответов нескольких хостингов (с замазанными названиями), плюс ответ от DirectAdmin, это вас устроит?
        • 0
          > Было бы странно выдумывать такой текст
          А что странного? Мотивация понятная, способ прост до безобразия
          > это вас устроит?
          Если честно, я все еще не понял, почему вы не хотите публиковать названия?
          • +1
            Приложил скриншоты:

            > Если честно, я все еще не понял, почему вы не хотите публиковать названия?
            Вопрос в следующем: если публиковать названия, то публиковать все. Часть компаний изначально просила это не делать, часть предлагала вознаграждение и просила не раскрывать данные о них. Будет неправильно указать их, но будет неправильно и не указать их (это выглядит, как будто они «откупились»).
            • 0
              Чисто из любопытства. Т.е. деньги таки взяли?
            • 0
              О каком «неправильно» вы говорите? Хостинг не в состоянии закрыть уже известную дыру. Это не необоснованное «они плохие» и даже не один недовольный клиент. По сути всех их клиентов от вас отгораживает только ваша порядочность и они ничего не делают.
              • 0
                Вот сейчас, без названий, это и выглядит как «откупились»
                • 0
                  Если говорить честно, то все вознаграждения и программы Bug Bounty — это откуп от хакеров в том или ином виде. Вместо того, чтобы отнести дыру в Яндексе на чёрный рынок, я отношу ее в Яндекс, где получаю деньги (часто меньше, чем мог бы получить с продажи) и спокойствие. Кто-то согласен на публикацию после исправления, кто-то (как некоторые известные банки) считает, что сокрытие факта наличия уязвимости — это одна из целей их Bug Bounty.

                  По поводу хостингов и откупа: это было бы откупом скорее в том случае, если бы я опубликовал условный список из 50 хостингов, на которых были дыры, плюс приписку, что ещё на 10 они тоже были, но по соглашению публиковать я их не могу.
        • 0
          А я считаю что надо приводить названия хостингов и уязвимости. Потому что сейчас всей полезной информации «я протестировал все хостинги и там все плохо, поэтому когда будете выбирать хостинг — тоже протестируйте все хостинги». А самое главное, что если не будут ломать, то и владельцы хостингов чесаться не будут. Так что пусть лучше уязвимость лежит в открытом доступе и этим хостингом я пользоваться не буду, чем ей пользуется ограниченный круг лиц, а я ее еще и оплачиваю.
          • 0
            Дабы избежать преследования можно привести названия хостингов, где вы НЕ нашли уязвимости =)
            • 0
              В этом случае появятся сомнения в квалификации и непредвзятости автора. Особенно если кто-то другой эти уязвимости там найдет:)
              • 0
                Это будет очень похоже на рекламу)

                Плюс, никто не может гарантировать, что на этих хостингах уязвимостей нет.
            • +1
              Уважаемый автор, что же Вас на самом деле сподвигло к 3-годичному анализу порядка 100 хостингов, при этом не имея никакого вознаграждения за свои труды, кроме… возможно… моральной удовлетворенности?
              • +1
                Я думаю, что в момент начала анализа для меня это было довольно интересно. Отдельно стоит заметить, что это потребовало не слишком много времени.
              • –1
                На HostYes была уязвимость?) Они этой весной обновляли панели просто…
                • +1
                  Автор молодец, что поискал дыры. Но не публикуя список уязвимых хостингов, делает плохо юзерам. Многие крупные лидеры рынка научились признавать свои баги (хоть и со скрипом), то уж у хостинга корона не свалится. Страна должна знать своих героев, особенно тех, кто игнорит подобные письма. В аду, говорят, для таких свой котел.
                  • +1
                    Все-таки кажется, что страна должна знать своих героев. Не всех, разумеется, а тех, у кого на момент написания статьи дыры не закрыты, при этом ТП либо не отвечает, либо шлет лесом. Вообще-то хостингам доверяют очень важные данные, и если они не в состоянии эти данные защитить, почему автор должен защищать такие хостинги, скрывая их имена?

                    Минусовать не намерен, но в текущем виде статья сильно напоминает цитату из Баша, которая применительно к нашему случаю выглядит как «Я обнаружил некую уязвимость, проверил сотню хостингов, почти все были уязвимы, кто-то прикрылся, но до сих пор тысячи сайтов в опасности. У многих хостингов за три года подвижек нет. Я решил не публиковать их список.»
                    • 0
                      Обычно, если баг нашелся у одной компании, его исправили и заплатили => название компании не публикуется.
                      Если баг нашелся у одной компании, его не исправили и не заплатили => название компании и баг публикуется, для того чтобы баг был таки закрыт.

                      Соответственно, если брать обычную этику белых хакеров, то все незакрытые сайты должны быть опубликованы. Собственно, я буду доверять больше тем компаниям, у которых баг уже закрыт.
                    • 0
                      Абсолютно, согласен.
                      Соответственно, обращение к автору статьи: общественность очень просит!
                      Если баг нашелся у одной компании, его не исправили и не заплатили => название компании и баг публикуется, для того чтобы баг был таки закрыт.


                      Вот железные доводы:

                      1. Если реальный хакер прочитает данную статью, то ему не составит труда протестировать топ 100 хостингов и воспользоваться дырой.

                      2. Если вы скрываете название таких компаний — значит поощряете хакеров и подставляете пользователей, т.к. об уязвимости сообщили достаточно информации (для хакера), а о защите — никакой (для пользователя хостинга). Если бы вы не публиковали вообще статью, для пользователей хостингов было бы больше пользы (меньше хакеров решило бы ими заняться).

                      3. Т.е. раз уж статью для хакеров вы написали (этого уже не исправишь), то либо предоставляете информацию по защите для пользователей (список дырявых компаний), либо можно считать, что вы на темной стороне силы и пытаетесь шантажировать эти самые компании, например, передавая им ссылку на эту самую статью ;)

                      4. Так что… ждемс.
                      • 0
                        Если реальный хакер прочитает данную статью, то ему не составит труда протестировать топ 100 хостингов и воспользоваться дырой.

                        Не в обиду, но что-то мне подсказывает, что реальный хакер знает о CSRF атаках уже лет *цать как.
                        • 0
                          Хм :) Реальный хакер — это довольно абстрактная формулировка. В данном случае, я под ней имел в виду не супер профессионала, а человека, который действительно не поленится повторить действия описанные в статье на реальном хостинге. То, что профи и спец.службы уже давно юзают все дыры и ежу понятно…

                          Грубо говоря статья выглядит примерно так: вот есть конкретный способ открыть железную дверь, я попробовал открыть этим способом дверь 100 топ банков и больше половины открылось… хм, вы не знали об этом способе или не думали, что он работает там? ок, теперь знаете.

                          С точки зрения пользователя хостинга — статья бесполезная страшилка.
                          С точки зрения «делового» человека не знавшего ранее этот способ или не проверявшего его на хостингах — интереснейшая информация.
                          Вопрос: Так для кого же эта статья полезна? (С учетом того, что дыры те кому о них сообщили закрывать не думают)
                      • 0
                        Меня как-то позвала одна веб студия реанимировать сервер с shared хостингом на ISP Lite. Чего там только не было, парочка левых пользователей с root правами, майнер, нагрузка на БД с почти лендинговых страничек. Платный модуль антивирус — нашел кучу зараженных сайтов…
                        При этом этот сервер жил только пару месяцев. Таки да, КДПВ очень в тему.
                        • 0
                          Для администрирования и корректировки кода на сайте, по большей части использую веб шелл, тут хостинг на CP DirectAdmin, говорил что у них супер безопасный хостинг, в итоге после некоторых не сложных манипуляций получил доступ к БД всех сайтов, после чего супер безопасный хостинг, брызжил слюнями и чуть не подал в суд, уязвимость им раскрыл, но на сегодняшний день в их случае, она также актуальна, спустя два года…
                          • 0
                            Хорошая исследовательская работа. Длительная, с вовлечением других лиц, с хорошим рефератом по итогам работы. Спасибо!
                            Для кого она написана? Для хакеров, админов сайтов или хозяев хостингов? Наука служит всем)

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.