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

• https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc733982(v=ws.10)

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:

• https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control
• https://www.microsoft.com/security/blog/2017/10/23/introducing-windows-defender-application-control/
• https://www.microsoft.com/security/blog/2019/07/01/delivering-major-enhancements-in-windows-defender-application-control-with-the-windows-10-may-2019-update/
• https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/SiSyPHus/Workpackage7_Device_Guard.pdf
• https://bohops.com/2019/01/10/com-xsl-transformation-bypassing-microsoft-application-control-solutions-cve-2018-8492/
• https://posts.specterops.io/documenting-and-attacking-a-windows-defender-application-control-feature-the-hard-way-a-case-73dd1e11be3a
• https://www.windowspro.de/wolfgang-sommergut/application-whitelisting-vergleich-richtlinien-fuer-software-einschraenkung-srp
• http://video.ch9.ms/sessions/ignite/2015/decks/BRK2336_Sutherland.pptx
• GitHub - bohops/UltimateWDACBypassList: A centralized resource for previously documented WDAC bypass techniques 

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.

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:

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

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.

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.

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:

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

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.