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

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

Выяснилось, что всё довольно прозаично: красный — это 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. Помогите черепахе починить покров: для этого разберите и заново соберите в правильном порядке все микросхемы.
Черепаха рассылала всем знакомым мастерам ссылку на схему верной сборки чипов в панцире с помощью этого сервиса — но увы, ни один ремонтник не откликнулся, а ссылка уже давно протухла.

cybershell-m7qdo6bx.alfactf.ru/»

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

У этой задачи есть два решения. 

№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.РФ.

Коротко подведу итоги последних обсуждений по вопросам уязвимости средств обхода, как я их понимаю .

Преамбула: Многие популярные средства обхода блокировок открывают порт на 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.РФ.

Поскольку рассматриваем процесс обучения, хочется напомнить, что учебный центр "Маском" предлагает ряд курсов по тематике РБПО:

1. М БРПО-Спец. Специалист по процессам разработки безопасного программного обеспечения. 200 часов / 20 дней.

2. М БРПО-01. Внедрение процессов разработки безопасного программного обеспечения в организации (для руководителей и ответственных). 40 часов/4 дня.

3. М БРПО-02. Внедрение процессов разработки безопасного программного обеспечения для специалистов по информационной безопасности. 50 часов/5 дней.

4. М БРПО-03. Сертификационные испытания с учётом требований по разработке безопасного программного обеспечения для экспертов органов по сертификации (испытательных лабораторий) различных систем сертификации средств защиты информации. 140 часов/14 дней.

5. М БРПО-04. Формирование практических навыков по разработке безопасного программного обеспечения для разработчиков и программистов. 140 часов/14 дней.

6. М БРПО-05. Методология подготовки предприятия к сертификации процессов безопасной разработки программного обеспечения средств защиты информации в соответствии с требованиями ФСТЭК России. 30 часов/3 дня.

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

• Вебинары – это теория. На курсах вы получите практические навыки, знакомясь с продуктами лидеров рынка РФ по РБПО.

• УЦ "Маском" имеет лицензию на учебную деятельность и право давать официальный документ о повышении квалификации и прохождении профессиональной переподготовки.

• Официальный документ об обучении требуется для экспертов органов/лабораторий в системах сертификации ФСТЭК России и Минобороны России.

• Программа М БРПО-Спец "Специалист по процессам разработки безопасного ПО" (200 часов/20 дней) официально согласована с ФСТЭК России.

• Человеческий фактор. Не все сотрудники достаточно мотивированы самостоятельно глубоко изучить тему РБПО. Курсы станут поводом выделить на это время.

P.S. В конце не могу не упомянуть про курс "ПВС СТАТ" – Статический анализ программного обеспечения в соответствии с требованиями ГОСТ Р 71207–2024 с применением PVS-Studio. 30 часов/3 дня.

Сегодня межсетевой экран нового поколения (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 или это дорогостоящее развлечение для зрелых команд.

Отдельно поговорили про выгорание: добавляет ли плановый хаос тревожности инженерам — или, наоборот, снимает её.

Если вы хоть раз думали «у нас и так всё нестабильно, зачем ещё специально ломать» — этот выпуск именно про вас.

Слушайте и смотрите на площадках

• 📺 YouTube

• 💻 Rutube

• 📱 VK

И подписывайтесь на телеграм-канал 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)

Открываем регистрацию на Альфа ЦТФ 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 | 📝 Хабр | 💙 ВКонтакте