Před dvěma lety jsem psal článek o schopnostech tehdy nového hardwarového tokenu Yubikey Neo. Yubico s vývojem nepřestalo a novinky na čerstvě doručeném Neo tokenu jsou příjemné.
Nenechavý router botnet
Není to tak dlouho, co jsme na základě sledování útočníků v našich telnetových honeypotech odhalili zajímavý botnet složený z domácích routerů značky ASUS. Poslední dva týdny se nám do SSH honeypotu provozovaného na routerech Turris zase nejvíce pokouší přihlašovat botnet, jehož IP adresy mají podle Shodanu často jednu společnou vlastnost: na portu 80 odpovídají s cookie AIROS_SESSIONID. Tato cookie ukazuje na AirOS bežící na Ubiquiti airRouter. Podle dat ze Shodanu lze touto cookie identifikovat asi 20 % útočících IP adres z celkových cca 6 500 jako AirOS. Mnoho adres ale bývá z dynamických poolů, o kterých Shodan ještě neví.
Kdo nám šťourá do Turrisího SSH honeypotu
Turrisí SSH honeypoty rozhodně nezahálí. Momentálně je aktivních 168 honeypotů, které denně zaznamenají mezi 1000 až 2000, někdy i 5000 SSH sessions obsahující alespoň jeden příkaz.
Cheatsheet k eliptickým křivkám
Občas se lidé ptají na nějaký tutorial k eliptickým křivkám. Pokud vím, tak žádný rozumný neexistuje. Nejspíš z toho důvodu, že na rozdíl od RSA, které je celkem jednoduše vysvětlitelné, jsou eliptické křivky jen „prachsprostá“ algebra. Naposledy se o tutorial pokusil D. Bernstein přednáškou na 31C3, ale ve výsledku to ještě víc zamotal. My zkusíme jiný přístup – „cheatsheet“ – popíšeme, na co je která křivka dobrá, které jsou ty „špatné“, ale „bez důkazů“.
Kleptografie – staronová metoda, jak se dostat k vašim datům, je na vzestupu
Byli bychom celkem rádi, kdyby se kryptografické krize omezily na jednu denně. Nicméně víme, že je to jen zbožné přání.
Neúmyslná exfiltrace klíčů
Čínský výrobce elektroniky Lenovo ve své chamtivosti šel až tak daleko, že nejen že předinstalovává zobrazovače reklamy na nově nainstalovaných noteboocích, ale nainstalovaný adware třetích stran nazvaný Superfish dokonce injektuje javacsript do kódu prohlížené stránky; cílem je analyzovat stránku a lépe cílit reklamu. Neomezuje se při tom jenom na nešifrované HTTP spojení.
Linuxový a další *NIX-ový malware
Před nějakou dobou jsme začali do SSH honeypotů přesměrovávat v testovacím provozu vnější SSH port z Turrisů některých dobrovolníků z vývojového týmu. Aby si s námi „povídalo“ co nejvíce útočníků, povolili jsme v honeypotu přihlášení na roota libovolným heslem; navzdory tomu většina botů stejně nic neudělá a hned se odpojí i po úspěšném pokusu.
Falšování RSA podpisů podle Bleichenbachera
V uplynulých dnech zastínily chyby bash interpreteru zvané Shellshock ostatní zprávy včetně chyby v NSS ovlivňující verifikaci certifikátů ve Firefoxu a Chrome. Jedná se o další instanci ne celkem běžné zranitelnosti, která se ale opakovaně vyskytuje: Bleichenbacherův útok na RSA s malým veřejným exponentem, typicky 3.
Stav SSL/TLS na českém Internetu u HTTPS
Rok 2014 příliš nepřeje SSL/TLS knihovnám, v nichž bylo objeveno několik závažných chyb. Nejznámější z nich jsou asi Heartbleed, goto fail a CCS útok. Zmíněné zranitelnosti byly objeveny manuálním auditem kódu nebo automatickým „dokazovačem“. Tyto chyby nejsou chybami SSL/TLS protokolu, nýbrž chybami implementací.
My jsme se již před časem zaměřili na scanování chyb konfigurací, které jsou lépe odhalitelné a odstranitelné.
Slabé RSA kľúče v TLS a DNSSEC
Praktických dôkazov, že RSA kľúče s modulum menším 1024 bitov (špeciálne 512-bitových) môžu predstavovať bezpečnostné riziko, sa za posledný rok objavilo viacero. Autori malware zneužili slabé 512-bitové RSA kľúče z certifikátov, ktoré mali vhodnú kombináciu X.509v3 extensions a podpisovali nimi malware. Útočníci v tomto prípade pravdepodobne faktorizovali modulus a získali tak privátny kľúč. Výskumníci tiež ukázali, že „okamžitá“ faktorizácia 512-bit RSA modulu je uskutočniteľná a relatívne lacná (menej než cca $150).
Aj keď to boli najskôr posledné X.509 certifikáty zneužiteľné na podpis kódu (ostatné známe sme našli a sú revokované), stále existuje mnoho serverov, ktoré posielajú 512-bitové certifikáty v TLS handshake, napríklad pri naväzovaní HTTPS komunikácie. Doporučené veľkosti kľúčov k rôznym algoritmom uvádza prehľadná tabuľka vychádzajúca z doporučení ECRYPT II (podrobný popis ako sa k hodnotám dostali obsahuje objemný ECRYPT II Yearly Report on Algorithms and Keysizes 2011).
Našťastie od júla 2012 platia nové požiadavky CAB fóra na certifikáty vydávané od CA – už nesmú mať RSA moduly menšie než 1024 bitov, naviac tie s dlhodobou platnosťou musia mať modulus veľkosti aspoň 2048 bitov. Microsoft tiež čoskoro začne blokovať certifikáty s RSA modulom menším než 1024 bitov. Zmeny k lepšiemu je už vidieť ako postupne CA revokujú staršie certifikáty so slabými RSA modulmi, ale stále sa občas nejaký 512-bit nájde.
Podobný problém so slabými RSA sa samozrejme netýka len TLS komunikácie, ale môže nastať tiež v DNSSEC. Ak útočník kľúč faktorizuje, môže pri man-in-the-middle útoku na DNSSEC falšovať podpisy DNS záznamov (tým pádom aj prípadne meniť asociácie na kľúče a certifikáty pinované cez záznamy typu SSHFP alebo TLSA).
Ako to vyzerá s RSA kľúčmi v doméne CZ? Keď sme robili prieskum DNSSEC kľúčov používaných v doméne .CZ pred pol rokom, tak domén s DNSSEC kľúčom s RSA modulom menším než 1024 bitov bolo mnoho (rádovo stotisíc), pri teste 20. júla 2012 už je ich zásadne menej:
- domén s kľúčom menším ako 1023 bitov: 6635
- unikátnych kľúčov so slabým modulom: 5209
- v dvoch prípadoch sa jedná o Key Signing Key, zbytok sú Zone Signing Keys; jeden z týchto KSK už nie je používaný (ale je v zóne)
- päť kľúčov má 768-bit modulus, zbytok 512-bit
- jedna doména má kľúč so slabým verejným exponentom (3)
- existuje jeden revokovaný DNSKEY RSA kľúč s malým modulom
Pre porovnanie veľkosti kľúča a periódy zmeny ZSK odkážem na blog Erica Rescorlu, kde ukazuje, že priame použitie silnejšieho kľúča prináša lepšiu bezpečnosť než častá zmena (key rollover).
Súčasné doporučenia pre KSK a ZSK RSA kľúče znejú:
- KSK 2048 bitov
- ZSK 1024 bitov
- verejný exponent 65537 (0x10001 hex)
Uvedené hodnoty sú minimálne. Tu zase platí, že ani s veľkosťou kľúčov to netreba preháňat – príliš veľké moduly alebo exponenty majú za následok spomalenie overovania RSA podpisu.
Poznámka na koniec: Teoreticky verejný exponent môže byť aj menší (napr. 3), vyšší exponent ale bráni proti implementačným chybám umožňujúcim varianty Bleichenbacherovho útoku (u schém používajícich PKCS#1 v1.5 RSA padding, stalo sa nedávno u openssl – netýkalo sa SSL/TLS, ale CMS).
Ondrej Mikle
Malware podepsán „od Microsoftu“
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:
- 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
- „Microsoft Root Authority“ je kořenová autorita, jejíž certifikát je přítomen v systémovém úložišti certifikátů Windows
- 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)
- certifikáty neobsahují žádné omezení týkající se jmen (rozšíření Name Constraints není přítomné)
- 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