Атаки шифровальщиков на VMware ESXi | Блог Касперского
-
Похожий контент
-
Автор KL FC Bot
4 марта Broadcom выпустила экстренные обновления для устранения трех уязвимостей — CVE-2025-22224, CVE-2025-22225 и CVE-2025-22226, которые затрагивают несколько продуктов VMware, включая ESXi, Workstation и Fusion. В бюллетене упоминается, что по информации Broadcom как минимум CVE-2025-22224 эксплуатируется в реальных атаках. Уязвимости позволяют выполнить «побег» из виртуальной машины и выполнить код в гипервизоре ESX (hypervisor escape). По информации из GitHub VMware, Microsoft Threat Intelligence Center первым обнаружил эксплойт в реальной среде и уведомил Broadcom. Но кто и против кого использовал этот эксплойт, компании не разглашают.
Уязвимости по данным Broadcom затрагивают VMware ESXi 7.0-8.0, Workstation 17.x, vSphere 6.5-8, Fusion 13.x, Cloud Foundation 4.5-5.x, Telco Cloud Platform 2.x-5.x, Telco Cloud Infrastructure 2.x-3.x, хотя некоторые эксперты считают, что список затронутых продуктов несколько шире. В частности, более старые версии, например 5.5, тоже должны быть подвержены уязвимости, но патчи для них выпущены не будут, эти версии не поддерживаются. По имеющимся оценкам на конец недели, уязвимостям подвержены более 41 тысячи серверов ESXi, расположенных во всех частях света — больше всего в Китае, Франции, США, Германии, Иране и Бразилии.
Какие ошибки устранены VMware
Наиболее серьезная уязвимость CVE-2025-22224 в VMware ESXi и Workstation получила рейтинг CVSS 9.3. Она связана с переполнением кучи (heap overflow) в VMCI и позволяет злоумышленнику с локальными административными привилегиями на виртуальной машине выполнить код от имени процесса VMX на хосте (то есть в гипервизоре).
Уязвимость CVE-2025-22225 в VMware ESXi (CVSS 8.2) позволяет злоумышленнику записать произвольный код в область ядра (arbitrary kernel write), то есть тоже подразумевает побег из «песочницы». CVE-2025-22226 является утечкой информации в HGFS (CVSS 7.1) и позволяет злоумышленнику с административными привилегиями на виртуальной машине извлекать содержимое памяти процесса VMX. Этой уязвимости подвержены VMware ESXi, Workstation и Fusion.
View the full article
-
Автор Алексей_
Добрый день, коллеги!
Помогите разобраться почему не работает
на KSC 15.1.0 добавил "Kaspersky Security для виртуальных сред 6.2 Легкий агент" + необходимые плагины по инструкции
хочу развернуть SVM, с помощью развертывания из оболочки - не работает. (ввожу логин root и пароль, единственный полный админ на VMware ESXi) - скрин1
хотя в параметрах подключения к инфраструктуре пишет все ок - скрин2
подключаюсь к хосту в той же подсети VMware ESXi 6.5 - скрин3
-
Автор KL FC Bot
В последние годы в блоге Kaspersky Daily мы стали уделять ransomware заметно меньше внимания, чем в былые времена. Но это вовсе не потому, что атаки вымогателей прекратились. Скорее наоборот — такие инциденты происходят настолько часто, что они уже давно стали привычным, практически фоновым явлением.
Однако некоторые атаки вымогателей по-прежнему привлекают внимание своей экстраординарностью. В этом посте мы перечислим связанные с шифровальщиками-вымогателями инциденты 2024 года, которые выделялись на общем фоне своим масштабом, последствиями или необычными методами атакующих.
Январь 2024: атака вымогателей на зоопарк Торонто
Одним из первых значительных инцидентов 2024 года, связанных с ransomware, стала январская атака на крупнейший канадский зоопарк, расположенный в Торонто. Администрация зоопарка поспешила заверить общественность в том, что атака вымогателей не повлияла на работоспособность систем, связанных с уходом за животными. Более того, веб-сайт организации и сервис продажи билетов также не были затронуты, так что зоопарк продолжил принимать посетителей в обычном режиме.
Официальный сайт зоопарка Торонто сообщает о кибератаке и уверяет, что с животными все в порядке. Источник
Через некоторое время после атаки выяснилось, что атакующим удалось похитить значительное количество личной информации сотрудников зоопарка за период с 1989 года до наших дней. Таким образом, данный инцидент послужил очередным напоминанием о том, что даже очень далекие от критических секторов организации могут стать объектами атак вымогателей.
View the full article
-
Автор KL FC Bot
Атаки на open source чаще всего сводятся к публикации новых вредоносных пакетов в репозиториях. Атака, произошедшая 14 марта, из другой лиги — злоумышленники скомпрометировали популярный процесс (GitHub Action) tj-actions/changed-files, который применяется более чем в 23000 репозиториев. Инцидент получил номер CVE-2025-30066, этой уязвимости подвержены все репозитории, в которых использовался заражённый процесс changed-files. Хотя администрация заблокировала changed-files, а затем откатила его к безопасной версии, все, кто пользовался им должны провести реагирование на инцидент, а сообщество разработчиков — извлечь из него более общие уроки.
Что такое GitHub Actions
Рабочие процессы (GitHub Actions) упрощают разработку ПО при помощи автоматизации типовых задач DevOps. Они могут стартовать при наступлении каких-то событий в GitHub, например коммитов. У GitHub есть условный «магазин приложений», в котором можно взять готовый процесс и применить его в своём репозитории, например популярны процессы для автоматической инсталляции вспомогательных инструментов. Чтобы интегрировать в свой сборочный конвейер CI/CD такой готовый процесс GitHub, достаточно всего одной строчки кода.
View the full article
-
Автор KL FC Bot
Чуть больше года назад в посте Google OAuth и фантомные аккаунты мы уже обсуждали, что использование опции «Вход с аккаунтом Google» в корпоративные сервисы дает возможность сотрудникам создавать фантомные Google-аккаунты, которые не контролируются администратором корпоративного Google Workspace и продолжают работать после оффбординга. Недавно выяснилось, что это не единственная проблема, связанная с OAuth. Из-за недостатков этого механизма аутентификации любой желающий может получить доступ к данным многих прекративших деятельность организаций, перерегистрировав на себя брошенные компаниями домены. Рассказываем подробнее об этой атаке.
Как работает аутентификация при использовании «Вход с аккаунтом Google»
Некоторые могут подумать, что, доверяя опции «Вход с аккаунтом Google», компания получает надежный механизм аутентификации, использующий продвинутые технологии Google и широкие возможности интернет-гиганта по мониторингу пользователей. Однако на деле это не так: при входе с Google OAuth применяется достаточно примитивная проверка. Сводится она, как правило, к тому, что у пользователя есть доступ к почтовому адресу, который привязан к Google Workspace организации.
Причем, как мы уже говорили в предыдущем материале о Google OAuth, это вовсе не обязательно Gmail — ведь привязать Google-аккаунт можно совершенно к любой почте. Получается, что при использовании «Входа с аккаунтом Google» доступ к тому или иному корпоративному сервису защищен ровно настолько надежно, насколько защищен почтовый адрес, к которому привязан Google-аккаунт.
Если говорить несколько более подробно, то при аутентификации пользователя в корпоративном сервисе Google OAuth отправляет этому сервису следующую информацию:
В теории в ID-токене Google OAuth есть уникальный для каждого Google-аккаунта параметр sub, но на практике из-за проблем с его использованием сервисы проверяют лишь домен и адрес электронной почты. Источник
View the full article
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти