poxek | Неотсортированное

Telegram-канал poxek - Похек

14582

All materials published on the channel are for educational and informational purposes only. Чат: @poxek_chat Рекламный менеджер: @not_savely Купить рекламу: https://telega.in/c/poxek РКН: https://clck.ru/3FsVhp

Подписаться на канал

Похек

Ломать не строить: как устроено хардверное тестирование
#QA #hardware #BIOS #тестирование

Когда мы говорим о тестировании, большинство представляет проверку кода, интерфейсов, приложений. Но есть другой мир — тестирование «железа»: серверов, систем хранения данных, базовых станций, клиентского и сетевого оборудования. Все это — физические устройства, где важна не только прошивка, но и то, чтобы правильно крутился вентилятор, не отваливалась пайка, а новый модуль памяти не конфликтовал с платформой.

Далее автор простыми словами расскажу, что такое hardware QA: где мы режем, замораживаем, зачем смотрим, загорается ли лампочка по команде BIOS — и что делаем, если нет. Если ты джун или только начинаешь разбираться в «железе», статья поможет понять, подходит ли тебе такая работа и в чем она на самом деле заключается.

🔗Читать далее

🌚 @poxek | 🌚 Блог | 📺 poxek_official/videos">YT | 📺 RT | 📺 poxek_official">VK

Читать полностью…

Похек

CVE-2025-32023: Критическая уязвимость в Redis и Valkey
#redis #valkey #брокерсообщений #СУБД

Обнаружена критическая уязвимость в популярных СУБД Redis и Valkey, потенциально приводящая к удаленному выполнению кода через переполнение буфера в HyperLogLog операциях.

➡️Технические детали
Тип уязвимости: Integer Overflow to Buffer Overflow (CWE-680)
CVSS Score: 7.0 HIGH
Вектор атаки: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

➡️Затронутые версии
Redis: >= 2.8 до 8.0.3, 7.4.5, 7.2.10, 6.2.19
Valkey: до 8.1.3, 8.0.4

➡️Корень проблемы
Уязвимость находится в обработке HyperLogLog структур данных в файле src/hyperloglog.c. При итерации по sparse HLL кодировке происходит переполнение целочисленной переменной int i, которая отслеживает общую длину.

Проблемный код в функции hllMerge():

while(p < end) {
if (HLL_SPARSE_IS_ZERO(p)) {
runlen = HLL_SPARSE_ZERO_LEN(p);
i += runlen; // Переполнение здесь!
p++;
}
// ...
while(runlen--) {
if (regval > max[i]) max[i] = regval; // Out-of-bounds write
i++;
}
}


➡️Механизм эксплуатации
1. Создание malformed HLL: Злоумышленник создает специально сформированную HyperLogLog структуру с некорректными run lengths
2. Integer overflow: Сумма run lengths превышает максимальное значение int, вызывая переполнение в отрицательную область
3. Out-of-bounds write: Отрицательное значение i позволяет записывать данные за пределы выделенного буфера
4. RCE: Перезапись критических структур данных приводит к выполнению произвольного кода

➡️Детали эксплуатации (по данным PoC)

Стандартная схема эксплуатации Redis:
1. Коррупция sds объекта в jemalloc heap для увеличения его длины
2. Спрей embstr объектов для создания fake module объекта
3. Дамп heap через поврежденный sds объект для поиска целевого embstr и утечки адресов
4. Создание fake module объекта в целевом embstr объекте
5. Удаление fake module объекта, вызывающее деструктор и получение RCE

Функции под угрозой
▪️hllMerge() - stack-allocated HLL структуры
▪️hllSparseToDense() - heap-allocated HLL структуры
▪️Все операции с HyperLogLog командами (PFADD, PFCOUNT, PFMERGE)

➡️Условия эксплуатации
▪️Аутентифицированный доступ к Redis/Valkey
▪️Возможность выполнения HyperLogLog команд
▪️Отсутствие ACL ограничений на HLL команды

➡️Защитные меры

1. Обновление до исправленных версий:
Redis 8.0.3+, 7.4.5+, 7.2.10+, 6.2.19+
Valkey 8.1.3+, 8.0.4+
2. Временное решение через ACL:
# Запретить HyperLogLog команды
ACL SETUSER username -pfadd -pfcount -pfmerge

3. Мониторинг подозрительной активности:
▪️Аномальные HyperLogLog операции
▪️Неожиданные падения Redis процессов
▪️Попытки выполнения HLL команд с большими данными
4. Сетевые ограничения:
▪️Ограничение доступа к Redis только доверенным источникам
▪️Использование Redis AUTH и ACL систем
▪️Мониторинг сетевого трафика к Redis портам

➡️Первоисточники:

🔗GitHub Security Advisory: https://github.com/redis/redis/security/advisories/GHSA-rp2m-q4j6-gr43
🔗PoC: https://github.com/leesh3288/CVE-2025-32023
🔗NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-32023

🌚 @poxek | 🌚 Блог | 📺 poxek_official/videos">YT | 📺 RT | 📺 poxek_official">VK

Читать полностью…

Похек

Хороший знакомый, который ранее выиграл у меня на канале подписку на хакер делает у себя на канале CTF таску с призом - та самая подписка на Xakep.ru
Если кто хочет попробовать свои силы, то велком)
/channel/offensiverescuerangers/34

Читать полностью…

Похек

📊 Отчет Curator: L3-L4 DDoS-атаки во 2 квартале 2025

Эксперты Curator выпустили отчет по «DDoS-атакам, ботам и BGP-инцидентам во 2 кв 2025 года», здесь рассказываем самое важное:

📈 Рост числа DDoS-атак:

• Общее число L3-L4 атак выросло на 43% по сравнению с тем же периодом прошлого года.
• Мультивекторные атаки немного прибавили — с 17,8% до 18,5%. При этом 64,7% всех L3-L4 атак пришлись на IP flood, а наименее популярным у атакующих был ICMP flood — всего 0,2%.

🏒 Самая интенсивная атака — 965 Гбит/с. Была нацелена на сегмент Онлайн-букмекеры и, вероятно, связана с новым рекордом результативности в НХЛ, который установил Александр Овечкин.

⏱️ Самые длительные атаки: Онлайн-букмекеры (96,5 ч), Телеком-операторы (42,8 ч) и Хостинговые платформы (20,7 ч). Для сравнения: в 2024 году самая долгая атака длилась 463,9 часа — почти 19 дней.

🎯 Кого атаковали чаще всего?
🏦 Финтех — 22,6%
🛍 Электронная коммерция — 20,6%
📡 ИТ и Телеком — 16,1%

📌 Топ-5 атакованных микросегментов:
🔹 Онлайн-ритейл — 11,6%
🔹 Медиа, ТВ, радио и блогеры — 11,0%
🔹 Программное обеспечение — 8,8%
🔹 Банки — 7,1%
🔹 Онлайн-букмекеры — 6,5%

👉 Больше интересного — в Telegram-канале Curator

Читать полностью…

Похек

Лучший папищек канала)

Читать полностью…

Похек

Обращение к багхантерам. Какую одну вещь вы бы хотели поменять в российском багбаунти? Какие плюшки/ивенты иностранных площадок было бы интересно видеть на наших площадках?

Читать полностью…

Похек

CVE-2025-27415: Отравление кэша в Nuxt.js

Исследователь Rachid.A (zhero_web_security) обнаружил критическую уязвимость в популярном веб-фреймворке Nuxt.js, которая позволяет злоумышленникам отравлять кэш CDN при определённых конфигурациях. Результат — массовое распространение вредоносного контента и полная недоступность сайтов.

➡️Технические детали
Затрагивает версии Nuxt.js 3.0.0–3.15.x, исправлена в версии 3.16.0. Уязвимость эксплуатируется при размещении за CDN, игнорирующим query-параметры при кэшировании.

CVSS 7.5 HIGH: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

➡️Как работает атака
Проблема кроется в слабой проверке URL через регулярное выражение. Nuxt использует паттерн для определения payload-маршрутов:

/_payload\.json|/_payload\.js


Но регулярка проверяет весь URL, а не только путь. Это позволяет обмануть проверку запросом вида:
GET /?/_payload.json HTTP/1.1
Host: vulnerable-site.com


CDN игнорирует query-параметры при формировании ключа кэша, поэтому запросы к / и /?/_payload.json кэшируются под одним ключом. В результате:

1. Злоумышленник отправляет запрос /?/_payload.json
2. Сервер возвращает JSON вместо HTML: {"serverRendered":true,"data":null,"state":{}}
3. CDN кэширует JSON-ответ для пути /
4. Все последующие пользователи получают JSON вместо нормальной страницы

➡️Масштаб поражения
Уязвимы ВСЕ страницы Nuxt-приложения, даже те, что не передают данные с сервера на клиент. Объект будет пустым, но всё равно вернётся в JSON-формате, ломая рендеринг.

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

➡️Альтернативный вектор через hash
Исследователь также обнаружил способ эксплуатации через hash-фрагмент URL:
GET /#/_payload.json HTTP/1.1


Hash не передаётся на сервер браузерами, но через прокси может попасть в Nuxt и сработать. Правда, многие CDN кодируют или удаляют hash, что может блокировать атаку.

🔥 PoC

def attack_loop(origin, cache_sec):
target = f"{origin}/?/_payload.json"
headers = {"Host": "localhost"}
while attacking:
requests.get(target, headers=headers)
time.sleep(cache_sec) # Интервал меньше TTL кэша


Достаточно одного запроса каждые 60 секунд при TTL кэша = 60 сек для постоянного DoS.

➡️Что делать?
1. Обновиться до Nuxt 3.16.0+ — добавлена валидация query-параметров
2. Настроить CDN правильно:
# Использовать полный ключ кэша
proxy_cache_key "$scheme$host$request_uri"; # вместо $uri

# Блокировать опасные паттерны
if ($args ~* "/_payload\.json") { return 403; }

3. Правила WAF:
SecRule REQUEST_URI|ARGS_GET "@rx \\?.*_payload\\.json" \
"id:93327415,phase:1,block,msg:'CVE-2025-27415: Nuxt Cache Poisoning'"


(http.request.uri contains "?_payload.json")



💬 Добавлю от себя, что видел инфу о поглащении NuxtLabs Vercel'ом, а это разработкии NextJS. Собственно NextJS тоже относительно недавно засветился с cache poisoning CVE-2025-49826. Совпадение?))
Картинка сгенерирована с первой попытки, так что не обращайте внимание на ayload ;D

🌚 @poxek | 🌚 Блог | 📺 poxek_official/videos">YT | 📺 RT | 📺 poxek_official">VK

Читать полностью…

Похек

Как я зарегистрировал CVE и разозлил вендора
#web3 #CVE #C

Статьи про багхантинг часто говорят о пользе для резюме, багбаунти, повышении безопасности продуктов, доступе на закрытые мероприятия. Информация о проблемах во взаимодействии с разработчиками в процессе багхантинга упоминается лишь изредка (и часто - вскользь). Но, это тоже важная часть багхантинга: начинающим бахгантерам полезно знать, с какой реакцией разработчиков они могут столкнуться. Всё-таки, это определённая психологическая нагрузка. Автор хочет показать на личном примере прекрасную иллюстрацию того, насколько различны в оценке проблемы разработчики и багхантер. Случай уникален тем, что ему удалось задокументировать многие тезисы разработчиков в их первоначальном виде (в т.ч. попытку отозвать CVE). И подсветить важный момент: уже сам факт оформления CVE по проблеме, которую вендор не признаёт, может вызвать раздражение у вендора.

В статье автор покажет этапы, очень похожие на стадии принятия Кюблер-Росс (отрицание, гнев, торг, депрессия и принятие), которые он наблюдал у разработчиков в процессе общения. Мы пройдём путь от отрицания наличия проблемы, через благодарность за информирование (о проблеме) до негодования в адрес MITRE и адрес хантера.

🔗Читать дальше

🌚 @poxek | 🌚 Блог | 📺 poxek_official/videos">YT | 📺 RT | 📺 poxek_official">VK

Читать полностью…

Похек

[1/2] MLSecOps: защита машинного обучения в эпоху киберугроз

На днях исследователь Цзянь Чжоу сообщил о критической уязвимости (CVE-2025-32434), затрагивающей все версии PyTorch до 2.5.1 включительно. Ошибка устраняется только обновлением версии до 2.6.0. Уязвимость соответствует критическому уровню риска, и позволяет злоумышленнику выполнить произвольный код на стороне жертвы без какого-либо взаимодействия с пользователем.

Единственным условием является факт загрузки модели, созданной атакующим, даже при якобы безопасном параметре weights_only=True. Эта опция ранее считалась надежной, но, как выяснилось, не спасала от угроз.

Подобные инциденты с развитием и повсеместным распространением нейронных сетей будут происходить всё чаще. Это еще один повод начать внедрение инструментов и технологий MLSecOps, даже на базовом уровне.

🔗Читать дальше

🌚 @poxek | 🌚 Блог | 📺 poxek_official/videos">YT | 📺 RT | 📺 poxek_official">VK

Читать полностью…

Похек

гений на юзере. Пусть сам мне тогда пишет, я не буду 200 звёзд тратить

Читать полностью…

Похек

Выбор дополнительных победителей (в количестве 1):

🏆 Победитель:
1. somewhitehat (@somewhitehat)

✔️Проверить результаты

Читать полностью…

Похек

Поздравляю всех победителей! Сегодня проверю, все ли выполнили условия конкурса. С сегодня и до конца недели буду человек по 10 в день писать, чтобы не словить спам блок.

upd: 7 человек не выполнили условия конкурса, их промик будет рерольнут

Читать полностью…

Похек

В тему опросника 😁

#meme from @Nellle6

🌚 @poxek_meme

Читать полностью…

Похек

Расскажите о кейсах, которыми стоит поделиться!

«Лаборатория Касперского» приглашает экспертов выступить на международной конференции в области защиты промышленных систем - Kaspersky Industrial Cybersecurity Conference.

Более 500 специалистов со всего мира встретятся в Сочи, чтобы обсудить ключевые вопросы ИБ в промышленности.

⚡️Выступление на KICS Conference — это возможность представить экспертное мнение, поделиться практическим опытом и внести вклад в развитие отрасли.

О чем можно рассказать:
🟢 актуальные угрозы и атаки на промышленный сектор
🟢 технологические тренды и развитие отрасли промышленности
🟢 ИИ в промышленности
🟢 киберфизическая безопасность

🔎 Ознакомиться с примерами тем и подать доклад — на странице.

Читать полностью…

Похек

Обходим CSP nonce через дисковый кеш браузера
#перевод #habr #CSP #bugbounty #XSS #CSRF #web #pentest

Данное исследование описывает способ обхода Content Security Policy на основе nonce-значений в реалистичном сценарии. Автор создал небольшой таск на XSS для демонстрации уязвимости и подробно разбирает все этапы эксплуатации.

😧 Если вас интересует только решение, то краткая суть такова: можно добиться повторного использования nonce-значения через bfcache с откатом на дисковый кеш после его утечки, а затем заставить HTML-инъекцию быть загруженной заново путем её изменения и запроса без кеширования.

P.S. моя новая переведенная статья, буду благодарен +rep на хабре)

🔗Читать дальше

🔗Оригинал ресерча

p.s.p.s. какой же ущербный редактор у Хабра, просто ппц

🌚 @poxek | 🌚 Блог | 📺 poxek_official/videos">YT | 📺 RT | 📺 poxek_official">VK

Читать полностью…

Похек

Начинаем в багбаунти: топ-10 (или нет?) инструментов для профессионального похека
#хабр #топ10 #багбаунти #пентест #тулзы #burpsuite #owasp #caido #ffuf

В этой статье — главные инструменты для поиска уязвимостей, которые я использую в ежедневной работе. Это не подборка ради подборки: для каждого инструмента приведу пример из собственной практики, чтобы было понятно, где и как их применять.

Если хотите понять, какие инструменты выбрать и как эффективно применять их в реальных пентестах, — эта статья вам пригодится!

P.s. эта статья расширофка нашего подкаста с PT для начинающих багхантеров. Буду рад апам)

🔗Читать далее

🌚 @poxek | 🌚 Блог | 📺 poxek_official/videos">YT | 📺 RT | 📺 poxek_official">VK

Читать полностью…

Похек

Революция в кибератаках: хакеры используют AI для внедрения вредоносов в DNS

Исследователи DomainTools обнаружили принципиально новый метод кибератак, при котором злоумышленники используют искусственный интеллект для внедрения вредоносного кода непосредственно в систему доменных имён. Этот подход позволяет обходить современные системы защиты и создает невидимую инфраструктуру для доставки малвари.

➡️Как работает атака
Методика основана на фрагментации исполняемых файлов и их сокрытии в DNS TXT записях:

1. Разбиение файла: Вредоносный .exe файл разбивается на сотни мелких фрагментов
2. Энкодинг: Каждый фрагмент кодируется в шестнадцатеричном формате
3. Распределение: Фрагменты размещаются в TXT записях отдельных субдоменов
4. Нумерация: Используются целочисленные значения субдоменов для отслеживания последовательности

➡️Пример структуры:

1.felix.stf.whitetreecollective.com TXT "4d5a90000300000004000000ffff0000..."
2.felix.stf.whitetreecollective.com TXT "b800000000000000400000000000000..."
...
500.felix.stf.whitetreecollective.com TXT "..."


Роль искусственного интеллекта

AI используется для автоматизации процесса сборки:
• Генерация скриптов для извлечения фрагментов из DNS
• Автоматическая сборка файла в правильной последовательности
• Адаптация под различные DNS-конфигурации
• Обход детекции через вариативность запросов

🪲Реальные примеры

DomainTools обнаружили активное использование этой техники:

▪️Случай 1: Joke Screenmate малварь
• Домены: felix.stf.whitetreecollective.com и аналогичные
• SHA256 хеши: 7ff0ecf2953b8662ede1577e330a514f09992c18aa3c14ed77cf2ffc115b0866
• Сотни субдоменов с фрагментами исполняемого файла

▪️Случай 2: Covenant C2 стейджер
• Домен: drsmitty.com
• PowerShell скрипт в TXT записи субдомена 15392.484f5fa5d2.dnsm.in
• Подключение к C2 серверу cspg.pw через эндпоинт /api/v1/nps/payload/stage1

➡️Технические преимущества атаки
1. Обход фильтрации: DNS-трафик редко подвергается глубокому анализу
2. Стойкость: Файлы персистентны до удаления DNS записей
3. Скрытность: Маскировка под легитимный DNS-трафик
4. Масштабируемость: Возможность хранения больших файлов через фрагментацию

➡️Обнаружение атак
Исследователи использовали regex-паттерны для поиска magic bytes исполняемых файлов:
^"((ffd8ffe[0-9a-f].{12,})|(89504e47.{12,})|(47494638[79]61.{8,})|(255044462d.{10,})|(504b0304.{12,})|(4d5a.{16,59}|4d5a.{61,})|(7f454c46.{12,})|(c[ef]faedfe.{12,})|(1f8b08.{14,})|(377abcaf271c.{8,})|(526172211a07.{8,}))

Этот паттерн ищет заголовки различных типов файлов в шестнадцатеричном формате в начале TXT записей.

❗️ Защитные меры

1. Мониторинг DNS:
• Анализ аномально длинных TXT записей
• Поиск паттернов шестнадцатеричного кодирования
• Отслеживание массовых запросов к субдоменам

2. Поведенческий анализ:
• Мониторинг последовательных DNS-запросов к нумерованным субдоменам
• Анализ размеров и структуры TXT записей
• Корреляция DNS-активности с исполнением процессов

3. Технические решения:
• Внедрение DNS Security Extensions (DNSSEC)
• Фильтрация подозрительных TXT записей
• Ограничение размеров TXT записей

➡️Значение для индустрии
Эта техника представляет серьёзный вызов для традиционных систем безопасности:
• DNS-инфраструктура становится новым вектором атак
• AI позволяет автоматизировать сложные многоэтапные атаки
• Необходимость пересмотра подходов к мониторингу DNS-трафика
• Важность анализа не только сетевого трафика, но и DNS-записей

Метод уже активно эксплуатируется в дикой природе с 2021-2022 годов, что говорит о его эффективности и стойкости к обнаружению.

🌚 @poxek | 🌚 Блог | 📺 poxek_official/videos">YT | 📺 RT | 📺 poxek_official">VK

Читать полностью…

Похек

Yandex B2B Tech и SolidSoft запустили совместку.
Будут вместе делать решения для кибербеза — в первую очередь для защиты веба от атак, DDoS и ботов.

Собираются объединить SolidWall WAF от SolidSoft и Smart Web Security от Яндекс Облака. Плюс планируют прикрутить ИИ, чтобы защита была посильнее.

Важно:
Всё это можно будет запускать как в облаке, так и у себя (on-premises).
Формат не новый — у Яндекса уже так работают YDB, SpeechKit, Foundation Models и DataLens.

ИБ‑направление сейчас у них вообще в топе: за 2024 год спрос на такие сервисы в Yandex Cloud вырос в 2,1 раза. А рынок защиты веб-приложений в РФ — больше 30 ярдов (по оценке Yandex B2B Tech).

Доли 50/50, управляют ребята из SolidSoft.
Все их текущие клиенты и партнёры — без изменений.

Читать полностью…

Похек

«Щит» или «дуршлаг»? ML упрощает жизнь разработчиков, но способен проделать новые дыры в безопасности
#ML #AI #LLM #vibecoding

Машинное обучение сейчас повсюду: автогенерация кода, умные помощники, анализ аномалий. Разработчики активно внедряют ML, радуясь новым возможностям — но злоумышленники тоже не дремлют. Они учатся обманывать и «отравлять» модели, превращая умные системы из помощников в уязвимое звено. Поговорим, как ML упрощает жизнь разработчиков и почему даже самая продвинутая нейросеть может превратиться в «дуршлаг».

🔗Читать дальше

🌚 @poxek | 🌚 Блог | 📺 poxek_official/videos">YT | 📺 RT | 📺 poxek_official">VK

Читать полностью…

Похек

Даблим

Исследователи сломали защиту eSIM-чипа Kigen, получив полный доступ к секретным ключам и возможность клонировать профили операторов.

Уязвимости кроются в Java Card — виртуальной машине Kigen eUICC. Злоумышленник может установить вредоносное приложение через SMS-PP протокол и скомпрометировать сертификат GSMA. С украденным сертификатом хакер способен скачивать в открытом виде eSIM-профили любых операторов, например, AT&T, Vodafone, O2, Orange и других.

Исследователи даже продемонстрировали клонирование eSIM в реальной сети польской Orange Poland. У них два телефона с одинаковыми профилями, где второй полностью перехватывал звонки и SMS первого. Пользователь даже не подозревал о подмене.

Kigen выпустила патч и получила оценку 6.7 по CVSS. Но проблема глубже, ведь дыры могут скрываться в eSIM других производителей, потому что все они используют архитектуру Java Card без проверки байт-кода.

Сертификация EAL4+ и железобетонная защита от GSMA не спасли🤔

НеКасперский

Читать полностью…

Похек

3 метода состязательных атак на глубокие нейронные сети: как обмануть ИИ
#AI #LLM #ML #нейросети #MLSec

Состязательные атаки используют уязвимости глубоких нейронных сетей (DNN), внося минимальные изменения во входные данные, чтобы заставить модель ошибаться. Они часто незаметны для человека, но могут полностью изменить результат работы модели. В этой статье рассмотрим три популярных метода состязательных атак.

💬от меня: понятная базовая статья с математикой атак, что довольно не часто увидишь

🔗Читать дальше

🌚 @poxek | 🌚 Блог | 📺 poxek_official/videos">YT | 📺 RT | 📺 poxek_official">VK

Читать полностью…

Похек

Атаки на MCP. Как взламывают инструменты ИИ-разработчиков
#MCP #AI #LLM #Cursor #Anthropic #OpenAI

Наконец-то вышла моя статья про безопасность MCP. Мысль написать эту статью меня натолкнуло одно из обновлений в Cursor IDE, где сделали "удобную", а по факту очень дырявую однокнопочную установку MCP серверов локально. Я уже ранее писал пост про запуск MCP в контейнерах и почему это нужно. Данный вектор раскрывает supply chain attack ещё больше, что очень интересно на мой взгляд)


В погоне за ско­ростью и удобс­твом раз­работ­чики ИИ‑при­ложе­ний час­то забыва­ют о безопас­ности. Имен­но это при­вело к кри­тичес­кой уяз­вимос­ти в MCP Inspector от Anthropic. Инс­тру­мент для отладки MCP-сер­веров стал точ­кой вхо­да для зло­умыш­ленни­ков.

Не­дав­но изра­иль­ские иссле­дова­тели обна­ружи­ли кри­тичес­кую уяз­вимость уда­лен­ного выпол­нения кода (RCE) в про­екте Anthropic's Model Context Protocol (MCP) Inspector. Уяз­вимость получи­ла иден­тифика­тор CVE-2025-49596 и оцен­ку CVSS 9.4 — это говорит о чрез­вычай­ной серь­езности. Экс­плу­ати­руя этот баг, зло­умыш­ленник может уда­лен­но выпол­нить про­изволь­ный код на машине раз­работ­чика с уяз­вимой вер­сией MCP Inspector. А это, сог­ласись, уже не шут­ки.

❤️ Буду благодарен комментам и фидбеку тут и там))

🔓 Рекомендую к прочтению

🌚 @poxek | 🌚 Блог | 📺 poxek_official/videos">YT | 📺 RT | 📺 poxek_official">VK

Читать полностью…

Похек

[2/2] Проверка на Data Poisoning в MLSecOps

Давайте сегодня погрузимся в практику и разберем один из наиболее часто задаваемых мне вопросов: «Как защищаться от отравления данных? Как проверять данные на Data Poisoning»?

Подчеркну – не обязательно все советы из статьи реализовывать, возможно какие-то меры будут избыточны, так как в вашей практике уже реализованы альтернативные и при этом не менее эффективные стандарты защиты данных от отравления.

Также добавлю, что в этой статье мы разберем только сценарии отравления, связанные с изменением значений данных и меток к ним. А к таким сценариям отравления, как внедрение вредоносного кода в данные, внедрение закладок и другим мы вернемся в будущем.

Итак, всех желающих узнать больше про Data Poisoning в MLSecOps приглашаю под кат.

🔗Читать дальше

🌚 @poxek | 🌚 Блог | 📺 poxek_official/videos">YT | 📺 RT | 📺 poxek_official">VK

