Архив метки: vulnerability

Средства Детектирования Уязвимостей Сетевого Периметра (СДУСП)

Средства Детектирования Уязвимостей Сетевого Периметра (СДУСП)

2. Средства Детектирования Уязвимостей Сетевого Периметра (СДУСП)

Позволяют детектировать известные уязвимости CVE/БДУ, мисконфигурации и (частично) неизвестные уязвимости (например XSS в самописном веб-приложении) для активов, которые публично доступны из Интернет. Для сбора информации об активах используется активное сетевое сканирование. Сканирование производится с внешней площадки вендора, что обеспечивает взгляд на анализируемую инфраструктуру как у атакующего.

Metascan. Специализированный облачный сервис для детектирования уязвимостей инфраструктуры доступной из Интернет. Позволяет детектировать уязвимости для оборудования, системных сервисов и веб-приложений. Для детектирования уязвимостей использует свой веб-краулер, модули собственной разработки и на основе свободного ПО. Позволяет проводить проверку TCP/UDP портов на соответствие белому списку. Сервис также включает экспертное сопровождение: анализ обнаруженных уязвимостей, демонстрацию PoC и команд для эксплуатации, участие в совместных планерках по состоянию сетевого периметра.

СКАНФЭКТОРИ. Специализированный облачный сервис для детектирования уязвимостей инфраструктуры доступной из Интернет. В рамках одной платформы предоставляет доступ к 16 сканерам безопасности системных сервисов и веб-приложений. В качестве дополнительной услуги возможна верификации результатов детектирования экспертами.

Group-IB - Attack Surface Management. Решение для контроля внешней поверхностью атаки. Включает возможности по инвентаризации IT-активов и детектированию уязвимостей связанных с ними. Позволяет выявлять теневые IT-активы, неизвестные в организации. С помощью решения также возможно контролировать утечки учетных записей и данных в Dark web.

BI ZONE - CPT (Continuous Penetration Testing). Решение для постоянного контроля защищенности внешнего IT-периметра организации. Сочетает автоматизированное сканирование на наличие уязвимостей и ручную верификацию найденных уязвимостей экспертами. Эксперты также сопровождают подтвержденные уязвимости рекомендациями по устранению.

МТС RED - Сicada 8. Платформа для централизованного управления уязвимостями внешнего периметра с экспертным сопровождением и возможностью отслеживания киберугроз в реальном времени.

Первые впечатления от мартовского Microsoft Patch Tuesday

Первые впечатления от мартовского Microsoft Patch Tuesday

Первые впечатления от мартовского Microsoft Patch Tuesday. Довольно лихо, бодрит. 😈

1. Elevation of Privilege - Microsoft Outlook (CVE-2023-23397). Какая-то лютая жесть. 😱

"Уязвимость можно проэксплуатировать, отправив вредоносное электронное письмо жертве с уязвимой версией Outlook. Когда письмо обрабатывается сервером, может быть установлено соединение с устройством, контролируемым злоумышленником, что приведет к утечке Net-NTLMv2 хэша получателя письма. Злоумышленник может использовать этот хэш для аутентификации в качестве жертвы-получателя письма в NTLM relay атаке. Microsoft отмечает, что эта эксплуатация может произойти до того, как электронное письмо будет просмотрено в Preview Pane, а это означает, что для успешной атаки не требуется никакого взаимодействия со стороны жертвы-получателя письма."

Ничего себе EoP! 😄 Существует функциональный эксплоит и есть признаки эксплуатации в реальных атаках.

2. Security Feature Bypass - Windows SmartScreen (CVE-2023-24880). Обходят функциональность Mark of the Web (MoTW). Пишут, что Microsoft Office доверяет документам с MoTW, а значит эта уязвимость упростит распространения малварей. Существует функциональный эксплоит и есть признаки эксплуатации в атаках.

3. Remote Code Execution - HTTP Protocol Stack (CVE-2023-23392). Позволяет атаковать Windows Server 2022 с включенным HTTP/3 и buffered I/O. Тут хотя бы пока без эксплоитов и атак.

4. Remote Code Execution - ICMP (CVE-2023-23415). Послал фрагментированный IP пакет на уязвимый таргет - получил на нем RCE. Пока в теории, но если это действительно будет так жестко, то мало не покажется.

Драфт Vulristics-отчета: https://avleonov.com/vulristics_reports/ms_patch_tuesday_march2023_report_with_comments_ext_img.html
Вроде выглядит прилично, думаю финальный будет выглядеть +- также, только комментариев прибавится.

Про дипломные проекты в ВУЗах

Про дипломные проекты в ВУЗах. Недавно спрашивали про актуальные темы для диплома в области ИБ.

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

