Gisteren heb ik een voorstel naar Microsoft gemailed om een soort Authenticode "kill bit" te realiseren.

Aanleiding
Dit n.a.v. berichtgeving afgelopen week o.a. in [1], verwijzend naar [2], dat cybercriminelen drivers toevoegen aan hun malwarepakket waarmee die malware hogere privileges kan krijgen (bijvoorbeeld om antivirus en andere beveiligingsmaatregelen uit te schakelen op kernel-niveau).

[1] https://www.security.nl/posting/642860/Ransomware+schakelt+antivirussoftware+uit+via+Gigabyte-driver
[2] https://news.sophos.com/en-us/2020/02/06/living-off-another-land-ransomware-borrows-vulnerable-driver-to-remove-security-software/

De fabrikant zou in zo'n geval aan de certificaatverstrekker (van het code-signing certificaat) kunnen vragen om dat certificaat in te trekken (revoken). Een potentieel groot probleem daarbij is dat er ook niet-kwetsbare bestanden met dat certificaat gesigneerd kunnen zijn, wat tot problemen voor veel meer gebruikers kan leiden. Om die reden zijn fabrikanten er vermoedelijk niet erg happig op om hun code-signing certificaten in te trekken.

Meer info over Authenticode
In dit kader is het belangrijk om te weten dat Authenticode-signatures geldig blijven na het verlopen van het gebruikte code-signing certificaat. Essentieel hierbij is een tweede signature waarin een time-stamp is opgenomen: het code-signing certificaat moet geldig zijn op het moment dat de time-stamp gezet wordt. Een fabrikant die dit mechanisme niet goed begrijpt zou kunnen denken dat het helemaal niet nodig is om een verlopen Authenticode-signing certificaat in te trekken - wel dus. Kortom, dit probleem lost zich niet vanzelf op doordat een certificaat op een gegeven ogenblik verloopt.

Voorstel
Microsoft zou, vergelijkbaar met het ActiveX kill bit van destijds, in het register een blacklist kunnen opnemen van bestanden die als onveilige moeten worden beschouwd, op basis van en/of:
1) De cryptografische hash gebruikt voor de Authenticode handtekening;
2) Een periode (ofwel "van-tot", "-tot" of "vanaf-") waarin een code-signing certificaat (feitelijk de bijpassende private key) is gebruikt voor het ondertekenen van een of meer kwetsbare bestanden.

Voordelen
Als één versie of enkele versies van een bestand (zoals een driver) kwetsbaar is/zijn, hoeft niet het code-signing certificaat te worden ingetrokken. Bovendien kunnen individuele gebruikers, die zich zorgen maken over dit soort kwetsbaarheden, zelf maatregelen nemen om de uitvoering van specifieke bestanden te blokkeren, ook indien dit soort "revocations" niet naar naar elke Windows PC worden gedistribueerd bijv. via Windows Update (het kan immers ook gaan om niet-publieke, d.w.z. voor gebruik binnen een organisatie, ondertekende bestanden waarbij het onwenselijk is om het gebruikte code-signing certificaat te blacklisten door een kopie ervan in de "untrusted certificates" store op te nemen).

Nadelen
Een nadeel is natuurlijk weer een extra stukje complexiteit. Ook zul je je moeten realiseren dat systemen die geen directie internet-connectiviteit hebben, je niet alleen revoked certificates moet instaleren, maar ook dit soort blacklist-gegevens (indien je risico's zodanig laag wilt houden dat je dit nodig acht voor dergelijke systemen).

Risico file-hash i.p.v. signature-hash gebruiken
In mijn mail heb ik Microsoft ervoor gewaarschuwd om zich, m.b.t. punt 1, niet te baseren op een cryptografische hash van het gehele bestand. De reden daarvoor is dat je, nog steeds, een bestand kunt wijzigen zonder dat de Authenticode handtekening ongeldig wordt [3]. Dat is iets minder erg dan het lijkt omdat je niet straffeloos wijzigingen in de uitvoerbare code van een bestaande executable file kunt maken, maar je (een kwaadwillende en/of een geheime dienst) kan zo wel een geprefabriceerde executable maken waarin een deel later vervangen wordt dat wel wordt uitgevoerd (zie [4] - Nb. de executables onderaan die pagina zijn met een self-signed certificaat ondertekend en leiden tot een reeks false positives op VirusTotal).

[3] https://docs.microsoft.com/en-us/archive/blogs/ieinternals/caveats-for-authenticode-code-signing
[4] https://blog.reversinglabs.com/blog/breaking-the-windows-authenticode-security-model

EnableCertPaddingCheck
Microsoft is ooit van plan geweest om deze halfslachtige Authenticode signatures definitief als ongeldig te verklaren, maar er bleken te veel legitieme toepassingen te bestaan die hier gebruik van maken (o.a. preconfigured Sophos VPN clients). In elk geval in Windows 10 v1903 werkt het toevoegen van de REG_SZ registerwaarde "EnableCertPaddingCheck" = "1" nog steeds (in 64-bit Windows zowel onder WOW6432Node als het reguliere pad, zie [5], en als de subkeys "Wintrust\Config\" nog niet bestaan zul je ze moeten aanmaken). Na een reboot zullen bestanden met "toevoegingen" buiten het Authenticode signature gebied dan geen digitale handtekening meer lijken te hebben: als je de "Eigenschappen" van zo'n bestand opent, ontbreekt het tabblad met "Digitale handtekeningen" (m.i. verwarrend, ik had liever een foutmelding gezien die me vertelt dat de handtekening niet klopt).

[5] https://docs.microsoft.com/en-us/security-updates/securityadvisories/2014/2915720

Overigens kun je niet simpelweg een aantal bytes achter een bestand plakken: ook zonder EnableCertPaddingCheck aangezet in het register zal een digitale handtekening van een legitiem bestand "verdwijnen" als je er een of meer willekeurige bytes achter plakt (bijv. met copy /b "signed.exe" + "whatever.txt" "signed_met_whatever.txt_erachter.exe"); zie het bovenste plaatje in [3] voor gebieden die, om al dan niet legitieme redenen, gewijzigd kunnen worden zonder de Authenticode handtekening ongeldig te maken.

Ik hou jullie op de hoogte.