Похек

ИИ-агент устроил инцидент. Кто и как будет его расследовать?

На E-CODE 2026 об этом поговорят в отдельном треке по информационной безопасности. Один из докладов разберёт применение Defense-in-Depth и DFIR в компании ИИ-агентов: как строить эшелонированную защиту и готовиться к расследованиям в инфраструктуре, где агенты действуют самостоятельно.

Контекст шире одной темы. В программе — создание аналога SLSA одновременно для банка и спутниковой системы, разбор ландшафта киберугроз и критических ошибок, а также практические кейсы Zero Trust. О том, куда в кибербезопасности движется сам Ozon Tech, расскажет CISO компании Кирилл Мякишев.

После технической части микрофоны перейдут к Нейромонаху Феофану, Кассете, группам «ХЛЕБ» и Jane Air, DJ Groove и Александру Анатольевичу. Будут концерты и караоке — уже без слайдов, зато с гостями конференции в свете софитов.

Доклады и остальные детали собраны в программе E-CODE.

На OFFZONE. Все обошёл, купил себе e-badge и микрокамеру. Сижу жду докладиков

Похек жесточайше получил бейдж и одним глазком поредтимил площадку

(Остальные инсайды не стал выкладывать, завтра сами увидите)))

Очень советую приехать сегодня и получить бейдж, иначе завтра принудительно придётся практиковать обочечный нетворкинг))

Но берите сегодня, может и 20-21 зонтики на всякий случай или ветровки

*площадка еще строиться, к завтра уже будет бимбо))

Activation Lock и Quick Start: когда миграция данных затрагивает владение

Activation Lock задуман как защита, которая переживает стирание устройства. По документации Apple, после включения Find My состояние блокировки проверяется через серверы активации, а повторная активация требует учётной записи владельца. Apple Support

В полном отчёте от 5 июня 2026 описан кейс на конкретной связке: iPhone 13 с iOS 18.6, заблокированный под чужой учётной записью и помеченный как Lost после фишинга, и iPhone 7 с iOS 15.8.8, привязанный к легитимной учётной записи. По наблюдению автора, после сброса и штатной миграции Quick Start целевой iPhone оказался связан с учётной записью исходного устройства. Повторное стирание завершилось без прежнего экрана Activation Lock.

Сценарий, как утверждается в отчёте, не требовал джейлбрейка, аппаратной атаки или знания пароля заблокировавшей учётной записи. Достаточными условиями были физический доступ к устройству и второй iPhone. Поэтому речь идёт не о «взломе пароля», а о предполагаемой ошибке авторизации в доверенном процессе передачи данных. Quick Start предназначен для переноса данных между устройствами, а не для изменения владельца Activation Lock. Apple Support

Гипотеза автора: сервер мог принять авторизованную сессию исходного устройства за право изменить состояние блокировки целевого, не проверив существующую привязку к другой учётной записи. Разница версий iOS — 15.8.8 против 18.6 — могла задействовать устаревший путь совместимости. Это реконструкция по наблюдаемым признакам, а не подтверждённое описание серверной реализации.

🔗Источник: публичная ретроспектива

🌚 @poxek | 🌚 @poxek_ai | 📲MAX

Продолжение моей очень долгой и скучной истории с европейской багбаунти платформой Bugcrowd. Я сдал P2/P3 (High-medium) уязвимость в один очень крупный проект БД. От команды платформы был проведен довольно быстрый первичный триаж за неделю где-то, с учетом что у них не получалось проэксплутировать багу и я им финально уже даже видос записывал, как скачиваю самую последнюю версию ПО, как поднимаю сервис и как запускаю скрипт после чего сервис сворачивается в клубочек. Вопросов к тому что я русский (т.к. У них обязательный KYC для отправки первого отчёта. Я проходил на свой заграник и прошел с первого раза его). После чего команда Bugcrowrd передала меня в руки вендора 8 июня и тут началось ожидание.........










Очень сука долгое ожидание. С 8 по 15 июня я ответственно ждал хоть какого-то пинга со стороны вендора. После чего увидел что есть прекрасная кнопка, как пнуть вендора и мол он заметит. Таких есть 2 волшебных пинга и если вендор в течение 2 недель не отвечает - пинг возвращается. Звучит адекватно и удобно для всех.

В итоге мной было отправлено 3 пинга, после чего я благополучно забыл о баге.

В какой-то момент я вспомнил, зашел - увидел снова тотальный игнор и уже думал тупо дисклознуть багу куда-нибудь и забить болт; Но благо вендора я на что-то отвлекся))

В итоге 15 аВгУсТа мне наконец ответил вендор, мол спасибо что подождали, если в течение 2 недель не придет финальный ответ - пингуйте)))
Начислили какие-то 10 points (если кто работает по этой платформе, подскажите что это и на что влияет?)

Как история закончится, постараюсь запросить дисклоз и показать багу.

