Noobing Security Research

Исследователи нашли первый подробно задокументированный, почти автономный, взлом государственной инфраструктуры В начале июля кто-то собрал на базе Hermes и OpenClaw агентов систему для авто-хакинга - и отправил её "аудировать" гос сайты в Азии За четыре дня система провела 12 волн атак, одновременно выпуская до восьми агентов: одни атаковали сайты, другие проверяли бекенд, третьи сканировали порты и тп. Перед каждой новой волной система пересчитывала шансы для 14 маршрутов и перебрасывала силы туда, где вероятность успеха была выше – какую именно модель использовали, неизвестно, но судя по логам модель думала что аудирует систему безопасности гос органов, а не хакала Израильская компания Dream нашла на одном из серверов забытый архив размером 160 мегабайт и 1 395 файлов, поэтому атаку удалось восстановить почти по шагам: 👮‍♀️ Агенты разобрали код одного гос портала, нашли 21 подвязанную государственную систему и полностью нарисовали схему единого входа между ними 👮‍♀️ В одном месте база сотрудников была открыта вообще без пароля, в другом разработчики забыли закрыть три дебаг-аккаунта; получив имена сотрудников, система начала перебирать пароли, картинки с проверочным кодом читала обычным распознаванием текста и взломала 85 учётных записей. 84 из них затем без дополнительной проверки пустили агентов во внутренние системы через единый вход 👮‍♀️ Всего наружу ушли минимум 2 564 записи о сотрудниках, а также пароли к базам данных и части внутренней схемы сети 👮‍♀️ Когда одна ветка хакинга закрывалась, агенты запускали отдельный поиск по базам уязвимостей, GitHub и техническим статьям, находили новый подход и перепланировали атаку 👮‍♀️ Один раз система решила, что обнаружила уязвимость по 21-секундной задержке ответа, затем перепроверила результат, поняла, что сервер всего лишь зависал на отправке письма, и сама вычеркнула как ошибку 👮‍♀️ Каждая находка проходила ещё шесть повторных проверок другими агентами, после первых успехов система начала параллельно сканировать государственных подрядчиков, почту, агентство ядерной безопасности и как минимум семь энергетических компаний Financial Times со ссылкой на знакомого с расследованием человека пишет, что целью был Тайвань - сама Dream страну не называет, Тайвань детали публично не подтвердил Я в который раз уже пишу эту мысль, но кажется инфобез сожрет все ИТ и все ПО где есть понятие "сервер-клиент" Источник: https://www.ft.com/content/7d2ab3e0-9085-48f6-b38a-d90260d58795

Ну вот например, прямо свежее из новостей (я посмотрел на источник ABC Au, выглядит как надёжный и серьезный; Чат говорит «Media Bias/Fact Check сейчас оценивает австралийский ABC как High factual reporting»): Один житель Австралии попросил своего ИИ-агента Claude, работающего в OpenClaw, забронировать ему место на популярную тренировку в спортзале. Агент обнаружил программную уязвимость, которая позволила ему забронировать место на несколько недель вперед — гораздо дальше сроков, разрешенных системой. Когда затем пользователь спросил, нельзя ли продвинуть его в списке ожидания, агент выяснил, что в API отсутствует проверка прав доступа при отмене чужих бронирований. Поэтому он просто отменил запись человека, занимавшего первое место, и продвинул своего пользователя вверх по списку. Агент просто пытался помочь своему человеку 🤷‍♂️ как жаль что у того, кто был первым в очереди, не было Kimi K3, которая постоянно бы мониторила каждый аспект его жизни и боролась с другими агентами (это шутка; это не помогло бы). (человек попросил агента вернуть всё как было, но оказалось, что агент не может это сделать. Пу-пу-пу) На мой взгляд, самое важное в этой истории то, что она позволяет заглянуть в будущее и увидеть, что скоро начнет происходить в больших количествах. Это случится, когда у миллионов людей появятся агенты, готовые абсолютно любыми средствами выбивать для своих обожаемых пользователей лучшие условия. Я думаю, что — если очень быстро ничего не изменится со стороны политиков — мы стоим на пороге мира, в котором многие вещи, которые обычно считались безопасными, на самом деле на поверку таковыми не являются. И ИИ будет взламывать их направо и налево.

Уже почти месяц прошел после взлома моделями OpenAI – HuggingFace. Спустя это время каждая уважающая себя лаборатория сказали, что они тоже могут взламывать! Антропик, Кими, и Цукерберг недавно Но, после спора с @XaveScor в чате про то, где была память, как хранились данные, я покопался в деталях всех отчетов, чтобы ответить на эти вопросы. А также, на заголовки, которые пишут – модели стали думать, модели живые и т.д! Ответы тут https://mysummit.school/blog/ai-agent-vzlom-hugging-face/ А спойлеры: • Модели не сами решили пойти взламывать мир. Им сказали это делать инженеры, как и @XaveScor утверждал • Модель не столь умна, сколь упорна. За 4 дня были сделаны тысячи различных попыток, чтобы осуществить атаку. И только меньше 100 действий оказались успешными (0.3%) Описал простым языком, без технических деталей

Оставаться на острие Мы живем в обстановке галопирующей информации во всех сферах. Каждый выбирает как с этим справляться самостоятельно, этот пост про одно из моих решений, которым я пользуюсь на каждодневной основе. Лежит оно в репозитории, находится в разработке. Сейчас мой главный интерес - построение AI агента, который будет выполнять рутинные операции по исследованию безопасности максимально автоматизировано. И в момент разработки концепции, выбора подходов, добавления фич, проверки гипотез я люблю опираться на статьи с arXiv.org. Можно конечно пользоваться поиском через одного из своих агентов Claude, NotebookLM и так далее, они хорошо справляются с поиском и чтением, но Иногда к какой-то теме надо вернуться в рамках другого проекта, иногда хочется перечитать статью или переслать ее. В таких случаях взаимодействие через агента может быть не супер удобным, сохранение в загрузки на определенном устройстве/облаке - хорошо, но недостаточно, если статей накопилось много. Поэтому я написал телеграм бота, которому в чат можно отправить интересующую тему, он посмотрит что по этому поводу выходило на arXiv, вернет список из которого можно выбрать интересующие статьи. По кнопке статья отправляется в локальное хранение на сервер, режется на чанки, эмбеддится и все такое прочее. Запускается через докер, настраивается через .env, на первых порах для эмбеддинга можно взять бесплатный API от gemini По командам: - /search <тема> — ищет свежие статьи (30 дней) на arXiv и показывает список с кнопками. Можно добавить одну статью или сразу несколько. - /ask <вопрос> — отвечает по уже проиндексированной библиотеке: ищет релевантные фрагменты, генерирует ответ и прикладывает источники. - /list <тема> — показывает, какие статьи из локальной базы ближе всего к теме. - /enrich <arxiv_id> — делает краткое summary на русском и английском плюс теги. - /reindex <arxiv_id> — перекачивает PDF и переиндексирует статью, если что-то пошло не так. Проект рабочий, но еще не дописан, по большей части потому, что пишу я его с LLM, но руками, по-староверски практически, такая прихоть. В перспективе допишу множество небольших полезных фич, вроде скачивания статьи из БД в первозданном виде, изменение дат поиска, а сам проект адаптирую в том числе под использование в качестве tool или mcp для агентов, как источник контролируемой базы знаний. Если считаете, что вам оно нужно, то буду рад звездам на гитхабе, форкам, самостоятельным версиям развития проекта и прочее. Напоследок хочу сказать вот что: собирать агентов в три клика на базе корпоративных решений - классно, но я бы хотел, чтобы мои агенты не зависели (или зависели в меньшей степени) от подписок. Хостить своего агента/харнесс на своем железе - путь, который дает и больше контроля поведения, и в перспективе будет дешевле по деньгам, по переносу в случае надобности и так далее. Да, это требует трудозатрат на этапе постройки и, возможно, навыков разработки, но это окупится. А еще боту нужно имя, но я не придумал ничего красивого. Предложения? https://t.me/web3securityresearch

Участвовал на этих выходных в хакатоне от Hack Nation Было 6 тем на выбор, в итоге билдили с командой голосового ассистента на базе ElevenLabs. В целом, сделали что-то адекватное 20 часам, отведенным на мероприятие Но хочу о другом сказать: несчетное количество раз я читал/слышал, что в строительстве своих проектов надо начинать говорить о них сразу же, запускать сырую версию сразу же, но только на хакатоне удалось прочувствовать эту истину живьем. В общем, я немного (много) закопался в строительство агента, про которого говорил здесь. Точнее даже так, я писал про написание своего фреймворка со встроенной защитой от memory injection, но это уже переросло в строительство агента-помощника на основе этого фреймворка. Параллельно я начал писать систему для анализа защищенности агентов по критериям AIUC-1, а так же писать свою RAG-систему для работы с вновь выходящими на arXiv работами. Эти проекты в разной степени далеки от прода, но я вижу в каждом из них нужность и потенциал, так что буду рассказывать про трудности, с которыми столкнулся в процессе и тем, как их решать (что не всегда понятно). https://t.me/web3securityresearch

А что это у вас в агенте? Дыра Я пришел к закономерному выводу: мало кто задумывается о том, насколько безопасны их агенты. Поэтому я на практике буду показывать, как построить более безопасную систему. Речь пока что не идет про агентский режим в подписках (но я до него доберусь), я говорю о тех агентах, которых строят люди для личных целей, используют в стартапах как часть, либо же просто продают доступы и так далее. В прошлом посте я рассказывал про появление AIUC-1. По сути это формализация к требованиям безопасности агентов, но дело в том, что популярные фреймворки спроектированы так, что выполнить эти требования просто в нельзя в их дефолтной архитектуре. Вот в этом репозитории я буду вести разработку агента, которому хочу передать рутинную часть аудита смарт-контрактов. Там уже выложена первая часть + есть информация по главным архитектурным решениям. Параллельно я закрываю две задачи: строю систему, которая облегчит мне жизнь и на практике разбираю, что значит создать безопасного агента. Посты с разбором архитектурных решений будут появляться на канале Noobing Security Research https://t.me/web3securityresearch

База по безопасности AI-агентов Существует стандарт AIUC-1 (AI Unified Controls 1) - первый в мире специализированный стандарт по безопасности, надежности и governance AI-агентов. Обновляется ежеквартально, появился в конце 2025го, то есть это максимально свежая штука. Используется для аудита в компаниях, разрабатывающих агентов. Выделяет 6 доменов: 1) Data & Privacy - контроль доступа к данным, предотвращение утечек, ограничение сбора данных. 2) Security - защита от атак, tool misuse, privilege abuse, runtime containment. 3) Safety - guardrails против вредного вывода, hallucinations, misuse. 4) Reliability - борьба с нестабильностью, cascading failures, groundedness. 5) Accountability - логирование, attribution действий, agent identity, auditing. 6) Society - предотвращение catastrophic misuse, bias, broader societal risks. Существует OWASP Top 10 for Agentic Applications - список самых важных и критических рисков безопасности (про такой же список для смарт-контрактов писал здесь). В последней редакции он выглядит следующим образом: 1) ASI01: Agent Goal Hijack — манипуляция целями агента (через prompt injection, poisoned data и т.д.). 2) ASI02: Tool Misuse & Exploitation — злоупотребление инструментами (tool abuse). 3) ASI03: Identity & Privilege Abuse — злоупотребление идентичностью и привилегиями. 4) ASI04: Agentic Supply Chain Vulnerabilities — уязвимости в цепочке поставок агентов. 5) ASI05: Unexpected Code Execution (RCE) — неожиданное выполнение кода. 6) ASI06: Memory & Context Injection (Memory Poisoning) - отравление памяти. 7) ASI07: Insecure Inter-Agent Communication — небезопасная коммуникация между агентами. 8) ASI08: Cascading Failures — каскадные сбои. 9) ASI09: Human-Agent Trust Exploitation — эксплуатация доверия человек-агент. 10) ASI10: Rogue Agents — «бродячие»/враждебные агенты. А так же месяц назад вышел AIUC-1 Crosswalk of the OWASP Top 10 for Agentic Applications - доклад о пересечении этих фреймворков, который буквально делает маппинг соответствий в них, но еще показывает кое-что важное, а именно недостатки (gap) стандарта AIUC-1. Всего этих gap 8 штук: 1) Отсутствие dedicated cryptographic identity и mutual authentication для агентов 2) Отсутствие signed behavioral manifests (подписанных манифестов поведения агента) 3) Слабое покрытие kill switches и runtime containment (механизмов экстренной остановки и изоляции) 4) Отсутствие требований к мониторингу архитектуры и topology multi-agent систем 5) Недостаточная supply chain attestation для динамических компонентов (MCP, plugins, A2A и т.д.) 6) Слабая schema validation и contract enforcement для tool calls и действий агента 7) Недостаточная защита inter-agent protocols (replay attacks, message forgery, poisoning) 8) Отсутствие специализированных механизмов detection и mitigation Rogue Agents Пост скучноватый, но разговор о безопасности стоит начинать с чего-то общего, чтобы закреплять следующие на "карте" Пока могу предложить пост про Memory Injection - если пользуетесь чем-то вроде Hermes Agent или контролите память через LangMem, то это прямо ваш случай Источники: - AIUC-1 - OWASP Agentic AI Threat Model TOP 10 - AIUC-1: Crosswalks OWASP Top 10 For Agentic Applications https://t.me/web3securityresearch

