Windows Defender Application Control Bypass

V dnešním článku se podíváme na ochranu v operačním systému Windows – řízení aplikací v programu Windows Defender, neboli WDAC. Windows Defender, jako vestavěné řešení pro ochranu před malwarem a jinými hrozbami, zahrnuje různé bezpečnostní mechanismy včetně řízení aplikací, které zajišťuje, že jsou spouštěny pouze ověřené a důvěryhodné programy. Nejprve si v článku ukážeme příklady definovaných zásad, nejčastější konfigurační chyby a jak jich zneužít ke spuštění libovolných binárních souborů.

WDAC je technologie navržená k řízení toho, které aplikace a ovladače mohou být na zařízení spuštěny. V podstatě se jedná o podobné bezpečnostní opatření jako je AppLocker, ale s několika klíčovými rozdíly. Nejvýznamnější z nich je, že Microsoft uznává WDAC jako oficiální bezpečnostní standard, což znamená, že je podstatně robustnější a veškeré nalezené bypassy jsou opraveny. Použitý termín v nadpisu článku „WDAC bypass“ není úplně přesný, neboť se ve skutečnosti nikdy neobchází WDAC jako takový. Místo toho musíme najít slabá místa / nedostatky v příslušné politice, která je na daném stroji vynucena.

WDAC zásady jsou nejprve definovány ve formátu XML – Microsoft dodává několik základních zásad, které lze nalézt v adresáři C:\Windows\schemas\CodeIntegrity\ExamplePolicies. Více politik lze následně sloučit do jediné zásady, která je poté zabalena do souboru .p7b a vynucena pomocí GPO (nebo jinou platformu pro správu, jako je Intune).

Aplikované zásady je možné získat buď lokálně z daného stroje nebo vzdáleně z příslušného GPO:

ls \\domain.local\SYSVOL\domain.local\Policies\{db76d039-f818-4a4c-acfa-9f5306591e12}\Machine\

 Size     Type    Last Modified         Name
 ----     ----    -------------         ----
 549b     fil     12/09/2024 16:35:21   comment.cmtx
 432b     fil     12/09/2024 16:35:21   Registry.pol

Soubor Registry.pol je možné stáhnou a rozparsovat pomocí nástroje Parse-PolFile. GPO politika jednoduše ukazuje na příslušný .p7b soubor, který je následně stažen a aplikován na každém zařízení:

Parse-PolFile .\Registry.pol

KeyName     : SOFTWARE\Policies\Microsoft\Windows\DeviceGuard
ValueName   : DeployConfigCIPolicy
ValueType   : REG_DWORD
ValueLength : 4
ValueData   : 1

KeyName     : SOFTWARE\Policies\Microsoft\Windows\DeviceGuard
ValueName   : ConfigCIPolicyFilePath
ValueType   : REG_SZ
ValueLength : 100
ValueData   : \\domain.local\SYSVOL\domain.local\scripts\CIPolicy.p7b

Naprosto běžně se jedná o lokaci, kde má právo pro čtení úplně každý uživatel, takže je možné soubor stáhnout pro offline prozkoumání. Případně je možné .p7b soubor získat přímo ze systému ve složce C:\Windows\System32\CodeIntegrity. Binární .p7b soubor je možné převést do čitelné podoby (zpět do XML formátu) pomocí nástroje CIPolicyParser.

PS C:\> ipmo C:\Tools\CIPolicyParser.ps1
PS C:\> ConvertTo-CIPolicy -BinaryFilePath .\CIPolicy.p7b -XmlFilePath CIPolicy.xml
1_wdac_xml

WDAC umožňuje velmi podrobnou kontrolu, pokud jde o důvěryhodnost aplikace. Mezi nejčastěji používaná pravidla patří:

  • Hash – umožňuje spouštění binárních souborů na základě hashů.
  • FileName - umožňuje spouštění binárních souborů na základě původních názvů souborů.
  • FilePath – umožňuje spouštět binární soubory ze specifických umístění (určité složky).
  • Publisher – umožňuje spouštět binární soubory, které jsou podepsány konkrétní certifikační autoritou.

Každé pravidlo může mít také „záložní“ pravidlo. Například „publisher“ jako primární a „filepath“ jako záložní. Tímto způsobem by se aplikace spustila, pokud by byla ve správné lokaci, i když by kontrola podpisu selhala.

Living Off The Land Binaries, skripty and knihovny

