Архив рубрики: Темы

Про недавнюю RCE уязвимость в Webkit (CVE-2023-23529) и браузерные RCE уязвимости вообще

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

Про недавнюю RCE уязвимость в Webkit (CVE-2023-23529) и браузерные RCE уязвимости вообще.

Описание CVE-2023-23529 довольно типовое. "Обработка вредоносного веб-контента может привести к выполнению произвольного кода. Apple известно об отчете сообщающем о том, что эта проблема могла активно эксплуатироваться". Бюллетени для iPhone/iPad и macOS Ventura. Для iPhone/iPad эта уязвимость затронет не только Safari, ни и вообще все доступные браузеры, т.к. Apple принуждает всех разработчиков использовать единый "rendering framework".

Критичны ли такие браузерные уязвимости? Конечно. Заставить пользователя перейти по ссылке, например через фишинг, дело достаточно тривиальное. Отличный путь для получения первоначального доступа. И если браузер не обновлен, тут только на EDR надежда.

С обновлением всё неоднозначно. Некоторые инсталляции по большей части обновятся сами, такие как Chrome и Firefox под Windows. Но не все. Для других всё упрется в процесс обновления ОС: Microsoft Edge, Safari, Linux-овые браузеры поставленные из репозитория. Возни немало.

Соблазнительной выглядит идея запретить использование любых браузеров, кроме одного выбранного, контролируемого и обновляемого централизованно. 😈 Респект тем, кому удалось такое провернуть. 👍 Но исключения все равно придется предусматривать, как минимум для дизайнеров/разработчиков/qa, которым важно тестить работоспособность своих поделий в нескольких браузерах. Фактор разнообразного легаси, работающего только с определенными браузерами (и зачастую определенными их версиями) тоже исключать нельзя. А отсюда дополнительная операционная нагрузка. И с чем будет больше возни - с обычными обновлениями или запретами/исключениями не очевидно.

В общем, успехов нам всем с фиксом CVE-2023-23529 и прочих бесконечных веб-браузерных радостей. 🙂

Февральский Microsoft Patch Tuesday

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

Февральский Microsoft Patch Tuesday

Февральский Microsoft Patch Tuesday. Общее впечатление теперь буду сразу выдавать, с пылу с жару, а причесанный блогопост/видяшку с задержкой.

1. Наиболее критичным выглядит RCE - Windows Graphics Component (CVE-2023-21823). Причем ZDI отметили эту уязвимость как EoP и не стали в свой обзор добавлять. Видимо MS поменяли тип уязвимости перед релизом. Будем надеяться, что EDR-ы оперативно начнут блокировать эксплуатацию.
2. EoP - Windows Common Log File System Driver (CVE-2023-23376) с признаком активной эксплуатации.
3. Пачка RCE для Exchange (CVE-2023-21529, CVE-2023-21706, CVE-2023-21707, CVE-2023-21710). Но пока без признаков эксплуатации.
4. Из курьезного Inf. Disclosure в устройствах дополненной реальности HoloLens 1 (CVE-2019-15126), старая уязвимость Broadcom с кучей эксплоитов.

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

Управление уязвимостями в новых реалиях

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

Управление уязвимостями в новых реалиях. Крутой доклад по VM-ной теме с недавно прошедшего Инфофорума. Представлял доклад Андрей Никонов, старший инженер-программист из Фродекс (Vulns.io). Видео в паблике не нашел, но есть даже лучше - слайды с текстом выступления.

Выписал тезисно:

1. Зарубежные VM-вендоры ушли - нет детектов, IT-вендоры ушли - нет обновлений.
2. Атаки на российские компаний множатся, утечки ПД и оборотные штрафы.
3. Рост отечественного ПО -> рост проблемы анализа защищенности этого ПО -> "VM-решения должны уметь работать с операционными системами и программами российского происхождения".
4. В достаточной степени отечественные VM-решения поддерживают отечественное ПО? Непонятно. "Никто открыто не публикует списки поддерживаемых ПО и не дает внятных ответов по степени покрытия российского софта".
5. Необходимы данные об уязвимостях отечественного ПО.
5.1. Западные компании "публикуют уязвимости, найденные в своих продуктах, причем эти данные являются общедоступными, несмотря на то, что большая часть ПО является коммерческим".
5.2. "Данные NVD также являются общедоступными, содержат огромное количество уязвимостей, но для проведения точного аудита годятся мало. В основном из-за того, что они используют собственный формат данных, и в них не указаны правила, по которым можно определить, является ПО уязвимым или нет". -> Ага, детект по CPE-шкам это зло.
5.3. Все ли вендоры одинаково описывают свои уязвимости? Далеко не все. OVAL стал довольно популярным. Но этого недостаточно.
5.4. У нас хорошие источники это БДУ ФСТЭК и OVAL RedOS. "Остальные вендоры, если и публикуют свои данные, то в намного более расслабленном режиме – обычно это выглядит как лента новостей или запись в блоге. Это очень сильно усложняет их обработку. Более того, не все вендоры публикуют данные открыто, хотя некоторые из них готовы предоставить данные по запросу или в случае приобретения сертификата на техническую поддержку."
5.5. Для прикладного ПО из 65 вендоров в базе ФСТЭК 3 публикуют данные об уязвимостях. А в реестре российского ПО 16000 программных продуктов!
5.6. Одной БДУ ФСТЭК недостаточно, т.к. "не указываются правила применимости той или иной уязвимости, для сканирования использовать эти данные проблематично". Данные в БДУ могут добавляться с запаздыванием, данные не всегда актуальны. Напрямую от вендора было бы быстрее.
6. Итог: "обратить внимание разработчиков российского ПО на важность поиска уязвимостей в своих продуктах, и выпуска обновлений безопасности".
Просьбы к регулятору:
"- принять единый стандарт описания уязвимостей или разработать собственный
- обязать разработчиков ОС и ПО вести базы данных уязвимостей в соответствии с принятым стандартом
- оказывать содействие компаниям при организации мероприятий Bug Bounty при условии публикаций найденных уязвимостей в базу ФСТЭК"

В целом, огонь! 🔥 Как раз такие доклады от VM-вендора и хочется видеть. Конкретно про детект уязвимостей и как делать его лучше. Очень сильно перекликается с моими собственными мыслями по этому поводу. Хочется надеяться, что регулятор прислушается.

А есть ли смысл в "Vulnerability Management Сycle"?

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

А есть ли смысл в Vulnerability Management Сycle?

А есть ли смысл в "Vulnerability Management Сycle"? Со временем все больше начинают подбешивать картинки циклов управления уязвимостями. Особенно картинка из "The New Vulnerability Management Guidance Framework" (2019). Хотя когда-то сам такое рисовал. 🙃

Чем плохо:

1. Создается иллюзия, что есть какие-то шаги, которые выполняются последовательно. "ручками похлопали, потом ножками потопали". Это представимо в рамках каких-то ежегодных аудитов, но Continuos VM так уже не работает. Все, что в "лепестках" должно идти одновременно, параллельно, автоматически. Нет "сканов-ресканов", есть процесс поддержания инвентори/детектов и его улучшения. Разбор и переоценка уязвимостей отдельный процесс. Пушинг их исправления тоже.
2. Зачастую VM-вендоры пытаются проектировать свои решения по этой схеме, стараясь всё, что отмечено как-то покрыть. Как правило, такие комбайны ни одну из заявленных задач толком не решают, а пользоваться ими так, как рекомендует вендор невозможно.

RCE уязвимости VMware ESXi OpenSLP в активной эксплуатации (CVE-2021-21974, CVE-2020-3992)

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

RCE уязвимости VMware ESXi OpenSLP в активной эксплуатации (CVE-2021-21974, CVE-2020-3992). Используются в шифровальщике ESXiArgs.

Массовые атаки ESXiArgs начались с 3 февраля. В первую очередь пострадали серверы VMware ESXi доступные из Интернет. Сообщают о как минимум 3000 пострадавших серверах. Есть оценки, что в Интернет выставлено более 80 000 (!) ESXi серверов. 🤩 Но, естественно, эта уязвимость касается вообще всех необновленных ESXi хостов, не только доступных из Интернет.

Сами VMware использование 0-day не нашли. В новостях пока пишут о двух старых уязвимостях OpenSLP. Это открытая реализация "Service Location Protocol", которая используется в ESXi.

CVE-2021-21974. В NVD с 24.02.2021. Публичный эксплоит с 03.06.2021

Уязвимые версии ESXi:
7.0 before ESXi70U1c-17325551
6.7 before ESXi670-202102401-SG
6.5 before ESXi650-202102101-SG

CVE-2020-3992. В NVD с 20.10.2020. Публичный эксплоит с 05.02.2021.

Уязвимые версии ESXi:
7.0 before ESXi70U1a-17119627
6.7 before ESXi670-202011301-SG
6.5 before ESXi650-202011401-SG

Нужно патчить. Если вообще никак, то отключать SLP (хотя есть сообщения, что некоторым это не помогло). Для одних версий ESXiArgs есть декриптор, для других нет, лучше не рассчитывать. Хороший повод проверить ваши бэкапы на случай, если всё же пошифруют. Дайте знать вашим VMware-админам! 😉

PS: Хороший пример как оно бывает. Так вот месяцами-годами может быть публичная инфа об уязвимости и какие-то PoC-и. А потом бабах - и понеслась. Не доводите до греха, патчитесь заранее и отказывайтесь от неподдерживаемых систем.

MEPhI CTF Meetup в эту пятницу

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

MEPhI CTF Meetup в эту пятницу. 10 февраля 18:00–23:00 в московском офисе BI ZONE или в онлайне.

Честно говоря, я к CTF-ам всегда как-то с прохладцей относился и практически никогда в них не участвовал. В чем смысл тратить время на эти надуманные головоломки? Берем полностью обновленную и максимально захардененную Ubuntu, зарезаем все ненужные сервисы, самописные веб-сервисы закрываем WAF-ом (а то и тоже просто зарезаем к ним доступ). Вот это таска так таска! Ну давайте теперь, ребята, атакуйте. 🙂

Но это, мягко говоря, не очень правильный взгляд на вещи. Насколько я сейчас вижу, CTF-команды, особенно университетские, это такие первичные ячейки для людей интересующихся хардкорной практической безопасностью. Причем наиболее живые и массовые. Например, в отборочном туре VI Кубке CTF России участвовало почти 298 команд (70 городов, 115 учебных заведений). Вот это размах! И это только Россия (и чуть-чуть Казахстан). Даже собрать столько заинтересованных людей это уже успех. Кроме того, участники этих команд не только ведь в соревнованиях участвуют. Они встречаются, общаются, готовятся, организуют митапы, разбирают таски с прошлых CTF-ов и т.п. И в процессе подготовки к CTF-ам происходит обучение полезным навыкам, которые затем пригодятся на работе в ресерче, пентестах, безопасной разработке, харденинге, vulnerability management-е и т.д. Этому, как правило, в ВУЗах не особенно-то и учат. А сами CTF-ы это такие практические лабораторные работы. Ещё и с мощным игровым соревновательным элементом. Круто же!

В общем, митап есть смысл заслушать. Наиболее интересными мне видятся доклады "Аутопсия бинарных CTF-тасков" и "Интересные баги из жизни пентестера".

Обзор рынка Vulnerability Management систем от Anti-Malware: велика ли разница между "обычным сканером" и "VM-решением"?

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

Обзор рынка Vulnerability Management систем от Anti-Malware: велика ли разница между "обычным сканером" и "VM-решением"? Обзор вышел 27 января. Я естественно побежал его читать, так как и сам занимаюсь похожей темой.

Основное, что бросилось в глаза: а почему такой скромный набор решений?

Российские
Positive Technologies MaxPatrol VM
Фродекс VulnsIO VM

Зарубежные
Qualys VMDR
Tenable SC
Rapid7 Insight VM
Holm Security

Конечно, все эти решения могут быть в таком обзоре. Но почему только они? Почему среди российских нет АЛТЭКС-СОФТ RedCheck или НПО "Эшелон" Сканер-ВС. А среди зарубежных нет Greenbone GVM, SecPod SanerNow, Outpost24. Дело тут похоже в следующем. В 2020 на Anti-Malware вышел аналогичный обзор "Сканеры уязвимостей — обзор мирового и российского рынков". Значительная часть решений, которых нет в отчете по VM, есть в отчете по сканерам уязвимостей:

Российские
Positive Technologies MaxPatrol 8
Positive Technologies XSpider
АЛТЭКС-СОФТ RedCheck
АЛТЭКС-СОФТ/ФСТЭК ScanOVAL
НПО "Эшелон" Сканер-ВС
Профиль Защиты "Ревизор сети"

Зарубежные
Qualys Vulnerability Management
Tenable Nessus Professional
Tenable IO
Rapid7 Nexpose Vulnerability Scanner
F-Secure Radar
GFI LanGuard
Tripwire IP360
Skybox Vulnerability Control

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

Но насколько такое разделение вообще оправдано?

В обзоре читаем:

"Резкий рост количества выявляемых брешей, необходимость их приоритизации и контроля за их устранением привели к появлению нового класса продуктов — VM (Vulnerability Management). Подобные комплексы не только имеют в своём составе сканер уязвимостей, но также позволяют расставлять приоритеты при устранении изъянов в зависимости от выбранных параметров и контролировать этот процесс в дальнейшем."

Ок, допустим есть такой параметр связанный с уязвимостью - CVSS (векторы и скоры). Любое решение для детектирования уязвимостей их показывает (ведь подтянуть их из NVD/БДУ тривиально) и чуть менее чем любое позволяет по ним фильтровать прямо в интерфейсе. При таком подходе любой сканер это VM-решение. Разве нет? 😉

Я, конечно, понимаю о чем тут речь. Об общем дашбордике со статистикой по уязвимостям и активам. Ну да, когда продукт может не только сканы отображать, но и как-то общую картину из них собирает это прикольно. Особенно если с динамикой. Но по сравнению с огромной проблемой именно детектирования уязвимостей это все сущая мелочь. Ну допустим нет дашбордика, выгрузите результаты и нарисуйте какие хотите дашборды в любой платформе для аналитики (ELK, Grafana, Splunk, Tableau). Или просто в специализированное решение экспортните (Faraday, Kenna), там автоматом всё разберется. Просто скриптиками попарсите наконец. Тем более это практически неизбежно в ситуации, когда ни одно решение не может покрыть детектами всю инфраструктуру целиком, придется как-то соотносить уязвимости из разных источников.

Обращать столько внимание на второстепенные функции типа дашбордов и интерфейса для приоритизации это все равно что при обсуждении автомобилей обращать внимания только на дворники. Делить все автомобили на те, у которых есть бескаркасные стеклоочистители и те, у которых их нет. Ну да, дворники это прикольно и важно. Дворники какие-то должны быть. И лучше чтобы они были хорошие, надежные. Но дворники же не должны быть определяющим фактором при оценке и выборе автомобиля! Если машина не ездит толком, то какая разница какие у неё там дворники. 🙃

В общем, моё имхо, что от чисто маркетингового разделения "обычный сканер уязвимостей" и "VM-решение" стоит уходить и рассматривать всё в рамках единого класса, например "Средства Детектирования Уязвимостей Инфраструктуры (СДУИ)". А при сравнении прежде всего обращать внимание на базовую функциональность - детектирование уязвимостей. А дополнительной функциональности уделять время соразмерно её важности.