Бесплатный проект email-fake позволяет генерировать одноразовую электронную почту за один клик. Сервис создаёт почтовые ящики, чтобы пользователи могли зарегаться в различных сервисах и получать любые коды доступа без регистрации и получения спама на личную почту.
РБПО по ГОСТ Р 56939—2024: вебинар №06 из 30 – Разработка, уточнение и анализ архитектуры программного обеспечения
Прошёлся сегодня по использованию вайб-кодинга без соответствующих мер контроля результата – Ревью вайб-кода с гнильцой, который притворяется оптимизированным С++ кодом. А теперь продолжим тему, как создавать качественные, надёжные и безопасные приложения. Это всё, кстати, актуально и для веб-кодинга, но, к сожалению, пока мало кто это осознаёт :(
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.6. – "Разработка, уточнение и анализ архитектуры программного обеспечения". Слайды.
Цели шестого процесса по ГОСТ Р 56939—2024:
5.6.1.1 Создание условий для снижения количества возможных недостатков при разработке архитектуры ПО.
5.6.1.2 Уточнение архитектуры ПО в процессе разработки кода.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Народное поверье, что все что дорого - значит качественно, не всегда является правдой. Аналогично можно сказать и про дешевый товар: не всегда он является одноразовым ширпотребом. Однако, в большинстве случаев это соответствует действительности: если цена высока, значит в оборудовании используются качественные и дорогие комплектующие, а также затрачены определенные человекочасы.
С момента покупки нового мультиметра UNI-T UT61B+ я горю желанием поменять родные щупы. Несмотря на китайское происхождение, у них минимальное сопротивление, а замеры они делают достаточно точно и быстро. Единственный существенный минус - их наконечники очень короткие и толстые, что накладывает определенные ограничения на их использование и измерения. Во-первых, когда мы имеем дело с плотной SMD-пайкой в ограниченном пространстве, в том числе с многоножечными чипами, производить измерения не только невозможно, но и опасно, так как можно “закоротить” плату. Во-вторых, на щуп нельзя прикрепить “крокодила”, например, для подачи точечного питания или имитации джампера.
Можно сказать, что проблема “высосана из пальца” и все, что мне нужно сделать - это сходить в магазин и купить подходящие комплектующие. Сказано - сделано: купил, принес домой, хотел начать работу и … не тут-то было. При первичной проверке щупов оказалось, что измерения на них скачут. Вроде качественный компьютерно-бытовой магазин на 3 буквы, а продали ерунду.
Хорошо, идем в синий маркетплейс и выбираем щупы с 36 тысячами отзывов и средней оценкой 4.8 (ну столько-то не накрутят же, верно?). “Оказалось, что показалась”, и замеры как прыгали, так и прыгают. При попытке вернуть товар даже продавец отказался их забирать обратно и предложил их оставить себе с выплатой небольшой компенсации. Я пару раз отказывался, но в итоге просто “забил”: теперь они лежат мертвым грузом и я не представляю, что с ними делать. Если посмотреть отзывы, очень много людей говорят, что провода работают отлично. Мне вот интересно: это мне так повезло или это “нелицензионные” провода и юни-т не хочет с ними работать ;)
В связи с этим я нуждаюсь в помощи и у меня к вам вопрос: посоветуйте, пожалуйста, хорошие провода для тестера, чтобы контакты были тонкими и длинными, с низким (желательно околонулевым) сопротивлением и подходящими под гнезда UNI-T. Заранее благодарю :)
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
Исследователи обнаружили уязвимость, позволяющую украсть деньги с заблокированного iPhone через NFC, если на устройстве активирован режим экспресс-транспорт и привязана карта Visa. В эксперименте со смартфона блогера Маркуса Браунли списали $10 тыс., обманув систему оплаты проезда. Apple и Visa заявили, что массовое мошенничество маловероятно, однако пользователям советуют отключить использование Visa для транспортных платежей на iPhone.
РБПО по ГОСТ Р 56939—2024: вебинар №05 из 30 – Управление недостатками и запросами на изменение программного обеспечения
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.5. – "Управление недостатками и запросами на изменение программного обеспечения". Слайды.
Цели пятого процесса по ГОСТ Р 56939—2024:
5.5.1.1 Обеспечение управления недостатками ПО.
5.5.1.2 Обеспечение управления запросами на изменение ПО.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Собрал в одном месте проверенные сервисы и инструменты для тех, кому важна приватность в сети.
Репозиторий: Awesome Anonymity
Каждый раз, когда нужно зарегистрироваться без слива личных данных приходится гуглить одно и то же. Этот список — попытка собрать всё в одном месте.
PR в репо приветствуются, если это не реклама.
Аватар: легенда о слитом мультфильме
На днях в сети появилась полная версия мультфильма «Легенда об Аанге: Последний маг воздуха» — за полгода до официального релиза, который должен был состояться 9 октября. Такое мы осуждаем, но мультфильм получился достойным.
Что произошло 🥷
Все началось 12 апреля, когда в сети появились фрагменты из будущего мультика — до этого было известно только его название и дата релиза; не было даже трейлера.
Есть две версии, как это вышло — обе неофициальные: компании Paramount, Nickelodeon и Avatar Studios пока что не прокомментировали утечку.
Серьезная версия: к краже причастна группировка PeggleCrew. Она решила отомстить Paramount за то, что та отказалась показывать мультфильм в кинотеатрах и решила выпустить его только на платформе Paramount+, доступной в основном в США.
Как пишут СМИ, группировка получила доступ к серверам Nickelodeon, откуда и смогла загрузить мультфильм, который еще был в стадии постпродакшна.
Забавная версия: пользователь ImStillDissin, опубликовавший фрагменты, сообщил, что получил фильм случайно по электронной почте от Nickelodeon.
🤷♀️ Где правда — мы не знаем. Но художники и аниматоры мультфильма очень недовольны. Уверены, что и студии тоже.
Мне не нравится, когда люди используют ужасное решение Paramount для того, чтобы оправдывать утечку. <…> Это невероятное неуважение по отношению к тем усилиям, которые все художники вложили в этот фильм.
Джулия Шоэль, художник-аниматор
А что пираты: ImStillDissin заявил, что не ожидал такого резонанса. Российские кинотеатры сообщили, что будут показывать мультфильм уже в апреле — хотя он был слит в качестве, неподходящем для показа на больших экранах.
Такое уже было:
1️⃣ Одна из самых громких утечек фильмов случилась в 2009 году — хакеры слили в сеть «Люди Икс: Начало. Росомаха» за месяц до релиза. В этой версии отсутствовала большая часть спецэффектов и некоторые сцены. Кстати, случилось это тоже в апреле — первого числа, что изначально посчитали шуткой. Сообщалось, что утечка произошла не из-за внешнего взлома, а из-за недостаточной защиты передачи превью-версии фильма.
2️⃣ В 2014 году у Sony Pictures украли и слили в сеть несколько фильмов, среди которых были «Ярость» и «Интервью» — про лидера КНДР. Официально ФБР сообщило, что за взломом стояли хакеры из КНДР, которые были недовольны выходом фильма, однако эта версия оспаривалась специалистами по кибербезопасности.
3️⃣ Квентин Тарантино чуть не отказался от съемок фильма «Омерзительная восьмерка» из-за утечки сценария в 2014 году. Когда он был готов, PDF-файл с ним начал распространяться в сети — скорее всего из-за человеческого фактора. Фильм все же сняли, но после того, как сценарий был переписан.
Что посоветуем: не отправляйте копии фильмов и сценариев по электронной почте и не злите фанатов 😉
❗ Фильм «Как получить доступ ко всему: реверс-инжиниринг» в сеть мы слили самостоятельно, смотрите его на любых удобных для вас платформах бесплатно.
Ищем эксперта в команду AppSec, который будет сопровождать ИТ-команды на всех этапах разработки, моделировать угрозы, анализировать безопасность архитектуры проектов и помогать внедрять новые ИБ инструменты и практики.
Что важно:
Знать основы информационной безопасности: протоколы, средства защиты информации, их назначение, инфраструктуру PKI и принципы работы криптографических алгоритмов
Уметь находить и устранять веб-уязвимости из OWASP Top 10, OWASP Mobile Top 10 и CWE Top 25
Иметь опыт практического анализа защищенности и анализа архитектурной документации от двух лет
Знать технологии построения прикладных систем, в том числе с использованием микросервисов и контейнеризации
Всем привет!
В интересное время мы живём конечно. В рабочий чат коллега присылает сообщение:
Общий привет! на заметку:
https://www.comss.ru/page.php?id=20317
Антивирус Dr.Web обнаружил сторонний код в зависимостях Visual Studio Code.
Суть в том, что Microsoft, с какого-то, пропустила в дистрибутив VSCode с версии 1.116.0 protestware - это вид вируса, который при определённых условиях, начинает показывать разные политические тексты на экране. DRWeb, неожиданно конечно, но респект!
MICROSOFT, WTF?
Я попросил OpenCode найти текст на русском в указанной зависимости в VSCode (у меня как раз 1.116) и знаете что, он нашёл!
В общем, если у вас версия VSCode ниже 1.116, то пока не обновляйтесь, а если уже обновились, то используйте мой патч:
https://github.com/Chumikov/vscode-es5ext-patch
В репо также описал как вручную всё исправить. Поделитесь этим с коллегами и друзьями!
Мой telegram.
Начал потихоньку разбирать то самое чудо-юдо из одного из прошлых постов. И, честно говоря, в этот раз оно решило не сопротивляться — на сайте производителя неожиданно нашлась вполне вменяемая документация. Причём не просто общие слова, а с техническими деталями и даже распиновкой.
Выяснилось, что всё довольно прозаично: красный — это KL.30, чёрный — земля, а белый — тот самый загадочный третий провод, который раньше вызывал больше всего вопросов. Им оказался KL.15 — не просто «ещё один плюс», а линия, на которую питание подаётся только при включённом зажигании. То есть, в отличие от постоянного питания на KL.30, этот провод живёт своей жизнью: есть зажигание — есть питание, нет зажигания — тишина: всё, что не должно сажать аккумулятор на стоянке, вешается именно туда.
В ходе изучения устройства я долго пытался понять, как же оно осуществляет связь с оператором: где GSM сим-карта или тут все по новомодной технологии Mesh? :) Ну или мне стоит искать дополнительный модуль связи где-то у себя под задним сидением? Но нет — всё оказалось куда компактнее. Если верить документации на УВЭОС, внутри вполне взрослый набор: GSM, UMTS и LTE в нескольких диапазонах, а тип SIM-карты – резидентная (несъемная) многопрофильная SIM-карта, установленная на печатную плату по SMD-технологии.
И действительно, если присмотреться, то “симка” у нас в форм-факторе WSON 8, и даже обведена соответственно. Поэтому, одним из следующих шагов может быть ее выпаивание и установка в полнофункциональный мобильный аппарат: узнать оператора связи, номер телефона, есть ли безлимитный интернет и звонки на отличные от экстренных служб номера.
А то кто знает… ну вы поняли ;)
Про остальные составляющие расскажу в будущих постах, а вы пока можете делать ставки, что тут еще есть интересного.
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
Почему “лучший курс” часто оказывается самой дорогой ошибкой
В криптообмене и цифровых переводах пользователи часто ориентируются на самый очевидный показатель, это курс.
Логика понятна: если в одном месте курс выше, а в другом ниже, значит выгоднее там, где цифра выглядит лучше. На практике именно здесь и начинается одна из самых частых ошибок.
Проблема в том, что «лучший курс» почти никогда не существует отдельно от условий, по которым этот курс вообще доступен. Пользователь видит красивую цифру, но не всегда замечает всё, что идёт рядом: комиссии, скрытые ограничения, ручную обработку, задержки, минимальные суммы, требования к верификации, плавающий итог или просто неочевидный порядок расчёта.
В итоге человек выбирает не самый выгодный сценарий, а самый привлекательный заголовок.
Особенно часто это происходит там, где пользователь сравнивает сервисы по агрегатору, таблице или просто по первым цифрам на экране. Визуально разница может выглядеть как очевидная выгода, но после оформления заявки выясняется, что реальный результат уже другой.
Иногда «лучший курс» ломается на комиссии, которая появляется позже. Иногда на спреде между заявленным и финальным расчётом. Иногда на том, что деньги приходят дольше, чем ожидалось, и пользователь теряет не на цифре, а на времени.
Есть и более неприятный сценарий: курс сам по себе хороший, но путь к нему слишком хрупкий. Например, заявка обрабатывается вручную, окно фиксации короткое, правила обновляются в процессе, а любое отклонение по сумме или времени уже меняет итог.
С точки зрения интерфейса всё выглядит честно: цифра показана. Но с точки зрения пользователя это часто превращается в когнитивную ловушку. Он уже увидел «выгоднее» и перестал смотреть на остальное.
Поэтому в финансовых и криптосценариях цена ошибки почти всегда выше, чем кажется. Пользователь сравнивает курс как витрину, хотя по факту ему нужно сравнивать весь маршрут операции: что спишется, сколько дойдёт, когда дойдёт, при каких условиях и насколько предсказуем будет итог.
Именно здесь появляется главный парадокс: иногда курс чуть хуже на старте, но итоговая операция оказывается выгоднее, быстрее и спокойнее. А иногда «лучший курс» на экране это просто самый дорогой способ ошибиться.
Если смотреть шире, проблема не в самом курсе. Проблема в том, что пользователь принимает решение по одному параметру в сценарии, где значимы сразу пять или шесть.
Поэтому «лучший курс» в цифровых переводах — это не гарантия выгоды, а всего лишь одна из переменных. И без контекста она часто работает против самого пользователя.
В десятках плагинов WordPress обнаружены бэкдоры, затронувшие сотни тысяч сайтов
В апреле 2025-го сотни тысяч сайтов на WordPress оказались скомпрометированы через обновление плагинов.
Исследователь Austin Ginder раскопал классическую supply chain attack — но с одним нестандартным элементом:
адрес командного сервера хранился в смарт-контракте Ethereum.
Разберём, что тут действительно интересно с технической точки зрения, а что — просто грамотная упаковка старых приёмов.
Что произошло — хронология
В начале 2025 года анонимный покупатель на Flippa приобрёл компанию Essential Plugin — разработчика популярных WordPress-расширений.
По данным Ginder Security, суммарная установочная база превышала 200 000 сайтов.
Спустя несколько месяцев в обновление были внедрены изменения:
добавлен файл wp-comments-posts.php (мимикрия под стандартный wp-comments-post.php)
модифицирован wp-config.php — добавлена загрузка внешнего payload
Бэкдор не активировался сразу.
Он находился в спящем режиме, а затем был запущен спустя несколько месяцев.
📌 Это важный момент: атака была рассчитана на доверие и время, а не на мгновенный эффект.
Почему Ethereum — это не «блокчейн ради хайпа»
Обычно инфраструктура C2 (command & control) строится на:
доменах
IP-адресах
➡️ Их можно заблокировать — и атака теряет управление.
Здесь подход другой:
бэкдор запрашивает адрес C2 из блокчейна Ethereum.
Что это даёт атакующему
Неубиваемость Нельзя «отключить» Ethereum или удалить контракт
Мгновенная ротация Новый C2 публикуется через транзакцию
Анонимность Данные публичны, но владелец кошелька — нет
💡 Важно: это не новая техника.
Подобные схемы фиксировались ещё в 2018 году (например, в исследованиях Akamai),
но их использование в массовых supply chain атаках — редкость.
Три грабли, которые сделали атаку успешной
1. Рынок плагинов — это дикий запад
WordPress не верифицирует смену владельца плагина.
Купил проект → получил:
доступ к репозиторию
доступ к обновлениям
доверие пользователей
Без дополнительных проверок.
📊 По данным WPScan:
в 2024 году было более 1500 уязвимостей в плагинах.
Но здесь уязвимости не нужны.
Ты сам становишься разработчиком.
2. Автообновления включены по умолчанию
Большинство сайтов обновляют плагины автоматически.
Что это означает на практике:
никто не смотрит diff
никто не читает код
никто не проверяет изменения
Бэкдор приезжает вместе с «фиксами безопасности».
3. Мимикрия под системные файлы
wp-comments-post.phpwp-comments-posts.php
Разница — одна буква.
И этого достаточно.
Это не уязвимость системы.
Это social engineering на уровне файловой структуры.
Что реально можно сделать
Для владельцев сайтов
Отключить автообновления плагинов
Проверять changelog перед обновлением
Мониторить файловую систему (OSSEC, Tripwire)
Использовать WAF с анализом исходящих запросов
Для разработчиков плагинов
Подписывать релизы (GPG)
Публиковать хэши сборок
Включить 2FA
Ввести обязательный code review
Для WordPress как платформы
Верификация смены владельца плагина
Флаги «подозрительных обновлений» (смена автора, нетипичные файлы, резкие изменения структуры)
Если честно
Атака выглядит сложной, но по сути:
supply chain через покупку — известный вектор
Ethereum как C2 — не новая идея
спящий режим — вопрос дисциплины
👉 Это не прорыв. Это комбинация рабочих техник.
Главный вывод
Проблема не в блокчейне.
И не в конкретной уязвимости.
Проблема — в экосистеме WordPress:
полное доверие к обновлениям
отсутствие контроля ownership
слабая прозрачность изменений
Вопрос к сообществу
Кто сталкивался с аудитом WordPress-плагинов при покупке бизнеса?
Есть ли вообще практика:
code audit перед M&A
проверка supply chain рисков
анализ истории изменений
Или всё до сих пор держится на доверии?
Вебинар: от Pod Security Standards к полноценной модели безопасности подов в Deckhouse Kubernetes Platform
Pod Security Standards ограничивают privileged-контейнеры, hostPath и capabilities. Однако реальные риски безопасности шире. Неконтролируемые registry, отсутствие лимитов на ресурсы, образы без фиксированных тегов, контейнеры без health-проверок — всё это расширяет поверхность атаки.
28 апреля в 12:00 на вебинаре Deckhouse Академии разберём, как выстроить полноценную модель безопасности пода средствами Deckhouse Kubernetes Platform:
как SecurityPolicy и OperationPolicy в DKP закрывают то, что PSS оставляют открытым;
как Gatekeeper превращает декларативные политики в версионируемый код, который можно проверить в CI/CD;
почему платформенный механизм проще и надёжнее подхода «договариваться о безопасности с каждой командой».
Зарегистрироваться на вебинар →
Готовимся к ЦТФ на примере задачи «Киберремонт киберпанциря»
ЦТФ (CTF, Capture the Flag, «Захват флага») — это соревнования, на которых в течение нескольких дней вы отвлекаетесь от рабочей рутины и пытаетесь найти «флаг» — специальную секретную информацию, которая зашита в разработанные для игры системы, заполучив которые можно только через взлом. Потому задания на соревнованиях ЦТФ имеют странные названия и не менее странные описания, ведь игра должна вырвать вас из рутины рабочих тасок, а не вогнать ещё сильнее.
При этом задачи на турнирах охватывают разные области кибербезопасности: поиск веб-уязвимостей, реверс-инжиниринг, расследование инцидентов и т.п. На примере сложной задачи «Киберремонт киберпанциря» на Альфа ЦТФ коротко пройдёмся, какие нужны знания и как думать, чтобы решать задания. Разбор пригодится 25 апреля, когда состоится Альфа ЦТФ 2026 с призовым фондом 3 100 000 рублей!
⚡️ Выбирайте трек, объединяйтесь в команду или участвуйте индивидуально — и оставляйте заявку на сайте.
Описание задачи:
«Вы прогуливаетесь вдоль берега и вдруг видите на песке цифры 404, а неподалёку от них — огромную черепаху. Она с грустью рассказывает, что недавно сломала свой киберпанцирь.
Теперь везде, где бы ни прошла Тортилла, остаются надписи Error 404, Page not found или Server is unavailable. Помогите черепахе починить покров: для этого разберите и заново соберите в правильном порядке все микросхемы.
Черепаха рассылала всем знакомым мастерам ссылку на схему верной сборки чипов в панцире с помощью этого сервиса — но увы, ни один ремонтник не откликнулся, а ссылка уже давно протухла.
В данной задаче нам необходимо подобрать необходимую комбинацию чипов (на панцире), чтобы получить флаг, а из условия известно, что изображение с данной комбинацией уже существовало и у изображения есть уникальный хэш картинки.
У этой задачи есть два решения.
№1. Достать картинку из кэша, используя инструменты фаззинга. Фаззинг — перебор директорий, файлов, скрытых и служебных ресурсы, HTTP-запросов посредством различных инструментов вроде Param Miner, ffuf или Webalizer. Подобные инструменты хороши тем, что предоставляют статистику по всем событиям веб-сервера, например, по переходам на Телеграм-бот. Далее найти закэшированное изображение — дело техники.
Читайте статью Основы безопасности веб-приложений: краткий «курс» по выявлению уязвимостей из которой подробнее узнаете о фаззинге и многих других инструментах, используемых для проверки безопасности веб-ресурсов.
№2. Второе решение — короткое — использовать Burp Suite, платформу для тестирования безопасности веб-приложений (о нём также рассказывали в статье выше). Воспользовавшись Burp Suite можно обнаружить, что токен JWT подписан с использованием общеизвестного секретного ключа HMAC. Через JWT Decoder генерируем токен для пользователя admin и получаем доступ к админской сессии. Готово.
Для решения подобных задач и успешного участия в Альфа ЦТФ вам потребуется сочетание навыков из областей Web Security и General IT.
1. Тестирование веб-приложений (Web Security):
Фаззинг (Fuzzing): умение работать с инструментами перебора для поиска скрытых файлов, директорий и забытых бэкапов в кэше.
Работа с прокси-инструментами: владение Burp Suite (или OWASP ZAP) для перехвата и анализа HTTP-трафика, подмены параметров и поиска уязвимостей в логике приложения.
2. Криптография и аутентификация:
Работа с JWT (JSON Web Tokens): понимание структуры токена, умение декодировать его и проверять на слабые методы шифрования (например, использование стандартных ключей HMAC).
Манипуляция сессиями: навык подделки токенов для повышения привилегий (например, получение прав admin).
3. Общие технические знания:
Анализ условий: умение находить в тексте задания «зацепки» (упоминание протухших ссылок, хэшей или специфических ошибок вроде 404).
Инструменты разработчика (DevTools): базовый навык просмотра кода страницы, сетевых запросов и хранилища.
⚡️ Участвуйте в Альфа ЦТФ — ждём заявки на сайте:)
РБПО по ГОСТ Р 56939—2024: вебинар №04 из 30 – Управление конфигурацией программного обеспечения
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.4. – "Управление конфигурацией программного обеспечения". Слайды.
Цели четвёртого процесса по ГОСТ Р 56939—2024:
5.4.1.1 Осуществление уникальной идентификации ПО, документации на ПО, других элементов, подлежащих отслеживанию в рамках управления конфигурацией ПО (элементов конфигурации).
5.4.1.2 Контроль реализации изменений ПО, документации на ПО, других элементов, подлежащих отслеживанию в рамках управления конфигурацией ПО (элементов конфигурации).
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
P.S. При разработке регламента идентификации ПО (версий ПО, модулей ПО) можно оттолкнуться от ГОСТ 19.103—77 "Единая система программной документации. Обозначение программ и программных документов".
Задал вопрос про безопасность MAX? Получи бан!
На днях вопрос безопасности мессенджера MAX снова всплыл в новостях. Как я понял, изначальным источником стала новость о результатах Bug Bounty, в рамках которой принимались отчёты о проблемах безопасности (на Хабре об этом тоже писали). Видимо, эта новость распространялась как-то не так. В связи с чем в Positive Technologies вышел пост с комментарием на эту тему. Этот пост был репостнут в канале "Заметки VMщика" с комментарием (ссылка на комментарий):
Хейтеры понесли статистику по багбаунти MAX с комментариями “посмотрите, какой MAX уязвимый”. 🤦♂️🤷♂️ Пипл хавает.
Я задал вопросы к этому комментарию:
"MAX устранил уязвимости и сделал это быстрее, чем ими воспользовались злоумышленники" - Это чья позиция: платформы багбаунти? Откуда у платформы эта информация? Разве проверка фикса уязвимости и уж тем более вопросы использования уязвимостей злоумышленниками - задача платформы?
Почему бы не раскрыть данные какие были уязвимости? Раз их всё равно уже нет (исправили). Тем более некоторые компании так делают (подробнее в статье Опыт zVirt на Standoff Bug Bounty: какие уязвимости нашли и как мы их исправили)
Или платформа багбаунти просто транслировала позицию МАХ? А была ли верификация этой информации, учитывая, что позиция разработчиков МАХ в вопросах безопасности вызывает вопросы. Например, по ситуации со странными запросами и доступам к части файлов.
После чего мой комментарий в канале исчез. А сам я оказался заблокирован. И вот тут интересен момент. Автор этого канала нередко выступает модератором в дискуссиях на конференциях по кибербезу. Что можно узнать из его другого канала "Управление Уязвимостями и прочее" (пост раз, пост два).
Что же такого было в моих вопросах, раз они вызвали настолько болезненную реакцию у человека, опытного в дискуссиях по кибербезу? И можно ли трактовать эту ситуацию иначе, чем борьба с инакомыслием? Интересно: сколько ещё каналов разных блогеров-безопасников могут так же однобоко подавать MAX (в стиле: "о MAX - хорошо или никак")?
UPD: 15.04.2026 автор каналов "Заметки VMщика" и "Управление Уязвимостями и прочее" сделал пост со своим видением ситуации (спасибо @ancotirза наводку). Скриншот прикладываю ниже. Видимо, автор считает, что не нужно читать\анализировать исходный пост перед репостом в свой канал (даже когда он используется как обоснование его позиции). Перефразируя старый мем (см мопед не мой, я просто разместил объяву): пост не мой, я просто репостнул.
UPD_2: дополнил свой пост комментарием.
Бойтесь Данайцев, ПО приносящих
Ситуация с сервисами, которые вроде как не запрещены в России, но замедлены, породила новые опасности для информационной безопасности. Так как блог мы ведём в первую очередь для наших пользователей, то напомним о «граблях» в приложениях, вроде как облегчающих жизнь.
Telegram — тот редкий случай, когда компания раскрывает код клиентской части, что позволяет сторонним разработчикам делать «форки» — версии, которые работают с основным сервисом, но могут иметь дополнительные функции. Одним из таких приложений стала «Телега», которая обещала спокойную работу с замедленным Telegram. Вот только первое же расследование показало, что трафик она отправляет на сторонние серверы, а возможно, ещё и читает сообщения (в норме этого не должно быть). Скоро сервис Павла Дурова опомнился и стал помечать аккаунты, которые используют сторонние клиентские приложения. А потом магазины приложений удалили «Телегу» как потенциально опасную.
Финал истории? Нет, во-первых, «Телега» по-прежнему рекламируется в выдаче как безопасный мессенджер — не все же читают новости по кибербезопасности. Наверняка у вас стоят расширения к браузеру, которые облегчают жизнь. Но в любой момент добросовестный разработчик может продать их, и неизвестно, кто получит доступ к вашим данным.
Любое приложение может быть небезопасным. И проверки в магазине приложений не всегда выявят бэкдоры, через которые хакеры получат доступ к нему. Но ещё хуже с приложениями, которые вы скачиваете напрямую из интернета. Каждый раз стоит помнить, что механизмы защиты любой ОС имеют свои пределы.
Приложения крупных производителей тоже могут иметь уязвимости: Apple в марте 2025 года предупредила о критической уязвимости в своей хвалёной iOS. Но, в отличие от мелких производителей, большие компании имеют возможность анализировать новое ПО, искать в нём уязвимости и предлагать патчи для их устранения.
Так что помните, что безопасность не обеспечена по умолчанию: стоит внимательно относиться к используемым сервисам и читать наш канал, чтобы узнавать о самых серьёзных опасностях (и самых больших возможностях) мира технологий.
Что это был за черновик и как он стал рекламой онлайн-казино
В пятницу тысячи (не преувеличиваем) каналов поделились сообщением, которое начиналось с красной надписи черновик: — а точнее, с трех эмодзи, которые ее и составляли. После нее каналы, в том числе крупных и известных брендов, соревновались в юморе: кто интереснее подаст свой черновик. Мы — в том числе 😅
На первый взгляд — безобидный флешмоб. На деле — тысячи каналов бесплатно прорекламировали онлайн-казино, сами того не подозревая. Рассказываем, как это получилось.
1️⃣ Когда вы создаете пак эмодзи в Telegram, его можно назвать как угодно. Предположим, «Котики». Вы добавляете туда прикольные картинки с котятами, делитесь с друзьями, потом это подхватывают каналы — и вот ваши котики везде.
Но у владельца эмодзи-пака есть возможность переименовать его в любой момент. То есть, например, когда он уже установлен у тысяч пользователей и им продолжают делиться, название может внезапно измениться на «Котики — не очень, песики — огонь». При этом короткое имя (ссылка на добавление пака) остается тем же.
2️⃣ В пятницу так и произошло. Пак из трех эмодзи изначально назывался просто «ЧЕРНОВИК», его начали активно распространять по каналам — копировать и вставлять, не подозревая о планируемом скаме.
Спустя время он был переименован в «ЧЕРНОВИК [упоминание канала] (ПОДПИШИСЬ)». Упоминаемый канал принадлежит некому «социальному казино» (как они сами себя называют), которое якобы бесплатно раздает деньги, но на самом деле через различные шаги уводит на платформу стандартного онлайн-казино. За несколько дней этот канал собрал несколько тысяч подписчиков. Всего за счет трех эмодзи.
3️⃣ Некоторые каналы (и мы, спасибо читателям) обратили на это внимание и заменили паки на собственные. Наш мы так и назвали — «безопасный» (кстати, его установили себе около 20 пользователей, а сколько установили оригинальный — загадка). Другие каналы, узнав об этом, удалили публикации или эмодзи в них.
4️⃣ Чего не произошло, а могло бы. Помимо того, что у паков можно обновлять названия — в них можно менять и сами эмодзи, а также добавлять новые. На примере котиков из начала объяснения — заменить их всех на песиков 🐈 —> 🐕 (сильно не переживайте, в уже размещенных эмодзи котики останутся, изменения будут только в новых публикациях). А дальше у кого на что хватит фантазии — вплоть до размещения фишингового QR-кода, состоящего из эмодзи.
💡 Такие механики — наглядный пример того, как даже без взлома можно использовать доверие аудитории в своих целях. Поэтому перед публикацией любого хайпового контента стоит оценивать риски, даже если на первый взгляд все выглядит безобидно (для себя тоже выводы сделали).
Я знаю, что ничего не знаю (с) Сократ
Казалось бы, уже более 7 лет я провожу аудиты безопасности и тестирование на проникновение. NMap, если и не затерт до дыр, то бодрый десяток команд уже настолько забетонирован на подкорке мозга, что если меня разбудить ночью и попросить составить запрос на сканирование 20-й подсети с отображением версий сервисов, с последующим применением к ним скриптов, с максимальным отображением вывода и последующей записи лога в формат grep’а, то я продиктую команду даже не разомкнув глаз.
Однако воистину: век живи - век учись! На одном из последних проектов, в котором я принимал участие со стороны “синих”, случилась интересная аномалия: все принтеры организации поверили в SkyNet и начали неистово печатать какую-то абракадабру. И я не говорю про 1-2 листка - это было тотальное истощение ресурсов: 1 строка на 1 листе, а таких листков около сотни. И даже очищение кэша через физическое отключение 220 не помогло. В общем, на полдня компания реально “встала”. Что же произошло?
В ходе изучения текста напечатанных “документов” мы с командой выявили, что все запросы на принтеры шли на порт 9100. Порт 9100/TCP является стандартным портом прямой печати Raw и часто называется JetDirect или RAW-печать. Он позволяет сетевому устройству отправлять задание на печать напрямую в буфер принтера без использования дополнительных протоколов, шифрования и авторизации.
Я, если честно, про это узнал впервые, равно как и обе команды: защиты и нападения. Для сканирования коллеги использовали nikto, который в принципе не таит в себе опасности, но результаты удивили буквально всех. В качестве тестирования мы через браузер телефона подключились на порт 9100 и жужжание принтера подтвердило нашу теорию.
После локализации проблемы и восстановления работоспособности парка техники я начал разбираться, почему за всю мою ИБэшную карьеру у меня такого никогда не случалось, ведь я сканирую сети практически каждый день? Так вот, если мы внимательно прочитаем документацию к приложению, мы узнаем, что у NMap есть исключения (так называемые Exclude Directive), в которые по умолчанию включены порты 9100-9107. Как вы можете понять, исключены они как раз по той причине, чтобы принтеры не тратили тонны бумаги на каждую проверку сканера. В общем, хорошее откровение.
П.С. Когда я собеседую кандидатов на вакантные должности, я внимательно изучаю резюме и стараюсь задать вопросы исключительно по нему (и на половину вопросов мне не могут ответить)). И когда я вижу в секции скилы “NMap”, я люблю задавать вопрос, как программа определяет, что порт на хосте открыт, закрыт или зафильтрован. Теперь у меня будет второй добивающе-контрольный вопрос: сканирование каких портов по умолчанию не производится и требует явного указания?
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
РБПО по ГОСТ Р 56939—2024: вебинар №03 из 30 – Формирование и предъявление требований безопасности к программному обеспечению
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.3. – "Формирование и предъявление требований безопасности к программному обеспечению". Слайды.
Цели третьего процесса по ГОСТ Р 56939—2024 (п. 5.3.1.1):
Обеспечение безопасности ПО посредством предъявления к нему требований и управления требованиями в процессе изменения (разработки) ПО.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Почему KYC воспринимается как препятствие, а не как защита
KYC это одна из самых раздражающих частей любого финтех- или криптосервиса.
Пользователь приходит за быстрым действием: перевести, купить, обменять, вывести. А вместо этого получает форму, паспорт, селфи, ожидание проверки и ощущение, что его снова заставляют что-то доказывать.
С точки зрения пользователя это выглядит просто: «Я хочу сделать операцию, почему вы тормозите процесс?»
С точки зрения сервиса всё выглядит иначе. Если не проверять пользователей, не отслеживать аномальные операции и не фильтровать очевидный риск, сервис очень быстро начинает получать не рост, а проблемы: блокировки, претензии, давление со стороны платёжной инфраструктуры, рост мошеннических кейсов и постоянные ручные разборы.
И в какой-то момент вопрос уже не в удобстве. Вопрос в выживании.
Проблема в том, что KYC почти всегда воспринимается как враждебный сценарий. Не потому, что люди в принципе против проверки, а потому что сам момент проверки обычно встроен в пользовательский путь максимально плохо.
Чаще всего пользователь сталкивается с KYC тогда, когда уже психологически считает операцию почти завершённой. Он выбрал сумму, дошёл до нужного шага, настроился на результат и только потом внезапно получает требование загрузить документы. В этот момент это воспринимается не как мера безопасности, а как подмена условий в последний момент.
Отсюда и главный конфликт: сервис считает, что защищает процесс, а пользователь считает, что его просто остановили на финише.
На практике раздражает не только сам факт проверки, а четыре вещи.
Первая – внезапность. Если KYC появляется слишком поздно, это почти всегда вызывает негатив.
Вторая – неопределённость. Пользователь не понимает, зачем это нужно именно сейчас, сколько это займёт времени и что будет дальше.
Третья – ощущение недоверия. Особенно если интерфейс подаёт проверку сухо, без нормального объяснения.
Четвёртая – несоответствие ожиданию. Человек пришёл за быстрым действием, а получил сценарий, похожий на банковскую бюрократию, только без банковской репутации.
Именно поэтому один и тот же KYC может восприниматься по-разному в разных сервисах. Где-то пользователь проходит его спокойно, а где-то уходит с раздражением ещё до завершения.
Парадокс в том, что сам по себе KYC не убивает доверие. Его убивает плохой сценарий вокруг него. Если сервис заранее объясняет, в каких случаях может потребоваться проверка, не прячет это до последнего шага, показывает понятную логику и не превращает процесс в чёрный ящик, уровень негатива заметно ниже. Пользователь всё ещё не любит KYC, но хотя бы понимает, почему это происходит.
Если же проверка возникает внезапно, без контекста и без понятных сроков, она воспринимается как ловушка. Даже если с точки зрения комплаенса всё сделано правильно.
Поэтому KYC сегодня – это уже не только юридическая или антифрод-задача. Это ещё и продуктовая задача. Сервису недостаточно просто «включить проверку». Ему нужно встроить её так, чтобы она не ломала доверие быстрее, чем защищала бы бизнес.
На практике пользователей раздражает не сам факт проверки, а то, как и в какой момент она появляется. Поэтому KYC давно перестал быть только задачей безопасности: теперь это ещё и вопрос интерфейса, коммуникации и доверия.
Коротко подведу итоги последних обсуждений по вопросам уязвимости средств обхода, как я их понимаю .
Преамбула: Многие популярные средства обхода блокировок открывают порт на localhost, на котором отвечает SOCKS-прокси. Трафик, идущий через этот прокси, отправляется в туннель, который завершается на удалённом сервере, где Интернет не столь ограничен. Для удобства использования уже этот прокси заворачивается в сетевой TUN-интерфейс, что позволяет пускать через него трафик приложений, которые с прокси работать не умеют/не хотят.
Проблема: Как правило, этот SOCKS-прокси не требует авторизации. А потому любое приложение, знающее о существовании открытого порта или TUN-интерфейса, может отправить запрос через него на подконтрольный создателям приложения сервер, и тем самым выяснить, куда именно ведёт обходной туннель. При этом выяснить наличие порта можно простым перебором (localhost обычно быстр), а список сетевых интерфейсов приложение может запросить без особых прав.
Последствия: Это позволяет РКН в перспективе полностью автоматизировать поиск и блокировку индивидуальных средств обхода блокировок, при этом не обрубая зарубежный трафик полностью. С недавних пор все российские ИТ-компании обязаны этому содействовать, блокируя пользователей с обнаруженным туннелем и/или донося на этих пользователей РКН. Любое российское приложение может оказаться стукачом.
Пути решения на Android:
Раздельная маршрутизация по сетевым адресам (например, ru - напрямую, не ru - в туннель) - скорее вредна, чем полезна. Приложение может сделать два запроса к "своим" серверам, один из которых находится за рубежом, получить от них ответы с адресом отправителя, и сравнить. Адреса разные = есть туннель.
"Обычная" раздельная маршрутизация по приложениям - гарантий не даёт. Насколько я понимаю, она просто задаёт сетевой интерфейс, который приложение использует по умолчанию, но не запрещает приложению использовать другие интерфейсы. Также она не мешает сканировать порты в поисках SOCKS-прокси.
Shelter, Knox и тому подобные песочницы - не слишком помогают. Они скроют часто проверяемый флаг TRANSPORT_VPN, но не защитят от перебора портов в поисках SOCKS. Проверяется утилитами вроде RKNHardening.
Включить авторизацию на SOCKS-прокси и ограничить доступ к TUN интерфейсу - пока доступно не везде. Сейчас добавление этой фичи в приложения для обхода обсуждается. Некоторые уже поддерживают. Это не помешает злонамеренному приложению увидеть, что прокси есть - но не позволит узнать адрес сервера. Также без ограничения доступа к TUN пароль на прокси не поможет.
Раздельные IP на вход и выход - довольно хороший способ. В худшем случае в бан улетит сервер-выход, а вы продолжите подключаться на входной.
Различные устройства - неудобный и дорогой, но надёжный способ. Одно устройство только для российских приложений, без следа средств обхода, подключается в Сети только через мобильный интернет. Второе - для всего остального. Но не стоит забывать про проблемы вебсайтов (см. ниже).
Что делать с сайтами?
Потенциально на сайт может быть внедрён JS-скрипт (через трекеры или рекламные сети), который пытается провести аналогичный анализ через сопоставление двух обращений на сервера в разных сетевых локациях. При этом правила CORS, не позволяющие скриптам произвольно обращаться к другим веб-сайтам, не особенно помешают. Они не позволяют скрипту прочитать ответ, но сервера всё ещё получат запрос - а значит, могут выполнить сопоставление сами, если они подконтрольны создателю скрипта.
Поэтому разумным представляется такой вариант: два разных браузера, или два разных профиля в одном браузере. Один без прокси, под работу с доступными сайтами и один под потенциальную запрещёнку. В оба профиля ставим адблокер и жёстко режем доступ к любым рекламным сетям - не гарантия, но может помочь. Во втором профиле - никакой раздельной маршрутизации, все запросы строго через прокси. На российские и другие подозрительные ресурсы через второй профиль не ходим никогда.
РБПО по ГОСТ Р 56939—2024: вебинар №02 из 30 – Обучение сотрудников
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем вашему вниманию сегодня вебинар цикла, посвящённый процессу, описанному в разделе 5.2. – "Обучение сотрудников". Слайды.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Я буду публиковать по два вебинара в неделю, чтобы было время знакомиться с ними.
Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Поскольку рассматриваем процесс обучения, хочется напомнить, что учебный центр "Маском" предлагает ряд курсов по тематике РБПО:
М БРПО-Спец. Специалист по процессам разработки безопасного программного обеспечения. 200 часов / 20 дней.
М БРПО-01. Внедрение процессов разработки безопасного программного обеспечения в организации (для руководителей и ответственных). 40 часов/4 дня.
М БРПО-02. Внедрение процессов разработки безопасного программного обеспечения для специалистов по информационной безопасности. 50 часов/5 дней.
М БРПО-03. Сертификационные испытания с учётом требований по разработке безопасного программного обеспечения для экспертов органов по сертификации (испытательных лабораторий) различных систем сертификации средств защиты информации. 140 часов/14 дней.
М БРПО-04. Формирование практических навыков по разработке безопасного программного обеспечения для разработчиков и программистов. 140 часов/14 дней.
М БРПО-05. Методология подготовки предприятия к сертификации процессов безопасной разработки программного обеспечения средств защиты информации в соответствии с требованиями ФСТЭК России. 30 часов/3 дня.
Вы узнаете много полезной информации из вебинаров, которые я здесь публикую. Однако есть смысл подумать и о прохождении обучающих курсов.
Вебинары – это теория. На курсах вы получите практические навыки, знакомясь с продуктами лидеров рынка РФ по РБПО.
УЦ "Маском" имеет лицензию на учебную деятельность и право давать официальный документ о повышении квалификации и прохождении профессиональной переподготовки.
Официальный документ об обучении требуется для экспертов органов/лабораторий в системах сертификации ФСТЭК России и Минобороны России.
Программа М БРПО-Спец "Специалист по процессам разработки безопасного ПО" (200 часов/20 дней) официально согласована с ФСТЭК России.
Человеческий фактор. Не все сотрудники достаточно мотивированы самостоятельно глубоко изучить тему РБПО. Курсы станут поводом выделить на это время.
P.S. В конце не могу не упомянуть про курс "ПВС СТАТ" – Статический анализ программного обеспечения в соответствии с требованиями ГОСТ Р 71207–2024 с применением PVS-Studio. 30 часов/3 дня.
7 вещей, которые нужно проверить перед любым крипто-переводом
Криптопереводы давно стали обычной частью цифровых финансов. Но, в отличие от банковских приложений, здесь одна ошибка может стоить не комиссии, а всей суммы. Проблема в том, что деньги часто теряются не из-за взломов, не из-за блокчейна и не из-за “скама”, а из-за вполне бытовых вещей: не ту сеть выбрали, не заметили важное поле, поспешили, не сверили адрес. Вот что действительно стоит проверить перед отправкой.
Первое — сеть. Один и тот же актив может существовать в нескольких сетях. Например, USDT можно отправить через ERC-20, TRC-20, BEP-20 и другие варианты. На экране это выглядит как тот же токен, но по факту это разные маршруты. Ошибка здесь — одна из самых дорогих.
Второе — адрес. Недостаточно просто скопировать его и вставить. Стоит хотя бы сверить первые и последние символы. Ошибки в буфере, невнимательность или банальная спешка — классика.
Третье — актив и сеть должны совпадать одновременно. Многие проверяют только монету или только сеть, а ошибка обычно возникает именно в связке.
Четвёртое — комиссия и итоговая сумма. Особенно если перевод идёт “впритык”. Иногда пользователь уверен, что отправляет нужную сумму, а после комиссии оказывается ниже минимального порога.
Пятое — минимальная сумма зачисления. Во многих сервисах слишком маленький перевод может прийти в сеть, но не зачислиться автоматически. И человек просто сидит и ждёт, не понимая, что произошло.
Шестое — memo, tag или дополнительный идентификатор, если он нужен. Для некоторых активов одного адреса недостаточно. Если забыть это поле, перевод может пройти, но деньги не будут привязаны к аккаунту без ручной поддержки.
Седьмое — тестовый перевод. Самый скучный совет, но самый дешёвый способ не потерять крупную сумму. Если сервис новый, сеть новая или сумма чувствительная — сначала лучше отправить небольшую часть.
Большая часть проблем в криптопереводах возникает не потому, что технология слишком сложная, а потому что в одном месте пересекаются невнимательность, непривычный интерфейс и отсутствие права на ошибку.
Сегодня межсетевой экран нового поколения (NGFW) остается одним из ключевых средств по защите информации. Среди его функций: системы обнаружения/предотвращения вторжений (IDS/IPS), потоковая антивирусная защита, инспекция SSL-трафика и так далее. До 2022 года у большинства компаний в основе инфраструктуры были решения класса NGFW от зарубежных производителей, но постепенно начался процесс миграции на отечественные продукты.
При этом этом среди компаний все еще распространена практика использования межсетевых экранов иностранных производителей. Об этом говорит, по крайней мере, востребованность уже установленных систем (запчасти и обход лицензионных ограничений). Однако с точки зрения информационной безопасности наличие зарубежных NGFW создает ряд рисков. Среди них:
Отсутствие официальных патчей и обновлений баз сигнатур угроз. Устройство без актуальных экспертных данных «слепнет» в течение нескольких месяцев. К тому же вы эксплуатируете устройство, об уязвимостях которого узнаете из публичного доступа, но закрыть их нечем;
Снижение отказоустойчивости. Если нет поддержки от вендора, то это лишает пользователя легитимного цикла. Поэтому сбой ПО или железа сулит длительную остановку деятельности организации;
Риск подмены ПО. Непрозрачность источника обновлений с высокой вероятностью приведет к внедрению закладок в прошивку. Такие атаки на цепочки поставок распространены среди профессиональных хакерских групп;
«Окирпичивание» NGFW при автоматическом обращении за лицензией или телеметрией. Устройство может получить команду на блокировку интерфейсов, что мгновенно парализует сеть;
Принадлежность производителей к недружественным странам с соответствующими выводами о доверии к ним.
Но стоит уточнить о нескольких факторов, которые затрудняют переход с зарубежных межсетевых экранов на отечественные. Так, российские продукты по функциям пока вне конкуренции со зрелыми зарубежными решениями. Российских NGFW моложе и некоторые функции, которые отточены до автоматизма, пока реализованы с ограничениями. В первую очередь, речь о поддерживаемых сетевых технологиях, что существенно ограничивает в вариантах внедрения. К тому же архитектурное отличие некоторых отечественных платформ требует мощных аппаратных ресурсов, особенно при обработке шифрованного трафика на высоких скоростях.
Решения класса NGFW преимущественно являются пограничными средствами защиты, поэтому ошибки или пренебрежение функциональностью при миграции могут стоить очень дорого.
Компания «Анлим» – центр компетенций по информационной безопасности, на протяжении 14 лет как интегратор, советует не держаться за зарубежные продукты, но и не рубить с плеча. Нужно обеспечить плавный переход, а не аварийную замену.
Разбираемся в уязвимости XXE
XXE (XML eXternal Entity injection) — это уязвимость, которая позволяет злоумышленнику вмешиваться в процесс обработки XML-данных приложением.
Язык разметки XML (eXtensible Markup Language) — это такой тип документа, в котором вся информация представлена в виде тегов. Для описания структуры документа часто используется DTD (Document Type Definition), который, помимо прочего, позволяет подключать внешние ресурсы.
Чем опасна XXE:
Позволяет читать локальные файлы на сервере (например, /etc/passwd);
Может привести к отказу в обслуживании (например, через атаку «Billion Laughs»);
В некоторых случаях открывает путь к удаленному выполнению кода;
Используется для обхода ограничений и получения чувствительных данных.
В этом видео Анна Данилова (Калугина), инженер по безопасности приложений Swordfish Security, подробно объясняет, как работает XXE-уязвимость. Эксперт разбирает принцип работы XML и DTD, демонстрирует реальный пример эксплуатации через подмену запроса и рассказывает, как предотвратить появление уязвимости.
Уронить прод специально: безумие или отвага?
Есть инженеры, которые боятся инцидентов. А есть те, кто устраивает их самостоятельно — по расписанию, с тикетом в Jira и полным пониманием того, что сейчас случится. Chaos Engineering — это не баг в процессах, а фича. Только вот объяснить это менеджеру, когда прод лежит намеренно — всё равно непросто.
Вместе с Дмитрием Баскаковым, Head of Platform в MindBox, разбираемся, что на самом деле стоит за этим методом — и почему компании, которые регулярно что-нибудь ломают, в итоге падают реже остальных.
Что на повестке
Chaos Engineering звучит красиво, но практика гораздо прозаичнее: нужна культура, нужны SLO, нужно понимать, что именно вы тестируете — систему или людей. В выпуске обсуждаем, чем хаос-тесты отличаются от нагрузочного тестирования, кто принимает решение «ломать» и кто за это отвечает, почему без blameless-культуры всё это превращается в поиск виноватых — и есть ли у хаос-инженерии реальный ROI или это дорогостоящее развлечение для зрелых команд.
Отдельно поговорили про выгорание: добавляет ли плановый хаос тревожности инженерам — или, наоборот, снимает её.
Если вы хоть раз думали «у нас и так всё нестабильно, зачем ещё специально ломать» — этот выпуск именно про вас.
Слушайте и смотрите на площадках
И подписывайтесь на телеграм-канал Avito SREда
Ещё больше экспертизы собрали для вас на сайте: смотрите наши лонгриды, новости, плейлисты видео. А узнать, как стать частью команды AvitoTech, можно вот здесь.
РБПО по ГОСТ Р 56939—2024: вебинар №01 из 30 – Планирование процессов РБПО
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем вашему вниманию сегодня первый вебинар цикла, посвящённый первому процессу, описанному в разделе 5.1. – "Планирование процессов разработки безопасного программного обеспечения". Слайды.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Я буду публиковать по два вебинара в неделю, чтобы было время знакомиться с ними.
Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
CHM-оснастка, будильники, ЦИБ МО РФ и биткоин-яйца 🤖
В конце декабря прошлого года команда Threat Intelligence экспертного центра кибербезопасности Positive Technologies обнаружила атаки, которые мы атрибутировали ранее описанной исследователями группировке CapFix.
Злоумышленники использовали PDF-документы, которые маскировались под «повреждённые» и побуждали пользователей скачать RAR-архив, внутри которого находился скрипт. Этот скрипт скачивал файл a.gif и переименовывал его в dmitry_medvedev.msi 😶, который впоследствии приводил к заражению пользователя вредоносным ПО CapDoor.
Инфраструктура группировки притворялась легитимными доменами, связанными с обновлениями Windows, и регистрировалась через onionmail. Но еще интереснее, что группировка использовала ряд легитимных IP-адресов и доменов, которые, по нашему мнению, злоумышленники взломали примерно за месяц до самих атак с помощью CVE-2025-49113 👨💻
В марте группировка возобновила эти атаки с измененной версией CapDoor, что говорит о том, что злоумышленники продолжают развивать свой инструмент.
Как именно злоумышленники развивают CapDoor, как группировка ранее использовала ClickFix и при чем тут биткоин-яйца — читайте в нашем исследовании ⬅
(Источник: https://t.me/ptescalator)
Claude Mythos примерно в 1,5 раза мощнее Opus 4.6 в кодинге
Anthropic опубликовала системную карту Claude Mythos Preview • своей самой большой модели, которая пока не вышла в открытый доступ. Заявлено: в 1,5 раза мощнее Opus 4.6 на кодинговых бенчмарках, +10–15 п.п. на агентных задачах. Уже работает под капотом Glasswing • новой системы кибербезопасности. Разбираемся, что здесь факт, а что требует оговорок.
Что именно показали
Mythos Preview • preview-версия, не финальный релиз. Anthropic позиционирует её как модель для длительных автономных задач: многодневный ресёрч, аудит безопасности, сложные кодовые ревью.
Ключевые цифры из системной карты:
SWE-bench Verified: 75,6% (Opus 4.6 • около 50%)
Terminal-bench: +10–15 п.п. к Opus 4.6 на агентных сценариях
Контекст: до 1М токенов
Заявлено, что в режиме работы с Glasswing модель уже нашла «тысячи уязвимостей», включая уязвимости в ОС и браузерах.
Где нужна трезвость
Бенчмарки ≠ продакшн. SWE-bench Verified • синтетический тест на исправление issues в open-source репозиториях. Реальные задачи сложнее: легаси-код, неполная документация, бизнес-контекст, который не укладывается в промпт.
«Тысячи уязвимостей» • без методологии. Anthropic не раскрыла: какого уровня критичности, сколько дубликатов известных CVE, какой false positive rate. В кибербезопасности это критично • модель, которая генерирует 10 000 находок с 95% ложных срабатываний, создаёт работу, а не снимает её.
Preview • не production. Системная карта прямо указывает на ограничения текущей версии: склонность к «reward hacking» при длительных сессиях, проблемы с консистентностью на задачах больше 4–6 часов, риски при автономной работе без supervision.
Что реально интересно инженерам
Архитектурный сдвиг. Anthropic явно двигается к моделям, заточенным под агентные сценарии • не «ответил на вопрос», а «работал над задачей несколько дней». Это другой паттерн использования и другие требования к инфраструктуре.
Glasswing как кейс. Первое публичное применение Mythos • не чатбот, а инструмент для security-команд. Если подтвердится эффективность, это сильный сигнал: LLM переходят из категории «генератор текста» в категорию «инструмент для специалистов».
Контекст 1М токенов. Для code review и аудита безопасности это существенно • можно загрузить целый репозиторий без chunk-ирования.
Что остаётся неизвестным
Стоимость инференса (ожидаемо высокая для модели такого масштаба)
Latency на длинных сессиях
Доступность API для внешних разработчиков
Сроки перехода из preview в production
Если честно
Mythos Preview • интересный технический артефакт, но пока это анонс анонса. Бенчмарки показывают прогресс, системная карта честно описывает ограничения (что редкость для AI-релизов). Реальная ценность станет понятна, когда появятся независимые тесты и опыт production-использования.
Для тех, кто строит агентные системы сейчас: следить за развитием стоит, переписывать архитектуру под Mythos • рано.
Кто уже работает с Claude на агентных задачах длиннее нескольких часов • какой основной блокер: контекст, консистентность или что-то третье?
Открываем регистрацию на Альфа ЦТФ 2026 — в этом году будем искать флаги на заоблачных высотах. Поэтому советуем брать с собой карабины и альпинистские верёвки, чтобы добраться до всех уязвимостей и покорить небоскрёбы.
⚡️ Выбирайте трек, объединяйтесь в команду или участвуйте индивидуально — и оставляйте заявку на сайте
5 бесплатных уроков апреля по информационной безопасности
8 апреля, 20:00. Настройка аудита событий ИБ в ОС Windows
Урок о том, как настраивать аудит событий в Windows и получать телеметрию для SIEM: от Event Log до расширенных политик и установки агента. Поймёте, как выстраивается сбор и контроль событий на практике.
>> Открытый урок курса «Специалист по внедрению SIEM»
8 апреля, 20:00. Управляющие серверы как ключ к расследованию утечек данных
Поговорим о том, как выявлять скрытое управление утечками через C2-инфраструктуру и отличать разовые инциденты от системных атак. Разберёте поведенческие признаки и подходы к детектированию на уровне инфраструктуры.
>> Открытый урок курса «Компьютерная криминалистика»
13 апреля, 20:00. Архитектура доверия: качество данных
Поговорим о том, почему одних проверок недостаточно и как выстроить управление качеством данных как систему. Покажем, как работают инциденты и дата-контракты в реальных процессах между командами.
>> Открытый урок курса «Качество данных / Data Quality»
15 апреля, 20:00. Запутывание кода (обфускация) как метод сокрытия вредоносного ПО
Разберём, как вредоносный код маскируется через обфускацию и какие приёмы используются для сокрытия логики. Покажем, как находить такие техники и анализировать запутанный код на практике.
>> Открытый урок курса «Компьютерная криминалистика»
21 апреля, 20:00. Архитектура мониторинга ИБ инфраструктуры на SIEM
Получите представление об эффективном построении системы SIEM в организациях различного масштаба. Будет особенно полезно тем, кто отвечает за мониторинг событий ИБ и построение/развитие SIEM в организации.
>> Открытый урок курса «Специалист по внедрению SIEM»
Полный список бесплатных уроков апреля смотрите в дайджесте.
Как думает хакер: логика атак на бизнес
Как оценить безопасность компании с точки зрения злоумышленника? Одно дело — знать теорию защиты, другое — понимать логику взлома.
27 марта состоялся очный бизнес-интенсив, реализуемый в рамках курса повышения квалификации «Анализ типовых сценариев компьютерных атак на организации и их последствия» МГТУ им. Н.Э. Баумана совместно с компанией Бастион!
Программа построена на исследовании сценариев реальных компьютерных атак и включает три ключевых блока:
1️⃣ Разведка: как хакер выбирает жертву
2️⃣ Внутренний взгляд: как атака развивается внутри компании
3️⃣ Вас взломали: что делать в первые 24 часа
Спикеры:
Дмитрий Калинин, директор департамента по работе с уязвимостями и инцидентами ИБ, Бастион
Иван Глинкин, руководитель группы аппаратного тестирования департамента по работе с уязвимостями и инцидентами ИБ, Бастион
Для тех, кто по тем или иным причинам не мог присутствовать очно, представляю полную запись интесива во 📺 ВКонтакте (3 часа 5 минут).
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
Рег.облако и DDoS-Guard договорились о сотрудничестве
В рамках партнерства Рег.облако интегрировал в облачную среду расширенную защиту от DDoS-атак (L3–L4 и L7) на базе технологий DDoS-Guard. За 2025 год DDoS-атаки на облачный сегмент выросли почти в полтора раза, сделав встроенную защиту от киберугроз важным элементом любой инфраструктуры, и теперь клиенты провайдера смогут ей воспользоваться.
Облачный и Bare metal провайдер Рег.облако объявил о запуске партнерского решения DDoS-Guard для защиты облачной инфраструктуры и веб-ресурсов от DDoS-атак. Сервис интегрирован в облачную платформу и позволяет клиентам подключать защиту через единый интерфейс панели управления, не вынося настройку безопасности в отдельный контур.
Рост зависимости бизнеса от облачных сред усиливает требования к устойчивости цифровой инфраструктуры. По данным DDoS-Guard, в 2025 году увеличился масштаб ботнетов: атаки происходят с участием более 2 млн уникальных IP-адресов. Подавляющее большинство атак, около 80%, приходится на уровень L7, то есть на приложения и веб-сервисы, где сбои напрямую отражаются на доступности сайтов, личных кабинетов, API и онлайн-платформ.
На этом фоне защита от DDoS-атак становится для облачных заказчиков не дополнительной опцией, а базовым элементом отказоустойчивости. Решение DDoS-Guard в Рег.облаке обеспечивает многоуровневую защиту на уровнях L3–L4 и L7, автоматическое обнаружение атак и запуск фильтрации в течение нескольких секунд, а также поведенческий мультивекторный анализ для противодействия ботам и другим видам вредоносной активности. Фильтрация трафика опирается на глобальную сеть очистки суммарной мощностью более 3,2 Тбит/с.
«Для компаний с публичной инфраструктурой DDoS-атаки остаются системным риском — от интернет-магазинов и игровых платформ до финансовых сервисов. Решение DDoS-Guard в Рег.облаке позволяет управлять инфраструктурой и защитой в одном интерфейсе, что упрощает запуск, снижает вероятность ошибок в настройке и делает инструменты сетевой безопасности доступнее для бизнеса любого масштаба», — комментирует Егор Сапун, руководитель направления сертификации инфраструктуры Рег.облака.
«Сотрудничество с Рег.облако позволит защитить гораздо большее количество отечественных сайтов от DDoS-атак и повысить уровень их отказоустойчивости. Это решение для очень актуальной сегодня проблемы бесперебойной работы бизнеса в условиях роста как числа, так и мощности DDoS-атак, особенно на облачный сектор», — заявил Дмитрий Никонов, директор по продуктам DDoS-Guard.
Запуск партнерского решения расширяет набор встроенных сервисов безопасности в Рег.облаке и отвечает запросу компаний, для которых критичны непрерывная работа онлайн-сервисов, предсказуемость затрат и быстрое развертывание защиты без сложной интеграции. Наиболее востребованным такой сценарий может быть для интернет-магазинов, игровых проектов, корпоративных систем с публичным доступом, а также финансовых и финтех-сервисов, где цена даже кратковременного простоя остается крайне высокой.
Представлен открытый OSINT-инструмент, который за несколько секунд собирает цифровой след по всему интернету. Проект Sherlock по одному нику пробивает аккаунты сразу на сотнях сайтов. Решение параллельно проверяет 400+ платформ: от соцсетей до форумов и цифровых площадок. На выходе получается список всех найденных профилей, можно выгрузить в файл или открыть прямо в браузере. Работает на любой системе, есть поддержка прокси и Tor.
Помните в своих постах я периодически указывал на 📺 Matt Brown и его реверс-инжиниринг IoT-устройств, которые нас окружают? Так вот, буквально 8 дней назад Matt совместно с Andrew Bellini анонсировали абсолютно бесплатный курс по аппаратному хакингу под названием All about UART (Все про UART).
В соответствии с описанием,
Этот вводный курс познакомит вас со всем, что касается UART, одного из старейших и до сих пор наиболее распространенных протоколов связи для встроенных систем. Вы изучите основы взаимодействия устройств с помощью электронных сигналов, принципы работы UART вплоть до уровня напряжения на проводе, научитесь распознавать сигналы UART и, что наиболее важно, взаимодействовать с ними. Помимо изучения UART, этот курс также научит вас основным навыкам работы с аппаратным обеспечением, таким как использование мультиметра, логического анализатора, адаптера UART и даже, при желании, пайка.
Курс состоит из 6 секций и суммарно 17 уроков общей продолжительностью 2 часа 35 минут. Авторами, как я упомянул выше, являются Andrew Bellini и Matt Brown. К сожалению, язык повествования только английский, но отечественный «однобуквенный» браузер имеет встроенный функционал по переводу его на русский.
Ребята «защитились» и не дают возможность просматривать видео с российских IP‑адресов. Какие наивные). Мало того, что у нас хорошие учителя в лице главного регулятора, и даже бабушки знают, как обойти это ограничение, так они решили защититься от главных хакеров таким детским способом. Ладно, не будем над ними шутить, возможно они руководствуются требованиями своего регулятора… В любом случае, для вашего удобства я скачал все уроки, смонтрировал в одно видео и разместил во 📺 ВКонтакте.
Поэтому устраивайтесь по-удобнее и в путь - грызть гранит науки!
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
Разбираемся в уязвимости типа Open Redirect
Перенаправления — это механизм, с помощью которого сервер указывает клиенту (например, веб-браузеру) необходимость перейти на другой URL. Они являются стандартной частью протокола HTTP и используются для управления трафиком между веб-сайтами.
Чем опасно открытое перенаправление:
Позволяет проводить фишинговые атаки;
Используется для эксплуатации уязвимостей браузеров и плагинов;
Способствует распространению вредоносного контента и дезинформации.
➡️ В этом видео Денис Данилов, инженер по безопасности приложений Swordfish Security, рассказывает, как защититься от этой уязвимости. Эксперт объясняет, какие подходы использовать на сервере, чтобы исключить риск, а также показывает реальный пример эксплуатации, когда злоумышленник может обмануть пользователя, даже если сайт выглядит безопасным.
Опрос об ИТ-стандартах: создавайте правила, по которым завтра будет работать вся индустрия
До 17 апреля у вас есть возможность пройти опрос и действительно повлиять на то, как развивается российская стандартизация в области информационных технологий.
Сегодня в разработке стандартов участвует менее 1% российских ИТ-организаций. И напрасно: национальные стандарты — это не «скучные документы», а реальных рабочий инструмент, который позволяет:
· осознанно выбирать необходимые для проекта технологии или их совокупность;
· заимствовать апробированные мировые практики, а не «изобретать велосипед» заново;
· влиять на государственное регулирование ИТ-отрасли, поскольку по ряду стандартов уже проводят проверки надзорные органы — и их количество будет расти.
В конце концов, лучше создавать собственные правила работы, а не работать по чужим. Сегодня у вас есть такая возможность.
По поручению Росстандарта при поддержке Информационной сети «Техэксперт» проводится опрос, который выявит востребованность российскими предприятиями стандартов в сфере ИТ. Ваши ответы помогут сформировать Программу национальной стандартизации (ПНС) на 2027–2030 годы на основе реальных запросов ИТ-индустрии и напрямую определят, какие международные технологии (ISO/IEC) станут национальными стандартами в ближайшие годы, и какие ГОСТ Р будут актуализированы и пересмотрены. Исследование продлится до 17 апреля 2026 года.
Заполнение анкеты требует определённых интеллектуальных усилий и доступа к нормативной базе. Учитывая это, организаторы:
· дают всем участникам месяц бесплатного доступа к системе «Техэксперт SMART: Цифровые технологии» (доступ можно оформить по ходу прохождения анкеты);
· разыгрывают 5 брендированных подарков от «Техэксперт» среди всех участников опроса.
Ваше экспертное мнение поможет выстроить правильную стратегию развития отрасли и обеспечить поддержку проектов на государственном уровне!
Claude Code стал публичным из-за ошибки в сборке
Исходный код агента Claude Code оказался в открытом доступе из-за технической ошибки. При публикации пакета разработчики не исключили .map-файл, что фактически позволило восстановить значительную часть внутренней логики проекта.
Репозиторий быстро разошёлся по сообществу: за короткое время он собрал тысячи звёзд на GitHub и был многократно скопирован. Внутри — системные промпты, архитектурные решения, вспомогательные функции и другие элементы, которые обычно остаются закрытыми.
Ознакомиться с утёкшим кодом можно в репозитории: https://github.com/instructkr/claude-code
Ситуация наглядно показывает, насколько критичной может быть даже незначительная ошибка в конфигурации сборки — особенно для проектов с закрытой архитектурой.
Мой блог в Телеграм: Хак Так ⬅ поддержите подпиской!
Встроенная защита от DDoS в Рег.облаке: подключение без отдельного контура и сложной интеграции
Рег.облако договорилось о партнерстве с DDoS-Guard и интегрировало их защиту прямо в облачную платформу — подключить можно через стандартную панель управления. Актуальность очевидна: за 2025 год атаки на облачный сегмент выросли почти в полтора раза, 80% из них бьют по уровню L7 — прямо по сайтам, API и личным кабинетам.
Решение работает на уровнях L3–L4 и L7: автоматически обнаруживает атаки, запускает фильтрацию за несколько секунд и противодействует ботам через поведенческий мультивекторный анализ. Особенно актуально для интернет-магазинов, игровых платформ, финансовых сервисов и корпоративных систем — там простой стоит дорого.
Подробнее об интеграции читайте на сайте Рег.облака.