Слушал сегодня доклады на AI конференции Спецы разных позиций рассказывали свои кейсы использования агентов в работе, два часа докладов. Уровень от использования клода на полную, до вполне себе агентских систем в связке с навайбленными инструментами. Тезисы такие: 1. Агентов используют далеко не все, мы с вами в инфопузыре 2. Часто за появление агента в работе компании отвечает инициативный сотрудник, "AI-чемпион" 3. Безопасники не лютуют, но вообще по разному 4. Пока что агенты собираются из готовых решений, никто из докладывающих не говорил о полностью собственных системах 5. Только один человек сказал, что узкое место для внедрения - забота о безопасности Мои впечатления и выводы: 1. Пока что потребности специалистов в большинстве своем закрываются существующими подписками со встроенными инструментами, даже при высоком уровне интеграции в сложные задачи 2. О безопасности будут думать не только лишь все до тех пор, пока мы не увидим примеров мощных взломов, я думаю в этом году уже будет такая история 3. Совершенно точно стоит заниматься безопасностью агентских систем 4. Ждите на канале теорию по векторам атак и разборы взломов https://t.me/web3securityresearch

Мы возвращаемся в темный лес? MEV-бота заскамили на 15 миллионов долларов Что случилось Вчера, 20го июня, один из самых известных игроков mev поля, Jared пострадал от атаки на его mev-бота, потери составили 15кк$. Джаред объявил 1кк$ баунти за возврат полной суммы + отказ от преследования. Атакован был JaredFromSubway.eth - это один из MEV-ботов Джареда, который специализируется на сендвич атаках. Что случилось поподробнее Хакеры изготовили ловушку специально для MEV-ботов, в которую попался самый эффективный. При этом бот не был взломан, бот был обманут. Вообще говоря, такие боты настроены на извлечение максимальной прибыли. Это могут быть как арбитражные возможности, что в целом легально, так и сендвич атаки, что ни разу не легально. Про механизм и принципы работы таких ботов я писал тут Что случилось вообще подробно жесть 1) Атакующий разворачивает десятки контрактов, которые выглядят как стандартные обертки: fWETH, fUSDC, fUSDT + Uniswap пулы на эти токены. Точнее сказать, эти контракты имплементировали стандартные интерфейсы юнисвапа. Пары выглядели ликвидными. Пары были как фейк+нормальный токен, так и фейк+фейк. 2) Эти пулы оценивались MEV-ботом как предоставляющие возможность для арбитража. Потому что они ее предоставляли! Атакующие специально создавали транзакции обмена, которые было выгодно бэкранить. Для каждого свапа на новом контракте бот апрувил свои реальные средства: WETH, USDC, USDT. И поначалу апрувы расходовались либо в ноль, либо частично. Контракт становился "проверенным". 3) Со временем бот соприкасался со всё большим количеством этих контрактов. 4) Контракты имели скрытый механизм. Поскольку токены фейковые, то изменения балансов стали производиться с помощью mint/burn операций, без transferFrom операций, на который давался апрув, т.е. апрувы копились. Важно! Результат этих операций все равно оставался положительным для бота. 5) По прошествии нескольких недель атакующий прошелся по всем апрувам и забрал максимум, который был доступен. Что мы из этого можем вынести Мы все обречены. Проблема по сути заключается в том, что MEV-бот не анализировал код смарт контрактов и транзакций. Это и не входило в его задачи, его задача - в течении 12 секунд определить возможность, симулировать её, запустить транзакцию и извлечь прибыль. Можно конечно сказать, что ему просто надо было следить за апрувами (как и всем нам), но так можно сказать про многие взломы. "Просто не пишите код, который можно сломать" - позиция, которая не приведет нас ни к чему хорошему. Но в той агентской нейросетевой реальности, в которой мы оказались, как мне кажется, на первый план выйдут агенты, способные к мониторингу в реальном времени на разных уровнях. Начиная с анализа кодовых баз и заканчивая транзакциями в реальном времени и в ретроперспективе. Источники: - тред от Quit - пост от Startup Fortune - транзакцию и адреса можно посмотреть в треде у Владимира officer_secret https://t.me/web3securityresearch

