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

Карьера в Innostage: ищем пресейл-архитектора

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

Первая позиция — пресейл-архитектор.

Чем предстоит заниматься

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

В зоне ответственности:

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

• определение ключевых стейкхолдеров проекта, их задач, рисков и потребностей;

• подготовка технико-коммерческих предложений с понятным составом работ, решениями и ограничениями;

• анализ рынка, вендоров и open-source решений для выбора оптимального технологического стека;

• поиск возможностей для развития и расширения проектов;

• техническое сопровождение сделки от первого контакта до заключения договора;

• подготовка презентаций и проведение технических демонстраций для заказчиков;

• участие в отраслевых мероприятиях и конференциях в качестве технического эксперта.

Что нам важно

• Архитектурный бэкграунд. Вы проектировали корпоративные ИТ-инфраструктуры и понимаете принципы их построения, эксплуатации и защиты.

• Экспертиза в информационной безопасности. Знакомы с требованиями ФСТЭК, ФСБ, 152-ФЗ и 187-ФЗ и умеете применять их при проектировании решений.

• Системное мышление. Понимаете ГОСТы и нормативные требования, но воспринимаете их как инструмент для создания работающих решений, а не как набор формальных требований.

• Опыт от 2 лет в ИБ/ИТ. Можете самостоятельно обсуждать технические решения с заказчиком, аргументировать свой подход и представлять результаты работы.

Также важно умение находить общий язык с разными участниками проекта — от технических специалистов и директоров по ИБ до руководителей бизнеса и финансового блока.

Что мы предлагаем

• помощь в адаптации и погружении в работу;

• ДМС, включая стоматологию, телемедицину, психологическую поддержку и ежегодное медицинское обследование;

• страхование от несчастных случаев и страхование при выезде за рубеж;

• возможности профессионального развития: курсы, семинары и доступ к онлайн-библиотеке МИФ;

• частичную компенсацию занятий спортом;

• сообщества сотрудников по интересам;

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

• официальное трудоустройство;

• имеем аккредитацию в Минцифры.

Если вам интересно развиваться на стыке ИБ, архитектуры и работы с бизнесом, будем рады познакомиться.

По вопросам вакансии: Александра Титова - телеграм @alex_titova, почта Aleksandra.Titova@innostage-group.ru

14 августа была выложена новая версия модели Qwen 3.8 27b и 27b-FP8. 12 августа назад была выложена новая версия модели Qwen 3.8-2.4T-A95B и Qwen 3.8-2.4T-A95B-FP8.

Почему это важно для кибербеза? Семейство квен самое популярное семейство среди моделей на hugging face как по количеству скачиваний так и по использованию для построения\файнтюна своих моделей. Россия в этом плане не сильно отличается от мировых тенденций.

Версия на 27 млрд параметров по общим бенчмаркам способностей находится на уровне GLM-5.2 (max), Deepseek V4Pro 0813, GPT 5.6 Luna. Квантованную до FP8 версию можно попробовать запустить на условно домашней rtx 5090 32 Гб

Версия на 2,4 трлн параметров по общим бенчмаркам способностей находится на уровне Muse Spark 1.2, GPT 5.6 Terra, т.е. можно отнести к SOTA моделям . Эта версия FP8 уже потребует профессиональных минимум 16 видеокарт Nvidia B300.

Как обычно хотелось бы понимать насколько эти модели более защищенная и (или) более способная для задач кибербезопасности.

А тут появляются проблемы, официально у новых моделей нет тех репорта, только карточки на hugging face c ссылками в никуда или на весьма ограниченное описание. Каких либо других независимых отчетов по кибербезопасности и safety мне тоже не удалось найти. В части возможностей самой модели можно с допущениями ориентироваться на тест облачной версии модели Qwen 3.8 Max (как аналога Qwen 3.8-2.4T-A95B) от Aikido:
"Qwen rediscovered 26 of 32 CVEs across three runs, for 81.25% pass@3 recall. That's ahead of GPT-5.6-Sol and matches Opus 5, at roughly half the cost".

Можно попробовать ориентироваться на комплексные бенчи:
Terminal‑Bench 2.1 - навыки работы в командной строке, в том числе для задач кибербезопасности (нахождение и закрытие уязвимостей в коде, реверс-инжиниринг бинарных файлов и безопасная настройка доступов).
DeepSWE 1.1 - бенч для навыков агентов по написанию кода, отдельных разделов по безопасности нет, но это навык смежный с написанием кода.

Значимое отличие - Qwen 3.8 27b единственную из актуальных опенсорс общих моделей можно запустить на одиночном устройстве, особенно если на неофициальном квантовании FP4. Тогда как для "соседей" по бенчмаркам (GLM 5.2, Deepseek V4Pro 0813, GPT 5.6 Luna) потребуется кластер (а иногда и не один) профессиональных видеокарт.

Что на текущий момент является аномальным результатом по соотношению (возможности модели в Terminal‑Bench 2.1)/стоимость оборудования. Соотношение сохраняется в DeepSWE 1.1 и нескольких других бенчах .

Будем ждать новых отчетов по этому семейству, пока Artificial Analysis не включил в бенч по затратам Qwen 3.8 27b, поэтому нужно отнестись сдержанно к получившейся аномальной оценке.

Если у кого то есть локальная RTX 5090 и свободное время - поделитесь впечатлениями ;) .

Эксплойт с молоком

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

Меламин - синтетическое органическое химическое вещество, используемое для создания прочных смол, пластика, ламината для мебели и посуды. Казалось бы, где меламин, и где молоко? Дельфин и русалка... Но...

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

Можно принебречь так же, как можно принебречь экранированием апострофа в имени пользователя на сайте парикмахерской. (Вряд ли у нас на районе поселится д'Артаньян или Жанна д'Арк). Но если принебрегли - у нас поселится '; DROP TABLE users; --

Если разбавить молоко бесплатной водой - получим много молока. Но его не примут, так как по азотному тесту содержание белка будет слишком низким. А вот в меламине - 66% азота. Добавляем совсем немного дешевого меламина - и белковый анализатор счастлив!

https://ru.wikipedia.org/wiki/Скандал_с_китайским_молоком_(2008)

Мы, конечно, пилим наш продукт в России, но Atmy (ex-Nebo - карта качества воздуха, приложение и датчики) будет жить и за пределами нашей страны.

И перед релизом бета-сайта Atmy мы столкнулись с вполне себе геморройной проблемой - data residency.

С правилами РФ более-менее разберёмся. А вот что делать с SOC2, GDPR и прочими зарубежными требованиями — вопрос открытый. Каждая юрисдикция хочет своё, и универсального рецепта не видно.

Поэтому спрашиваю: как вы сейчас решаете data residency?

▶ Подняли второй Keycloak.
▶ Купили InCountry или Strivacity. Платим $XXk.
▶ Отказались от рынка.
▶ Держим два Auth0 tenants.
▶ Написали свой router.
▶ Ничего не сделали и живём с риском.

Что из этого — про вас? Или есть свой вариант, которого здесь нет?

Telemax: когда не хочешь держать MAX на телефоне, но есть Telegram

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

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

Мне хотелось третьего варианта: чтобы MAX вообще не было ни на моём телефоне, ни в моём браузере — а переписка при этом приходила туда, где я и так сижу. В Telegram.

Так появился Telemax — мост между MAX и Telegram.

Что понадобится

• Сервер — любая VPS на Ubuntu/Debian. Требования скромные, хватит самой дешёвой.

• Свой Telegram-бот — создаётся за минуту в @BotFather, токен вставляется при настройке. Бот твой, живёт на твоём сервере, никакого общего чужого бота — данные идут только через твою инфраструктуру.

• Telegram-группа с включёнными темами, куда ты добавишь этого бота админом. Она и станет твоим «окном» в MAX.

• Номер MAX, на который мост авторизуется (в том числе если на аккаунте стоит пароль-2FA).

Про безопасность и доступ — два уровня:

• Снаружи бот глухой. На любое сообщение или команду из другого чата (личка боту, чужая группа, куда его попытались добавить) он просто молчит. Работает только внутри твоей группы.

• Внутри группы — разграничение. Обычные участники могут читать и писать (можно спокойно добавить людей в группу, чтобы вести общее обсуждение). А вот команды боту — только для админа.

Честная оговорка: тот, кого ты добавил в Telegram-группу, видит там все MAX-чаты, а не один. Так что доступ к самой группе — вещь чувствитвительная.

В ТГ это выглядит так:

• текст, фото, файлы, голосовые, видео и видео-кружки;

• стикеры — и статичные, и анимированные;

• геолокация и контакты;

• опросы — создание и голосование;

• удаление сообщений;

• реакции;

• пересылка (обычным forward в Telegram — прилетает в MAX с пометкой источника);

• уведомления о звонках (входящий / пропущенный / завершённый — текстом, без передачи звука: для аудио нужен WebRTC, это вне рамок).

Плюс мелочи для удобства: веб-панель со статусом и метриками (приватный доступ), самообновление по кнопке прямо из Telegram, авторизация (включая аккаунты с паролем-2FA) без танцев с бубном.

Из интересного: анимированные стикеры ТГ по умолчанию МАХ не принимает, поэтому они конвертируются в короткие видео - можно завалить максчатланинов своими стикерпаками )

Как развернуть

На чистом Ubuntu-сервере — одна команда:

curl -fsSL https://raw.githubusercontent.com/Trollobot/Telemax/main/install.sh | bash

Дальше скрипт сам поставит Docker, склонирует проект, сгенерирует ключи и по шагам проведёт настройку: попросит токен Telegram-бота (создаётся в @BotFather), сам определит id твоей группы, а в конце прямо в консоли спросит номер MAX и код из SMS. Переключаться в браузер для первого запуска не нужно.

Всё, что дальше (сменить номер, посмотреть логи) — через веб-панель по HTTPS.

Честно про ограничения, чтобы никто не питал иллюзий:

• Это не end-to-end. Переписка идёт через серверы MAX и Telegram — как и в любом обычном мессенджере. Мост ничего в этом плане не «шифрует поверх», он просто переносит сообщения. Если тебе нужен E2E — это не сюда.

• Переписка оседает на твоём сервере — в логах и в истории Telegram-группы. Безопасность этого сервера (доступ, шифрование диска) — на тебе.

• Это неофициально. Проект не связан с MAX, работает поверх твоего собственного аккаунта на твой страх и риск, в том числе в части их правил.

• Сыровато. Один разработчик, живой проект. Но у меня самого крутится и работает.

Открытый код и зову тестить

Специально открытый исходник — чтобы можно было посмотреть, что внутри, и гонять на своём сервере, а не на чьей-то инфраструктуре:

github.com/Trollobot/Telemax

Буду очень благодарен за тесты и замечания — что неудобно, что сломалось, чего не хватает. Issues и Discussions открыты. Сам его допиливаю потихоньку.

Рынок VPN — это рынок недоверия. Как я пытался починить его голосами пользователей

Выбор VPN-сервиса устроен хуже, чем выбор почти любого другого софта. Обзоры «Топ-10 VPN» — это партнёрские ссылки, отсортированные по размеру комиссии. Отзывы на агрегаторах пишут сами сервисы. Нейросети уверенно рекомендуют сервисы, закрывшиеся год назад. А проверить самому можно только одним способом — заплатить и попробовать. Классический рынок лимонов: у продавца информации больше, чем у покупателя, и добросовестным сервисам это вредит не меньше, чем пользователям.

В апреле этого года я сделал каталог, где вместо редакционных обзоров — голоса пользователей: «работает / не работает» в один клик, без регистрации. Сейчас в нём ~140 сервисов и десятки тысяч голосов. Расскажу, что из этого вышло с продуктовой и технической стороны — в первую очередь про то, как заставить краудсорсинговый рейтинг быть честным.

Почему «свежесть» важнее «качества»

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

Накрутка приходит сразу, как только рейтинг начинает что-то значить

Самая интересная часть — антифрод. Как только каталог начал приводить сервисам пользователей, рейтинг попытались накрутить. Показательный эпизод: 173 голоса за 50 минут с пяти IP за один сервис, причём атакующий проходил SmartCaptcha — то есть капча как единственная линия обороны не работает.

Что сработало — скучная математика на уровне модели данных:

• рейтинг считается по уникальным голосовавшим, а не по числу голосов — повторные голоса с того же пользователя схлопываются;

• малые выборки сглаживаются байесовским средним: сервис с пятью восторженными голосами не обгонит сервис с тысячей смешанных;

• аномальные всплески видны на мониторинге, и данные можно откатить точечно.

Вывод, который переносится на любой UGC-продукт: антифрод в модели данных надёжнее антифрода на входе. Капча отсеивает ленивых, а математика делает накрутку бессмысленной — двигать рейтинг с пяти IP просто некуда.

Доверие — двустороннее

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

Что в итоге

Проблема выбора VPN — на самом деле проблема доверия, и решается она не «более честным обзором», а механикой, в которой врать дорого: уникальные голосовавшие, скользящее окно, сглаживание, верификация владельцев. Посмотреть, как это выглядит вживую, можно тут: https://vpn-catalog.online. Про методику подсчёта и антифрод-механику с удовольствием отвечу в комментариях.

Сертификаты минцифры в Firefox Nightly на Android: через adb, без рута

Понадобилось, чтобы сертификату минцифры доверял только Firefox Nightly, а не весь Android.

GeckoView читает /data/local/tmp/<package>-geckoview-config.yaml не только у debuggable-приложений, но и если пакет назначен текущим debug_app. А в конфиге можно задать аргументы запуска Gecko и поднять Marionette.

Поднимаем Marionette

geckoview-config.yaml:

args:
  - --marionette
  - --remote-allow-system-access
prefs:
  marionette.port: 2828

adb shell am set-debug-app --persistent org.mozilla.fenix
adb push geckoview-config.yaml \
  /data/local/tmp/org.mozilla.fenix-geckoview-config.yaml
adb shell chmod 644 /data/local/tmp/org.mozilla.fenix-geckoview-config.yaml
adb shell am force-stop org.mozilla.fenix
adb shell monkey -p org.mozilla.fenix -c android.intent.category.LAUNCHER 1
adb forward tcp:2828 tcp:2828

Кладём сертификаты в cert9.db

Marionette в chrome-контексте даёт привилегированный JS, дальше всё делает nsIX509CertDB. Флаг "C,," для корня, которому доверяем по SSL, ",," для промежуточных: доверия им не надо, они нужны только чтобы собралась цепочка.

Протокол простой, длина:json поверх TCP, клиент пишется за пять минут:

use v5.36;
use IO::Socket::INET;
use MIME::Base64 'encode_base64';
use JSON::PP;

my $s = IO::Socket::INET->new('127.0.0.1:2828') or die $@;
my $j = JSON::PP->new->canonical;
my $id = 0;

sub pkt {
    my ($len, $buf, $c) = ('', '');
    $len .= $c while sysread($s, $c, 1) and $c ne ':';
    $buf .= $c
        while length $buf < $len and sysread $s, $c, $len - length $buf;
    $j->decode($buf);
}

sub cmd ($name, $params = {}) {
    my $body = $j->encode([0, ++$id, $name, $params]);
    print {$s} length($body) . ":$body";
    my $r = pkt();
    die "$name: " . $j->encode($r->[2]) . "\n" if defined $r->[2];
    $r->[3];
}

my @certs = map {
    my ($file, $trust) = split /=/, $_, 2;
    open my $fh, '-|', qw(openssl x509 -outform DER -in), $file
        or die "$file: $!";
    binmode $fh;
    [ encode_base64(do { local $/; <$fh> }, ''), $trust // 'C,,' ];
} @ARGV;

pkt();
cmd 'WebDriver:NewSession';
cmd 'Marionette:SetContext', { value => 'chrome' };

say JSON::PP->new->pretty->canonical->encode(cmd 'WebDriver:ExecuteScript', {
    script => q{
        const cid = "@mozilla.org/security/x509certdb;1";
        const db = Cc[cid].getService(Ci.nsIX509CertDB);
        return arguments[0].map(([b64, trust]) => {
            try {
                const c = db.addCertFromBase64(b64, trust);
                return { ok: true, subject: c.subjectName };
            } catch (e) {
                return { ok: false, error: String(e) };
            }
        });
    },
    args => [ \@certs ],
});

cmd 'WebDriver:DeleteSession';

устанавливем:

perl fenix-cert.pl \
  russian_trusted_root_ca_pem.crt=C,, \
  russian_trusted_sub_ca_pem.crt=,, \
  russian_trusted_sub_ca_2024_pem.crt=,,

# cleanup
adb shell rm -f /data/local/tmp/org.mozilla.fenix-geckoview-config.yaml
adb shell am clear-debug-app
adb forward --remove tcp:2828
adb shell am force-stop org.mozilla.fenix

Проверено на Pixel 5, Android 14, Firefox Nightly 156.0a1.

Видео доступно по ссылке -> https://vkvideo.ru/clip-237277610_456239029

Давайте сегодня поговорим про бумажную безопасность, но не в привычном ее понимании: политики, контроли и комплаенс; а в буквальном смысле - безопасность информации, представленной на бумаге. Сотрудник ФБР (по крайней мере он так представился) на наглядных примерах показывает разницу между шредерами и качеством выполнения их работы.

На сегодня существует 3 типа уничтожителей бумаги: прямые, ромбовидные и конфетти. 
Первые уничтожают бумагу, разрезая ее на ровные полоски. При таком подходе собрать обратно пазл не составляет особого труда и занимает не более 1 часа на восстановление информации. Тоже самое относится и к банковским картам - получить номер карты, ФИО и CVV код займет от силы 1 минуту (30 секунд из которых вы будет искать кончик скотча, чтобы склеить ее обратно).

С ромбовидными сложнее, но восстановление тоже возможно, хотя и занимает намного больше времени. По информации сотрудника, собрать обратно документ составляет около 8 часов.

Самые лучшие, и которые стоят в офисах ФБР (спасибо за подсказку) - это шредеры, которые превращают документ в конфетти. При таком подходе собрать документ обратно не возможно (но тут бы я поспорил). 

Естественно, стоимость бумагоизмельчителей пропорционально растет в зависимости от качества уничтожения документов. С другой стороны, купить шредер ради шредера (первый вариант) - выглядит бездумной тратой денег. К сожалению, не всегда удается донести до закупки почему нужно покупать дорогую вещь, когда существует версии в 10 раз дешевле. 

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

п.с. нас еще учили, чтобы безвозвратно уничтожить документ, его сначала сжигают, а потом просеивают через мелкозернистую сеть. К сожалению, таких устройств еще не существует, поэтому дарю бизнес-идею ;) 

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

ФСТЭК опубликовала методику оценки уровня зрелости в области технической защиты информации, которая затрагивает в том числе значимые объекты КИИ. Документ вводит пять уровней зрелости (от «нулевого» до «верифицируемого») и 21 направление оценки — от управления защитой до применения ИИ. Эксперты отмечают, что методика призвана бороться с недобросовестными подрядчиками и перевести ИБ из разрозненных задач в стратегию, однако её реализацию могут осложнить неясность с проведением оценки и отсутствие должного контроля со стороны регулятора.

Червь Shai-Hulud вернулся в npm и получил настоящую подпись

4 августа в npm вышла новая версия keyv, небольшой библиотеки для работы с хранилищами. Внутри был вредоносный код, и через час он появился в cacheable, flat-cache, cache-manager и остальных пакетах того же автора, а оттуда пошел дальше по чужим учетным записям. Сутки спустя специалисты Aikido насчитали 444 зараженных пакета.

Опознать волну было несложно. Червь складывал краденое в публичные репозитории с описанием «Shai-Hulud: Here We Go Again». Wiz относит образец к тому же семейству, что и прошлогодние.

Атакующий получил доступ к учетной записи мейнтейнера и выпустил зараженные версии от его имени. В них он добавил загрузчик setup.mjs, файл с замаскированным вредоносным кодом и настройку preinstall в package.json. Она заставляла npm запускать загрузчик еще во время обычной установки пакета.  

setup.mjs определял, на какой системе работает машина. Если на ней не было Bun (среды для выполнения JavaScript), то он скачивал ее легитимную версию 1.3.13 из официального списка релизов. Затем через Bun запускался Math_Symbol.js. Этот файл собирал токены, ключи и другие секреты, доступные на машине разработчика или сервере сборки. Используя токены публикации червь выпускал зараженные версии пакетов, которыми мог распоряжаться их владелец. Таким образом червь шел не только по дереву зависимостей, но и по полномочиям мейнтейнеров. Очередной зараженный пакет попадал в следующую среду сборки, получал доступ уже к ее секретам и повторял тот же сценарий.

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

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

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

Как в таком случае защитить цепочку поставки?

Новые версии внешних пакетов лучше вовсе не пускать в сборки в день публикации. Период охлаждения хотя бы на 14 дней дает время заметить подозрительный релиз. Доступ к публичным реестрам стоит пропускать через внутренний репозиторий или прокси, чтобы известная вредоносная версия не попала к разработчикам и в сборочные системы. Подробнее о таких рубежах контроля мы писали в статье «Атаки на цепочку поставки ПО: виды угроз и как с ними бороться».

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

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

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

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

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

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

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

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

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

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

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

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

Полтора года пентестов 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 на практике.

Продуктовые новости 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. Подробнее →

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 и Макс.

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

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

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

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

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

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

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

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

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

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

Агентная проверка безопасности для 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 и рабочий фикс. Ну штош, не привыкать. Неолуддизм и прочий подсчет букв ё, это святое

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

Русскоговорящий хакер использовал 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 | 📝 Хабр | 💙 ВКонтакте

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

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

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

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

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

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

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

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

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

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

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

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. Пользователям рекомендуют заменить токены и проверить недавнюю активность аккаунта.

Источники

• Официальное раскрытие Hugging Face

• The Hacker News

• Исходник fsspec.ReferenceFileSystem

Как 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-адрес, легко случайно отдать злоумышленнику куда более ценную часть своей цифровой жизни.

Всем привет!

Очень много 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 негласных пути взлома.

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

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

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

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

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

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

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

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

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 и Макс.

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

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

Эксперты Arktis компании «Газинформсервис» подготовили отчёт об актуальных уязвимостях и активностях группировок

Во втором квартале Arktis зафиксировала новую волну критических уязвимостей и перераспределение сил киберпреступных группировок. Эксперты проанализировали более сотни публичных CVE, выделили топ-5 наиболее атакуемых продуктов и проследили эволюцию трендовых векторов атак — от эксплуатации атак нулевого дня до массового сканирования корпоративных периметров. Особое внимание уделено географии инцидентов: смещение фокуса злоумышленников на азиатско-тихоокеанский регион и рост шифровальщиков в госсекторе. Arktis также разобрала реальные кейсы реализации и патчинга CVE; составила антирейтинг самых частых логинов и паролей; отметила временные паттерны атак. В заключении представлен прогноз угроз на следующий квартал и практические рекомендации по приоритизации защитных мер.

Весь отчёт можно прочитать по ссылке.

Как работает приватность Monero под капотом

Большинство пользователей думают, что все криптовалюты работают примерно одинаково. Есть кошелек, есть адрес, есть блокчейн, а различия сводятся только к скорости или комиссиям.

На самом деле Monero построен совершенно на другой философии. Если Bitcoin создавался как максимально прозрачная система, то Monero наоборот старается скрыть практически все, что можно скрыть. Из-за этого привычные вещи, которые работают в Bitcoin, здесь просто отсутствуют.

Например, в Bitcoin достаточно открыть любой blockchain explorer, вставить адрес и увидеть его баланс, историю переводов и все входящие транзакции.

В Monero так сделать нельзя.

Когда вы отправляете XMR, сеть не использует постоянный адрес получателя. Вместо этого для каждой транзакции автоматически создается одноразовый stealth address. Со стороны кажется, что средства ушли вообще на новый неизвестный кошелек, хотя на самом деле они принадлежат тому же владельцу. Если человек получит тысячу переводов, в блокчейне появится тысяча разных адресов, и понять, что все они принадлежат одному пользователю, практически невозможно.

Но это только первый уровень защиты.

Следующая особенность - Ring Signatures. Представьте, что у Bitcoin каждая транзакция показывает, какой именно выход был потрачен. В Monero этого нет. Перед отправкой кошелек автоматически подбирает несколько похожих выходов из блокчейна и объединяет их в одну группу. Проверить корректность подписи можно, но определить, какой из участников группы действительно потратил монеты, уже нельзя. Для наблюдателя все выглядят одинаково вероятными.

Даже если скрыть отправителя и получателя, остается еще одна проблема - сумма перевода. В Bitcoin она всегда видна. В Monero для этого используются Ring Confidential Transactions и Bulletproofs. Сумма полностью скрывается, но при этом сеть все равно может математически доказать, что никто не создал новые монеты из воздуха и баланс системы остался корректным.

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

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

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

Представлен проект «Контекстные бомбы: остановка ИИ‑атак на корню». «Теперь ИИ‑агенты могут самостоятельно проводить сложные кибератаки: получив доступ к базе, самые сильные модели могут повысить свои привилегии и похитить данные за считанные минуты. Модули Canary — ресурсы‑приманки, которые мы размещаем для обнаружения злоумышленников, — надёжно обнаруживают этих агентов в действии, но обнаружение атаки — это не то же самое, что ее предотвращение. Поэтому мы попробовали нечто более амбициозное: контекстную бомбу — короткий фрагмент текста, спрятанный в канарейке, который активирует защитные механизмы ИИ‑агента и останавливает его на корню. Контекстная бомба — короткий фрагмент текста, предназначенный для активации защитных механизмов атакующих ИИ‑агентов, размещаемый непосредственно на пути их атаки», — пояснили в команде Tracebit Research.

Эффективность этого проекта может варьироваться в зависимости от поставщика модели. Мы тестировали контекстные бомбы на пяти перспективных моделях, выполняющих атаку «красной команды» в реалистичной среде AWS. Развёртывание одной контекстной бомбы внутри среды (в качестве секрета AWS) оказало огромное влияние на остановку атакующих ИИ-атак. Например, эскалация привилегий администратора снизилась с 57% запусков до 5%.

Проект tlosint-vm - виртуальная машину от Tracelabs OSINT, которая проверяет тысячи открытых источников по запросу:

• сервис специально создали для соревнований OSINT‑исследователей и поиска пропавших пользователей в сети;

• готовый стек: Shodan CLI, Sherlock (поиск по логинам и юзернеймам), PhoneInfoga (разведка по номерам телефонов), SpiderFoot и sn0int (автоматизированные OSINT‑фреймворки), theHarvester и h8mail (email), Sublist3r (поддомены), exiftool и steghide (метаданные и стеганография);

• проработана приватность — как только пользователь выходит из сервиса, то система чистит все данные и куки;

• внутрь также вшили хранилище Obsidian, где можно оставлять заметки во время поиска;

• без ограничений, открытый проект, легальный поиск по открытым источникам.

Innostage PAM обновлен до версии 1.7.0

30 июля в 11:00 на вебинаре расскажем и покажем, что нового появилось в Innostage PAM. Управление привилегированным доступом 1.7.0:

👍 улучшение функциональности работы с RDP;

👍 больше прозрачности при входе по сертификатам, смарт-картам и токенам;

👍 новые возможности автоматизации при работе с SSH-ключами;

👍 улучшения защиты данных и хранения событий.

Отдельно расскажем о развитие модуля поведенческой аналитики, над которым работает команда Innostage PAM.

Присоединяйтесь, чтобы увидеть обновления версии в действии и задать вопросы экспертам.

Регистрация по ссылке

Дата: 30 июля, 11:00 - 12:00

Формат: онлайн

Старт третьей рубрики ИТ-кроссворда уже через 30 минут 🦖

В 12:00 по московскому времени открываем новую рубрику ИТ-кроссворда — «Безопасность ML и AI». В публикации вас будут ждать вопросы об использовании ML в ИБ и новых типах угроз.

Зарегистрироваться →

👉 Отвечать на вопросы можно с 12:00 до 18:00 (МСК). Среди призов — комплекты эксклюзивного мерча Selectel и бонусы на аренду серверов.

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

Как отключить Google и Apple ID и не сломать авторизацию для пользователей

Привет! Я Александр Бондаренко, руководитель проектной группы в Далее. С сегодняшнего дня кнопка «Войти через Google» на сайте может стоить от 500 до 700 тысяч рублей. Всё потому, что 7 июля вступает в силу Федеральный закон № 199-ФЗ — поправки в КоАП, по которым за авторизацию пользователей через иностранные сервисы владельцы сайтов несут административную ответственность.

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

Коротко о законе: требование идентифицировать российских пользователей через российские сервисы действует с декабря 2023 года (149-ФЗ). В список приоритетных способов входят номер телефона РФ, «Госуслуги» (ЕСИА), единая биометрия или сервис российского гражданина или компании — например, VK ID, Яндекс ID, Сбер ID. С 7 июля у требования появилась статья в КоАП (13.55, 199-ФЗ от 26 июня) — штраф до 700 тысяч рублей для юрлиц.

Авторизация через Google и Apple ID — очевидная часть, но список шире. Sign in with Apple часто появляется просто потому, что Apple требует его для iOS-приложений. На старых проектах нередко остается Facebook Login (принадлежит Meta, признанной в России экстремистской организации). Реже встречаются GitHub, Discord и Microsoft / Azure AD — обычно в сервисах для разработчиков, игровых проектах и корпоративных SSO.

Как искать в коде

Механизмы авторизации есть не только на главной при входе, но и при регистрации, восстановлении пароля, в мобильном приложении и API для партнеров.

Для Passport.js проверьте passport-google-oauth20 и passport-apple в package.json, для OmniAuth — omniauth-google-oauth2 в Gemfile, для Firebase Auth — providers в конфиге. В мобильных сборках обратите внимание на GoogleSignIn в Podfile и play-services-auth в build.gradle.

Просканируйте репозитории через grep или поиск IDE по строкам accounts.google.com, appleid.apple.com, facebook.com — так часто находятся забытые интеграции.

Отдельно стоит заглянуть в консоли провайдеров — Google Cloud Console, Apple Developer, GitHub OAuth Apps. Кнопку в интерфейсе можно убрать, но пока приложение зарегистрировано в консоли и redirect-URI активен, эндпоинт технически остается рабочим.

Как перейти на российские сервисы и не потерять пользователей

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

1. Подключить и протестировать российский способ: SMS, VK ID, Яндекс ID, Сбер ID или «Госуслуги».

2. Предложить авторизованным пользователям привязать новый способ входа и заранее предупредить о дедлайне.

3. Тем, кто не успел, предоставить восстановление через поддержку с подтверждением личности.

4. После миграции отключить иностранного провайдера, удалить OAuth-приложение в консоли, очистить GOOGLE_CLIENT_SECRET из .env и хранилища секретов.

5. При необходимости инвалидировать активные JWT и refresh-токены, выданные через Google.

6. Обновить Политику обработки персональных данных.

3 вопроса, которые пока остаются открытыми

1. Что считать иностранным сервисом. Кнопку входа через Google меняем точно. А вот использование Gmail как адреса электронной почты без OAuth, по мнению большинства юристов, под действие закона не подпадает: значение имеет способ подтверждения личности, а не почтовый адрес.

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

3. Что с сайтами иностранных компаний в зоне .ru. Закон адресован владельцам сайтов без разделения по юрисдикции регистрации. Судя по формулировкам, ключевой критерий — наличие российской аудитории, а не страна регистрации компании.

Пишите в комментариях, если я не упомянул какие-то подводные камни, и подписывайтесь на мой тг-канал про цифровой комплаенс 👌

РБПО по ГОСТ Р 56939—2024: вебинар №30 из 30 — Сертификация процессов РБПО: требования ФСТЭК России, новые стандарты и практика

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Мы добрались до дополнительных (бонусных) вебинаров цикла. Рассмотрим "Сертификация процессов РБПО: требования ФСТЭК России, новые стандарты и практика". На YouTube. Слайды.

Финальный дополнительный вебинар прошёл при участии ведущих экспертов: Дмитрия Шмойлова, Алексея Щербакова и Виталия Вареницы. Участники обсудили практику сертификации, новые национальные стандарты и методику подготовки, опыт компаний, а также подводные камни аудита и преимущества внедрения РБПО.

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

НЕкурс про РБПО

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.

Доброго. Не прошло и года, как я писал статью о mail.ru https://habr.com/ru/posts/940422/ и вот новая. Назвал бы я это фразой "Очередные проделки mail.ru или агрессивное удержание клиентов".

Итак к сути. Достаточно давно к mail.ru привязан мой домен с бесплатной услугой "Почта для домена" от mail.ru. Изначально, к слову, на бесплатном тарифе можно было использовать неограниченное (во всяком случае точно больше 5) почтовых ящиков. Несколько лет назад лимит ящиков на бесплатном тарифе уменьшили до 5. Уменьшил, и так это всё работало у меня до 29.06.2026 примерно до 15:00 мск. Кстати, почтой пользуюсь исключительно через почтового клиента по протоколам pop3/smtp. Ну и сразу напишу, что какой бы то ни было ощутимой нагрузки на сервера не создаю, почтой пользуюсь исключительно я и только я, с одного и того же компьютера и никто другой. Периодичность отправки/получения со всех 5 ящиков примерно 1-2 письма в день, но нередко бывают дни, даже несколько дней с полным отсутствием приёмом/отправкой писем по электронке. Последнее пишу, чтобы было представление о том, создаю ли я вообще какую-либо нагрузку на почтовые сервера.

И, примерно 29.06.2026 ~15:00 мск. в логах почт. клиента появились записи:

29.06.2026, 15:00:00: ******-ERR Net dostupa na vashem tarife. Skachaite prilozhenie VK WorkSpace

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

Самым логичным, в моей ситуации было решение - уйти на сторонний почтовый хостинг. Платный, кстати.Сказано - сделано. В админке аккаунта mail.ru домен был удалён, однако mail.ru написал, что, дескать они его удалят окончательно только через 14 дней.

Тем не менее, начал перепривязывать свой домен для стороннего почтового хостинга, а именно обновил записи DNS домена в частности MX, TXT записи.

Примерно менее чем через час, я уже мог отправлять письма с почтовых адресов своего домена кому бы то ни было, НО вот с получением почты возникли нюансы, а именно: Я могу получать почту со (!)всех почтовых доменов, (!)КРОМЕ почтовых доменов mail.ru - @mail.ru, @inbox.ru, @bk.ru, @list.ru. Этим, кстати, исключается вариант неправильной настройки DNS записей домена, иначе я бы не смог получать почту вообще от кого бы то ни было.

Справедливости ради следует написать, что для смены DNS записей домена у разных хостеров и провайдеров требуется время и происходит это не мгновенно (кстати по личному опыту максимум было несколько часов, вообще), но была информация, что обновление записей может длиться до 3-х суток максимум. На данный момент с момента изменения мной DNS записей домена прошло уже более (!)74 часов, что составляет время более чем трое суток.

Разумеется за это время было написано как обращение к платному хостеру почтового сервера, так и в тех поддержку mail.ru. На последних (mail.ru), по печальному предыдущему опыту я не особо рассчитывал, что практически и оправдало в негативном смысле мои предположения - сразу после обращения от mail.ru получил автоматический ответ с присвоением номера заявки и что они обязательно ответят не более чем через 10 часов. На данный момента с изначального момента обращения прошло более 50 часов, ничего более от них не получил!

Тех. поддержка платного почтового хостинга несколько раз отвечали, сейчас вопрос находится до сих пор в работе, но субъективно это не их вопрос и к ним у меня вопросов нет, ибо с не mail.ru адресов почта доходит без проблем. Более того, как док-во того, что проблема в mail.ru - если я отправляю письмо с одного из @mail.ru почт.серверов на ранее существующий адрес своего домена, когда я хостился в mail.ru - письмо просто не доходит, а если на не существующий адрес - получаю письмо-автоответ, "Ошибка 550 User Not Found", что говорит о том, что сервера mail.ru не обновили информацию о домене.

DDoS-атака не всегда очевидна. Резкий рост нагрузки может оказаться как настоящей атакой, так и вполне легитимным всплеском трафика после рекламной кампании или важного инфоповода. В совместном материале с ITSumma разбираем, как быстро отличить одно от другого, на какие метрики смотреть в первую очередь и какие действия предпринимать в первые минуты после обнаружения проблемы.

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

Отдельное внимание уделяем двум основным моделям защиты — Always-On и On-Demand. Рассматриваем, чем они отличаются, в каких случаях каждая из них эффективнее, а также какие компромиссы приходится учитывать при выборе между постоянной фильтрацией трафика и подключением защиты только во время атаки.