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

#meme from @Nellle6

🌚 @poxek_meme

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

🏆 Победители:
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)

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

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

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

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

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

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

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

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

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

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

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

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

🌚 @poxek | 🌚 Блог | 📺 YT | 📺 RT | 📺 VK

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

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

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

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

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

🌚 @poxek | 🌚 Блог | 📺 YT | 📺 RT | 📺 VK

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

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

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

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

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

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

🌚 @poxek | 🌚 Блог | 📺 YT | 📺 RT | 📺 VK

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

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

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

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

🌚 @poxek | 🌚 Блог | 📺 YT | 📺 RT | 📺 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 | 🌚 Блог | 📺 YT | 📺 RT | 📺 VK

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 | 🌚 Блог | 📺 YT | 📺 RT | 📺 VK

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

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

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

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

🌚 @poxek | 🌚 Блог | 📺 YT | 📺 RT | 📺 VK

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

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

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

🌚 @poxek | 🌚 Блог | 📺 YT | 📺 RT | 📺 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 | 🌚 Блог | 📺 YT | 📺 RT | 📺 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
🔗PoC
🔗NVD

🌚 @poxek | 🌚 Блог | 📺 YT | 📺 RT | 📺 VK

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

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

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

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

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

🌚 @poxek | 🌚 Блог | 📺 YT | 📺 RT | 📺 VK