Архив рубрики: Уязвимости

Итак, вы решили начать разработку своего Vulnerability Management решения

2 комментария

Итак, вы решили начать разработку своего Vulnerability Management решения. Часть 2. А может лучше специализироваться?

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

* поддержку разных видов таргетов (все ОС, все third-party софты для этих ОС, ERP, базы данных, разнообразнейшие сетевые устройства, любые технологии виртуализации и прочее)
* разработку конкретные фич ("пентест-сканирование" без аутентификации, визуализация и приоритизация уязвимостей и прочее)

то может лучше не замахиваться на все сразу, а взять конкретный кусочек функциональности полноценного VM-продукта и выпустить специализированное решение? Если в большом VM вендоре кусочек функциональности пилит команда из 3-4 человек, то и для стартапа команда разработчиков понадобится примерно сопоставимая. И возможно за счёт фокусирования, конечный результат будет даже лучше.

Давайте на примерах:

1. Сканирования сетевого периметра без аутентификации. Тот самый EASM. Периметр у любой организации есть. Легко продавать как облачный сервис. Хорошо и для старта, и для дальнейшего развития в облачный VM (при желании). Из решений с российскими корнями можно посмотреть Metascan, ScanFactory. Из нероссийских ImmuniWeb. У Vulners есть бета такого сервиса, можете тоже заценить. 😉
2. Детектирование уязвимостей Linux-хостов по бюллетеням. Linux-овой инфраструктуры сейчас в компаниях много, будет ещё больше. Задача более-менее подъемная. Для каждого Linux дистриба необходимо разобраться с бюллетенями безопасности, научиться корректно сравнивать версии. Инвентаризацию хостов можно делать самим, а можно оставить самим клиентам и предоставить только API для проверки. Как пример Vulners Linux API и Vulns.io VM.
3. Сканирование сетевых устройств. Linux хосты можно проверять по пакетам, Windows хосты можно проверять дополнительной функциональностью, реализуемой в антивирусах (у Kaspersky например). А что делать с устройствами на которые агента не поставишь? Тут либо полноценный VM брать, либо самим что-то писать, либо брать решение специализирующееся на сетевых устройстах. С этого начинали Газинформсервис с продуктом Efros Config Inspector. Давно их не смотрел, сейчас, судя по описанию, они стали полноценным VM решением.
4. Сканирование ERP и других систем критически важных для бизнеса. Чем сложнее ПО, тем выше вероятность, что VM-решения не будут поддерживать его в достаточной мере. Взять например SAP. Из полноценных VM решений его только MaxPatrol 8 умеет сканировать, а TOP-3 мировых VM вендора нет и им норм. Поэтому и есть ниша, для специализированных решений, например ERPScan. Пример очень эффектной фишечки в ERPScan это возможность проэксплуатировать некоторые найденные уязвимости проямо из интерфейса.
5. Приоритизация уязвимостей. Существует масса решений, которые даже не пытаются сами детектировать уязвимости, а занимаются только агррегацией уязвимостей из сторонних продуктов-сканеров и последующей их приоритизацией. Как пример Kenna Security (теперь Cisco). Можно глянуть Faraday Security, у них есть бесплатная опенсурсная версия.
6. Фиды по уязвимостям. Каждый Vulnerability Management продукт это база уязвимостей + правила детектирования. Собрать хорошую базу уязвимостей, обогащенную данными об эксплоитах (и их зрелости), малварях и признаках эксплуатации вживую совсем не просто. Тут можно отметить платные фиды Vulners, Kaspersky, Vuldb, Risk Based Security VulnDB.

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

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

Видяшечка по мероприятию Код ИБ Безопасная Среда "Управление уязвимостями" успешно вышла

Добавить комментарий

Видяшечка по мероприятию Код ИБ Безопасная Среда "Управление уязвимостями" успешно вышла. На самом деле ещё 2 дня назад, но только сейчас дошли руки посмотреть и разметить. Отдельно выделил фрагменты, где, имхо, * самое огнище 🔥. Приглашаю заценить полностью или частично. Также посмотрите мои впечатления по мероприятию, если не читали.

