VMware устранила критические уязвимости в Carbon Black App Control

VMware устранила критические уязвимости в Carbon Black App Control

VMware устранила критические уязвимости в Carbon Black App Control

Компания VMware обновила софт Carbon Black App Control (AppC), устранив две критические уязвимости, которые позволяют выполнить сторонний код на сервере под управлением Windows. Поскольку данный продукт используется для защиты ЦОД и критически важных систем, пользователям настоятельно рекомендуется применить патчи.

Комплексная платформа управления приложениями VMware Carbon Black App Control объединяет в себе белый список разрешенных программ, мониторинг целостности файлов, полнофункциональное управление устройствами и защиту памяти. Решение позволяет администратору серверов, используя один агент, контролировать изменения, блокировать непроверенные приложения в критических системах, а также поддерживать соответствие отраслевым нормам безопасности.

Обе RCE-уязвимости, выявленные в AppC, вендор оценил в 9,1 балла из 10 возможных по шкале CVSS. Эксплойт в обоих случаях требует сетевого доступа к интерфейсу администрирования и наличия соответствующих прав. Это означает, что воспользоваться лазейкой может только злоумышленник, угнавший админ-аккаунт, или продажный инсайдер с высокими привилегиями на доступ.

Проблема CVE-2022-22951, согласно описанию, возникла из-за неадекватной проверки пользовательского ввода и характеризуется как возможность инъекции команд. Причиной появления CVE-2022-22952 является слабость контроля загрузки файлов на сервер.

Наличие уязвимостей подтверждено для AppC веток 8.5.x, 8.6.x, 8.7.x и 8.8.x. Патчи включены в состав обновлений 8.5.14, 8.6.6, 8.7.4 и 8.8.2 соответственно.

В прошлом году VMware залатала столь же критичную дыру в другом представителе семейства — Carbon Black Cloud Workload. Этот локально устанавливаемый продукт отвечает за связь между сервером vCenter во внутренней сети и облачной платформой мониторинга безопасности ВМ. Наличие уязвимости позволяло непривилегированному пользователю обойти ограничения доступа и нарушить эту связь, приостановив работу защитных механизмов.

Linux-руткиты поумнели: теперь они прячутся в eBPF и io_uring

Linux-руткиты долго оставались где-то в тени по сравнению с Windows-аналогами, но сейчас ситуация меняется. Причина понятная: Linux всё плотнее сидит в облаках, контейнерах, IoT и корпоративной инфраструктуре, а значит, и интерес злоумышленников к нему растёт. Исследователи из Elastic обратили внимание на новую тенденцию: современные Linux-руткиты всё чаще прячутся не в «экзотике», а во вполне легитимных механизмах ядра — eBPF и io_uring.

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

Защитные меры в Linux-средах стали жёстче: Secure Boot, подпись модулей, режимы lockdown, стандартные средства аудита. В результате старые методы либо быстро выявляются, либо вообще не работают. И вот тут злоумышленники начали использовать то, что уже встроено в систему и изначально создавалось совсем не для атак.

Один из главных инструментов в этой новой волне — eBPF. Изначально он нужен для фильтрации пакетов, трассировки и других полезных низкоуровневых задач. Но проблема в том, что eBPF позволяет выполнять код внутри ядра, не подгружая классический модуль. Для атакующего это почти подарок: можно цепляться к системным вызовам или событиям Linux Security Module и делать это так, что обычные сканеры вроде rkhunter или chkrootkit просто ничего не заметят. Формально модуль ядра не загружался, и искать вроде бы нечего.

 

По сути, это даёт злоумышленнику очень тихий способ вмешиваться в работу системы: скрывать файлы, влиять на процессы, фильтровать сетевой трафик и при этом почти не оставлять привычных следов. Elastic приводит в пример такие проекты, как TripleCross и Boopkit, которые показывают, как eBPF можно использовать для перехвата системных вызовов и даже для скрытого канала управления.

Вторая интересная история — io_uring. Интерфейс io_uring появился в Linux как быстрый способ асинхронного ввода-вывода: он позволяет пачками отправлять операции в ядро через кольцевые буферы общей памяти. Для производительности это отлично. Для атакующего — тоже. Вместо того чтобы вызывать множество отдельных системных вызовов, процесс может передать целую очередь операций сразу. А значит, системам мониторинга, которые привыкли ловить активность по отдельным системным вызовам, становится заметно сложнее увидеть полную картину.

Именно поэтому io_uring всё чаще рассматривают как удобный механизм ухода от EDR и других средств наблюдения. Если упрощать, телеметрии становится меньше, шума тоже, а вредоносная активность растворяется в «нормальной» работе системы. В материале Elastic упоминается, например, экспериментальный руткит RingReaper, который показывает, как через io_uring можно скрытно подменять типовые операции вроде read, write и connect.

RSS: Новости на портале Anti-Malware.ru