Czego nie mówi Broadcom? Luka w VMware jest banalna do wykorzystania i korzysta z niej co najmniej jedna grupa hakerska!

kapitanhack.pl 16 godzin temu

Niedawno załatana wysoce poważna luka w zabezpieczeniach VMware jest wykorzystywana jako zero-day od października 2024 roku do wykonywania kodu z podwyższonymi uprawnieniami. Taką informacją podzieliło się w zeszłym tygodniu NVISO Labs. Tych wiadomości zabrakło jednak w komunikacji producenta.

Oznaczona numerem CVE-2025-41244 luka bezpieczeństwa (wynik CVSS 7,8) dotyczy zarówno VMware Aria Operations, jak i VMware Tools.

Broadcom, spółka matka VMware, wydała w tym tygodniu poprawki, ostrzegając, iż podatność umożliwia atakującym eskalację uprawnień do roota na maszynach wirtualnych z zainstalowanym VMware Tools i zarządzanych przez Aria Operations z włączonym SDMP. Jednocześnie producent nie ostrzega przed wykorzystaniem podatności w atakach.

Zazwyczaj o wykryciu luki typu zero-day klientów ostrzegają publiczne komunikaty firmy.

Według NVISO, która przypisuje sobie odkrycie tej podatności, chiński haker, oznaczony numerem UNC5174, wykorzystuje ją od roku. UNC5174 został niedawno powiązany z atakiem na firmę zajmującą się cyberbezpieczeństwem SentinelOne.

„Nie możemy jednak ocenić, czy ten exploit był częścią palety narzędzi wykorzystywanych w atakach przez UNC5174, czy też użycie luki typu zero-day było jedynie przypadkowe ze względu na jej trywialność” – zauważa NVISO.

Luka wpływa na funkcję wykrywania usług i aplikacji w VMware Aria Operations, która obejmuje zarówno starsze wykrywanie usług oparte na poświadczeniach (w którym VMware Tools działa jako proxy dla operacji), jak i wykrywanie usług bez poświadczeń (zbieranie metryk zaimplementowane w VMware Tools).

„W ramach odkrycia NVISO było w stanie potwierdzić, iż eskalacja uprawnień dotyczy obu trybów, a zatem luka logiczna znajduje się odpowiednio w VMware Aria Operations (w trybie opartym na poświadczeniach) i VMware Tools (w trybie bez poświadczeń)” – wyjaśnia NVISO.

Zauważając, iż udane wykorzystanie luki CVE-2025-41244 umożliwia użytkownikom bez uprawnień wykonywanie kodu z uprawnieniami roota, NVISO ostrzega, iż zagrożona jest również wersja open source VMware Tools, a mianowicie open-vm-tools, zawarta w głównych dystrybucjach Linuksa.

Funkcja wykrywania w open-vm-tools, jak twierdzi NVISO, wywołuje funkcję, która przyjmuje jako argument wzorzec wyrażenia regularnego, sprawdzając, czy pasuje on do obsługiwanych plików binarnych usług.

Ponieważ jednak funkcja ta używa klasy znaków \S o szerokim dopasowaniu w kilku wzorcach wyrażeń regularnych, dopasowuje również pliki binarne inne niż systemowe, znajdujące się w katalogach, do których mogą zapisywać użytkownicy bez uprawnień.

W ten sposób atakujący może wykorzystać podatną na ataki iterację open-vm-tools, umieszczając złośliwy plik binarny w ścieżce wyrażenia regularnego o szerokim dopasowaniu, co spowoduje zwiększenie uprawnień do wykrywania wersji.

Jak zauważa NVISO, UNC5174 wykorzystuje lukę w zabezpieczeniach, umieszczając złośliwe pliki binarne w folderze /tmp/httpd. Aby uzyskać dostęp do podatności, pliki binarne są uruchamiane z niskimi uprawnieniami i otwierane jest losowe gniazdo nasłuchujące.

Broadcom naprawiło lukę w nowych wersjach VMware Cloud Foundation, vSphere Foundation, Aria Operations, Telco Cloud Platform i VMware Tools, a także poinformowało, iż poprawki dla open-vm-tools będą dystrybuowane przez dostawców Linuksa.

Aby wykryć CVE-2025-41244, organizacje powinny szukać nietypowych procesów potomnych. W środowiskach bez monitorowania analiza skryptów i wyników kolektora metryk w starszym trybie opartym na poświadczeniach powinna potwierdzić podatność.

„Powszechna praktyka naśladowania plików binarnych systemu (np. httpd) wskazuje na realne prawdopodobieństwo, iż wiele innych odmian złośliwego systemu od lat przypadkowo korzysta z niezamierzonych eskalacji uprawnień” – twierdzi NVISO, zaznaczając, iż błąd może zostać z łatwością znaleziony w kodzie źródłowym open-vm-tools przez atakujących.

O najlepszych praktykach w zabezpieczeniu Vmware pisaliśmy tutaj.

Idź do oryginalnego materiału