Часть 1
* 1:05 - 2:32 Управление мисконфигурациями и управление уязвимостями, можно ли делать в рамках одного процесса? Леонов
* 2:32 - 3:45 А уязвимость процесса это часть VM? Какая функциональность входит в VM? Можно ли отталкиваться от функциональности САЗ? Родыгин, Леонов
* 3:45 - 6:15 А есть ли устоявшаяся терминология в VM? Пример: что такое Compliance Scan? Assessment и Mitigation plan. Ермаков
6:20 - 6:38 Smart Install в Cisco это уязвимость или мисконфигруация? Хлапов
6:42 - 7:34 Vulnerability, Weakness и Misconfiguration. О доверии экспертному мнению. Кузнецов
7:53 - 9:44 Уровни уязвимостей. Мисконфигурации это уязвимости. Волчков
* 10:12 - 14:53 А всякая ли небезопасная настройка приводит к уязвимости? На примере CIS Benchmarks. Нам нужны более лучшие стандарты. Кузнецов, Волчков, Леонов, Ермаков
14:55 - 15:44 Реализуемость уязвимости для конкретной системы. Родыгин
* 16:15 - 22:37 Трендовые эксплуатируемые уязвимости. Кузнецов, Леонов, Хлапов, Ермаков, Родыгин
22:50 - 26:27 Стандарты и требования по безопасной конфигурации: регуляторные и корпоративные. Волчков
* 26:27 - 27:55 Требования по управлению уязвимостями. Методичка по управлению патчами и уязвимостями для MaxPatrol на 300 страниц. Кузнецов
28:00 - 29:30 Стоит ли вообще устранять уязвимости? Родыгин, Волчков
29:30 - 52:58 Стоит ли устранять все уязвимости? Кузнецов, Леонов, Ермаков, Волчков, Хлапов, Родыгин
* -> 29:30 - 30:33 Не стоит устранять все, фокусироваться на детекте и реагированием на действия злоумышленника. Кузнецов
* -> 30:41 - 36:16 Нужно исправлять все уязвимости, если вы доверяете вендору. Леонов. Оппонируют Ермаков, Кузнецов, Родыгин
-> 36:16 - 36:55 Уязвимости могут становиться нереализуемыми из-за изменения архитектуры. Родыгин, Кузнецов
-> 36:55 - 38:41 Нужно ли оценивать реализуемость? Родыгин - да, Кузнецов - нет
-> 38:41 - 39:47 Все патчить невозможно. Хлапов, Родыгин
* -> 39:47 - 41:15 А почему нам больно патчиться? Леонов
-> 41:30 - 42:41 Пример кейса, когда патчиться не вариант. Кузнецов
-> 42:41 - 44:06 Переконфигурирование как способ ремедиации. Волчков
-> 44:06 - 47:07 Архитектурные изменения лучше патчинга. Родыгин. Оппонирует Кузнецов
* -> 47:07 - 48:19 Комментируем результаты опроса. Леонов, Родыгин, Волчков
-> 48:50 - 50:51 Автоматическая приоритизация на основе сетевых сегментов и ассетов. Хлапов, Кузнецов
* -> 50:51 - 52:58 Патчить нужно всё, потому что хорошая качественная сетевая сегментов это иллюзия. Ермаков

Часть 2 таймкодов Код ИБ Безопасная Среда "Управление уязвимостями" (в один пост не помещалось)

Добавить комментарий

Часть 2 таймкодов Код ИБ Безопасная Среда "Управление уязвимостями" (в один пост не помещалось)

52:58 - 1:04:42 Взаимодействие ИБ и ИТ в части управления уязвимостями. Волчков, Родыгин, Кузнецов, Хлапов
1:04:54 - 1:07:35 Автоматизация и централизованный менеджмент конфигураций. Волчков, Ермаков, Кузнецов
* 1:07:35 - 1:13:34 Инвентаризация ассетов и инвентаризация софтов как основа для Vulnerability и Compliance Management-а. Ермаков, Волчков, Кузнецов, Хлапов, Леонов, Родыгин
* 1:13:58 - 1:17:05 Конкретные решения на рынке для VM и CM. Леонов, Кузнецов, Хлапов
1:17:47 - 1:20:16 Решение SpaceBIT для CM. Волчков
1:21:06 - 1:33:59 Вопросы
-> 1:21:06 - 1:22:40 Как считать вероятность эксплуатации уязвимости? Кузнецов
* -> 1:23:20 - 1:24:44 Патчинг "ушедших" вендоров. Алгоритм НКЦКИ. Леонов, Родыгин, Кузнецов
-> 1:24:44 - 1:28:24 Внедрение CIS стандарта. Хлапов, Ермаков, Кузнецов, Волчков
-> 1:28:24 - 1:29:30 Кто должен заниматься безопасной настройкой. Кузнецов
* -> 1:29:30 - 1:33:59 Насколько можно доверять аудиту Windows хостов по аналогии с аудитом Linux хостов? Ограничения детектов сканеров. Леонов, Кузнецов, Родыгин
1:33:59 Завершающие слова.

