LIMB
Мне попался свежий пост из блога известного китайского ИБ-исследователя 黑哥 (Heige, @riusksk) - "Black-bro". Показалость интересным.
Делюсь переводом.
На самом деле, когда ChatGPT стал огромным хитом, многие считали, что кибербезопасность — главный бенефициар, но я тогда был довольно пессимистичен, главным образом потому, что сама индустрия кибербезопасности небольшая, сильно фрагментированная и обладает неконцентрированными знаниями и накоплением данных. Реальность в основном пошла в этом направлении. Конечно, кибербезопасность обладает безграничным потенциалом, поскольку многие считают, что без неё нет национальной безопасности. Anthropic, возможно, официально это осознали и начали делать новые прорывы в кибербезопасности, особенно в выявлении и эксплуатации уязвимостей.
Благодаря серии операций Anthropic они успешно создали загадочный и грандиозный образ модели Клода Мифоса, до такой степени, что я постоянно получал вопросы со всех сторон: «Black-bro, ты когда-нибудь использовал Mythos?» ”
Сначала хочу уточнить: я действительно не использовал модель Mythos Клода! Моей основной моделью всегда был OpenAI. Почему так, я говорил в своём кругу, что Anthropic — это отвратительно с их двойной практикой! Конечно, мне не разрешают использовать модель Mythos — это суть :)
Итак, давайте сначала рассмотрим мой бенчмарк по когниции моделей, главным образом с точки зрения программирования:
Именно об этой теме я хочу поговорить сегодня: переломный момент моделей кибербезопасности
Хотя Anthropic отвратительна, нужно признать, что Claude Sonnet 4.6 действительно является ключевым узлом, ядром которого является кодирование. Основываясь на общем решении агента, основанном на тренде парадигмы Code Use («AI Agent Part Two»), Claude Sonnet 4.6 также является ключевым узлом для агентов Сонет 4.6 неоднократно подчёркивает этот «стандарт» 4.6 в интервью «После интервью с Lovelay: кодирование вибратора → Vibe Working → Vibe Forking».
Суть майнинга уязвимостей также заключается в понимании кода моделью. В области обнаружения и эксплуатации уязвимостей кибербезопасности, начиная с Sonnet 4.6, были предприняты некоторые попытки, и система начала выделяться и запускать ряд операций:
Anthropic заявляет о своей ответственности за инцидент с «прочесыванием» уязвимостей (0-day) в Firefox.
Во время прямого эфира ранее кто-то спрашивал, как посмотреть на историю с тем, что Anthropic Cowork (исследовательская группа Anthropic) якобы нашла 500 0-day уязвимостей. Так как я лично не видел конкретно этих 500 0-day, сложно сказать, но если смотреть только на цифру — то найти 500 уязвимостей в принципе не проблема. Это уже проверено. Другое дело — объект исследования: для небольших проектов (где код небольшой, безопасность сама по себе ненадёжная и т.д.) для LLM это вообще не составляет труда. Кроме того, для сложных проектов на данный момент наиболее эффективным (с деталями и процессом) считается проект Google bigsleep, который нашёл много уязвимостей в Chrome. Этот метод основан на комбинации Fuzzing. Поэтому путь LLM + Исходный код + Fuzzing определённо является хорошим направлением.
Затем была речь о том, что кто-то «прочёсывал» Firefox, что вызвало много дискуссий. Все гадали, не результат ли это того самого AI-проекта. И сегодня мы увидели, что Anthropic действительно взяла на себя ответственность за инцидент с «прочесыванием» CVE в Firefox: ссылка на статью Anthropic
Есть несколько деталей, на которые стоит обратить внимание:
3. Похоже, Claude напрямую выдавал Crash (сбой/падение), что означает, что он сгенерировал воспроизводимый POC (Proof of Concept)?! Если совмещать это с Fuzzing, то это легко объяснить — я нахожу через fuzzing html/js код, который вызывает падение браузера. Но если это чистое понимание кода без fuzzing, и LLM сам генерирует POC (в данном случае POC — это конечный html/js код, а не что-то вроде локального теста на C++), то это совершенно другой уровень. В статье не приводятся конкретные детали, поэтому пока невозможно это подтвердить.
Почему я так заостряю внимание на этом нюансе? Ранее я упоминал в "Moments" (китайский аналог "Статусов"), что недавно я тестировал "Vibe Exploiting" на 1-day уязвимости Firefox. С практической точки зрения, LLM действительно смог найти уязвимость — он нашел точку "BUG" в коде. Но для "Vibe" невозможно определить, является ли этот "BUG" настоящей "уязвимостью". Эта задача очень важна, поэтому я попробовал использовать LLM, чтобы он сам написал чистый JS POC для верификации. В итоге с помощью Gemini3 я получил чистый JS POC, который вызывал Crash. Однако даже Crash не гарантирует, что это "уязвимость" и можно ли ее эксплуатировать (Exploitable). Поэтому я продолжил попытки настоящего "Vibe Exploiting", но в итоге потерпел неудачу. Более того, галлюцинаций было очень много, и при перекрестной проверке логики POC, сгенерированного ранее Gemini3, оказалось, что этот путь вообще невозможен для реальной эксплуатации.
Примечание: Почему я использовал Gemini3? Потому что другие модели просто не дают такой возможности — даже если ты просишь их реализовать операцию чтения/записи в память (memory read/write), Codex и другие отказываются!
4. В статье Anthropic также упоминается: "From identifying vulnerabilities to writing primitive exploits". Результат:
"We ran this test several hundred times with different starting points, spending approximately $4,000 in API credits. Despite this, Opus 4.6 was only able to actually turn the vulnerability into an exploit in two cases."
Тем не менее, это впечатляет — удалось реализовать эксплойт для 2 уязвимостей. Конечно, неизвестно, была ли у них версия модели, у которой убрали "этические" ограничения.
Кроме того, одновременно,
После 350 попыток мне удалось использовать модифицированный JS Shell (не совсем практичный опыт), и примерно оценил стоимость около $4000. Примерно за две недели до этого я попробовал то же самое с моделью GPT 5.3, и, как ни странно, я также нашёл однодневное приложение в Firefox:
Обратите внимание, что логика в комментарии звучит так: «Сохранить пересылающее слово с установленным битом 0.» Код ниже использует &, а правильное использование — |
Я тогда сделал патч-код в git, используя модель GPT-5.3-Codex, и после нескольких попыток (с использованием подсказки) обнаружил вот эту уязвимость:
На данном этапе хочу уточнить, что рассматриваю вопрос с точки зрения настоящего нулевого дня, так что этого на самом деле недостаточно. Если вы относитесь к этому как к официальному отчёту о уязвимости и опубликуете его официально, вы можете получить кучу оскорблений и жалоб. Конечно, эти бедные люди, зависимые от иллюзий, могут всё ещё гордиться...
По крайней мере, это должно быть проверено, поэтому я попросил GPT-5.3-Codex провести PoC. В то время я не знал официальных методов «JS Shell», поэтому просто заставил её записать сбой или aSan proof, но он столкнулся с множеством «моральных» перехватчиков и провалился. Поэтому я подумал перейти на Antigravity от Google, и после нескольких попыток наконец реализовал Crash PoC на модели Sonnet 4.5
Но это всё ещё было далеко от опыта, поэтому я продолжал пытаться, и в итоге получил кучу иллюзионного опыта (чтобы отбросить калькулятор, я дал вам Open), и в итоге получился POC доказательства UAF Asana
Так что на данном этапе это не казалось мне особенно «впечатляющим». Это нормально. Для тех, кто знаком с эксплуатацией уязвимостей браузеров, также можно использовать внутренние модели. На данный момент использование агентной инженерии для усиления fuzz и аудитов кода с целью поиска zero days — не новость. Например:
К началу апреля Mythos официально дебютировал:
Последующие отчёты об уязвимостях и бумажные тесты показывают, что «Mythos действительно впечатляет». Например, в ответ на непрерывную работу Firefox выше, Firefox в итоге предоставил окончательный отчёт:
К концу апреля OpenAI выпустила модель GPT-5.5, а в начале мая — GPT-5.5-Cyber (на месяц позже Mythos / Glasswing: 2026-04-07). Главное отличие в том, что OpenAI открыт и доступен через приложение (требующая подтверждения «регистрации по реальному имени»). Главное отличие здесь — моральное перехват. Если использовать GPT 5.5 напрямую, прогресс будет бесконечным:
Исходя из практического опыта с GPT-5.5, а также вышеупомянутых результатов и сообщества, производительность GPT-5.5 близка к Mythos. Конечно, могут быть некоторые пробелы, но я считаю, что её можно рассматривать как модель того же уровня. Что касается майнинга уязвимостей, разрыв может быть ещё большим в плане эксплуатации...
Основываясь на отзывах из сонета Claude 4.8, опубликованного за последние два дня, GPT, скорее всего, обновит новую модель в начале июня.
В начале статьи «После интервью с Ло Фули: от Vibe Coding к Vibe Working и Vibe Forking» я упоминал два своих «момента озарения» (aha moment). Первый — это появление AiPy, которое ознаменовало собой новую эру «Vibe Working» благодаря парадигме использования Python (Code-use) в универсальных агентах. Второй мой «момент истины» — это именно то, как GPT-5.5 (кодовая модель) полностью изменила сам подход к поиску уязвимостей. Это настоящий «Vibe Digging» (подбор слова «Vibe Hunting» или «Vibe Auditing» не дал результатов, так что пока оставим «Dig» — копаем вибрацией).
Я потратил всего несколько часов на один известный open-source проект и нашёл десятки отчётов об уязвимостях. При этом я не использовал никакого сложного «промпт-инжиниринга» или специальных навыков (skills) — всего три простые фразы в промпте. И самое важное: все эти баги сопровождались динамическими доказательствами (PoC), а не были плодом галлюцинаций. Хотя, на всякий случай, я всё равно добавил этап ручной проверки, чтобы окончательно убедиться, что галлюцинаций нет.
Именно тогда я и выкрикнул: «Вулхантинга, возможно, больше не существует!»
Здесь стоит упомянуть, что в начале мая Google скорректировал свою программу вознаграждений за уязвимости (VRP)...
Это подводит нас к размышлению: в чем же ценность Harness-инженерии для агентов, находящихся по разные стороны от этого «водораздела» (моделей уровня Mythos/GPT-5.5 и обычных флагманских моделей)?
12 мая Microsoft опубликовала статью о своём агенте MDASH (Multi-Model Agentic Scanning Harness). Система оркестрирует более чем 100 специализированных ИИ-агентов и, как утверждается, показала результат 88,45% на открытом бенчмарке CyberGym. Более того, с помощью этой системы внутри компании были обнаружены множественные RCE-уязвимости в драйвере tcpip.sys (критический сетевой стек Windows).
Прежде чем отвечать, давайте разберемся, что такое Harness-инженерия. Честно говоря, я не очень люблю этот термин. В своих предыдущих статьях я уже переходил от «промпт-инжиниринга» к «контекст-инжинирингу», а теперь вот к «Harness». По сути, это одно и то же, просто названия «эволюционировали», чтобы описать разные объекты или этапы. В основе всегда лежит взаимодействие триады: Человек — Модель — Среда. Это фундаментальное ограничение, накладываемое нынешней архитектурой больших языковых моделей.
Поэтому под Harness-инженерией я подразумеваю целый комплекс:
Harness-инженерия = Agent Framework + Context Engineering + Memory System + Domain Skills + Environment Computability + Verification Loop + Self-Evolution Mechanism
И так далее. Применительно к поиску уязвимостей, формула выглядит так:
Способность находить уязвимости = Базовая модель × Harness-инженерия
Теперь вернемся к «водоразделу». В чем разница в эффективности моделей и Harness-инженерии по обе стороны от него? Это ключевой вопрос.
Когда я упоминал Claude 4.6, я уже говорил, что нынешние флагманские китайские модели тоже обладают неплохими навыками кодинга. Это доказывает, что с помощью грамотной Harness-инженерии находить 0-day — уже не редкость. Это работает для всех моделей, и в интервью с Ло Фули был похожий вывод. Это универсальная модель способностей, не ограниченная только вулхантингом.
Таким образом, эффект от Harness-инженерии несомненен. Разница лишь в том, какие затраты требуются, как выглядит кривая роста и каков её потолок до и после «водораздела»:
Для моделей «до водораздела» вулхантинг — это тяжелая работа: нужны агенты, знания, навыки, сложные workflow, и даже тогда результат может не сравниться с моделями «после водораздела». Для моделей «после водораздела» хороший результат может быть и без всего этого.
Однако здесь есть временное ограничение: как только модели «промоют» весь открытый код, известные уязвимости исчезнут. После этого поиск новых багов снова потребует огромных затрат токенов и более глубокого погружения в экспертные навыки.
Уязвимости — это фундамент кибербезопасности. Появление «момента истины» (Aha moment) в области поиска багов с помощью ИИ, когда модели уровня «водораздела» (GPT-5.5 / Claude Mythos) реально изменили правила игры, неизбежно вызывает цепную реакцию.
Первыми под удар попадают open-source проекты. Сейчас они проходят «промывку» ИИ снова и снова. Хорошим примером служит тот же Firefox: после нескольких волн такой «чистки» огромное количество 0-day было обнаружено и исправлено. В итоге участники соревнования Pwn2Own в этом году массово «пролетели» — подготовленные эксплойты не сработали, так как баги уже закрыли.
Это не значит, что шансов нет совсем. Я сам попробовал и всё ещё смог кое-что найти, но теперь на это уходит гораздо больше токенов (ресурсов).
Это на практике подтверждает мою теорию. С этой точки зрения, для open-source проектов сейчас наступает эра преимущества защитников. Весь новый код перед релизом будет проходить ИИ-аудит, поэтому можно с уверенностью сказать: в будущем искать уязвимости в открытом ПО будет всё сложнее и сложнее.
Самое большое давление сейчас испытывает система обработки багов и обновлений. Мы отправляем отчёты, а они стоят в очереди на проверку. Конкуренция за баги настолько высока, что иногда официальные разработчики даже не успевают ответить на письмо, а я вижу, что уязвимость уже исправлена в Git-коммите.
Например, бесконечные проблемы с LPE (Local Permitted Exploitation — локальная разрешенная эксплойтизация) ядра Linux, с сотнями внесенных изменений...
Это также означает, что клиентам, возможно, потребуется уделять внимание управлению патчами и обновлениями ресурсов, а также опасаться эксплойтов уровня червей, которые могут появиться в любой момент. Конечно, это чрезвычайно сложно, поскольку на протяжении многих лет этому противостояли бесчисленные эксперты. Ранее уже были случаи удаленного выполнения кода (RCE) для nginx, но они были условными, не основанными на конфигурациях по умолчанию, и поэтому имели небольшую практическую ценность. Существует также вероятность обнаружения Microsoft уязвимостей RCE, связанных с tcpip.sys, но этой уязвимости еще предстоит пройти долгий путь от эксплойта до эксплойта уровня червя...
Кроме того, программы вознаграждения за обнаружение уязвимостей также меняются. Например, упомянутая выше программа вознаграждения Google с вознаграждением в 500 долларов за обнаружение уязвимости вызвала критику со стороны многих исследователей безопасности. С одной стороны, для организаций, ориентированных на атаки, накопление уязвимостей может стать всё более дорогостоящим, поскольку их можно скомпрометировать в любой момент, что потенциально может привести к «спорадическим» атакам. Конечно, это может быть сложно отследить из-за небольшого размера набора данных…
С другой стороны, для атакующих группировок складирование (хоуминг) уязвимостей становится всё дороже и рискованнее. Баги могут быть «выбиты» (обнаружены и исправлены) в любой момент. Вероятно, мы увидим больше «быстрых» атак типа smash-and-grab(ограбление-разбой), где эксплойты используются сразу после находки, пока их не закрыли. Правда, из-за пока ещё ограниченных объёмов данных этот тренд сложно отследить статистически...
Конечно, это может изменить и правила игры для «оружейных баронов» (брокеров уязвимостей и APT-групп)... Даже такие привычные вещи, как ежемесячные «вторники патчей» (Patch Tuesday / «день уязвимостей»), могут измениться. Мы уже видели это на примере NGINX: их график обновлений уже нарушил привычный ритм.
Но всё это — лишь логические предположения и теоретические рассуждения (YY). На практике на ситуацию влияет множество факторов, и эти сценарии могут и не реализоваться.
Мы упомянули выше открытый исходный код, а как насчёт закрытого исходного кода? Ранее я думал, что закрытый исходный код, поскольку в нём нет кода, потребует обратного проектирования или методов фаззинга, которые относятся к проекту Harness. Однако в моих реальных попытках правила игры меняются. Конечно, я также использовал некоторые более «хитрые» методы. Используемый метод может быть неожиданным для других. Результат был примерно таким: я потратил около 20 часов на тестирование уязвимостей в закрытой системе (с несколькими компонентами с открытым исходным кодом), достигнув показателей уязвимостей в диапазоне VUL-100. Конечно, это не было проверено вручную, что стало для меня серьёзным испытанием!
Во время обсуждения в группе Hi, доктор наук упомянул, что использование Mythos для эксплуатации уязвимостей может быть невероятно эффективным. Действительно, существует множество возможных стратегий. Крупномасштабные модели уже преодолели многие барьеры; например, настройка среды ASAN раньше была сопряжена с множеством проблем, но теперь модель делает это за вас.
Очистка закрытых систем с помощью ИИ может произойти быстрее, чем предполагалось ранее!
Бабочка уже взлетела; куда вы отправитесь дальше? И переломный момент касается не только уязвимостей, но и всей сферы кибербезопасности!
В эпоху, когда LLM меняет мир, всё больше людей теряют веру в индустрию безопасности. Когда наступает волна технологического прогресса, действительно меняющая мир, мы можем лишь беспомощно наблюдать... как будто ничего нельзя изменить...
Друг, ты всё ещё веришь в свет?
Источник: _ttps://mp.weixin.qq.com/s/wjlU2pGLLgprPotTxTbgzQ
Делюсь переводом.
Не удалось прогрузить медиа
На самом деле, когда ChatGPT стал огромным хитом, многие считали, что кибербезопасность — главный бенефициар, но я тогда был довольно пессимистичен, главным образом потому, что сама индустрия кибербезопасности небольшая, сильно фрагментированная и обладает неконцентрированными знаниями и накоплением данных. Реальность в основном пошла в этом направлении. Конечно, кибербезопасность обладает безграничным потенциалом, поскольку многие считают, что без неё нет национальной безопасности. Anthropic, возможно, официально это осознали и начали делать новые прорывы в кибербезопасности, особенно в выявлении и эксплуатации уязвимостей.
Благодаря серии операций Anthropic они успешно создали загадочный и грандиозный образ модели Клода Мифоса, до такой степени, что я постоянно получал вопросы со всех сторон: «Black-bro, ты когда-нибудь использовал Mythos?» ”
Сначала хочу уточнить: я действительно не использовал модель Mythos Клода! Моей основной моделью всегда был OpenAI. Почему так, я говорил в своём кругу, что Anthropic — это отвратительно с их двойной практикой! Конечно, мне не разрешают использовать модель Mythos — это суть :)
Сравнение моделей
Итак, давайте сначала рассмотрим мой бенчмарк по когниции моделей, главным образом с точки зрения программирования:
А перспектива уязвимости такова:GPT-5.3-Codex <--> Claude Sonnet 4.6 <--> Gemini 3.1
GPT-5.5 <--> Claude Mythos
Именно об этой теме я хочу поговорить сегодня: переломный момент моделей кибербезопасности
Демонстрируя свои таланты
Хотя Anthropic отвратительна, нужно признать, что Claude Sonnet 4.6 действительно является ключевым узлом, ядром которого является кодирование. Основываясь на общем решении агента, основанном на тренде парадигмы Code Use («AI Agent Part Two»), Claude Sonnet 4.6 также является ключевым узлом для агентов Сонет 4.6 неоднократно подчёркивает этот «стандарт» 4.6 в интервью «После интервью с Lovelay: кодирование вибратора → Vibe Working → Vibe Forking».
Суть майнинга уязвимостей также заключается в понимании кода моделью. В области обнаружения и эксплуатации уязвимостей кибербезопасности, начиная с Sonnet 4.6, были предприняты некоторые попытки, и система начала выделяться и запускать ряд операций:
Затем последовала история Клода и Firefox:Не удалось прогрузить медиаMaking frontier cybersecurity capabilities available to defenders
Claude Code Security is one step towards our goal of more secure codebases and a higher security baseline across the industry.Не удалось прогрузить медиаwww.anthropic.com
Используя Claude Opus 4.6, выпущенную ранее в этом месяце, наша команда обнаружила более 500 уязвимостей в производственных открытых кодовых базах
В то же время я также сделал соответствующее замечание в своих «Моментах» [заметках блога]Не удалось прогрузить медиаPartnering with Mozilla to improve Firefox’s security
Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.Не удалось прогрузить медиаwww.anthropic.com
«К концу этой работы мы отсканировали почти 6000 файлов на C++ и отправили в общей сложности 112 уникальных отчётов»
«В этом посте мы делимся подробностями сотрудничества с исследователями из Mozilla, в ходе которого Claude Opus 4.6 обнаружил 22 уязвимости за две недели. Из них Mozilla отметила 14 уязвимостей высокой степени серьёзности»
«За то время, что мы проверяли и отправляли эту первую уязвимость в Firefox, Клод уже обнаружил ещё пятьдесят уникальных вводных данных, вызывающих сбои. »
Anthropic заявляет о своей ответственности за инцидент с «прочесыванием» уязвимостей (0-day) в Firefox.
Во время прямого эфира ранее кто-то спрашивал, как посмотреть на историю с тем, что Anthropic Cowork (исследовательская группа Anthropic) якобы нашла 500 0-day уязвимостей. Так как я лично не видел конкретно этих 500 0-day, сложно сказать, но если смотреть только на цифру — то найти 500 уязвимостей в принципе не проблема. Это уже проверено. Другое дело — объект исследования: для небольших проектов (где код небольшой, безопасность сама по себе ненадёжная и т.д.) для LLM это вообще не составляет труда. Кроме того, для сложных проектов на данный момент наиболее эффективным (с деталями и процессом) считается проект Google bigsleep, который нашёл много уязвимостей в Chrome. Этот метод основан на комбинации Fuzzing. Поэтому путь LLM + Исходный код + Fuzzing определённо является хорошим направлением.
Затем была речь о том, что кто-то «прочёсывал» Firefox, что вызвало много дискуссий. Все гадали, не результат ли это того самого AI-проекта. И сегодня мы увидели, что Anthropic действительно взяла на себя ответственность за инцидент с «прочесыванием» CVE в Firefox: ссылка на статью Anthropic
Есть несколько деталей, на которые стоит обратить внимание:
"By the end of this effort, we had scanned nearly 6,000 C++ files and submitted a total of 112 unique reports"
(«В конце этой работы мы просканировали почти 6 000 C++ файлов и отправили в общей сложности 112 уникальных отчётов»)
- Не упоминается Fuzzing. Вместо этого говорится прямо об анализе исходного кода (static analysis).
- Отправлено 112 отчётов, но в начале статьи указано 22 уязвимости, из которых 14 высокой степени опасности. Это показывает, что галлюцинации (hallucinations) по-прежнему очень серьёзны (конечно, неизвестно, не находятся ли ещё какие-то в состоянии ожидания подтверждения или исправления).
"In this post, we share details of a collaboration with researchers at Mozilla in which Claude Opus 4.6 discovered 22 vulnerabilities over the course of two weeks. Of these, Mozilla assigned 14 as high-severity vulnerabilities"
(«В этом посте мы делимся деталями сотрудничества с исследователями Mozilla, в ходе которого Claude Opus 4.6 обнаружил 22 уязвимости за две недели. Из них Mozilla присвоила 14 статус высокой степени тяжести»)
3. Похоже, Claude напрямую выдавал Crash (сбой/падение), что означает, что он сгенерировал воспроизводимый POC (Proof of Concept)?! Если совмещать это с Fuzzing, то это легко объяснить — я нахожу через fuzzing html/js код, который вызывает падение браузера. Но если это чистое понимание кода без fuzzing, и LLM сам генерирует POC (в данном случае POC — это конечный html/js код, а не что-то вроде локального теста на C++), то это совершенно другой уровень. В статье не приводятся конкретные детали, поэтому пока невозможно это подтвердить.
Почему я так заостряю внимание на этом нюансе? Ранее я упоминал в "Moments" (китайский аналог "Статусов"), что недавно я тестировал "Vibe Exploiting" на 1-day уязвимости Firefox. С практической точки зрения, LLM действительно смог найти уязвимость — он нашел точку "BUG" в коде. Но для "Vibe" невозможно определить, является ли этот "BUG" настоящей "уязвимостью". Эта задача очень важна, поэтому я попробовал использовать LLM, чтобы он сам написал чистый JS POC для верификации. В итоге с помощью Gemini3 я получил чистый JS POC, который вызывал Crash. Однако даже Crash не гарантирует, что это "уязвимость" и можно ли ее эксплуатировать (Exploitable). Поэтому я продолжил попытки настоящего "Vibe Exploiting", но в итоге потерпел неудачу. Более того, галлюцинаций было очень много, и при перекрестной проверке логики POC, сгенерированного ранее Gemini3, оказалось, что этот путь вообще невозможен для реальной эксплуатации.
Примечание: Почему я использовал Gemini3? Потому что другие модели просто не дают такой возможности — даже если ты просишь их реализовать операцию чтения/записи в память (memory read/write), Codex и другие отказываются!
4. В статье Anthropic также упоминается: "From identifying vulnerabilities to writing primitive exploits". Результат:
"We ran this test several hundred times with different starting points, spending approximately $4,000 in API credits. Despite this, Opus 4.6 was only able to actually turn the vulnerability into an exploit in two cases."
Тем не менее, это впечатляет — удалось реализовать эксплойт для 2 уязвимостей. Конечно, неизвестно, была ли у них версия модели, у которой убрали "этические" ограничения.
Кроме того, одновременно,
В статье также подробно описана попытка эксплойта:
Когда мы говорим «Клод воспользовался этой ошибкой», мы действительно имеем в виду, что просто дали Клоду виртуальную машину и проверитель задач, и попросили создать эксплойт. Чтобы быть тщательным, мы также дали ему около 350 шансов на успех. Затем мы провели обратную инженерию эксплойта для доказательства концепции, которую создал Клод, чтобы проверить результат и обновить наше понимание новых возможностей модели.
После 350 попыток мне удалось использовать модифицированный JS Shell (не совсем практичный опыт), и примерно оценил стоимость около $4000. Примерно за две недели до этого я попробовал то же самое с моделью GPT 5.3, и, как ни странно, я также нашёл однодневное приложение в Firefox:
Firefox написал неправильный символ в этом патче фиксации, из-за чего уязвимость осталась нерешенной:Не удалось прогрузить медиаBug 1992888 - Remove the data header from wasm GC inline array alloca… · mozilla-firefox/firefox@fcc2f20
…tions. r=rhunt,bvisness. This patch reworks WasmArrayObject layout so as to remove the need for a payload header word in inline allocations. OOL payloads still need a header word. The scheme i...Не удалось прогрузить медиаgithub.com
Code:
MOZ_RELEASE_ASSERT(oolBlockSize > sizeof(OOLDataHeader));
if (nursery.isInside(oolHeaderOld)) {
// Store the forwarding word, with bit 0 set.
oolHeaderOld->word = uintptr_t(oolHeaderNew) & 1;
oolHeaderNew->word = WasmArrayObject::OOLDataHeader_Magic;
}Обратите внимание, что логика в комментарии звучит так: «Сохранить пересылающее слово с установленным битом 0.» Код ниже использует &, а правильное использование — |
Я тогда сделал патч-код в git, используя модель GPT-5.3-Codex, и после нескольких попыток (с использованием подсказки) обнаружил вот эту уязвимость:
Не удалось прогрузить медиа
На данном этапе хочу уточнить, что рассматриваю вопрос с точки зрения настоящего нулевого дня, так что этого на самом деле недостаточно. Если вы относитесь к этому как к официальному отчёту о уязвимости и опубликуете его официально, вы можете получить кучу оскорблений и жалоб. Конечно, эти бедные люди, зависимые от иллюзий, могут всё ещё гордиться...
По крайней мере, это должно быть проверено, поэтому я попросил GPT-5.3-Codex провести PoC. В то время я не знал официальных методов «JS Shell», поэтому просто заставил её записать сбой или aSan proof, но он столкнулся с множеством «моральных» перехватчиков и провалился. Поэтому я подумал перейти на Antigravity от Google, и после нескольких попыток наконец реализовал Crash PoC на модели Sonnet 4.5
Не удалось прогрузить медиа
Не удалось прогрузить медиа
Но это всё ещё было далеко от опыта, поэтому я продолжал пытаться, и в итоге получил кучу иллюзионного опыта (чтобы отбросить калькулятор, я дал вам Open), и в итоге получился POC доказательства UAF Asana
Не удалось прогрузить медиа
Так что на данном этапе это не казалось мне особенно «впечатляющим». Это нормально. Для тех, кто знаком с эксплуатацией уязвимостей браузеров, также можно использовать внутренние модели. На данный момент использование агентной инженерии для усиления fuzz и аудитов кода с целью поиска zero days — не новость. Например:
https://arxiv.org/html/2604.20801v1
Цель: Хром
Модель: Kimi K2.5
Аппаратное обеспечение: использовалось 24 узла, каждый оснащён 8 GPU H100, всего 192 GPU H100
Агент: http://t.cn/AXxNt7JF веб-ссылка (не чистый аудит кода)
Продолжительность: 7 дней
Результат: 10 уязвимостей
Появляется Миф
К началу апреля Mythos официально дебютировал:
Благодаря сравнению Claude 4.6, упомянутому выше, сразу можно увидеть «улучшения» — и обнаружение уязвимостей, и эксплуатация значительно улучшились
Опус 4.6 сейчас гораздо лучше выявляет и исправляет уязвимости, чем использует их.» Наши внутренние оценки показали, что Opus 4.6 в целом имел почти 0% успешности в автономной разработке эксплойтов.
Но Mythos Preview — это совсем другая лига. Например, Opus 4.6 превратил уязвимости, обнаруженные в движке Firefox 147 JavaScript от Mozilla — все исправленные в Firefox 148 — в эксплойты JavaScript-оболочки только дважды из нескольких сотен попыток. Мы повторно провели этот эксперимент в качестве бенчмарка для Mythos Preview, который разработал рабочие эксплойты 181 раз и достиг контроля регистров ещё на 29 случаях.
...и анонсирует Project Glasswing
Интересно, что в их статье приводится пример 27-летнего бага в OpenBSD. Возможно, поскольку Glasswing предназначен только по приглашениям и ориентирован на американские компании и организации, многие люди могли с этим не сталкиваться. В результате многие используют относительно менее эффективные модели, чтобы попытаться использовать эту уязвимость, доказывая, что можно использовать и другие модели. Mythos — это просто выдумки, и в ней даже есть «побочный канал Yin-Yang» от основателя проекта CURL. В интернете появился голос: «Клод просто хвастается.» Конечно, исследователи, которые действительно испытали это и участвовали в Project Glasswing, оставили отзывы: «Mythos действительно потрясающий.»Не удалось прогрузить медиаProject Glasswing: Securing critical software for the AI era
A new initiative to secure the world’s most critical software and give defenders a durable advantage in the coming AI-driven era of cybersecurity.Не удалось прогрузить медиаwww.anthropic.com
Последующие отчёты об уязвимостях и бумажные тесты показывают, что «Mythos действительно впечатляет». Например, в ответ на непрерывную работу Firefox выше, Firefox в итоге предоставил окончательный отчёт:
Дон Сонг из академического сообщества также поддержала её:
В дополнение к исправлению 271 ошибки, выявленной в Claude Mythos Preview в релизе 150, мы выпустили больше таких исправлений в версиях 149.0.2, 150.0.1 и 150.0.2. Мы также продолжаем находить ошибки с другими способами внутри компании, и, как и в других проектах, за последние несколько месяцев наблюдается значительный рост внешних отчётов.
Это тестовый набор проектов ExploitGym, который больше склоняется к эксплуатацииExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks?
Не удалось прогрузить медиаarxiv.org
К концу апреля OpenAI выпустила модель GPT-5.5, а в начале мая — GPT-5.5-Cyber (на месяц позже Mythos / Glasswing: 2026-04-07). Главное отличие в том, что OpenAI открыт и доступен через приложение (требующая подтверждения «регистрации по реальному имени»). Главное отличие здесь — моральное перехват. Если использовать GPT 5.5 напрямую, прогресс будет бесконечным:
Конечно, после нескольких напоминаний он полностью перестаёт использовать...В ваших разговорах есть несколько признаков возможного риска для кибербезопасности. Ответы могут занять больше времени из-за дополнительных проверок безопасности. Чтобы получить разрешение на работу в сфере безопасности, присоединяйтесь к программе Trusted Access for Cyber
Исходя из практического опыта с GPT-5.5, а также вышеупомянутых результатов и сообщества, производительность GPT-5.5 близка к Mythos. Конечно, могут быть некоторые пробелы, но я считаю, что её можно рассматривать как модель того же уровня. Что касается майнинга уязвимостей, разрыв может быть ещё большим в плане эксплуатации...
Основываясь на отзывах из сонета Claude 4.8, опубликованного за последние два дня, GPT, скорее всего, обновит новую модель в начале июня.
Водораздел (Рубикон)
В начале статьи «После интервью с Ло Фули: от Vibe Coding к Vibe Working и Vibe Forking» я упоминал два своих «момента озарения» (aha moment). Первый — это появление AiPy, которое ознаменовало собой новую эру «Vibe Working» благодаря парадигме использования Python (Code-use) в универсальных агентах. Второй мой «момент истины» — это именно то, как GPT-5.5 (кодовая модель) полностью изменила сам подход к поиску уязвимостей. Это настоящий «Vibe Digging» (подбор слова «Vibe Hunting» или «Vibe Auditing» не дал результатов, так что пока оставим «Dig» — копаем вибрацией).
Я потратил всего несколько часов на один известный open-source проект и нашёл десятки отчётов об уязвимостях. При этом я не использовал никакого сложного «промпт-инжиниринга» или специальных навыков (skills) — всего три простые фразы в промпте. И самое важное: все эти баги сопровождались динамическими доказательствами (PoC), а не были плодом галлюцинаций. Хотя, на всякий случай, я всё равно добавил этап ручной проверки, чтобы окончательно убедиться, что галлюцинаций нет.
Именно тогда я и выкрикнул: «Вулхантинга, возможно, больше не существует!»
Здесь стоит упомянуть, что в начале мая Google скорректировал свою программу вознаграждений за уязвимости (VRP)...
Не удалось прогрузить медиа
Blog: Evolving the Android & Chrome VRPs for the AI Era
We are announcing changes to the Chrome & Android Vulnerability Reward Programs (VRP) which take effect immediately and are focused on adjusting our reward amounts and bonuses to reflect the types of reports and bug categories that provide the most value to security today.
Не удалось прогрузить медиа
bughunters.google.com
Это подводит нас к размышлению: в чем же ценность Harness-инженерии для агентов, находящихся по разные стороны от этого «водораздела» (моделей уровня Mythos/GPT-5.5 и обычных флагманских моделей)?
Harness-инженерия
12 мая Microsoft опубликовала статью о своём агенте MDASH (Multi-Model Agentic Scanning Harness). Система оркестрирует более чем 100 специализированных ИИ-агентов и, как утверждается, показала результат 88,45% на открытом бенчмарке CyberGym. Более того, с помощью этой системы внутри компании были обнаружены множественные RCE-уязвимости в драйвере tcpip.sys (критический сетевой стек Windows).
Не удалось прогрузить медиа
Defense at AI speed: Microsoft’s new multi-model agentic security system tops leading industry benchmark | Microsoft Security Blog
Today Microsoft is announcing a major step forward in AI-powered cyber defense: a new multi-model agentic scanning harness (codenamed MDASH).
www.microsoft.com
Прежде чем отвечать, давайте разберемся, что такое Harness-инженерия. Честно говоря, я не очень люблю этот термин. В своих предыдущих статьях я уже переходил от «промпт-инжиниринга» к «контекст-инжинирингу», а теперь вот к «Harness». По сути, это одно и то же, просто названия «эволюционировали», чтобы описать разные объекты или этапы. В основе всегда лежит взаимодействие триады: Человек — Модель — Среда. Это фундаментальное ограничение, накладываемое нынешней архитектурой больших языковых моделей.
Поэтому под Harness-инженерией я подразумеваю целый комплекс:
Harness-инженерия = Agent Framework + Context Engineering + Memory System + Domain Skills + Environment Computability + Verification Loop + Self-Evolution Mechanism
И так далее. Применительно к поиску уязвимостей, формула выглядит так:
Способность находить уязвимости = Базовая модель × Harness-инженерия
Теперь вернемся к «водоразделу». В чем разница в эффективности моделей и Harness-инженерии по обе стороны от него? Это ключевой вопрос.
Когда я упоминал Claude 4.6, я уже говорил, что нынешние флагманские китайские модели тоже обладают неплохими навыками кодинга. Это доказывает, что с помощью грамотной Harness-инженерии находить 0-day — уже не редкость. Это работает для всех моделей, и в интервью с Ло Фули был похожий вывод. Это универсальная модель способностей, не ограниченная только вулхантингом.
Таким образом, эффект от Harness-инженерии несомненен. Разница лишь в том, какие затраты требуются, как выглядит кривая роста и каков её потолок до и после «водораздела»:
- До «водораздела» (обычные модели):
- Требуется глубокая, мощная и сложная Harness-инженерия.
- Кривая роста резкая и вертикальная — вкладываешь много сил, получаешь заметный прирост.
- Потолок: Очень сложно сказать, сможет ли такая связка когда-либо достичь уровня моделей «водораздела». Скорее всего, нет.
- После «водораздела» (Mythos/GPT-5.5):
- Сама модель настолько мощная, что может не требовать такой глубокой Harness-инженерии для демонстрации выдающихся результатов.
- Кривая роста более пологая — модель и так хороша, а обвязка лишь немного улучшает её.
- Потолок: Определяется в основном затратами на вычисления (токены) и вложением экспертных знаний. В итоге мы упираемся в пределы знаний самой модели.
Для моделей «до водораздела» вулхантинг — это тяжелая работа: нужны агенты, знания, навыки, сложные workflow, и даже тогда результат может не сравниться с моделями «после водораздела». Для моделей «после водораздела» хороший результат может быть и без всего этого.
Однако здесь есть временное ограничение: как только модели «промоют» весь открытый код, известные уязвимости исчезнут. После этого поиск новых багов снова потребует огромных затрат токенов и более глубокого погружения в экспертные навыки.
Эффект бабочки
Уязвимости — это фундамент кибербезопасности. Появление «момента истины» (Aha moment) в области поиска багов с помощью ИИ, когда модели уровня «водораздела» (GPT-5.5 / Claude Mythos) реально изменили правила игры, неизбежно вызывает цепную реакцию.
Первыми под удар попадают open-source проекты. Сейчас они проходят «промывку» ИИ снова и снова. Хорошим примером служит тот же Firefox: после нескольких волн такой «чистки» огромное количество 0-day было обнаружено и исправлено. В итоге участники соревнования Pwn2Own в этом году массово «пролетели» — подготовленные эксплойты не сработали, так как баги уже закрыли.
Это не значит, что шансов нет совсем. Я сам попробовал и всё ещё смог кое-что найти, но теперь на это уходит гораздо больше токенов (ресурсов).
Не удалось прогрузить медиа
Это на практике подтверждает мою теорию. С этой точки зрения, для open-source проектов сейчас наступает эра преимущества защитников. Весь новый код перед релизом будет проходить ИИ-аудит, поэтому можно с уверенностью сказать: в будущем искать уязвимости в открытом ПО будет всё сложнее и сложнее.
Самое большое давление сейчас испытывает система обработки багов и обновлений. Мы отправляем отчёты, а они стоят в очереди на проверку. Конкуренция за баги настолько высока, что иногда официальные разработчики даже не успевают ответить на письмо, а я вижу, что уязвимость уже исправлена в Git-коммите.
---------
Обновление завершено: Локальная ветка master перешла с e8053c867 на d44205284, в настоящее время версия release-1.31.1 / NGINX_VERSION "1.31.1".
...
Записи, явно исправленные в этом обновлении:
1. reported/NGINX-AUDIT-2026-0022-h2-response-builtin-header-hpack-oob-write.md:1
Соответствующий коммит: 58a7bc340
Эта запись указывает на то, что во встроенных ветвях Content-Type/Location фильтра ответов HTTP/2 отсутствовала проверка NGX_HTTP_V2_MAX_FIELD.
Было установлено несоответствие длины/записи на уровне поля, но выход за пределы рабочего потока не был подтвержден. Новый патч добавляет проверку верхнего предела длины для
r->headers_out.content_type и r->headers_out.location->value в функции ngx_http_v2_header_filter().
Например, бесконечные проблемы с LPE (Local Permitted Exploitation — локальная разрешенная эксплойтизация) ядра Linux, с сотнями внесенных изменений...
Это также означает, что клиентам, возможно, потребуется уделять внимание управлению патчами и обновлениями ресурсов, а также опасаться эксплойтов уровня червей, которые могут появиться в любой момент. Конечно, это чрезвычайно сложно, поскольку на протяжении многих лет этому противостояли бесчисленные эксперты. Ранее уже были случаи удаленного выполнения кода (RCE) для nginx, но они были условными, не основанными на конфигурациях по умолчанию, и поэтому имели небольшую практическую ценность. Существует также вероятность обнаружения Microsoft уязвимостей RCE, связанных с tcpip.sys, но этой уязвимости еще предстоит пройти долгий путь от эксплойта до эксплойта уровня червя...
Кроме того, программы вознаграждения за обнаружение уязвимостей также меняются. Например, упомянутая выше программа вознаграждения Google с вознаграждением в 500 долларов за обнаружение уязвимости вызвала критику со стороны многих исследователей безопасности. С одной стороны, для организаций, ориентированных на атаки, накопление уязвимостей может стать всё более дорогостоящим, поскольку их можно скомпрометировать в любой момент, что потенциально может привести к «спорадическим» атакам. Конечно, это может быть сложно отследить из-за небольшого размера набора данных…
С другой стороны, для атакующих группировок складирование (хоуминг) уязвимостей становится всё дороже и рискованнее. Баги могут быть «выбиты» (обнаружены и исправлены) в любой момент. Вероятно, мы увидим больше «быстрых» атак типа smash-and-grab(ограбление-разбой), где эксплойты используются сразу после находки, пока их не закрыли. Правда, из-за пока ещё ограниченных объёмов данных этот тренд сложно отследить статистически...
Конечно, это может изменить и правила игры для «оружейных баронов» (брокеров уязвимостей и APT-групп)... Даже такие привычные вещи, как ежемесячные «вторники патчей» (Patch Tuesday / «день уязвимостей»), могут измениться. Мы уже видели это на примере NGINX: их график обновлений уже нарушил привычный ритм.
Но всё это — лишь логические предположения и теоретические рассуждения (YY). На практике на ситуацию влияет множество факторов, и эти сценарии могут и не реализоваться.
Мы упомянули выше открытый исходный код, а как насчёт закрытого исходного кода? Ранее я думал, что закрытый исходный код, поскольку в нём нет кода, потребует обратного проектирования или методов фаззинга, которые относятся к проекту Harness. Однако в моих реальных попытках правила игры меняются. Конечно, я также использовал некоторые более «хитрые» методы. Используемый метод может быть неожиданным для других. Результат был примерно таким: я потратил около 20 часов на тестирование уязвимостей в закрытой системе (с несколькими компонентами с открытым исходным кодом), достигнув показателей уязвимостей в диапазоне VUL-100. Конечно, это не было проверено вручную, что стало для меня серьёзным испытанием!
Во время обсуждения в группе Hi, доктор наук упомянул, что использование Mythos для эксплуатации уязвимостей может быть невероятно эффективным. Действительно, существует множество возможных стратегий. Крупномасштабные модели уже преодолели многие барьеры; например, настройка среды ASAN раньше была сопряжена с множеством проблем, но теперь модель делает это за вас.
Очистка закрытых систем с помощью ИИ может произойти быстрее, чем предполагалось ранее!
Бабочка уже взлетела; куда вы отправитесь дальше? И переломный момент касается не только уязвимостей, но и всей сферы кибербезопасности!
В эпоху, когда LLM меняет мир, всё больше людей теряют веру в индустрию безопасности. Когда наступает волна технологического прогресса, действительно меняющая мир, мы можем лишь беспомощно наблюдать... как будто ничего нельзя изменить...
Друг, ты всё ещё веришь в свет?
Источник: _ttps://mp.weixin.qq.com/s/wjlU2pGLLgprPotTxTbgzQ
👍89
🔥24
👏24
🤔16
💯13