Stejně jako v případě AppLockeru existuje mnoho nativních binárních souborů Windows a skriptů, které lze použít ke spuštění libovolného kódu a obejit WDAC. Zmíněné nástroje obcházejí typické zásady WDAC, protože podepsané aplikace Windows jsou ve výchozím nastavení považované jako důvěryhodné. Společnost Microsoft aktivně udržuje doporučený seznam blokovaných binárních souborů jako řešení proti těmto nedostatkům, které by měly implementovány. Explicitní pravidla pro odmítnutí spuštění lze v XML souboru snadno dohledat:

2_wdac_deny

Jedná se o pravidla typu FileName, takže je kontrolován název souboru, se kterým byla aplikace původně zkompilována. Původní název je možné zobrazit ve vlastnostech daného binárního souboru:

3_wdac_deny_nazev_souboru

Při pokusu o spuštění jakékoli zablokované aplikace dojde k zobrazení chybové hlášky:

4_wdac_deny_spusteni

Způsob, jak zneužít důvěryhodné binární soubory, skripty nebo knihovny Windows, je najít takové, které nejsou blokovány zásadami. Ultimate WDAC Bypass List je skvělým zdrojem možných kandidátů.

Wildcard FilePaths

Nejrobustnější typ WDAC pravidla je založen na certifikátech vydavatele (podepisování kódu), avšak ne všichni vývojáři své aplikace podepisují. 7-Zip je ve Windows velmi populární komprimační nástroj, ale žádný z jejich binárních souborů není podepsaný.

Directory: C:\Program Files\7-Zip


SignerCertificate                         Status                                 Path
-----------------                         ------                                 ----
                                          NotSigned                              7-zip.dll
                                          NotSigned                              7-zip32.dll
                                          NotSigned                              7z.dll
                                          NotSigned                              7z.exe
                                          NotSigned                              7zFM.exe
                                          NotSigned                              7zG.exe
                                          NotSigned                              Uninstall.exe

Dalším nejlepším způsobem, jak takové nástroje přidat na seznam povolených, mohou být jednotlivá pravidla FilePath pro každý soubor a jako záložní pravidlo jeho hash. Absolutně líný, ale zároveň mnohem snazší způsob by byl prostě přidat na whitelist celý adresář. Takové pravidlo by pak mohlo vypadalo následovně:

<FileRules><AllowID="ID_ALLOW_A_001"FilePath="C:\Program Files\7-Zip\*"/><AllowID="ID_ALLOW_A_002"FileName="7zipInstall.exe"MinimumFileVersion="24.8.0.0"/></FileRules>

Jediné, co pro zneužití tohoto pravidla musíme udělat, je zkopírovat binární soubor do příslušného adresáře. Nicméně, u FilePath pravidel se defaultně uplatňuje další ochrana s názvem Runtime FilePath Rule Protection. Ta je ve výchozím nastavení povolena a kontroluje za běhu DACL daného umístění. Pokud do umístění mohou zapisovat všichni uživatelé bez oprávnění správce, pak WDAC zablokuje spuštění přestože je cesta v zásadách povolena. V našem konkrétním příkladě, pokud by došlo k nesprávné konfiguraci DACL na složku C:\Program Files\7-Zip, která by umožňovala všem standardním uživatelům nahrávat do ni spustitelné soubory, pak by WDAC prostě zablokoval vše v celém adresáři.

FileName

Další pravidlo z příkladu výše s nástrojem 7-Zip je pro jeho instalační program.

<FileRules><AllowID="ID_ALLOW_A_001"FilePath="C:\Program Files\7-Zip\*"/><AllowID="ID_ALLOW_A_002"FileName="7zipInstall.exe"MinimumFileVersion="24.8.0.0"/></FileRules>

Toto jednoduché pravidlo FileName bylo vygenerováno z instalačního EXE:

5_wdac_7zip_installer

Pravidlo vyžaduje, aby byla aplikace zkompilována s názvem "7zipInstall.exe" a verze souboru byla alespoň 24.8.0.0. Taková pravidla nejsou vůbec bezpečná, neboť můžeme při kompilaci zvolit libovolný název a číslo verze. Například v .NET projektu stačí pozměnit hodnoty ve vlastnostech projektu – Název sestavení a Verze souboru (v sekci Informace o sestavení):

6_wdac_nazev_souboru
6.2_wdac_verze_souboru

Zkompilované sestavení pak bude mít vlastnosti, které pravidlo vyžaduje, a spustí se:

7_wdac_sestaveni
8_wdac_spusteni

Trusted Signers

