Code Integrity (WDAC)

Code Integrity ist eine von Microsoft seit Windows Vista eingesetzte Technologie, um Gerätetreiber und Kernkomponenten des Betriebsssystem vor Manipulation zu schützen, s. dazu

Seit Windows 10 und Windows Server 2016 wird Code Integrity als Bestandteil der Device Guard-Funktionalität von Microsoft eingeordnet.

Device Guard ist eine Funktionalität, die Windows vor Manipulationen schützt. Device Guard kann dafür hardware-basierte Funktionalitäten wie TPM, UEFI Secure Boot und Virtualisierungserweiterungen der CPU nutzen.

Administratoren können die Code Integrity-Funktionalität per PowerShell konfigurieren, s. dazu

https://docs.microsoft.com/en-us/powershell/module/configci/?view=win10-ps

Code Integrity ist die dritte Generation einer Software Whitelisting-Funktionalität von Microsoft. Code Integrity selbst wird von Microsoft  seit Windows 10 (1709) als Windows Defender Application Control, kurz WDAC, bezeichnet und seitdem als Funktionalität der Antivirus-Lösung Microsoft Defender zugeordnet.

WDAC wird von Microsoft als Sicherheitsmerkmal (Security feature) eingestuft  anders als Applocker (der Vorgänger von WDAC) , welches nur als Teil einer mehrstufigen Verteidigungsstrategie (Defence-in-Depth security feature) klassifiziert wird, s. dazu
https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria?rtc=1

Wichtig ist diese Einstufung in Bezug auf die Behebung von Bugs, da Microsoft sich selbst verpflichtet Fehler in Sicherheitsbarieren und Sicherheitsmerkmalen in jedem Fall zu beheben.

Darüber hinaus wird Code Integrity auch in Windows 10 S-Mode verwendet, um die Sicherheit des Systems in Bezug auf Anwendungen zu gewährleisten.

Weitere Informationsquellen:

Systemversiegelung mittels Software Whitelisting

Software Whitelisting versiegelt ein Windows-System und schützt vor jeglicher Malware, die sich nicht auf der Liste (Whitelist/Positivliste) der zugelassenen Anwendungen befindet, s. Software Whitelisting - der bessere Anti-Virus-Schutz.

Code Integrity hat gegenüber Applocker und Software Restrictions folgende Vorteile:

  1. Code Integrity-Regeln werden unabhängig vom jeweiligen Nutzer angewendet und gelten somit uneingeschränkt auch für den Betriebssystemnutzer "System" anders als bei Applocker, s. dazu auch "Auswirkungen von Microsoft Software Whitelisting auf das Systemkonto (built-in Benutzer "System")" in "Software Whitelisting - der bessere Virenschutz".
     

  2. Skriptdateien der PowerShell werden im eingeschränkten Sprachmodus (Constraint Language Mode) ausgeführt und der Zugriff auf COM-Objekte ist per "Windows Secure Mode Policy" (früher "Windows Lockdown Policy") für Microsoft-Skriptdateien JScript, PowerShell und VBScript beschränkt, außer die Skriptdateien befinden sich auf der Whitelist.
       
  3. Code Integrity-Richtlinien können signiert werden, um eine Manipulation der Regeln zu verhindern, s. dazu
    https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering

Code Integrity hat gegenüber Applocker folgende Nachteile:

  1. Regeln können nicht pro Nutzer sondern nur für das gesamte System konfiguriert werden.

Systemvoraussetzungen

Erstellen von Code Integrity-Richtlinien

  • ab Windows 10 1909 (alle Editionen)
  • ab Windows 10 Enterprise/Education 
  • ab Windows Server 2016 

Anwenden von Code Integrity-Richtlinien

  • ab Windows 10  (alle Editionen) (per Gruppenrichtlinie nur Enterprise/Education)
  • ab Windows Server 2016 

Quelle:

Systemvoraussetzungen des Code Integrity-Toolkits

Nutzung des Code Integrity-Toolkits

  • ab Windows 10 1809/Server 2019

Die Code Integrity-Toolkits können erst sinnvoll ab Windows 10 1809/Server 2019 benutzt werden, da erst ab dieser Version eine Aktualisierung der Regeln ohne Neustart des Systems möglich ist (Offiziell ist diese Funktionalität ab Windows 10 1709 verfügbar, aber fehlerfrei leider erst ab Windows 10 1809). Für die Nutzung von Code Integrity ohne das Code Integrity-Toolkit gelten die unter "Systemvoraussetzungen" angegeben Daten.

