Эксплуатация некорректного алгоритма веб-кэширования - новое направление атак, угрожающих различным технологиям и инфраструктурам.
Автор: Omer Gil
Задумывались ли вы когда-нибудь о том, что ссылки наподобие https://www.paypal.com/myaccount/home/stylesheet.css или https://www.paypal.com/myaccount/settings/notifications/logo.png могут спровоцировать утечку конфиденциальных данных или даже позволить злоумышленнику завладеть вашей учетной записью? Эксплуатация некорректного алгоритма веб-кэширования - новое направление атак, угрожающих различным технологиям и инфраструктурам.
Пару слов о кэшировании и реакции веб-сервера
Рассмотрим пример с веб-кэшем. Сайт http://www.example.com настроен так, что трафик проходит через обратный прокси-сервер. Динамическая страница, хранимая на сервере, которая возвращает персональную информацию, например, http://www.example.com/home.php, будет генерироваться динамически, поскольку содержимое зависит от конкретного пользователя. Подобные страницы или как минимум отдельные части не кэшируются.
Обычно кэшируются статические и общедоступные файлы: таблицы стилей (css), скрипты (js), текстовые файлы (txt), картинки (png, bmp, gif) и так далее, поскольку там не содержится конфиденциальной информации. Кроме того, в различных статьях авторитетных авторов рекомендуется кэшировать все публичные статические файлы, не учитывая HTTP-заголовки, имеющие отношение к кэшированию.
При попытке получить доступ по адресу вида http://www.example.com/home.php/non-existent.css браузер будет формировать GET-запрос к этому URL’y. Здесь самое интересное в том, как сервер интерпретирует URL и какой будет ответ. В зависимости от технологии и настроек (в разных серверах структура построения URL может отличаться) сервер может возвращать содержимое http://www.example.com/home.php, даже если будет запрос к адресу http://www.example.com/home.php/non-existent.css. При прямом запросе к адресу http://www.example.com/home.php HTTP-заголовки будут одинаковыми: те, что имеют отношение к кэшированию и content-type (text/html).
Детали схемы запрос-ответ
Что произойдет при попытке поучить к адресу http://www.example.com/home.php/non-existent.css, если веб-кэширование статических файлов в прокси-сервере настроено так, что не учитываются заголовки кэширования? Давайте рассмотрим процесс пошагово.
Эксплуатация некорректной схемы запрос-ответ
После того как авторизованный пользователь обратился по адресу http://www.example.com/home.php/logo.png, страница с персональными данными попадет в кэш и будет общедоступна. Будет еще хуже, если тело ответа по каким-то причинам содержит идентификатор сессии, секретные ответы или CSRF-токены. Злоумышленнику остается получить доступ и извлечь информацию с закэшированной страницы.
Рисунок 1: Схема получения конфиденциальной информации из кэша
Интересный факт
Обычно веб-сайты не требует аутентификации для доступа к публичным статическим файлам, а поскольку кэш относится к этой категории, то также является общедоступным.
Условия присутствия уязвимости
Для наличия бреши необходимо, чтобы выполнялись 2 условия:
Методы защиты
Некорректное веб-кэширование на примере PayPal
В PayPal была уязвимость, связанная с некорректным механизмом веб-кэширования, которая на данный момент устранена и публично раскрыта.
Информация, которая могла быть похищена при помощи данной бреши:
Примеры некоторых уязвимых страниц:
- https://www.paypal.com/myaccount/home/attack.css
- https://www.paypal.com/myaccount/settings/notifications/attack.css
- https://history.paypal.com/cgi-bin/webscr/attack.css?cmd=_history-details
Различные расширения статических файлов могли быть использованы для кэширования страниц (более 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 срок действия может увеличиваться до бесконечности.
Видео демонстрация
Домашняя страница:
https://www.paypal.com/myaccount/home
Страница с настройками:
https://www.paypal.com/myaccount/settings
История операций:
https://history.paypal.com/cgi-bin/webscr?cmd=_history-details
Компания PayPal наградила меня премией в размере 3.000$ за нахождение этой уязвимости.
Получение полного контроля над учетной записью
В точности такую уже уязвимость я нашел в других приложениях, но, к сожалению, по определенным причинам не могу разглашать деталей. В тех случаях мне удалось получить полный контроль над пользовательскими учетными записями, поскольку в HTML-коде уязвимых страниц был либо идентификатор сессии, либо секретные ответы, позволяющие восстановить пароль. Большое спасибо Саги Коэну (Sagi Cohen) за всестороннюю поддержку.
Демо пример для IIS
На видео ниже показан веб-сайт, размещенный на двух серверах, которые находятся за распределителем нагрузки на базе IIS с установленным компонентом ARR (Application Request Routing; Маршрутизация запросов приложений). После успешной авторизации пользователь перенаправляется на страницу «welcome.php» с персональными данными. Распределитель нагрузки сконфигурирован на кэширование всех файлов CSS без учета соответствующих заголовков.
Если авторизованный пользователь запрашивает адрес http://www.sampleapp.com/welcome.php/stylesheet.css, распределитель нагрузки обращается к странице welcome.php как к директории, создает папку и кэширует файл «stylsheet.css» с персональной информацией.