Неочевидные уязвимости онлайн сервисов. Часть первая16.06.2021 16:31

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

А может быть, вы популярный хостинг? Хотите привлечь пользователей, используя около-тематический трафик — создаете онлайн сервис который смог бы заменить целые серверные утилиты — nslookup, dig, curl?! Звучит неплохо, но всё ли так хорошо с безопасностью пользователей?

Об интересных и неочевидных уязвимостях онлайн-сервисов поговорим под катом.

▍Важное отступление

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

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

Поиск уязвимостей проходил в рамках программы BugBounty. Все сайты, указанные во всех частях статьи, раскрыты с письменного согласия владельцев.

Ой! Прекратите! Чем опасен XSS в 2021?! Да и вообще, XSS не опасен. Не смешите читателей!

Кажется, верное утверждение. С внедрением CORS, X-XSS-Protection современные браузеры научились неплохо фильтровать XSS, вот только не все так гладко.

Любая XSS уязвимость, несет в себе идею возможности кражи Cookie данных для авторизации или переброски пользователя на фишинговый сайт — например, для имитации окна ввода пароля. Эта статья как раз про то, что XSS всё ещё опасен, даже в Google Chrome.

▍Проверяем DNS записи или опасности утилиты Dig и NSLOOKUP в онлайн сервисах

Рассматриваемую здесь уязвимость можно расценивать как Stored XSS. Хоть хранимой она, в зависимости от архитектуры построения сервиса может не являться, вот только конечному пользователю будет совершенно непонятно откуда на странице взялся скрипт.

Если кто не знает, серверная утилита Dig (NSLOOKUP работает похожим образом) позволяет получить DNS записи любого домена. В интернете же, можно найти множество онлайн сервисов, которые используют эту утилиту у себя на «бэкенде», а своим пользователям показывают результат её работы.

DNS записей существует несколько: A, MX, CNAME, SOA, TXT и другие. Мне стало интересно проверить возможности TXT записи — что если здесь написать скрипт? Для проверки атаки нужен собственный домен.

Оказалось, помимо всевозможных символов DKIM и SPF подписей, в TXT запись можно написать обычный скрипт или полноценный html, с небольшими нюансами. Можно было бы подумать, что мой NS провайдер не экранирует спецсимволы, но нет — так делать можно у всех.

Вот только сама схема эксплуатации не очевидна. Согласитесь, что написать скрипт в TXT запись домена, чтобы эксплуатировать XSS — на ум сразу не приходит. Так и программисту, который выводит информацию со своего же «бэкенда» может показаться, что все в порядке — тут нЕчего экранировать.

Положение ухудшается еще и тем, что утилиту Dig часто используют популярные хостеры и регистраторы, данные пользователей которых имеют повышенную ценность. А большинство таких онлайн-инструментов еще и генерирует прямую ссылку на результаты проверки.

На видео выше видим простую реализацию эксплуатации XSS уязвимости крупного хостинг-провайдера. Здесь пришлось немного изощренно подойти к вопросу реализации и вместо тега script, навесить код на событие onerror тегаimg.

Ребята из ukraine.com.ua закрыли уязвимость через 10 минут, после моего обращения в техподдержку. Быстрее, на моем опыте, пока не делал никто. Адекватная и профессиональная команда на всех этапах переговоров.

А что другие, спросите Вы? Например, ребята из Xtool тоже быстро исправили проблему и разрешили рассказать об этом в статье. Проблема здесь была в блоке DNS INFO:

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

Тем не менее, стоит отметить, что XSS уязвимости через TXT записи домена были (и могут быть) подвергнуты проекты масштабом на любой вкус — от 200 тысяч до нескольких миллионов посетителей в месяц (по данным Similarweb), по всему миру.

Желаю всем владельцам онлайн инструментов быть максимально адекватными и рассматривать пользователей, рассказавших об уязвимости — как друзей, но не врагов.

▍Странные HTTP заголовки в ответе сервера

Продолжим тестировать онлайн-сервисы — что если передать скрипт в HTTP заголовке? Сколько сервисов будут экранировать заголовки сервера, выводимые на свой «фронтенд» из curl -I [host]? Давайте попробуем, назовем заголовок X-Test .

