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

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

SQL-инъекция в сетевых хранилищах QNAP (CVE-2022-27596)

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

SQL-инъекция в сетевых хранилищах QNAP (CVE-2022-27596)

SQL-инъекция в сетевых хранилищах QNAP (CVE-2022-27596). CVSS 9.8. До какого состояния докрутят эту SQLi сказать сложно, но угрозу конфиденциальности и целостности данных можно смело предположить. Нужно патчить. Хоть эксплоита и признаков эксплуатации вживую пока не видно.

QNAP это тайваньский вендор. В основном они выпускают NAS-ы (Network-attached storage) различного класса: от "для дома для семьи" до серьезных энтерпрайзных решений. Используют свои операционные системы QTS (для устройств попроще) и QuTS hero (для навороченных). Эти ОС и предлагается обновить на устройствах для исправления уязвимости.

NAS-ы это излюбленные мишени для ransomware. Во-первых, там хранятся ценные данные компаний. Во-вторых, их частенько выставляют прямо в Интернет. 🙃

Судя по тому, что у QNAP есть вполне актуальный русскоязычный сайт и активная группа в ВК, продаются они в России неплохо. А значит и в инфраструктуре вашей организации они вполне могут найтись. Дайте знать своим админам! 😉

Парень нашел "уязвимость" в VK и ему стали массово писать в личку заинтересованные девушки

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

Парень нашел "уязвимость" в VK и ему стали массово писать в личку заинтересованные девушки. 🙂 Этот забавный кейс я увидел в канале Standoff News. Технически там не очень интересно. Но как пример простой "уязвимости" для иллюстрации почему искать уязвимости это прикольно и как противостоять эксплуатации уязвимостей - вполне норм (студентам младших курсов, школьникам на профориентации т.п.).

В чем там было дело:

1. В VK пользователи могут видеть кто смотрел их сторисы (формат вертикальных публикаций, которые исчезают из ленты через 24 часа). В отличие от обычных сообщений в ленте, для которых видно только тех, кто полайкал.
2. В VK не было лимита на просмотр сторисов. Было возможно автоматически "просматривать" хоть миллионы чужих сторисов в день. (не конкретизируется как)
3. Было возможно массово получить идентификаторы пользователей из групп типа "любители котиков". (не конкретизируется как)
4. Было возможно автоматически получить сторисы для идентификаторов пользователей. (не конкретизируется как)

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

Далее конверсия: миллионы просмотренных сторисов -> десятки тысяч заходов от любопытных пользователей на страницу Накрутчика -> сотни сообщений от тех, кому совсем уж любопытно. Profit.

Вопросы, которые можно задать аудитории:
1. Что можно было бы предусмотреть на стороне VK, чтобы так было делать нельзя? Возможный ответ: установить лимиты, при превышении таймаут или показывать капчу.
2. Что ждет Накрутчика, когда это обнаружится? Возможный ответ: как минимум забанят профиль, т.к. автоматизация действий нарушает пользовательское соглашение.
*3. Как можно подвести действия Накрутчика под УК РФ? Возможный ответ: по факту это скрэпинг, можно в теории натянуть на 272 и 273.

После этого можно поставить риторический вопрос. Что лучше: сдать уязвимость в VK и получить $100/спасибо, или пытаться эксплуатировать и подставляться? Каждый сам для себя решает.

Сканировать принтеры на уязвимости следует с осторожностью

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

Сканировать принтеры на уязвимости следует с осторожностью

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

Некоторые Vulnerability Management вендоры вообще не рекомендуют активно сканировать принтеры. Например, в #Tenable относят принтеры к "хрупким устройствам" ("fragile devices") и рекомендуют использовать для обнаружения уязвимостей на них пассивные детекторы. Т.е. перехватывать трафик и определять по нему версию устройств и связанные уязвимости. Продвигают этим Nessus Network Monitor (NNM), бывший Passive Vulnerability Scanner (PVS), но тем не менее.

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

RCE в 130 моделях принтеров (МФУ) Lexmark (CVE-2023-23560)

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

RCE в 130 моделях принтеров (МФУ) Lexmark (CVE-2023-23560)

RCE в 130 моделях принтеров (МФУ) Lexmark (CVE-2023-23560). Нашли в наиболее уязвимом, в web-интерфейсе. Получив контроль над устройством, злоумышленник может воспользоваться дополнительными сетевыми доступами для развития атаки. Непонятно может ли получить доступ к тому, что печатается/сканируется, но тоже исключать нельзя. Либо патчимся, либо отключаем TCP 65002 (WSD Print Service) в настройках.

Хороший повод, чтобы поразмышлять об активах неудобных для VM:

1. Вы обо всех принтерах в вашей инфраструктуре знаете?
2. Ваш сканер уязвимостей умеет детектировать уязвимости для ваших принтеров?
3. Давно вы сканировали принтеры на наличие уязвимостей?
4. Давно вы обновляли принтеры? Есть понимание кто, как и в какой срок это должен делать?

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