Malware s digitálním podpisem už není žádná novinka, i když naštěstí pořád rarita – viděli jsme to u ukradených certifikátů (Stuxnet) a certifikátů se slabými faktorizovatelnými klíči. A teď ještě přibyl případ, kde se malware tvářil, jako by byl podepsán přímo od Microsoftu.

Všechny detaily ještě nejsou známé, občas se mlží, ale základní princip je už z některých zveřejněných řetězců certifikátů celkem jasný – Microsoft udělal „sub-CA“ ze všech zákazníků jednoho produktu (enterprise verze Terminal Services), takže mohli podepisovat jakýkoli kód libovolným jménem. Certifikáty Microsoftu umožňující tento podpis jsou již revokovány, původní security advisory je v následujících článcích:

• Microsoft Security Advisory (2718704)
• Unauthorized digital certificates could allow spoofing
• Microsoft certification authority signing certificates added to the Untrusted Certificate Store

CrySys zveřejnil ukázku řetězce certifikátů, na které lze vidět jak celý „trik“ funguje:

1. sub-CA „Microsoft Enforced Licensing Registration Authority CA“ se řetězí přes „Microsoft Enforced Licensing Intermediate PCA“, která je podřízená sub-CA pod „Microsoft Root Authority“ CA
2. „Microsoft Root Authority“ je kořenová autorita, jejíž certifikát je přítomen v systémovém úložišti certifikátů Windows
3. podle OID v X509v3 rozšíření Extended Key Usage je použití certifikátů pro: Code Signing, Key Pack Licenses (szOID_LICENSES), License Server Verification (szOID_LICENSE_SERVER)
4. certifikáty neobsahují žádné omezení týkající se jmen (rozšíření Name Constraints není přítomné)
5. tudíž jakýkoli podpis kódu ověřený přes tento řetězec se ukáže jako správný

V ukázce od CrySys je certifikát na čtvrté úrovni (Level 4) zřejmě certifikátem sub-CA, který zákazníci mohli použít pro podpis koncového certifikátu kódu. Znamená to, že k němu měli privátní klíč nebo fungovali jako registrační autorita (RA) – tj. nadřazená CA jim poskytovala „orákulum“, které podepsalo cokoliv (z popisu to není úplně jasné, variantě o RA by odpovídala i zkratka LSRA).

Hlavním problémem zde není ani použití PKI per se, ale spíše drobný „detail“, díky němuž se celý řetězec certifikátů řetězil ke kořenovému certifikátu v systémovém úložišti (je označen jako důvěryhodný). Jedna spekulace říká, že si vývojáři nebo architekt chtěli ulehčit život a místo separátní CA použili právě tu existující (ta ale měla vedlejší efekty).

V KB Microsoftu byly ještě zmatené zmínky o MD5 kolizích, ale žádné páry kolizních certifikátů nebyly k dispozici. Až nedávno se na MSDN objevil článek Flame malware collision attack explained, který sice ty kolizní certifikáty taky nemá, ale z analýzy certifikátu je vidět, že certifikát je „podivně“ pozměněn – chybí některé X.509v3 extensions. Při zkoumání se v certifikátu objevilo podivné pole Issuer Unique Identification (v praxi se téměř nepoužívá). To vzniklo právě kolizí a právě bity kolize způsobily, že se tělo pole natáhlo přes zbytek struktury ASN.1 – tudíž se „nepříjemná“ Hydra extension (OID 1.3.6.1.4.1.311.18, označená navíc jako „critical“) stala tělem nějakého řetězce – ten se neparsuje jako extension, tudíž už nepředstavuje problém.

Využití MD5 kolize je založeno na stejném triku, jaký jsem kdysi použil pro demonstraci já nebo mnoho jiných – „binární bordel“ je potřeba nastrkat do nějaké „vaty“ v datové struktuře (tak, že se neovlivní zásadně sémantika změněných dat). Je ale potřeba trochu experimentovat, než člověk trefí správné bity a správné délky. Ty kolizní certifikáty zřejmě podepisovalo „podepisovací orákulum“ někde u Microsoftu; toto orákulum ale nechtělo podepsat libovolný certifikát. Tak si útočníci pomohli s kolizí, při níž jim navíc hrál do karet fakt, že sériové čísla certifikátů a pár dalších polí byly lehce predikovatelné. Musím říct, že je to dost chytrý a elegantní útok. Nečekal jsem, že bych ho po tolika letech viděl „v divočině“.

Stevens a de Weger (autoři proof-of-concept certifikátů s MD5 kolizemi) tvrdí, že MD5 chosen-prefix-collision útok ve Flame je nový oproti jejich útoku. Nicméně myšlenka zůstává stejná – mít možnost zostrojit kolizi pro libovolné IV (odtud chosen-prefix – útočník si může vybrat libovolný kus dat délky násobku bloku před kolizí). Tím pádem novost spočívá pravděpodobně v rychlosti vytvoření kolize nebo menší počet CSR požadavků, než se útočník strefil do očekávaného sériového čísla a času, aby získal pár kolizních certifikátů.

Na závěr trocha odlehčení – CrySys poslal výzvu autorům Duqu, ať zveřejní kód, protože podléhá GPL.

Ondrej Mikle