Обновить

Информационная безопасность

Сначала показывать
Порог рейтинга

Вот и подошел к концу летний интенсив Баумантех.Дети, который проходил в течение всего июля на базе МГТУ им. Н.Э. Баумана. Школьники 7-11 классов со всей страны приехали не только обучиться информационной безопасности, технологиям, инженерии и ИТ, но также попробовать себя в качестве специалистов по ИБ.

В рамках обучения, кроме теоретической части, ребят ждали:
* практикумы, где участники разбирали реальные сценарии кибератак, искали уязвимостей и работали с инструментами ИБ-специалистов
* расследования - игра, в которой участники учились мыслить как синяя команда: анализировали подозрительные события, искали цифровые следы и расследовали инциденты
* CTF (Capture The Flag) - пробовали один из самых популярных форматов в мире кибербезопасности: командные соревнования на логику, внимательность и практические навыки
* финальные проекты, в рамках которых участники применили всё, чему научились, и представили результаты на финальной защите.

Конечно же, будущим ИТ экспертам показали, как работает настоящий центр кибербезопасности (SOC), и дали возможность познакомиться с его инструментами на практике путем выявления реальной хакерской активности. Также ребята посетили безэховую камеру (место, где действительно начинаешь слышать собственное сердцебиение и внутренний голос), а также рентгеновскую лабораторию, где «всё тайное становится явным».

В качестве наставников и преподавателей были приглашены специалисты и эксперты ведущих ИТ-компаний страны. Со своей стороны я рассказывал про поиск информации по открытым источникам (OSINT), а также показывал "чемоданчик хакера" - аппаратные инструменты, которыми наша команда пользуется практически на каждом проекте

Те, кто не успел принять участие в летней сессии - не переживайте. Впереди осенние интенсивы (в течениие каникул) с новыми расследованиями и задачами. Мир ИБ огромен, и мы рады быть вашим проводником в нем.

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Теги:
Всего голосов 2: ↑1 и ↓1+2
Комментарии0

В связи с историей про “Мадагаскар” https://habr.com/ru/articles/1067420/ , не грех опубликовать вот этот скриншот.

2
2

Это я вставил в конец статьи https://habr.com/ru/articles/1065858/ инструкцию , а потом пошёл постить соответствующий запрос в разные сервисы.

Один из испытуемых сам нашёл статью, скачал и честно выполнил инструкцию.

Теги:
Всего голосов 3: ↑3 и ↓0+5
Комментарии4

Вышел 9-й номер журнала Paged Out (#8 выпустили в июне), который включает в себя различные материалы на тему этичного хакинга и информационной безопасности. Издание публикуется в формате: 1 страница — 1 статья. Все остальные Paged Out выпуски можно скачать с сайта проекта.

Теги:
Всего голосов 3: ↑3 и ↓0+5
Комментарии0

Полтора года пентестов Active Directory сводились к одному и тому же неудобству: для аудита нужен PingCastle (только Windows, только скоринг, ничего не проверяет на практике), для графа путей атаки — BloodHound плюс отдельный коллектор (SharpHound или RustHound-CE), а для реальной эксплуатации — Impacket на Python со всем шлейфом зависимостей. Три инструмента, три экосистемы, и ни один не даёт честного ответа на вопрос "эта уязвимость реально эксплуатируется в этом домене прямо сейчас, или только теоретически светится в отчёте".

Я решил закрыть это одним инструментом — adhammer.

Что внутри

adhammer — это Rust-тулкит для AD security assessment, который совмещает три слоя:

  1. Аудит в стиле PingCastle — сканирует домен, скорит находки по severity, размечает MITRE ATT&CK тегами.

  2. Граф путей атаки в стиле BloodHound — строит и визуализирует attack paths до Domain Admin.

  3. Валидация с реальным PoC — вот это ключевое отличие. Guided-режим проходит по каждой находке и предлагает: "провалидировать и получить PoC?". Если да — запускает реальную атаку и помечает finding как "validated" только если получен настоящий артефакт — хеш $krb5tgs$/$krb5asrep$, реплицированный секрет krbtgt, реально выпущенный сертификат. Если атака не удалась — честно "attempted", а не тихо пропускается.

Почему Rust, а не поверх Impacket

Изначально пробовал строить поверх существующих Python-библиотек — уперся в то, что тащить весь стек зависимостей ради одного бинарника, который должен без проблем компилироваться и запускаться и с Kali, и с Windows-хоста внутри AD-сети, неудобно и хрупко.

Поэтому пришлось написать протокольный стек с нуля: DCE/RPC, NTLM, SMB2, Kerberos — практически "impacket для Rust", которого в экосистеме ещё не было. Результат — один статический бинарник без рантайм-зависимостей, кросс-компилируется под Linux и Windows.

Что дальше

Инструмент build как security research, соседствует с раскрытым в MSRC 0-day в ядре Windows. Сейчас думаю над тем, чтобы вынести протокольный стек в отдельные переиспользуемые crates — уже начал переписку с мейнтейнерами sspi-rs и RustHound-CE на предмет пересечения усилий.

Код и write-up: github.com/icedracon/adhammer

Использование — только на системах, где есть явная авторизация. SECURITY.md в репозитории описывает это подробно.

Буду рад issues, PR и просто фидбеку от тех, кто занимается AD security на практике.

Теги:
Всего голосов 2: ↑2 и ↓0+4
Комментарии0

Продуктовые новости Innostage в июле

Мы продолжаем системно развивать продукты, чтобы они, ещё точнее, отвечали задачам заказчиков, требованиям рынка и регуляторов, а также были удобны в ежедневной эксплуатации. Собрали ключевые обновления и события за месяц: что изменилось и что уже применяется на практике.

Вышла новая версия Innostage PAM 1.7.0

В новой версии Innostage PAM. Управление привилегированным доступом доработаны сценарии, от которых зависит повседневная эксплуатация PAM в крупных корпоративных инфраструктурах: улучшение функциональности работы с RDP; больше прозрачности при входе по сертификатам, смарт-картам и токенам; новые возможности автоматизации при работе с SSH-ключами; улучшения защиты данных и хранения событий. Подробнее →

Innostage AIDR включён в реестр российского ПО

Innostage AIDR «Защита ИИ» помогает контролировать взаимодействие с языковыми моделями: какие запросы отправляются, какие ответы возвращаются и какие события возникают внутри ИИ-контуров. Подробнее →

Вебинар по обновлённой версии Innostage PAM 1.7.0

Показали ключевые сценарии работы с новой версией Innostage PAM 1.7.0: доступ через RDP, аутентификация по сертификатам и управления SSH-ключами. Смотреть запись →

Регуляторика и ИБ: что меняется на практике

Обсудили с СПб ИАЦ усиление требований к ИБ в госсекторе. В фокусе — совместимость решений и соответствие нормативам (в т. ч. ФСТЭК №117). Показали, как эти задачи закрываются на практике: от расследования инцидентов до контроля применения ИИ с помощью Innostage TDIR и Innostage AIDR. Подробнее →

Теги:
Всего голосов 2: ↑2 и ↓0+4
Комментарии0

DDoS-Guard провела исследование совместно с FirstVDS, пионером российского VDS-хостинга. 

Мы изучили состояние современных DDoS-атак, собрали статистику по атакуемым отраслям. Составили портрет того, как скорее всего будет выглядеть DDoS-атака, с которой вы столкнетесь, и насколько велик риск конкретно для вашей отрасли.

Зафиксировали значительный рост тактики Pulse Wave: когда волны трафика идут с паузами, чтобы сбить с толку автоматические системы защиты.

Отметили значительное повышение атак на игровые сервисы и тенденцию к росту атак длиной более суток.

Выявили прямую корреляцию риска атаки с возрастом сервера.

И многое другое.

Каждая из компаний изучала данные со своей стороны, а затем мы объединили результаты. Была исследована внутренняя статистика, опрошены более двухсот действующих клиентов FirstVDS и изучены глобальные тренды (с нашей стороны — данные по более чем 7,5 млн инцидентов, включая типы атак, отраслевую структуру, географию источников и сезонные колебания).

Полностью прочесть исследование можно здесь.

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

БДУ ФСТЭК работает в обе стороны, и у обратной стороны есть срок: пять рабочих дней

В банке данных угроз ФСТЭК сейчас 91 986 уязвимостей, счётчик на главной bdu.fstec.ru. Все привыкли к движению в одну сторону: оттуда берут перечни, туда ходят сканеры, на базу ссылаются регламенты.

Обратное движение тоже существует: кнопка «Сообщить об уязвимости» на сайте есть, жмут её добровольцы. А с 1 марта 2026 года для операторов госсистем это уже не добрая воля. Приказ ФСТЭК № 117, пункт 38: при выявлении уязвимости, сведений о которой в БДУ нет, оператор «в срок не более 5 рабочих дней с даты такого выявления должен направить информацию об уязвимости в ФСТЭК России для оценки необходимости включения выявленной уязвимости в банк данных угроз…». Основание в сноске приказа: подпункт 21 пункта 8 Положения о ФСТЭК.

Нашли на пентесте или в бою что-то, чего в базе нет, и делиться этим вы обязаны, причём быстрее, чем во многих конторах согласуют служебную записку.

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

Формально пункт касается ГИС и систем госорганов. Но у него есть эффект второго порядка: базу теперь обязаны кормить и эксплуатанты, не только исследователи с вендорами. Любопытно, сколько из следующих тысяч записей придёт именно этим маршрутом.

Кто-нибудь уже отправлял находку во ФСТЭК по пункту 38? Интересно, как быстро отвечают и доходит ли уязвимость до публикации.

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии3

Атака на цепочку поставки через Steam, или как вредоносный код спрятали в легитимных обновлениях

В США задержали 21-летнего Зайра Уилкинса, которого обвиняют в причастности к схеме распространения игр с вредоносным кодом через Steam. По версии следствия, встроенное в игры вредоносное ПО собирало учетные данные и другую информацию с компьютеров пользователей.

В июле 2026 года в суд поступили подробные материалы дела. В документе говорится о восьми играх с вредоносным кодом и примерно 8 тысячах зараженных устройств. Следствие связывает атаку с несанкционированным доступом приблизительно к 80 криптовалютным кошелькам и хищением не менее 220 тысяч долларов. Пока это версия обвинения, а не установленные судом факты.

Игры распространялись через учетные записи разработчиков. По данным следствия, для регистрации использовались похищенные персональные данные — это позволяло злоумышленникам успешно проходить проверки площадки, запрашивающей документы и платежные реквизиты. Затем релизы продвигали через соцсети и сообщения пользователям с крупными криптовалютными активами.

Особенно показателен случай Lampy. Вредоносный код содержала обновленная версия игры, выпущенная в январе 2026 года. Пользователю не требовалось переходить на поддельный сайт или устанавливать программу из неизвестного источника – исполняемый файл доставлялся через привычный механизм обновлений.

Судя по опубликованным материалам, злоумышленники не взламывали сам Steam. Они встроились в штатный процесс поставки и использовали доверие к площадке, учетной записи издателя и обновлениям. Этот случай хорошо дополняет привычное представление об атаках на цепочку поставки. Точкой входа может стать не только скомпрометированная зависимость или система сборки, но и канал, через который готовый продукт доходит до пользователя.

Публикация через доверенную площадку не делает программу безопасной, а обновление необходимо проверять как новый исполняемый артефакт. Для владельца площадки это означает повторный анализ каждой загружаемой сборки, сравнение с предыдущим выпуском и запуск в изолированной среде. На устройстве пользователя такая атака уже попадает в зону, ответственности антивируса, EDR и контроля запуска приложений. Они могут обнаружить подозрительное поведение уже установленной программы, хотя ни один из этих уровней сам по себе не дает гарантии.

Подписывайтесь на CodeScoring в Telegram, VK, YouTube и Макс.

Теги:
Всего голосов 4: ↑4 и ↓0+6
Комментарии0

uInfraTwin: цифровой двойник сегмента сети для безопасного тестирования изменений

Тестировать обновления или новые сервисы сразу на боевом контуре рискованно. А собирать тестовый стенд, который бы в точности повторил уникальную инфраструктуру заказчика, как правило, долго и дорого.

Чтобы закрыть эту задачу, мы представили платформу виртуального цифрового двойника сегмента сети UserGate InfraTwin (uInfraTwin).

Решение совмещает функции эмулятора и симулятора. Оно позволяет создать цифровую копию окружения и безопасно моделировать в ней изменения: проверять совместимость uNGFW со сторонними системами, анализировать уязвимости или расследовать инциденты в изолированной среде, не затрагивая продакшн.

Платформа имеет модульную архитектуру и поставляется как отдельный продукт, а не как функция других решений. Сейчас uInfraTwin проходит пилотную эксплуатацию в ряде крупных российских компаний. В планах развития — добавление новых модулей и образов решений, а также обеспечение возможности самостоятельной разработки образов силами партнёров-интеграторов и заказчиков.

➡ Узнать детали и запросить пилот

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

PyPI готовится закреплять префиксы имен пакетов за организациями

29 июня 2026 года был принят PEP 752. Он описывает механизм, с помощью которого пакетные репозитории смогут закреплять префиксы имен за определенными организациями. Например, новые пакеты с префиксом google-cloud- смогут публиковать только организации, получившие соответствующее право.

Сейчас пространство имен PyPI остается плоским. Если название свободно, пользователь может зарегистрировать пакет, который выглядит частью известного проекта, например, google-cloud-something, opentelemetry-something или apache-airflow-providers-something. Знакомый префикс повышает доверие к названию, хотя реального отношения к организации у пакета может не быть.

PEP 752 предлагает закреплять за владельцем как сам префикс, так и новые названия, которые включают префикс и дефис после него. Попытка опубликовать такой пакет без разрешения будет завершаться ошибкой. При этом уже существующие проекты можно не блокировать. Репозиторий вправе разрешить их владельцам выпускать новые версии и после появления защищенного префикса.

Синтаксис имен не изменится, поэтому дорабатывать pip, uv и другие менеджеры пакетов ради обычной установки не потребуется. Вместе с тем в API репозитория появятся сведения о связи проекта с защищенным префиксом. В дальнейшем менеджеры пакетов и прокси смогут учитывать их в собственных политиках.

Принятый PEP пока описывает стандарт, а не уже работающую функцию PyPI. Правила подачи и рассмотрения заявок вынесены в PEP 755, который остается черновиком. Срок запуска механизма также пока не объявлен.

PEP 752 переносит часть проверки на самый ранний этап, когда в репозитории только появляется новое имя. Для семейств пакетов вроде google-cloud-* или apache-airflow-providers-* это позволяет остановить постороннего издателя до того, как правдоподобно названная подделка станет доступна пользователям.

У такой защиты есть довольно четкие ограничения. Право на префикс подтверждает, что издатель может использовать такое имя в конкретном репозитории, но ничего не говорит о безопасности содержимого. Если учетную запись доверенного издателя скомпрометируют или он сам выпустит вредоносную версию, резервирование не поможет. На другой репозиторий выданное право тоже не распространяется.

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

Подписывайтесь на CodeScoring в Telegram, VK, YouTube и Макс.

Теги:
Всего голосов 4: ↑4 и ↓0+6
Комментарии0

Не устану повторять, что подключение ОТ и АСУТП оборудования к интернету является не самой лучшей идеей, равно как и использование беспроводных технологий для их управления. И если вы думаете, что это касается только корпоративной среды с их заводами и мануфактурами, то смею вас огорчить, что это не является истиной уже как последние несколько лет.

Умные дома раньше были предметами роскоши и гордости. Конечно, потратить несколько десятков или сотен тысяч на дорогущее оборудование для управления светом, климатом, охраной и мультимедией в автоматическом режиме дорогого стоит. Только раньше все эти помощники базировались преимущественно на проводных шинных стандартах, а не на радиоволнах.

Сейчас же ситуация кардинально изменилось. Правилом хорошего тона является LoRa или Wi-Fi (иногда и 433,92 МГц), быстрая установка, чистота и доступность из любой точки мира.
Отчасти в этом виноваты сами потребители: устройства умного дома устанавливают в уже отремонтированные дома и квартиры, стены которых для прокладки кабеля никто штробить не хочет: тут и грязь, шум, да и дополнительный бюджет на работы и провода. Гораздо проще подключить чайник по LoRe к умной колонке и голосом его заваривать (кто правда воду наливать будет не сказано)).

Вот тут вот и кроется самая главная уязвимость: радиоволны выходят далеко за пределы вашей квартиры или дома и злоумышленник без особого труда, находясь в соседнем подъезде, меняет вам температуру на термостате "умной" батареи. И я сейчас не фантазирую, а рассказываю реальный кейс, когда мой друг купил себе такой обогреватель и при подключении и настройке нашел аналогичный у соседей (кстати, при подготовке данного поста я также нашел несколько чужих устройство в радиусе действия).

Самое распространенное приложение для управления домом является SmartLife, которое де-факто считается золотым стандартом бюджетных и средне-бюджетных "умных устройств". Если мы откроем программу, мы увидим, что оно умеет работать с розетками, светом и LED-лентами, датчиками движения, холодильниками, кофе-машинами, электрическими автоматами и еще с более 100 устройств. То есть теперь злоумышленник не только может удалить пару файлов у вас на компьютере и украсть данные карт, но и физически причинить ущерб, вплоть до летального исхода.

Почему я снова об этом заговорил? Буквально пару дней назад Ремонтяш выпустил новое видео, в котором обозревает китайский клон японского "умного" унитаза, выделяя все его удобства, красоту и функциональность. Однако, не смотря на то, что Ремонтяш достаточно хорошо разбирается в IT, проблема беспроводной безопасности как-то прошла стороной. Он только вскользь упомянул, что пульт работает на частоте 2,4 ГГц и является основным центром администрирования, включая настройки температуры воды.
Поэтому, скажем так, я не готов доверить свое тело на откуп китайским инженерам и добросовестности соседей, которые случайно смогут подключиться к моему унитазу (про дружелюбный интернет с его пранками я думаю напоминать не стоит).

Так что теперь распространенное выражение из конца нулевых

я тебя по IP вычислю и надеру }|{0пу

не кажется уже и таким виртуальным. А вы что скажете: доверемся 2.4 ГГц или лучше все-таки по кабелю?

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Теги:
Всего голосов 2: ↑1 и ↓1+1
Комментарии7

Агентная проверка безопасности для Rust

Сделал свой микро-Mythos на основе Anthropic's defending-code-reference-harness но для нормального языка.

Веселитесь:
https://github.com/scadastrangelove/rust-in-peace

Автономный цикл разведки → обнаружения → оценки → обнаружения → фаззинга → отчета → исправления для реальных ошибок, которые действительно затрагивают Rust: безопасность памяти в unsafe/FFI, DoS-атака из-за паники, вызванная недоверенными входными данными, доверие к десериализации (проверка целостности не является проверкой границ) и надежность Send/Sync + безопасность при панике.
Статический анализ управляет динамическим этапом — модель угроз определяет, какой санитайзер, порог фаззинга и бюджет голосования получит каждая обнаруженная ошибка.

Детекторы: Miri (неопределенное поведение), AddressSanitizer, panic/abort, hang-timeout и cargo-fuzz для динамического воспроизведения ошибок.

Если на сцене висит ружьё то не удержался и я - запустил Rust In Peace по десятку популярных ржавых ящиков. Из тех, что в топе и парсят внешние данные, чтобы с поверхностью атаки.

На удивление балалайка не только пожужжала и съела токены, но реально нашла забавное, наделала PoC-ов и фиксов — часть уже смёржена мейнтейнерами.

По состоянию на 24.07.2026 было зарегистрировано 51 сообщение об уязвимостях в 17 независимых проектах на Rust: 12 уже исправлены и в влиты в main (включая lopdf, x509-parser, quick-xml, ntex), еще 9 приняты или находятся на рассмотрении в качестве GSHA безопасности (gitoxide, quinn-proto, rustls, ciborium, h2, hyperium).

Трекер тут: https://github.com/scadastrangelove/rust-in-peace/blob/main/DISCLOSURES-PUBLIC.md

Из интересного:

Методически правильный подход через «модель угроз» работает иногда так же хорошо, как просто бахнуть бессистемно. Просто они находят разные баги. На одном таргете: threat-model-first взял глубину и логические баги, слепой прогон взял пачку генериков, которые модель угроз недооценила, поскольку слишком умная, но фаззинг подтвердил. Ничья, точнее дабл страйк.

Старая пословица «баги ходят косяками» работает. «Поищи ещё такие же», «в этой функции был такой-то баг — проверь остальные» — приёмы из репертуара Google Project Zero живее всех живых. RUSTSEC-патч закрыл что-то в парсере, но не тронул еще четыре точки входа — те же дырки. Добавил как третий срез.

Статика и фаззинг — это хорошо, но только PoC — мерило истины. Очевидно, но забывается. В половине случаев когда и агент-копатели, и «более умный» ревьюер независимо согласились, что путь достижим — оба ошибались, поймала это только реальная сборка и прогон против настоящего апстрима.

Слепой фаззинг хорошо но уже есть у большинства проектов, инструментированный cargo-fuzz еще лучше, а если на вход скормить находки анентской статики, то вообще бомба.

Всегда стоит почитать issues и проверить ветки перед тем как бахать репорт и репортить бахи. Вполне может приключится, что твоя находка уже закрыта. Просто не релизнута ещё. В табличке это отдельная строка «refound». Особенно обидно, было когда три баги все разом закрылись одним ещё не выпущенным архитектурным рефакторингом. А робото жужжал и хлопал в ладоши, эх.

Разглашение в open source не сильно отличается от «responsible disclosure» в закрытом софте: кто-то вливает фикс за час, кто-то говорит спасибо, кто-то наоборот - «это всё неправда». Как и в коммерции, отказ это не последняя инстанция: поставил себе таймер вернуться через месяц и перепроверить на сайлент-фиксы.

Ну и да, часть человеков роботов не любят и ругаются на «нейрослоп», несмотря на приложенный PoC и рабочий фикс. Ну штош, не привыкать. Неолуддизм и прочий подсчет букв ё, это святое

Если честно, сам не ожидал такого результата — штука реально работает, хоть токенов жрёт изрядно.

Теги:
Всего голосов 2: ↑2 и ↓0+5
Комментарии0

Русскоговорящий хакер использовал Gemini для контроля ботнета из восьми компьютеров стоматологических клиник

Именно такими заголовками пестрили новостные ленты на этой неделе в западных СМИ. Давайте разберемся, что произошло и действительно ли данная новость достойна звания новости.

В понедельник, 20 июля, на известном новостном агрегаторе thehackernews.com вышла одноименная статья, основанная на исследовании японо-американской компании в сфере кибербезопасности Trend Micro. Как утверждают авторы статьи, исследователи обнаружили русскоязычного злоумышленника под псевдонимом bandcampro, который использовал Google Gemini CLI как полноценного помощника при проведении реальных атак. Анализ основан на более чем 200 логах сессий Gemini CLI за период с 19 марта по 21 апреля 2026 года.

Специалисты называют это одним из первых документированных случаев, когда LLM понимает существующую инфраструктуру атаки, самостоятельно пишет код, исправляет собственные ошибки и помогает администрировать действующий ботнет. По оценке Trend Micro, во время миграции инфраструктуры сам злоумышленник выполнил лишь около 11% действий, остальное сделал ИИ: во время подготовки инфраструктуры возникли ошибки (502 Bad Gateway, блокировка Cloudflare, проблемы с HTTP-заголовками), однако Gemini сам диагностировал проблемы, предлагал добавить нужные заголовки, определял необходимость User-Agent и корректировал запросы. По мнению исследователей, ИИ использовался уже не как генератор кода, а как инженер по эксплуатации инфраструктуры.

Ну и как вишенка на торте, все инструкции (ради чего и была, наверно, написана статья) были на русском языке.

Однако, если детально проанализировать текст исследования и написанной на его основе статьи, мы не увидим ничего нового. Обход, злоупотребление и эксплуатация цензуры ИИ уже существует достаточно давно и компании-разработчики пытаются активно защититься от данного вида атаки. В данном случае, несмотря на громкое имя, Google оказался существенно уязвим, раз в течении нескольких месяцев ее детище активно использовалось для описанных в статье действиях.

С моей точки зрения, само по себе исследование интересно не потому, что найден новый джейлбрейк, а потому что появился хорошо задокументированный кейс: опубликованы реальные логи злоумышленника, показано длительное использование ИИ-агента в живой атакующей инфраструктуре и количественно оценена доля работы, выполненной AI. Исследование помогает понять как думает злоумышленник, последовательность его шагов и, самое главное, цели. В принципе можно сказать, что из Gemini получился симбиоз Honeypot и SIEM, который записал подробные действия хакера.

п.с. Вопрос: насколько быстро удалось бы обнаружить активность bandcampro, если бы среди исследователей не оказалось специалистов, свободно читающих русскоязычные логи? ;)

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Теги:
Всего голосов 2: ↑0 и ↓2-2
Комментарии0

