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

По определенным обстоятельствам я не могу тупо дропать звонки от неизвестных. Но скаммерсанты достают. Что делать ? Все очень просто:

1) подождать пока отзвонит. 2 сек на звонок - тоже нехороший признак но не 100%.

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

2) номер телефона из пропущенных копипастом в ватсапп "+ создать новый контакт". если "этот номер телефона не зарегистрирован ... пригласить" то пошли они. в телеграме то же самое.

3) если мессенджер взял контакт, то стандартно: "Здравствуйте, от вас один пропущенный", если в ответ скам то бан и жалоба.

ps: мошонники и скаммерсанты, а также честные колл-центры ! не стесняйтесь регистрировать мессенджеры wa/tg на свои 1разовые sim-карты. вас ждет много удивительных приключений.

об электронной подписи

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

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

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

Вопросов много. Среди основных:

1. Как возможно признавать "токен", то есть обыкновенную флэшку, средством подписи? Вообще, термин "токен" здесь принесен из программирования и не совсем, как бы сказать, оправданно. Так как токен в обычном значении - это код, формируемый для каждой транзакции и каждый раз он меняется.

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

   И, самое главное - флэшка отделяема от человека и не является действием.

2. Как возможно идентифицировать, кем или чем (в случае алгоритмов) подписан документ в случае ЭЦП?

3. Недавняя ситуация с одним из крупнейших коммерческих сервисов по электронному подписанию документов, когда системой не был определен вирус и распространился по ЭДО в автоматическом режиме, намекает на вопрос, что произойдет, если уже не произошло, когда будут "подписываться" миллионы документов вирусом по API.

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

   Нам всем надо выдохнуть и посмотреть на ситуацию здраво. Да, многое создано, многое "подписано", но замалчивать эту ситуацию дальше становится опасно. Возглас Касперской услышан и поддержан многими, но он так и не оценен.

Вебинар "От кода до запуска: российский стек для Java — Axiom JDK и OpenIDE"

Приглашаем на вебинар, посвященный безопасному стеку базовых технологий для разработки и исполнения Java-приложений и безопасной среде разработке OpenIDE. Вы поймете, что такое OpenIDE, как это всё относится к Intellij IDEA, зачем OpenIDE бизнесу и какие у проекта OpenIDE планы на будущее.

Кому будет полезен вебинар:
• тимлидам
• разработчикам
• DevOps

Вебинар проведут:
• Дмитрий Сапожников, технологический консультант Axiom JDK
• Илья Сазонов, директор по продуктам Axiom JDK, направления Spring и OpenIDE

Когда: 21 августа 2025 г.

Во сколько: 11:00–12:30 по мск

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

Участие: Бесплатное (нужно предварительно зарегистрироваться)

ИБ-ДАЙДЖЕСТ INFOWATCH

Больше миллиона человек пострадали от утечки данных лабораторий для диализа компании DaVita — скомпрометированы ПДн, финансовая и медицинская информация.

Хакеры завладели ПДн участников Венецианского кинофестиваля, но его представители утверждают, что это не повлияет на работу мероприятия этого года.

Сеть онкологических клиник Highlands Oncology Group призналась в утечке ПДн более 113 тыс. пациентов — они могут добиться компенсации, подав коллективный иск.

Авиакомпании KLM и Air France сообщили об утечке данных пассажиров, произошедшей на стороне их внешнего партнера.

У рентгенологической компании Northwest Radiologists злоумышленники украли ПДн около 350 тыс. пациентов из штата Вашингтон.

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

Попросил GPT5 написать скрипт для приложения 3ds max, который сможет информировать об потенциальных угрозах в 3d-сцене программы. После нескольких часов возни и исправлений, скрипт заработал и отлично показал себя в деле, обнаружив в сцене имитационный вредоносный код.

Кто из специалистов может посмотреть этот код? Будет от него реальная польза или это бесполезная пустышка?

По словам ИИ, MaxScript по синтаксису напоминает смесь JavaScript + Pascal, с динамической типизацией.

