Эксплуатация некорректного алгоритма веб-кэширования - новое направление атак, угрожающих различным технологиям и инфраструктурам.
Задумывались ли вы когда-нибудь о том, что ссылки наподобие
Эксплуатация некорректного алгоритма веб-кэширования - новое направление атак, угрожающих различным технологиям и инфраструктурам.
Пару слов о кэшировании и реакции веб-сервера:
Обычно кэшируются статические и общедоступные файлы: таблицы стилей (css), скрипты (js), текстовые файлы (txt), картинки (png, bmp, gif) и так далее, поскольку там не содержится конфиденциальной информации. Кроме того, в различных статьях авторитетных авторов рекомендуется кэшировать все публичные статические файлы, не учитывая HTTP-заголовки, имеющие отношение к кэшированию.
В зависимости от технологии и настроек (в разных серверах структура построения URL может отличаться) сервер может возвращать содержимое
Детали схемы запрос-ответ:
Что произойдет при попытке поучить к адресу
После того как авторизованный пользователь обратился по адресу
Рисунок 1: Схема получения конфиденциальной информации из кэша
Интересный факт:
Обычно веб-сайты не требует аутентификации для доступа к публичным статическим файлам, а поскольку кэш относится к этой категории, то также является общедоступным.
Условия присутствия уязвимости
Для наличия бреши необходимо, чтобы выполнялись 2 условия:
В PayPal была уязвимость, связанная с некорректным механизмом веб-кэширования, которая на данный момент устранена и публично раскрыта.
Информация, которая могла быть похищена при помощи данной бреши:
-
-
-
Различные расширения статических файлов могли быть использованы для кэширования страниц (более 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 без учета соответствующих заголовков.
Если авторизованный пользователь запрашивает адрес
Оригинал:
Задумывались ли вы когда-нибудь о том, что ссылки наподобие
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
или
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
могут спровоцировать утечку конфиденциальных данных или даже позволить злоумышленнику завладеть вашей учетной записью?Эксплуатация некорректного алгоритма веб-кэширования - новое направление атак, угрожающих различным технологиям и инфраструктурам.
Пару слов о кэшировании и реакции веб-сервера:
- На сайтах зачастую используется веб-кэширование, например, через CDN, или в качестве распределителя нагрузки или обратного прокси-сервера. Цель очевидна – хранение файлов, к которым наиболее часто поступают запросы, для того, чтобы снизить нагрузку на веб-сервер.
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
настроен так, что трафик проходит через обратный прокси-сервер. Динамическая страница, хранимая на сервере, которая возвращает персональную информацию, например,
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
, будет генерироваться динамически, поскольку содержимое зависит от конкретного пользователя. Подобные страницы или как минимум отдельные части не кэшируются.Обычно кэшируются статические и общедоступные файлы: таблицы стилей (css), скрипты (js), текстовые файлы (txt), картинки (png, bmp, gif) и так далее, поскольку там не содержится конфиденциальной информации. Кроме того, в различных статьях авторитетных авторов рекомендуется кэшировать все публичные статические файлы, не учитывая HTTP-заголовки, имеющие отношение к кэшированию.
2. В атаках на некорректный алгоритм веб-кэширования, эксплуатируются механизмы браузеров и серверов подобно схемам, используемым в RPO-атаках (Relative Path Overwrite; Перезапись относительного пути), как, например, описывается в статьях
При попытке получить доступ по адресу вида
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
и
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
.
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
браузер будет формировать GET-запрос к этому URL’y. Здесь самое интересное в том, как сервер интерпретирует URL и какой будет ответ.В зависимости от технологии и настроек (в разных серверах структура построения URL может отличаться) сервер может возвращать содержимое
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
, даже если будет запрос к адресу
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
. При прямом запросе к адресу
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
HTTP-заголовки будут одинаковыми: те, что имеют отношение к кэшированию и content-type (text/html).Детали схемы запрос-ответ:
Что произойдет при попытке поучить к адресу
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
, если веб-кэширование статических файлов в прокси-сервере настроено так, что не учитываются заголовки кэширования? Давайте рассмотрим процесс пошагово.- Браузер делает запрос по адресу
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки.
- Сервер возвращает содержимое
Вы должны зарегистрироваться, чтобы увидеть внешние ссылкии, скорее всего, вместе с HTTP-заголовками, которые запрещают кэширование этой страницы.
- Ответ проходит через прокси.
- Прокси-сервер опознает, что файл имеет расширение css.
- В директории, связанной с кэшированием, прокси-сервер создает папку с именем home.php и кэширует некорректный «CSS»-файл (non-existent.css).
После того как авторизованный пользователь обратился по адресу
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
, страница с персональными данными попадет в кэш и будет общедоступна. Будет еще хуже, если тело ответа по каким-то причинам содержит идентификатор сессии, секретные ответы или CSRF-токены. Злоумышленнику остается получить доступ и извлечь информацию с закэшированной страницы.Рисунок 1: Схема получения конфиденциальной информации из кэша
Интересный факт:
Обычно веб-сайты не требует аутентификации для доступа к публичным статическим файлам, а поскольку кэш относится к этой категории, то также является общедоступным.
Условия присутствия уязвимости
Для наличия бреши необходимо, чтобы выполнялись 2 условия:
- Веб-приложение настроено так, что при кэшировании учитывается только расширение файла, а не специальные заголовки.
- При попытке доступа к адресу наподобие
Вы должны зарегистрироваться, чтобы увидеть внешние ссылкивеб-сервер вернет содержимое страницы «home.php».
- Выполните настройку веб-сервера так, чтобы кэшировались только файлы, у которых позволяет заголовок. Таким образом, будет устранена главная причина проблемы.
- Если веб-сервер позволяет, настройте так, чтобы файлы кэшировались по типу содержимого.
- Настройте веб-сервер так, чтобы при запросе страниц наподобие
Вы должны зарегистрироваться, чтобы увидеть внешние ссылкине возвращалась страница «home.php». Вместо этого должен возвращаться код состояния 404 или 302.
В PayPal была уязвимость, связанная с некорректным механизмом веб-кэширования, которая на данный момент устранена и публично раскрыта.
Информация, которая могла быть похищена при помощи данной бреши:
- Имена и фамилии пользователя.
- Остаток на счете.
- Последние 4 цифры кредитной карты.
- Транзакционные данные.
- Полный номер паспорта.
- Адрес электронной почты.
- Домашний адрес.
- Телефонный номер.
- Любая дополнительная информация на уязвимых страницах.
-
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
-
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
-
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
Различные расширения статических файлов могли быть использованы для кэширования страниц (более 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» с персональной информацией.Оригинал:
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки