Category: vCenter

Posted on

BRICKSTORM – “sårbarhet” eller något värre? Så hänger den ihop med vCenter & ESXi (och hur du skyddar och upptäcker angrepp)

Det pratas ibland om “BRICKSTORM-sårbarheten”, men det är viktigt att reda ut begreppen: BRICKSTORM är i första hand en bakdörr/malware-familj som används för långvarig, smygande åtkomst – inte en enskild CVE i sig. Den har observerats i intrång där angripare tar sig in (ofta med stulna legitimationer eller via andra sårbarheter), och sedan installerar BRICKSTORM på VMware vSphere-miljöer, särskilt vCenter och ESXi, eftersom de ger kontroll över hela den virtualiserade infrastrukturen.

Nedan får du en praktisk och defensivt fokuserad genomgång: hur BRICKSTORM relaterar till vCenter/ESXi, varför den är farlig, samt konkreta skydds- och detektionsåtgärder.

Varför vCenter och ESXi är så attraktiva mål

I många organisationer är vCenter “kontrollplanet”: där finns åtkomst till att skapa/ändra VM:ar, snapshotta, klona, hantera nätverk och lagring, och ofta även integreringar mot identitet (AD/SSO).

När en angripare får fotfäste på vCenter/ESXi kan de i praktiken:

  • Skapa eller dölja “rogue” VM:ar för att köra verktyg, pivotera eller exfiltrera data.
  • Stjäla snapshots/kloner av VM:ar och sedan extrahera credentials offline (en extremt effektiv credential access-väg).
  • Tunnla trafik (t.ex. via SOCKS-proxy-funktion) så att kommandokontroll och lateral rörelse ser “normal” ut från insidan.
  • Utnyttja privilegierade konton/komponenter i vSphere (t.ex. vCenter-konton, vpxuser i vissa scenarier) för att röra sig sidledes.

Poängen: om angriparen kontrollerar vCenter kontrollerar de ofta allt som körs på ESXi.

Vad BRICKSTORM är och vad den gör

Enligt den gemensamma analysen (CISA/NSA/Canadian Centre for Cyber Security) är BRICKSTORM en sofistikerad bakdörr som setts mot VMware vSphere (vCenter och ESXi) samt Windows. Den används för långvarig persistence och kommer med indikatorer och detektionssignaturer (bl.a. YARA och Sigma).

Kända/rapporterade egenskaper i kampanjerna inkluderar bland annat:

  • Lång “dwell time” (angriparen ligger kvar länge innan upptäckt).
  • Krypterade C2-kanaler (t.ex. HTTPS/WebSockets/TLS/DoH i rapporterad aktivitet) och ibland proxyfunktion för pivotering.
  • Masquerading (binärer med legitima namn/utseende) och persistence via uppstartsskript/paths.

Typisk angreppsbild kopplad till vCenter/ESXi

Även om intrång kan börja på olika sätt, återkommer ofta ett mönster:

  1. Initial access: internetexponerade edge-enheter, stulna credentials (t.ex. MSP-konton), eller exploaterade sårbarheter som ger fotfäste.
  2. Pivot till vCenter: angriparen tar sig till management-nät/administrationsplan.
  3. Installation av BRICKSTORM på vCenter (och ibland vidare mot ESXi/VM:ar), för stabil och dold åtkomst.
  4. Missbruk av vCenter-funktioner: snapshots, kloner, “rogue” VM:ar, credential harvesting och vidare lateral movement.

I ett rapporterat incidentexempel hade angripare åtkomst från april 2024 och använde BRICKSTORM för persistence åtminstone fram till 3 september 2025 efter att ha laddat upp den till en intern vCenter-server.

Skydd: så minskar du risken att bli nästa vCenter/ESXi-offer

Här är en defensiv checklista med hög “bang for the buck”.

1) Separera och lås ner management-planet

  • Isolera vCenter/ESXi management i ett separat nät (ingen direkt access från klientnät/DMZ).
  • Tillåt administration endast via jump hosts/bastion med hårda kontroller.
  • Blockera utgående trafik från vCenter/ESXi så långt det går (default deny, tillåt bara det som behövs).

Varför: BRICKSTORM-kampanjer utnyttjar ofta att kontrollplanet är “för nära” resten av miljön och att verktyg/EDR inte alltid täcker appliances.

2) Stärk identitet och åtkomst

  • MFA överallt för administrativ access (SSO/IdP, VPN, bastion, vCenter).
  • Minimera och granska privilegier: separata admin-konton, “just enough admin”.
  • Rotera och skydda servicekonton (särskilt om du är MSP eller har många tenants).
  • Larma på nya API-tokens, nya administratörer, och ovanliga inloggningar.

3) Patcha och hårdna vSphere-komponenterna

  • Håll vCenter och ESXi strikt uppdaterade (även om BRICKSTORM inte är “en CVE”, utnyttjas den ofta efter att angriparen fått access via svaga länkar).
  • Stäng av onödiga tjänster (t.ex. begränsa/disable SSH när det inte behövs).
  • Aktivera och använd Lockdown Mode där det är möjligt, och strama åt brandväggsregler på ESXi.
  • Följ VMware hardening guides (och håll konfigurationsavvikelser under kontroll).