Итак, вы решили начать разработку своего Vulnerability Management решения

3 комментария

Итак, вы решили начать разработку своего Vulnerability Management решения. Часть 1. Подводные камни.

Где-то с периодичностью раз в полгода ко мне приходят из какой-нибудь компании и говорят: "мы хотим разрабатывать свое решение по Управлению Уязвимостями как у ZZZ, расскажи что как и не хочешь ли поучаствовать?" Я на это обычно не то, чтобы отговариваю, но стараюсь подсветить сложности. Кажется пора уже это сформулировать в виде текста. Думаю будет полезно и тем, кто хочет запилить самописный VM в конкретной организации.

1. Основная сложность для вката в VMный рынок в устоявшемся ожидании, что VM решения должны детектировать уязвимости вообще во всем: все ОС (Linux дистрибы, Unix-ы, Windows, MacOS), все third-party софты для этих ОС, ERP, базы данных, разнообразнейшие сетевые устройства, любые технологии виртуализации и прочее. Все, что может встретиться у заказчика должно быть покрыто этим VM решением. Причем не только при сканировании с аутентификацией, но и без. И желательно ещё и смежные области тоже зацепить: AppSec DAST/SAST, DevOps, облака, IOT, SCADA, встраиваемые системы. Это даже не конкурентные преимущества, это база, нижняя планка для входа в рынок, что-то само собой разумеющееся.
2. Естественно абсолютного покрытия быть не может. Но если ожидания клиентов не будут биться с реальностью, если это будет заметно, особенно если в результате расследования инцидента, то маркетинговая иллюзия рухнет. Как и позиции вендора. Поэтому VM вендоры очень стараются соответствовать. Хотя бы для текущих и потенциальных заказчиков.
3. Необходимость покрытия всего значит, что вам, новому игроку, придется скопировать кадровую структуру больших VM вендоров. То есть под каждое направление из п.1. завести отдел как минимум из 2-3 человек. Они будут на фулл-тайме ресерчить где можно получить данные по уязвимостям для конкретных систем, как для этих систем устроен патчинг, будут писать проверки и автоматические генераторы проверок, тестить, что ничего не отъехало, дорабатывать при необходимости. Работа непростая, специфическая. Сам года 3 этим занимался. Людей под это нужно много ещё и с учётом того, что нужно догнать существующих VM вендоров с их десятками и сотнями тысяч проверок.
4. Всех этих людей нужно кормить. Откуда денег столько взять? Это подводит нас к тому, что конечное решение будет стоить дорого. Невозможно поддерживать такое хозяйство продавая безлимитный а-ля Nessus Professional за $3k в год. Это уже из серии демпинга. Вот продавая а-ля Tenable SC крупным компаниям с лицензированием по хостам - уже можно жить.
5. Такие продукты сами себя не продают. Поэтому также придется завести армию сейлов, пресейлов и маркетологов. А работа последних во многом и привела к ситуации из п.1, когда все с покерфейсом пытаются соответствовать невыполнимым требованиям при этом отмахиваясь, что качество детектирования это ерунда, не нужно на это обращать внимание, лучше на дашборды наши посмотрите. 🙂

В общем, невероятный вывод: чтобы делать полноценный VM нужно обладать командой и ресурсами как у Tenable, Qualys, Rapid7, Positive Technologies. 🙂 Ну или хотя бы как у Altx-soft, Secpod, Outpost24, F-Secure.

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

В полку Linux уязвимостей позволяющих поднять привилегии до root-а прибыло

Добавить комментарий

В полку Linux уязвимостей позволяющих поднять привилегии до root-а прибыло. Встречаем DirtyCred (CVE-2021-4154 - февральская, есть PoC; CVE-2022-2588 - свежая, пока нет PoC-а). 8 лет уязвимость никто не замечал. Или замечали и использовали, но помалкивали. Естественно NVD как обычно тормозит и там нового идентификатора пока нет, но он во всю используется в бюллетенях безопасности.

Судя по описанию это уязвимость ядра, похожая на мартовскую Dirty Pipe (CVE-2022-0847), только круче, т.к. работает стабильнее:

"The novel exploitation method, according to the researchers, pushes the dirty pipe to the next level, making it more general as well as potent in a manner that could work on any version of the affected kernel."

И контейнеризация не спасает:

"Second, while it is like the dirty pipe that could bypass all the kernel protections, our exploitation method could even demonstrate the ability to escape the container actively that Dirty Pipe is not capable of."

Ну и так-то уязвимости позволяющие получить в Linux root-а появляются достаточно регулярно. Из громких можно ещё вспомнить Dirty Cow (CVE-2016-5195 - обалдеть 😱, 6 лет назад, помню как вчера как тестил) и Qualys-овские PwnKit (CVE-2021-4034) и Sequoia (CVE-2021-33909).

А что делать? Имхо, патчить. Лучше в рамках регулярного процесса, а не в пожарном режиме. Но если регулярного патчинга Linux-ов нет, то лучше разово обновиться, махая этой уязвимостью (или даже более старыми с публичными эксплоитами) как флагом. После разового упражнения будет видно какие есть проблемы с внедрением регулярного процесса, а где-то возможно получится его внедрить с наскока.

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

Но, имхо, оценка эксплуатабельности, харденинг и внедрение СЗИ для Linux-ов это конечно все замечательно, но основное это патчинг и прежде всего нужно разобраться именно с ним.

У Алексея Лукацкого сегодня был интересный пост про "H.R.7900 - National Defense Authorization Act for Fiscal Year 2023"

1 комментарий

У Алексея Лукацкого сегодня был интересный пост про "H.R.7900 - National Defense Authorization Act for Fiscal Year 2023". Длиннющий документ. Местами видимо интересный. Если в PDF выгружать, то там 3854 страницы. Слово "Russia" там встречается 281 раз. Солидно. 🙂 "China" только 130 раз.

Алексей Викторович обратил внимание, что теперь согласно "SEC. 6722. DHS SOFTWARE SUPPLY CHAIN RISK MANAGEMENT." контракторам Department of Homeland Security (DHS) придется собирать зависимости их продуктов в "bill of materials" и доказывать сертификатом, что ни в одной из зависимостей нет ни одной уязвимости из NVD. Не то, что там критичных уязвимостей нет, а вообще никаких CVE нет!

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

Ну и там вроде не конкретизировано кто и как именно должен процедуру сертификации проводить, так что могут быть нюансы. 😏

Но меня больше зацепило, что там речь идет не только об NVD, но и

"(B) any database designated by the Under Secretary, in coordination with the Director of the Cybersecurity and Infrastructure Security Agency, that tracks security vulnerabilities and defects in open source or third-party developed software."

Это что такое? Это просто вставочка на будущее, типа вдруг когда-нибудь сделают ещё какую-нибудь базу? Или есть какая-то ещё база уязвимостей Open Source софта разработанная DHS и CISA, которая не в паблике? Загадочно. 🙂

PS: Надо бы тамошним законодателям рассказать, что у каждого item в "bill of materials" могут быть свои зависимости, и в этих зависимостях могут быть (и есть) уязвимости, а для самого item-а в NVD об этом никакой информации не будет. Как не было отдельной CVE под каждый софт уязвимый Log4Shell. Даешь "bill of materials" для каждого item-а и тотальный разбор этой адской матрешки! Муа-ха-ха! 😈

Microsoft продолжают чудачить

1 комментарий

Microsoft продолжают чудачить. Принесли новую уязвимость. Проигрывание музыкального клипа Janet Jackson - Rhythm Nation (1989) ломает некоторые жесткие диски в некоторых ноутбуках ~ 2005-го года выпуска. Причем не только если клип проигрывается на самом устройстве, но и просто на соседнем устройстве. Есть в этом клипе какие-то частоты, которые с чем-то там в жестком диске резонируют. 😄 Звучит как лютый бред, но вот CVE-шка есть, CVE-2022-38392:

"A certain 5400 RPM OEM hard drive, as shipped with laptop PCs in approximately 2005, allows physically proximate attackers to cause a denial of service (device malfunction and system crash) via a resonant-frequency attack with the audio signal from the Rhythm Nation music video."

Заведена по посту в майкрософтовском блоге. Пишут, что неназванный "major computer manufacturer" зафиксил уязвимость добавлением кастомного аудио-фильтра:

"The manufacturer worked around the problem by adding a custom filter in the audio pipeline that detected and removed the offending frequencies during audio playback."

На самом деле демонстирует отсутствие какого-либо входного барьера при заведении CVE. CVE Numbering Authorities могут завести практически что угодно, с каким-угодно обоснованием, вплоть до совсем анекдотических.