Ближайшие события

Готовы бросить вызов киберугрозам?

Попробуйте себя в роли атакующего или защитника с полноценной подготовкой, рейтинговой системой и фокусом на практические навыки.

29–31 октября в Казани пройдет V Всероссийская студенческая кибербитва. Это соревнование по практической информационной безопасности, где команды студентов работают в условиях, максимально приближенных к реальности.

Команды Атакующих (Red Team) ищут уязвимости и реализуют атаки, команды Защитников (Blue Team) — расследуют инциденты и выстраивают защиту на модернизированном киберполигоне Innostage с цифровыми копиями реальных систем.

В юбилейном сезоне обновлен формат:

— уже с 24 августа участники начнут подготовку на киберполигоне, впервые для обеих ролей — и Защитников, и Атакующих;
— вместо классического отбора — диагностический этап: команды выполняют практические задания и распределяются по лигам (от новичков до продвинутых);
— количество баллов на кибербитве теперь складывается не только из результата, но и из техничности эксплуатаций уязвимостей, глубины расследований и других факторов.

Что это значит для участников? Больше практики, распределение по лигам и возможность расти в процессе подготовки к финалу кибербитвы. Впервые на подобных соревнованиях вводятся дополнительные номинации для оценки разных достижений команд еще в процессе предфинальной подготовки.

