Ай! Не туда! Как злоупотреблять симлинками и повышать привилегии (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

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

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

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

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

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

FaultLine: Автоматизированная генерация эксплойтов с помощью LLM агентов
#LLM #AI #PoC #research

Исследователи из Columbia University и Microsoft представили FaultLine - революционную систему автоматической генерации proof-of-vulnerability (PoV)(но дальше я буду писать PoC, т.к. мне так привычнее) тестов с использованием LLM агентов. Система демонстрирует 77% улучшение производительности по сравнению с существующими решениями.

Проблема
Большинство отчетов об уязвимостях неполные - в них отсутствуют PoC, необходимые для:
▪️Валидации исправлений
▪️Предотвращения регрессий
▪️Понимания механизма эксплуатации разработчиками

Генерация PoC тестов требует глубокого понимания потоков данных и управления через многоуровневые программные структуры - задача, с которой традиционные LLM агенты справляются плохо.

Техническая архитектура FaultLine

Ключевые преимущества:
▪️Языково-независимый подход (Java, C, C++)
▪️Отсутствие статического/динамического анализа
▪️Иерархическое рассуждение
▪️Feedback-driven генерацияТрехэтапная методология

Этап 1: Data Flow Reasoning (Трассировка потока данных)
▪️Идентификация "source" - внешне доступного API
▪️Определение "sink" - места возникновения уязвимости
▪️Построение пути от источника к получателю

Пример трассировки:

// Source: пользовательский ввод
String userInput = args[0]; // line 2, CronValidator.java

// Flow: передача через методы
validateExpression(userInput);

// Sink: выполнение кода
ScriptEngine.eval(expression); // line 11, уязвимое место

2: Branch Condition Analysis (Анализ условий ветвления)
▪️Выявление условий, которые должен удовлетворить input
▪️Определение требований для обхода защитных механизмов
▪️Анализ логических условий на пути source-to-sink

Этап 3: PoC Generation (Генерация эксплойта)
▪️Создание тестового случая на основе предыдущих этапов
▪️Feedback-driven цикл доработки
▪️Автоматическое исправление на основе результатов сборки и выполнения

➡️Поддерживаемые типы уязвимостей

CWE-22 (Path Traversal): Недостаточная валидация пользовательского ввода при конструировании путей файлов
Payload: ../../../etc/passwd

CWE-78 (OS Command Injection): Выполнение произвольных системных команд через инъекцию
Payload: ; rm -rf / #

CWE-79 (Cross-Site Scripting): Выполнение вредоносных скриптов в браузерах жертв
Payload: <script>alert('XSS')</script>

CWE-94 (Code Injection): Инъекция и выполнение произвольного кода
Payload: System.exit(1);

Тестовая база:
▪️100 известных уязвимостей
▪️Проекты на Java, C, C++
▪️Мультиязычный датасет

Сравнительные результаты:
▪️FaultLine: 16 успешных PoC тестов
▪️CodeAct 2.1: 9 успешных PoC тестов
▪️Улучшение: 77% относительное повышение производительности

➡️Технические инновации

1. Hierarchical Reasoning
Поэтапное рассуждение вместо монолитного подхода:
▪️Разделение сложной задачи на подзадачи
▪️Специализированные промпты для каждого этапа
▪️Передача контекста между этапами

2. Language-Agnostic Approach
▪️Отсутствие языково-специфичных компонентов
▪️Универсальные принципы анализа потоков
▪️Масштабируемость на новые языки программирования

3. Feedback-Driven Loop
▪️Автоматический анализ ошибок сборки
▪️Итеративное улучшение тестов
▪️Адаптация к специфике проектов

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

Для защиты:
▪️Автоматизированное тестирование безопасности
▪️Валидация патчей безопасности
▪️Continuous security testing в CI/CD
▪️Обучение разработчиков механизмам уязвимостей

Для атакующих:
▪️Автоматизация создания эксплойтов
▪️Снижение барьера входа для атакующих

➡️Ограничения системы

Текущие вызовы:
▪️Сложность понимания глубоко вложенных потоков данных
▪️Ограниченное понимание семантики программ у LLM
▪️Проблема с выравниванием целей (alignment)

Области для улучшения:
▪️Более точное понимание control flow
▪️Лучшая интеграция с инструментами статического анализа
▪️Расширение поддержки языков программирования

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

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

ВСЕ ПО ИБ | Про личный бренд, закрытые мероприятия, блогинг, выступления и экспертизу
#бастион #подкаст #volgactf #похек

В этом выпуске обсудим опыт в построении личного бренда и медийности в информационной безопасности. Расскажем о закрытых комьюнити, взаимодействии с аудиторией, о том, как блогинг влияет на карьеру в ИБ, насколько важна экспертная прокачка и многое другое

Сергей Зыбнев — ведущий специалист по анализу защищенности @szybnev
Алексей Гришин – директор по развитию сервисов кибербезопасности @mokando

Основные темы выпуска:
Личный бренд • Блогинг • Медийность • Спикерство • Контент • Преподавание • Комьюнити • Закрытые тусовки

Смотреть бесплатно без регистрации:
💙 ВК
📺 YouTube
📺 Rutube

Слушать:
🎵 Яндекс.Музыка
🎵 Звук
🎵 ВК
💬 Телеграм

🔗 Полезные ссылки и предыдущие выпуски

Подписывайтесь на канал, лайки, репосты друзьям - всё сюда))

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

Trend Micro State of AI Security Report 1H 2025: Новая эра угроз
#AI #LLM

Trend Micro опубликовала комплексное исследование состояния AI-безопасности за первую половину 2025 года. Цифры впечатляют и одновременно пугают - мы входим в эпоху ежедневных AI-атак.

➡️Ключевая статистика
93% руководителей безопасности готовятся к ежедневным AI-атакам в 2025 году. Это не прогноз - это реальность, которая уже стучится в дверь.
66% организаций ожидают максимального влияния AI на кибербезопасность в этом году. По данным World Economic Forum, искусственный интеллект станет главным фактором изменения ландшафта угроз.

➡️Pwn2Own Berlin 2025: Первая AI-категория
Впервые в истории конкурса введена отдельная категория AI-безопасности. Результаты превзошли ожидания:
28 уникальных zero-day уязвимостей за три дня
7 уязвимостей в AI-категории от участников из 11 стран
Целевые системы: Chroma DB, NVIDIA Triton Inference Server, Redis

➡️Критические находки
Chroma DB - первая победа в AI-категории

Sina Kheirkhah из Summoning Team стал первым победителем в AI-категории, эксплуатировав артефакты разработки, оставшиеся в продакшене.
▪️200+ незащищенных серверов Chroma без аутентификации (май 2025)
▪️300+ защищенных, но экспонированных серверов
▪️Возможность чтения, записи и удаления данных без авторизации

Техническая суть: Chroma DB - популярная векторная база данных для RAG-систем, написанная на Python. Уязвимость позволяет получить доступ к данным и потенциально к машине целиком.

NVIDIA Triton Inference Server - цепочка из четырех уязвимостей
Команда Qrious Secure достигла полной компрометации через chain exploit:
▪️Использование известных, но не пропатченных багов
▪️Загрузка произвольных данных на сервер
▪️Эксплуатация сложных взаимозависимостей компонентов

Проблема: Triton развертывается как часть Kubernetes-инфраструктуры, что усложняет защиту и мониторинг.

Redis - use-after-free через устаревший Lua
Wiz Research использовала UAF-уязвимость в Redis vector database:
▪️Эксплуатация через устаревшую подсистему Lua
▪️Цепочка уязвимостей в "стабильном" компоненте
▪️Демонстрация опасности legacy-кода в современных системах

➡️Анализ угроз
Основные векторы атак на AI-системы:

1. Артефакты разработки в продакшене
▪️Отладочные эндпоинты
▪️Тестовые конфигурации
▪️Временные файлы и скрипты

2. Устаревшие компоненты
▪️Legacy-библиотеки в современных системах
▪️Отсутствие инвентаризации зависимостей
▪️Проблемы с patch management

3. Сложность AI-инфраструктуры
▪️Множество взаимозависимых компонентов
▪️Kubernetes и контейнеризация
▪️Микросервисная архитектура

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

Для векторных баз данных:
▪️Обязательная аутентификация для всех операций
▪️Сетевая сегментация и firewall rules
▪️Регулярный аудит экспонированных сервисов
▪️Мониторинг необычной активности

Для AI-инфраструктуры:
▪️Инвентаризация всех компонентов системы
▪️Регулярное обновление зависимостей
▪️Удаление артефактов разработки перед деплоем
▪️Внедрение zero-trust архитектуры

Общие рекомендации:
▪️Проактивное сканирование уязвимостей
▪️Автоматизация patch management
▪️Security by design
▪️Регулярные security assessments

➡️Тенденции угроз
Переход к ежедневным массовым атакам на AI-системы. Agentic AI создает новые поверхности атак, а злоумышленники активно внедряют AI в свои бизнес-модели.

🔥 Выводы
Результаты Pwn2Own Berlin 2025 четко показывают: AI-безопасность больше не нишевая тема. Это критически важная область, требующая немедленного внимания.

Ключевые takeaways:
▪️AI-системы уязвимы на всех уровнях стека
▪️Традиционные подходы к безопасности недостаточны
▪️Необходима специализация в области AI-security
▪️Время действовать - сейчас, а не "когда будет время"

Практические шаги:
1. Аудит всех AI-компонентов в инфраструктуре
2. Внедрение специализированного мониторинга
3. Обучение команды особенностям AI-угроз
4. Разработка incident response планов для AI-атак

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

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

#оффтоп

Я в ближайшие выходные буду собирать себе новый комп, т.к. хочу мощь для практики с LLM, файнтюн, RL и т.д.

Собственно текущий комп через пару дней мне уже станет не нужен, я не очень люблю заниматься продажей вещей на Авито и её аналогах, поэтому предлагаю кому-то из вас его купить)

Спеки следующие:
➡️AMD Ryzen 7 5800X
➡️Gigabyte RTX 3080 OC
➡️СЖО не помню какая, но по температурам всё шикарно
➡️64 ГБ ОЗУ, даже на самые большие проекты в бурпе хватает)
➡️Корпус mid/full-tower, с антипылевыми фильтрами
➡️1 ТБ Samsung 970 Evo Plus
➡️500 Гб не помню модель, но тоже NVME M2

Цена: 100.000 рублей

В принципе за компом я ухаживал, ничего не кряхтит, не шумит аномально.

По цене пока не смотрел сколько аналогичное стоит, но в ближайшее время готов за 100к отдать. Если вы в Москве/не далёкое Подмосковье, то готов сам на таксишке к вам его подвезти, чтобы в доставках ничего не сломали.

Если будете рассматривать для покупки, то можете написать какие тесты прогнать - сделаю)

Спасибо за внимание!

Спасибо подписчику, который купил мой комп!

На1️⃣2️⃣3️⃣4️⃣5️⃣6️⃣7️⃣ появилась карта для GEOINT!

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

Как сдать флаг?
🐥Найдите правильное место
🐥Отметьте эту точку на карте
🐥Нажмите на кнопку "сдать" для их проверки
🐥Получите флаг и сдай его на платформе

Карта доступна в следующих заданиях:
🐥Снеговик
🐥Улица
🐥Загадочный лимон
🐥Потерянный в Политехе

🐥 Канал | 🐥 Чат | 🐥 Платформа