• Уменьшение отступа

    Обратная связь

    (info@ru-sfera.pw)

ПЕНТЕСТИНГ Атака на кеш PayPal :)


virt

Просветленный
Просветленный
Регистрация
24.11.2016
Сообщения
706
Репутация
228
Эксплуатация некорректного алгоритма веб-кэширования - новое направление атак, угрожающих различным технологиям и инфраструктурам.

Задумывались ли вы когда-нибудь о том, что ссылки наподобие или могут спровоцировать утечку конфиденциальных данных или даже позволить злоумышленнику завладеть вашей учетной записью?

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

Пару слов о кэшировании и реакции веб-сервера:
  1. На сайтах зачастую используется веб-кэширование, например, через CDN, или в качестве распределителя нагрузки или обратного прокси-сервера. Цель очевидна – хранение файлов, к которым наиболее часто поступают запросы, для того, чтобы снизить нагрузку на веб-сервер.
Рассмотрим пример с веб-кэшем. Сайт настроен так, что трафик проходит через обратный прокси-сервер. Динамическая страница, хранимая на сервере, которая возвращает персональную информацию, например, , будет генерироваться динамически, поскольку содержимое зависит от конкретного пользователя. Подобные страницы или как минимум отдельные части не кэшируются.

Обычно кэшируются статические и общедоступные файлы: таблицы стилей (css), скрипты (js), текстовые файлы (txt), картинки (png, bmp, gif) и так далее, поскольку там не содержится конфиденциальной информации. Кроме того, в различных статьях авторитетных авторов рекомендуется кэшировать все публичные статические файлы, не учитывая HTTP-заголовки, имеющие отношение к кэшированию.

2. В атаках на некорректный алгоритм веб-кэширования, эксплуатируются механизмы браузеров и серверов подобно схемам, используемым в RPO-атаках (Relative Path Overwrite; Перезапись относительного пути), как, например, описывается в статьях и .
При попытке получить доступ по адресу вида браузер будет формировать GET-запрос к этому URL’y. Здесь самое интересное в том, как сервер интерпретирует URL и какой будет ответ.

В зависимости от технологии и настроек (в разных серверах структура построения URL может отличаться) сервер может возвращать содержимое , даже если будет запрос к адресу . При прямом запросе к адресу HTTP-заголовки будут одинаковыми: те, что имеют отношение к кэшированию и content-type (text/html).

Детали схемы запрос-ответ:

Что произойдет при попытке поучить к адресу , если веб-кэширование статических файлов в прокси-сервере настроено так, что не учитываются заголовки кэширования? Давайте рассмотрим процесс пошагово.
  1. Браузер делает запрос по адресу .
  2. Сервер возвращает содержимое и, скорее всего, вместе с HTTP-заголовками, которые запрещают кэширование этой страницы.
  3. Ответ проходит через прокси.
  4. Прокси-сервер опознает, что файл имеет расширение css.
  5. В директории, связанной с кэшированием, прокси-сервер создает папку с именем home.php и кэширует некорректный «CSS»-файл (non-existent.css).
Эксплуатация некорректной схемы запрос-ответ:

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

clip_image002.jpg

Рисунок 1: Схема получения конфиденциальной информации из кэша

Интересный факт:

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

Условия присутствия уязвимости

Для наличия бреши необходимо, чтобы выполнялись 2 условия:
  1. Веб-приложение настроено так, что при кэшировании учитывается только расширение файла, а не специальные заголовки.
  2. При попытке доступа к адресу наподобие веб-сервер вернет содержимое страницы «home.php».
Методы защиты:
  1. Выполните настройку веб-сервера так, чтобы кэшировались только файлы, у которых позволяет заголовок. Таким образом, будет устранена главная причина проблемы.
  2. Если веб-сервер позволяет, настройте так, чтобы файлы кэшировались по типу содержимого.
  3. Настройте веб-сервер так, чтобы при запросе страниц наподобие не возвращалась страница «home.php». Вместо этого должен возвращаться код состояния 404 или 302.
Некорректное веб-кэширование на примере PayPal:

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

Информация, которая могла быть похищена при помощи данной бреши:
  1. Имена и фамилии пользователя.
  2. Остаток на счете.
  3. Последние 4 цифры кредитной карты.
  4. Транзакционные данные.
  5. Полный номер паспорта.
  6. Адрес электронной почты.
  7. Домашний адрес.
  8. Телефонный номер.
  9. Любая дополнительная информация на уязвимых страницах.
Примеры некоторых уязвимых страниц:

-
-
-

Различные расширения статических файлов могли быть использованы для кэширования страниц (более 40 наименований). Например:
aif, aiff, au, avi, bin, bmp, cab, carb, cct, cdf, class, css, doc, dcr, dtd, gcf, gff, gif, grv, hdml, hqx, ico, ini, jpeg, jpg, js, mov, mp3, nc, pct, ppc, pws, swa, swf, txt, vbs, w32, wav, wbmp, wml, wmlc, wmls, wmlsc, xsd, zip

Прекращение срока действия закэшированных файлов

По моим расчетам после первоначального запроса закэшированный файл доступен в течение примерно 5 часов. При повторном доступе в течение этого отрезка времени, срок действия увеличивается. Очевидно, что этого времени более чем достаточно, чтобы злоумышленник смог получить файл прежде, чем прекратится срок действия. А при постоянном мониторинге URL срок действия может увеличиваться до бесконечности.

Видео демонстрация:

Домашняя страница:




Страница с настройками:




История операций:




Компания PayPal наградила меня премией в размере 3.000$ за нахождение этой уязвимости.

Получение полного контроля над учетной записью

В точности такую уже уязвимость я нашел в других приложениях, но, к сожалению, по определенным причинам не могу разглашать деталей. В тех случаях мне удалось получить полный контроль над пользовательскими учетными записями, поскольку в HTML-коде уязвимых страниц был либо идентификатор сессии, либо секретные ответы, позволяющие восстановить пароль. Большое спасибо Саги Коэну ( ) за всестороннюю поддержку.

Демо пример для IIS:

На видео ниже показан веб-сайт, размещенный на двух серверах, которые находятся за распределителем нагрузки на базе IIS с установленным компонентом ARR (Application Request Routing; Маршрутизация запросов приложений). После успешной авторизации пользователь перенаправляется на страницу «welcome.php» с персональными данными. Распределитель нагрузки сконфигурирован на кэширование всех файлов CSS без учета соответствующих заголовков.

Если авторизованный пользователь запрашивает адрес , распределитель нагрузки обращается к странице welcome.php как к директории, создает папку и кэширует файл «stylsheet.css» с персональной информацией.


Оригинал:
 
Верх Низ