Бесплатный проект 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.РФ.