Если это не вариант, то можно дипломный проект воспринимать как инструмент для последующего трудоустройства. Смотрим на рынок - ищем "компанию мечты", выясняем чем они занимаются, выбираем тему из того, что хорошо будет смотреться на будущем собесе. 😏 Допустим компания это вендор какого-то продукта по ИБ, в разработке которого нам было бы интересно поучаствовать. Собираем проблемы/тренды для этого класса продуктов (для VM-а недавно скидывал) и попытаемся предложить для какой-нибудь из проблем свое решение. Такой дипломный проект это отличная тема для разговора на собесе (важно: даже если про тему диплома написано в резюме, не забудьте голосом акцентировать внимание на этом!). Будете выглядеть уже не как "белый лист", а как специалист с некоторым практическим опытом, который может приносить пользу практически с первого дня. Это дорогого стоит. Ну и в процессе подготовки дипломного проекта неизбежно прокачаетесь в нужную сторону. 😉

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

Сюрприз в обновлениях прошивок принтеров от HP

Сюрприз в обновлениях прошивок принтеров от HP

Сюрприз в обновлениях прошивок принтеров от HP. Наглядная демонстрация того, что вендор может привнести с обновлениями любую функциональность, даже совершенно нежелательную для пользователя. В принтерах HP с 2016 года используется функция динамической безопасности, позволяющая отличать родные картриджи HP от совместимых картриджей сторонних производителей. Раньше при использовании неродных картриджей просто показывалось предупреждение, а теперь, после недавнего обновления прошивки, стала полностью блокироваться работа устройств. Все с заботой о пользователе, "для защиты качества клиентского опыта". 😏

Совсем не обновлять прошивки устройств я, конечно, посоветовать не могу (см. уязвимость Lexmark). Но стоит внимательнее подходить к выбору устройств, учитывая возможность и таких финтов.

Вышла третья итерация Exploit Prediction Scoring System (EPSS)

Вышла третья итерация Exploit Prediction Scoring System (EPSS)

Вышла третья итерация Exploit Prediction Scoring System (EPSS). Пишут, что стала на 82% круче. Есть довольно прикольная и подробная статья про изменения. Например, EPSS-ники начали анализировать не 16 свойств уязвимостей, а аж 1164. Есть подозрение, что большая часть этих свойств это лейблы вендоров, как в таблице. Но выяснять как оно конкретно работает дело всё равно малоперспективное, потому что "а внутри у ней нейронка" ©. В целом, по запутанности уже похоже на Tenable VPR. Но бесплатность всё искупает. 😇 Кстати, в статье упоминают Tenable VPR и прочие коммерческие скоры и критикуют их за проприетарность, публичную недоступность и то, что они частично базируются на экспертном мнении, а не только на данных.

Поглядел выгрузку EPSS на примерах.
1. Для RCE уязвимости Word-а (CVE-2023-21716) с недавним PoC-ом EPSS очень высокий (0.16846,0.95168).
2. Для SPNEGO (CVE-2022-37958), для которого эксплоит ожидается в Q2, EPSS тоже высокий (0.07896,0.93195).
3. Для рандомной уязвимости MS Edge (CVE-2023-0696) из февральского MS Patch Tuesday (их десятки каждый месяц), EPSS низкий (0.00062,0.24659)
4. Взял наоборот уязвимость с высоким EPSS из выгрузки - CVE-2023-0297 (0.04128,0.90834). Тоже понятно почему, там ссылка на эксплоит прямо в NVD.

На первый взгляд всё вполне адекватно. 👍

То есть делать приоритизацию исключительно на основе EPSS я бы не советовал, но использовать как дополнительный фактор с весом как у CVSS Base Score (а возможно и повыше) выглядит вполне оправданным. Совсем без причины эта цифирь вверх вряд ли поползет, если она идёт к 0.9 и выше имеет смысл поглядеть на уязвимость повнимательнее. Подумываю начать учитывать EPSS в Vulristics. 😉

Vulnerability Management чек-лист для финансовых организаций от Positive Technologies

Vulnerability Management чек-лист для финансовых организаций от Positive Technologies. Статья вышла в BIS Journal 22 февраля, но я только сейчас её увидел. Мне в целом, импонирует подход PT к VM процессу. Особенно то, что Евгений Полян и Анастасия Зуева транслируют в своих выступлениях. Поэтому мимо их совместной статьи пройти никак не мог. Собрал краткую выжимку, за деталями рекомендую обратиться к исходной статье.

1. ИТ и ИБ должны дружить и вместе работать над исправлением уязвимостей, иначе ничего не получится.

