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

Как самописный git-сервер слил приватный код одним HTTP-заголовком

Клиент был уверен, что его код в безопасности — сервер стоит у него, а не в облаке. На практике «приватное» репо открылось без единого пароля.

Ко мне обратился владелец небольшой продуктовой компании — 15 разработчиков, весь код в самостоятельно поднятом Gitea. Логика простая: своё железо, своя сеть, значит безопасно. Формально так и есть, если не забывать обновлять софт.

На аудите я поднял точную копию их версии Gitea на тестовом стенде и прогнал типовые проверки. И наткнулся на свежую уязвимость, о которой уже писали security-исследователи: определённый HTTP-заголовок в запросе заставляет сервер думать, что пользователь уже авторизован. Без пароля, без токена, без единого лишнего клика.

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

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

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

Закрыли проблему в три шага, без покупки нового софта. Обновили Gitea до версии с патчем — бесплатно, час работы. Настроили реверс-прокси так, чтобы он отбрасывал подозрительные заголовки авторизации, если запрос пришёл не изнутри доверенной сети. И включили логирование неудачных и подозрительных попыток входа с алертом в мессенджер — раньше логи просто копились и никто их не смотрел.

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

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

Полный разбор с деталями кейса →

Бесплатный аудит безопасности Сколько стоит взлом Канал в Telegram Канал в MAX

TG @CIOlogia

Русскоговорящий хакер использовал 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

Адриан Мастронарди (занимается созданием и управлением инженерными организациями, стоящими за выпуском ПО) выпустил книгу под названием «Полсекунды». В ней подробно рассматривается попытка создания бэкдора в xz в 2024 году. Книга распространяется бесплатно под (несвободной) некоммерческой лицензией CC, запрещающей создание производных работ.

Публикации про инцидент с xz на Хабре:

• «Можно ли было обнаружить бэкдор xz при более продуманной работе с пакетами в Git и Debian?»

• «Бэкдор в xz нашли из‑за замедления работы sshd в полсекунды».

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

Как настроить TLS в клиенте Python при HTTPS-запросах?

Бывает так, что после обновления OpenSSL часть HTTPS-вызовов к внешним сервисам падает с ошибкой ssl.SSLError. Сейчас разберемся, как настроить Python, чтобы handshake проходил успешно и соединение оставалось безопасным.

После апдейтов OpenSSL часто отключают старые протоколы и слабые шифры — старые серверы не проходят handshake. Решение на клиенте — явно создать ssl.SSLContext, задать минимальную версию TLS и, при необходимости, набор шифров, а затем передать этот контекст в HTTP-клиент (например, httpx).

import ssl
import httpx

ctx = ssl.create_default_context(purpose=ssl.Purpose.SERVER_AUTH)
ctx.minimum_version = ssl.TLSVersion.TLSv1_2
ctx.set_ciphers('ECDHE+AESGCM:!ECDSA:!aNULL:!eNULL')

with httpx.Client(verify=ctx, timeout=10.0) as client:
    r = client.get('https://api.example.com')
    r.raise_for_status()
    print(r.status_code)

В коде мы указываем TLSv1_2 как минимальный порог. Это удобно: если сервер уже поддерживает TLS 1.3, все само заработает на самой новой версии. Но если какой-то внешний сервис еще не успел обновиться, соединение не разорвется, и все продолжит работать на стабильном 1.2. Так мы получаем универсальный код, который не сломается при работе со старыми API.

Для отладки TLS handshake применяйте openssl s_client -connect host:443 -tls1_2 чтобы увидеть, какие шифры поддерживает сервер. Временное ослабление minimum_version даст совместимость, но хуже для безопасности — лучше апгрейдить серверную часть. Сертификаты и ключи храните вне кода (секреты/volumes), не логируйте их, и при работе в контейнерах используйте безопасные механизмы передачи секретов.

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

Всем привет!

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

Проект 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. Закон адресован владельцам сайтов без разделения по юрисдикции регистрации. Судя по формулировкам, ключевой критерий — наличие российской аудитории, а не страна регистрации компании.

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

Представлен открытый сервис NtWARden (Windows Analysis and Research Toolkit), который распознает любые вредоносы и проблемное ПО, даже если эти компоненты находятся глубоко в системе Windows.

Проект NtWARden:

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

• обнаруживает скрытые вредоносы;

• убивает майнеры и трояны;

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

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

• может подключиться к другому ПК и также отслеживать его процессы.

Открытый проект T3MP3ST превращает ИИ‑агентов в системы для поиска уязвимостей в IT‑проектах:

• это мультиагентная система, которая ищет любые уязвимости в сервисах;

• нужно только указать цель и агенты сами проведут разведку, найдут баги и предоставят отчёт;

• результаты — из 104 тестовых задач ИИ нашёл уязвимости в 90% с первой попытки.

• удобный инструмент для изучения кибербезопасности на практике.

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

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

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

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

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

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

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

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