tgindex

Noobing Security Research

описание

Изучаю и пишу про безопасность смарт контрактов и агентов

← к каналу@web3securityresearch
270
подписчиков
Охват к подписчикам
93,0%
ERR
Реакции к просмотрам
1,99%
109 на 23 постов
Пересылки к просмотрам
0,78%
43
Постов в день
0,3
всего 23

Где отзываются чаще

доля реакций к просмотрам
  • 13:32без подписи12,82%
  • 5 июн.Фиксирую: первый валидированный баг на контест площадке! Контестами я занялся в конце февраля, этот баг нашел в начале мая По счету это шестой контест, в котором я принимал участие, в предыдущих находил либо что-то недостаточно серьезное, либо ловил понижение класса уязвимости Выплата конечно символическая, но тут более важен факт её существования5,57%
  • 23 июн.Слушал сегодня доклады на AI конференции Спецы разных позиций рассказывали свои кейсы использования агентов в работе, два часа докладов. Уровень от использования клода на полную, до вполне себе агентских систем в связке с навайбленными инструментами. Тезисы такие: 1. Агентов используют далеко не все, мы с вами в инфопузыре 2. Часто за появление агента в работе компании отвечает инициативный сотрудник, "AI-чемпион" 3. Безопасники не лютуют, но вообще по разному 4. Пока что агенты собираются из готовых решений, никто из докладывающих не говорил о полностью собственных системах 5. Только один человек сказал, что узкое место для внедрения - забота о безопасности Мои впечатления и выводы: 1. Пока что потребности специалистов в большинстве своем закрываются существующими подписками со встроенными инструментами, даже при высоком уровне интеграции в сложные задачи 2. О безопасности будут думать не только лишь все до тех пор, пока мы не увидим примеров мощных взломов, я думаю в этом году уже будет такая история 3. Совершенно точно стоит заниматься безопасностью агентских систем 4. Ждите на канале теорию по векторам атак и разборы взломов https://t.me/web3securityresearch4,43%
  • 10 авг.без подписи3,00%
  • 9 апр.Анализируем взлом в реальном времени вместе с 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/web3securityresearch2,35%
  • 28 июл.Оставаться на острие Мы живем в обстановке галопирующей информации во всех сферах. Каждый выбирает как с этим справляться самостоятельно, этот пост про одно из моих решений, которым я пользуюсь на каждодневной основе. Лежит оно в репозитории, находится в разработке. Сейчас мой главный интерес - построение 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/web3securityresearch2,29%
  • 16 маяЗащита от 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/web3securityresearch2,24%
  • 10 авг.Ну вот например, прямо свежее из новостей (я посмотрел на источник ABC Au, выглядит как надёжный и серьезный; Чат говорит «Media Bias/Fact Check сейчас оценивает австралийский ABC как High factual reporting»): Один житель Австралии попросил своего ИИ-агента Claude, работающего в OpenClaw, забронировать ему место на популярную тренировку в спортзале. Агент обнаружил программную уязвимость, которая позволила ему забронировать место на несколько недель вперед — гораздо дальше сроков, разрешенных системой. Когда затем пользователь спросил, нельзя ли продвинуть его в списке ожидания, агент выяснил, что в API отсутствует проверка прав доступа при отмене чужих бронирований. Поэтому он просто отменил запись человека, занимавшего первое место, и продвинул своего пользователя вверх по списку. Агент просто пытался помочь своему человеку 🤷‍♂️ как жаль что у того, кто был первым в очереди, не было Kimi K3, которая постоянно бы мониторила каждый аспект его жизни и боролась с другими агентами (это шутка; это не помогло бы). (человек попросил агента вернуть всё как было, но оказалось, что агент не может это сделать. Пу-пу-пу) На мой взгляд, самое важное в этой истории то, что она позволяет заглянуть в будущее и увидеть, что скоро начнет происходить в больших количествах. Это случится, когда у миллионов людей появятся агенты, готовые абсолютно любыми средствами выбивать для своих обожаемых пользователей лучшие условия. Я думаю, что — если очень быстро ничего не изменится со стороны политиков — мы стоим на пороге мира, в котором многие вещи, которые обычно считались безопасными, на самом деле на поверку таковыми не являются. И ИИ будет взламывать их направо и налево.2,11%
  • 19 мар.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/web3securityresearch2,05%
  • 21 июл.Участвовал на этих выходных в хакатоне от Hack Nation Было 6 тем на выбор, в итоге билдили с командой голосового ассистента на базе ElevenLabs. В целом, сделали что-то адекватное 20 часам, отведенным на мероприятие Но хочу о другом сказать: несчетное количество раз я читал/слышал, что в строительстве своих проектов надо начинать говорить о них сразу же, запускать сырую версию сразу же, но только на хакатоне удалось прочувствовать эту истину живьем. В общем, я немного (много) закопался в строительство агента, про которого говорил здесь. Точнее даже так, я писал про написание своего фреймворка со встроенной защитой от memory injection, но это уже переросло в строительство агента-помощника на основе этого фреймворка. Параллельно я начал писать систему для анализа защищенности агентов по критериям AIUC-1, а так же писать свою RAG-систему для работы с вновь выходящими на arXiv работами. Эти проекты в разной степени далеки от прода, но я вижу в каждом из них нужность и потенциал, так что буду рассказывать про трудности, с которыми столкнулся в процессе и тем, как их решать (что не всегда понятно). https://t.me/web3securityresearch2,03%
  • 12 авг.Исследователи нашли первый подробно задокументированный, почти автономный, взлом государственной инфраструктуры В начале июля кто-то собрал на базе 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-d90260d587951,82%
  • 19 мар.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/web3securityresearch1,79%