4) Säkerhetskopiera och gör recovery realistiskt

  • Ha offline/immutabla backuper av kritiska system (inkl. vCenter-konfig, viktiga VM:ar).
  • Öva återställning: om vCenter komprometteras kan du behöva återbygga snarare än “städa”.

Detektion: så upptäcker du BRICKSTORM och liknande aktivitet

Eftersom traditionell endpoint-telemetri ofta är begränsad på appliances behöver du kombinera loggar, nätverksdetektion och vSphere-specifik övervakning.

1) Använd officiella IOCs + YARA/Sigma

Den gemensamma rapporten innehåller indikatorer och detektionssignaturer (YARA & Sigma) och uppdaterades senast 19 december 2025. Börja där och implementera matchning i din SIEM/EDR/NDR/hunting-pipeline.

Praktiskt tips:

  • Kör YARA där du kan (forensiska image-sökningar, EDR på Linux/Windows där relevant).
  • Kör Sigma-regler i SIEM (översätt vid behov till din plattformsformat).

2) Övervaka vCenter för “administrativt missbruk”

Larma/hunta på:

  • Ovanliga snapshot- och kloningsmönster (tidpunkt, frekvens, mål-VM:ar).
  • Skapande av nya VM:ar som snabbt skapas/avregistreras/stängs ner (kan vara “rogue”/dolda).
  • Nya/oväntade konton, rolländringar och behörighetseskaleringar.
  • Aktivitet från oväntade IP-adresser mot vCenter API/UI.

3) Nätverksdetektion: leta efter “osannolika” utgående mönster

BRICKSTORM-aktivitet har rapporterats använda krypterade protokoll och ibland proxyfunktioner, vilket gör att klassisk signaturbaserad detektion kan vara svår.

Larma på:

  • vCenter/ESXi som plötsligt gör nya utgående TLS/HTTPS-förbindelser till okända destinationsnät.
  • DNS-over-HTTPS-liknande beteenden från system som normalt inte behöver det.
  • Tecken på tunnling/proxy (t.ex. många interna destinationsförsök som “kommer från” vCenter/ESXi).

4) Host-baserad jakt på vCenter/ESXi (när du kan)

På vCenter Server Appliance (VCSA) är det extra värdefullt att:

  • Samla in och centralt lagra loggar (syslog) från vCenter/ESXi.
  • Larma på förändringar i uppstart/persistence-mekanismer (init-/startup-skript, ovanliga binärer, PATH-manipulation, tjänster som inte borde finnas).

Obs: Exakta filnamn/artefakter varierar mellan varianter och kan vara anpassade per offer, så basera inte allt på en enda IOC. Kombinera TTP-baserad jakt + officiella signaturer.

Om du misstänker intrång: snabb IR-checklista (vCenter/ESXi)

  1. Isolera management-nätet (kontrollerat): stoppa utgående trafik från vCenter/ESXi där möjligt.
  2. Säkra bevis: ta forensiska snapshots/exports av relevanta loggar och system (innan “städning”).
  3. Jämför mot rapportens IOCs + regler (YARA/Sigma).
  4. Rotera credentials: särskilt vCenter admin, SSO/IdP, servicekonton, och alla konton som kan nå management-planet.
  5. Granska vSphere-händelser: snapshots, kloner, nya VM:ar, rolländringar.
  6. Planera för återuppbyggnad: i vissa fall är säkraste vägen att återställa/återinstallera vCenter från “known good” och återansluta hostar kontrollerat.

Sammanfattning

BRICKSTORM är farlig av en enkel anledning: den siktar på din kontrollyta, inte dina vanliga endpoints. När vCenter/ESXi komprometteras kan angriparen:

  • extrahera credentials via snapshots,
  • skapa/dölja VM:ar,
  • och använda plattformen som språngbräda för långvarig åtkomst.

Skyddet handlar därför om att låsa ner management-planet, stärka identitet, segmentera, begränsa utgående trafik och bygga detektion som faktiskt täcker vSphere – plus att implementera de IOCs och YARA/Sigma-regler som publicerats i den gemensamma analysen.

Finns det något verktyg för detektering av BRICKSTORM?

Utöver klassisk logg- och nätverksövervakning finns det nu specialiserade verktyg framtagna specifikt för att upptäcka spår av BRICKSTORM i VMware-miljöer. Ett av de mest användbara är brickstorm-scanner, ett öppet verktyg publicerat av Mandiant.

🔗 https://github.com/mandiant/brickstorm-scanner

Vad är brickstorm-scanner?

brickstorm-scanner är ett forensiskt detektionsverktyg som är designat för att identifiera indikatorer på BRICKSTORM-kompromettering, med särskilt fokus på:

  • vCenter Server Appliance (VCSA)
  • ESXi-hostar
  • Linux-system som kan ha använts i attackkedjan

Verktyget är utvecklat baserat på Mandiants incidentresponsarbete och publika hotunderrättelser kring BRICKSTORM.

Vad letar verktyget efter?

brickstorm-scanner söker efter flera typer av artefakter som är typiska för BRICKSTORM-operationer, bland annat:

  • Kända filhashar och binärer
  • Ovanliga eller modifierade start-/persistence-mekanismer
  • Misstänkta processer och tjänster
  • Avvikelser i filsystemet som tyder på masquerading
  • Spår av bakdörrsinstallation på vCenter/VCSA

