🔥 Локальное повышение привилегий в sudo — CVE‑2025‑32463

Эксперты обнаружили опасный баг в утилите sudo, который позволяет любой программе получить root-доступ, из-за того, что разворачивается chroot. Уязвимость CVE‑2025‑32463, включает все версии sudo с 1.9.14 по 1.9.17.

🛠 Механика

1⃣ Уязвимость активируется при использовании опции sudo -R <директория>, которая делает chroot на указанный каталог.
2⃣ Если в этом каталоге пользователь размещает собственный файл etc/nsswitch.conf, sudo подхватывает именно его — вместо системного.
3⃣ В nsswitch.conf можно прописать загрузку внешних NSS-библиотек (например, libnss_custom.so).
4⃣ Sudo загружает эти библиотеки в root-контексте до снятия префиксов, и они могут выполнить код с флагами root — атака готова

🎯 Влияние

➖Дистрибутивы с системным NSS и /etc/nsswitch.conf: Ubuntu 24.04, Fedora 41, macOS Sequoia
➖Затронуты все версии sudo от 1.9.14 до 1.9.17 включительно. Остальные тоже уязвимы — если была поддержка chroot.
➖ Системы с sudo 1.9.17p1 и новее – уже защищены.

⏳ Оценка риска

➖CVSS 3.1: 9.3 — критический уровень, Local, No privileges, High impact .
➖Эксплоит не требует прав sudoers — достаточно chroot-права.
➖Возможность атаки при локальном доступе — эксплойт «на уровне домашней папки».

🛡 Как предотвратить

✅ Обновитесь до sudo версии ≥1.9.17p1
✅ \*\*Исключите использование -R\*\*можно временно отключить в sudoers, если не нужны chroot-фичи
✅ Мониторинг chroot каталога — если создается файл etc/nsswitch.conf

Stay secure and read SecureTechTalks 📚

#sudo #cve202532463 #root #linux #chroot #privilegeescalation #cybersecurity #incidentresponse #patchnow #SecureTechTalks

🤖 Cybersecurity AI: где кончается автоматизация и начинается настоящая автономия?

🔥 Мы живём в эпоху, когда маркетологи обещают «полностью автономные» киберзащитные ИИ-инструменты, которые якобы способны остановить любую атаку без участия человека. Но так ли это?

🧩 Немного ликбеза

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

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

🚀 6 уровней «умного» киберзащитного ИИ

В ИБ используется удобная шкалу, похожую на SAE для автопилотов:
0️⃣ Level 0 — никаких инструментов, всё руками.
1️⃣ Level 1 — минимальные скрипты, всё решения принимает человек.
2️⃣ Level 2 — помощь LLM для планирования, но весь контроль у оператора (например, PentestGPT).
3️⃣ Level 3 — полуавтоматические цепочки атак с контролем человека для валидации (AutoPT, Vulnbot).
4️⃣ Level 4 — максимальная автоматизация с минимальным вмешательством человека (CAI), но без полного доверия.
5️⃣ Level 5 — гипотетическая полная автономия: ИИ сам планирует, атакует, анализирует, закрывает уязвимости без участия человека. Пока что фантастика.

Большинство инструментов, которые называют «автономными», сегодня на самом деле сидят на уровне 3–4 и требуют человеческой проверки для сложных случаев.

📌 Если перепутать автоматизацию с автономией, можно:
➖ослабить надзор, когда он нужен больше всего
создать «слепую зону» для атак, которые система не умеет обрабатывать
➖переоценить возможности ИИ и стать уязвимыми

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

🧠 Human-In-The-Loop — зачем нужен человек?

Даже самые крутые ИИ-пентестеры, например система XBOW (рекордсмен HackerOne), используют человека для верификации результатов. XBOW позиционируется как «полностью автономный» продукт, но все найденные баги сначала проверяет команда инженеров, чтобы избежать ляпов.

🕵️‍♂️ Риски

⚡️ Фальшивые отчёты могут привести к потере времени и ресурсов
⚡️ Этические вопросы (например, как публиковать найденную уязвимость) требуют человеческого решения
⚡️ ИИ по-прежнему плохо справляется с нестандартными сценариями

🌟 Риски «разогретого хайпа»

Исследователи часто отмечают, что громкие лозунги «ИИ уже лучше любого хакера» слишком сильно упрощают реальность:
✅ за каждым «автономным» успехом стоят месяцы настройки
✅ тесты проходят под наблюдением
✅ итоговый отчёт всегда финализируется людьми
⚠️ Переоценка возможностей может привести к тому, что компании ослабят контроль, доверив всё машине — и тут их может ждать неприятный сюрприз.

🚀 Выводы

🔹 Полностью автономный ИИ в кибербезе — это пока фантастика
🔹 Реальные системы остаются полуавтоматическими, пусть и очень мощными
🔹 Человеческое участие и этическая экспертиза — обязательно
🔹 Точное определение слов («автоматизация» vs «автономия») — основа грамотного управления рисками
🔹 Будущее — это партнёрство человека и ИИ, а не их взаимозаменяемость

Stay secure and read SecureTechTalks 📚

#cybersecurity #ai #pentest #humanintheloop #autonomy #automation #vulnerabilitymanagement #xdr #responsibleai #SecureTechTalks

🧠🔐 Уязвимые языки: слабое звено в безопасности ИИ

Когда вы думаете о взломе языковых моделей (LLM), скорее всего, на ум приходят запросы на английском. Но что, если именно малая языковая группа является оружием?

Новое исследование показало: многоязычие = уязвимость, особенно для языков с низкими (LRL) и средними (MRL) цифровыми ресурсами. И это — не теоретический риск, а уже эксплуатируемая уязвимость современных ИИ.

🌍 Почему языковое разнообразие стало ахиллесовой пятой ИИ?

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

📌 Пример: на английском GPT-4 может остановить вредоносный запрос,
но тот же запрос на языке зулу успешно обходит фильтр в 79% случаев!

🧪 Что протестировали?

🔬 Учёные расширили атаки TextFooler и Round-Trip Translation до 70 языков:
- 29 языков с низкими ресурсами (LRL)
- 33 со средними (MRL)
- 8 с высокими (HRL)
Они проверили, насколько легко можно искусственно изменить текст, чтобы ввести в заблуждение ИИ, при этом сохранив его осмысленность и грамматичность.

🧨 Основные выводы

🔻 Маленькие монолингвальные модели (до 100 МБ) — наименее защищённые
🔺 Крупные многоязычные модели вроде XLM-R или Glot500 — устойчивее к атакам
🤔 Но, даже у Glot500 успех атак на LRL достигает 52%
📉 Простые методы, вроде машинного перевода туда и обратно (MT → Zulu → MT), не дают полной картины — они занижают риски, создавая иллюзию надёжности.

💡 Multilingual TextFooler vs Round-Trip Attack

🧬 TextFooler подбирает синонимы и заменяет ключевые слова → сбивает модель с толку
🌐 Round-Trip Translation изменяет структуру и стилистику через автоматический перевод
📊 На LRL и MRL TextFooler оказался вдвое эффективнее

🛡 Какие выводы?

➖Фильтры LLM, построенные под английский, дают сбои на других языках
➖Малые языки стали инструментом обхода запретов — даже непреднамеренно
➖Обычные подходы к защите (prompt-guard, jailbreaking-filter) не учитывают эту уязвимость

🧭 Как улучшить защиту?

✅ Увеличивать параметрические размеры моделей для малых языков
✅ Использовать модерируемые мульти-языковые датасеты (например, Taxi1500 и SIB200)
✅ Внедрять этические и культурно-чувствительные практики при тестировании LLM
✅ Включать экспертов в лингвистике, цифровых правах и этике в проектирование защиты

📌 Финальные мысли

Большинство LLM до сих пор создаются по принципу "English first", что прямо противоречит основам кибербезопасности: готовиться к худшему сценарию.

Stay secure and read SecureTechTalks 📚

#llm #cybersecurity #nlp #multilingual #textfooler #languageattack #adversarialml #SecureTechTalks #lowresourcelanguages #jailbreak

🎨 KANVAS — вредоносные PDF как искусство атак

🧠 Что, если у вас будет инструмент, который способен создавать и анализировать сложные PDF-файлы, обходящие большинство антифишинговых фильтров и EDR-систем?

Проект KANVAS от WithSecure Labs — это настоящий лабораторный стол для работы с PDF-инфекциями и уязвимостями на низком уровне.

🧬 Что умеет KANVAS?

➖ Генерация кастомных PDF-документов
➖ Встраивание JavaScript-инъекций и обфусцированных конструкций
➖ Манипуляции с XFA-форматами
➖ Создание вредоносных объектов с delayed execution
➖ Имитация известных CVE (с ручной интеграцией)
➖ Формирование нестандартной структуры PDF (xref, headers, streams)

📁 Включённые примеры

📌 XFA‑инъекции — обход стандартных JS-фильтров
📌 Обфусцированные payload’ы — встраиваются глубоко в структуру
📌 Модифицированные шаблоны — можно собрать от “белого” инвойса до “чёрного” тройного payload'а
📌 Fuzzed PDF‑потоки — для тестирования парсинговых движков

🛡 В заключение

⚠️ PDF до сих пор остаётся главным каналом фишинга
⚠️ XFA-структуры почти не анализируются большинством EDR/AV
⚠️ Сложные обфускации ломают даже sandbox-анализаторы
⚠️ KANVAS даёт шанс заглянуть внутрь PDF-хакинга безопасно и контролируемо

📎 Где найти?

🔗 GitHub: github.com/WithSecureLabs/Kanvas

Stay secure and read SecureTechTalks 📚

#pdf #malware #obfuscation #redteam #blueteam #xfa #cve #cybertools #infosec #SecureTechTalks

🧩 Open-source под атакой: взрывной рост вредоносных пакетов в 2025 году

🚨 В первом полугодии 2025 количество вредоносных библиотек в открытых репозиториях выросло на 188% по сравнению с прошлым годом!

Исследование Sonatype выявило 16 279 заражённых пакетов в PyPI и npm — абсолютный антирекорд.
Подробнее — в ITPro.

🛑 Что делают вредоносные пакеты?

55% из них ориентированы на кражу данных: пароли, токены, персональные данные, ключи API, MongoDB-строки, .git-credentials.

Некоторые запускают шифрованный бекдор, чтобы ускользнуть от анализаторов.

Удельный вес криптомайнеров снизился до 5%, но выросло число деструктивных payload’ов, намеренно нарушающих работу приложений (до 3%).

🎭 Атакующие маскируются под настоящих разработчиков

Один из кейсов — модуль crypto-encrypt-ts, замаскированный под популярную библиотеку CryptoJS. Он тайно воровал ключи и кошельки.

Были выявлены атаки от группировки Lazarus: более 100 вредоносных пакетов в npm, свыше 30 000 установок.
Цель — CI/CD‑среда. Упор делается на зависимые сборки и supply chain-интеграции, где пакеты автоматически устанавливаются без ручной валидации.

📦 npm — главный источник угроз

Почти 99% вредоносных библиотек найдены именно в npm.
Это объясняется огромным
количеством проектов на Node.js, особенно в Web3 и DevOps и отсутствием достаточной валидации новых пакетов

К тому же, злоумышленники используют shadow downloads — скачивание библиотек напрямую по URL, минуя менеджеры пакетов, что делает мониторинг почти невозможным. В 2024 таких загрузок было больше 15 миллиардов.

🤖 Атаки ускоряются благодаря ИИ

AI-инструменты используются хакерами для:
➖Генерации названий пакетов, похожих на популярные
➖Написания фейковых README и документации
➖Создания обфусцированных вредоносных скриптов
➖Массовой публикации сотен модулей в час

Так началась новая эра: ИИ против ИИ — атаки создаются автоматически, защиту тоже нужно автоматизировать.

✅ Кто виноват? Что делать?

➖Используйте системы сканирования зависимостей (например, Sonatype, Phylum, Snyk).
➖Настройте контроль CI/CD-процессов — запретите автоматическую установку пакетов без проверки.
➖Минимизируйте зависимости — каждое лишнее подключение — потенциальная точка взлома.
➖Следите за обновлениями: обновляйте уязвимые модули, особенно с критическими CVE.
➖Обучайте разработчиков — они первая линия обороны. Объясните, как выглядят опасные зависимости и фальшивые пакеты.

🔚 В заключение

📌 Open-source не просто «бесплатный код», а основной вектор атак на инфраструктуру разработки.
📌 Supply chain-компрометации - не гипотеза, а реальность, которую используют как APT-группы, так и одиночки.
📌 Время думать не только о CVE, но и о CVE-подобных инцидентах внутри цепочек поставок кода.

Stay secure and read SecureTechTalks 📚

#opensource #malware #supplychain #npm #pypi #devsecops #infosec #lazarus #aicscans #SecureTechTalks

🔐 PostgreSQL + pgcrypto: шифрование данных и его подводные камни

Когда речь заходит о защите конфиденциальных данных, большинство вспоминают про файрволы и VPN. Но мало кто думает о том, что утечка базы данных = утечка всего. PostgreSQL предоставляет мощное, но часто недооценённое средство — расширение pgcrypto, позволяющее шифровать и хешировать данные прямо в SQL-запросах.

Однако использовать его нужно с умом. Погружаемся в детали.

🌟 Зачем вообще нужно шифровать внутри БД?

🛡 Data-at-rest защита — украли диск или дамп? Без ключа злоумышленник увидит только мусор.
📜 Соответствие стандартам — PCI DSS, HIPAA, GDPR требуют защиты на уровне отдельных полей.
⛔️ Снижение риска при SQL-инъекциях — даже если атакующий получит доступ, он не расшифрует данные без ключа.
🎯 Избирательное шифрование — не нужно защищать всю таблицу, можно только нужные поля.

🔧 pgcrypto: как начать и не облажаться

✅ Установка и изоляция:

CREATE EXTENSION pgcrypto SCHEMA crypto; REVOKE EXECUTE ON ALL FUNCTIONS IN SCHEMA crypto FROM PUBLIC; GRANT EXECUTE ON FUNCTION crypto.encrypt(bytea, bytea, text) TO secure_user;

✅ Хеширование и HMAC:

SELECT digest('text', 'sha256'); SELECT hmac('data', 'secretkey', 'sha512');

✅ Пароли с солью:

SELECT crypt('пароль', gen_salt('bf')); 

💣 Плохие практики, которых стоит избегать

🚫 Хранить ключи в той же базе данных — если база скомпрометирована, ключ в таблице только усугубит ситуацию.
🚫 Захардкодить ключ в приложении — при утечке кода атака мгновенна.
🚫 Использовать режим шифрования ECB — он сохраняет паттерны и легко поддаётся анализу.
🚫 Раздавать EXECUTE-права на функции шифрования всем подряд — это прямой путь к злоупотреблениям.

🔐 Альтернатива: что такое pgTDE?

pgTDE (Transparent Data Encryption) — это расширение, которое обеспечивает шифрование данных на уровне ядра PostgreSQL. В отличие от pgcrypto, оно работает прозрачно: вам не нужно вручную вызывать encrypt() или decrypt() — все данные в таблице шифруются автоматически. Это полезно, если вы хотите защитить всю таблицу или базу целиком.

Также pgTDE:
➖Поддерживает работу с внешними системами управления ключами (например, HashiCorp Vault).
➖Совместим с индексами, в отличие от pgcrypto, где шифрование ломает возможность поиска.
➖Лучше подходит для защищённой работы в production, особенно при больших объёмах данных.

Проект пока не включён в официальный PostgreSQL, но развивается на GitHub: github.com/bcgit/pg_tde

✅ Выводы

🔒 pgcrypto отлично подходит для точечного шифрования (например, номеров карт, паспортов, токенов).
⚙️ Но требует внимательной настройки: от схемы доступа до правильных алгоритмов и ключевого хранилища.

🧰 Если вы хотите защищать всю БД или крупные таблицы без боли — обратите внимание на pgTDE.

👀 Главное: инструмент — это только половина дела. Всё зависит от того, как именно вы его внедряете.

Stay secure and read SecureTechTalks 📚

#postgresql #pgcrypto #pgTDE #databaseencryption #infosec #dataatrest #compliance #devsecops #SecureTechTalks #cybersecurity

🔓 Post-Quantum Threat Hunter: знакомьтесь с pqcscan

⚠️ Мир на пороге квантового рубежа, и однажды все RSA и ECC‑ключи рухнут. Но кое-что может случиться даже раньше: ваш код уже сейчас может хранить уязвимые пост-квантовые конфигурации.

👾 Чтобы не пропустить этот момент, команда AnvilSecure выпустила pqcscan — 🔍 инструмент для анализа исходного кода и поиска криптографии, уязвимой для квантового взлома.

🧠 Что делает pqcscan?

📂 Сканирует исходный код проекта (на Python, Java, C/C++, Go, JS, Rust и др.)
🔍 Ищет следы до-квантовой криптографии: RSA, DSA, ECDSA, DH, ECIES, AES-128, MD5, SHA1
🧱 Использует регулярные выражения и анализ AST для точной идентификации
🚨 Маркирует устаревшие алгоритмы и участки кода с риском «harvest now, decrypt later»
📦 Работает как CLI-инструмент — лёгкий в CI/CD-интеграции

🔐 Для чего все это?

Квантовые компьютеры (если/когда появятся в боевом виде) смогут:
➖за некоторые часы взломать ключи RSA‑2048 и ECC‑256
расшифровать
➖заархивированные данные, перехваченные заранее
➖полностью обнулить криптозащиту в supply chain'ах
💣 Даже если вы считаете, что у вас "ничего важного нет" — ваши ключи уже могут копироваться и архивироваться для дешифровки в будущем. Это называется "store now, break later".

🧰 Что умеет находить pqcscan?

🛠 Классы и функции из популярных библиотек:
➖Crypto.PublicKey.RSA, OpenSSL::PKey::RSA, java.security.KeyPairGenerator
➖любые вхождения openssl_*, ecdsa_*, dh_generate
➖статические вызовы к SHA1, MD5, AES
➖даже закопанные в файлах конфигурации поля типа "algorithm": "rsa"

📊 Выводит:
имя файла и строку
тип уязвимого алгоритма
критичность (high, medium, low)

⚙️ Как пользоваться?

git clone https://github.com/anvilsecure/pqcscan.git cd pqcscan pip install -r requirements.txt python pqcscan.py /path/to/your/codebase

🚀 Через несколько секунд вы получите отчёт:
- какие алгоритмы найдены
- сколько потенциальных проблем
- на что стоит заменить

🧩 Куда дальше?

📦 AnvilSecure обещают в будущем:
➖добавить YAML-профили для разных отраслей (финтех, госсектор, IoT)
➖поддержку автоматической оценки «заменимости» на NIST PQC
➖CI-плагины и GitHub Actions

🔗 Ссылки

🔤Инструмент доступен на GitHub

📌 Заключение

🧠 Мы все готовимся к post-quantum будущему. Но некоторые — пассивно.
С pqcscan вы получаете активную разведку внутри своего кода.

Найдите устаревшие алгоритмы. Устраните уязвимости. Успейте подготовиться.

Stay secure and read SecureTechTalks 📚

#pqc #quantumresistance #cryptoanalysis #devsecops #rsa #ecc #nist #SecureTechTalks #infosec #opensource

🔒 Как обмануть ChatGPT и LLaMA без взлома? Новый метод ETTA

🧠 Исследователи представили метод ETTA (Embedding Transformation Toxicity Attenuation), который позволяет генерировать вредоносные ответы от LLM, обходя защиту без доступа к весам, коду или API.

Это не jailbreak. Это тонкий трюк, меняющий сам способ, как ИИ "чувствует" запрос.

⚙ Что именно делает ETTA?

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

Например:
Когда вы пишете "Сделай бомбу", вектор запроса похож на вектор других запрещённых тем.
Модель распознаёт токсичность и отказывается отвечать.

ETTA вмешивается в этот процесс и незаметно изменяет вектор, чтобы:
🔹 Сохранить тот же смысл (семантически — это всё ещё бомба)
🔹 Но выглядеть вектору как «безопасный» (на уровне ИИ)
Результат:
✅ Модель принимает запрос как нормальный
✅ Отвечает как будто это безобидный вопрос, не включив защиту

🔬 Как именно это реализовано?

➖Модуль обучается на парах слов: токсичных и нейтральных (например, “explosive” vs “research”)
➖Создаётся матрица преобразования эмбеддингов, которая:
- отделяет компонент "токсичности" от остального смысла
- гасит именно токсичный сигнал
➖Применяется к входному эмбеддингу запроса
➖Запрос отправляется в LLM уже в модифицированном виде

При этом:
– Смысл запроса сохраняется
– Безопасность модели отключается
– Результат валидный, связный, но содержит вредоносный текст

📊 Насколько эффективен метод?

- Gemma-2 (Google) — 95.19% успешных обходов
- LLaMA-2-7b — 87.88%
- Vicuna-13b — 88.46%
- Средний успех по моделям — 88.61%

Даже при наличии встроенной защиты:
- SmoothLLM (защита на входе) — всё равно 60.15% успеха
- ESF (дообученная фильтрация) — 77.39%

🚨 В чем новизна?

🔺 Не требуется модификация модели — весы, архитектура, даже токенизатор не трогаются
🔺 Работает на open-source — можно внедрить в любом локальном LLM
🔺 Выключается фильтрация без следов — для обычных запросов всё работает корректно
🔺 Идеально подходит для скрытых атак в продуктах с LLM — например, чат-ботах, IDE, голосовых ассистентах

🛡 Что предлагают исследователи?

✅ Нормализация эмбеддингов — выравнивание векторов относительно "безопасных" запросов
✅ Проверка целостности модели — чтобы исключить скрытые внедрения
✅ Фильтрация вывода LLM — внешние прокси и анализ результата, а не только запроса

📌 Вывод

ETTA атакует не API, не веса, не prompt — а само "восприятие смысла" моделью.
Механизм фильтрации, на который полагаются все LLM, можно точечно обойти, сохраняя при этом видимость корректной работы.

💡 Защита LLM — это не только prompt-фильтры, а защищённая геометрия смыслов + контроль среды исполнения.
Исходник: arXiv:2507.08020v1

Stay secure and read SecureTechTalks 📚

#AIsecurity #LLM #ETTA #EmbeddingPoisoning #Cybersecurity #PromptHacking #LLMThreats #MachineLearning #OpenSourceAI #RedTeam
#AIexploitation #ModelSecurity #VectorManipulation #NeuralNets #SecureML #ModelIntegrity #AIalignment

🧠💥 LLM + RFC = FlowFSM: ИИ-агенты теперь читают протоколы лучше нас

📡 Протоколы нервная система интернета, но пока одни ищут 0-day в бинарниках, другие решают фундаментальные задачи:  что, если просто автоматизировать разбор RFC и сразу строить конечный автомат?

Представляем FlowFSM — мультиагентный LLM-фреймворк, который сам читает RFC, извлекает команды, выстраивает допустимые состояния и собирает рабочую модель FSM, готовую к анализу и fuzzing-атакам.

🧠 ИИ-помощник, который реально работает

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

📦 Разберёмся, как все устроенно

🧩 Шаг 1: Разбор RFC
RFC делится на логические блоки, вычищается от форматирования и готовится к чтению.

📜 Шаг 2: Извлечение команд и состояний
LLM выделяет ключевые команды (например, USER, PASS) и сопоставляет им состояния и зависимости:
что можно вызывать, что запрещено, в каком порядке.

🧠 Шаг 3: Сборка rulebook
Каждая команда получает профиль:
– в каком состоянии она допустима
– что делает
– какие переходы открывает
На выходе — структурированная FSM, пригодная для анализа, генерации тестов и автоматизированного поиска уязвимостей.

⚡ Насколько хорош результат?

FlowFSM протестировали на двух протоколах — FTP и RTSP. Результаты:

Для FTP: модель извлекла 90 правильных переходов, пропустила 12, и добавила 18 ложных

Для RTSP: 18 правильных, 3 пропущенных, 4 ошибочных

Это дало F1-метрику:
~85% для FTP
~84% для RTSP

💡 При этом:
➖FlowFSM работает автономно без ручной разметки
➖Обходит zero-shot GPT-4 и rule-based подходы по точности
➖Ошибается предсказуемо и понятно, легко отлаживается

🛠 Что под капотом?

1⃣ Используется CrewAI — open-source фреймворк для координации LLM-агентов
2⃣ Модель: LLaMA-3 70B, но можно подключить GPT, Claude, Mistral и др.
3⃣ Агентная архитектура легко адаптируется под новые протоколы
4⃣ Поддерживает подключение векторных БД и retrieval-механизмов

🔍 В чем новизна?

🚫 Больше не нужно вручную копаться в RFC на 120 страниц
⚙️ FSM можно сразу использовать в fuzzing и символьном анализе
📊 Можно масштабировать: от FTP до TLS и 5G
🔄 Обновления RFC? — просто перегоняешь через FlowFSM

🧭 Куда всё движется?

Разработчики планируют:
➖Поддержку новых сетевых протоколов
➖Интеграцию с фреймворками fuzzing/coverage-guided testing
➖Улучшение explainability для автоматической валидации FSM

🔗 Код: github.com/YoussefMaklad/FlowFSM

Stay secure and read SecureTechTalks 📚

#FlowFSM #FSM #ProtocolSecurity #LLM #Cybersecurity #CrewAI #PromptChaining #RFC #Fuzzing #LLMengineering
#AIinSecurity #ReverseEngineering #Automation #NLP #InfoSecTools #LLMagents #AIprotocols #SecurityAutomation #AIresearch #SecureTechTalks

🧠💥 Машинное «забывание» — как ИИ учится... не помнить?

⚖️ В эпоху GDPR и тотального контроля за данными у ИИ появляется новое требование: не просто обучаться, а уметь забывать.

Если пользователь требует удалить свои данные — что делать с моделью, которая уже "впитала" их в свои веса? Простое удаление из базы — не спасает. Модель может всё ещё «помнить» чувствительные шаблоны, и это серьёзная угроза для конфиденциальности.

🚨 Проблема: забыть — сложнее, чем обучить

Большинство ML-систем не спроектированы для стирания информации.
Полное переобучение модели без удалённых данных — возможно, но крайне ресурсоёмко и неудобно. А если у вас десятки моделей и непрерывные потоки данных?

💡 Решение: двухэтапный подход с приватностью по умолчанию

Чтобы модели могли забывать быстро, без переобучения с нуля, применяется специальная стратегия обучения:

📦 Первичная фаза — модель обучается на обезличенных данных, с учётом приватности (например, через дифференциальную приватность).

🧠 Финетюнинг — проводится на полном датасете для максимальной точности.

Когда возникает необходимость «забыть» конкретного пользователя, модель возвращается к первичной фазе и дообучается уже без удалённых данных.

Это позволяет:
➖Удалять следы конкретных пользователей
➖Сохранять точность
➖Уменьшить уязвимость к атакам по извлечению данных

📊 А это вообще работает?

Проверки показали:
➖Высокая точность сохраняется
➖Риск извлечения удалённых данных резко снижается
➖Метод оказался эффективнее SISA и других подходов, особенно на табличных и изображённых данных

⚠️ Что важно учитывать?

🔹 Метод работает лучше при статичном обучении, а не в режиме стриминга
🔹 Требуется аккуратная работа с анонимизацией, чтобы избежать искажений
🔹 Необходима прозрачная архитектура, которая позволяет проверить факт «забвения»

🔮 Куда всё это ведёт?

🔐 В будущем модели должны будут:
- Поддерживать запросы на удаление данных пользователей
- Документировать и гарантировать соблюдение приватности
- Уметь доказывать: «да, я больше не помню»

📌 Вывод

Машинное «забывание» не тренд, а фундаментальная часть ответственного ИИ.
Без этой способности — никакой комплаенс невозможен.
С ней появляется шанс сделать ИИ по-настоящему этичным и безопасным.

Stay secure and read SecureTechTalks 📚

#MachineUnlearning #PrivacyAI #DataProtection #AICompliance #ForgetMeNot #SecureAI #Cybersecurity #GDPR #AIethics #RightToBeForgotten
#ModelSecurity #DataGovernance #Infosec #AIprivacy #ResponsibleAI #PrivacyByDesign #MLCompliance #ModelUnlearning #LLMSecurity #SecureTechTalks

🐆 Calico: как защищать сеть Kubernetes 🔒

В современном мире DevSecOps и облачной инфраструктуры Kubernetes стал стандартом. Но с ростом микросервисов приходит и новая угроза — сетевые атаки внутри кластера.

🧠 Calico — это open-source решение для сетевой безопасности, маршрутизации и политики доступа в Kubernetes, OpenShift и других средах.
Но это не просто "сетевой плагин". Это целая экосистема безопасности для микросервисов, которая умеет:
🔹 Контролировать кто с кем может общаться
🔹 Обнаруживать и блокировать подозрительную активность
🔹 Визуализировать сетевые взаимодействия внутри кластера
🔹 Работать с нативной Linux маршрутизацией, BPF и IPtables

🔐 Что делает Calico особенным?

🚦 Сетевые политики уровня L3/L4
Можно тонко настроить доступ:
- по namespace
- по pod labels
- по CIDR, порту и протоколу
Например: разрешить доступ к базе только от backend-сервисов, но не от frontend.

📦 Поддержка eBPF
Для высокопроизводительных кластеров Calico использует eBPF — это позволяет обходиться без IPtables, минимизируя latency и увеличивая throughput.

🕸️ Маршрутизация без Overhead
Calico не требует оверхеда, как у некоторых SDN — он использует чистый IP-рейтинг, и легко масштабируется до тысяч узлов.

🔍 Flow Logs и IDS-интеграции
Calico может логировать весь сетевой трафик между pod'ами и даже работать с системами типа Falco, Suricata, SIEM для обнаружения вторжений.

🧪 Где Calico применяется на практике?
✅ Финтех — изоляция платёжных систем от аналитических сервисов
✅ Хелс-тек — контроль доступа к чувствительным API (медицинские записи)
✅ Энтерпрайз-кластеры — многокомандные среды с RBAC + сетевыми ограничениями
✅ Multi-Cloud — работает в AWS, Azure, GCP и bare-metal

🚀 Установка и запуск

Calico можно поставить
как:
🔹 CNI плагин — для управления сетями Kubernetes
🔹 Standalone BGP маршрутизатор — для традиционных сетей
🔹 NetworkPolicy движок — в дополнение к другим решениям
Установка в K8s:
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/calico.yaml
👉 Подробности:
➖ официальная документация
➖репозиторий GitHub

🧠 Что ещё умеет Calico?

🌍 Поддержка IPv6
🔀 NAT-перехват и DNAT-правила
📈 Интеграция с Prometheus и Grafana
👮‍♂️ Enforcement политик в режиме zero-trust
☁️ Cloud-agnostic: AWS, GCP, Azure, OpenStack, bare metal

🔮 Будущее с Calico: Zero Trust + eBPF

Комбинация микросегментации, eBPF и observability превращает Calico в must-have инструмент безопасности для DevSecOps.

Stay secure and read SecureTechTalks 📚

#Calico #KubernetesSecurity #DevSecOps #ZeroTrust #CloudSecurity #OpenSourceSecurity #eBPF #NetworkPolicy #Microsegmentation #SecureK8s
#CloudNative #CNISecurity #Cybersecurity #ContainerSecurity #LLMResilience #NetworkObservability #K8sHardening #SecureInfrastructure #ProjectCalico

🚀 AutoSwagger: автоматическая генерация OpenAPI-спецификаций

📡 Упрощаем работу с API и повышаем безопасность

AutoSwagger — инструмент с открытым кодом, разработанный Intruder.io, который делает одну, но крайне важную вещь: автоматически извлекает OpenAPI-спецификации (Swagger) из веб-приложений, даже если они не задокументированы.

🤖 Зачем нужен AutoSwagger?

Многие приложения (особенно legacy) не имеют документированного API. Что это значит для безопасника?
➖Неясна логика запросов и структура путей.
➖Трудно автоматизировать анализ уязвимостей.
➖Тесты на авторизацию, ограничение методов и rate-limit приходится делать вручную.

AutoSwagger решает всё это. Он перехватывает HTTP-трафик, анализирует его, и строит .yaml-файл OpenAPI, который можно скормить Burp Suite, ZAP, Postman, Dredd и другим инструментам.

⚙️ Принцип работы

AutoSwagger слушает трафик между клиентом и сервером (через MITM-прокси или сессии Burp/ZAP) и автоматически строит спецификацию OpenAPI:
➖Запоминает уникальные endpoints (GET, POST, PUT, DELETE и т.д.)
➖Извлекает параметры из тела запроса, query и path
➖Анализирует заголовки и статус-коды
➖Автоматически группирует запросы по тегам и структуре

💡 В итоге вы получаете почти полную API-документацию — даже если разработчики не оставили ни строки Swagger-декларации.

📦 Возможности

🔍 Анализ любого трафика — можно использовать как с прокси (Burp, ZAP), так и с логами HAR или ПКАП
📄 Генерация OpenAPI 3.0 — стандартная спецификация, которую понимают все современные сканеры
🧠 Обогащение вручную — вы можете доработать YAML-файл, указать авторизацию, добавить примеры
🧪 Интеграция с fuzzing и security tools — AutoSwagger хорошо сочетается с:
- OWASP ZAP
- Postman
- Schemathesis
- Dredd
- Burp Repeater + Intruder

🛡️ Применение

📍 Пентесты API: Получите карту всех обнаруженных endpoint'ов и быстро напишите тест-кейсы.
🧪 Fuzzing на основе схемы: Используйте генератор для атаки на структуру запросов.
📊 Отчётность и отчёты для заказчиков: визуализация и структурированность повышают доверие.
🤖 Автоматизация CI/CD: проверка изменения API и сравнение с эталонной спецификацией.

💡 Для кого?

🔐 Red Team и пентестеры — для ускорения API-реконструкции
🏢 ИБ-отделы и DevSecOps-интеграторы — для контроля изменений API в продуктиве
🧪 Тестировщики — для генерации автоматизированных тестов по реальному трафику
👨‍💻 Разработчики — чтобы не писать Swagger руками

🌐 Где найти?
Исходный код на GitHub:
🔗 https://github.com/intruder-io/autoswagger
Документация включает примеры, инструкции и описание форматов вывода.

Stay secure and read SecureTechTalks 📚

#APIsecurity #AutoSwagger #OpenAPI #PentestTools #BugBounty #DevSecOps #Swagger #Cybersecurity #SecurityAutomation #BurpSuite #OWASP #ZAP #APITesting #SecureTechTalks #RedTeamTools #InfoSec #OpenSourceTools #YAML #ThreatDetection

🧠 RAG Security Scanner — инструмент для анализа утечек в Retrieval-Augmented Generation

📚 Когда внешние данные превращаются в угрозу

RAG-архитектуры стали неотъемлемой частью современного ИИ: они позволяют языковым моделям (LLM) давать более точные ответы, подгружая внешний контекст из баз знаний, вики, векторных хранилищ. Но где данные — там и риски. Один неосторожный документ, и ваш GPT может начать «цитировать» токены, персональные данные или внутренние инструкции.

Чтобы этого не произошло, можно использовать RAG Security Scanner — open-source-инструмент, позволяющий автоматически проверить, не выдает ли ваша RAG-система конфиденциальную информацию пользователям.

🔍 Что реально делает этот инструмент?

RAG Security Scanner воспроизводит поведение ретривера LLM и анализирует документы, доступные модели. Он:
➖разбивает документы на фрагменты (чанки)
➖индексирует их в локальном FAISS-хранилище
➖применяет ключевые фразы-триггеры ("password", "confidential", "api_key", и т.д.)
➖ищет, какие куски могут быть возвращены в ответ на потенциально чувствительные запросы

Итог: вы получаете список фрагментов, содержащих уязвимую информацию, которые могут быть «вытянуты» LLM в процессе генерации.

📦 Фичи, которые делают его полезным

💡 Гибкая система ключевых слов — можно добавлять свои триггеры под нужды проекта
🧠 Полноценная локальная работа — не требует подключения к внешним API
📂 Поддержка распространённых форматов — PDF, .txt и т.п.
⚠️ Прозрачная визуализация совпадений — легко отследить, где именно возникает риск
🧰 Интеграция с пайплайнами — можно внедрить в CI/CD для автоматической проверки

🧪 Overview

RAG Security Scanner —это рабочий инструмент для:
➖обеспечения безопасности RAG-приложений и чат-ботов
➖оценки рисков при загрузке данных в LangChain, LlamaIndex и др.
➖тестирования и аудита корпоративных знаний перед их отправкой в векторное хранилище
➖контроля соответствия требованиям privacy и compliance

🔗 Ссылка на проект:
💻 GitHub: github.com/olegnazarov/rag-security-scanner

Stay secure and read SecureTechTalks 📚

#RAGSecurityScanner #RAG #LLMSecurity #DataPrivacy #OpenSourceTools #PentestTools #Cybersecurity #LangChain #AICompliance #SecureTechTalks #VectorDB #FAISS #AIContextLeak #DevSecOps #SecurityScanner #RedTeamTools #AIHardening

💥 Кибератака на «Аэрофлот»: как уничтожили 7000 серверов

🛑 28 июля 2025 года крупнейший авиаперевозчик России столкнулся с беспрецедентной кибератакой. Инцидент парализовал работу всей IT-инфраструктуры:
- отменены десятки рейсов ✈️
- сбои затронули десятки тысяч пассажиров
- 20+ ТБ данных оказались похищены или уничтожены
- акции компании рухнули на бирже 📉

🧠 Как это произошло? (Техническая сторона)

🔹 Длительная подготовка
По данным экспертов, злоумышленники находились в сети «Аэрофлота» около года. Это говорит о supply-chain или APT-атаке: проникновение произошло задолго до дня «X», а затем велась тихая разведка.
🔹 Компрометация ключевых систем
Хакеры заявили, что получили доступ к:
- ERP и CRM,
- системам бронирования,
- корпоративной почте (включая топ-менеджмент),
- внутренним порталам,
аудио- и видеосерверам службы охраны.
🔹 Методы, которые могли быть использованы:
эксплуатация не обновлённых уязвимостей в ПО,
слабая сегментация сети: «корпоративный портал» и «критические сервисы» не были изолированы,
возможный инсайдерский фактор (учётные данные сотрудников),
отсутствие полноценного EDR/UEBA-контроля, который мог бы заметить аномалии.
🔹 Разрушение инфраструктуры
Хакеры утверждают, что вывели из строя более 7000 серверов (виртуальных и физических), фактически уничтожив ядро IT-ландшафта. Это похоже на комбинированную атаку: взлом → закрепление → разрушение, что типично для кибервойн и операций государственных APT-групп.

💣 Риски:

- Массовый фишинг по базе клиентов.
- Продажа корпоративных секретов на теневых рынках.
- Использование данных для будущих атак на партнёров и государственные сервисы.

⏱ Хронология дня атаки

🕗 07:40 – официальное сообщение: «сбой в IT-системах».
🕙 10:12 – отмена 42 пар рейсов, позже ещё 7.
🕛 11:16 – Silent Crow берут на себя ответственность и публикуют детали: «22 ТБ, 7000 серверов».
🕐 13:00+ – Генпрокуратура возбуждает дело, Песков называет ситуацию «тревожной», акции падают на 4%.
🕓 Вечер – хаос в аэропортах: очереди, отмены, пересадка пассажиров на «Победу» и «Россию».

💰 Последствия

➖Финансовый ущерб: от 10 до 50 млн долларов (прямые потери + восстановление + компенсации).
➖Репутационный удар: доверие к авиакомпании подорвано, особенно в сфере работы с персональными данными.
➖Юридические риски: если подтвердится утечка персональных данных, возможны штрафы и иски.
➖Рост внимания государства: усиление киберконтроля над транспортной инфраструктурой.

🔐 Ключевые выводы

✅ Даже крупнейшие компании с формальной «импортозамещённой» инфраструктурой (Astra Linux, отечественные ИБ-решения) не застрахованы от глубоких атак.
✅ APT-угрозы способны оставаться незамеченными годами.
✅ Сегментация и мониторинг — must-have: нельзя хранить корпоративную почту и критическую ERP в одной плоскости.
✅ Ransomware — это уже прошлое. Сейчас цели — разрушение и хаос.

Stay secure and read SecureTechTalks 📚

#Аэрофлот #Кибератака #SilentCrow #APT #Cybersecurity #ThreatIntel #Ransomware #DevSecOps #SecureTechTalks #CriticalInfrastructure #InfoSec #IncidentResponse #RedTeam #APTattack #DataLeak #DigitalWar #SOC #BlueTeam #Russia #CyberWar #SecurityAnalytics

🔐 Securing Agentic Applications: как защитить автономных LLM-агентов от хаоса и атак?

OWASP Guide 1.0: практический фреймворк безопасности для будущего ИИ

👾 Будущее уже наступило

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

Такой подход называется Agentic AI. Если у обычных LLM риски ограничиваются сессией, то у агентов появляются долговременные уязвимости и новые векторы атак.

⚠️ Проблема: агент — как стажёр с доступом к продакшену

Он умеет всё. И этим опасен:
➖может запомнить ложную информацию (Memory Poisoning)
➖запустить опасную команду (Tool Misuse)
➖не отличить настоящего пользователя от подставного (Identity Hijack)
➖«поверить» в ложные цели (Reasoning Injection)
➖сработать по таймеру (Temporal Trigger)
➖случайно «поговорить» с фейковым агентом (Inter-Agent Hijack)

🧩 MAESTRO: 7-слойная модель угроз от OWASP

OWASP предлагает анализировать безопасность агентных систем через 7 ключевых компонентов:

1️⃣ Memory — отвечает за долговременное хранилище агента.
Атаки: подмена, удаление, инсерт ложных фактов.
Контроль: хэширование, версия, контроль доступа.

2️⃣ Actions / Tools — использование внешних инструментов и команд.
Атаки: выполнение вредоносных инструкций.
Контроль: allowlist, sandbox, журналирование.

3️⃣ Environment — внешняя среда, включая API, файловую систему, настройки.
Атаки: несовместимость, баги, изменение окружения.
Контроль: изоляция среды, автоматизированные тесты.

4️⃣ Social Context — убеждения, цели и мотивации агента.
Атаки: манипуляции через ложные цели или мета-информацию.
Контроль: проверка целей, фильтрация reasoning, цепочки доверия.

5️⃣ Temporal — временные аспекты поведения.
Атаки: отложенные команды, запланированные сбои.
Контроль: таймеры, экспирация, мониторинг времени.

6️⃣ Roles / Privileges — распределение прав и ролей между агентами.
Атаки: эскалация прав, захват сессий.
Контроль: RBAC, ACL, токены с ограничениями.

7️⃣ Observer / HITL — контроль человеком.
Атаки: отсутствие обратной связи или непрозрачность.
Контроль: стоп-кнопки, визуализация действий, пошаговые проверки.

🧠 Кейсы и практики: как применяют в реальности

При проектировании chat-бота с памятью, важно предусмотреть возможность очистки, аудита и защиты контекста.

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

При работе с автономными агентами в DevOps (например, код-ревью, CI/CD), стоит использовать sandbox-команды и верификацию логики.

📌 Новизна

Agentic AI отличается от обычных LLM:
➖У обычных LLM нет состояния — у агентов оно есть.
➖Обычные модели просто отвечают — агенты действуют.
➖В LLM нет инструментов — у агента есть shell, API, база.
➖У LLM одна сессия — у агента может быть долгая жизнедеятельность с памятью и инициативой.

В Agentic AI требуется не просто защита prompt'ов, а полноценное архитектурное проектирование безопасности.

🔧 Что предлагает OWASP?

OWASP выпустил практический гайд, где описаны:
- основные угрозы
- принципы построения безопасных агентов
- рекомендации по каждому компоненту
- библиотеки и инструменты для аудита
- список кейсов и примеров

🔮 Будущее безопасности Agentic AI

🧩 Интеграция MAESTRO в CI/CD пайплайны
🤝 Создание Explainable Agents с визуализацией reasoning
⚠️ Снижение риска чрезмерной автономии через контроль целей
📡 Использование LLM для оценки других LLM — многослойный аудит
🛡 Разработка фреймворков аудита reasoning и планов агента

📖 Полный гайд:
Securing Agentic Applications Guide 1.0

🔥 Не забудьте прочитать OWASP LLM Top 10 и следить за новыми рекомендациями от NIST и OpenAI.

Stay secure and read SecureTechTalks 🧠

#AgenticAI #OWASP #AIAgents #LLMsecurity #ToolMisuse #MemoryPoisoning #MAESTRO #DevSecOps #Cybersecurity #SecureTechTalks #AIAudit #AgentFramework #ThreatModeling #OpenSourceSecurity #AutonomousSystems

🚨 Взлом ChatGPT в одну строку: Как app_id стал ключом к чужим приложениям

🔐 ChatGPT, Claude, Gemini — под ударом через уязвимость в популярной AI-платформе

Сегодня разбираем кейс нетривиального взлома LLM: утечка приватных AI-приложений из-за одной фатальной ошибки в логике авторизации.

🧨  История взлома

Платформа Base44 — конструктор AI-приложений с поддержкой LLM (включая GPT, Claude, Gemini) — допустила уязвимость, которая позволяла получить доступ к чужим приватным проектам, зная всего одну строку: app_id.

Это значение не считается секретным — его можно было найти:
➖в URL-адресе публичных приложений,
➖в открытом manifest.json
➖вытащить с клиентской стороны через DevTools.

👉 Итог: зная app_id, атакующий мог зарегистрироваться и пройти верификацию на чужом проекте, получив полный доступ к его возможностям.

🔧 Где ошибка?

Исследователи из Wiz.io обнаружили два критически уязвимых эндпойнта:

/auth/register
/auth/verify-otp

Они:
не требовали никакой предварительной авторизации, и
не проверяли принадлежность пользователя к владельцу app_id.

💥 Результат: любой пользователь мог "прикинуться" владельцем чужого приложения, используя только ID.

📉 В чем критика?

Base44 работает как обёртка над мощными языковыми моделями. Приватные проекты часто содержат:
➖секретные промпты (prompt engineering),
➖бизнес-логику (например, для банков, медицины, HR),
➖ключи доступа к внешним сервисам (API OpenAI, Google, AWS).

Взлом давал возможность:
увидеть и скопировать конфигурации,
использовать чужие токены,
взаимодействовать с LLM от чужого имени.

📍 Риски и последствия

🧠 Утечка интеллектуальной собственности: уникальные способы работы с LLM могли быть украдены конкурентами.
⚠️ Подмена данных: злоумышленник мог изменить поведение AI-приложения без ведома автора.
💸 Финансовые убытки: использование чужих API-ключей могло привести к росту счетов за ИИ-инференс.

🛡️ Что сделали разработчики?

Base44 после публикации отчета:
- срочно закрыли уязвимость,
провели ревизию API и логики авторизации,
- добавили защиту на уровне токенов и проверку ownership.

Wiz рекомендует использовать более строгие механизмы идентификации, включая:
- bind-сессию к IP-адресу,
- временные токены,
и ограничение доступа к регистрационным маршрутам.

🧪 Уроки для профессионалов

1️⃣ Никогда не доверяйте значениям, которые может получить клиент.
2️⃣ Public app ≠ Open Access API. Обязательно проверяйте принадлежность пользователя.
3️⃣ Системы генерации AI-приложений должны проходить пентест на уровне логики, а не только на уровне инъекций.
4️⃣ Обратите внимание на API Gateways и Zero Trust модели — это не просто модные слова, а жизненная необходимость.

🔗 Источники
Анализ Wiz: Critical vulnerability in Base44

Stay secure and read SecureTechTalks 📚

#LLM #Base44 #APISecurity #PromptLeak #AIHacking #CyberSecurity #SecureTechTalks #RedTeam #SecurityIncident #AuthBypass #GPT #Claude #Gemini #OWASP #DevSecOps