Inhalt des Code Integrity-ToolKits

Script Funktion
CI-Activate.bat Software Whitelist-Einträge für Standardverzeichnisse erstellen und Software Whitelisting aktivieren.
CI-ConfigAudit.bat Code Integrity Logging in das Ereignisprotokoll konfigurieren. Skript-Parameter: 0 - Deaktivieren 1- Aktivieren
CI-Cleanup.bat Software Whitelisting-Konfiguration löschen.
CI-Disable.bat Software Whitelisting deaktivieren.
CI-Enable.bat Software Whitelisting aktivieren.
CI-ScheduleNextReboot.bat Software Whitelist-Einträge beim nächsten Neustart erstellen (Versiegeln des Systems).
CI-SealDir.bat Software Whitelist-Einträge für den Inhalt eines Verzeichnisses erstellen/aktualisieren.
CI-SealSystem.bat Software Whitelist-Einträge erstellen (Versiegeln des Systems).
CI-Status.bat Anzeige des Software Whitelisting Status.
CI-UpdatePolicy.bat Aktualisiert die Software Whitelist-Richtlinie, s. FAQ.
CIv1.ps1 Powershell-Skript zur Code Integrity-Richtlinienerstellung ab Windows 10 1809/Windows Server 2019.

Herunterladen des Code Integrity-Tookits und Aktivierung von Code Integrity

Nachdem Sie die Systemvoraussetzungen überprüft haben, laden Sie sich die Datei CIToolkit.cab von https://softsrv.uni-rostock.de/pub/uni-rostock/rz/NT-Kurs/ToolKit/CIToolkit.cab  herunter und entpacken die Dateien z.B. in das Verzeichnis C:\Soft\Tools (wurde in Phase 1 der Anleitung "Wie installiere und konfiguriere ich ein sicheres und robustes Windows System?" erstellt) per GUI oder mit folgendem Befehl:

    expand CIToolKit.cab -F:* C:\Soft\Tools

Anschließend können Sie Code Integrity mit dem Skript "CI-Activate.bat" aktivieren.

Anpassen des Code Integrity-Toolkits

Die Aktionen des Code Integrity-Toolkits sind einfach anpassbar, indem Sie eine Datei namens civ1.cfg im Verzeichnis der CI-Skripte oder im Verzeichnis C:\Logs\WinConfig erstellen und diese Datei zeilenweise mit Konfigurationsparametern aus der nachfolgenden Tabelle füllen, z.B.

$AllowFullLanguageMode=1

 Die folgende Tabelle beschreibt Variablen, die Sie nutzen können, um das Code Integrity-Toolkit an Ihre Umgebung anzupassen:

Skriptvariablen des Code Integrity-ToolKits

Variable Mögliche Werte Standard Bedeutung
$AllowAllCOMObjects 0 oder 1   Erlaubt uneingeschränkten Zugriff auf alle COM -Objekte
$AllowAllIECOMObjects 0 oder 1   Erlaubt uneingeschränkten Zugriff auf alle COM -Objekte des Internet Explorers
$AllowAllMSICOMObjects 0 oder 1   Erlaubt uneingeschränkten Zugriff auf alle COM -Objekte des Windows Installers
$AllowAllPowershellCOMObjects 0 oder 1   Erlaubt uneingeschränkten Zugriff auf alle COM -Objekte der PowerShell
$AllowAllWSHCOMObjects 0 oder 1   Erlaubt uneingeschränkten Zugriff auf alle COM -Objekte des Windows Scripting Hosts
$AllowAllVBACOMObjects 0 oder 1   Erlaubt uneingeschränkten Zugriff auf alle COM -Objekte von Visual Basic for Applications
$AllowFlightSigning 0 oder 1   Erlaubt die Nutzung von Windows Insider-Builds
$AllowFullLanguageMode 0 oder 1   Erlaubt den Full Language Mode für die PowerShell und PowerShell-Skripte
$AllowUserWriteableFilePaths 0 oder 1   Erlaubt FilePath-Regeln für nutzerbeschreibbare Verzeichnisse
$AuditMode 0 oder 1   Aktiviert den Audit-Modus
$DenyDirs Komma getrennte Liste von Verzeichnissen C:\Logs\WinConfig \ CIPolicy \ Files2Block Liste der Verzeichnisse, die nach Programmdateien für den Aufbau der Software Blacklist durchsucht werden
$Dirs Komma getrennte Liste von Verzeichnissen s.FAQ Liste der Verzeichnisse, die nach Programmdateien für den Aufbau der Software Whitelist durchsucht werden
$EnableApplockerScriptRules 0 oder 1   Aktiviere Applocker-Skriptregeln 
$EnableDynamicCodeSecurity 0 oder 1   Erweitert den Schutz auf .NET-Anwendungen und dynamisch geladene Bibliotheken
$EnableMSBlockRules 0 oder 1 1 Aktiviere Microsoft Dateiblockregeln 
$EnableMSBlockRulesExceptions 0 oder 1   Schließe bestimmte Regeln der Microsoft Dateiblock aus, z.B. Microsoft.Workflow.Compiler.exe, MSBuild.exe u.a.
$EnableMSDriverBlockRules 0 oder 1   Aktiviere Microsoft Treiberblockregeln 
$ExcludedDirs Komma getrennte Liste von Verzeichnissen s.FAQ Liste der Verzeichnisse, die nicht nach Programmdateien für den Aufbau der Software Whitelist durchsucht werden
$FileNameOnlyDirs Komma getrennte Liste von Verzeichnissen C: \Logs \WinConfig \CIPolicy \Files2Name Liste von Verzeichnissen, für die vorrangig Dateinamen-Regeln (Filename-Regeln) erstellt werden
$FilePathDenyDirs Komma getrennte Liste von Verzeichnissen - Liste von Verzeichnissen, für die pfad-basierte Deny-Regeln (FilePath-Regeln) erstellt werden
$FilePathDirs Komma getrennte Liste von Verzeichnissen - Liste von Verzeichnissen, für die pfad-basierte Allow-Regeln (FilePath-Regeln) erstellt werden
$FullLanguageModeUsers Komma getrennte Liste von Benutzern S-1-5-32-544 Liste von Benutzern, die den Full Language Mode der PowerShell nutzen dürfen
$HashOnlyDirs Komma getrennte Liste von Verzeichnissen C: \ Logs \ WinConfig\ CIPolicy \ Files2Hash, $env:SystemRoot \ Assembly, $env:SystemRoot \ Installer Liste von Verzeichnissen, für die hash-basierte Regeln erstellt werden
$IncludeWinSxSDir 0 oder 1 1 0=Erstellt FilePath-Regeln für das Verzeichnis C:\Windows\WinSxS 1=Erstellt Regeln für das Verzeichnis C:\Windows\WinSxS wie durch die Variable $ProtectionLevel konfiguriert
$PreferFilePathRules 0 oder 1   Erstellt vorrangig FilePath-Regeln (nutzbar ab Windows-Build 19042)
$ProtectionLevel Medium oder "High" High Erstellt vorrangig zertifikatsbasierte Publisher-Regeln (Medium) oder möglichst nur zertifikatsbasierte FilePublisher-Regeln (High)
$PublisherDirs Komma getrennte Liste von Verzeichnissen C : \ProgramData \ Microsoft \ Windows Defender Liste von Verzeichnissen, für die vorrangig zertifikatsbasierte Regeln (Publisher-Regeln) erstellt werden
$WindirPublisherRules 0 oder 1 1 Erstellt vorrangig zertifikatsbasierte Publisher-Regeln (1) oder möglichst zertifikatsbasierte FilePublisher-Regeln (0) für das Windows-Verzeichnis
$UseFilePathRulesForSystemRootHashonlyDirs 0 oder 1   Erstellt FilePath-Regeln für die Verzeichnisse der Variable $HashOnlyDirs aus %SystemRoot% (nutzbar ab Windows-Build 19042)

Nutzung des Toolkits

Die vollständige Versiegelung des Systems per CI-Sealsystem.bat kann sehr lange dauern (bis zu 60 Minuten und mehr).

Anschließend ist eine erneute vollständige Versiegelung jedoch nicht mehr notwendig, da vorrangig zertifikatsbasierte Code Integrity-Regeln erstellt werden, wenn die Dateien signiert sind und hash-basierte Reglen nur als Ausnahme (Fallback), wenn die Dateien unsigniert sind. Daher müssen zukünftig nur noch für veränderte unsignierte Dateien neue hash-basierte Regeln erstellt werden.

Zertifikatsbasierte Publisher-Regeln verwenden das PCA-Zertifikat (Zwischenzertifikat) und den Common-Name des Leaf-Zertifikates (Endzertifikat) einer signierten Datei. Publisher-Regeln eignen sich sehr gut, um signierte Dateien eines bestimmten Herstellers wie z.B. Microsoft oder Intel für die Ausführung zu autorisieren.

Zertifikatsbasierte FilePublisher-Regeln verwenden das PCA-Zertifikat (Zwischenzertifikat) und den Common-Name des Leaf-Zertifikates (Endzertifikat) und die Versionsangaben einer signierten Datei.

Standardmäßig werden für alle Verzeichnisse zertifikatsbasierte FilePublisher-Regeln Regeln erstellt, außer für folgende Verzeichnisse für die zertifikatsbasierte Publisher-Regeln erstellt werden:

  • C:\Windows
  • C:\ProgramData\Microsoft\Windows Defender

Sie können das Skript CI-UpdateHashOnlyDirs.bat verwenden, um für veränderte Dateien neue hash-basierte Regeln zu erstellen. Das Skript erneuert standardmäßig die hash-basierten Regeln für die folgenden Verzeichnisse:

  • $env:SystemRoot\Assembly
  • $env:SystemRoot\Installer
  • C:\Logs\WinConfig\CIPolicy\Files2Hash

Das Verzeichnis $env:SystemRoot\Assembly (C:\Windows\Assembly) enthält .NET 2.0 Assemblies (vorkompilierter .NET 2.0 Programmcode).

Das Verzeichnis C:\Logs\WinConfig\CIPolicy\Files2Hash können Sie nutzen, um hash-basierte Regeln für bestimmte Anwendungen zu erzeugen, in dem Sie die entsprechenden Dateien in das Verzeichnis C:\Logs\WinConfig\CIPolicy\Files2Hash kopieren und anschließend das Skript CI-UpdateHashOnlyDirs.bat ausführen.

Achtung!

Die Batchdateien müssen in einer administrativen Kommandozeile ausgeführt werden. 

  • Software Whitelist Status anzeigen
     
    CI-Status.bat
     
  • Software Whitelist löschen
     
    CI-Cleanup.bat
     
  • Software Whitelist deaktivieren
     
    CI-Disable.bat
       
  • Software Whitelist aktivieren
     
    CI-Enable.bat
     
  • System "versiegeln"
     
    CI-SealSystem.bat
     
  • Programmdateien im Verzeichnis "C:\Soft\Apps\SuperEditor\" in die Software Whitelist aufnehmen
     
    CI-SealDir.bat C:\Soft\Apps\SuperEditor\
     
  • CI-Logging in die Ereignisanzeige aktivieren
      
    CI-ConfigAudit.bat 1
      
  • CI-Logging in die Ereignisanzeige deaktivieren
     
    CI-ConfigAudit.bat 0

