Nedávno se ve full-disclosure mailing-listu objevila zpráva o heap-overflow zranitelnosti v parsování ASN.1 v OpenSSL. Zranitelnost je složena ze dvou částí:
- Při konverzi long -> int na x86_64 architektuře dochází k ořezání nejvyšších 32 bitů, výsledek se uloží do 32-bit integeru se znaménkem. Použitím DER-enkódovaného certifikátu, který má nějaký length-field s bitem 32 nastaveným, dojde k přetečení do záporných čísel.
- Funkce realloc() podle C99. standardu musí umět jak paměť alokovaného bloku zvětšit, tak zmenšit. Problém spočívá v tom, že obdobná funkce CRYPTO_realloc_clean() v OpenSSL nepodporuje zmenšení bloku. Pokud je nová délka alokovaného bloku menší než původní délka, část paměti za alokovaným bufferem se přepíše bajty navíc z původního bloku.
Kombinací obou chyb lze část paměti přepsat „speciálně formovaným“ certifikátem. Chybu je poměrně těžké zneužít, ale rozhodně to není nemožné. Týká se funkcí pojmenovaných d2i_*_bio a d2i_*_fp (a pár dalších pracujících s CMS a S/MIME).
Zatím probíhá šetření, který software používající OpenSSL je chybou ovlivněn. V tuto chvíli jsou chyby s největší pravděpodobností vyloučeny u:
- OpenSSH – používá vlastní kód pro parsování ASN.1
- Tor – používá in-memory d2i_* a PEM_* funkce, žádné z napadnutelných
- DNSSEC Validator – ASN.1 parsování se vůbec nepoužívá
- dslib – openssl se vůbec nepoužívá, ASN.1 parsování dělá pyasn1
- datovka – potenciálně zranitelná funkce OpenSSL.crypto.load_pkcs12 se nachází jen u načtení vašeho certifikátu z disku (tudíž dokud ho někdo nezmění, nic se nestane; navíc používá se jenom při přihlašovaní certifikátem)
- Knot DNS 1.0.3 – žádná zranitelná funkce se nevolá
- Firefox 11, Thunderbird 11.0.1 (komponenty NSS, NSPR a XulRunner) – Firefox i Thunderbird mají ale spoustu závislostí; je teoreticky možné, že jsem něco přehlédnul
- Apache 2.4.2, nginx 1.0.15 a 1.1.19, lighttpd 1.4.30 – používají některé ze zranitelných funkcí, ale jenom při čtení certifikátů z disku
Další pár očí pro kontrolu samozřejmě neuškodí. Statickou analýzou kódu jsem vytvořil call-graph a regexp, kterým lze ověřit, jestli nějaký kód volající funkce openssl používá potenciálně zranitelné funkce. Bugy jsou opraveny ve verzích openssl 1.0.1a, 1.0.0i or 0.9.8v. Jeden způsob, jak zmírnit dopad chyby v openssl (i budoucí), je použití stunnel v jail-u, ale má to některé další nevýhody jako těžší zpracování logů.
Další zajímavý fakt je, že tato konkrétní chyba (bez části o realloc()) byla publikována v roce 2006 v knize The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities. Zde je fotografie stránek se zmíněnou chybou (konverze long -> int). Nicméně to není první ani poslední „znovuobjevený“ bug v softwaru.
Ondrej Mikle
Slabý generátor náhodných čísel umožňuje faktorizovať RSA moduly
Akoby nestačilo napadnutie certifikačných autorít v roku 2011 a nedávne priznanie Trustwave, že vydávala certifikáty na korporátne man-in-the-middle útoky, našla sa ďalšia trhlina spôsobená nesprávnou implementáciou generátora náhodných čísel (kauza s debianími slabými kľúčami bola podobne spôsobená chybou v náhodnom generátore).
Tým výskumníkov vedený A. Lenstrom z EPFL našiel v databáze certifikátov z SSL Observatory a iných zdrojoch ďalšie páry kľúčov, ktoré zdieľajú v RSA module prvočíslo. To znamená, že použitím obyčajného vyše 2000 rokov starého Euklidovho algoritmu je možné niektoré RSA moduly faktorizovať. Z ich výsledkov vyplýva, že zhruba 2 z 1000 kľúčov idú týmto spôsobom faktorizovať. Testovali celkovo 11.7 milióna RSA, ElGamal, DSA a ECDSA kľúčov, z toho šlo uvedenou metódou prelomiť cca 27000 RSA kľúčov.
DSA a ElGamal kľúče nevykazovali žiadne podobné štatistické anomálie, ECDSA kľúč bol len jeden. Z uvedeného sa dá usudzovať, že PGP a GnuPG slabým generátorom netrpia (pretože väčšina testovaných ne-RSA kľúčov bola vygenerovaná jedným z týchto softwarov). Zatiaľ sa nevie, ktoré implementácie vygenerovali zmienené slabé RSA kľúče.
V diskrétnom grafe použitom na modelovanie zdieľaných prvočísiel a modulov je prvočíslo reprezentované vrcholom, hrana spája dve prvočísla patriace k modulu (moduly s viacerými prvočíslami neboli nájdené). V ideálnom prípade by vrcholov malo byť dvakrát toľko čo hrán, tj. žiadny pár RSA modulov nezdieľa prvočíslo. V Lenstrových výsledkoch sa ale nachádza 1995 nesúvislých komponent s tromi a viac vrcholmi.
Preložené do „nematematičtiny“: existuje 1995 skupín po niekoľkých RSA kľúčoch, kde keď poznáte prvočísla aspoň jedného z vrcholov, môžete faktorizovať ostatné. Rovnako znalosť dvoch modulov z rovnakej skupiny umožňuje použiť Euklidov algoritmus na zistenie jedného z prvočísiel a teda faktorizovanie oboch modulov.
Lenstra tiež zmieňuje dlhšie známy fakt o zdieľaní RSA modulov v X.509 SSL/TLS certifikátoch. Podľa jeho údajov 4 % kľúčov sú zdieľané, často medzi nesúvisejúcimi organizáciami alebo jedincami. Časť „s nesúvisejúcimi organizáciami“ ale treba brať trocha s rezervou.
O zdieľaní kľúčov v certifikátoch som mal pár debát s rôznymi výskumníkmi, napríklad s Ralphom Holzom, ktorého práca SSL Landscape je spomínaná v Lenstrovom príspevku. Obaja sme našli rôzne kľúče zdieľané medzi zdanlivo nesúvisejúcimi stranami, ale keď sa človek do toho začal vŕtať viac, tak zistil, že nejak prepojené sú (ale to treba robiť ručne prehliadaním obchodných registrov, atp.). Napriek tomu existujú kľúče ktoré sú zdieľané medzi organizáciami bez toho, aby to bolo úmyselné (napríklad niekto nezmení na VPS hostingu SSH/SSL kľúče, ktoré sa nakopírujú z inštalačného obrazu).
Podľa iného článku sa problém týka hlavne embedded zariadení, ktoré majú pri generovaní kľúčov malý zdroj entropie, takže netreba až tak moc panikáriť. Linkovaný článok obsahuje veľa technických podrobností, hlavná pointa je, že najskôr sa to netýka internetového bankovníctva a iných vysoko citlivých aplikácií.
Záujemcov o podrobnosti odkážem na pôvodný príspevok od Lenstra, et al publikovaný na eCrypt archíve (pdf).
Ondrej Mikle
Statistika DNSSEC resolverů
Jako správce české domény máme poměrně dobrý přehled o tom, kolik existuje zabezpečených domén s koncovkou .CZ. Jak to ale vypadá na druhé straně?
Samotné měření toho, kolik je validujících resolverů, není bohužel jednoduchá záležitost. Žádný resolver nehlásí autoritativnímu serveru „já jsem validující“, takže pro detekci lze použít nepřímé techniky, které využívají znalost toho, jakým způsobem validující resolver žádá o DNS záznamy. Asi nejkomplexnější metodu měření navrhl Olafur Gudmundsson a Steve Crocker na konferenci SATIN 2011; popsanou ji najdete v článku Guðmundsson, Crocker: Observing DNSSEC validation in the wild. Tuto metodiku jsme použili pro naše měření. Kromě toho, že nemá smysl znovu vynalézat kolo, je jednotná metodika také důležitá pro srovnání s ostatními registry. V případě, že by každý registr vynalézal znovu a znovu metodiku měření validujících resolverů, bylo by následné porovnávání výsledků příslovečným porovnáváním jablek s hruškami.
Stručné shrnutí metodiky:
Pro zjednodušení bereme jednu IP adresu za jeden resolver, i když ve skutečnosti se za jednou IP adresou může v případě NATu skrývat více resolverů.
Pro detekci validujících resolverů se metodika snaží hledat odlišnosti mezi chováním „zastaralých“, tedy nevalidujících resolverů, a těch validujících. Ty se liší především dotazy na DS a DNSKEY záznamy:
- dotaz na DS záznam – resolver označíme jako určitě validující
- opakovaný dotaz na DNSKEY záznam v časových intervalech odpovídající době platnosti (TTL) tohoto záznamu – resolver také označíme jako určitě validující
- samostatný dotaz na DNSKEY záznam – resolver označíme jako pravděpodobně validující
Z charakteru protokolu DNS vyplývá, že není možné, aby byla tato metodika absolutně spolehlivá. K jistému zjednodušení dochází proto, protože na straně autoritativního serveru není možné poznat, zda-li položený dotaz na DS nebo DNSKEY záznam vznikl na základě požadavku na validaci nebo jej vznesl nějaký testovací nebo monitorovací skript. Ke zkreslení výsledků přispívají i lidé, kteří prostými dotazy pomocí různých DNS nástrojů mohou způsobit zařazení IP adresy do jedné z výše uvedených kategorií. Podrobnější diskuzi nad použitou metodikou lze nalézt ve výše zmíněném článku.
Nejprve uvedeme výsledky měření z dubna 2011 a pak pro porovnání z prosince 2011. Měření se provádělo vždy tři pracovní dny na stejných autoritativních serverech.
Data z dubna 2011
Dle popsané metodiky jsme v našich DNS datech našli 6767 určitě a 727 pravděpodobně validujících resolverů. Vzhledem k tomu, že většina provozovatelů DNS serverů nemá ve svých sítích pouze jeden server, tak jsme získané IP adresy následně museli ručně agregovat na základě vlastníka IP adresy serveru. Toto seskupení představuje další zjednodušení, které ovšem v případě resolverů s největším provozem můžeme zanedbat.
V následující tabulce naleznete top 10 českých společností jejichž sítě provozují validující resolvery (podle počtu DNSKEY dotazů zaslaných z validujících resolverů).
#DNSKEY ISP 5320 Casablanca 4224 České Radiokomunikace 3024 Telefónica O2 2089 GTS NOVERA 1624 UPL Telecom 1338 NFX 710 OMEGA tech 537 Dial Telecom 513 Ignum 441 VUT Brno
Data z prosince 2011
Počet validujících resolverů se zvýšil: evidujeme 11403 určitě a 1201 pravděpodobně validujících resolverů.
Pořadí top 10 českých společností počtu DNSKEY dotazů z validujících resolverů se mírně promíchalo:
#DNSKEY ISP 7894 Telefónica O2 6309 Vodafone 4342 ACTIVE 24 3441 UPC 3285 GTS NOVERA 3075 RIOMEDIA 2712 2 connect 2029 T-Mobile 1946 Casablanca 1737 CESNET
Pokud by vás zajímalo, zda váš ISP validuje, podívejte se na www.dnssec.cz, kde najdete jednoduchý a průkazný test. V komentářích nám potom můžete napsat, jak jste uspěli či neuspěli, kdo má nebo nemá zájem na větším bezpečí svých zákazníků.
Ondřej Mikle
Bitsquatting
Najskôr sa už každému podarilo spraviť preklep v názve domény pri ručnom písaní do browseru a dostať sa na doménu zaregistrovanú „typosquatterom“, aby využil preklep k nejakému zisku (typicky reklamy). Artem Dinaburg prezentoval na konferencii Defcon 19 zaujímavú variantu nazvanú bitsquatting.
Bitsquatting je založený na predpoklade, že v počítačoch pripojených k internetu dochádza občas vplyvom tepla, elektromagnetického žiarenia apod. k chybe, ktorá prehodí v pamäti niektorý bit. Takáto bitová chyba nastáva veľmi zriedkavo, preto na „zmysluplné“ využitie sa musí jednať o mimoriadne často dotazovanú doménu.
Dinaburg si zaregistroval niekoľko variant populárnych domén s jedným prehodeným bitom, ktorý je na klávesnici ďaleko od originálneho znaku (napr. mic2osoft.com s prehodeným 7. bitom v znaku ‚r‘, aby sa to jednoduchšie odlíšilo od typosquattingu) a sledoval 7 mesiacov príchodzie dotazy. Za toto obdobie prišlo 52 317 dotazov z 12 949 unikátnych IP adries, čo je dosť malý počet oproti chybám z preklepov. Relatívne nízky počet je očakávateľný kvôli nízkej pravdepodobnosti výskytu bitovej chyby. Nasledujúci graf ilustruje rozloženie počtu spojení od unikátnych IP počas meraného obdobia:
Okrem troch anomálií (označených v grafe A, B, C) je počet IP za deň celkom rovnomerný. Prvé dva extrémy (A, B) podľa autora vznikli chybou cache priamo v infraštruktúre spoločnosti Zynga (tvorca hry Farmville), za posledný (označený C) je zodpovedná proxy alebo DNS resolver spoločný pre menšiu sieť.
Koncept vzbudil miernu nedôveru, pretože je celkom ťažké dokázať, že sa jedná o bitovú chybu a nie o zvláštny preklep alebo aktivitu skriptu, ktorý enumeruje domény. Asi najlepší argument podporujúci Dinaburgove tvrdenie sú rozdiely medzi dotazovanou doménou a HTTP Host hlavičkou: 3 % HTTP spojení na bitsquat domény obsahujú Host hlavičku odpovedajúcu pôvodnej („nebitsquatovej“) doméne, čomu pri typosquattingu nedochádza. Naviac v jeho príkladoch obsahujú bežne HTTP spojenia aj Referer.
Niektoré komentáre namietali, že pri podobných „náhodných“ chybách by neboli schopné počítače pracovať. V skutočnosti si človek takú chybu skôr vôbec nevšimne. Zhodou okolností som asi pred 15 rokmi robil experiment, ako sa PC vysporiada s chybami v RAM. Na starších PC bolo možné preprogramovať cez časovač frekvenciu obnovy pamäte (DRAM refresh). DRAM refresh zaručuje, že pamäť „nevybledne“ (nestratí sa z kondenzátorov náboj). Po znížení frekvencie refreshu trvalo rádovo minúty, než boli chyby človekom viditeľné (refresh je rádovo mikrosekundy až milisekundy). Prvé viditeľné chyby boli zmeny zobrazovaných znakov, logické chyby v aplikáciách a nakoniec pád systému. Podobne Dinaburg zachytil prípady havarujúcich Windows strojov, ktoré odosielali chybové hlásenia na bitsquat domény.
Ďalšie informácie k bitsquattingu sa dajú nájsť v Dinaburgovej prezentácii a článku.
Ondřej Mikle, Laboratoře CZ.NIC