Требования к участникам:

✅ Студенты российских вузов и колледжей
✅ Базовый опыт в ИБ / CTF или готовность быстро погружаться
✅ Состав команды от 3 до 10 человек
✅ Интерес к развитию в кибербезопасности

До 10 августа соберите команду, зарегистрируйтесь и начните подготовку 🛡

Подробности и регистрация ➡️кибербитва.рф

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

Hugging Face взломали через датасет: автономный AI-агент дошёл до внутренних кластеров

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

Цепочка атаки

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

Агентный фреймворк выполнил тысячи операций в короткоживущих средах, а C2 мигрировал между публичными сервисами. Какая LLM использовалась, неизвестно. Независимого подтверждения полностью автономной атаки нет.

Что раскрывают исправления

Hugging Face не опубликовала CVE, payload или карту эксплуатации, но изменения в публичном dataset-viewer раскрывают часть механики.

13 июля разработчики обновили fsspec и ввели allowlist: worker теперь принимает только hf, s3, zip, file и local, а остальные реализации удаляются из registry. Использовавшийся ранее fsspec.ReferenceFileSystem обрабатывал конфигурацию через несандбоксированный jinja2.Template(...).render(...). Это согласуется с заявленным внедрением шаблона и возможным SSTI-to-RCE, но компания официально не связала этот код с атакой.

В тот же день усилили worker-поды: отключили Kubernetes ServiceAccount token, включили seccompProfile: RuntimeDefault и сбросили дополнительные возможности ядра Linux. Точный способ перехода к уровню узла не раскрыт.

Следующие изменения соответствуют ротации секретов. 14 июля в production слили переход на IRSA, убирающий статические S3-ключи. 15 июля MONGO_URL перевели на MONGODB-AWS через IRSA, затем добавили ротацию JWT-ключей. PR совпадают с реагированием, но не названы официальным postmortem.

Масштаб и атрибуция

Подтверждён доступ к части внутренних датасетов и служебным учётным данным. Их количество, права и объём возможной выгрузки не названы. Признаков изменения публичных моделей, датасетов или Spaces не обнаружено; контейнерные образы и пакеты признаны чистыми.

Ни одна группировка не представила проверяемого заявления об ответственности или доказательства доступа. Публичных IoC тоже нет. Связь с JADEPUFFER, имена OpenAI или Anthropic, «первый полностью автономный взлом», а также сообщения о 4200 токенах и 1800 приватных моделях источниками не подтверждаются.

Как расследовали

Атаку обнаружила корреляция телеметрии с LLM-триажем. Аналитические агенты обработали более 17 000 событий, восстановили хронологию, извлекли IoC для внутреннего расследования, сопоставили затронутые credentials и отделили реальные действия от отвлекающей активности.

Коммерческие модели блокировали запросы с командами атакующего, эксплойтами и C2-артефактами. Форензику перенесли на локальную GLM 5.2 от Z.ai: журналы и найденные секреты остались внутри инфраструктуры. GLM использовали защитники; модель атакующего не установлена.

Hugging Face закрыла оба пути исполнения кода, пересобрала скомпрометированные узлы, отозвала затронутые токены, начала более широкую ротацию секретов и усилила admission controls. Пользователям рекомендуют заменить токены и проверить недавнюю активность аккаунта.

Источники

Теги:
Всего голосов 3: ↑3 и ↓0+5
Комментарии0

Как VPN может украсть вашу криптовалюту

VPN принято считать защитным инструментом. Он шифрует соединение, скрывает реальный IP и переносит доверие от интернет-провайдера к владельцу VPN-сервера. Но именно здесь появляется неприятный парадокс. Пользователь устанавливает приложение ради безопасности и добровольно отдаёт ему контроль над маршрутом почти всего сетевого трафика.

