Захват аккаунта ChatGPT - Wildcard Web Cache Deception

Введение

История о том как я мог захватить ваш аккаунт в ChatGPT.

В прошлом году Nagli обнаружил уязвимость web cache deception в ChatGPT. Ее последствия были критическими, так как она привела к утечке аутентификационных токенов пользователей и, как следствие, к захвату аккаунта. OpenAI уведомила пользователей ChatGPT об этой уязвимости и быстро исправила ошибку... Или не исправила?

В этой статье я расскажу, как мне удалось злоупотребить ошибкой Path Traversal в URL парсере, чтобы добиться того, что я называю уязвимостью обмана кэша с помощью "подстановочных знаков", чтобы украсть токены авторизации пользователей и завладеть их аккаунтами. Я буду исходить из того, что читатели знают основы уязвимости обмана веб-кэша, так как не буду слишком углубляться в ее объяснение. Если вы еще не знакомы с этой замечательной уязвимостью или хотите освежить ее в памяти, я настоятельно рекомендую сначала ознакомиться со статьей Нагли, а затем вернуться к этой статье. Кроме того, эта ошибка использует концепцию, схожую с уязвимостью отравления веб-кэша, которую я нашел в Glassdoor в прошлом году, и позволяет нам кэшировать "некэшируемые" файлы и конечные точки. Хоть это и не совсем та же техника, она демонстрирует, насколько велик потенциал того, как путаница в парсере URL, особенно при path traversal, может открыть новые двери для всевозможных уязвимостей в кэше.

Первоначальное открытие

Играя с недавно реализованной в ChatGPT функцией "поделиться", которая позволяет пользователям публично делиться своими чатами с другими, я заметил нечто странное. Ни одна из моих ссылок на общий чат не обновлялась, пока я продолжал общаться с ChatGPT. После того как я некоторое время разбирался с подобными ошибками, первое, что пришло мне в голову, - это проблема с кэшированием. Я решил, что общий чат кэшируется и, следовательно, не обновляется до тех пор, пока запись в кэше не умрет. Чтобы проверить это, я открыл вкладку "Сеть" в dev tools, чтобы проверить заголовки ответа, и, как я и предсказывал, увидел заголовок Cf-Cache-Status: HIT. Это было довольно интересно, так как это был не статический файл. Я проверил URL и увидел, что путь не имеет статического расширения, как ожидалось:

https://chat.openai.com/share/CHAT-UUID.

Это означало, что, скорее всего, существует правило кэширования, которое опирается не на расширение файла, а на его расположение в пути URL. Чтобы проверить это, я проверил https://chat.openai.com/share/random-path-that-does-not-exist и, как и ожидалось, он также был закэширован. Быстро выяснилось, что правило кэширования выглядело примерно так: /share/*. Это означает, что практически все, что находится по пути /share/, попадает в кэш. Это сразу же стало красным флагом (или зеленым, в зависимости от того, как на это посмотреть), поскольку во время последнего исследования отравления кэша я отметил для себя, что расслабленные правила кэша могут быть очень опасными, особенно при запутывании URL парсера.

Путаница при Path Traversal

На сайте, использующем кэширование, запрос должен пройти через CDN, прежде чем он попадет на веб-сервер. Это означает, что URL-адрес анализируется дважды, что делает возможной путаницу в URL парсере. В случае с ChatGPT путаница в парсере URL означала, что два сервера по-разному разбирают URL, закодированные прямыми слешами, где CDN Cloudflare НЕ декодирует и НЕ нормализует URL, закодированный path traversal, а веб-сервер делает это. Таким образом, path traversal в кодировке URL позволяет злоумышленнику кэшировать любой файл с сервера, включая наиболее уязвимые конечные точки API, содержащие токены для авторизации. Звучит немного запутанно, поэтому вот пример полезной нагрузки: Обратите внимание, что %2F расшифровывается как /, а /api/auth/session - это чувствительная конечная точка API, которая содержит токен авторизации пользователя https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123. Итак, давайте разберем это.

• Мы уже выяснили, что CDN будет кэшировать все, что находится в каталоге /share/.
• Мы также сказали, что CDN НЕ будет ни декодировать, ни нормализовать %2F..%2F, поэтому ответ будет кэширован.
• Однако когда CDN пересылает этот URL, веб-сервер декодирует и нормализует %2F..%2F и выдает в ответ /api/auth/session, который содержит токен авторизации.

Если сложить все вместе, то, когда жертва перейдет на https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123, ее токен будет записан в кэш. Когда атакующий позже посетит https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123, он увидит кэшированный токен аутентификации жертвы. Это конец игры. Как только у злоумышленника будет токен, он сможет завладеть учетной записью, просматривать чаты, платежную информацию и многое другое.

Вот небольшая схема, который я нарисовал, чтобы помочь вам все это представить:

Итак, если подвести итог, то благодаря несоответствию нормализации путей между CDN и веб-сервером я смог использовать path traversal с URL кодировкой для кэширования важных конечных точек API.

Удивительно, но это была, пожалуй, самая быстрая находка в баг-баунти, а также одна из самых интересных и больших по вознаграждению на данный момент - $6500.

На этом все, спасибо за просмотр!

Оригинал на английском тут.

Подпишись на канал - @shadow_group_tg.