Viktigt: verktyget är byggt för detektion och triage, inte för borttagning. Ett positivt fynd ska alltid följas av en fullständig incidenthantering.

Hur och när bör verktyget användas?

brickstorm-scanner passar särskilt bra i följande scenarier:

  • Threat hunting i vSphere-miljöer
  • Efter misstänkt intrång (t.ex. ovanliga vCenter-händelser, snapshots, eller nätverkstrafik)
  • Proaktiv kontroll av högvärdessystem som vCenter

Rekommenderad praxis:

  1. Kör verktyget offline eller i ett kontrollerat IR-läge
  2. Samla och spara resultat som forensiskt bevismaterial
  3. Korrelatera fynd med:
    • vCenter-/ESXi-loggar
    • SIEM-larm
    • Nätverksdata
    • Officiella IOCs och YARA/Sigma-regler

Begränsningar att känna till

Som med alla IOC-baserade verktyg gäller:

  • Ett negativt resultat betyder inte att miljön är ren
  • BRICKSTORM-aktörer är kända för att:
    • Anpassa filnamn och paths
    • Kompilera unika varianter per offer
  • Verktyget bör därför användas som en del av en större detektionsstrategi, inte som enda skydd

Rekommenderad kombination

För bästa effekt bör brickstorm-scanner användas tillsammans med:

  • Centraliserad logginsamling från vCenter & ESXi
  • Nätverksövervakning (NDR) för utgående trafik från management-planet
  • Regelbunden granskning av snapshots, kloner och VM-skapande
  • Stark identitetssäkerhet (MFA, begränsade API-tokens, bastion access)

Officiella resurser från VMware (BRICKSTORM-guidelines)

För att hjälpa organisationer att skydda sina VMware-miljöer mot avancerade hot som BRICKSTORM har VMware publicerat en samling guider och resurser inom sitt Security & Compliance Guidelines-repo på GitHub.

Resurserna ligger under katalogen ransomware-resources/BRICKSTORM i detta repo:
https://github.com/vmware/vcf-security-and-compliance-guidelines/tree/main/ransomware-resources/BRICKSTORM

Även om GitHub-sidan i sig inte är en fullständig “instruktionsmanual”, fungerar den som en samling av riktlinjer, verktyg och konfigurationsguider som du kan använda för att:

Förbättra din säkerhetskonfiguration

I hela vcf-security-and-compliance-guidelines-projektet finns exempel på:

  • Hardening-riktlinjer för VMware-komponenter (som vCenter och ESXi) för att minska ytan för angrepp.
  • Checklistor och policyer som hjälper dig att säkra både VMware Cloud Foundation och vSphere.
  • Ransomware-resurser kategoriserade utifrån olika hot, inklusive BRICKSTORM, som ger en defensiv ram att arbeta utifrån.

Exempel på vad du får hjälp med

Guidelines-projektet är inte bara en kodbas – det innehåller:

  • Security Configuration Hardening Guide: detaljerade rekommendationer för hur du sätter säkerhetsinställningar rätt i VMware-produkter.
  • Ransomware-resurser: samlade dokument och best practices för att förbereda, upptäcka och återhämta dig från intrång som involverar ransomware-liknande bakdörrar såsom BRICKSTORM.
  • Exempelskript, politiska kontroller och rådatat: som kan implementeras i verktyg och automationer i din miljö.

Hur dessa riktlinjer hjälper mot BRICKSTORM

Den BRICKSTORM-specifika delen av VMware-guiden är tänkt att komplettera andra detektions- och skyddsåtgärder – som de vi redan nämnt (t.ex. brickstorm-scanner). Den används bäst i kombination med:

  • Standard hardening-guider för vSphere/vCenter, som minskar attackytan generellt.
  • Policy-drivna kontroller och larm i din SIEM/övervakningslösning.
  • Automatiserade compliance-kontroller, vilket gör det lättare att se avvikelser från “known good”-konfigurationer.

Eftersom VMware-guiden underhålls tillsammans med andra säkerhetsresurser innebär det att du får kontinuerligt uppdaterade best practices som hjälper dig att:

* implementera least privilege och hård autentisering
* konfigurera loggning och audit trails
* upptäcka avvikelser i konfigurationer
* förbereda återställningspunkter och resilient design

Att använda dessa riktlinjer är ett sätt att proaktivt minska risken för BRICKSTORM-komprometteringar istället för att enbart reagera efter att ett intrång inträffat.

Posted on

Optimera din VMware VCF miljö

Varför prestandaoptimering i vSphere är viktigt

När du kör virtuella maskiner med vSphere delar flera VM:ar på samma underliggande fysiska resurser — CPU, minne, I/O, nätverk och lagring. Om inte dessa resurser är korrekt konfigurerade och balanserade kan det leda till flaskhalsar, låg responstid, eller att vissa VM:ar påverkar andra negativt. Därför är det viktigt att följa vissa best practices för att få ut maximal prestanda, stabilitet och effektiv resursanvändning.

Därför publicerar VMware riktlinjer för hur hårdvara, ESXi-konfiguration, virtuell maskin-konfiguration, lagring, nätverk och infrastrukturhantering bör utformas.

Rekommendationer för hårdvara

