Как я взломал одного хостинг провайдера



    С недавних пор мне стали приходить предложение проверить работу различных сервисов на предмет наличия ошибок и уязвимостей. И в таких предложениях я стараюсь работать на результат и получать максимальное удовольствие от процесса. Но результат последнего «проекта» меня мягко сказать шокировал.

    Мне было предложено протестировать хостинг провайдера.

    Раскрывать название я не стану. И в своем рассказе я буду использовать название Hoster. С самим сайтом хостинг сервиса было все стандартно. Предложения купить VDS, Домены, SSL сертификаты.

    В первую очередь меня удивило то, как был реализован личный кабинет пользователя. Подтверждений владения электронным адресом при регистрации не требовалось. Т.е можно было регистрироваться с электронным адресом steve.jobs@apple.com. Или еще лучше — support@hoster.com.

    Но к счастью по аналогии с этой историей, раскрытие чувствительной информации службы поддержки сервиса не произошло.

    Однако оно все же случилось, когда я создал тестовый запрос на поддержку и сходу проверил доступность соседних ID-шников других запросов на поддержку. На удивление они оказались доступны. И можно было наблюдать кто и что регистрирует у хостера. И с какими проблемами сталкиваются пользователи. Вообщем стандартная IDOR уязвимость, которой сейчас никого не удивишь. Её конечно моментально исправили.

    Так же было несколько мест с Stored XSS. Была и Blind XSS которая вернула мне Cookie Администратора сервиса. Благодаря этой XSS мне удалось узнать где находиться интерфейс администратора, ну и вообще раскрывало много интересной информации.

    • Сколько активных пользователей.
    • Сколько доменов в управлении.
    • Сколько VDS развернуто.

    И много другого…



    Были различные ошибки с CSRF токенами, которые позволяли от лица пользователя делать много опасных вещей в личном кабинете. И если были места где передавались CSRF токены, то они просто передавались. Проверять их на backend никто не планировал. В результате моих находок часть функционала вовсе отключили. Так например 2FA аутентификацию было решено временно убрать, как не состоявшуюся в реализации.

    В ходе своей работы я обращал внимание не только на проблемы безопасности, но и на ошибки реализации или проблемы в работе какого то функционала. Я как QA не мог проходить мимо подобного. В итоге мой issue tracker дошел до цифры — 22. Столько проблем в совокупности я нашел и зафиксировал (исключительно заслуживающих внимания).

    Результаты были более чем убедительные. И я уже планировал завершать этот проект. Но почему-то снова вспомнил о проблеме отсутствия подтверждения владельца электронного адреса при регистрации. И начал придумывать ситуации при которых это может создать максимальные проблемы хостингу и его владельцам. В какой то момент я начал думать о связях владельцев этого хостинг сервиса с другими проектами этой же компании, о которых мне было известно. Спустя пару минут я зарегистрировал аккаунт с email адресом другого проекта этой же компании (пусть будет support@example.com). Дальше мне удалось привязать домен example.com к моей созданной учетной записи suppot@example.com. Но контролировать контент привязанного домена я все еще не мог.

    Зато мог отлично фишить электронными письмами от имени сервиса example.com.



    До конца непонятно куда приходили ответные письма. Т.к на одно такое тестовое письмо самому себе я ответил. Но самого ответа я не получил. Вероятно оно ушло в ответ реальному владельцу электронного ящика support@example.com.

    И вот тут случилось то, ради чего я решил написать эту статью.

    Мне удалось сделать resolve поддомена, о котором забыли. Классическая уязвимость subdomain takeover. Очень подробно об этом можно почитать тут.

    Не знаю почему, но я попытался добавить привязку к несуществующему домену. И у меня это получилось.



    Поддомен был успешно добавлен и я мог контролировать содержимое этого поддомена. И контент отображался.



    Но такого же не может быть! Как так ?! Ведь классическая subdomain takeover уязвимость работает только с существующими поддоменами.

    В моей голове абсолютно не укладывалась эта ситуация. Т.е ладно я смог миновать уровни валидации моего отношения к адресу example.com, который ни разу не мой (вероятно благодаря example.com в имени моего аккаунта). Но каким образом возможно вообще добавлять поддомены и контролировать их без всяких проверяющих составляющих в записях A, TXT, CNAME ...?

    Обычно я встречаю подобное — мы тебе добавим поддомен, только ты докажи что ты можешь это делать. Сходи и добавь в TXT данный hash ololopyshpyshpyshbdysh123.

    Но тут такого не было. Хочешь admin.example.com поддомен? Без проблем!



    Как будто уязвимость Subdomain Takeover V2.

    Благодаря возможности оперативно общаться с владельцами тестируемого хостинг сервиса — мне приоткрыли этот ящик пандоры.

    Выяснилось следующее. Хостинг работал через CloudFlare. И работал очень хитрым образом.
    Постараюсь объяснить простыми словами.

    Грубо говоря я вам говорю, идем ко мне я буду вас хостить. Делегируйте свои домены на меня.
    А дальше все входящие обращения без разбора я шлю в CloudFlare, считая их корректными.
    И если мне доверили домен vasya.ru, а сосед пришел и запилил сайт с test.vasya.ru и тоже мне его дал для хостинга, то мой сервер имея доступ к CloudFlare и уже имеющий права на vasya.ru — без проблем добавил третий уровень домена для соседа и все норм, быстро и без вопросов. Для всех DNS корректная информация от CloudFlare пришла. А CloudFlare мне доверяет.

    Обычно конечно хостинг провайдеры свои DNS сервисы настраивают. Но тут получается схитрили и просто все передают в CloudFlare от одного пользователя.

    Вот и имеем subdomain takeover god_mode. Правда это работало только с теми адресами, которые уже контролирует хостинг. Но в совокупности с ранее обнаруженной админкой сервиса — это могло сыграть злую шутку как с хостером так и с клиентами хостинг сервиса.

    В данный момент практически все критические уязвимости и ошибки исправлены. И я надеюсь что на подобные архитектурные изыски больше никто не решится после прочтения данной истории.

    P.S.: Комментарии и пожелания к статье приветствуются. Отдельное спасибо Patriot2k за техническую консультацию! Также я открыт к предложениям по тестированию чего-то интересного.
    Поделиться публикацией

    Комментарии 11

      0
      Спасибо, интересно. И еще вопрос. Судя по содержимому статьи, уязвимостей хватало. Как часто вы сталкивались с эксплуатацией уязвимостей? И каковы были последствия. Еще раз спасибо.
        0
        Спасибо за вопрос. Действительно уязвимостей хватало. С эксплуатацией увы почти не сталкиваюсь. Была недавно одна ситуация, как у компании на одном из проектов в поисковой выдаче появились порнографические материалы. Но там все банально было. Движком на проекте был Wordpress. И злоумышленники просто сделали bruteforce атаку на xmlrpc. Сбрутили пароль админа и спокойно разместили порнографический контент. Компания потом мучалась с результатами выдачи гугла.
          –1

          увы?! У вас опасная профессиональная деформация.

            +1
            Я имел в виду не эксплуатацию уязвимостей, а сам процесс расследования инцидентов (форензика). Весьма интересное направление, но времени к сожалению на это направление у меня нет (
              0
              Я понимаю, что вопрос не особо приветствуется, но хорошо ли оплачивается аудит?
                +1
                Все зависит от сложности проекта. Но я не считаю себя профессионалом и иду на встречу потенциальным заказчикам. Если заказчик доволен проделанной работой — он и сам в праве добавить бонусы. Что собственно и вышло в данной ситуации.
                Есть компании с которыми я взаимодействую просто для опыта.
        0
        Вопрос скорее общего характера: вы сталкивались с ситуацией, когда вас не просили находить уязвимости, но вы их обнаруживали по тем или иным причинам? Какая обычно реакция следует, когда вы сообщаете компании о найденных проблемах? Если таких случаев было несколько, какой сценарий встречается чаще:
        1. «Спасибо, поправим.»
        2. … игнорирование...
        3. «Да ты хакер! Ну все, жди повестки в суд!»
          +2
          Сталкиваюсь регулярно. Чаще всего — «Спасибо, поправим». Ситуации с игнорированием тоже бывают. Но если проблема серьезная и затрагивает много пользователей — то я стараюсь довести проблему до состояния «исправлено». Однажды мне за предоставленную информацию о проблеме выдали вознаграждение в виде купонов на два стаканчика кофе. И смешно и грустно.
          +1
          Это вы ещё к ним по ssh не логинились…
            0
            Знакомый интерфейс личного кабинета. Пытался завести с ними дружбу, не получилось. Показалось что все очень сыро у провайдера. Прочитал статью утвердился во мнении, что был прав. Поиск уязвимостей это ваше основное занятие или больше хобби?
              0
              В личной беседе все же выяснили что речь о разных конторах. Поиск уязвимостей для меня пока остается хобби. Но вообще я тестированием занимаюсь. Так что в принципе области достаточно близкие.

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

            Самое читаемое