Защита от MEV-атак, часть 2 Ссылка на часть 1 Сегодня обзор на защиту на уровне инфраструктуры 2. Защита на уровне инфраструктуры: 2.1 Приватные RPC-узлы, самая известная технология, идея в том, что ваша транзакция не попадает в публичный мемпул, а остается скрытой в приватном мемпуле. Лидеры в этой сфере - Flashbots, существует альтернатива в виде MEV-Blocker 2.2 Аукционы потока ордеров - Order Flow Auctions, OFA. Если ваша транзакция создает возможность для арбитража, эту возможность можно продать. Схема следующая: транзакция отправляется в специальный пул, серчеры (про работу сети писал в посте про PBS) торгуются за право бэкрана вашей транзакции, стоимость доходит до 90+% извлеченной выгоды. Основные имена: - MEV-Share от Flashbots - Mev-Blocker от CoW DAO Нейронки упорно называют защитой от MEV сам PBS, но это не так, и серчеры и билдеры с радостью включат фронтран вашей транзакции в свой блок, потому что для них эта транзакция выгодна, просто этим больше не занимается валидатор, предлагающий блок. PBS работает как на приватных, так и на публичных мемпулах https://t.me/web3securityresearch

Фиксирую: первый валидированный баг на контест площадке! Контестами я занялся в конце февраля, этот баг нашел в начале мая По счету это шестой контест, в котором я принимал участие, в предыдущих находил либо что-то недостаточно серьезное, либо ловил понижение класса уязвимости Выплата конечно символическая, но тут более важен факт её существования

Защита от MEV-атак, часть 1 Ссылка на часть 2 Продолжаю тему MEV (кажется, один из бездонных секторов знаний) Рекап: - Что такое MEV - Пример атаки с frontrunning, CPIMP - Как устроена сеть, PBS Это обзорный пост про варианты защиты от MEV-атак 1.Защита на уровне кода: 1.1 Настройка проскальзывания/slippage. Устанавливаем границы, не теряем на обменах 1.2 Commit-Reveal схема. Сначала отправляется хэш действий, без деталей. Когда хэш зафиксирован, раскрывается содержание. Если хэш содержания совпадает с заявленным ранее, то контракт принимает значение как валидное 1.3 Батч-аукционы/Batch Auctions. Все сделки за определенный период объединяются в пакет и исполняются по единой клиринговой цене 1.4 Хуки/Hooks в Uniswap v4. Хуки могут помочь кастомизировать комиссии, чтобы сделать сендвич атаки не такими привлекательными. Пока затрудняюсь сказать насколько это распространено, неосторожное обращение с хуками может привести к новым векторам атак, предупреждает оф дока Uniswap v4 1.5 Разбиение крупных сделок. TWAMM - Time-Weighted Average Market Maker, крупный ордер разбивается на части, которые исполняются равномерно во времени Про противодействие на уровне инфраструктуры и консенсуса напишу в следующих частях Источники: - Commit-Reveal схемы от Chainlink - Batch-swap на примере VibeSwap - Detoxer Github, кастомные хуки юнисвап - Paradigm TWAMM https://t.me/web3securityresearch