CPU & virtualisering

  • Välj CPU:er som stöder hårdvaruassisterad virtualisering — t.ex. Intel VT-x / AMD-V, och för minneshantering Intel EPT eller AMD RVI.
  • Kontrollera att hårdvaran finns med på vSphere: s officiella kompatibilitetslista.
  • Undersök minnet noga — exempelvis genom att köra test under 72 timmar för att upptäcka eventuella minnesfel innan produktion.

Minnes- och lagringskonfiguration

  • Om du använder minnestiering (memory tiering) — en ny möjlighet i vSphere 9.0 — bör du välja NVMe-enheter med hög uthållighet och minst 100 000 skrivningar per sekund (per enhet) för att hantera belastning bra.
  • För lagringsenheter: använd snabba back-end-lösningar med rätt RAID, cache och ”stripe size” beroende på arbetsbelastning.
  • För flash / SSD / NVMe: överväg PCIe-anslutna NVMe-kort — de ger oftast bäst prestanda.

Nätverk & I/O-kort

  • När du använder snabb lagring — t.ex. NVMe eller flash för swap / cache — är det viktigt att nätverk och I/O-kort (t.ex. PCIe-kort) placeras i platser med tillräcklig bandbredd (tillräckligt många ”lanes”).

Virtuell maskin & ESXi — inställningar som påverkar prestanda

När hårdvaran är på plats är följande inställningar viktiga:

  • Undvik överdriven minnes-overcommit: överutnyttja inte värdens minne på bekostnad av prestanda.
  • Använd “Large Memory Pages” (t.ex. 2 MB sidor) där det är möjligt — det kan minska overhead och förbättra minnesprestanda.
  • För arbetsbelastningar som är känsliga för latens — t.ex. databaser — se till att lagring, I/O-vägar och nätverk är korrekt konfigurerade för låg latens.
  • Vid användning av funktioner som direkt I/O-åtkomst (t.ex. SR-IOV, DirectPath I/O) — konfigurera korrekt för att undvika prestandaförsämringar.

Infrastruktur- och management-nivå: vCenter & hantering

Prestanda påverkas inte bara av hårdvara och VM-konfiguration — även hur infrastrukturen hanteras spelar stor roll:

  • Om du använder vCenter Server: tänk igenom databas- och lagringskonfiguration för vCenter, särskilt med avseende på nätverk och I/O.
  • Använd resurshantering — t.ex. kluster med VMware Distributed Resource Scheduler (DRS), VMware vMotion / Storage vMotion och VMware vSAN (om relevant) — men dimensionera och konfigurera dessa med omsorg för att undvika prestandaproblem.
  • För vSAN: välj mellan ”all-flash” eller hybrid beroende på krav — och planera nätverk, lagring och layout noggrant.

Hur du kommer igång — praktiska tips

  1. Inventera din hårdvara – kontrollera att CPU, minne, lagrings- och nätverkskort är kompatibla med vSphere 9.0. Kör minnestest om möjligt.
  2. Planera din lagrings- och I/O-struktur – välj lagringsenheter med tillräcklig prestanda, undvik översubskription av I/O, konfigurera korrekt PCIe-bandbredd.
  3. Tänk på hakearbeten och latens-känsliga arbetsbelastningar – använd Large Pages, dedikerade resurser, och överväg direkt I/O/SR-IOV om det behövs.
  4. Konfigurera resurshantering och kluster med omsorg, t.ex. DRS, vMotion, vSAN, sambandet mellan resurser och verkliga arbetsbelastningar.
  5. Övervaka prestanda kontinuerligt — missa inte att gå igenom vCenter-loggar, övervaka I/O, CPU, minne och svarstider på VM:ar.

Slutsats

Att driftsätta en virtuell miljö med vSphere 9.0 är mer än bara att installera ESXi och vCenter — det kräver noggrann planering av hårdvara, lagring, nätverk och konfigurationer för att verkligen få ut god prestanda. Genom att följa best practices från dokumentet kan du skapa en stabil, effektiv och högpresterande virtualiseringsmiljö.

Läs hela dokumentet här: https://www.vmware.com/docs/vsphere-esxi-vcenter-server-90-performance-best-practices

Posted on

Säkerhetsuppdatering från Broadcom: VMware vCenter och NSX åtgärdar flera sårbarheter

Broadcom har släppt en viktig säkerhetsuppdatering, VMSA-2025-0016, som adresserar flera sårbarheter i VMware vCenter och NSX. Dessa sårbarheter, identifierade som CVE-2025-41250, CVE-2025-41251 och CVE-2025-41252, har en allvarlighetsgrad i intervallet 7.5–8.5 enligt CVSSv3 och klassas som viktiga. Här är en översikt av sårbarheterna, deras påverkan och hur de kan åtgärdas.

Påverkade produkter

De berörda produkterna inkluderar:

  • VMware vCenter Server
  • VMware NSX
  • NSX-T
  • VMware Cloud Foundation
  • VMware Telco Cloud Platform
  • VMware Telco Cloud Infrastructure

Sårbarheter och deras påverkan

1. SMTP-headerinjektion i vCenter (CVE-2025-41250)

