Архив за месяц: Февраль 2023

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

Про дипломную работу, написанную ChatGPT

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

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

1. Студент несколько раз пытался сдать своему научному руководителю сгенерированный ChatGPT текст как план дипломной бакалаврской работы "Анализ и совершенствование управления игровой организацией", принципиально не желая написать его нормально по методичке. "И на четвертый раз ломаю научницу, она присылает план моего диплома". План ему написали.
2. Чтобы получить введение, студент вводил в ChatGPT план диплома целиком (!) в качестве запроса, получал какой-то бред (потому что релевантный ответ на "это" получить нельзя), а потом переводил его яндекс-переводчиком.
3. Для теоретической части студент генерил текст в ChatGPT на тему "5 принципов менеджмента", а потом переводил это опять же яндекс-переводчиком.
4. Практическая часть это рерайт текста из чужого дипломного проекта про мясокомбинат. 😐
5. Проверку научного руководителя полученный текст не прошел, студент приводил текст до более-менее читаемого вида вручную и с помощью ChatGPT. Основной критерий, на который смотрели это уникальность текста по антиплагиату.
6. Отзывы студенту написали нормальные.
7. На защите диплома студент устроил клоунаду, его выгоняли из аудиториии, но в итоге трояк поставили.

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

С другой стороны это наглядная демонстрация типичного адепта ChatGPT - человека, которому достоверность сгенеренного текста глубоко безразлична, лишь бы только этот текст доставался бесплатно в неограниченных количествах и выглядел убедительно.

Некоторые заметки по итогам митапа Яндекс-а

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

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

1. Прикольная тема из Яндекс Финтех про "одна команда - один Golden Image":

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

➡️ Вопрос: Используете ли вы distroless образы в Банке, да и в Яндексе в целом, к примеру Google distroless, чтобы минимизировать поверхность атаки и уменьшить размер самих образов?
Ответ: нет, но очень хотим к этому прийти
➡️ Вопрос: Если не секрет, что у вас за базовый образ? Аstra Linux? 😉
Ответ: отвечу, что такой же как и во всем Яндексе )

Вполне возможно это секрет полишинеля на основе какого Linux-дистрибутива базовые образы в Яндексе делают, но я не знаю. Если кто знает - шепните в личку, любопытно. 😉

2. То, что Яндекс Финтеху комфортно в Яндекс Облаке это понятное дело. Но будет ли так же комфортно другим банкам и финтехам?

➡️Вопрос: Возвращаясь к сертификации банка в облаке по стандартам PCI DSS и ГОСТам. Я смогу запустить такой банк в я.облаке и получить содействие при прохождении аудита со стороны Команды облака или это единичный случай для «родственной» компании?
Ответ: Можно это получить как отдельную услугу в Облаке.
➡️ Вопрос: прям услуга Облака или рекомендованная внешняя команда?
Ответ: В Облаке есть архитекторы и premium support.

3. В Wildberries и Яндекс Финтех для организации привилегированного доступа к Linux-инфраструктуре используют Teleport. Почему именно его? Как минимум половина доклада команды Wildberries была про обоснование этого выбора. Очень подробно и убедительно. Единственное жаль, что тема в основном крутилась про то как безопасно дать доступ до нужных серверов и дать/не дать root-а, но не про хитрое ограничение прав пользователя на хосте. А это у Wildberries есть, т.к. Teleport у них сильно допиленный:

"Команда переписала админку Teleport-а полностью с нуля. Написала свой PAM-модуль, который учитывает роли, которые передаются телепортом при аутентификации и на основе этого настраивает sudo. Но мы сегодня про это подробно не рассказывали, потому что оно опять же не поместилось."

Про sudo тема интересная, будем ждать следующего раза. 🙂

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 есть вполне актуальный русскоязычный сайт и активная группа в ВК, продаются они в России неплохо. А значит и в инфраструктуре вашей организации они вполне могут найтись. Дайте знать своим админам! 😉