Adobe neuhlídala svou síť a její podpis se dostal na cizí kód
Společnost Adobe nedávno potkal nepříjemný bezpečnostní incident: zjistila, že někdo si nechal „jejím jménem“ a na její vlastní infrastruktuře podepsat kus svého kódu. Pochopitelně bez jejího vědomí a souhlasu. Musela proto revokovat certifikát, který dříve běžně používala při podepisování svých produktů. Co to znamená pro jejich uživatele?
Podle dostupných informací se celý incident měl odehrát 25. a 26. července 2012. Společnost Adobe se o tom dozvěděla 12. září, kdy se jí dostal do rukou první vzorek podvodně podepsaného kódu. Ihned to začala šetřit a 27. září vydala bezpečnostní bulletin i příspěvek na firemním blogu. V něm o celé věci informovala veřejnost a současně oznámila záměr revokovat v dalších dnech (konkrétně 4. října) ten certifikát pro podepisování kódu, na kterém jsou podvodné podpisy založeny (který jí vystavila autorita Verisign).
Jak je vidět i z následujícího obrázku (s příslušným seznam CRL), k revokaci došlo zpětně, k datu 10. července 2012.
Než se dostaneme k tomu, jaké dopady to má na koncové uživatele Adobe produktů, zastavme se nejprve u dostupných informací o tom, jak se incident měl odehrát.
Jak k tomu došlo?
Ředitel Adobe pro bezpečnost produktů, Brad Arkin, popsal celý incident v tomto příspěvku na firemním blogu. Podle něj se útočníkům podařilo napadnout jeden ze strojů ve firmě, skrze který se pomocí technik APT (Advanced Pesistent Threat) dostali až na jeden z tzv. build serverů, neboli serverů připravujících nová „sestavení“ (verze) konkrétního softwaru. No a tomuto build serveru dokázali podstrčit svůj vlastní kód a přimět jej k tomu, aby jej nechal podepsat od interní služby pro podepisování kódu. Tedy od dalšího firemního serveru, který již má k dispozici příslušný soukromý klíč, který byl k podpisu použit.
Adobe tvrdí, že rozhodně nedošlo ke kompromitaci jejího soukromého klíče, sloužícího k podepisování kódu. Přesněji jednoho z těch, které k podepisování kódu používá, protože jich má a používá více. A všechny by měly být „zadrátovány“ v modulech HSM (Hardware Security Module), ze kterých by vůbec nemělo být možné je jakkoli dostat ven. Ale jak vidno, zneužít se dají i jinak, vhodným „podstrčením“ cizího kódu k podepsání.
Proto Adobe nechala revokovat certifikát, spojený s inkriminovaným soukromým klíčem. Kromě toho okamžitě vyřadila z provozu svou interní službu pro podepisování kódu, přešla na prozatímní řešení, a nejspíše nasadila i další bezpečnostní opatření.
Směrem ke svým zákazníkům pak Adobe vzkazuje, že útočníci nenapáchali žádné další škody, a nezískali ani přístup ke zdrojovým kódům jejích produktů. Samotné produkty a služby Adobe tak nemají být jakkoli ohroženy či kompromitovány.
Prý se tedy nemáme čeho bát. Nicméně už jen samotná revokace podpisového certifikátu může mít určité důsledky pro koncové uživatele, které si záhy ukážeme. A hlavně: co další otázky? Třeba: jak je možné, že se něco takového vůbec stalo? Netrvalo hledání řešení, včetně revokace certifikátu, příliš dlouho? Proč k revokaci došlo tak „hluboko“ do minulosti, konkrétně k 10. červenci, když k prvnímu podvodnému podpisu mělo dojít až 25. července? Známe skutečně celý rozsah událostí? Nebyly podvodně podepsány ještě další „kusy kódu“, o kterých se zatím neví či jen mlčí?
Co bylo podepsáno?
Samotný kód, o kterém se ví, že byl podvodně podepsán, Adobe popisuje (ve svém v bulletinu i na blogu) jako dvě položky, z nichž jedna je fakticky tvořena dvěma soubory. Proto také některé zdroje hovoří o dvou „kusech“ podvodně podepsaného kódu, a jiné o třech.
Jedním „kusem“ je knihovna myGeeksmail.dll, podvodně podepsaná dne 25.7.2012. Podle názoru Adobe se jedná o ISAPI filtr, a tedy o kód, který se instaluje na webové servery a upravuje HTTP streamy. Ale co přesně dělá a v čem je škodlivý, není zatím nikde popisováno. Nejspíše i proto, že tento filtr prý dosud nebyl běžně dostupný.
Dalším „kusem“ kódu je utilita PwDump7.exe, podvodně podepsaná 26.7.2012 spolu s knihovnou libeay32.dll, kterou ke své činnosti obvykle využívá. No a onou činností není nic jiného než získávání otisků (hashů) hesel na platformě MS Windows. Na rozdíl od knihovny myGeeksmail.dll je tato utilita běžně dostupná na Internetu.
Zajímavé přitom je, že dostupné zdroje vůbec nemluví o tom, co má podvodně podepsaný kód „za lubem“. Zda jde o nějakou modifikovanou verzi utility PWdump, nebo zda jde o verzi zcela „standardní“, jejíž fungování je jinak vcelku známé. Obdobně pro knihovnu myGeeksmail.dll, jejíž standardní fungování ale známo není.
Proč došlo k útoku?
Příspěvek na blogu společnosti Adobe zmiňuje „vysoce cílené“ útoky, které mají využívat podvodné utility podobné těm, o kterých je zde řeč – a i z toho odvozuje své přesvědčení, že drtivá většina uživatelů je mimo jakékoli nebezpečí. Navíc prý Adobe včas poskytla vzorky podvodně podepsaného kódu do programu MAPP (Microsoft Active Protection Program), tak aby na ně výrobci bezpečnostních řešení mohli včas zareagovat.
Proč by ale někdo vůbec mohl mít zájem na tom, aby si nechal podepsat svůj podvodný kód od někoho jiného, dostatečně renomovaného a důvěryhodného?
Odpověď je jednoduchá: je to cesta, jak snáze projít skrze různé kontroly, usilující o odhalení malwaru. Ty se totiž mohou spokojit s tím, že mají platný podpis od důvěryhodného vydavatele, a dále už je nezkoumají a považují za „čisté“. Někde je podpis ovladačů dokonce podmínkou k tomu, aby vůbec mohly být instalovány.
Pravdou také je, že podepisování škodlivého kódu není žádnou novinku. Tvůrci nejrůznějšího malwaru se již delší dobu snaží o to, aby jejich výtvory měly platné podpisy dostatečně důvěryhodných subjektů – a také se jim to daří. Připomenout si můžeme i známý případ Stuxnetu, jehož kód byl také platně podepsán, podpisy firem Realtek a JMicron.
Nejspíše se jedná o určitý trend, do kterého zde popisovaný incident bohužel také zapadá. Doufejme jen, že podaří tomuto trendu včas kontrovat vhodnými a účinnými protiopatřeními, aby dále neeskaloval.
Co vše znamená pro koncové uživatele Adobe produktů?
Pojďme nyní již k tomu, jak se vše dotýká koncových uživatelů produktů Adobe. Jim společnost vzkazuje, že z hlediska bezpečnosti se nemají čeho obávat:
Je váš software od Adobe v důsledku tohoto problému vystaven riziku? Ne. Tato záležitost nemá vliv na bezpečnost vašeho autentického software společnosti Adobe. Hrozí vám nějaké jiné nebezpečí z hlediska bezpečnosti? Máme pádný důvod k přesvědčení, že tato záležitost nepředstavuje žádné obecné bezpečnostní riziko.
Pokud jde o důsledky revokace certifikátu, pak zde již Adobe zmiňuje tři konkrétní produkty:
Otázka: Ovlivní nějak odvolání certifikátu software Adobe na veškerých platformách?
Odpověď: Ne. Odvolání certifikátu se týká platformy Windows a tří aplikací Adobe AIR*, které se spouštějí v systému Windows i v počítačích Macintosh. Odvolání neovlivní žádný jiný software Adobe pro počítače Macintosh nebo jiné platformy.
* Aplikace Adobe Muse, Adobe Story AIR a služby pro stolní počítače dostupné na webu Acrobat.com
Jde o šikovnou formulaci, která by mohla svádět k interpretaci, že vše se týká jen oněch tří vyjmenovaných aplikací Adobe Air (Muse, Story a Acrobat Desktop Services). A tedy že dnes již revokovaný certifikát byl využíván pouze k podepisování kódu těchto tří aplikací, které (aniž bych je chtěl jakkoli podceňovat) přeci jen nejsou nejznámějšími produkty Adobe.
Ve skutečnosti je to zřejmě tak, že na revokovaném certifikátu byl založen podpis řady dalších aplikací pro platformu Windows, včetně tak „vlajkových“, jako je přehrávač Flash. Tabulka na této stránce, nadepsaná jako „Seznam produktů s aktualizacemi certifikátu“, je pravděpodobně jejich seznamem. A pouze tři výše vyjmenované aplikace (Muse, Story a Acrobat Desktop Services), jako aplikace Adobe Air, jsou multiplatformní a týkají se tedy i dalších platforem, než je MS Windows.
Dopady revokace
Ukažme si nyní již konkrétně, jaké dopady má revokace certifikátu pro podepisování kódu. Ukažme si to na příkladu přehrávače Flash na standardně nastavené platformě Windows 7. A připomeňme si, že k revokaci došlo 4.10.2012, ovšem zpětně, k datu 10.7.2012.
Stejně tak si řekněme, že Adobe k podpisu pod svým kódem přidává i časové razítko. To se právě teď projevuje jako velmi důležité, protože podpisy vytvořené před 10.7.2012 mohou stále být považovány za platné. Ukažme si to na příkladu Flashe 11.3.300.262 z 20.6.2012: vyhodnocení podpisu jeho kódu vidíte na následujícím obrázku. Podpis je platný („v pořádku“), protože časové razítko osvědčuje, že vznikl ještě před revokací certifikátu. Podle sériového čísla certifikátu si můžete sami ověřit, že jde skutečně o revokovaný certifikát (viz druhý dnešní obrázek, ukazující CRL seznam).
Pokud se posuneme v čase o měsíc, k verzi 11.3.300.268 přehrávače Flash, zjistíme že je stále podepsána stejným certifikátem – ale že podpis vznikl 21.7.2012, a tedy již po revokaci certfikátu.
Pokud si tento podpis necháme vyhodnotit, dopadne to tak, jak by mělo: je shledán neplatným, z důvodu revokace certifikátu. Byť terminologie zdaleka není ideální a uživatel si sám musí domyslet, že revokace certifikátu způsobuje neplatnost podpisu.
Teď ale: co se stane, pokud se na standardně nastavené platformě Windows 7 pokusíte spustit program opatřený neplatným podpisem svého kódu? Bude vám to znemožněno? Nebo budete muset projít přes varování, že podpis je neplatný? Nikoli, skutečnost vidíte na následujícím obrázku: Windows vás sice varují, ale pouze v tom smyslu, že vydavatel je neznámý.
O neplatném podpisu, či alespoň o revokovaném certifikátu, se nedozvíte ani při rozkliknutí podrobností, protože pak se vám navíc zobrazí jen umístění souboru se spouštěným programem.
Jinými slovy samotná revokace certifikátu běžnému uživateli moc nepomůže. Sama nezpůsobí to, že kód s neplatným podpisem nepůjde spustit. Vlastně dopadne úplně stejně, jako kód, který vůbec žádný podpis nemá. A uživatel, zvyklý moc nepřemýšlet a odkliknout úplně všechno, si nejspíše ničeho ani nevšimne.
Další možností je explicitně prohlásit příslušný certifikát za nedůvěryhodný, jeho umístěním do složky s neplatnými certifikáty v systémovém úložišti certifikátů MS Windows. Viz následující obrázek, kde je takto umístěn předmětný (revokovaný) certifikát.
Pak už budou Windows interpretovat neplatně podepsaný kód přísněji a neumožní jeho spuštění:
Problém je v tom, že tento krok (umístění revokovaného certifikátu mezi nedůvěryhodné) se obrátí i proti těm podpisům, které vznikly před revokací a mohou to prokázat svým časovým razítkem. Ani tyto programy pak nejdou běžně spustit, protože jejich podpis bude vyhodnocen jako neplatný (a čas podepsání vlastně nebude hrát roli).
Zřejmě právě proto Adobe tuto možnost nedoporučuje. Píše to její ředitel pro bezpečnost produktů, Brad Arkin, ve svém příspěvku na firemním blogu, kde současně konstatuje, že ani tento krok prý nemusí zabránit spuštění škodlivého kódu.
Jak se měnily podpisové certifikáty?
Na závěr si ještě ukažme, jak se v čase měnil způsob podepisování kódu společností Adobe. Z výše uvedeného příkladu s Flashem lze usuzovat, že původní (a dnes již revokovaný) certifikát byl používán ještě po 11. červenci, nejspíše až do 12. září, kdy Adobe dostává první vzorek podvodně podepsaného kódu. Následně odstavuje svou interní službu pro podepisování kódu a přechází na dočasné náhradní řešení, již s jiným certifikátem.
To je patrné na následujícím příkladu Flashe ze 17. září, kdy již byl použit jiný (a to starší) certifikát. Tomu v době podpisu zbývalo z jeho řádné platnosti pouhých 14 dnů. Takže se skutečně jednalo o jakési nouzové řešení, ještě než si společnost Adobe nechala vystavit novější certifikáty pro podepisování svého kódu a začala je skutečně používat.
K vystavení nových certifikátů došlo prakticky souběžně, jak dokládá i následující výpis od autority Verisign.
A tak třeba již 20. září podepisuje Adobe novou verzi (sestavení) svého Flashe novým certifikátem, vydaným o pouhý den dříve.
Spíše jen pro zajímavost si ukažme ještě jiný výpis certifikátů, které Verisign vystavil společnosti Adobe. Třetí shora je v tomto článku popisovaný certifikát, s řádnou platností od 15.12.2010 do 14.12.2012, revokovaný k 10.7.2012.
Na seznamu jsou ovšem další dvě položky, odpovídající certifikátům vydaným 13. a 18. září. A ty byly revokovány již v den svého vydání.