Многие SEO-анализаторы, помимо технической информации о сайте, выводят, в том числе и заголовки ответа сервера. Это проблема не только «мелких» анализаторов. Здесь, как и в уязвимости из прошлого раздела, не очевидной уязвимости со скриптом в HTTP заголовке были подвержены проекты разных масштабов. Идея эксплуатации HTTP заголовка ответа сервера не лежит на поверхности, именно поэтому разработчики могли упустить попытки подобной XSS атаки. Так произошло и с SEO анализатором сайтов Seolik, владельцы которого любезно разрешили опубликовать этот кейс. Разработчики проявили серьезное отношение к безопасности и в режиме адекватного диалога очень быстро исправили уязвимость.

Можно справедливо заметить, что для безопасности исполнения скриптов стоит использовать Content Security Policy . Некоторые онлайн-инструменты использовали этот прием и отключали inline скрипты. Однако, это не сильно осложняло задачу эксплуатации уязвимости, ведь большинство сервисов пользуются внешними средствами аналитики трафика.

Перед началом использования счетчиков, на странице необходимо инициализировать их, например так script nonce="analytics". Чтобы этот код заработал, онлайн-сервис добавил в CSP: default-src 'nonce-analytics'.

Но безопаснее не стало — ведь мы по прежнему можем передать через XSS over Response Header такую же конструкцию скрипта. Браузер будет считать чужой скрипт «местным».

▍Пишем скрипт в HTML теги

Согласитесь, писать скрипт в тег заголовка страницы — неочевидное решение для попытки эксплуатации XSS. Но оно работает. Исследовав небольшую часть онлайн-сервисов, становится понятно, что не все экранируют содержимое HTML тегов: title, h1, description и других. Разработчики популярного сервиса поисковой аналитики Topvisor тоже упустили нашу маленькую шалость и вывели содержимое тега title на страницу отчета анализа сайта.

Здесь, очень полезная функция ТопВизора «Поделиться результатом анализа» играет нам на руку — ведь мы получаем прямую ссылку на эксплуатацию XSS уязвимости через вывод содержимого HTML тегов. Также стоит отдать должное отношению к безопасности — разработчики связались в тот же день и сразу закрыли уязвимость.

Ситуация повторяется в популярном онлайн-сервисе для SEO-аудита PR-CY. Здесь также, в инструменте проверки Open Graph разметки, не экранировались значения полученные с исследуемого ресурса. Для удобства пользователей генерировалась прямая ссылка на результат — что конечно на руку атакующему.

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

▍Неожиданные уязвимости популярных онлайн-инструментов

Пожалуй, в этой главе будет история об одной, точнее о нескольких наиболее неожиданных уязвимостях популярных онлайн-сервисов, один из которых за авторством W3C. История, которую можете попробовать написать сами.

Нет. Писать текст не придётся. Здесь не будет NFT котиков и рояля на тросах, но будет небольшая головоломка. Предлагаю читателям как можно скорее найти и раскрыть все варианты одной XSS уязвимости онлайн-сервиса от W3C который называется «Unicorn».

Официально, уязвимость на W3C уже исправлена, но специально для читателей этой статьи я развернул на своем сервере «уязвимую» версию Unicorn Validator. Чтобы хоть как-то усложнить задачу, вам придется самостоятельно разыскать адрес моего онлайн-сервиса. А еще есть арбитр, который сможет ответить на некоторые вопросы — если вы окажетесь совсем в тупике и подскажет удалось ли найти все решения головоломки.

Решением можно считать найденные, как минимум, 3 разных способа эксплуатации XSS уязвимости Юникорна (должны быть разные варианты скрипта и разные теги страницы). Варианты точно не очевидные, но очень простые и из статьи легко понять направление поиска. Минимально, в валидаторе должен сработать alert с любым текстом из вашего скрипта.

Пока вы решаете головоломку, я подготовлю вторую часть статьи с объявлением лучших решателей и подробным описанием уязвимостей популярного продукта W3C Unicorn и еще нескольких онлайн-сервисов, аудитория которого превышает несколько миллионов посетителей в месяц (по данным SimilarWeb).