2. Если не исправлять уязвимости, это может привести к серьезным инцидентам и недопустимым событиям для бизнеса.

3. Разрабатываете/внедряете новую систему? Проверьте, что в ТЗ учтены:
3.1. Технологические окна для регулярных обновлений
3.2. Возможность сканирования (от меня: лучше даже шире - проверить, что есть средство детектирования уязвимостей для системы)
3.3. План реагирования на появление новых опасных уязвимостей для ИТ и ИБ

4. Пока не убрали уязвимости, новую систему в промышленную эксплуатацию не берем. Как взяли - продолжаем поддерживать уровень безопасности.

5. Три шага к организации процесса управления уязвимостями:
5.1. Определить перечень недопустимых для организации событий c бизнесом и ТОПами
5.2. Определить риск-рейтинг активов
5.3. Составить регламент работы и обслуживания каждого типа активов, согласовать с бизнесом и IT

6. Зафиксируйте роли подразделений:
6.1. Руководство компании - приоритеты и перечень недопустимых событий
6.2. Топ-менеджмент - перечень наиболее важных сервисов
6.3. ИТ-подразделение - обновление в соответствии с SLA
6.4. ИБ-подразделение - приоритеты устранения уязвимостей, критерии эффективности процессов ИБ, контроль уровня защищенности, определение ключевых активов

7. Определение сроков обновления систем и регламента обновлений:
7.1. Выделить ключевые активы (контроллеры домена, серверы Exchange, системы управления виртуализацией, рабочие станции администраторов и т.д.)
7.2. Установить регламенты по обновлению, определить SLA (и что делать если SLA будет нарушаться)
7.3. Для зарубежного ПО использовать алгоритм НКЦКИ и результаты тестирования обновлений ПО от ФСТЭК

Что мне нравится в этой статье: большой акцент на регулярных обновлениях. Ситуация когда месяцами-годами системы не патчатся и все ждут ИБ-шников, которые должны просканить и поставить задачу на обновление - это не норма. IT-шник, если есть обновление безопасности - иди ставь! ИБшник (VM-щик) нужен для того, чтобы удостовериться, что все хорошо и по регламенту работает, а не для того, чтобы всех пушить постоянно. Ну и для того, чтобы бить в рынду, когда появляется что-то реально критичное.

Что не особо нравится: "три шага" к организации процесса управления уязвимостями это, конечно, что-то из серии научной фантастики. Просто прекрасно, если где-то это действительно без оговорок запустилось, но это скорее не рекомендация к команде ИБ, а реклама крутого консалтинга, который такие штуки делать умеет. Про планирование новых проектов с требованиями по VM тоже все правильно, но отстаивать эти требования также будет ох как не просто. Наиболее практически полезной кажется идея, что наводить порядок нужно с ключевых активов и разгребаться дальше насколько ресурсов хватит.

Прочитал пост в блоге Rapid7 про разницу "Vulnerability Assessment" и "Vulnerability Management"

Прочитал пост в блоге Rapid7 про разницу "Vulnerability Assessment" и "Vulnerability Management".

О различии между VA и VM они пишут так: "Однако ключевое различие между ними заключается в том, что управление уязвимостями представляет собой непрерывный цикл, включающий vulnerability assessment. Там, где VA идентифицирует и классифицирует риски в вашей сетевой инфраструктуре, VM делает шаг вперед и включает решения о том, следует ли устранять, смягчать или принимать риски. VM также занимается общим улучшением инфраструктуры и созданием отчетов." Дальше просто описание VM-цикла от Gartner, который в жизни не встречается, уже разбирали его.

Люблю, когда люди хотят подчеркнуть большую разницу, чтобы продать свою дорогую VM-пепяку, а в итоге выходит, что как таковой разницы и нет. Если вы надетектили уязвимости как-то и приняли решение, что с ними дальше делать (устранять, смягчать, оставить как есть) и сделали отчет для начальства, то поздравляю, это уже Vulnerability Management. Как минимум исходя из поста в блоге Rapid7. 😉

Ещё порадовало, в Vulnerability Assessment они включают и детектирование уязвимостей в людях. "Эти уязвимости обычно относятся к одной из трех категорий: […] Человеческие. Эти уязвимости связаны с проблемами безопасности пользователей, такими как слабые (или утекшие) пароли, нажатие ссылок на вредоносных веб-сайтах и человеческие ошибки, такие как открытие фишингового электронного письма. Из трех категорий командам NetOps зачастую труднее всего контролировать и обеспечивать соблюдение требований для этой категории." Получается мешать VA/VM и Антифишинг это уже не придурь одного шведского VM-вендора, а уже почти мейнстрим. 😆