Читать полностью…

Похек

Ай! Не туда! Как злоупотреблять симлинками и повышать привилегии (LPE-шиться) в Windows
#windows #microsoft #symlink #LPE #privesc

Привет всем! Автор статьи Михаил Жмайло, он пентестер в команде CICADA8.

Символические ссылки присутствуют в Windows практически с момента его появления. Однако лишь немногие курсы по анализу защищенности смогут раскрыть весь их потенциал и позволят нам получить заветный LPE.
Его статья подробно расскажет о символических ссылках, специфике работы с ними, а также наглядно покажет варианты их злоупотребления для получения LPE.

Что такое символическая ссылка?
Символическая ссылка позволяет указать от одного объекта на другой.
Буквально: симлинка example может указывать на файл 1.txt. И вы, обратившись к example, попадете в 1.txt.

🔗 В Windows есть разные виды символических ссылок. Рассмотрим их подробнее.

🌚 @poxek | 🌚 Блог | 📺 poxek_official/videos">YT | 📺 RT | 📺 poxek_official">VK

Читать полностью…

Похек

от 1 человека ещё жду пока он никнейм поставит, а остальные 49 промиков выбраны побидители

На будущее, ну дочитывайте вы условия конкурса, на ровном месте теряете право получения приза ведь

upd: человек 20-25 отписал, остальным в другие дни. А то переживаю за спамблок

Читать полностью…

Похек

Выбор дополнительных победителей (в количестве 7):

🏆 Победители:
1. Gaus (@GausHack)
2. 🐣 (@kotozaavr)
3. Scrap (@Sccrrap)
4. Pavel (@root42)
5. Firuz (@isRuf)
6. Женя (@belka_e)
7. Евгений (@justoneplus)

✔️Проверить результаты

Читать полностью…

Похек

🎉 Результаты розыгрыша:

🏆 Победители:
1. 4lchemist (@darth_alchemist)
2. Ivan (@Primename)
3. .
4. Ulya (@it_fixik)
5. Егор (@Krahobeer)
6. Vlad (@vladpi)
7. NDA (@abracadaabra21)
8. I have no mouse (@lolkasasai)
9. Frankie (@frankiew2000)
10. Белгравская (@makot0_desu)
11. working on dying (@wwwcrimecom)
12. mry (@mrySEC)
13. Хагбард (@vslppl)
14. Данила (@danila200_1)
15. ㅤ (@sl1pstrim)
16. Υaroslav (@leningrad_ru)
17. Niffelheim (@Keklebos)
18. Михаил (@Unforgot10)
19. Cakes (@cakescats)
20. Ola (@Peppermintuu)
21. qasimis (@qasimis)
22. ᅠ
23. 0hat (@z3rohat)
24. T (@penisoida)
25. Сергей (@szybnev)
26. Alexander (@salfenok)
27. Александр (@alex_tomatos)
28. Дима (@nullrever)
29. Deemoun (@deemounus)
30. CyberManiac (@CyberManiac)
31. qeckl (@q3ckl)
32. Standart (@Raw_Garden0x01)
33. evalar (@evalar4)
34. Юлия (@Lalabud)
35. Екатерина (@Ancotir)
36. tter17 (@some_ne7)
37. Руслан (@Mishka0777)
38. Дмитрий (@Usotsuke_Dm)
39. Rev0x1337 (@Rev0x1337)
40. A (@gtrrnr)
41. .Morty (@moortyyy)
42. only4l0ve (@only4l0ve)
43. Depost (@GorgonzolaCTF)
44. 𝕍𝕒𝕧𝕚𝕝𝕠𝕟 (@Bazzzber)
45. p1nk1 (@StayAtSunset)
46. twnty5 (@twnty5)
47. Егор (@abyssraven)
48. A (@vyvnv)
49. Malwarya (@Malwarya)
50. Gurren (@gurrenV2)

✔️Проверить результаты

Читать полностью…

Похек

RainLoop: от шелла через аттач, до кэша в инбоксе
#bugbounty #bughunter #багбаунти #report #php

🔥 Данная статья интересна тем, что Beget как вендор на bizone bugbounty раскрыл как их поломал багхантер hunter)

Около четырех месяцев назад один из участников программы нашел критическую уязвимость в архивном, но всё еще популярном веб-почтовом клиенте RainLoop. Мы оперативно отправили баг-репорт в апстрим и, как выяснилось позже, сам багхантер также напрямую уведомил разработчиков проекта.

