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

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

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

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

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

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

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

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

#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