Pamatujete si na Heartbleed? Pokud věříte dnešnímu humbuku, Shellshock je stejná liga a má stejně úžasný název, i když postrádá cool logo (někdo v marketingovém oddělení těchto vulgárních chyb se tím musí zabývat). Ale ve vší vážnosti, má to potenciál být velký problém a stejně jako v případě Heartbleedu jsem chtěl dát dohromady něco definitivního jak pro sebe, abych se v situaci zorientoval, tak pro ostatní, aby mohli rozklíčovat humbuk od skutečného základního rizika.
Abych uvedl situaci na pravou míru, dovolte mi podělit se o obsah příspěvku z blogu Roberta Grahama, který na toto téma provádí vynikající analýzy. Představte si požadavek HTTP, jako je tento:
target = 0.0.0.0/0port = 80banners = truehttp-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)http-header = Cookie:() { :; }; ping -c 3 209.126.230.74http-header = Host:() { :; }; ping -c 3 209.126.230.74http-header = Referer:() { :; }; ping -c 3 209.126.230.74
Který, když je vydán proti řadě zranitelných IP adres, vede k tomuto:
Krátce řečeno, Robert právě naordinoval skupině externích strojů, aby na něj pingovaly pouhým vydáním pečlivě vytvořeného požadavku přes web. Co je opravdu znepokojující, je to, že účinně přiměl tyto stroje, aby vydaly libovolný příkaz (i když poměrně neškodný ping), a to otevírá celý svět velmi vážných možností. Dovolte mi to vysvětlit.
Co je to Bash a proč ho potřebujeme?
Přeskočte to, pokud je to stará zpráva, ale kontext je důležitý pro ty, kteří Bash neznají, takže si vytvořme základní představu. Bash je *nixový shell nebo jinými slovy interpret, který umožňuje organizovat příkazy v systémech Unix a Linux, typicky připojením přes SSH nebo Telnet. Může také fungovat jako analyzátor skriptů CGI na webovém serveru, například typicky na serveru Apache. Existuje od konce 80. let, kdy se vyvinul z dřívějších implementací shellu (název je odvozen od Bourneova shellu), a je nesmírně populární. Pro unixové varianty existují i jiné shelly, ale Bash je výchozím shellem pro Linux a Mac OS X, což jsou samozřejmě extrémně rozšířené operační systémy. To je hlavní faktor, proč je toto riziko tak významné – všudypřítomnost Bash – a je popisován jako „jedna z nejčastěji instalovaných utilit v jakémkoli linuxovém systému“.
O vlivu Bash si můžete udělat představu, když se podíváte na nejnovější statistiky webových serverů Netcraft:
Když polovina sítě používá Apache (který se obvykle nachází v Linuxu), je to značná velikost velmi, velmi velkého koláče. Stejný článek Netcraftu uvádí, že jsme také právě překročili hranici jedné miliardy webových stránek, a i když hromada z nich sdílí stejné hostitele, stále je to spousta instalací Bashe. A to jsou také jen webové servery, nezapomeňte, že existuje hromada dalších serverů s Linuxem a k dalším zařízením s Bashem se vrátíme o něco později.
Bash lze použít pro celou řadu typických administrátorských funkcí, od konfigurace webových stránek až po ovládání vestavěného softwaru v zařízení, jako je webová kamera. Přirozeně se nejedná o funkce, které by měly být otevřené světu, a teoreticky se bavíme o ověřených uživatelích, kteří spouštějí příkazy, k nimž byli oprávněni. Teoreticky.
Co je to za chybu?“
Nechte mě začít s CVE z databáze zranitelností NIST, protože dává dobrou představu o závažnosti (zvýraznění moje):
GNU Bash přes 4. verzi.3 zpracovává koncové řetězce za definicemi funkcí v hodnotách proměnných prostředí, což umožňuje vzdáleným útočníkům spustit libovolný kód prostřednictvím vytvořeného prostředí, jak ukazují vektory zahrnující funkci ForceCommand v OpenSSH sshd, moduly mod_cgi a mod_cgid v serveru Apache HTTP, skripty spouštěné nespecifikovanými klienty DHCP a další situace, kdy k nastavení prostředí dochází přes hranici oprávnění od spuštění Bash.
Dále hodnotí závažnost „10 z 10“, jinými slovy, je to tak špatné, jak to jen jde. K tomu přistupuje skutečnost, že provedení útoku je snadné (složitost přístupu je nízká) a snad nejvýznamnější je, že při zneužití Bash prostřednictvím skriptů CGI není vyžadována autentizace. Výše uvedené shrnutí je však poněkud zamotané, takže se pojďme omezit na mechaniku chyby.
Hrozba se soustředí na možnost libovolně definovat proměnné prostředí v rámci shellu Bash, které určují definici funkce. Problém začíná, když Bash po definici funkce pokračuje ve zpracování příkazů shellu, což vede k tomu, co bychom klasifikovali jako „útok vstřikováním kódu“. Podívejme se znovu na Robertův příklad a vezmeme jen tento řádek:
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
Definice funkce je () { :; }; a příkazem shellu je příkaz ping a následné parametry. Při zpracování v kontextu shellu Bash se provede libovolný příkaz. V kontextu webu by to znamenalo prostřednictvím mechanismu, jako je skript CGI, a ne nutně také jako hlavička požadavku. Stojí za to si přečíst poradenství seclists.org, kde se věnují podrobnějším informacím, včetně toho, že cesta a řetězec dotazu mohou být potenciálními vektory útoku.
Jedním z prostředků, jak zmírnit tento konkrétní vektor útoku, je samozřejmě jednoduše zakázat všechny funkce CGI, které volají shell, a někteří to skutečně doporučují. V mnoha případech však půjde o vážně míněnou změnu, která bude přinejmenším vyžadovat rozsáhlé testování, aby se zajistilo, že nezpůsobí okamžité problémy na webu, což se v mnoha případech stane.
Výše uvedený důkaz HTTP je jednoduchý, ale účinný, i když jde jen o jednu implementaci nad běžným protokolem. Jakmile začnete přihazovat Telnet a SSH a zřejmě i DHCP, rozsah se dramaticky zvětší, takže zde v žádném případě nemluvíme jen o zneužití serverů webových aplikací. (Podle všeho je riziko přítomno pouze v SSH po autorizaci, ale v tak raném stádiu zveřejnění se ještě nevyhnutelně objeví další vektory útoku)
Je třeba si také uvědomit, že rozsah potenciálních škod sahá daleko za ping na libovolnou adresu, jako v Robertově příkladu, to je prostě malý elegantní důkaz, že by mohl naaranžovat stroj, který by vydal příkaz shellu. Otázka zní takto: Jaké škody může útočník způsobit, když může spustit příkaz shellu podle svého výběru na libovolném zranitelném stroji?
Jaké jsou potenciální důsledky?
Potenciál je obrovský – „získání shellu“ na krabici bylo pro útočníka vždy velkou výhrou, protože mu to nabízí kontrolu nad cílovým prostředím. Přístup k interním datům, rekonfiguraci prostředí, zveřejnění vlastního škodlivého kódu atd. Je to téměř neomezené a navíc snadno automatizovatelné. Existuje již mnoho a mnoho příkladů exploitů, které lze snadno odpálit proti velkému množství počítačů.
Naneštěstí pokud jde o spuštění libovolného kódu v shellu až na polovině webových stránek na internetu, je potenciál poměrně široký. Jedním z těch zřejmých (a obzvláště nepříjemných) je vypisování interních souborů pro veřejné načítání. Soubory s hesly a konfigurační soubory s přihlašovacími údaji jsou zřejmé, ale mohly by se pravděpodobně rozšířit na jakékoli jiné soubory v systému.
Podobně by se stejný přístup dal použít i pro zápis souborů do systému. To je potenciálně nejjednodušší vektor znehodnocení webových stránek, jaký jsme kdy viděli, nemluvě o velmi snadném způsobu distribuce malwaru
Nebo co třeba toto: Jedno slovo, se kterým se stále často setkávám, je „červ“:
Když mluvíme o červu v kontextu škodlivých počítačů, mluvíme o samoreplikujícím se útoku, kdy škodlivý aktér vytvoří kód, který je schopen se šířit napříč cíli. Velmi efektivní implementaci jsme viděli například u červa Samy’s MySpace XSS Worm, kdy se pečlivě vytvořeným JavaScriptem podařilo „nakazit“ stránky milionu obětí za méně než den.
V případě Shellshocku se obáváme, že útok tohoto typu by se mohl replikovat alarmující rychlostí, zejména na počátku, kdy většina počítačů zůstává v ohrožení. Teoreticky by to mohlo probíhat tak, že infikovaný stroj vyhledá další cíle a útok se na ně rozšíří. To by se v žádném případě neomezovalo pouze na veřejně přístupné stroje; pokud by se to dostalo za firemní firewall, bylo by to neomezené.
Na využití této možnosti se pracuje již nyní. Právě proto jsou tyto první dny tak zajímavé, protože se rozhořívají závody ve zbrojení mezi těmi, kdo se snaží opravovat, a těmi, kdo se snaží útočit.
Kterých verzí Bashe se to týká?
V titulcích se uvádí vše až do verze 4.3, jinými slovy asi 25 let starých verzí Bashe. Vzhledem k tomu, že to všichni neustále srovnávají s Heartbleed, zvažte, že zasažené verze OpenSSL trvaly pouhé dva roky, což je ve srovnání s Shellshockem kapka v moři. Ano, lidé aktualizují své verze, ale ne, nedělají to důsledně a ať už to rozdělíte jakkoli, rozsah ohrožených strojů bude v případě Shellshocku podstatně větší než v případě Heartbleedu.
Riziko však může přesahovat i verzi 4.3. Již nyní se objevují zprávy o ne zcela účinných záplatách a vzhledem k rychlosti, s jakou jsou zaváděny, to není až tak překvapivé. Tohle je věc, kterou si ti, kterých se to týká, chtějí velmi pečlivě hlídat, ne jen „záplatovat a zapomenout“.
Kdy jsme se o tom dozvěděli poprvé a jak dlouho jsme byli v ohrožení?
První zmínka, kterou jsem našel ve veřejném éteru, bylo toto velmi stručné shrnutí na seclists.org, které vychází na středu kolem 14:00 GMT (pro ty z nás na východním konci Austrálie asi půlnoc dnes ráno). Podrobnosti se objevily v poradě, kterou jsem zmínil o hodinu později, takže se blíží středečnímu odpoledni v Evropě nebo ránu v USA. Je to stále velmi čerstvá zpráva se všemi obvyklými spekulacemi tisku a předpověďmi Chicken Little; je příliš brzy na to, abychom pozorovali nějaké rozsáhlé zneužití ve volné přírodě, ale to by také mohlo přijít velmi brzy, pokud riziko naplní svůj potenciál.
Přejděme zpět za to, co bylo zveřejněno, a chybu zřejmě minulý týden objevil Stéphane Chazelas, chlapík „specialista na Unix/Linux, sítě a telekomunikace“ ve Velké Británii. Jak již bylo řečeno, v příspěvku společnosti Akamai o chybě se hovoří o tom, že je přítomna „delší dobu“ a zranitelné verze Bashe jsou samozřejmě staré již dvě a půl desetiletí. Otázkou, stejně jako v případě Heartbleed, bude, zda o tom záškodníci věděli již dříve a zda toho skutečně aktivně využívali.
Jsou postiženy naše „věci“?
Tady to začíná být zajímavé – máme spoustu „věcí“, na kterých potenciálně běží Bash. Když používám tento termín, mám samozřejmě na mysli „internet věcí“ (IoT), což je stále častější používání IP adresy a bezdrátového adaptéru do všeho, od příborů přes dveřní zámky až po světelné koule.
Na mnoha zařízeních IoT běží vestavěné linuxové distribuce se systémem Bash. Stejná zařízení již vykazují závažné bezpečnostní chyby v jiných oblastech, například u světelných globusů LIFX bylo jen před několika měsíci zjištěno, že dochází k úniku přihlašovacích údajů k wifi. I když se nejedná o zranitelnost Bash jako Shellshock, ukazuje nám to, že připojením našich věcí vstupujeme do zcela nového světa zranitelností na místech, která nikdy předtím nebyla ohrožena.
Edit: Několik lidí se zmínilo o rozšířenosti BusyBoxu se shellem Ash na mobilních zařízeních. Zdá se, že zařízení s tímto shellem nejsou ohrožena Shellshockem. Potíž pro spotřebitele spočívá v tom, že neví, co na jejich zařízeních běží, a to se týká i tradičnějších „věcí“, jako jsou routery. Dlouhá historie této chyby znamená, že máme k dispozici více než několik desetiletí zařízení, která prošla různými evolucemi různých vestavěných operačních systémů, a nyní máme velmi rozmanitou krajinu strojů a shellshocků pokrývající dlouhé časové období.
To s sebou přináší mnoho nových výzev; například kdo aktivně přemýšlí o tom, že by měl pravidelně záplatovat své žárovky? Zvažte také životnost zařízení, ve kterých se tento software objevuje, a zda jsou skutečně aktivně udržována. V případě, jako jsou zranitelné kamery Trendnet z doby před několika lety, jich na webu nepochybně stále leží obrovské množství, protože z hlediska záplatování jde v podstatě o záležitost typu „nastav a zapomeň“. Ve skutečnosti v tomto případě existuje celý účet na Twitteru, který se věnuje vysílání pořízených snímků nic netušících majitelů zranitelných verzí. Je to velký problém, který se nedá snadno vyřešit, a bude se nás držet velmi dlouho.
Bash shelly jsou ale přítomny i v mnoha běžnějších zařízeních, například v našich domácích routerech, které jsou zpravidla orientovány na internet. Vzpomínáte si, kdy jste naposledy opravovali firmware svého routeru? Dobře, pokud toto čtete, pak jste možná typ technického člověka, který svůj router skutečně opravuje, ale vžijte se do role průměrného spotřebitele Joea a položte si tuto otázku znovu. Přesně tak.
Všechny naše věci jsou na stacku Microsoftu, jsme ohroženi?
Krátká odpověď „ne“, dlouhá odpověď „ano“. Nejdřív se budu zabývat tou jednodušší – Bash se ve Windows nativně nevyskytuje, a i když existují implementace Bashe pro Windows, rozhodně nejsou běžné a na spotřebitelských počítačích je nenajdete. Není také jasné, zda jsou produkty jako win-bash vůbec zranitelné vůči Shellshocku.
Dlouhodobější odpověď je, že to, že pracujete v prostředí převážně zaměřeném na Microsoft, neznamená, že nemáte Bash spuštěný na počítačích sloužících k jiným diskrétním účelům v tomto prostředí. Když jsem psal o Heartbleedu, odkazoval jsem na příspěvek Nicka Cravera o přechodu Stack Overflow na SSL a odkazoval jsem na toto schéma jejich infrastruktury:
Před jejich aplikačním stackem Microsoftu se nacházejí nemicrosoftí komponenty, komponenty, kterými musí provoz projít, než se dostane na webové servery. Jsou to také komponenty, které mohou mít zvýšená oprávnění za firewallem – jaký dopad bude mít, pokud bude Shellshock zneužit na nich? Mohlo by to být významné a to je to, na co zde poukazuji; Shellshock má potenciál ovlivnit nejen ohrožené implementace Bash, když existuje v širším ekosystému dalších strojů.
Jsem správce systému – co mohu dělat?
Předně, zjistit, zda jste ohroženi, je triviální, protože jde o tak snadno reprodukovatelné riziko. Existuje velmi jednoduchý test, který navrhuje The Register, a to pouhé spuštění tohoto příkazu v rámci shellu:
env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"env X="() { :;} ; echo busted" 'which bash' -c "echo completed"
Zpět se vám ozve echo „busted“ a vy jste chybu úspěšně zneužili.
Prioritou zde samozřejmě bude záplatování ohrožených systémů a záplata se v podstatě omezuje na zajištění toho, že po skončení funkce Bash nebude možné spustit žádný kód. Distribuce Linuxu, jako je Red Hat, vydávají pokyny k záplatování rizikových systémů, takže se na ně přednostně vrhněte.
Nevyhnutelně se také dočkáme definic pro systémy detekce průniků a jistě zde budou hledány společné vzory. To se může ukázat jako dobrá okamžitá implementace pro mnoho organizací, zejména tam, kde mohou existovat zatěžující požadavky na testování před zavedením záplat do rizikových systémů. Cílem společnosti Qualys je mít definici, která útok odhalí poměrně rychle, a nevyhnutelně na tom nepřetržitě pracují i další poskytovatelé IDS.
Další drastičtější možnosti zahrnují nahrazení Bash alternativní implementací shellu nebo uzavření rizikových systémů, což by mohlo mít dalekosáhlé důsledky a pravděpodobně nepůjde o lehkovážné rozhodnutí. Ale taková bude pravděpodobně povaha této chyby pro mnoho lidí – těžká rozhodnutí, která by mohla mít hmatatelný dopad na podnikání, aby se vyhnuli potenciálně mnohem závažnějším důsledkům.
Dalším problémem, který se nyní začne často objevovat, je otázka, zda již byl Shellshock v nějakém prostředí zneužit. To může být těžké určit, pokud se nelogují vektory útoku (často nebudou, pokud se předává hlavičkou HTTP požadavku nebo tělem POST), ale je pravděpodobnější, že se to zachytí, než v případě Heartbleedu, kdy kromě plného zapnutí pcaps by se heartbeat payloady normálně nikde nelogovaly. Ale i tak bude nejčastější odpověď na otázku „byli jsme napadeni přes Shellshock“ tato:
bohužel to není „Ne, máme důkazy, že nedošlo ke kompromitaci“; spíše „nemáme důkazy, které by se týkaly celé doby trvání této zranitelnosti“. Pochybujeme, že je má mnoho lidí – a to ponechává majitele systémů v nepříjemné situaci, kdy nevědí, k jakým kompromitacím mohlo dojít, pokud vůbec k nějakým došlo.
Nechť začnou spekulace o tom, zda v tom jela NSA…
Jsem spotřebitel – co mohu dělat?
Záleží na tom. Shellshock postihuje počítače Mac, takže pokud používáte OS X, v této fázi se zdá, že je ohrožen, což je na jednu stranu špatně vzhledem k rozšířenosti OS X, ale na druhou stranu bude snadno (a doufejme, že rychle) odstranitelný díky celkem osvědčenému mechanismu aktualizací (tj. Apple může vzdáleně posílat aktualizace do počítače).
Pokud jste na Macu, riziko lze snadno otestovat, jak je popsáno v této odpovědi na Stack Exchange:
Jde o snadný test, i když pochybuji, že se průměrný uživatel Macu bude cítit pohodlně, když projde navrhovanou opravou, která zahrnuje rekompilaci Bash.
Větší starosti dělají zařízení bez snadné cesty k záplatování, například router. Krátce po zjištění aktualizovaného firmwaru na webu výrobce to bude opravdu tvrdý oříšek. Routery poskytované poskytovateli internetu jsou často uzamčené, takže spotřebitelé náhodně nemění ani konfiguraci, ani firmware, a ne vždy existuje vzdálená cesta aktualizace, kterou by mohli spustit. V kombinaci s obrovským množstvím zařízení a jejich stářím by to mohlo být obzvlášť složité. Samozřejmě to také není věc, kterou by průměrný spotřebitel pohodlně dělal sám.
Zkrátka rada pro spotřebitele zní: sledujte bezpečnostní aktualizace, zejména v systému OS X. Sledujte také všechny rady, které můžete dostat od svého poskytovatele internetových služeb nebo jiných poskytovatelů zařízení, na kterých máte vestavěný software. Buďte obezřetní k e-mailům, které vás žádají o informace nebo dávají pokyny ke spuštění softwaru – po takových událostech často následují phishingové útoky, které využívají strachu spotřebitelů. Hoaxy v současné době nutí lidi dávat své iPhony do mikrovlnné trouby, takže si ani na okamžik nemyslete, že nespustí náhodný kus softwaru, který jim byl zaslán e-mailem jako „oprava“ Shellshocku!
Shrnutí
S největší pravděpodobností jsme ještě ani nezačali domýšlet rozsah této zranitelnosti. Samozřejmě se objevuje spousta srovnání s Heartbleed a z tohoto cvičení jsme se dozvěděli řadu věcí. Jednou z nich je, že nám chvíli trvalo, než jsme si uvědomili, do jaké míry jsme závislí na OpenSSL. Druhá věc je, že to mělo velmi dlouhý chvost – několik měsíců po úderu zůstaly zranitelné stovky tisíc známých hostitelů.
V jednom ohledu ale srovnání s Heartbleed není fér – tohle je potenciálně mnohem horší. Heartbleed umožňoval vzdálený přístup k malému množství dat v paměti postižených počítačů. Shellshock umožňuje vzdálené vkládání kódu libovolných příkazů před autorizací, což je potenciálně mnohem hrozivější. V tomto ohledu musím souhlasit s Robertem:
Je ještě velmi, velmi brzy – v době psaní tohoto článku uplynulo teprve půl dne od chvíle, kdy se to poprvé dostalo do éteru – a mám podezření, že zatím jen škrábeme povrch toho, co teprve přijde.
Bezpečnost