Сам по себе VPN не получает магический доступ к seed-фразам и не может просто расшифровать нормальное HTTPS-соединение. Но вредоносный VPN-клиент может оказаться обычным инфостилером в красивой упаковке. Вместе с туннелем он способен читать буфер обмена, искать расширения криптокошельков, красть cookies и сохранённые пароли, подменять адрес получателя или показывать фальшивые окна авторизации. В таком сценарии VPN нужен злоумышленнику не как технология перехвата, а как причина убедить пользователя установить вредоносную программу.

На смартфонах риск ещё интереснее. Android позволяет VPN-приложению создавать виртуальный сетевой интерфейс, через который проходят исходящие пакеты устройства. Это нормальная функция системы, но она требует огромного доверия к разработчику. Если приложение дополнительно просит доступ к специальным возможностям, уведомлениям, экрану, буферу обмена или установке неизвестных сертификатов, оно уже получает возможности, которые к обычному VPN почти не относятся. На iPhone похожим тревожным сигналом будет просьба установить профиль управления или вручную доверять корневому сертификату. Такой сертификат потенциально позволяет организовать перехват защищённого трафика на самом устройстве.

Есть и менее очевидный сценарий через DNS. VPN может назначить собственный DNS-сервер и решать, на какой IP отправить пользователя после ввода адреса сайта. Подделать HTTPS незаметно всё равно сложно, но пользователя можно направить на похожий домен, фальшивую страницу биржи или копию интерфейса кошелька. Если человек не проверяет адрес и подтверждает вход, VPN уже выполнил свою задачу. Иногда вредоносный клиент вообще не трогает трафик, а просто меняет скопированный криптоадрес перед отправкой. Пользователь видит знакомый процесс, но деньги уходят на другой кошелёк.

Поэтому опасен не VPN как протокол, а приложение и инфраструктура, которым пользователь передаёт слишком много доверия. Особенно рискованны клиенты из рекламы, Telegram-архивов, неизвестных GitHub-репозиториев и сайтов-клонов. Перед установкой стоит проверить разработчика, цифровую подпись, источник загрузки, запрашиваемые разрешения и наличие открытого кода. А устройство, с которого проводятся крупные криптооперации, лучше вообще не превращать в полигон для случайных VPN-клиентов. Защищая IP-адрес, легко случайно отдать злоумышленнику куда более ценную часть своей цифровой жизни.

Теги:
Всего голосов 13: ↑2 и ↓11-6
Комментарии1

Всем привет!

Очень много CTF-соревнований проводится с использованием платформы CTFd. Как они сами скромно про себя пишут:

CTFd - The best Capture The Flag framework out there for hiring hackers, training developers, and teaching students.

Я, в одной из своих статей, писал, что полностью автоматическое решение всей CTF-площадки AI- агентом затруднено и перечислил те трудности, с которыми тогда боролся.

Оказывается, у CTFd есть API!

Так вот, работа по API решает тьму из тех проблем, с которыми я тогда столкнулся! Это прям прорыв в моих исследованиях на эту тему!

Для использования API CTFd я написал skill для OpenCode, про который и хочу вам рассказать!

CTFd-Skill — skill, позволяющий ИИ-агенту играть в любой CTF на платформе CTFd через REST API от лица обычного участника: список и чтение задач, скачивание файлов, подача флагов, подсказки, рейтинг, анонсы. Покрывает только player-действия (без админ-эндпоинтов) и работает с любым инстансом CTFd — не привязан к конкретной площадке.

Ключевые возможности:

  • Подача флагов с обработкой всех статусов задачи и авто-backoff без риска заблокировать себя перебором;

  • Персистентный журнал под каждую задачу: файлы, solve-скрипты и статусы решения задач переживают случайные перезагрузки;

  • Авто-обнаружение новых задач и анонсов организаторов (подсказки, уточнения) с классификацией по тегам — ничего не теряется по ходу соревнований;

  • Интеграция с HexStrike;

... и многое другое.

github.com/Chumikov/CTFd-Skill

Теперь промт на решение всей CTF-площадки может выглядеть так:

Используя CTFd-skill, реши все задачи площадки ctf.url.com, token - ...., формат флага ctf{...}. Все задачи, по которым тебе требуются моё мнение или моя помощь, переноси в конец. Решай все задачи, которые можешь решить автоматически.

Пробуйте, пишите обратную связь, ну поставьте мне лайк тут и звезду проекту на GitHub!

Мой телеграм-канал.

Теги:
Всего голосов 2: ↑0 и ↓2-2
Комментарии2

По роду своей деятельности нашей команде постоянно приходится сталкиваться с обходом физической безопасности: будь-то биометрия, СКУД или обычные “амбарные” замки. И как бы не казался большой металлический “кирпич” неприступной крепостью, вскрыть его (при этом вскрыть без повреждений) зачастую оказывается упражнением с низким уровнем сложности.

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

Причиной вскрытия в первом методе, как можно наблюдать на видео, является слабая пружина запорной пластины, которая под действием перегрузки сдвигается и высвобождает наружную скобу. Как итог: прикладываем небольшую силу (например, удар) и замок открывается.