Beskrivning: VMware vCenter har en sårbarhet för SMTP-headerinjektion. En angripare med icke-administrativa behörigheter, men med rättigheter att skapa schemalagda uppgifter, kan manipulera notifikationsmejl som skickas för dessa uppgifter.
Allvarlighetsgrad: Viktig, CVSSv3-poäng 8.5.
Åtgärd: Uppdatera till de versioner som anges i svarsmatrisen nedan. Inga tillfälliga lösningar finns tillgängliga.
Erkännande: Tack till Per von Zweigbergk för rapporteringen av denna sårbarhet.

Svarsmatris för CVE-2025-41250:

ProduktKomponentVersionFast VersionDokumentation
VMware Cloud Foundation, VMware vSphere FoundationvCenter9.x.x.x9.0.1.0Ingen
VMware vCenterN/A8.08.0 U3gLänk
VMware vCenterN/A7.07.0 U3wLänk
VMware Cloud FoundationvCenter5.x5.2.2Async Patching Guide: KB88287
VMware Cloud FoundationvCenter4.5.xAsync patch till 7.0 U3wAsync Patching Guide: KB88287
VMware Telco Cloud PlatformvCenter5.x, 4.x, 3.x, 2.xKB411508Ingen
VMware Telco Cloud InfrastructurevCenter3.x, 2.xKB411508Ingen

2. Svag lösenordsåterställningsmekanism i NSX (CVE-2025-41251)

Beskrivning: VMware NSX har en sårbarhet i sin lösenordsåterställningsmekanism som kan utnyttjas av en oautentiserad angripare för att lista giltiga användarnamn, vilket potentiellt kan leda till brute-force-attacker.
Allvarlighetsgrad: Viktig, CVSSv3-poäng 8.1.
Åtgärd: Applicera uppdateringarna som anges i svarsmatrisen nedan. Inga tillfälliga lösningar finns.
Erkännande: Tack till National Security Agency för rapporteringen.

3. Användarnamnsuppräkning i NSX (CVE-2025-41252)

Beskrivning: VMware NSX har en sårbarhet för användarnamnsuppräkning som gör det möjligt för en oautentiserad angripare att identifiera giltiga användarnamn, vilket kan underlätta obehöriga åtkomstförsök.
Allvarlighetsgrad: Viktig, CVSSv3-poäng 7.5.
Åtgärd: Applicera uppdateringarna som anges i svarsmatrisen nedan. Inga tillfälliga lösningar finns.
Erkännande: Tack till National Security Agency för rapporteringen.

Svarsmatris för CVE-2025-41251 och CVE-2025-41252:

ProduktKomponentVersionFast VersionDokumentation
VMware Cloud Foundation, VMware vSphere FoundationVMware NSX9.x.x.x9.0.1.0Ingen
VMware NSXN/A4.2.x4.2.2.2, 4.2.3.1Länk 4.2.2.2, Länk 4.2.3.1
VMware NSXN/A4.1.x, 4.0.x4.1.2.7Länk
NSX-TN/A3.x3.2.4.3Länk
VMware Cloud FoundationVMware NSX5.x, 4.5.xKB88287Async Patching Guide: KB88287
VMware Telco Cloud InfrastructureVMware NSX3.x, 2.xKB411518Ingen
VMware Telco Cloud PlatformVMware NSX5.x, 4.x, 3.xKB411518Ingen

Rekommendationer

Broadcom uppmanar alla användare av de berörda produkterna att omedelbart applicera de tillgängliga uppdateringarna för att skydda sina system. Det finns inga tillfälliga lösningar för dessa sårbarheter, så uppdatering till de angivna versionerna är avgörande.

Referenser och ytterligare resurser

Slutsats

Dessa sårbarheter understryker vikten av att hålla dina VMware-produkter uppdaterade. Genom att snabbt applicera de rekommenderade uppdateringarna kan du skydda dina system från potentiella attacker.

Posted on

Viktig säkerhetsuppdatering för VMware-produkter: Flera sårbarheter åtgärdade

Den 20 maj 2025 publicerade Broadcom en viktig säkerhetsrådgivning (VMSA-2025-0010) som adresserar flera sårbarheter i VMware-produkter, inklusive ESXi, vCenter Server, Workstation och Fusion. Dessa sårbarheter har olika allvarlighetsgrader och kan potentiellt utnyttjas av illvilliga aktörer för att kompromettera system.

Översikt över sårbarheterna

  1. CVE-2025-41225 – Autentiserad kommandokörning i vCenter Server
    • Beskrivning: En användare med rättigheter att skapa eller ändra larm och köra skript kan utnyttja denna sårbarhet för att köra godtyckliga kommandon på vCenter Server.
    • CVSSv3-poäng: 8.8 (Hög allvarlighetsgrad)
    • Åtgärd: Uppdatera till vCenter Server 8.0 U3e eller 7.0 U3v.
  2. CVE-2025-41226 – Tjänsteavbrott via gästoperationer i ESXi
    • Beskrivning: En autentiserad användare med rättigheter att utföra gästoperationer kan orsaka ett tjänsteavbrott i virtuella maskiner med VMware Tools installerat.
    • CVSSv3-poäng: 6.8 (Måttlig allvarlighetsgrad)
    • Åtgärd: Uppdatera till ESXi 8.0 U3se eller 7.0 U3sv.
  3. CVE-2025-41227 – Tjänsteavbrott via gästalternativ i ESXi, Workstation och Fusion
    • Beskrivning: En användare med icke-administrativa rättigheter inom ett gästoperativsystem kan utnyttja vissa gästalternativ för att förbruka värdprocessens minne, vilket leder till ett tjänsteavbrott.
    • CVSSv3-poäng: 5.5 (Måttlig allvarlighetsgrad)
    • Åtgärd: Uppdatera till ESXi 8.0 U3se, 7.0 U3sv, Workstation 17.6.3 eller Fusion 13.6.3.
  4. CVE-2025-41228 – Reflekterad Cross-Site Scripting (XSS) i ESXi och vCenter Server
    • Beskrivning: Otillräcklig validering av indata kan tillåta en angripare med nätverksåtkomst att injicera skadlig kod via vissa URL-vägar, vilket kan leda till stöld av cookies eller omdirigering till skadliga webbplatser.
    • CVSSv3-poäng: 4.3 (Måttlig allvarlighetsgrad)
    • Åtgärd: Uppdatera till vCenter Server 8.0 U3e eller 7.0 U3v, samt ESXi 8.0 U3se eller 7.0 U3sv.