FAQ

  1. Welche Dateiendungen werden beachtet
     
    Treiberdateien: *.sys
     
    Binärprogrammdateien: *.exe, *.com

    Programmbibliotheken: *.dll, *.ocx

    Skriptdateien: *.js, *.ps1, *.vbs

    Universal  Windows Apps (UWP): *.appx

    Windows Installer-Dateien: *.msi, *.msp, *.mst

     
    Quelle:
    https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/feature-availability
       

  2. Welche Verzeichnisse werden standardmäßig für den Aufbau der Software Whitelist durchsucht?

    Alle Windows-Systeme:
    "C:\Soft\Apps","C:\Soft\Tools","C:\Program Files" oder "C:\Programme", "C:\Windows", "C:\ProgramData\Microsoft\Windows Defender"

    Zusätzlich bei 64-Bit Windows-Systeme:
    "C:\Program Files (x86)" oder "C:\Programme (x86)"

    Zusätzlich bei Active Directory-Umgebungen:
    \\AD-DNS-Name\NETLOGON \\DC-Name\NETLOGON
       

  3. Welche Verzeichnisse werden standardmäßig bei der Erstellung der Whitelist-Regeln ignoriert?

    C:\WINDOWS\assembly\temp
    C:\WINDOWS\assembly\tmp
    C:\WINDOWS\CbsTemp
    C:\WINDOWS\Logs
    C:\WINDOWS\ServiceProfiles
    C:\WINDOWS\Servicing\LCU
    C:\WINDOWS\Servicing\Packages
    C:\WINDOWS\WinSxS
    C:\WINDOWS\system32\CatRoot
    C:\WINDOWS\System32\config\systemprofile
    C:\WINDOWS\System32\LogFiles
    C:\WINDOWS\SysWOW64\config\systemprofile
    C:\WINDOWS\Debug
    C:\WINDOWS\PCHEALTH
    C:\WINDOWS\Registration
    C:\WINDOWS\System32\BioAPIFFDB
    C:\WINDOWS\System32\catroot2
    C:\WINDOWS\System32\Com\dmp
    C:\WINDOWS\System32\FxsTmp
    C:\WINDOWS\System32\Microsoft
    C:\WINDOWS\System32\spool\drivers\color
    C:\WINDOWS\System32\Spool\Printers
    C:\WINDOWS\System32\Spool\Servers
    C:\WINDOWS\System32\Tasks
    C:\WINDOWS\SysWOW64\Com\dmp
    C:\WINDOWS\SysWOW64\FxsTmp
    C:\WINDOWS\SysWOW64\Tasks
    C:\WINDOWS\Tasks
    C:\WINDOWS\TEMP
    C:\WINDOWS\Tracing

    Dies wird durch die Skriptvariable $ExcludedDirs konfiguriert.
      

  4. Welche Programmdateien werden standardmäßig blockiert und wie kann ich die Liste der blockierten Dateien anpassen?

    Die Ausführung folgender Programmdateien wird über Blockregeln verhindert:
     
    addinprocess.exe
    addinprocess32.exe
    addinutil.exe
    bash.exe
    bginfo.exe
    cdb.exe
    csi.exe
    dbghost.exe
    dbgsvc.exe
    dnx.exe
    fsi.exe
    fsiAnyCpu.exe
    kd.exe
    ntkd.exe
    lxssmanager.dll
    msbuild.exe
    mshta.exe
    ntsd.exe
    rcsi.exe
    windbg.exe
    wmic.exe

    Diese Liste ist einer Microsoft-Empfehlung entnommen, s. dazu
    https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules

    Sie können die Liste der von Microsoft blockierten Programmdateien nicht anpassen, jedoch können Sie die Benutzung der Microsoft Blockregeln über die Skriptvariable $EnableMSBlockRules ein oder ausschalten, s. dazu die Tabelle "Skriptvariablen des Code Integrity-ToolKits" weiter oben.

    Wenn Sie die Ausführung weiterer Programme blockieren wollen, dann können Sie die Skriptvariable $DenyDirs verwenden. Die Skriptvariable $DenyDirs legt die Verzeichnisse fest, für dessen Inhalte Blockregeln erstellt werden. Zum grundsätzlichen Vorgehen s. dazu Punkt 5 dieser FAQ "Wie kann ich die Verzeichnisliste für den Aufbau der Software Whitelist für Programme verändern?".
      

  5. Wie kann ich die Verzeichnisliste für den Aufbau der Software Whitelist für Programme verändern?

    Passen Sie die Skriptvariable $Dirs für das Skript civ1.ps1 an.

    Dazu gehen Sie wie folgt vor:

    1. Legen Sie eine leere Datei namens civ1.cfg im Verzeichnis des Skripts civ1.ps1 (standardmäßig in C:\Soft\Tools) oder im Pfad C:\Logs\WinConfig an.

    2. Fügen Sie folgende Zeile in die entsprechende cfg-Datei ein, um
        
    a) die Variable $Dirs zu erweitern:

    $Dirs+="C:\MyApps" 
         
    b) die Variable $Dirs zu überschreiben:

    $Dirs="D:\Soft\Apps","D:\Soft\Tools","D:\Program Files","D:\Windows"
       

  6. Wie wird der Full Language Mode von PowerShell für die interaktive PowerShell für lokale Administratoren konfiguriert?

    Dazu gehen Sie wie folgt vor:

    1. Legen Sie eine leere Datei namens civ1.cfg im Verzeichnis des Skripts civ1.ps1 (standardmäßig in C:\Soft\Tools) oder im Pfad C:\Logs\WinConfig an.

    2. Fügen Sie folgende Zeile in die entsprechende cfg-Datei ein:

    $AllowFullLanguageMode=1

    Weitere Informationen zu den Language Modi der PowerShell:
    https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_language_modes 
    https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/design/script-enforcement 
    https://devblogs.microsoft.com/powershell/powershell-the-blue-team/#constrained-powershell 
    https://p0w3rsh3ll.wordpress.com/2019/03/07/applocker-and-powershell-how-do-they-tightly-work-together/ 

      

Bei Fragen oder Hinweisen zu diesem Dokument melden Sie sich bitte per E-Mail bei joerg.maletzky(at)uni-rostock.de.