Второй путь - заложенный производителем бэкдор, который при наборе определенной комбинации на замке его просто открывает. Ужас начинается тогда, когда мы попробовали воспроизвести этот код на остальных образцах исследования: все замки имеют встроенную уязвимость (спасибо восточным партнерам за унификацию). В результате, 1-2 минуты и дверь открывается.

По понятным причинам, мы не будем публично раскрывать эксплойт, но уже уведомили об этом производителя и сделали запрос на присвоение CVE/BDU. Как говорится, ждем-с.

Кроме того, уязвимостью также может быть неправильный выбор материала замка (изучаем физику). Если запорная пластина выполнена из металла, подверженного намагничиванию, то отодвинуть ее можно с помощью простого магнита. Второе видео, скорее всего, является постановочным, но как вектор атаки его никто не отменял. К слову, этот метод был опробован первым в исследовании биометрических замков, однако инженеры предусмотрели такой вектор атаки: запорная пластина выполнена из дюралюминия и не подвержена действию магнита.

Подводя краткий итог, могу с уверенностью сказать, что выражение

Все замки от честных людей

появилось не просто так и действительно является правдой. Поэтому, выбирать инструменты или оборудование для организации защиты нужно с умом: злоумышленники думают не стандартно и не всегда идут напролом по предложенному пути.

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Теги:
Всего голосов 3: ↑2 и ↓1+1
Комментарии0

npm 12 больше не запускает скрипты установки зависимостей без разрешения

npm 12 больше не запускает скрипты установки зависимостей автоматически и требует отдельно разрешать установку из внешних источников и Git. Одновременно npm начинает ограничивать токены с обходом двухфакторной аутентификации. В посте разбираем, что это меняет для безопасности установки пакетов и что стоит проверить перед обновлением. 

8 июля 2026 года GitHub выпустил npm 12 и пометил его тегом latest. Вместе с новой версией изменился базовый сценарий установки – раньше скрипт зависимости мог выполниться автоматически, теперь проект должен заранее разрешить его через allowScripts.

Ограничение распространяется на preinstall, install, postinstall и неявные сборки через node-gyp. Если такой скрипт действительно нужен, его можно добавить в список разрешенных; для разбора уже существующего проекта npm предлагает команду npm approve-scripts --allow-scripts-pending, которая показывает зависимости без явно заданного решения и помогает сохранить настройки в package.json.

Тот же принцип теперь применяется к зависимостям из Git и удаленным архивам. Без --allow-git npm откажется устанавливать Git-зависимости, а для архивов по внешним URL понадобится --allow-remote. В июньском анонсе npm 12 GitHub отдельно отмечал, что Git-зависимости создавали обходной путь для выполнения кода даже при использовании --ignore-scripts.

Одновременно npm начинает ограничивать токены с обходом двухфакторной аутентификации: в начале августа 2026 года они потеряют доступ к чувствительным операциям управления аккаунтами, пакетами и организациями, а позднее не смогут напрямую публиковать пакеты. Для автоматической публикации GitHub рекомендует переходить на доверенную публикацию через OIDC или использовать публикацию с ручным подтверждением.

Почему это важно

Новые настройки заметно сужают возможности для атак через установочные скрипты. Это хорошо видно на примере Shai-Hulud и Shai-Hulud 2.0. В первой вредоносные версии пакетов в основном запускали код через postinstall, а во второй для этого использовался preinstall. Однако важно понимать, что вредоносный пакет по-прежнему может попасть в реестр и дерево зависимостей, а нежелательный код выполнится позднее, когда его импортирует приложение или система сборки. npm 12 закрывает не весь путь заражения, а именно автоматическое выполнение кода непосредственно во время установки. Более широкий разбор атак через пакеты и другие звенья цепочки поставки есть в нашей статье «Атаки на цепочку поставки ПО: виды угроз и как с ними бороться».

Перед переходом на новую версию командам стоит проверить:

  • какие зависимости действительно используют установочные скрипты

  • откуда в проектах появляются Git-зависимости и удаленные архивы

  • есть ли в CI долгоживущие токены публикации с лишними правами

Подписывайтесь на Codescoring в Telegram, VK, YouTube и Макс.

Теги:
Всего голосов 2: ↑2 и ↓0+4
Комментарии0

ICL Services выпустила новый эпизод подкаста «Сервисные хроники», посвященный эволюции технологии SD-WAN. Главным гостем нашего выпуска стал Максим Каминский, менеджер по развитию бизнеса «Лаборатории Касперского», давнего партнера ICL Services в области информационной безопасности.

Участники разобрали технологию SD-WAN глазами тех, кто ее разрабатывает, и тех, кто ежедневно внедряет в инфраструктуру бизнеса. Отдельный блок был посвящен кибербезопасности — в ее рамках мы вместе с «Лабораторией Касперского» регулярно реализуем совместные проекты для российских компаний. Герои обсудили, как привязать к SD-WAN полноценную защиту с помощью сервисных цепочек, межсетевых экранов и умной оркестрации.

Теги:
Всего голосов 2: ↑2 и ↓0+4
Комментарии0