Comments 12
скомпрометирована через фишинг и получение доступа во внутреннюю инфраструктуру с использованием VMware Horizon. Следом за этим, используя уязвимость программного обеспечения, VMware злоумышленником получен доступ к ESXI
А не подскажите, а каким образом злоумышленник пусть даже через фишинг пробившийся в виртуальный десктоп смог получить сетевой доступ до mgmt порта ESXi чтобы атаковать его через не пропатченные уязвимости?
Мисконфигурация сети, здесь уже проблема не в VMware =)
Вот за такую "мисконфигурацию" и надо долго и сильно бить по рукам. И это ИМХО должно быть правило номер 0, перед тем как ставить патчи особенно от well-known и seen in the wild уязвимостей. Потому что management сеть платформы и железа, по умолчпнию, должна быть изолирована от сети пользователей. А требования номер 3 - просто включить MFA на Horizon. Любой из этих шагов был бы достаточен для защиты. Рекомендация 4 - проверить и настроить мониторинг соответствия Hardening Guide.
А вот от инструментов, которые обеспечивают безопасность ESXi часто больше вреда, чем пользы, не говоря уже про то, VMware не рекомендует установку всяких security агентов на хосты - https://knowledge.broadcom.com/external/article/330057/deployment-of-3rd-party-agents-and-antiv.html
С одной стороны - я полностью согласен, правильная конфигурация всей системы обеспечила бы эшелонированную защиту. С другой стороны - это справедливо для многих энтерпрайз систем, но тем не менее для них выпускают средства защиты информации либо сразу их встраивают.
Банально, при правильно конфигурации домена AD и своевременном обновлении пробить его тоже не всегда просто, однако Shodan, Fofa, Censys и пр. полнятся уязвимыми системами, ведь люди не идеальны. Смысл решений в области ИБ - снизить риски.
На текущий же момент заметна активность хакеров в направлении атак систем виртуализации, при этом необходимые компетенции у администраторов не всегда есть, а снизить риск нечем.
Основное и принципиальное отличие — это то, что ESXi не является ОС общего назначения, на которой можно запускать произвольный код/программы. Все компоненты должны быть подписаны цифровой подписью от VMware. Да, есть CommunitySupported VIB, но их разрешение требует изменение Acceptance Level (что прямо не рекомендуется и не поддерживается вендором, а так же запрещено в рамках всяких сертификаций по безопасности типа PCI DSS и прочих) + Secure Boot просто перестанет работать и не позволит запустить ESXi. См. https://blogs.vmware.com/vsphere/2011/09/whats-in-a-vib.html + https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-security/GUID-5D5EE0D1-2596-43D7-95C8-0B29733191D9.html
Поэтому тулзы безопасности, о которых вы говорите (кстати, а какие конкретно вы можете привести в качестве примера?), обычно используют всякие грязные хаки (типа установки таких же не подписанных модулей или работа по всегда открытому ssh), которые только создают новые вектора угроз + могут оказывать влияние на стабильность работы платформы и СИЛЬНО усложняют любой траблшутинг (возможное/вероятное требование номер 1 от поддержки будет - удалите всякую фигню с хоста и тогда будем смотреть) и обновление (потому что кто его знает кто и как тестировал эту тулзу на работу с новыми версиями/патчами).
Да, безусловно, есть нормальные инструменты безопасности для защиты самой платформы. Но они пассивные и или мониторят логи/события, или мониторят/отслеживают конфигурацию платформы и в случае чего (например, кто-то открыл ssh порт) кидают алерты. Но ИМХО — это все-таки скорее система мониторинга, чем система активной защиты.
Ну и если вам нужно сделать все совсем-совсем секурно на ESXi, то включайте еще и Lockdown Mode + пустой DCUI.Access (https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-security/GUID-88B24613-E8F9-40D2-B838-225F5FF480FF.html) в дополнение к стандартным SecureBoot + Host Profiles. Тогда никакой ssh/cli/dcui не работает. Хотя на практике так делают крайне редко (и только в средах с очень высокими требованиями по безопасности), потому что траблшутинг превращается в ад, где все заканчивается просто перезаливкой хостов.
видимо на вирутальном дестктопе лежал реальный текстовый файл с реальными паролями.
в СДЭКе что-то такое было.
Так дело не в паролях. По умолчанию, management сеть гипервизора, серверов, СХД и прочего изолирована от сети пользователей. Так что хоть есть пароли и уязвимости, хоть нет, туда не достучаться при атаке на VDI десктоп пользователя.
хорошо. допустим вы изолировали mgmt в отдельный vlan.
рассмотрим вопрос: а кто еще имеет туда доступ и как ?
мои ответы это:
автоматика (мониторинг, биллинг, бэкап, IDS, ...) и ручное управление от админов.
через роутинг + фаерволл, через роутинг + фаерволл.
видите в п1. потенциально уязвимые места ?
Так что хоть есть пароли и уязвимости, хоть нет, туда не достучаться при атаке на VDI десктоп пользователя.
пользователь не простой. достучаться можно.
А только для VMware есть проблема? У него сейчас популярность падает вроде.
Малварь ниже «уровня радаров»