Påverkade produkter och rekommenderade uppdateringar

ProduktVersionerÅtgärd
VMware vCenter Server8.0, 7.0Uppdatera till 8.0 U3e eller 7.0 U3v
VMware ESXi8.0, 7.0Uppdatera till 8.0 U3se eller 7.0 U3sv
VMware Workstation17.xUppdatera till 17.6.3
VMware Fusion13.xUppdatera till 13.6.3
VMware Cloud Foundation5.x, 4.5.xAnvänd asynkrona patchar enligt KB88287
VMware Telco Cloud Platform5.x, 4.x, 3.x, 2.xUppdatera till ESXi 8.0 U3se
VMware Telco Cloud Infrastructure3.x, 2.xUppdatera till ESXi 8.0 U3se eller 7.0 U3sv

För detaljerade instruktioner och nedladdningslänkar, besök den officiella säkerhetsrådgivningen:

Broadcom Security Advisory VMSA-2025-0010

Rekommendationer

  • Omedelbar uppdatering: Administratörer bör snarast uppdatera sina system enligt ovanstående rekommendationer för att skydda mot potentiella attacker.
  • Ingen tillfällig lösning: Det finns inga kända tillfälliga lösningar för dessa sårbarheter; uppdatering är den enda åtgärden.
  • Övervakning: Fortsätt att övervaka officiella kanaler för eventuella ytterligare uppdateringar eller information.

Att snabbt åtgärda dessa sårbarheter är avgörande för att upprätthålla säkerheten i din IT-miljö. Genom att följa de rekommenderade uppdateringarna kan du minimera risken för attacker och säkerställa systemens integritet.

Posted on

PowerCLI script to start vCenter default services

I had some problems recently in my home lab where my vCenter server didn’t start all necessary services when rebooted resulting in some backup jobs failing. See separate post about the issue.

Instead of fixing the problem, why not create a script that checks if the default services was started. Typically, the following services are not required:
vmcam
vmware-imagebuilder — unless the Imagebuilder feature has been enabled
vmware-netdumper
vmware-rbd-watchdog
vmware-vcha — unless vCenter High Availability has been enabled