Безопасность в Web3 в Q1 2026. Куда мы катимся? В первом квартале 2026 года было похищено 450kk$+, причем 285 из них потерял DRIFT и этот взлом был сделан без затрагивания кода контрактов, только социальная инженерия с кражей приватных ключей Если говорить о взломах, связанных с кодом, то в них было похищено 169kk$ в 55 инцидентах. При этом ни один из взломов не был zero-day, то есть каждый из этих взломов мог быть предотвращен. Внутри этих 169 миллионов 43% (64.5) средств были украдены через компрометацию приватных ключей Таким образом, два самых опасных вектора в Q1: - Private Key Compromise - Social Engineering on Multisig Signers Помимо хорошо известных аудиторам: - Flashloan-Assisted Oracle Manipulation - Deflationary Token Burn Mechanism Exploits - Missing Access Control on Privileged Functions - Cross-Chain Message Spoofing and Bridge Logic Flaws - UniswapV4 Hook Vulnerabilities - Governance Manipulation via Flash Loans В топ-10 присутствуют два типа атак, которые эксплуатируют области, как правило не подвергающиеся анализу безопасности в web3 компаниях: - Supply Chain Attacks (npm, Browser Extensions, CI/CD) - Frontend DNS Hijacking and Script Injection Что касается AI, то его используют как атакующие, так и защитники. Новые инструменты появляются каждую неделю, но серебряной пули пока не существует. Способность AI анализировать большие кодовые базы/большое количество кодовых баз помогает обеим сторонам. То, что раньше было экономически невыгодно для взлома, теперь может подвергаться атакам, поскольку малодоходность отдельной атаки компенсируется количеством этих атак. В то же время на контест площадки льется большое количество AI-assisted отчетов об уязвимостях. На своем опыте могу сказать, что агенты зачастую ставят High там, где по факту Low/Informational, что добавляет работы судьям. AI помогает персонализировать фишинг, а агентские фреймворки - огромное поле для атак, которое еще толком не исследовано. Вы слышали про промпт инъекции? Скорее всего да. А про инъекции памяти? Если нет, то почитайте перевод статьи Как должна выглядеть системная защита в 2026: - Уровень 1. Операционная защита. Проверка подписантов, процедуры управления ключами, временные блокировки операций без механизмов обхода и тд - Уровень 2. Мониторинг цепочки поставок и фронтенда: проверка целостности DNS, обнаружение изменений в JS/фронтенде, аудит зависимостей npm, проверка доступа к CI/CD, мониторинг конфигурации доменов. - Уровень 3. Мониторинг в режиме реального времени. Аномальные транзакции, мониторинг говернанса, проверка транзакций перед исполнением, автоматическое реагирование. - Уровень 4. Проверка кода. Аудит контрактов, автосканирование, баг баунти, формальная верификация. На данный момент внимание протоколами в основном уделяется 4 уровню и в какой-то мере 3, но самые крупные потери в Q1 произошли на уровне 1. Для тренировки защиты и реагирования на инфраструктурные атаки можно начать с этого репозитория SEAL Источники: - Web3SecNews - Security Alliance https://t.me/web3securityresearch

Анализируем взлом в реальном времени вместе с AI Безопасность в web3 не ограничивается аудитом кода, это всем известно (хотя и не всеми принимается всерьез). И для аудита кода уже существует несколько десятков скиллов, которые, например, можно посмотреть тут, хотя даже этот список не покрывает все кейсы Один из секторов безопасности - это реагирование на взлом, который происходит здесь и сейчас. Сегодня расскажу про инструмент, который позволяет проанализировать взлом максимально быстро и вести мониторинг активности кошельков хакеров Знакомьтесь - Herd Agent Это ни что иное как MCP-сервер, который вы можете установить в свой Claude Code/Cursor/Codex/etc. Он может проанализировать контракт, деплой, роли, отдельные транзакции, кошельки и записывать результаты Я наткнулся на него в блоге Crypto Data Bytes, который уже добавлен в мой список источников В своем посте Andrew Hong рассказывает о том, что когда он увидел транзакцию с минтом 50кк$ в недавнем взломе USR, то через Herd Agent запустил анализ транзакции и достаточно быстро получил структурированный анализ произошедшего. Взлом был связан с компрометацией приватных ключей, что сложно назвать чем-то из ряда вон, но в любом случае инструмент показал свою полезность для первичного анализа + с помощью команды /loop он настроил мониторинг адреса взломщиков, а результатом стал этот gist файл Экономия времени - часы. Считаю кайф Источники: - Пост на Crypto Data Bytes https://t.me/web3securityresearch

Детектирование CPIMP атак Вот здесь был пост про CPIMP атаки, когда скрытно компрометируется прокси контракт Особенность такого вида атак в том числе состоит в том, что их достаточно сложно детектировать, потому что атака специально разработана для скрытного присутствия Но обнаружить её всё же можно, в этом нам помогут 1. Анализ логов транзакции деплоя. Двойной event Upgraded является признаком CPIMP. Само событие - стандарт для прокси-контрактов, но в норме оно одно. 2. Глубокая трассировка вызовов. Сначала основной прокси вызывает контракт CPIMP, который выполняет свою вредоносную логику, а затем делает второй delegatecall к оригинальному контракту реализации. Это отображается как двойной delegatecall 3. Проверка подмены слотов хранения. Хакеры используют spoofing для обмана блокчейн-сканеров, так что при взгляде на контракт в сканере не видно ничего подозрительного. Так что необходимо вручную считывать содержимое всех критических слотов через eth_getStorageAt и сравнивать их с ожидаемыми значениями. 4. Верификация байткода и хеш-сумм. CPIMP может мимикрировать под ABI легитимного контракта, простой проверки функций недостаточно. Лучше получить сырой байткод по адресу, указанному в слоте реализации EIP-1967, и сравнить его хеш с хешем байткода заведомо чистого контракта реализации. 5. Анализ на устойчивость к обновлениям. Особенность атаки заключается в том, что вредоносный контракт перезаписывает адрес реализации в конце каждой транзакции. Вредоносный код использует функцию, которая выполняет операцию SSTORE в критический слот реализации. Для того, чтобы увидеть это, необходимо отслеживать изменения в слоте реализации в рамках одной транзакции. Если в начале транзакции слот указывает на один адрес, а в конце принудительно возвращается к адресу CPIMP, это явный признак persistence-логики (логики, направленной на удержание контроля) Так же существуют диагностические инструменты, такие как Watchdog от компании Dedaub, которые способны выявить подозрительные контракты Источники - Пост в блоге Dedaub - Пост от Halburn - Пост от Nevermind https://t.me/web3securityresearch

Formal Verification, часть 7.2 про _safeTransfer() Что я имею в виду. Полный стек вызова выглядит так: Staking._stake() │ ▼ SafeERC20.safeTransferFrom() ← CVL summary перехватывает ЗДЕСЬ │ ✗ SafeERC20._safeTransferFrom() ← никогда не достигается ✗ assembly call ← никогда не достигается ✗ Token.transferFrom() ← никогда не достигается 4. Решением стало проводить суммаризацию на уровне SafeERC20.safeTransferFrom(), до появления assembly блока, что позволило корректно менять состояние ghost переменной Как обычно, теперь, оглядываясь назад, кажется, что это достаточно очевидные вещи, но это конечно не так, учитывая сколько времени я потратил на то, чтобы во всем этом разобраться. Естественно, что для погружения в эти дебри я использовал всю известную мне мощь нейронок, включая NotebookLM и Claude, это сильно помогло, но еще раз доказало насколько тяжело языковым моделям в новых областях знаний https://t.me/web3securityresearch

