От CRLF-инъекции к XSS: Повышение ставок в безопасности Apple iTunes
Примерно восемнадцать месяцев назад я обнаружил серьезную уязвимость в системе Apple iTunes.
Примерно восемнадцать месяцев назад я обнаружил серьезню уязвимость в Apple iTunes, которая начиналась с проблемы, связанной с Carriage Return Line Feed (CRLF). Благодаря анализу эта находка была раскручена до уязвимости Cross-Site Scripting (XSS). Более того, на поздних стадиях исследования мой коллега обнаружил уязвимость Cross-Origin Resource Sharing (CORS) в той же самой конечной точке, где была найдена проблема CRLF. Это ещё раз подчеркивает опасность выявленного нами недостатка в безопасности.
В пятницу, после запуска моего bash-скрипта для агрегации субдоменов и URL-адресов из Wayback Machine, и дальнейшего анализа их с помощью Dalfox и Nuclei, я обнаружил уязвимость. В процессе мониторинга трафика через прокси Burp Suite я наткнулся на поддомен, который использовался в качестве API основным доменом для получения данных о предложениях iTunes. Это открытие было сделано благодаря изучению исходного кода основного домена, где я заметил, что этот поддомен принимает определённые параметры.
Я нашел субдомен на странице iTunes.apple.com, упомянутый в исходном коде сайта. Этот субдомен, принимающий определённые параметры, стал объектом моего внимания. С помощью инструмента Burp Suite repeater я начал тестирование на уязвимости, такие как XSS и LFI, через фаззинг. Прорыв произошёл, когда инъекция
%0d%0aSet-Cookie:%20attacker=exploit
привела к успешному отражению cookie
attacker=exploit
на странице ответа, что указывало на уязвимость в системе безопасности.
Несмотря на то, что я обнаружил уязвимость CRLF, я столкнулся с проблемой. Ответ имел тип содержимого JSON, что я уже встречал ранее. Отображение в JSON снижает эффективность эксплуатации. Однако после некоторых исследований и экспериментов я обнаружил, что ручное изменение типа содержимого в запросе успешно обходит это ограничение, что стало значительным успехом в моем исследовании. Это изменение позволило эксплойту отображаться вне JSON-ответа, усиливая его воздействие.
В конечном итоге, после манипуляции с content-type, мне удалось успешно перехватить cookies. Более того, благодаря уязвимости CORS, которую обнаружил мой коллега, мы смогли захватить cookies через сторонний домен. Это продемонстрировало серьёзный изъян в системе безопасности, который потенциально может быть использован неавторизованными лицами для доступа к конфиденциальной информации.