Některé společnosti vytvářejí a udržují své vlastní aplikace, které mohou být podepsány pomocí interní certifikační autority, jako je Active Directory Certificate Services. Zásady WDAC často považují tyto certifikační autority za důvěryhodné, aby bylo možné dané aplikace spouštět.

WDAC má dvě úrovně certifikační politiky (tři, pokud budeme počítat i „Root“, který ale není podporován). První je „Leaf“ a druhá je tzv. „PCA“ (zkratka pro Private Certificate Authority). Leaf přidá „trusted signers“ na úrovni jednotlivých podpisových certifikátů, v případě PCA se jedná o nejvyšší dostupný certifikát v řetězci (obvykle první certifikát pod kořenový certifikát). Leaf poskytuje mnohem podrobnější kontrolu, neboť každý jednotlivý vydaný certifikát pro podepisování kódu by musel být označen za důvěryhodný zvlášť, což samozřejmě vyžaduje větší režii pro správu. PCA je méně robustní, ale snáze se spravuje, protože jakýkoli certifikát pro podepisování kódu vydaný certifikační autoritou může být považován za důvěryhodný pouze za pomoci jediného pravidla.

V uměle vytvořeném příkladě se bude v rámci společnosti objevovat nástroj s názvem „DomainApp.exe“, který je podepsán podřízenou CA domény (CN=Domain.Local). Příslušný záznam v zásadách WDAC může být obtížnější najít, protože ve většině případů ztrácejí svá popisná jména. Vše, co můžeme vidět, je pouze „signer entry“ a TBS hash certifikátu:

<SignerName="Signer 2"ID="ID_Signer_S_0002"><CertRootType="TBS"Value="42ed0877ab83e95120d63f5d0cdf0f5404d7288ebaf88853d1d23a91ebee9904"/><Signer/>

TBS je zkratka pro "ToBeSigned", která je vypočtena z SignerCertificate podrobností o podepsaném binárním souboru. Abychom toto pravidlo obešli, musíme získat certifikát, pomocí kterého byla politika vygenerována, nebo požádat o vlastní certifikát ze stejné šablony pro podepisování kódu. Předpokládejme, ze v rámci dostupných šablon certifikátů se vyskytuje některý, u kterého má běžný uživatel právo pro vystavení, slouží k podepisování kódů a je povolen příznak „ENROLLEE_SUPPLIES_SUBJECT“ – můžeme certifikátu nastavit libovolný tzv. subject (v našem příkladě, abychom replikovali podepsanou binárku DomainApp.exe, stačí zadat „CN=Domain.Local“).

Pokud máme stroj připojený k doméně, lze rovnou certifikát přímo vyžádat pomocí modulu snap-in v MMC, nebo za pomocí nativních nástrojů certreq a certutil. Případně, dostupné šablony z certifikační autority lze enumerovat a následně vystavit pomocí volně dostupného nástroje Certify, šablona pak vypadá např. následovně:

CA Name                               : sub_ca.domain.local\sub_ca
Template Name                         : CodeSigning
Schema Version                        : 4
Validity Period                       : 1 year
Renewal Period                        : 6 weeks
msPKI-Certificate-Name-Flag          : ENROLLEE_SUPPLIES_SUBJECT
mspki-enrollment-flag                 : NONE
Authorized Signatures Required        : 0
pkiextendedkeyusage                   : Code Signing
mspki-certificate-application-policy  : Code Signing
Permissions
  Enrollment Permissions
    Enrollment Rights           : DOMAIN\Domain Users 			  S-1-5-21-762797448-840734356-2058421928-513
                                  DOMAIN\Domain Admins            S-1-5-21-762797448-840734356-2058421928-512

Příkaz pro vystavění příslušného certifikátu:

Certify.exe request /ca:sub_ca.domain.local\sub_ca /template:CodeSigning /altname:Domain.Local

Získaný certifikát je následně potřeba převést do PFX formátu, nástroj Certify rovnou potřebný příkaz ve výstupu zobrazuje:

openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx

Výsledný PFX certifikát je možné následně použít k podepsání binárních souborů. K tomu lze využít program signtool (který je součástí sady Windows SDK) a nejlépe jej spustit z Visual Studio Developer příkazového řádku:

signtool sign /f cert.pfx /fd SHA256 C:\Temp\HelloWorld.exe

Podepsanou aplikace HelloWorld.exe bude následně možné spustit.

V článku jsme si představili ochranu Windows Defender Application Control a příklady zásad, které definuje. Uvedli jsme také nejčastější chyby v konfiguraci politik a jak je zneužít ke spuštění libovolných binárních souborů.