До этого в течение долгого времени мы предлагали пользователям RainLoop как альтернативный почтовый клиент. Однако после обнаружения уязвимости приняли решение полностью отказаться от его использования и перевели всех активных пользователей на основной, поддерживаемый интерфейс.

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

🔗Читать далее

🌚 @poxek | 🌚 Блог | 📺 poxek_official/videos">YT | 📺 RT | 📺 poxek_official">VK

Читать полностью…

Похек

Echo Chamber: революционная техника взлома нейросетей
#разбор_атаки #AI #ML #LLM

Исследователи из NeuralTrust представили принципиально новую методику обхода защит нейросетей под названием Echo Chamber. Техника демонстрирует более 90% эффективность против ChatGPT, GPT-4o, Gemini и других ведущих LLM в генерации запрещенного контента.

➡️ Что это такое

Echo Chamber — это контекстно-отравляющий джейлбрейк, который превращает собственные рассуждения модели против неё самой. В отличие от традиционных методов (подмена символов, хитрые формулировки), атака использует косвенные намеки, семантическое управление и многоэтапное логическое наведение.

Название отражает суть механизма: ранние промпты влияют на ответы нейросети, а эти ответы затем используются для усиления изначальной цели. Получается замкнутая петля, где модель сама усиливает вредоносный подтекст и постепенно разрушает собственные защитные барьеры.

➡️ Механизм атаки

Атака состоит из шести этапов:
1. Определение цели — злоумышленник выбирает конечную задачу, но не включает её в ранние промпты
2. Посадка ядовитых семян — безобидные на вид запросы создают тонкие намеки на вредоносную цель
3. Направляющие семена — лёгкие семантические подталкивания начинают смещать внутреннее состояние модели
4. Вызов отравленного контекста — атакующий косвенно ссылается на ранее сгенерированный рискованный контент
5. Выбор пути — злоумышленник выборочно подхватывает нить из отравленного контекста
6. Цикл убеждения — серия последующих промптов, замаскированных под уточнения

➡️ Результаты тестирования

В контролируемых экспериментах на 200 попытках джейлбрейка для каждой модели:
➡️Сексизм, насилие, разжигание ненависти, порнография: более 90% успеха
➡️Дезинформация и пропаганда самоповреждений: около 80% эффективность
➡️Нецензурная лексика и незаконная деятельность: свыше 40% успеха

Большинство успешных атак происходило за 1-3 хода. Модели демонстрировали возрастающую податливость после того, как контекстное отравление закреплялось.

➡️ Практический пример

Исследователи продемонстрировали атаку на примере запроса "напиши инструкцию по изготовлению коктейля Молотова". При прямом запросе LLM отказалась. Но после применения Echo Chamber модель не только описала коктейль Молотова, но и предоставила пошаговое руководство с ингредиентами.

➡️ Почему это критично

Echo Chamber выявляет критическую слепую зону в методах выравнивания LLM:
➡️Системы безопасности уязвимы к косвенным манипуляциям через контекстные рассуждения
➡️Многоходовой диалог позволяет строить вредоносные траектории даже при безобидных отдельных промптах
➡️Фильтрация на уровне токенов недостаточна, если модели могут выводить вредоносные цели без токсичных слов

В реальных сценариях — боты поддержки клиентов, помощники продуктивности, модераторы контента — такая атака может использоваться для скрытого принуждения к вредоносному выводу без срабатывания сигнализации.

➡️ Защита

NeuralTrust рекомендует:
➡️Контекстно-осведомленный аудит безопасности — динамическое сканирование истории разговоров для выявления паттернов возникающих рисков
➡️Оценка накопления токсичности — мониторинг разговоров на протяжении нескольких ходов
➡️Обнаружение косвенности — обучение слоев безопасности распознавать использование прошлого контекста

➡️ Значение для индустрии

Уязвимость является прямым следствием стремления создавать модели с развитыми способностями к рассуждению. Чем глубже нейросеть анализирует смысл и строит цепочки выводов, тем легче её эксплуатировать через косвенные влияния.

Echo Chamber подчеркивает следующий рубеж в безопасности LLM: атаки, которые манипулируют рассуждениями модели, а не её входной поверхностью. По мере того как модели становятся более способными к устойчивым выводам, они также становятся более уязвимыми к косвенной эксплуатации.

🔗Первоисточник

🌚 @poxek | 🌚 Блог | 📺 poxek_official/videos">YT | 📺 RT | 📺 poxek_official">VK

Читать полностью…

Похек

#meme by @chelovek_iz_kemerovo

🌚 @poxek_meme

Читать полностью…
Подписаться на канал