Собственно багу нашла ИИшка, буквально минут за 10-15 (но результат скорее рандомный, вероятно со второй попытки на чистую она бы уже не нашла её), чуть не положив мне основную систему в ходе эксплуатации)))
Не фаззьте дети на основной машине, только в виртуале

Stay tuned! 🇷🇺

Поправили в комментариях, что Bugcrowd это американская бб, а не европейская

ФРИИ и 🥰METASCAN запускают акселератор для ИБ-стартапов

Российским командам в сфере ИБ часто не хватает не разработки, а доступа к крупному заказчику: пройти пилот, подтвердить ценность продукта, разобраться с закупкой и довести переговоры до контракта. Под это ФРИИ и METASCAN запустили совместный фонд объёмом 600 млн рублей и его первую инициативу — двухмесячный акселератор.

В него отберут до 20 российских ИБ-компаний с работающим продуктом на стадии MVP или выше, первыми клиентами, пилотами либо выручкой. Инвестиции в один проект — от 5 до 100 млн рублей; участие бесплатное. Уже закрыта одна сделка: 40 млн рублей получил стартап по обучению сотрудников ИБ с выручкой 1,5 млн рублей.

В фокусе — кибербезопасность, DevSecOps, защита данных, антифрод, мониторинг, compliance и security tooling. Приоритетны управление уязвимостями, защита веб-приложений и API, автоматизация ИБ-процессов и ИИ в защите.

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

Заявки принимают до 15 сентября. Старт — 1 октября.

OpenAI инсценировала взлом Hugging Face? В истории слишком много белых пятен
#openai #huggingface #анализ #pr

Статья на Хабре разбирает не столько сам взлом Hugging Face во время внутренней кибероценки OpenAI, сколько пробелы в его публичном описании. И это полезная оптика — если не превращать вопросы в готовый вердикт.

Самый предметный из них — воспроизводимость среды. Открытый ExploitGym содержит 869 задач по эксплуатации уязвимостей в userspace, V8 и Linux kernel и предусматривает изоляцию исходящего трафика. В официальном отчёте OpenAI говорится о внутренней среде, где сетевой доступ был ограничен прокси-кэшем реестров пакетов; модели, по утверждению компании, нашли и использовали zero-day в Artifactory, чтобы выйти во внешнюю сеть. Это объясняет, почему описанный инцидент не сводится к публичному набору задач, но не отвечает на главный вопрос: какие внутренние расширения, права и наблюдение за длительными запусками сделали такую цепочку возможной.

Автор справедливо обращает внимание и на операционную сторону: сохранение контекста или артефактов между запусками, доступ к учётным данным, аномальные обращения к внутренним сервисам, отсутствие быстрой остановки. Это не доказательство того, что «главную часть сделали люди». Пока есть предварительная версия OpenAI и заявления сторон; независимый технический отчёт ещё не опубликован.

Для команд, запускающих агентные кибероценки, вывод прозаичнее: изоляция должна быть проверяемой. Нужны запрет исходящего трафика по умолчанию, короткоживущие учётные данные, раздельные среды для задач и инфраструктуры, сброс состояния между запусками и автоматическая остановка по признакам lateral movement. Без журналов действий и независимой реконструкции инцидента любой рассказ о «самостоятельности» агента остаётся неполным.

СТАТЬЯ тут

Факты сверены с сообщением OpenAI / репозиторием ExploitGym / позицией METR

🌚 @poxek | 🌚 @poxek_ai | 📲MAX

Агент в CI/CD может провести вредоносный код через собственные проверки

Исследователь Yohann Sidot проверил, как пятиагентный CI/CD-конвейер реагирует на внешнее обращение с просьбой добавить «телеметрию». В тексте обращения была prompt injection: фраза о якобы заранее согласованном изменении с номером SEC-2291 и требование не проводить повторную проверку. Предложенный код маскировал передачу переменных окружения процесса под наблюдаемость.

Первый агент не раскрыл системный промпт. Но последующие этапы — разработка, сканирование, ревью и одобрение деплоя — принимали заявленное согласование за факт: сканер пропустил около 80% замаскированных pull request, а в худшем варианте эксперимента до деплоя дошло 55% сценариев.

Это не отчёт об атаке на реальную компанию. Автор использовал синтетические данные, имитировал конечную точку и не отправлял секреты наружу. Выборка также невелика: 20 запусков для основных условий. Поэтому цифры нельзя считать оценкой распространённости риска в промышленных конвейерах.

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

В агентном CI/CD обращения, описания pull request, комментарии и документацию нужно считать недоверенным вводом, а не инструкциями. Деплойные права, доступ к секретам и исходящий трафик должны ограничиваться детерминированными политиками вне контекста модели; значимые изменения — проходить независимое подтверждение.

Видео с PoC на YouTube

🌚 @poxek | 🌚 @poxek_ai | 📲MAX