/*
   MaxScript Exorcist 3.1 (fixed - helpers moved to top-level)
   - Исправлена ошибка "No outer local variable references permitted here"
   - Вспомогательные функции вынесены на верхний уровень
   - Проверка папки с .ms/.mcr/.mse
   - Расширенное сканирование сцены (все свойства, контроллеры, материалы, XRef)
   - ⚡ Подсветка найденных потенциально опасных токенов
   - Авторы: Юра и GPT5-mini
*/

-- ===== GLOBAL PATTERNS =====
global patterns
patterns = #(
    "shell",
    "cmd\.exe",
    "CreateProcess",
    "WinExec",
    "system\s*\(",
    "Process\.Start",
    "ProcessStartInfo",
    "DotNet\.loadAssembly",
    "LoadAssembly",
    "LoadLibrary",
    "ImportDLL",
    "dll",
    "WriteLine\s*\(",
    "Write\s*\(",
    "DeleteFile\s*\(",
    "removeFile",
    "renameFile",
    "copyFile",
    "RunScript",
    "Execute",
    "openFile",
    "fileStream",
    "StartProcess",
    "Run",
    "ShellExecute",
    "regsvr32",
    "CreateObject",
    "WScript",
    "ActiveXObject"
)

-- ===== Helper: read ASCII strings from binary .mse =====
fn readBinaryStrings filePath =
(
    local strings = #()
    try
    (
        local f = openFile filePath mode:"rb"
        local buf = ""
        while not eof f do
        (
            local b = readByte f
            if b >= 32 and b <= 126 then buf += (bit.intAsChar b)
            else
            (
                if buf.count >= 4 then append strings buf
                buf = ""
            )
        )
        if buf.count >= 4 then append strings buf
        close f
    )
    catch()
    return strings
)

-- ===== Helper: scan files in folder (text and .mse) =====
fn scanFilesInFolder folderPath =
(
    local suspicious = #()
    local files = getFiles (folderPath + "\\*.ms*")
    if files.count == 0 then
    (
        format "No .ms/.mcr/.mse files found in %\n" folderPath
        return suspicious
    )

    for f in files do
    (
        local isText = true
        local content = ""
        try
        (
            if matchPattern f pattern:"*.mse" then
            (
                local lines = readBinaryStrings f
                for l in lines do
                    for p in patterns do
                        -- сравниваем в нижнем регистре для устойчивости
                        if findString (toLower l) (toLower p) != undefined then append suspicious #(f, p)
                isText = false
            )
            else
            (
                local fh = openFile f mode:"r"
                while not eof fh do content += readLine fh + "\n"
                close fh
            )
        )
        catch
        (
            isText = false
            append suspicious #(f, "<binary or unreadable>")
        )

        if isText then
            for p in patterns do if findString (toLower content) (toLower p) != undefined then append suspicious #(f, p)
    )

    return suspicious
)

-- ===== Helper: recursive scan of an object (uses global 'patterns') =====
fn scanObjectRecursively obj =
(
    local findings = #()
    try
    (
        -- Все свойства объекта (без аварий при чтении)
        local propNames = #()
        try ( propNames = getPropNames obj ) catch()
        for p in propNames do
        (
            try
            (
                local val = getProperty obj p
                if classOf val == String then
                (
                    for pattern in patterns do
                        if matchPattern val pattern pattern:"regex" then append findings #(obj.name, p, pattern)

Это же шутка, да? Ведь, да?(С)падме.джпг

https://www.securitylab.ru/blog/personal/Bitshield/355756.php

Самое серьёзное обвинение связано с подозрением, что MAX передаёт пользовательские данные на зарубежные серверы. Автор Telegram-канала Scamshot утверждает, что с последним обновлением мессенджер получил полный доступ к буферу обмена смартфона и начал собирать информацию обо всех установленных приложениях, после чего эти данные якобы отправляются за пределы России.

Особенно иронично выглядит тот факт, что мессенджер, позиционируемый как «полностью отечественный», использует библиотеки из «недружественных стран». В коде MAX обнаружили украинскую библиотеку uCrop от компании Yalantis, а также компоненты из США и Польши. Критики язвительно называют это «безопасным национальным мессенджером с утечкой данных непосредственно в днепровские офисы».

Квиз: насколько вы разбираетесь в законодательстве и ИБ

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

Квиз проверит, насколько глубоко вы в теме. 

Пройти квиз

Ответьте на девять вопросов и получите подборку полезных материалов. Не забудьте заглянуть в комментарии поделиться своим рекордом.

Интеграция PVS-Studio в Inseq RBPO

Компания PVS-Studio и Inseq заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.

Программное обеспечение Inseq RBPO предназначено для создания и управления конфигурациями, необходимыми для автоматического развёртывания и настройки компонентов инфраструктуры безопасной разработки ПО — систем контроля версий, анализаторов кода, инструментов автоматизации сборки, тестирования и развёртывания. Управление конфигурациями и политиками безопасности осуществляется централизованно.

"ИНСЕК.РБПО" представляет собой клиент-серверную систему, работающую на локальном оборудовании. Она включает серверную часть, генерирующую конфигурационные файлы, и веб-приложение с графическим интерфейсом для взаимодействия с пользователями.

Внутри этой платформы стало возможным использовать статический анализатор PVS-Studio для поиска критических ошибок в исходном коде.

Также мы провели вебинар с коллегами из Inseq, в котором поговорили о необходимости регулярного статического анализа, а также в целом об автоматизации в РБПО.

Стань спикером SOC Forum 2025 — сделай вклад в развитие безопасного цифрового общества

С 17 по 23 ноября состоится Российская неделя кибербезопасности — масштабная серия событий для обсуждения темы ИБ в государстве, бизнесе и граждан. Главная цель Недели — создание и развитие безопасного цифрового общества. Ее ядром станет ежегодный SOC Forum, который пройдет в Москве 19-20 ноября. Форум притянет еще больше профессионалов и лидеров отрасли для выстраивания стратегий защиты от самых актуальных киберугроз. Сбор докладов на форум уже открыт. ГК «Солар» — организатор Недели и соорганизатор форума.

SOC Forum 2025 – это:

• Новая масштабная площадка — «Тимирязев центр»;

• 9 тематических треков – о влиянии ИИ на киберугрозы и отражение атак, о поиске и удержании талантливых ИБ-специалистов, о преобразовании данных о кибератаках в конкретные меры защиты и другие;

• Больше форматов – от воркшопов и питч-сессий до персональных встреч.

Сбор докладов: без продаж и «воды»

Сбор докладов на SOC Forum продлится до 14 сентября. Чтобы стать спикером, необходимо заполнить заявку в личном кабинете на сайте форума с описанием доклада, выбрав подходящий тематический трек. До 30 сентября все заявки будут оценены компетентным жюри, в составе которого — эксперты крупнейших компаний отрасли и представители профильных ведомств.

При оценке докладов жюри будут учитывать: актуальность, новизну и практическую пользу. Жюри будет отклонять заявки с рекламой продуктов или услуг без уникальных кейсов, а также попытками «продать», а не поделиться экспертизой. Это означает, что на SOC Forum попадут только самые острые для ИБ-сообщества доклады, все они будут уникальны и полезны участникам отрасли. В прошлом году конкурсное жюри отобрало 151 заявку из 354 поданных.

Новые треки: ИИ и люди на защите от киберугроз

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

День 1 (19 ноября):

• AI & Cybersecurity: как искусственный интеллект меняет ландшафт киберугроз, инструменты защиты и ставит этические вопросы перед ИБ и ИТ- сообществом;

• Естественный интеллект: как искать талантливых ИБ-специалистов, грамотно оценивать их навыки и сохранять мотивацию;

• ИБ и бизнес: как CISO и ИБ команды могут не только защищать, но и помогать компаниям выигрывать у конкурентов и снижать риски простоя бизнес-процессов;

• Тренды и аналитика угроз: как превращать данные о киберугрозах в конкретные меры защиты, чтобы оставаться на шаг впереди хакеров;

• Многогранный кибербез: cамые нестандартные и экспериментальные темы отрасли.

День 2 (20 ноября):

• Offense: технические разборы и кейсы реальных кибератак от лучших ИБ-специалистов и пентестеров;

• Defense: разбор наиболее актуальных технологий защиты, реагирования и обнаружения киберугроз, а также закрытия уязвимостей, которые «невозможно исправить»;

• Архитектура ИТ и ИБ: как построить безопасную комплексную архитектуру для защиты не только «здесь и сейчас», но и на долгие годы вперед;

• SOC-практикум: обсуждения наиболее эффективных кейсов работы с NTA/EDR, SIEM и другими техническими средствами.

Компания «Доктор Веб» выпустила практические рекомендации по усилению безопасности ИТ-инфраструктуры для компаний и сотрудников по ИБ. Документ основан на многолетнем опыте работы службы технической поддержки «Доктор Веб» и департамента по расшифровке файлов,

Стартовала работа над новым бумажным спецвыпуском журнала «Хакер». На этот раз в коллекционный сборник войдут лучшие статьи, опубликованные в 2025 году: от разбора сетевых протоколов до хакерских применений LLM.

После выпуска трёх бумажных сборников с архивными статьями за 2015–2021 годы в «Хакере» решили попробовать новый формат: журнал, в котором будут собраны лучшие статьи за год. В новый номер войдут более 20 топовых текстов, публиковавшихся на страницах «Хакера» в 2025 году. Каждая статья по традиции будет сопровождаться уникальными комментариями от авторов и редакторов, которые позволят заглянуть за кулисы работы журнала. 240 страниц на плотной бумаге — вдвое толще старых номеров «Хакера» образца 2015 года.

Лучшие статьи за год, подшивка всего самого интересного:

• Автоматизация хакерских тасков при помощи LLM;

• Полный гайд по разведке перед пентестом;

• Разбор популярных сетевых протоколов с примерами;

• Туториал по опенсорсному отладчику radare2;

• Новые способы обфускации малвари в Windows;

• Хакерские трюки и софт для Android;

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

Интеграция PVS-Studio с Hexway

Компания PVS-Studio и платформа Hexway заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.

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

В Hexway стало возможным загрузить результаты анализа PVS-Studio в виде отчёта и работать с конкретными ошибками так же, как это позволяют другие инструменты. Загрузка возможна двумя способами: через пользовательский интерфейс или командную строку с использованием CLI-инструментов.

Подробнее о том, как загрузить результаты анализа PVS-Studio в Hexway VamPy можно прочитать в соответствующем разделе нашей документации.

Как обойти защиту JWT?

В этом видео инженер по безопасности приложений Swordfish Security Денис Данилов разбирает уязвимость стандарта передачи данных JSON Web Token (JWT).

Суть уязвимости

JWT состоит из трех частей:

• Header — заголовок, где указывается алгоритм подписи (например, HS256),

• Payload — полезная нагрузка (данные пользователя, роли и т. д.),

• Signature — подпись, которая формируется с помощью секретного ключа.

Проблема возникает, если сервер не проверяет, какой алгоритм указан в заголовке. Если там стоит alg: "None", библиотека может интерпретировать это буквально — и не проверять подпись вовсе.

В результате злоумышленник может:

• извлечь JWT токен (например, из cookies),

• заменить полезную нагрузку (например, указать "role": "admin"),

• подставить alg: "None" в заголовке,

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

Как научиться находить такие уязвимости?

Такой тип ошибки — не уникален для JWT. Это общий паттерн: разработчик полагается на библиотеку, не разбираясь в деталях. В продакшене такие недочёты дорого обходятся — и бизнесу, и карьере инженера.

Swordfish Security мы регулярно сталкиваемся с подобными уязвимостями в реальных проектах. Опыт показывает: даже базовое понимание архитектуры протоколов и моделей угроз помогает разработчикам предотвращать критичные ошибки ещё на этапе проектирования. Этот кейс, кстати, — часть одного из модулей курса по DevSecOps нашей академии, где мы разбираем типовые уязвимости и подходы к их предотвращению.

Благодаря найденной уязвимости я зарегистрировал CVE-2024-45244, попал на спикер-пати OffZone 2024 (как докладчик) и в топ-10 "Pentest Award 2025" (номинация Out Of Scope). А ведь этого всего могло бы и не быть, если бы я не продолжил настаивать на своём (невзирая на мнение моего тогдашнего тимлида). Уязвимость обнаружил несколько лет назад в процессе исследования безопасности коммерческого смарт-контракта. Сообщил тимлиду (отдел занимался безопасностью блокчейна) во всех подробностях, даже макет с результатами показал и описал. Но, тимлид проигнорировал мою находку. Он до этой работы не имел практического опыта в безопасности (был разработчиком). Врезалось в память, как он называл себя "самым компетентным по блокчейнам в отделе". После моего отказа на предложение добровольно стать "козлом отпущения", у него появились претензии к моей работе. Мол, это я ничего не смыслю в безопасности блокчейнов. В какой-то момент он даже позвал HR бизнес-партнёра на 3-х сторонний диалог (видимо, показать, что он не одинок во мнении насчёт моей компетенции). HR весь наш диалог молчала, "считая ворон". А в конце выдала гениальное: я не поспеваю за темпом компании в безопасности. И, вообще-то, очень плохо, что я не внимаю мнению руководителя - тимлидом абы кого не ставят (видимо, кейс с президентом Ельциным молодое поколение HR-ов и не знает). Учитывая, что у компании одной из целей был поиск CVE в блокчейнах, и на текущий момент в публичной плоскости у них так ни одной CVE в этой области не появилось - большой вопрос: кто за кем не поспел.

Сегодня, прочитав статью "Когда руководитель не руководитель. Синдром «Самого умного» я вспомнил не только разработчиков блокчейна, пафосно уверявших меня, что проблемы нет, они-то лучше меня знают свой продукт. А фикс - только чтоб меня успокоить (подробнее в статье "Как я зарегистрировал CVE и разозлил вендора"). Я также вспомнил своего бывшего тимлида. И ведь такие люди - не редкость. На одной из лекций психологу задали вопрос почему среди руководителей часто нарциссы? Ответ: обычный человек 10 раз подумает стоит ли идти в руководители. У нарциссов же это желанная цель: уже самой своей должностью показывать подчинённым кто в доме хозяин. Надо сказать, что такие люди любят публичный вынос "сора из избы". Пример с этим тимлидом - на картинке.

Что делать когда сталкиваешься с такими людьми? Это дело каждого. Но, лично я солидарен с психологом: не пытаться что-то им доказать, не вестись на провокации, и постараться не пересекаться в жизни (если нужно - сменить работу). Ну, и CVE, OFFZONE, Pentest award - те вещи, которые вряд ли бы появились, если бы не сменил работодателя.

Проект Zero Day Initiative (ZDI) сообщил о проведении соревнований Pwn2Own Ireland 2025, которые состоятся в середине октября 2025 года в Ирландии. Участникам предложено продемонстрировать эксплоиты для ранее неизвестных уязвимостей (0-day) в смартфонах, мессенджерах, беспроводных точках доступа, устройствах для умного дома, принтерах, сетевых хранилищах, системах видеонаблюдения и устройствах виртуальной /дополненной реальности. Атака должна быть проведена на самые свежие программы и операционные системы со всеми доступными обновлениями и в конфигурации по умолчанию.

Мероприятие примечательно готовностью выплатить миллион долларов за выявление в мессенджере WhatsApp ошибки, позволяющей удалённо выполнить код без действия пользователя (0-click). За удалённо эксплуатируемую уязвимость в WhatsApp, требующую действий пользователя (1-click), премия составляет 500 тысяч долларов, за уязвимость, приводящую к захвату учётной записи - $150 тысяч, а за получение удалённого доступа к данным пользователя, микрофону или камере - $130 тысяч.

В категории "мобильные телефоны" за удалённую эксплуатацию уязвимости в смартфонах Google Pixel 9 и Apple iPhone 16 назначена премия 300 тысяч долларов. При этом введена новая категория - взлом устройства при подключении по USB c размером премии $75 тысяч. За удалённый взлом 3D-шлема Meta Quest 3/3S и умных очков Meta Ray-Ban назначено вознаграждение в $150 тысяч. Максимальный размер премии за взлом устройств умного дома и сетевых хранилищ составляет $50 тысяч, систем видеонаблюдения - $30 тысяч, а принтеров - $20 тысяч.

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

1. Зарегистрироваться по своему номеру телефона в двух-трёх мессенджерах из разных юрисдикций, в которых есть функции сквозного шифрования. Например, в Телеграм, Signal и Wire.

2. Включить в мессенджерах сквозное шифрование и выключить резервное копирование сообщений.

3. Одному собеседнику сгенерировать и выслать второму составные части ключа шифрования в разных мессенджерах. Например, три части по 85, 85 и 86 (суммарно 256) бит.

4. После приема частей ключа получателю объединить их и хранить в надёжном месте.

5. Обоим собеседникам удалить отправленные сообщения с ключом.

6. Установить у себя приложения для шифрования сообщений. Например,  Secure Text, где используется AES. Отменить у приложения разрешения на доступ к функциям своих устройств связи.

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

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

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

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

Краткий (и не краткий) экскурс в ГОСТ Р 56939-2024 – РБПО

Недавно мои коллеги обработали и опубликовал пятую — финальную — часть моего рассказа про ГОСТ Р 56939-2024 – Разработка безопасного программного обеспечения. Поскольку все части записывались сразу, к моменту выхода этого заключительного видео я понимаю, что сейчас бы немного иначе его сделал. Видение меняется, появляется новая информация. Например, завершился этап домашнего задания испытаний анализаторов кода, и про это стоило бы упомянуть. Или, например, появилась эта методическая рекомендация, про которую стоило бы рассказать.

Но не страшно, про новое расскажем в рамках других митапов и вебинаров. А пока, вот все части общего обзора:

1.      Причины разработки и выпуска нового ГОСТ Р 56939-2024 на замену версии 2016 года

2.      Содержание ГОСТ Р 56939-2024 и его структура

3.      Процессы РБПО 5.1-5.10 в ГОСТ Р 56939-2024

4.      Процессы РБПО 5.11-5.25 в ГОСТ Р 56939-2024

5.      ГОСТ Р 56939-2024: вопросы сертификации, выводы и дополнительные ссылки

Но на этом история не закончилась. Сейчас вместе с УЦ "МАСКОМ" и приглашёнными гостями-экспертами мы записываем подробный цикл вебинаров про каждый из 25 процессов, описанных в стандарте.

Приглашаю смотреть уже записанные встречи и участвовать в новых: Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024.

Интеграция PVS-Studio c AppSecHub

Компания PVS-Studio и платформа AppSec.Hub заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.

AppSec.Hub — это платформа для автоматизации процессов Application Security, которая позволяет объединять различные инструменты анализа, тестирования и мониторинга безопасности приложений.

Отчёт анализатора PVS-Studio теперь можно загрузить для просмотра в платформу AppSecHub вручную с помощью пользовательского интерфейса инструмента либо с помощью специальной утилиты командной строки.

Подробнее о работе PVS-Studio в AppSec.Hub можно прочитать в посвящённом этому разделе документации.

Также мы провели вебинар с коллегами из AppSec Solutions, чтобы на практике показать, как инструменты работают вместе, а также поделиться полезным опытом в интеграции статического анализа в DevSecOps.

Хотел как лучше, а получилось... или снова о качестве описания CVE

В статье "Как я зарегистрировал CVE и разозлил вендора" я писал:

Желательно, чтобы CVE были достаточно хорошо описаны. У CVE-2024-45244 на данный момент есть некоторые проблемы. Описание в части версий некорректно: на момент создания CVE версия 2.5.9 была крайней в своей ветке. Но, далее в этой ветке продолжился выпуск версий без фикса. Фикс для стабильных версий вышел в рамках версии 3.0.0. Я планирую обратиться в MITRE с целью улучшить содержательную часть CVE.

После моего обращения описание CVE было обновлено. Было:

Hyperledger Fabric through 2.5.9 does not verify that a request has a timestamp within the expected time window.

Стало:

Hyperledger Fabric through 3.0.0 and 2.5.x through 2.5.9 do not verify that a request has a timestamp within the expected time window.

Честно говоря, такое описание вводит меня в ступор. Например, версия 2.5.13 по такому описанию уязвима? С одной стороны да: она до 3.0.0. С другой - нет: она после 2.5.9. И, если я не ошибаюсь, в версиях 2.4.х проблема тоже есть.

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

Всё это в очередной раз наводит на мысли, что доверять описанию CVE полностью нельзя. И качество анализа CVE влияет на безопасность: у атакующих может быть преимущество, если они дотошно перепроверяют условия реализации уязвимости. А у защищающихся часто нет такой дотошности (часто - из-за огромного количества уязвимостей, с которыми работаешь в рамках Vulnerability Management). В итоге в этой гонке у атакующих бывает преимущество. Помнится, я даже для CTF задачку на эту тему делал: изюминка была связана именно с неверным описанием CVE в части версий. К сожалению, тогда работодатель мою идею не одобрил. А ведь это был бы хороший практический урок для начинающих специалистов по безопасности.

Проблема с описанием версий иногда обостряется из-за позиции вендора. Как я писал в статье:

Разработчики, имея больше информации о своём продукте, могли бы повлиять на более точное описание CVE. Но, вместо этого им захотелось устроить борьбу "за честь мундира".

В процессе подготовки статьи "Как я зарегистрировал CVE и разозлил вендора" я искал статьи с практическими результатами по подмене локального времени жертвы (при синхронизации через NTP). Это оказалось нелегко: чаще всего статьи были теоретическими. Но, я нашёл и довольно интересную статью от 07.11.2024: Quantitative Risk Analysis of Network Time Protocol (NTP) Spoofing Attacks. Часть вопросов, которые изучаются в статье:

• рассмотрены атаки на ntpd, NTPSec, chrony, и OpenNTPD;

• оценивается возможность максимального смещения времени атакой (в условиях защитных механизмов атакуемых утилит);

• рассматриваются сложности атак.

Указывается, что остаются вопросы для дальнейшего изучения. Например, в части встроенных в различные ОС механизмов синхронизации времени.

Помимо этих вопросов - вот вопросы, которые у меня остались.

• Когда именно происходит синхронизация времени через утилиты или в ОС в обычной жизни? И как часто? Т.е. сколько времени нужно ждать атакующему для возможности совершить атаку? Принудительный перезапуск утилиты не рассматриваем.

• DHCP предусматривает периодическое обновление данных - не только IP-адрес, шлюз по-умолчанию и DNS. А и NTP (пример настройки NTP для DHCP в маршрутизаторе MikroTik). И тут 2 варианта атаки: либо получен доступ к DHCP серверу, либо подмена DHCP-пакетов (при атаке "человек посередине"). Как эти варианты атаки скажутся на системное время различных ОС, сконфигурированных по-разному (в т.ч. если даже в ОС используется более безопасный вариант вроде NTPSec и др.)? Тем более, что подмена NTP-сервера через DHCP во многом лишена тех сложностей, что описываются в статье.

• UPD: другой вариант - отравить кэш локального DNS-сервера (если в качестве сервера времени прописано доменное имя). Допустим, клиенты получают время от 0.ru.pool.ntp.org. И в качестве DNS сервера у них прописан роутер MikroTik, подверженный CVE-2019-3978.

Было бы любопытно ознакомиться с существующими best practices синхронизации времени, учитывающими все вышеуказанные риски (либо хотя бы пытающиеся их учитывать).

Другие статьи на эту же тему:

• Securing NTP against MITM attacks (от 09.12.2022);

• Как синхронизация времени стала безопасной (от 09.06.2020).