For the script to work, SSH needs to be enabled on the vCenter Server
In the vCenter Server Appliance Management Interface (https://<vcenter IP>:5480) click Access, and click Edit.
Edit the access settings for the vCenter Server Appliance and enable Enable SSH login.

and the Posh-SSH module needs to be installed on the client you’re running the script from, a simple
Install-Module -Name Posh-SSH
will do it.

# Start-VCSA-services.ps1
# v1.0 Niclas Borgstrom
#
# Ensure Posh-SSH module is imported
Import-Module -Name Posh-SSH -ErrorAction Stop

# Parameters - Replace these with actual values
$VCServer = "IP Address or FQDN to vCenter"
$Username = "root" # useraccount to use to access vCenter VAMI
$Password = "<password>" # Password for the above user account

# Services to check and potentially start - Started by default
$ServicesToCheck = @("applmgmt", "lookupsvc", "lwsmd", "observability", "observability-vapi", "pschealth", "vc-ws1a-broker", "vlcm", "vmafdd", "vmcad", "vmdird", "vmware-analytics", "vmware-certificateauthority", "vmware-certificatemanagement", "vmware-cis-license", "vmware-content-library", "vmware-eam", "vmware-envoy", "vmware-envoy-hgw", "vmware-envoy-sidecar", "vmware-infraprofile", "vmware-perfcharts", "vmware-pod", "vmware-postgres-archiver", "vmware-rhttpproxy", "vmware-sca", "vmware-sps", "vmware-stsd", "vmware-topologysvc", "vmware-trustmanagement", "vmware-updatemgr", "vmware-vapi-endpoint", "vmware-vdtc", "vmware-vmon", "vmware-vpostgres", "vmware-vpxd", "vmware-vpxd-svcs", "vmware-vsan-health", "vmware-vsm", "vsphere-ui", "vstats", "vtsdb", "wcp", "vmware-hvc")


try {
    # Establish an SSH session to the vCenter server
    $SSHSession = New-SSHSession -ComputerName $VCServer -Credential (New-Object -TypeName PSCredential -ArgumentList $Username, (ConvertTo-SecureString $Password -AsPlainText -Force))

    # Check the status of all services
    Write-Output "Checking service statuses on $VCServer..."
    $ServiceStatusCommand = "com.vmware.service-control --status"
    $ServiceStatusResult = Invoke-SSHCommand -SessionId $SSHSession.SessionId -Command $ServiceStatusCommand

    # Output the raw service status for debugging
    Write-Output "Raw Service Status Output:"
    Write-Output ($ServiceStatusResult.Output -join "`n")

    # Parse the service status output
    $ServiceStatusOutput = $ServiceStatusResult.Output -join "`n" # Combine output lines into a single string

    # Extract the services under the "Stopped:" section
    Write-Output "Parsing the 'Stopped:' section..."
    $StoppedServices = @() # Initialize an empty array for stopped services
    if ($ServiceStatusOutput -match "Stopped:\s*(.*)") {
        # Match everything after "Stopped:"
        $StoppedServicesRaw = $Matches[1] -replace "\r|\n", " " # Replace newlines with spaces
        $StoppedServices = $StoppedServicesRaw -split '\s+' | Where-Object { $_ -ne "" } # Split services by whitespace
        Write-Output "Services found in 'Stopped:' section: $($StoppedServices -join ', ')"
    } else {
        Write-Output "No services found in the 'Stopped:' section."
    }

    # Check if the required services are in a stopped state and start them if necessary
    foreach ($Service in $ServicesToCheck) {
        if ($StoppedServices -contains $Service) {
            Write-Output "Service '$Service' is stopped. Starting it now..."
            $StartServiceCommand = "com.vmware.service-control --start $Service"
            $StartServiceResult = Invoke-SSHCommand -SessionId $SSHSession.SessionId -Command $StartServiceCommand

            # Output the result of the start service command
            Write-Output "Start Service Output for '$Service':"
            Write-Output ($StartServiceResult.Output -join "`n")
        } else {
            Write-Output "Service '$Service' is already running."
        }
    }
}
catch {
    Write-Error "An error occurred: $_"
}
finally {
    # Clean up and remove the SSH session
    if ($SSHSession) {
        Remove-SSHSession -SessionId $SSHSession.SessionId
        Write-Output "SSH session to $VCServer closed."
    }
}

Posted on

Kritiska Säkerhetsuppdateringar för VMware vCenter Server

Den 21 oktober 2024 släppte Broadcom en uppdaterad säkerhetsrådgivning som adresserar två allvarliga säkerhetsproblem i VMware vCenter Server och VMware Cloud Foundation: en heap-överflödes-sårbarhet (CVE-2024-38812) och en privilegieförhöjnings-sårbarhet (CVE-2024-38813).

Båda sårbarheterna har en kritisk CVSSv3-poäng på upp till 9,8, och kan potentiellt leda till fjärrkörning av skadlig kod eller ge en angripare högre systembehörighet. VMware har uppmanat alla kunder att installera de senaste säkerhetsfixarna så snabbt som möjligt för att skydda sina system.

Heap-overflow och Privilegieförhöjning: CVE-2024-38812 är en heap-overflow-sårbarhet i DCERPC-protokollet som kan användas för att skicka specialdesignade nätverkspaket och möjliggöra fjärrkodexekvering. CVE-2024-38813 är en sårbarhet som gör det möjligt för en angripare att eskalera sina privilegier till root genom att skicka särskilda paket till vCenter Server.

Påverkade Produkter och Uppdateringar:

  • VMware vCenter Server och VMware Cloud Foundation är de primära produkterna som påverkas.
  • Uppdateringar finns nu tillgängliga för versionerna 8.0 och 7.0. Broadcom har också bekräftat att tidigare utgivna patchar från september 2024 inte helt löste sårbarheterna, vilket gör att de nu tillhandahåller uppdaterade patchar.

Rekommendation: Alla VMware-användare uppmanas starkt att omgående tillämpa de senaste patcharna som anges i Broadcoms svarsmatris för att skydda sina system mot potentiella hot.

För mer information, besök Broadcoms säkerhetsrådgivning här.

Posted on

Kritiska Sårbarheter i VMware vCenter Server

Broadcom har nyligen utfärdat en säkerhetsrådgivning för att varna användare om två kritiska sårbarheter som upptäckts i VMware vCenter Server: CVE-2024-38812 och CVE-2024-38813. Båda dessa sårbarheter har potential att allvarligt påverka systemets säkerhet och integritet, och därför är det avgörande att förstå vad de innebär och hur de kan åtgärdas.

Sårbarheter i Detalj

  1. CVE-2024-38812 – Heap Overflow i DCERPC
    • Denna sårbarhet är kopplad till ett heap-overflow i DCERPC-protokollet. Den kan utnyttjas av en illasinnad aktör som har nätverksåtkomst till vCenter Server för att köra godtycklig kod. Med andra ord kan angripare få kontroll över systemet genom att utnyttja denna brist. I och med att DCERPC är ett viktigt protokoll för kommunikation mellan nätverkstjänster, gör detta sårbarheten mycket allvarlig.
    • Sårbarheten kan användas för att kompromettera hela systemet, vilket innebär att den ger möjlighet till fjärrkodkörning utan att användaren behöver interagera aktivt med en infekterad fil eller länk.
  2. CVE-2024-38813 – Eskalering av Privilegier
    • Den andra sårbarheten kan utnyttjas för att eskalera rättigheter till root-nivå. Detta innebär att om en angripare har lyckats få någon form av åtkomst till systemet kan denne uppgradera sina rättigheter för att få full kontroll över vCenter Server. En eskalering till root-nivå kan innebära att angriparen får möjlighet att göra omfattande systemändringar, vilket ytterligare ökar risken för dataförlust och manipulation.

Potentiella Konsekvenser

Om dessa sårbarheter utnyttjas framgångsrikt kan det leda till att en angripare tar full kontroll över hela den virtuella infrastrukturen. Med fjärrkodkörning kan skadlig programvara installeras, och med privilegieförhöjning kan kritiska systemfiler och tjänster manipuleras. Detta utgör ett allvarligt hot, särskilt i miljöer där VMware vCenter Server hanterar stora mängder data och virtuella maskiner.

Rekommendationer för Åtgärd

  • Uppdatera omedelbart: Broadcom rekommenderar starkt att administratörer omedelbart uppdaterar till den senaste versionen av VMware vCenter Server. Uppdateringar och patchar är de mest effektiva sätten att åtgärda dessa kritiska sårbarheter.
  • Segmentera Nätverkstillgången: Begränsa åtkomsten till vCenter Server till endast betrodda nätverk eller VPN-anslutningar. Genom att segmentera nätverkstrafiken kan risken för utnyttjande minskas.
  • Övervakning av System: Implementera noggrann övervakning för att snabbt identifiera misstänkt aktivitet som kan indikera försök till intrång eller utnyttjande av sårbarheter.

Varför Detta Är Viktigt

VMware vCenter Server är ett centralt system för hantering av virtuella miljöer, och många företag är beroende av det för sina molntjänster och interna system. En attack som utnyttjar dessa sårbarheter kan få förödande konsekvenser, inklusive driftstopp, dataförlust och potentiella kostnader kopplade till återställning och incidenthantering. Därför är det avgörande att snabbt agera för att minimera riskerna.

Slutsats

De nyligen identifierade sårbarheterna, CVE-2024-38812 och CVE-2024-38813, utgör en betydande säkerhetsrisk för VMware vCenter Server-användare. Att snabbt applicera de senaste uppdateringarna och stärka säkerhetsåtgärderna kring nätverksåtkomst är avgörande för att minimera dessa risker. Organisationer som är beroende av vCenter bör se över sina säkerhetsprotokoll och implementera proaktiva säkerhetslösningar för att skydda sin virtuella infrastruktur.

Posted on

Viktig säkerhetsuppdatering för VMware vCenter Server

VMware har nyligen släppt kritiska säkerhetsuppdateringar för vCenter Server som adresserar två allvarliga sårbarheter: en heap-overflow-sårbarhet (CVE-2024-38812) och en privilegieeskalering (CVE-2024-38813). Dessa sårbarheter kan potentiellt utnyttjas av illvilliga aktörer och påverka systemets säkerhet allvarligt.

Sammanfattning av sårbarheterna

CVE-2024-38812 – Heap-overflow sårbarhet

  • Beskrivning: En sårbarhet i implementeringen av DCERPC-protokollet i vCenter Server.
  • Påverkan: En angripare med nätverksåtkomst kan skicka ett speciellt utformat nätverkspaket som kan leda till fjärrkörning av kod.
  • Allvarlighetsgrad: Kritisk med en CVSSv3-baspoäng på 9.8.

CVE-2024-38813 – Privilegieeskalering

  • Beskrivning: En sårbarhet som tillåter en angripare att eskalera sina privilegier till root-nivå.
  • Påverkan: Genom att skicka ett speciellt utformat nätverkspaket kan en angripare få högre behörighet på systemet.
  • Allvarlighetsgrad: Viktig med en CVSSv3-baspoäng på 7.5.

Påverkade produkter

  • VMware vCenter Server versioner 7.0 och 8.0.
  • VMware Cloud Foundation versioner 4.x och 5.x.

Rekommenderade åtgärder

Uppdatera till senaste versionen

För att åtgärda dessa sårbarheter bör du omedelbart uppdatera till följande versioner:

  • vCenter Server 8.0: Uppdatera till 8.0 U3b.
  • vCenter Server 7.0: Uppdatera till 7.0 U3s.
  • VMware Cloud Foundation 5.x/4.x: Följ asynkron patchningsguide enligt KB88287.

Observera: VMware har identifierat att uppdateringen vCenter Server 8.0 U3b kan introducera funktionsproblem. Läs KB377734 för mer information innan du uppdaterar.

Inga tillgängliga workarounds

Det finns inga tillgängliga inbyggda lösningar för dessa sårbarheter. Det är därför avgörande att du applicerar de officiella uppdateringarna.

Så här uppdaterar du

  1. Ladda ner uppdateringen:
  2. Följ installationsinstruktionerna:
  3. Verifiera uppdateringen:
    • Efter installationen, kontrollera att systemet fungerar korrekt och att sårbarheterna har åtgärdats.

Slutsats

Att skydda din VMware-infrastruktur är av yttersta vikt. Vi uppmanar alla administratörer att omedelbart vidta åtgärder för att uppdatera sina system och därmed minimera risken för potentiella säkerhetsincidenter.

För ytterligare information och vanliga frågor, besök: