www.opennet.ru
Docker предоставил бесплатный доступ к защищённым образам контейнеров
Компания Docker объявила о предоставлении бесплатного доступа к коллекции защищённых образов контейнеров DHI (Docker Hardened Images), насчитывающей более тысячи минималистичных сборок на базе Alpine и Debian c готовыми преднастроенными окружениями для запуска…
🔗Ссылка:
https://opennet.ru/64766/
https://opennet.ru/64766/
www.opennet.ru
Уязвимость, позволяющая обойти механизм защиты Intel TDX
Компании Google и Intel раскрыли результаты (PDF) совместной работы по аудиту безопасности механизма Intel TDX 1.5 (Trusted Domain Extensions). Технология Intel TDX реализует возможность шифрования памяти виртуальных машин для их защиты от вмешательства и…
🔗Ссылка:
https://opennet.ru/64774/
https://opennet.ru/64774/
Всем хак! 🥳
Мы достигли 3000 участников на Discord сервере! 🎉
Это огромная цифра, представьте себе 3000 людей в одном месте.
Хочу выразить всем благодарность, всем, кто с нами, и тем, кто когда-то был с нами. Именно вы внесли такой вклад! Именно благодаря вам существует Fsecurity 🦊
Мы будем продолжать развиваться и помогать тем, кто приходит в наше сообщество 🛟
На этом не все!
Планируется CTF в Discord сервере 🏴
Готовьте заранее свои ВМки с хацкерскими системами.
Вам предстоит окунуться в сеть... Где вас ждут 5 пользователей... Пробить веб и продвинуться по системе, либо вы выберете другой путь решения!
🛠️ Приготовьте ToolSet:
Nmap, Gobuster, SearchSploit, Metasploit, LinPEAS, Python http.server и другой софт
Подключение к сети: WireGuard
Образы для хацкерской ВМки:
1. Kali Linux
2. Parrot OS
⚠️ Важно: вы можете объединяться в команды для решения, помогать другим, кто застрял или только начинает пробовать себя в решении CTF
P.S. Это первая попытка реализовать подобное, возможны недочёты и непредвиденные ситуации
Мы достигли 3000 участников на Discord сервере! 🎉
Это огромная цифра, представьте себе 3000 людей в одном месте.
Хочу выразить всем благодарность, всем, кто с нами, и тем, кто когда-то был с нами. Именно вы внесли такой вклад! Именно благодаря вам существует Fsecurity 🦊
Мы будем продолжать развиваться и помогать тем, кто приходит в наше сообщество 🛟
На этом не все!
Планируется CTF в Discord сервере 🏴
Готовьте заранее свои ВМки с хацкерскими системами.
Вам предстоит окунуться в сеть... Где вас ждут 5 пользователей... Пробить веб и продвинуться по системе, либо вы выберете другой путь решения!
🛠️ Приготовьте ToolSet:
Nmap, Gobuster, SearchSploit, Metasploit, LinPEAS, Python http.server и другой софт
Подключение к сети: WireGuard
Образы для хацкерской ВМки:
1. Kali Linux
2. Parrot OS
⚠️ Важно: вы можете объединяться в команды для решения, помогать другим, кто застрял или только начинает пробовать себя в решении CTF
❤2
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/