Fsecurity | HH pinned «Всем хак! 🥳 Мы достигли 3000 участников на Discord сервере! 🎉 Это огромная цифра, представьте себе 3000 людей в одном месте. Хочу выразить всем благодарность, всем, кто с нами, и тем, кто когда-то был с нами. Именно вы внесли такой вклад! Именно благодаря…»
Forwarded from BlackFan
Интересная уязвимость, связанная с кэшированием HTTP ответов из S3, может возникнуть если немного перестараться с настройкой.
Условия:
1) Сайт хранит статику в S3 и по определенным условиям проксирует туда запросы, либо имеет отдельный поддомен, который проксирует запросы на S3 бакет
2) Чтобы не гонять 10 мегабайтные JavaScript файлы, кэшируется контент из S3 для любого HTTP ответа с кодом 200
3) Так как кэшируется только статика - не включаем в ключ кэша cookie или query-параметры
Казалось бы, все в порядке, но проблема заключается в том, что S3 умеет отвечать с кодом 200 не только возвращая контент файла, но еще и при получении другой информации об объекте.
Например, для получения списка тегов достаточно в query-параметры добавить
В результате, вместо контента файла вернется следующий HTTP ответ:
И если так запросить статику на сайте в момент, когда кэш HTTP ответа будет обновляться - это приведет к тому, что всем следующим пользователям вместо JS вернется некорректный ответ и сайт станет недоступен на время жизни зараженного кэша.
Если
Как проверить уязвимость и не аффектить реальных пользователей:
1) Находим через архивы устаревшие JS на сайте
2) Так как к ним никто не обращается, следующий запрос будет с обновлением кэша, поэтому сразу запрашиваем с
3) Проверяем, что зараженный HTTP ответ возвращается без указания query-параметров
4) Проверяем, что кэш не привязан к текущему пользователю запросив с другого устройства / IP / от имени другого пользователя
Как исправить уязвимость:
1) Убрать из проксируемого HTTP запроса query-параметры при передаче на S3
2) Добавить query-параметры в ключ кэша
Условия:
1) Сайт хранит статику в S3 и по определенным условиям проксирует туда запросы, либо имеет отдельный поддомен, который проксирует запросы на S3 бакет
2) Чтобы не гонять 10 мегабайтные JavaScript файлы, кэшируется контент из S3 для любого HTTP ответа с кодом 200
3) Так как кэшируется только статика - не включаем в ключ кэша cookie или query-параметры
Казалось бы, все в порядке, но проблема заключается в том, что S3 умеет отвечать с кодом 200 не только возвращая контент файла, но еще и при получении другой информации об объекте.
Например, для получения списка тегов достаточно в query-параметры добавить
?tagging, что часто разрешают для неавторизованных запросов.https://site.tld/static/somefile.js?tagging
В результате, вместо контента файла вернется следующий HTTP ответ:
<?xml version="1.0" encoding="UTF-8"?>
<Tagging xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<TagSet></TagSet>
</Tagging>
И если так запросить статику на сайте в момент, когда кэш HTTP ответа будет обновляться - это приведет к тому, что всем следующим пользователям вместо JS вернется некорректный ответ и сайт станет недоступен на время жизни зараженного кэша.
Если
?tagging, ?acl и подобные методы возвращают 403, можно попробовать параметры из GetObject API и, например, закэшировать некорректный Content-Type, указав в запросе ?response-content-type=text/html. Это приведет к тому, что браузер откажется выполнять JavaScript с некорректным типом, что также приведет к нарушению работы сайта (это поведение еще зависит от наличия в ответе заголовка X-Content-Type-Options: nosniff).Как проверить уязвимость и не аффектить реальных пользователей:
1) Находим через архивы устаревшие JS на сайте
2) Так как к ним никто не обращается, следующий запрос будет с обновлением кэша, поэтому сразу запрашиваем с
?tagging или ?response-content-type=text/html3) Проверяем, что зараженный HTTP ответ возвращается без указания query-параметров
4) Проверяем, что кэш не привязан к текущему пользователю запросив с другого устройства / IP / от имени другого пользователя
Как исправить уязвимость:
1) Убрать из проксируемого HTTP запроса query-параметры при передаче на S3
2) Добавить query-параметры в ключ кэша
www.opennet.ru
Выпуск REMnux 8.0, дистрибутива для анализа вредоносного ПО
Представлен релиз специализированного Linux-дистрибутива REMnux 8.0, предназначенного для изучения и обратного инжиниринга кода вредоносных программ. REMnux позволяет сформировать изолированное лабораторное окружение, в котором можно эмулировать работу атакуемого…
🔗Ссылка:
https://opennet.ru/64801/
https://opennet.ru/64801/
Forwarded from 🕷 BugBountyRu
8.8.1028 → Объединяет 3-й и 4-й октеты: 4 × 256 + 4 = 10288.525316 → Объединяет последние три октета в одно десятичное число0x08.8.004.004 → Шестнадцатеричный + десятичный + восьмеричный (сегмент за сегментом)0x08.0x08.004.004 → Два сегмента в hex, два в восьмеричном0x08.010.4.4 → Смешанный hex + восьмеричный + десятичный134743044 → Полное 32-битное целое представление IP-адреса0x08080404 → Весь IP закодирован как одно hex-число010.010.004.004 → Каждый сегмент с ведущим нулём, чтобы форсировать восьмеричную интерпретацию0x8.0x8.0x4.0x4 → Все четыре октета закодированы индивидуально в шестнадцатеричном виде8.8.0x404 → Последний сегмент в hex: 0x404 = 1028curl/ping, но могут срабатывать в других библиотеках/языках: ⑧.⑧.④.④, 𝟠.𝟠.𝟜.𝟜.Автоматизируй работу по байбасу валидации с помощью ipfuscator — простого Go-инструмента для быстрой генерации альтернативных представлений IP-адресов (v4)
Please open Telegram to view this post
VIEW IN TELEGRAM