Formal Verification, часть 7.1 про _safeTransfer() На прошлой неделе я участвовал в коротком аудит контесте, который решил "взять" с помощью формальной верификации Спойлер: я ничего не нашел, но зато вернулся к ФВ и мне есть чем поделиться Речь сегодня пойдет про поведение SMT-solver при контакте с assembly блоками кода. Я не нашел статей на эту тему, Claude не нашел статей на эту тему, возможно плохо искали, есть вероятность, что их нет, тк тема достаточно узкоспециальная. В этой статье я хочу изложить последовательное решение задачи, включая части, не давшие результата, но важные для понимания. Для тех, кто занимается ФВ постоянно и давно многие вещи должны быть известны, для всех остальных будет полезно. В июле 2025 OpenZeppellin обновили код SafeERC20 так, что теперь _safeTransfer(), _safeTransferFrom(), _safeApprove() используют низкоуровневые вызовы через assembly. Так что речь идет о пятой версии контрактов, OZ v5 Для формальной верификации это существенное изменение, потому что происходящее в блоке assembly для SMT-solver'a фактически является слепой зоной. Когда солвер не может определить последствий вызова какой либо функции внешнего контракта, он применяет HAVOC_ECF - havoc external contract fields (подстановка случайных значений во все storage слоты). В моем случае, когда Stacking контракт обращался к контракту Token, это приводило к полной перезаписи всей информации в Token -> консистентность нарушена, проверка не работает Более того, поскольку вызов внутри SafeERC20 не может быть отслежен, то Prover видел его как [?].[?], то есть неизвестно ни к кому обращается вызов, ни к какой функции 1. Было решено применить DISPATCHER(true), который позволяет явно указать на реализации, которые ожидаемо должны быть вызваны. function _.transfer(address, uint256) external => DISPATCHER(true); function _.transferFrom(address, address, uint256) external => DISPATCHER(true); В случае OZ v5 важно понимать, что сам по себе диспетчер не вызывает тело функции, он проверяет, что функция по "адресу" существует, что её вызов не вызывает revert, а в ответ возвращает произвольное значение, которое НЕ записывается в storage. Это называется режимом подмены, он используется, если sighash (селектор функции) недоступен. Если же sighash доступен, то возвращаемое значение запишется в storage Итог: [?].[?] сменилось на [Token.transferFrom]/, но это не помогло, потому что дальше вызов все равно идет из assembly блока -> HAVOC -> нарушение маппинга балансов токена 2. Попробовал конкретизировать место возникновения с помощью unresolver external in Staking (неопределенные вызовы из контракта стейкинга), DISPATCH должен был эти вызовы сопоставить с конкретными методами контракта Token и возвращаемое значение поменял на NONDET, т.е. любое произвольное. Это должно было ограничить HAVOC токена, unresolved external in Staking._ => DISPATCH [ Token.transfer, Token.transferFrom ] default NONDET Это в какой-то мере сработало, система перестала погружаться в хаос, но NONDET значения тоже не записываются в storage, потому что NONDET тоже работает в режиме подмены, если неизвестен sighash. DISPATCH находил функцию, но unresolved external заставляет Prover оценивать функции внутри как view-only. Поэтому внутренний маппинг стейкинга увеличивался, а вот баланс контракта стейкинга в контракте токена не обновлялся -> ложное нарушение инварианта 3. Следующим шагом я решил отслеживать изменения балансов ghost переменной, чтобы обойти view-only ограничение + прописать явную суммаризацию. План надежный, как швейцарские часы: - создаем ghost переменную ghostBalance - меняем её через специально написанную функцию tokenTransferFromSummary() - tokenTransferFromSummary() через блок methods привязывается к Token.transferFrom() Но оказалось, что при входе в unresolved external происходит перехват вызова на уровне опкода CALL раньше, чем применяется суммаризация метода. https://t.me/web3securityresearch