Vägledning för blockering av återställning av virtualiseringsbaserade säkerhetsrelaterade säkerhetsuppdateringar (VBS)

Viktig information om SkuSiPolicy.p7b-policyn

Anvisningar om hur du tillämpar den uppdaterade principen finns i avsnittet Distribuera en Microsoft-signerad återkallningsprincip (SkuSiPolicy.p7b ). 

I denna artikel

• Sammanfattning

• Påverkans omfattning

• Tillgängliga lösningar

• Förstå begränsningsrisker

• Riktlinjer för begränsningsdistribution

  • Distribuera en Microsoft-signerad återkallningsprincip (SkuSiPolicy.p7b)

  • Uppdatera externa startmedia

• Windows-händelseloggar

  • Principaktiveringshändelser

  • Granska och blockera händelser

• Principborttagnings- och återställningsprocedur

• Ändringar som gjorts i den här artikeln

Sammanfattning

Microsoft har blivit medveten om en säkerhetsrisk i Windows som gör att en angripare med administratörsbehörighet kan ersätta uppdaterade Windows-systemfiler som har äldre versioner, vilket öppnar dörren för en angripare att återinföra sårbarheter för virtualiseringsbaserad säkerhet (VBS).  Återställning av dessa binärfiler kan göra det möjligt för en angripare att kringgå VBS-säkerhetsfunktioner och exfiltera data som skyddas av VBS. Det här problemet beskrivs i CVE-2024-21302 | Windows Säkerhetsrisk med säkerhetsrisk för kernelläge för rättighetsökning.

För att lösa det här problemet återkallar vi sårbara VBS-systemfiler som inte uppdateras. På grund av det stora antalet VBS-relaterade filer som måste blockeras använder vi en alternativ metod för att blockera filversioner som inte uppdateras.

Påverkans omfattning

Alla Windows-enheter som stöder VBS påverkas av det här problemet. Detta omfattar lokala fysiska enheter och virtuella datorer. VBS stöds i Windows 10 och senare Windows-versioner och Windows Server 2016 och senare Windows Server versioner.

VBS-tillståndet kan kontrolleras via Microsofts systeminformationsverktyg (Msinfo32.exe). Det här verktyget samlar in information om din enhet. När du har startat Msinfo32.exe rullar du ned till den Virtualiseringsbaserade säkerhetsraden . Om värdet för raden körs aktiveras och körs VBS.

VBS-tillståndet kan också kontrolleras med Windows PowerShell med hjälp av WMI-klassen Win32_DeviceGuard. Om du vill fråga VBS-tillståndet från PowerShell öppnar du en förhöjd Windows PowerShell session och kör sedan följande kommando:

När du har kört ovanstående PowerShell-kommando ska VBS-statusen vara något av följande.

Tillgängliga lösningar

För alla versioner av Windows 10 som stöds, version 1507 och senare Windows-versioner, och Windows Server 2016 och senare Windows Server versioner, kan administratörer distribuera en Microsoft-signerad återkallningsprincip (SkuSiPolicy.p7b). Detta blockerar sårbara versioner av VBS-systemfiler som inte uppdateras från att läsas in av operativsystemet.  

När SkuSiPolicy.p7b tillämpas på en Windows-enhet låses principen även till enheten genom att en variabel läggs till i den inbyggda UEFI-programvaran. Vid start blockeras inläsningen av principen och Windows inläsningen av binärfiler som strider mot principen. Om UEFI-låset används och principen tas bort eller ersätts med en äldre version startar inte Windows-starthanteraren och enheten startar inte. Det här startfelet visar inget fel och systemet fortsätter till nästa tillgängliga startalternativ, vilket kan resultera i en startloop.

En ytterligare Microsoft-signerad CI-princip som är aktiverad som standard och som inte kräver några ytterligare distributionssteg har lagts till som inte är bunden till UEFI. Den signerade CI-principen läses in under starten och tillämpningen av den här principen förhindrar återställning av VBS-systemfiler under den startsessionen. Till skillnad från SkuSiPolicy.p7b kan en enhet fortsätta att starta om uppdateringen inte är installerad. Den här principen ingår i alla versioner av Windows 10 som stöds, version 1507 och senare. SkuSkiPolicy.p7b kan fortfarande tillämpas av administratörer för att ge ytterligare skydd för återställning över startsessioner.   

Windows-uppmätta startloggar som används för att intyga datorns starthälsa innehåller information om vilken principversion som läses in under startprocessen. Dessa loggar underhålls på ett säkert sätt av TPM under starten, och Microsofts attestation-tjänster parsar dessa loggar för att kontrollera att rätt principversioner läses in. Attestationstjänsterna tillämpar regler som säkerställer att en viss principversion eller högre läses in. annars kommer systemet inte att intygas som hälsosamt.

För att principreduceringen ska fungera måste principen uppdateras med underhållsuppdateringen för Windows eftersom komponenterna i Windows och principen måste vara från samma version. Om policyn kopieras till enheten kanske enheten inte startar om fel version av begränsningen tillämpas eller om begränsningen kanske inte fungerar som förväntat. Dessutom bör åtgärder som beskrivs i KB5025885 tillämpas på enheten.

På Windows 11 version 24H2, Windows Server 2022 och Windows Server 23H2 lägger DRTM (Dynamic Root of Trust for Measurement) till ytterligare en begränsning för återställningsrisken. Den här begränsningen är aktiverad som standard. På de här systemen är VBS-skyddade krypteringsnycklar bundna till den standardaktiverade VBS CI-principen för startsession och öppnas bara om den matchande CI-principversionen tillämpas. För att aktivera användarinitierade återställningar har en respitperiod lagts till för att aktivera säker återställning av 1 version av Windows-uppdateringspaketet utan att förlora möjligheten att öppna VSM-huvudnyckeln. Men den användarinitierade återställningen är bara möjlig om SkuSiPolicy.p7b inte tillämpas. VBS CI-principen tillämpar att alla start binärfiler inte har återställts till återkallade versioner. Det innebär att om en angripare med administratörsbehörighet återställer sårbara start binärfiler startar inte systemet. Om både CI-principen och binärfilerna återställs till en tidigare version kommer vsm-skyddade data inte att öppnas.

Förstå begränsningsrisker

Du måste vara medveten om potentiella risker innan du använder den Microsoft-signerade återkallelseprincipen. Granska dessa risker och gör eventuella uppdateringar av återställningsmedia innan du tillämpar begränsningen.

Obs! Dessa risker gäller endast SkuSiPolicy.p7b-principen och gäller inte för standardaktiverade skydd.

• UEFI Lås och avinstallera uppdateringar. När du har tillämpat UEFI-låset med den Microsoft-signerade återkallelseprincipen på en enhet kan enheten inte återställas (genom att avinstallera Windows-uppdateringar, med hjälp av en återställningspunkt eller på annat sätt) om du fortsätter att använda Säker start. Även om du formaterar om disken tas inte UEFI-låset bort om det redan har tillämpats. Det innebär att om du försöker återställa Windows-operativsystemet till ett tidigare tillstånd som inte har den tillämpade begränsningen startar inte enheten, inget felmeddelande visas och UEFI går vidare till nästa tillgängliga startalternativ. Detta kan resultera i en startloop. Du måste inaktivera Säker start för att ta bort UEFI-låset. Tänk på alla möjliga konsekvenser och testa noggrant innan du tillämpar de återkallningar som beskrivs i den här artikeln på din enhet.

• Externt startmedium. När UEFI-låsåtgärderna har tillämpats på en enhet måste externa startmedia uppdateras med den senaste Windows-uppdateringen installerad på enheten. Om externa startmedia inte uppdateras till samma Windows-uppdateringsversion kanske enheten inte startar från det mediet. Läs anvisningarna i avsnittet Uppdatera externa startmedia innan du tillämpar lösningarna.

• Windows Återställningsmiljö. Windows Återställningsmiljö (WinRE) på enheten måste uppdateras med den senaste Windows Safe OS Dynamic Update som släpptes 8 juli 2025 på enheten innan SkuSipolicy.p7b tillämpas på enheten. Om du utelämnar det här steget kan WinRE inte köra funktionen Återställ dator.  Mer information finns i Lägga till ett uppdateringspaket i Windows RE.

• PXE-start (Pre-boot Execution Environment). Om begränsningen distribueras till en enhet och du försöker använda PXE-start startar inte enheten om inte den senaste Windows-uppdateringen även tillämpas på PXE-serverstartavbildningen. Vi rekommenderar inte att du distribuerar åtgärder till nätverksstartkällor om inte PXE-startservern har uppdaterats till den senaste Windows-uppdateringen som släpptes i januari 2025 eller senare, inklusive PXE-starthanteraren.  

Riktlinjer för begränsningsdistribution

Du kan åtgärda problemen som beskrivs i den här artikeln genom att distribuera en Microsoft-signerad återkallningsprincip (SkuSiPolicy.p7b). Den här begränsningen stöds endast i Windows 10 version 1507 och senare Windows-versioner och Windows Server 2016.

Obs! Om du använder BitLocker kontrollerar du att BitLocker-återställningsnyckeln har säkerhetskopierats. Du kan köra följande kommando från en kommandotolk med administratörsbehörighet och anteckna det 48-siffriga numeriska lösenordet:

Windows-händelseloggar

Windows loggar händelser när principer för kodintegritet, inklusive SkuSiPolicy.p7b, läses in och när en fil blockeras från att läsas in på grund av principtvingande. Du kan använda dessa händelser för att verifiera att begränsningen har tillämpats.

Kodintegritetsloggar är tillgängliga i Windows Loggboken under Program- och tjänstloggar > Microsoft > Windows > CodeIntegrity > > application and services-loggar > Services-loggar > Microsoft > Windows > AppLocker > MSI and Script.

Mer information om kodintegritetshändelser finns i driftsguiden för Windows Defender-programreglering.

Principborttagnings- och återställningsprocedur

Om något går fel efter att du har tillämpat begränsningen kan du använda följande steg för att ta bort begränsningen:

1. Pausa BitLocker om det är aktiverat. Kör följande kommando från ett fönster med upphöjd kommandotolk:

   Manager-bde -protectors -disable c: -rebootcount 3

2. Inaktivera Säker start från UEFI BIOS-menyn.
   
   Proceduren för att inaktivera Säker start skiljer sig mellan enhetstillverkare och modeller. Om du behöver hjälp med att hitta var du kan inaktivera Säker start kan du läsa dokumentationen från enhetstillverkaren. Mer information finns i Inaktivera säker start.

3. Ta bort principen SkuSiPolicy.p7b.

   1. Starta Windows som vanligt och logga sedan in.
      
      Principen SkuSiPolicy.p7b måste tas bort från följande plats:

      • <EFI-systempartition>\Microsoft\Boot\SkuSiPolicy.p7b

   2. Kör följande kommandon från en förhöjd Windows PowerShell session för att rensa principen från dessa platser:

      $PolicyBinary = $env:windir+"\System32\SecureBootUpdates\SkuSiPolicy.p7b"
      $MountPoint = 's:'
      
      $EFIPolicyPath = "$MountPoint\EFI\Microsoft\Boot\SkuSiPolicy.p7b"
      $EFIDestinationFolder="$MountPoint\EFI\Microsoft\Boot"
      mountvol $MountPoint /S
      if (-Not (Test-Path $EFIDestinationFolder)) { New-Item -Path $EFIDestinationFolder -Type Directory -Force }
      
      if (Test-Path   $EFIPolicyPath ) {Remove-Item -Path $EFIPolicyPath -Force }
      
      ​​​​​​​mountvol $MountPoint /D

4. Aktivera Säker start från BIOS.
   
   Läs dokumentationen från enhetstillverkaren för att hitta var säker start ska aktiveras.
   
   Om du inaktiverade Säker start i steg 1 och enheten skyddas av BitLocker , pausar du BitLocker-skyddet och aktiverar sedan Säker start från UEFI BIOS-menyn .

5. Aktivera BitLocker. Kör följande kommando från ett fönster med upphöjd kommandotolk:

   Manager-bde -protectors -enable c:

6. Starta om enheten.