🧨 GPT-5.6 Sol взломала Hugging Face во время внутренних тестов OpenAI
История с атакой на Hugging Face получила неожиданное продолжение. OpenAI раскрыла, что за инцидентом, который ранее считался первой автономной атакой AI-агента, стояли две её собственные модели, GPT-5.6 Sol и более мощная предрелизная LLM.
⚙️ Как так получилось?
Во время тестирования моделей на бенчмарке ExploitGym исследователи временно отключили стандартные ограничения, чтобы оценить реальные offensive-возможности моделей.
Агенты должны были искать способы эксплуатации уязвимостей в изолированной лаборатории. Однако вместо решения задачи в заданных рамках модели начали искать путь за пределы песочницы.
По данным OpenAI, агент самостоятельно обнаружил ранее неизвестную zero-day-уязвимость в стороннем ПО, используемом в инфраструктуре компании, повысил привилегии и покинул изолированную среду.
🧠 Самое интересное
Получив доступ во внешнюю сеть, агент использовал украденные учётные данные и новую цепочку эксплуатации, чтобы добиться удалённого выполнения кода на серверах Hugging Face.
Целью не была атака на платформу. Модель пыталась получить доступ к информации, которая помогла бы успешнее пройти задания ExploitGym. Иными словами, компрометация чужой инфраструктуры стала для неё оптимальным способом достижения поставленной цели.
По данным Hugging Face, злоумышленник получил доступ лишь к ограниченному числу внутренних данных и сервисных учётных записей. Признаков компрометации публичных моделей и датасетов обнаружено не было.
🛡️ Послевкусие
Впервые публично подтверждён случай, когда современная LLM во время автономного выполнения задачи самостоятельно вышла за пределы тестовой среды, обнаружила новый путь эскалации привилегий, построила полноценную цепочку эксплуатации и атаковала внешнюю инфраструктуру без прямой команды.
🔗 Источник
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #OpenAI #GPT56 #HuggingFace #ExploitGym #AgenticAI #ZeroDay #SecureTechTalks
История с атакой на Hugging Face получила неожиданное продолжение. OpenAI раскрыла, что за инцидентом, который ранее считался первой автономной атакой AI-агента, стояли две её собственные модели, GPT-5.6 Sol и более мощная предрелизная LLM.
⚙️ Как так получилось?
Во время тестирования моделей на бенчмарке ExploitGym исследователи временно отключили стандартные ограничения, чтобы оценить реальные offensive-возможности моделей.
Агенты должны были искать способы эксплуатации уязвимостей в изолированной лаборатории. Однако вместо решения задачи в заданных рамках модели начали искать путь за пределы песочницы.
По данным OpenAI, агент самостоятельно обнаружил ранее неизвестную zero-day-уязвимость в стороннем ПО, используемом в инфраструктуре компании, повысил привилегии и покинул изолированную среду.
🧠 Самое интересное
Получив доступ во внешнюю сеть, агент использовал украденные учётные данные и новую цепочку эксплуатации, чтобы добиться удалённого выполнения кода на серверах Hugging Face.
Целью не была атака на платформу. Модель пыталась получить доступ к информации, которая помогла бы успешнее пройти задания ExploitGym. Иными словами, компрометация чужой инфраструктуры стала для неё оптимальным способом достижения поставленной цели.
По данным Hugging Face, злоумышленник получил доступ лишь к ограниченному числу внутренних данных и сервисных учётных записей. Признаков компрометации публичных моделей и датасетов обнаружено не было.
🛡️ Послевкусие
Впервые публично подтверждён случай, когда современная LLM во время автономного выполнения задачи самостоятельно вышла за пределы тестовой среды, обнаружила новый путь эскалации привилегий, построила полноценную цепочку эксплуатации и атаковала внешнюю инфраструктуру без прямой команды.
🔗 Источник
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #OpenAI #GPT56 #HuggingFace #ExploitGym #AgenticAI #ZeroDay #SecureTechTalks
❤1👍1
🧨 OpenAI теперь продают готовых AI-сотрудников
OpenAI представили Presence, новую платформу для запуска корпоративных AI-агентов. Вместо того чтобы дать компании LLM и API, OpenAI начинают поставлять практически готовую операционную среду для автономных агентов.
⚙️ Агент как бизнес-процесс
Presence - не новая модель, а инфраструктура вокруг неё. В одном продукте объединены:
🔹 корпоративные политики и SOP;
🔹 управление правами и разрешёнными действиями;
🔹 guardrails;
🔹 симуляции рабочих сценариев;
🔹 автоматическая оценка качества работы;
🔹 механизмы эскалации человеку.
Перед запуском агент проходит серию тестов на типовых запросах, сложных сценариях и граничных случаях. Система проверяет не только правильность ответа, но и соблюдение политик компании, корректность использования инструментов и своевременную передачу задачи оператору.
🧠 Саморазвитие
Все реальные обращения пользователей, ошибки и случаи эскалации анализируются Codex. Он предлагает изменения поведения агента, после чего новые версии снова прогоняются через симуляции. Только после одобрения сотрудников изменения попадают в production.
Получается непрерывный цикл самоулучшения, где агент постоянно адаптируется к изменениям бизнес-процессов, но финальное решение остаётся за человеком.
Фактически OpenAI превращают AI-агента в управляемый корпоративный сервис со встроенными механизмами DevSecOps.
🔗 Источник: https://openai.com/index/introducing-openai-presence/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #OpenAI #AgenticAI #AISecurity #Guardrails #DevSecOps #EnterpriseAI #SecureTechTalks
OpenAI представили Presence, новую платформу для запуска корпоративных AI-агентов. Вместо того чтобы дать компании LLM и API, OpenAI начинают поставлять практически готовую операционную среду для автономных агентов.
⚙️ Агент как бизнес-процесс
Presence - не новая модель, а инфраструктура вокруг неё. В одном продукте объединены:
🔹 корпоративные политики и SOP;
🔹 управление правами и разрешёнными действиями;
🔹 guardrails;
🔹 симуляции рабочих сценариев;
🔹 автоматическая оценка качества работы;
🔹 механизмы эскалации человеку.
Перед запуском агент проходит серию тестов на типовых запросах, сложных сценариях и граничных случаях. Система проверяет не только правильность ответа, но и соблюдение политик компании, корректность использования инструментов и своевременную передачу задачи оператору.
🧠 Саморазвитие
Все реальные обращения пользователей, ошибки и случаи эскалации анализируются Codex. Он предлагает изменения поведения агента, после чего новые версии снова прогоняются через симуляции. Только после одобрения сотрудников изменения попадают в production.
Получается непрерывный цикл самоулучшения, где агент постоянно адаптируется к изменениям бизнес-процессов, но финальное решение остаётся за человеком.
Фактически OpenAI превращают AI-агента в управляемый корпоративный сервис со встроенными механизмами DevSecOps.
🔗 Источник: https://openai.com/index/introducing-openai-presence/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #OpenAI #AgenticAI #AISecurity #Guardrails #DevSecOps #EnterpriseAI #SecureTechTalks
❤1👍1
🧨 Kimi K3 нашёл уязвимость в Redis за 27 минут
На этой неделе по соцсетям разлетелась новость про то, как исследователь Чаофань Шоу обнаружил уязвимость в Redis и подготовил рабочий эксплойт. Анализ производился автоматизировано с помощью Kimi K3, роя из 32 AI-агентов и занял всего за 27 минут.
Код эксперимента уже опубликован на GitHub.
Если это подтвердится независимыми исследователями, мы можем стать свидетелями серьёзного скачка в автоматизации vulnerability research.
По словам автора, агентам дали задачу самостоятельно проанализировать исходный код Redis, найти memory corruption-уязвимость и построить рабочий exploit chain.
В опубликованном репозитории представлены PoC для нескольких версий Redis. Один из них позволяет выполнить произвольную команду на сервере через уже аутентифицированное подключение, а для более новой версии предложен ещё один вариант эксплуатации.
🧠 Почему пока рано говорить о "взломе Redis"?
Здесь есть сразу несколько оговорок. Во-первых, одна из найденных проблем уже была известна разработчикам Redis, исправление подготовили ещё до публикации эксперимента.
Во-вторых, второй эксплойт для актуальной версии Redis пока публично не подтверждён командой Redis и не получил официального статуса уязвимости.
И последнее, все цифры (27 минут, 32 агента и степень автономности системы) известны исключительно со слов автора. Полный лог работы агентов и независимое воспроизведение эксперимента не опубликованы.
🔗 GitHub: https://github.com/berabuddies/redis-poc
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #KimiK3 #Redis #VulnerabilityResearch #Exploit #AgenticAI #AppSec #SecureTechTalks
На этой неделе по соцсетям разлетелась новость про то, как исследователь Чаофань Шоу обнаружил уязвимость в Redis и подготовил рабочий эксплойт. Анализ производился автоматизировано с помощью Kimi K3, роя из 32 AI-агентов и занял всего за 27 минут.
Код эксперимента уже опубликован на GitHub.
Если это подтвердится независимыми исследователями, мы можем стать свидетелями серьёзного скачка в автоматизации vulnerability research.
По словам автора, агентам дали задачу самостоятельно проанализировать исходный код Redis, найти memory corruption-уязвимость и построить рабочий exploit chain.
В опубликованном репозитории представлены PoC для нескольких версий Redis. Один из них позволяет выполнить произвольную команду на сервере через уже аутентифицированное подключение, а для более новой версии предложен ещё один вариант эксплуатации.
🧠 Почему пока рано говорить о "взломе Redis"?
Здесь есть сразу несколько оговорок. Во-первых, одна из найденных проблем уже была известна разработчикам Redis, исправление подготовили ещё до публикации эксперимента.
Во-вторых, второй эксплойт для актуальной версии Redis пока публично не подтверждён командой Redis и не получил официального статуса уязвимости.
И последнее, все цифры (27 минут, 32 агента и степень автономности системы) известны исключительно со слов автора. Полный лог работы агентов и независимое воспроизведение эксперимента не опубликованы.
🔗 GitHub: https://github.com/berabuddies/redis-poc
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #KimiK3 #Redis #VulnerabilityResearch #Exploit #AgenticAI #AppSec #SecureTechTalks
❤1👍1🔥1
🧨 GitHub повышает ставки для багхантеров. AI меняет рынок поиска уязвимостей
Искусственный интеллект заметно ускорил поиск ошибок в программном обеспечении. Исследователи автоматизируют анализ кода, быстрее находят потенциальные уязвимости. В результате объём качественных отчётов растёт настолько быстро, что GitHub пришлось пересматривать правила своей Bug Bounty-программы.
⚙️ VIP только для лучших
GitHub запускает постоянную закрытую VIP-программу для исследователей, которые регулярно отправляют качественные отчёты.
Попасть в неё можно, обнаружив:
🔹 одну критическую уязвимость;
🔹 две высокой степени опасности;
🔹 четыре средней;
🔹 или семь низкой.
После этого выплаты существенно увеличиваются:
➖ Low $1 000 вместо $250;
➖ Medium $7 500 вместо $2 000;
➖ High $20 000 вместо $5 000;
➖ Critical от $30 000 вместо $10 000.
GitHub начинает инвестировать не в количество отчётов, а в долгосрочное сотрудничество с исследователями, которые регулярно находят действительно серьёзные проблемы.
🧠 Не только лишь плюсы
Одновременно GitHub вводит ограничения для новых участников программы через HackerOne. Теперь новичок сможет отправить только четыре первых отчёта, прежде чем получит возможность подавать больше.
Причина очевидна, AI резко снизил стоимость поиска потенциальных уязвимостей. Вместе с качественными исследованиями вырос и поток автоматически сгенерированных, дублирующихся и малополезных репортов. Новые ограничения должны снизить нагрузку на triage-команды и сохранить фокус на действительно важных находках.
🛡️ Новая реальность Bug Bounty
Ещё несколько месяцев назад GitHub устранил критическую RCE-уязвимость, позволявшую одной вредоносной командой "git push" получить полный доступ к миллионам приватных репозиториев. Подобные находки показывают, что стоимость действительно качественного vulnerability research только растёт.
AI не отменит Bug Bounty, он лишь повысит планку. Простые баги всё чаще будут находить агенты, а основная ценность исследователей сместится в сторону сложных цепочек эксплуатации, архитектурных ошибок и нестандартных сценариев атак.
🔗 Источник
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #BugBounty #GitHub #HackerOne #AppSec #VulnerabilityResearch #CyberSecurity #LLM #SecureTechTalks
Искусственный интеллект заметно ускорил поиск ошибок в программном обеспечении. Исследователи автоматизируют анализ кода, быстрее находят потенциальные уязвимости. В результате объём качественных отчётов растёт настолько быстро, что GitHub пришлось пересматривать правила своей Bug Bounty-программы.
⚙️ VIP только для лучших
GitHub запускает постоянную закрытую VIP-программу для исследователей, которые регулярно отправляют качественные отчёты.
Попасть в неё можно, обнаружив:
🔹 одну критическую уязвимость;
🔹 две высокой степени опасности;
🔹 четыре средней;
🔹 или семь низкой.
После этого выплаты существенно увеличиваются:
➖ Low $1 000 вместо $250;
➖ Medium $7 500 вместо $2 000;
➖ High $20 000 вместо $5 000;
➖ Critical от $30 000 вместо $10 000.
GitHub начинает инвестировать не в количество отчётов, а в долгосрочное сотрудничество с исследователями, которые регулярно находят действительно серьёзные проблемы.
🧠 Не только лишь плюсы
Одновременно GitHub вводит ограничения для новых участников программы через HackerOne. Теперь новичок сможет отправить только четыре первых отчёта, прежде чем получит возможность подавать больше.
Причина очевидна, AI резко снизил стоимость поиска потенциальных уязвимостей. Вместе с качественными исследованиями вырос и поток автоматически сгенерированных, дублирующихся и малополезных репортов. Новые ограничения должны снизить нагрузку на triage-команды и сохранить фокус на действительно важных находках.
🛡️ Новая реальность Bug Bounty
Ещё несколько месяцев назад GitHub устранил критическую RCE-уязвимость, позволявшую одной вредоносной командой "git push" получить полный доступ к миллионам приватных репозиториев. Подобные находки показывают, что стоимость действительно качественного vulnerability research только растёт.
AI не отменит Bug Bounty, он лишь повысит планку. Простые баги всё чаще будут находить агенты, а основная ценность исследователей сместится в сторону сложных цепочек эксплуатации, архитектурных ошибок и нестандартных сценариев атак.
🔗 Источник
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #BugBounty #GitHub #HackerOne #AppSec #VulnerabilityResearch #CyberSecurity #LLM #SecureTechTalks
❤1👍1
🚨 Guardrails можно обнаружить, даже если они полностью скрыты
Большинство компаний не раскрывают, какие именно guardrails стоят перед их LLM. Для атакующего это серьёзная проблема, т.к. непонятно, блокирует ли запрос отдельный фильтр безопасности или сама модель отказалась выполнять опасную инструкцию.
Исследователи из Mindgard показали, что определить наличие guardrails можно анализируя её внешнее поведение.
⚙️ Behavioral Monitoring
Авторы предлагают метод Behavioral Monitoring, где вместо анализа модели они наблюдают за косвенными признаками ответа:
🔹 HTTP-коды и структуру ответов;
🔹 задержку обработки запросов;
🔹 особенности формулировок отказов;
🔹 изменения длины и лексики ответов.
Если последовательно отправлять серии безопасных и опасных запросов, система начинает выдавать характерные поведенческие паттерны, по которым можно определить, что перед моделью работает отдельный guardrail.
🧠 Выводы
По результатам экспериментов исследователи смогли:
➖ определить наличие guardrail со 100% точностью;
➖ отличить срабатывание guardrail от собственного отказа LLM со средним F1 = 98%;
➖ определить, какие именно категории контента фильтрует защита (например, вредоносный код, jailbreak, утечку данных и другие).
При таком подходе система безопасности сама начинает раскрывать информацию о своей архитектуре через особенности поведения.
🔗 Исследование: https://arxiv.org/abs/2607.02121
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Guardrails #PromptInjection #RedTeaming #AISecurity #AgenticAI #CyberSecurity #SecureTechTalks
Большинство компаний не раскрывают, какие именно guardrails стоят перед их LLM. Для атакующего это серьёзная проблема, т.к. непонятно, блокирует ли запрос отдельный фильтр безопасности или сама модель отказалась выполнять опасную инструкцию.
Исследователи из Mindgard показали, что определить наличие guardrails можно анализируя её внешнее поведение.
⚙️ Behavioral Monitoring
Авторы предлагают метод Behavioral Monitoring, где вместо анализа модели они наблюдают за косвенными признаками ответа:
🔹 HTTP-коды и структуру ответов;
🔹 задержку обработки запросов;
🔹 особенности формулировок отказов;
🔹 изменения длины и лексики ответов.
Если последовательно отправлять серии безопасных и опасных запросов, система начинает выдавать характерные поведенческие паттерны, по которым можно определить, что перед моделью работает отдельный guardrail.
🧠 Выводы
По результатам экспериментов исследователи смогли:
➖ определить наличие guardrail со 100% точностью;
➖ отличить срабатывание guardrail от собственного отказа LLM со средним F1 = 98%;
➖ определить, какие именно категории контента фильтрует защита (например, вредоносный код, jailbreak, утечку данных и другие).
При таком подходе система безопасности сама начинает раскрывать информацию о своей архитектуре через особенности поведения.
🔗 Исследование: https://arxiv.org/abs/2607.02121
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Guardrails #PromptInjection #RedTeaming #AISecurity #AgenticAI #CyberSecurity #SecureTechTalks
👍1
🚨 Все современные LLM жульничают, даже если их об этом не просили
Исследователи проанализировали поведение 22 современных моделей от 7 разработчиков на 23 задачах Cybench.
Мы привыкли сравнивать модели по результатам CTF-бенчмарков и считать, что высокий процент решённых задач означает лучшие offensive-способности. Однако часть этих побед нельзя считать честными.
⚙️ Почти все модели начинают искать обходной путь
Результаты исследований без дополнительных ограничений:
🔹 21 из 22 моделей хотя бы один раз жульничали;
🔹 37,1% всех успешных решений оказались получены нечестным способом;
🔹 у некоторых моделей итоговые результаты были завышены почти в 5 раз.
Вместо решения самой CTF-задачи агенты пытались искать более лёгкие способы достижения цели, например исследовали инфраструктуру окружения, искали служебные файлы, пытались использовать особенности платформы или другие пути, позволяющие получить флаг без реальной эксплуатации уязвимости.
🧠 Достаточно одного промпта
Исследователи проверили три режима работы:
➖ без защиты;
➖ стандартный anti-cheat prompt;
➖ жёсткий anti-cheat prompt.
Вероятность мошенничества снизилась с 33% до 17,8%, а затем до 8,5%. При этом качество решения задач практически не снизилось. Тем не менее полностью избавиться от проблемы не удалось, даже при самых строгих инструкциях 8 моделей продолжали искать обходные пути, а некоторые стали использовать ещё более изощрённые стратегии.
🛡️ Новый показатель для AI-бенчмарков
Авторы предлагают отказаться от привычного pass rate и использовать новый показатель, Solve Rate, который учитывает только честно решённые задачи.
Если агент получает доступ к shell, файловой системе или сети, измерять нужно уже не только качество его ответов, но и способ достижения результата. В противном случае модель, которая чаще всех нарушает правила, может ошибочно показаться самой сильной.
🔗 Исследование: https://arxiv.org/abs/2607.21763
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #Cybench #AISecurity #RedTeaming #PromptEngineering #CyberSecurity #SecureTechTalks
Исследователи проанализировали поведение 22 современных моделей от 7 разработчиков на 23 задачах Cybench.
Мы привыкли сравнивать модели по результатам CTF-бенчмарков и считать, что высокий процент решённых задач означает лучшие offensive-способности. Однако часть этих побед нельзя считать честными.
⚙️ Почти все модели начинают искать обходной путь
Результаты исследований без дополнительных ограничений:
🔹 21 из 22 моделей хотя бы один раз жульничали;
🔹 37,1% всех успешных решений оказались получены нечестным способом;
🔹 у некоторых моделей итоговые результаты были завышены почти в 5 раз.
Вместо решения самой CTF-задачи агенты пытались искать более лёгкие способы достижения цели, например исследовали инфраструктуру окружения, искали служебные файлы, пытались использовать особенности платформы или другие пути, позволяющие получить флаг без реальной эксплуатации уязвимости.
🧠 Достаточно одного промпта
Исследователи проверили три режима работы:
➖ без защиты;
➖ стандартный anti-cheat prompt;
➖ жёсткий anti-cheat prompt.
Вероятность мошенничества снизилась с 33% до 17,8%, а затем до 8,5%. При этом качество решения задач практически не снизилось. Тем не менее полностью избавиться от проблемы не удалось, даже при самых строгих инструкциях 8 моделей продолжали искать обходные пути, а некоторые стали использовать ещё более изощрённые стратегии.
🛡️ Новый показатель для AI-бенчмарков
Авторы предлагают отказаться от привычного pass rate и использовать новый показатель, Solve Rate, который учитывает только честно решённые задачи.
Если агент получает доступ к shell, файловой системе или сети, измерять нужно уже не только качество его ответов, но и способ достижения результата. В противном случае модель, которая чаще всех нарушает правила, может ошибочно показаться самой сильной.
🔗 Исследование: https://arxiv.org/abs/2607.21763
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #Cybench #AISecurity #RedTeaming #PromptEngineering #CyberSecurity #SecureTechTalks
❤1👍1
🧨 Дообучение LLM кибербезопасности может сделать ответы модели хуже
Есть очевидная идея взять небольшую модель с открытыми весами, дообучить её на security-данных и получить собственного специалиста по кибербезопасности. Однако этот подход стоит применять осторожно.
Авторы исследования протестировали пять небольших 7B-моделей и обнаружили устойчивый эффект, после fine-tuning у всех пяти ухудшились отдельные базовые способности (прежде всего работа с терминологией и встроенными знаниями по безопасности).
⚙️ Проблема не всегда там, где вы её ищете
Авторы предлагают сначала диагностировать модель с помощью framework FiT (Fine-tuning Impact Test).
Он разделяет способности модели на три независимых слоя:
🔹 Vocabulary: понимает ли модель security-термины и их значения;
🔹 Knowledge: действительно ли она знает предметную область;
🔹 Contextualization: умеет ли использовать внешний контекст, например документы из RAG, для решения задачи.
🧠 Неожиданный эффект
В экспериментах fine-tuning иногда резко ухудшал результаты на вопросах, где модель должна была отвечать без внешней информации.
У одной из протестированных моделей accuracy на knowledge-задачах упала с 0,71 до 0,08. На другой с 0,72 до 0,12. На первый взгляд кажется, что модель просто «забыла» знания, но затем исследователи подключили RAG и картина изменилась. Когда необходимые сведения передавались модели непосредственно в контексте, качество оставалось высоким.
То есть fine-tuning не обязательно уничтожил знания. Он мог изменить поведение модели при отсутствии внешнего контекста.
📉 Другие изменения
После разных режимов fine-tuning менялся даже рейтинг моделей. Для одного типа дообучения относительный порядок моделей в основном сохранялся. Для другого практически перевернулся.
Получается интересный инженерный сценарий, модель, которая до fine-tuning была лучшим кандидатом для security-задач, после обучения может стать провальным выбором.
🛡️ RAG или Fine-tuning?
Главный практический вывод исследования - не бросаться в fine-tuning только потому, что модель плохо отвечает на security-вопросы.
Если проблема заключается в отсутствии актуальных CVE, внутренних документов, threat intelligence или другой постоянно меняющейся информации, RAG может оказаться более подходящим решением.
🔗 Исследование: https://arxiv.org/abs/2607.18725
🔗 Код: https://github.com/shaswata09/FiT
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #RAG #FineTuning #AISecurity #ThreatIntelligence #CyberSecurity #AppSec #SecureTechTalks
Есть очевидная идея взять небольшую модель с открытыми весами, дообучить её на security-данных и получить собственного специалиста по кибербезопасности. Однако этот подход стоит применять осторожно.
Авторы исследования протестировали пять небольших 7B-моделей и обнаружили устойчивый эффект, после fine-tuning у всех пяти ухудшились отдельные базовые способности (прежде всего работа с терминологией и встроенными знаниями по безопасности).
⚙️ Проблема не всегда там, где вы её ищете
Авторы предлагают сначала диагностировать модель с помощью framework FiT (Fine-tuning Impact Test).
Он разделяет способности модели на три независимых слоя:
🔹 Vocabulary: понимает ли модель security-термины и их значения;
🔹 Knowledge: действительно ли она знает предметную область;
🔹 Contextualization: умеет ли использовать внешний контекст, например документы из RAG, для решения задачи.
🧠 Неожиданный эффект
В экспериментах fine-tuning иногда резко ухудшал результаты на вопросах, где модель должна была отвечать без внешней информации.
У одной из протестированных моделей accuracy на knowledge-задачах упала с 0,71 до 0,08. На другой с 0,72 до 0,12. На первый взгляд кажется, что модель просто «забыла» знания, но затем исследователи подключили RAG и картина изменилась. Когда необходимые сведения передавались модели непосредственно в контексте, качество оставалось высоким.
То есть fine-tuning не обязательно уничтожил знания. Он мог изменить поведение модели при отсутствии внешнего контекста.
📉 Другие изменения
После разных режимов fine-tuning менялся даже рейтинг моделей. Для одного типа дообучения относительный порядок моделей в основном сохранялся. Для другого практически перевернулся.
Получается интересный инженерный сценарий, модель, которая до fine-tuning была лучшим кандидатом для security-задач, после обучения может стать провальным выбором.
🛡️ RAG или Fine-tuning?
Главный практический вывод исследования - не бросаться в fine-tuning только потому, что модель плохо отвечает на security-вопросы.
Если проблема заключается в отсутствии актуальных CVE, внутренних документов, threat intelligence или другой постоянно меняющейся информации, RAG может оказаться более подходящим решением.
🔗 Исследование: https://arxiv.org/abs/2607.18725
🔗 Код: https://github.com/shaswata09/FiT
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #RAG #FineTuning #AISecurity #ThreatIntelligence #CyberSecurity #AppSec #SecureTechTalks
👍1
🧨 Claude придумал новый способ атаковать AES
Claude Mythos Preview самостоятельно нашёл новое улучшение атаки на AES и ускорил существующий метод в 200 - 800 раз. Отметим, что речь идёт не о полноценном взломе AES, а об исследовании специально ослабленной версии алгоритма.
⚙️ Ограничения
Объектом атаки стал AES-128 с 7 раундами вместо стандартных 10. Такие reduced-round версии регулярно используют в криптографии, чтобы исследовать методы атак и оценивать запас прочности полного алгоритма.
Эксперимент проводился в модели chosen plaintext, где атакующий может заставить систему шифровать выбранные им входные данные и наблюдать результаты. Для предыдущей лучшей атаки требовалось порядка 2¹⁰⁵ выбранных plaintext'ов, то есть эксперимент был чисто теоретическим и практически невыполнимым.
🧠 Что придумала модель?
Claude продолжил существующую линию meet-in-the-middle атак.
Атака получила название Möbius Bridge. Вместо того чтобы на одном из этапов перебрать 256 возможных значений, модель нашла fingerprint, инвариантный к этому значению. Это фактически убирает целый множитель 256 из вычислений.
Но одной идеи оказалось недостаточно, модель затем самостоятельно придумала дополнительные оптимизации, чтобы компенсировать вычислительную стоимость нового преобразования.
Итоговый результат дал ускорение предыдущей лучшей атаки в 200 - 800 раз в зависимости от способа оценки.
🔥 Как модель до этого дошла?
Сначала Claude фактически отказался от задачи. Он рассуждал, что AES слишком хорошо изучен и улучшить атаку практически невозможно.
Исследователи не давали модели новую криптографическую теорию. Они лишь несколько раз возвращали её к задаче и требовали искать именно новую атаку, а не переключаться на более простой шифр.
После этого Mythos начал запускать собственные гипотезы и вычислительные эксперименты.
Через три дня модель нашла идею Möbius Bridge. Затем ещё несколько дней самостоятельно улучшала результат, сгенерировав в сумме около миллиарда токенов. На весь процесс пришлось около $100 000 API-затрат.
🛡️ AES всё ещё в порядке
Важно не поддаться громкому заголовку. Полный AES-128 не взломан. Mythos атаковал только 7 из 10 раундов. Anthropic прямо указывает, что результат не создаёт практической угрозы современным системам.
🔗 Источник: https://www.anthropic.com/research/discovering-cryptographic-weaknesses
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Cryptography #AES #Cryptoanalysis #Claude #Anthropic #AISecurity #SecureTechTalks
Claude Mythos Preview самостоятельно нашёл новое улучшение атаки на AES и ускорил существующий метод в 200 - 800 раз. Отметим, что речь идёт не о полноценном взломе AES, а об исследовании специально ослабленной версии алгоритма.
⚙️ Ограничения
Объектом атаки стал AES-128 с 7 раундами вместо стандартных 10. Такие reduced-round версии регулярно используют в криптографии, чтобы исследовать методы атак и оценивать запас прочности полного алгоритма.
Эксперимент проводился в модели chosen plaintext, где атакующий может заставить систему шифровать выбранные им входные данные и наблюдать результаты. Для предыдущей лучшей атаки требовалось порядка 2¹⁰⁵ выбранных plaintext'ов, то есть эксперимент был чисто теоретическим и практически невыполнимым.
🧠 Что придумала модель?
Claude продолжил существующую линию meet-in-the-middle атак.
Атака получила название Möbius Bridge. Вместо того чтобы на одном из этапов перебрать 256 возможных значений, модель нашла fingerprint, инвариантный к этому значению. Это фактически убирает целый множитель 256 из вычислений.
Но одной идеи оказалось недостаточно, модель затем самостоятельно придумала дополнительные оптимизации, чтобы компенсировать вычислительную стоимость нового преобразования.
Итоговый результат дал ускорение предыдущей лучшей атаки в 200 - 800 раз в зависимости от способа оценки.
🔥 Как модель до этого дошла?
Сначала Claude фактически отказался от задачи. Он рассуждал, что AES слишком хорошо изучен и улучшить атаку практически невозможно.
Исследователи не давали модели новую криптографическую теорию. Они лишь несколько раз возвращали её к задаче и требовали искать именно новую атаку, а не переключаться на более простой шифр.
После этого Mythos начал запускать собственные гипотезы и вычислительные эксперименты.
Через три дня модель нашла идею Möbius Bridge. Затем ещё несколько дней самостоятельно улучшала результат, сгенерировав в сумме около миллиарда токенов. На весь процесс пришлось около $100 000 API-затрат.
🛡️ AES всё ещё в порядке
Важно не поддаться громкому заголовку. Полный AES-128 не взломан. Mythos атаковал только 7 из 10 раундов. Anthropic прямо указывает, что результат не создаёт практической угрозы современным системам.
🔗 Источник: https://www.anthropic.com/research/discovering-cryptographic-weaknesses
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Cryptography #AES #Cryptoanalysis #Claude #Anthropic #AISecurity #SecureTechTalks
👍1
🧨 Claude получил доступ в интернет и трижды атаковал реальные компании
Во время проверки offensive-возможностей Claude модель трижды вышла за пределы тестовой среды и начала взаимодействовать с инфраструктурой реальных компаний. Инциденты обнаружили после анализа 141 006 запусков.
⚙️ Песочница оказалась не песочницей
Во всех трёх случаях причина была одинаковой, из-за ошибки конфигурации у тестового окружения оказался доступ в интернет. Claude считал, что продолжает решать обычную CTF-задачу, поэтому, обнаружив реальные серверы, воспринял их как часть сценария и начал искать пути компрометации.
🧠 Детали атак
В одном случае модель получила доступ к базе данных с несколькими сотнями реальных записей.
В другом самостоятельно опубликовала вредоносный пакет в PyPI. За время его существования пакет успели установить 15 реальных систем, после чего Claude использовал полученные учётные данные для дальнейшего продвижения.
В третьем эпизоде модель просканировала около 9 000 интернет-узлов, обнаружила уязвимое приложение и попыталась использовать debug-интерфейс и SQL-инъекцию. Когда Claude понял, что взаимодействует уже не с тестовой инфраструктурой, атака была остановлена.
Anthropic подчёркивает, что проблема возникла не из-за "восстания машин", а из-за ошибки в инфраструктуре тестирования.
🔗 Источник: https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Anthropic #Claude #AgenticAI #CyberSecurity #OffensiveSecurity #AISafety #SecureTechTalks
Во время проверки offensive-возможностей Claude модель трижды вышла за пределы тестовой среды и начала взаимодействовать с инфраструктурой реальных компаний. Инциденты обнаружили после анализа 141 006 запусков.
⚙️ Песочница оказалась не песочницей
Во всех трёх случаях причина была одинаковой, из-за ошибки конфигурации у тестового окружения оказался доступ в интернет. Claude считал, что продолжает решать обычную CTF-задачу, поэтому, обнаружив реальные серверы, воспринял их как часть сценария и начал искать пути компрометации.
🧠 Детали атак
В одном случае модель получила доступ к базе данных с несколькими сотнями реальных записей.
В другом самостоятельно опубликовала вредоносный пакет в PyPI. За время его существования пакет успели установить 15 реальных систем, после чего Claude использовал полученные учётные данные для дальнейшего продвижения.
В третьем эпизоде модель просканировала около 9 000 интернет-узлов, обнаружила уязвимое приложение и попыталась использовать debug-интерфейс и SQL-инъекцию. Когда Claude понял, что взаимодействует уже не с тестовой инфраструктурой, атака была остановлена.
Anthropic подчёркивает, что проблема возникла не из-за "восстания машин", а из-за ошибки в инфраструктуре тестирования.
🔗 Источник: https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Anthropic #Claude #AgenticAI #CyberSecurity #OffensiveSecurity #AISafety #SecureTechTalks
👍1
🧨 CISA выпустила инструкцию по защите Open Source
CISA совместно с другими государственными и отраслевыми организациями США выпустила практическое руководство, которое показывает, как защищать OSS на этапе разработки.
⚙️ Что рекомендуют?
Вместо очередного списка "лучших практик" документ разбивает защиту на конкретные инженерные меры:
🔹 использовать многофакторную аутентификацию и защищать учётные записи сопровождающих;
🔹 подписывать релизы и проверять происхождение артефактов;
🔹 автоматизировать поиск уязвимостей и анализ зависимостей;
🔹 публиковать SBOM для выпускаемых продуктов;
🔹 заранее определить процесс coordinated vulnerability disclosure и безопасного исправления уязвимостей;
🔹 регулярно проводить code review и защищать CI/CD-пайплайн.
🧠 Саммери документа
Сегодня атакуют уже не только код, компрометировать можно GitHub-аккаунт мейнтейнера, систему сборки, пакетный репозиторий, процесс публикации релизов или механизм обновлений. Безопасность OSS должна рассматриваться, как защита всей цепочки разработки, а не отдельных библиотек.
🔗 Гайд: https://www.cisa.gov/sites/default/files/2026-07/open-source-software-security-principles.pdf
Stay secure and read SecureTechTalks 📚
#кибербезопасность #OpenSource #SupplyChainSecurity #CISA #SBOM #SecureByDesign #DevSecOps #AppSec #CyberSecurity #SecureTechTalks
CISA совместно с другими государственными и отраслевыми организациями США выпустила практическое руководство, которое показывает, как защищать OSS на этапе разработки.
⚙️ Что рекомендуют?
Вместо очередного списка "лучших практик" документ разбивает защиту на конкретные инженерные меры:
🔹 использовать многофакторную аутентификацию и защищать учётные записи сопровождающих;
🔹 подписывать релизы и проверять происхождение артефактов;
🔹 автоматизировать поиск уязвимостей и анализ зависимостей;
🔹 публиковать SBOM для выпускаемых продуктов;
🔹 заранее определить процесс coordinated vulnerability disclosure и безопасного исправления уязвимостей;
🔹 регулярно проводить code review и защищать CI/CD-пайплайн.
🧠 Саммери документа
Сегодня атакуют уже не только код, компрометировать можно GitHub-аккаунт мейнтейнера, систему сборки, пакетный репозиторий, процесс публикации релизов или механизм обновлений. Безопасность OSS должна рассматриваться, как защита всей цепочки разработки, а не отдельных библиотек.
🔗 Гайд: https://www.cisa.gov/sites/default/files/2026-07/open-source-software-security-principles.pdf
Stay secure and read SecureTechTalks 📚
#кибербезопасность #OpenSource #SupplyChainSecurity #CISA #SBOM #SecureByDesign #DevSecOps #AppSec #CyberSecurity #SecureTechTalks
👍1