www.opennet.ru
Стабильный выпуск СУБД MariaDB 12.1
Опубликован выпуск СУБД MariaDB 12.1.2, который отмечен как первый стабильный релиз ветки 12.1. Ветка MariaDB 12.1 отнесена к промежуточным выпускам (rolling), продолжает постепенное развитие функциональности и пришла на смену ветке MariaDB 12.0. Одновременно…
🔗Ссылка:
https://opennet.ru/64309/
https://opennet.ru/64309/
Forwarded from SecuriXy.kz
🚨 CVE-2025-61757 (Oracle Identity Manager, RCE)
Коротко: RCE без логина → полный захват. Обновиться и закрыть доступ
CISA признала уязвимость реально опасной и внесла её в список KEV - это значит, что эксплойт уже используется хакерами.
📌 Основные факты
Продукт: Oracle Identity Manager
Тип: RCE (Remote Code Execution)
Статус: активно эксплуатируется в атаках с конца августа
Риски: полный захват сервера, компрометация учётных данных, распространение в сети
🛡️ Что делать
1. Обновить Oracle Identity Manager до последних версий
2. Ограничить внешний доступ (VPN, ACL)
3. Проверить логи на обращения к эндпоинтам
4. Включить мониторинг процессов и сетевых соединений
📊 Первые IoC
🔗 PoC: GitHub — CVE-2025-61757.py
Коротко: RCE без логина → полный захват. Обновиться и закрыть доступ
CISA признала уязвимость реально опасной и внесла её в список KEV - это значит, что эксплойт уже используется хакерами.
📌 Основные факты
Продукт: Oracle Identity Manager
Тип: RCE (Remote Code Execution)
Статус: активно эксплуатируется в атаках с конца августа
Риски: полный захват сервера, компрометация учётных данных, распространение в сети
🛡️ Что делать
1. Обновить Oracle Identity Manager до последних версий
2. Ограничить внешний доступ (VPN, ACL)
3. Проверить логи на обращения к эндпоинтам
/templates;.wadl и /groovyscriptstatus;.wadl 4. Включить мониторинг процессов и сетевых соединений
📊 Первые IoC
IP: 89.238.132.76, 185.245.82.81, 138.199.29.153
🔗 PoC: GitHub — CVE-2025-61757.py
Forwarded from SecuriXy.kz
🚨 CVE-2025-41115 (Grafana Enterprise, CVSS 10.0). Коротко: SCIM включен → риск захвата админки. Обновиться немедленно.
Уязвимость в SCIM provisioning - можно подменить
Затронуты: Grafana Enterprise 12.0.0-12.2.1
Фикс: обновиться до 12.0.6 / 12.1.3 / 12.2.1 (patched) / 12.3.0
✅ Чеклист:
1 Проверить, включен ли SCIM (enableSCIM, user_sync_enabled).
2 Если не нужен - отключить.
3 Срочно обновить Grafana.
4 Мониторить журналы и входы.
PoC: GitHub — Blackash-CVE-2025-41115
Уязвимость в SCIM provisioning - можно подменить
externalId и войти под любым пользователем, включая админа.Затронуты: Grafana Enterprise 12.0.0-12.2.1
Фикс: обновиться до 12.0.6 / 12.1.3 / 12.2.1 (patched) / 12.3.0
✅ Чеклист:
1 Проверить, включен ли SCIM (enableSCIM, user_sync_enabled).
2 Если не нужен - отключить.
3 Срочно обновить Grafana.
4 Мониторить журналы и входы.
PoC: GitHub — Blackash-CVE-2025-41115
Forwarded from PWN AI (Artyom Semenov)
Как APT используют LLM/AI-агентов ...
Forwarded from 8ug8ear
Говорить на языке бизнеса в багбаунти
Я долго удивлялась почему мне иногда так занижают уязвимости. Я научилась демонстрировать импакт, а не сдавать просто XSS с алертом. Пишу видео демонстрации, стараюсь быть понятной, собираю цепочки проблем, но все еще чего-то не хватает. Чего же?
Сообщество и внутренний голос говорили, что просто не надо работать смудаками не зрелыми программами, но кажется, что такой взгляд слишком поверхностный и проблема глубже.
В этом году получила через BAC чужие балансы и истории операций в системе. Там были особенности, которые позволяли запрашивать по своей компании, а получать чужие данные. Я выгрузила данные 2х компаний за 12 лет с тратами 30 млн. Заплатили за это после фикса 10к с комментариями, что юристы сказали, что никакого нарушения тут не происходит так как нет идентификации клиента. Данные о фирмах можно получить публично в этой системе, по другими данным это можно увидеть. И казалось, что стоило добавить эту информацию в отчет, но мне она казалась очевидной и поэтому я не стала при написании отчета это показывать. Оспорить выплату не получилось. Похожая история, когда заплатили за IDOR с критичным импактом как за лоу багу, потому что это "IDOR не интересная проблема".
Посмотрев эту дискуссию, поняла, что среднестатистический CISO не заплатит за просто IDOR, XSS и тд как за крит. Но бизнес умеет хорошо считать деньги.
Попробовала действовать по другому. Завела отчет, где показала, что не просто получила фичу бесплатно "вот так". Продемонстрировала сколько стоит эта фича по тарифам системы, что это главная фича для работы аккаунта, что вот такие и такие настройки приватности она нарушает. И мне заплатили по нижней границе "крита", хотя я завела отчет как "высокий", т е гораздо выше чем я рассчитывала. Тот же самый вендор, что очень сильно снижал критичность ранее.
Реализация каких рисков крично для компании? На вскидку скажу, что никто не хочет нарваться на штраф, потерять прибыль от сервиса, получить простой сервиса с долгим восстановлением, получить кражу аккаунтов пользователей.
Далеко не все баги и стоимость убытков при реализации можно подсчитать, а сделать это снаружи в рамках багбаунти кажется задачей не реальной. Сколько стоит 1 час простоя главного сервиса? А какого-нибудь низкоуровнего, который денег не приносит? Но держать в голове и в отчете реализацию рисков, смотреть на баг в рамках вектора атаки - точно стоит. Деньги бизнес сам посчитает, если ему на это указать и понятно описать.
Какие тут стоит сделать выводы? Нужно говорить не только на языке технарей, сдавая крутой poc, но и на языке бизнеса, потому что именно он решает в конечном счете сколько стоит баг.
Я долго удивлялась почему мне иногда так занижают уязвимости. Я научилась демонстрировать импакт, а не сдавать просто XSS с алертом. Пишу видео демонстрации, стараюсь быть понятной, собираю цепочки проблем, но все еще чего-то не хватает. Чего же?
Сообщество и внутренний голос говорили, что просто не надо работать с
В этом году получила через BAC чужие балансы и истории операций в системе. Там были особенности, которые позволяли запрашивать по своей компании, а получать чужие данные. Я выгрузила данные 2х компаний за 12 лет с тратами 30 млн. Заплатили за это после фикса 10к с комментариями, что юристы сказали, что никакого нарушения тут не происходит так как нет идентификации клиента. Данные о фирмах можно получить публично в этой системе, по другими данным это можно увидеть. И казалось, что стоило добавить эту информацию в отчет, но мне она казалась очевидной и поэтому я не стала при написании отчета это показывать. Оспорить выплату не получилось. Похожая история, когда заплатили за IDOR с критичным импактом как за лоу багу, потому что это "IDOR не интересная проблема".
Посмотрев эту дискуссию, поняла, что среднестатистический CISO не заплатит за просто IDOR, XSS и тд как за крит. Но бизнес умеет хорошо считать деньги.
Попробовала действовать по другому. Завела отчет, где показала, что не просто получила фичу бесплатно "вот так". Продемонстрировала сколько стоит эта фича по тарифам системы, что это главная фича для работы аккаунта, что вот такие и такие настройки приватности она нарушает. И мне заплатили по нижней границе "крита", хотя я завела отчет как "высокий", т е гораздо выше чем я рассчитывала. Тот же самый вендор, что очень сильно снижал критичность ранее.
Реализация каких рисков крично для компании? На вскидку скажу, что никто не хочет нарваться на штраф, потерять прибыль от сервиса, получить простой сервиса с долгим восстановлением, получить кражу аккаунтов пользователей.
Далеко не все баги и стоимость убытков при реализации можно подсчитать, а сделать это снаружи в рамках багбаунти кажется задачей не реальной. Сколько стоит 1 час простоя главного сервиса? А какого-нибудь низкоуровнего, который денег не приносит? Но держать в голове и в отчете реализацию рисков, смотреть на баг в рамках вектора атаки - точно стоит. Деньги бизнес сам посчитает, если ему на это указать и понятно описать.
Какие тут стоит сделать выводы? Нужно говорить не только на языке технарей, сдавая крутой poc, но и на языке бизнеса, потому что именно он решает в конечном счете сколько стоит баг.
YouTube
Ток-шоу Безопасная среда | Хакерский взгляд на бизнес и кибериспытания
#codeib
На встрече эксперты обсудят:
— Как правильно организовать взаимодействие между бизнесом и этичными хакерами?
— Можно ли заложить непрерывный анализ защищенности как базовый процесс компании, какие преимущества дает такой подход?
— Что бизнес может…
На встрече эксперты обсудят:
— Как правильно организовать взаимодействие между бизнесом и этичными хакерами?
— Можно ли заложить непрерывный анализ защищенности как базовый процесс компании, какие преимущества дает такой подход?
— Что бизнес может…
❤1
Forwarded from вольтаж
file://localhost/etc/passwd что вернёт?
В RFC 8089, верный формат протокола описан как
file://<host>/<path>, в то время как все шпоры на LFR при SSRF говорят лишь о file:///<path>Причём, в
<host> возможно вписать домен. Система резолвнет его, и если тот указывает на 127.0.0.1, то вернётся содержимое файла. В противном случае получишь лишь отстук в DNS. питон пок
from urllib.request import urlopen
content = urlopen(
"file://yoogle.com/etc/passwd", timeout=2,
).read().decode('utf-8')
print(content)
Представил сколько возможностей для обхода фильтров? И это не последний твой приступ FOMO за сегодня.
В статье The Minefield Between Syntaxes от @yeswehack, автор вскрывает проблемы разных синтаксисов и как парсеры выживают с ними.
Представим, ты нашёл SSTI, но WAF блокирует символ$
Что делать?
Неприятно, но не критично, ведь в Python / Perl возможно представить символ через
\N{CHARACTER NAME}. Пример обхода фильтра
\N{dollar sign}{7*7} == ${7*7} == 49Уже на стену лезешь? Погоди, я с тобой ещё не закончил.
Давай дальше по загрузке файлов. Видел же в
Content-Disposition есть параметр filename?В RFC 6266 описан базовый подход с именем файла, но RFC 8187 вышибает дверь с... чего.. какие юникод байты
# RFC 6266
filename="image.png"
# RFC 8187
filename*=UTF8''image%0a.png
RFC 8187 вводит новые правила для
filename параметра, включая поддержку всего Unicode + способности кодировать произвольные байты через % То есть, ты можешь закодировать перенос строки (
%0a == \n) и всячески ломать как парсинг имени файла, так и куда тот запишется. . . .
FOMO карусель закрыта.
Как восстановишь силы, пробегись по статье автора ради:
⚀ разбор CVE из-за проблем синтаксиса [^]
⚀ кейс бб, из cache poisoning в stored xss через пролом валидации parse_url в PHP [^]
⚀ кейс бб, из слепого чтения файлов через SSRF в arbitrary file read [^]
Затем разнеси CTF по ресерчу
1. обход фильтров SSTI [^]
2. иной подход к протоколу file:// [^]
3. проломparse_urlв PHP [^]
#web #waf_bypass
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM