Emlékszel még a Heartbleedre? Ha hihetsz a mai hype-nak, a Shellshock is ebben a ligában játszik, és ugyanolyan félelmetes névvel, bár nélkülözi a menő logót (valakinek az ilyen sebezhetőségek marketingosztályán rá kell állnia erre). De minden komolysággal, ez potenciálisan nagy dolog lehet, és ahogy a Heartbleed esetében is tettem, össze akartam állítani valamit, ami meghatározó mind számomra, hogy megbirkózzak a helyzettel, mind mások számára, hogy boncolgassák a hype-ot a valódi mögöttes kockázattól.
A színpadra állításhoz hadd osszam meg Robert Graham blogbejegyzésének néhány tartalmát, aki kiváló elemzést készített ezzel kapcsolatban. Képzeljünk el egy ilyen HTTP-kérést:
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
amely, ha egy sor sebezhető IP-címre adjuk ki, ezt eredményezi:
Röviden fogalmazva, Robert éppen egy csomó külső gépet hangszerelt arra, hogy pingelje őt, egyszerűen egy gondosan kidolgozott kérés webes kiadásával. Ami igazán aggasztó, az az, hogy gyakorlatilag arra késztette ezeket a gépeket, hogy egy tetszőleges parancsot adjanak ki (bár egy meglehetősen jóindulatú pinget), és ez nagyon komoly lehetőségek egész világát nyitja meg. Hadd magyarázzam el.
Mi az a Bash, és miért van rá szükségünk?
Hagyjuk ezt, ha ez már régi hír, de a kontextus fontos azok számára, akik nem ismerik a Bash-t, ezért hozzunk létre egy alapszintű megértést. A Bash egy *nix shell vagy más szóval egy értelmező, amely lehetővé teszi, hogy parancsokat vezényeljünk Unix és Linux rendszereken, jellemzően SSH vagy Telnet kapcsolaton keresztül. CGI szkriptek elemzőjeként is működhet egy webkiszolgálón, mint amilyeneket tipikusan az Apache-on látunk futni. A 80-as évek vége óta létezik, ahol a korábbi shell implementációkból fejlődött ki (a neve a Bourne shellből származik), és óriási népszerűségnek örvend. A Unix változatokhoz más héjak is léteznek, a Bash-sel kapcsolatban azonban az a lényeg, hogy ez az alapértelmezett héj a Linux és a Mac OS X operációs rendszerekhez, amelyek nyilvánvalóan rendkívül elterjedt operációs rendszerek. Ez az egyik fő tényező, ami miatt ez a kockázat olyan jelentős – a Bash mindenütt jelen van -, és úgy írják le, mint “az egyik legtöbbet telepített segédprogram bármely Linux rendszeren”.
A Bash lábnyomát érzékelheted, ha megnézed a Netcraft legfrissebb webszerver statisztikáit:
Ha a net fele Apache-t futtat (ami jellemzően Linuxon található), akkor ez egy nagyon-nagyon nagy tortából jelentős méret. Ugyanez a Netcraft-cikk arról számol be, hogy nemrég átléptük az egymilliárd weboldalt is, és bár ezek közül egy csomó ugyanazokon a hosztokon osztozik, ez még mindig rengeteg Bash-telepítés. Ó – ez csak a webszerverek, ne felejtsük el, hogy van egy rakás más Linuxot futtató szerver is, és kicsit később visszatérünk más eszközökre is a Bash segítségével.
A Bash a tipikus adminisztrációs funkciók egész sorára használható, a weboldalak konfigurálásától kezdve a beágyazott szoftverek, például egy webkamera vezérléséig. Természetesen ez nem olyan funkció, amelyet a világ számára nyitottnak szánnak, és elméletileg hitelesített felhasználókról beszélünk, akik az általuk engedélyezett parancsokat hajtják végre. Elméletben.
Mi a hiba?
Hadd kezdjem a CVE-vel a NIST sebezhetőségi adatbázisából, mert jól érzékelteti a súlyosságot (kiemelés tőlem):
GNU Bash through 4.3 a környezeti változók értékeiben a függvénydefiníciók után hátrahagyott karakterláncokat dolgoz fel, ami lehetővé teszi a távoli támadók számára tetszőleges kód futtatását egy manipulált környezeten keresztül, amint azt az OpenSSH sshd ForceCommand funkcióját, az Apache HTTP Server mod_cgi és mod_cgid moduljait, a nem meghatározott DHCP kliensek által végrehajtott szkripteket és más olyan helyzeteket érintő vektorok mutatják, amelyekben a környezet beállítása a Bash végrehajtásától eltérő jogosultsági határon túl történik.
A továbbiakban “10-ből 10”-re értékelik a súlyosságot, vagyis a lehető legrosszabbra. Ezt tetézi, hogy a támadást könnyű végrehajtani (a hozzáférés összetettsége alacsony), és ami talán a legfontosabb, hogy a Bash CGI-szkripteken keresztül történő kihasználásakor nincs szükség hitelesítésre. A fenti összefoglaló azonban kissé bonyolult, ezért egyszerűsítsük le a hiba mechanikájára.
A kockázat középpontjában az áll, hogy a Bash héjon belül tetszőlegesen definiálhatunk olyan környezeti változókat, amelyek egy függvény definícióját adják meg. A baj akkor kezdődik, amikor a Bash folytatja a shell parancsok feldolgozását a függvénydefiníció után, ami azt eredményezi, amit mi “kódinjekciós támadásnak” minősítenénk. Nézzük meg újra Robert példáját, és csak ezt a sort vesszük:
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
A függvény definíciója () { :; }; és a shell parancs a ping utasítás és az azt követő paraméterek. Ha ezt egy Bash shell kontextusában dolgozzuk fel, akkor a tetszőleges parancs végrehajtásra kerül. Webes kontextusban ez egy olyan mechanizmust jelentene, mint egy CGI szkript, és nem feltétlenül kérés fejlécként is. Érdemes elolvasni a seclists.org tanácsadást, ahol részletesebben is kifejtik, többek között azt, hogy az elérési útvonal és a lekérdezési karakterlánc potenciális támadási vektorok lehetnek.
Természetesen ennek a támadási vektornak az enyhítésére az egyik eszköz az, hogy egyszerűen letiltunk minden olyan CGI funkciót, amely shell-t hív, és néhányan ezt ajánlják is. Sok esetben azonban ez egy komolyan törő változtatás lesz, és legalábbis olyan, amely kiterjedt tesztelést igényel annak biztosítására, hogy ne okozzon azonnali problémákat a weboldalon, ami sok esetben meg is fog történni.
A fenti HTTP-bizonyíték egyszerű, de hatékony, bár csak egy közös protokollon keresztül történő megvalósítás. Amint elkezdjük bedobni a Telnetet és az SSH-t, és nyilvánvalóan még a DHCP-t is, a hatókör drámaian megnő, így semmiképpen sem csak a webes alkalmazások szervereinek kihasználásáról beszélünk itt. (Úgy tűnik, hogy a kockázat csak az SSH post-auth-ban van jelen, de a nyilvánosságra hozatal ilyen korai szakaszában elkerülhetetlenül látni fogunk még más támadási vektorok megjelenését.)
Azt sem szabad elfelejteni, hogy a potenciális kár terjedelme jóval túlmutat egy tetszőleges cím pingelésén, mint Robert példájában, ez egyszerűen egy takaros kis bizonyíték arra, hogy egy gépet egy shell parancs kiadására tudott hangszerelni. A kérdés a következő:
Milyen lehetséges következményekkel járhat?
A lehetőségek óriásiak – a “shell” megszerzése egy dobozon mindig is nagy nyereség volt a támadók számára, mivel a célzott környezet feletti kontrollt biztosít számukra. Hozzáférés a belső adatokhoz, a környezetek újrakonfigurálása, saját rosszindulatú kódok közzététele stb. Ez szinte korlátlan, és könnyen automatizálható. Már most is sok-sok példa van olyan exploitokra, amelyeket könnyen ki lehet lőni nagyszámú gép ellen.
Sajnos, ha az interneten található webhelyek akár felén lévő héjban történő önkényes kódfuttatásról van szó, a lehetőségek elég széleskörűek. Az egyik nyilvánvaló (és különösen kellemetlen) a belső fájlok nyilvános lehívásra történő dömpingje. A jelszófájlok és a hitelesítő adatokat tartalmazó konfigurációs fájlok a nyilvánvalóak, de elképzelhető, hogy a rendszerben lévő bármely más fájlra is kiterjeszthető.
Az ugyanez a megközelítés alkalmazható a rendszerbe írt fájlok írására is. Ez potenciálisan a valaha látott legegyszerűbb weboldal-fertőzési vektor, nem is beszélve a rosszindulatú programok terjesztésének nagyon egyszerű módjáról
Vagy mit szólsz ehhez: az egyik szó, amellyel sokat találkozom, a “féreg”:
Mikor a rosszindulatú számítástechnikában féregről beszélünk, akkor olyan önmásoló támadásról beszélünk, amelyben egy rosszindulatú szereplő olyan kódot hoz létre, amely képes terjedni a célpontokon. Ennek nagyon hatékony megvalósítását láthattuk például a Samy’s MySpace XSS Worm esetében, ahol néhány gondosan kidolgozott JavaScript segítségével kevesebb mint egy nap alatt egymillió áldozat oldalát sikerült “megfertőzni”.
A Shellshock esetében az az aggodalom, hogy egy ilyen jellegű támadás riasztó sebességgel szaporodhat, különösen a korai szakaszban, amíg a gépek többsége veszélyben van. Elméletileg ez úgy történhet, hogy egy fertőzött gép más célpontok után kutat, és ezekre terjeszti a támadást. Ez semmiképpen sem korlátozódna a nyilvános gépekre; a vállalati tűzfal mögé kerülve a határ a csillagos ég.
Az emberek már most is dolgoznak ennek kihasználásán. Ez teszi ezeket a korai napokat olyan érdekessé, ahogy a fegyverkezési verseny a foltozásra és a támadásra törekvők között felforrósodik.
Melyik Bash-verziók érintettek?
A szalagcímek szerint a 4.3-ig minden, vagy más szóval körülbelül 25 évnyi Bash-verzió. Mivel ezt mindenki a Heartbleedhez hasonlítja, gondoljunk arra, hogy az OpenSSL érintett verziói mindössze két évet öleltek fel, ami a Shellshockhoz képest csepp a tengerben. Igen, az emberek frissítik a verziókat, de nem, nem teszik ezt következetesen, és akárhogy is nézzük, a Shellshock esetében a veszélyeztetett gépek köre jelentősen nagyobb lesz, mint a Heartbleed esetében.
De a kockázat a 4.3-on túl is terjedhet. Már most arról kapunk jelentéseket, hogy a javítások nem teljesen hatékonyak, és tekintve a gyorsaságot, amivel kiadták őket, ez nem is olyan meglepő. Ez az a fajta dolog, amit az érintettek nagyon szorosan szemmel akarnak tartani, nem csak “foltozni és elfelejteni”.
Mikor értesültünk róla először, és mióta vagyunk veszélyben?
Az első említés, amit a nyilvános éterben találtam, ez a nagyon rövid összefoglaló volt a seclists.org-on, amely szerdán 14:00 GMT körül készült (körülbelül ma reggel éjfélkor az Ausztrália keleti részén élők számára). A részletek az általam korábban említett tanácsadásban jelentek meg egy órával később, így Európában a szerda délutáni órák, az Egyesült Államokban pedig a reggeli órák felé közelednek. Ez még mindig nagyon friss hír, a szokásos sajtóspekulációkkal és Chicken Little jóslatokkal; túl korai lenne megfigyelni bármilyen széles körű kihasználást a vadonban, de ez is nagyon hamar bekövetkezhet, ha a kockázat beváltja a benne rejlő lehetőségeket.
Tekintsünk vissza a nyilvánosságra hozott adatokon túlra, és a hibát nyilvánvalóan Stéphane Chazelas, egy “Unix/Linux, hálózati és távközlési specialista” fickó fedezte fel a múlt héten az Egyesült Királyságban. Ennek ellenére az Akamai a hibáról szóló bejegyzésében arról beszél, hogy a hiba már “hosszabb ideje” jelen van, és természetesen a Bash sebezhető változatai már két és fél évtizedes múltra tekintenek vissza. A kérdés a Heartbleedhez hasonlóan az lesz, hogy a rosszindulatú szereplők tudtak-e erről korábban, és valóban aktívan kihasználják-e.
A mi “dolgaink” is érintettek?
Itt válik érdekessé a dolog – sok “dolgunk” futtatja potenciálisan a Bash-t. Természetesen amikor ezt a kifejezést használom, a “dolgok internetére” (Internet of Things, IoT) utalok, ami azt jelenti, hogy egyre inkább elterjedt az IP-cím és a vezeték nélküli adapter beépítése az evőeszközeinktől kezdve az ajtózárakon át a világítótestekig mindenbe.
Sok IoT-eszközön futnak beágyazott Linux-disztribúciók Bash-szel. Ugyanezekről az eszközökről már kiderült, hogy más területeken is komoly biztonsági réseket mutatnak, például a LIFX világítógömbökről alig néhány hónapja derült ki, hogy wifi hitelesítő adatokat szivárogtatnak ki. Bár ez nem egy olyan Bash sebezhetőség, mint a Shellshock, mégis azt mutatja, hogy a dolgaink összekapcsolásával a sebezhetőségek teljesen új világába lépünk be olyan helyeken, amelyek korábban soha nem voltak veszélyben.
Szerkesztés: Néhányan utaltak az Ash shell-t futtató BusyBox elterjedtségére a mobileszközökön. Úgy tűnik, hogy az ezt futtató eszközök nincsenek Shellshock-kockázatnak kitéve. A nehézséget a fogyasztók számára az jelenti, hogy nem tudják, mi fut az eszközeiken, és ez olyan hagyományosabb “dolgokra” is vonatkozik, mint a routerek. Ennek a hibának a hosszú története azt jelenti, hogy több mint néhány évtizednyi eszközünk van, amelyek különböző beágyazott operációs rendszerek különböző evolúcióin mentek keresztül, és most egy nagyon változatos, hosszú időn átívelő gép- és shellshock-tájképpel rendelkezünk.
Ez sok új kihívást hoz magával; például ki gondolja aktívan, hogy rendszeresen foltoznia kellene a villanykörtéit? Gondoljunk arra is, hogy milyen hosszú életű eszközökben jelennek meg ezek a szoftverek, és hogy valóban aktívan karbantartják-e őket. Az olyan esetekben, mint a néhány évvel ezelőtti sebezhető Trendnet kamerák, kétségtelenül rengeteg van belőlük még mindig a weben, mert a foltozás szempontjából ezek nagyjából egy “állítsd be és felejtsd el” ajánlatot jelentenek. Ebben az esetben egy egész Twitter-fiók foglalkozik azzal, hogy a sebezhető verziók gyanútlan tulajdonosairól készített képeket sugározza. Ez egy nagy probléma, amelynek nincs könnyű megoldása, és még nagyon sokáig velünk marad.
A Bash-héjak azonban sok hétköznapi eszközben is jelen vannak, például az otthoni routerekben, amelyek általában az internetre néznek. Emlékszel, mikor javítottad utoljára a firmware-t a routereden? Oké, ha ezt olvasod, akkor talán az a fajta műszaki ember vagy, aki valóban foltozza a routerét, de képzeld magad az átlagfogyasztó helyébe, és kérdezd meg magadtól ezt újra. Pontosan.
Minden eszközünk a Microsoft stack-en van, veszélyben vagyunk?
Rövid válasz: “nem”, hosszú válasz: “igen”. Először a könnyűvel foglalkozom – a Bash nem található meg natívan a Windowson, és bár vannak Bash implementációk Windowsra, ez biztosan nem általános, és nem lesz megtalálható a fogyasztói PC-ken. Az sem egyértelmű, hogy az olyan termékek, mint a win-bash egyáltalán sebezhetőek-e a Shellshockkal szemben.
A hosszabb válasz az, hogy csak azért, mert Ön egy túlnyomórészt Microsoft-központú környezetben működik, nem jelenti azt, hogy nem fut a Bash a környezeten belül más, különálló célokat szolgáló gépeken. Amikor a Heartbleedről írtam, hivatkoztam Nick Craver bejegyzésére a Stack Overflow SSL felé történő elmozdításáról, és utaltam az infrastruktúrájukról készült ábrára:
A Microsoft alkalmazás stack előtt nem Microsoft komponensek ülnek, olyan komponensek, amelyeken a forgalomnak át kell haladnia, mielőtt elérné a webszervereket. Ezek olyan komponensek is, amelyek a tűzfal mögött megnövelt jogosultságokkal rendelkezhetnek – mi a hatása annak, ha a Shellshockot ezeken kihasználják? Jelentős lehet, és ez a lényeg, amire itt utalok; a Shellshock hatással lehet az eszközökre a veszélyeztetett Bash implementációkon túl is, ha más gépek szélesebb ökoszisztémájában létezik.
Rendszeradminisztrátor vagyok – mit tehetek?
Először is, a kockázat felfedezése triviális, mivel ez egy könnyen reprodukálható kockázat. Van egy nagyon egyszerű teszt, amit a The Register javasol, ami nem más, mint ennek a parancsnak a futtatása a héjon belül:
env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"env X="() { :;} ; echo busted" 'which bash' -c "echo completed"
Az “elkapott” visszhangot visszakapod, és sikeresen kihasználod a hibát.
A prioritás itt természetesen a veszélyeztetett rendszerek foltozása lesz, és a folt lényegében arra fut ki, hogy a Bash függvények vége után nem lehet kódot végrehajtani. A Linux disztribúciók, mint például a Red Hat, útmutatást adnak ki a kockázat foltozásához, így ezt prioritásként kell kezelni.
Kikerülhetetlenül látni fogjuk a behatolásérzékelő rendszerek definícióit is, és minden bizonnyal lesznek közös minták, amelyeket itt keresni kell. Ez sok szervezet számára jó azonnali megvalósításnak bizonyulhat, különösen ott, ahol a kockázatos rendszerekre történő javítások bevezetése előtt terhelő tesztelési követelmények merülnek fel. A Qualys célja, hogy a támadást gyorsan felismerő definícióval rendelkezzen, és elkerülhetetlen, hogy más IDS-szolgáltatók is éjjel-nappal dolgozzanak ezen.
A többi drasztikusabb lehetőség közé tartozik a Bash helyettesítése egy alternatív shell implementációval vagy a kockázatos rendszerek elzárása, mindkettőnek messzemenő következményei lehetnek, és valószínűleg nem könnyű döntés. De valószínűleg sokak számára ez lesz ennek a hibának a természete – nehéz döntések, amelyek kézzelfogható üzleti hatással járhatnak, hogy elkerüljék a potenciálisan sokkal jelentősebb következményeket.
A másik kérdés, amely mostantól sokat fog felmerülni, az a kérdés, hogy a Shellshockot kihasználják-e már egy környezetben. Ezt nehéz lehet megállapítani, ha nincs naplózás a támadási vektorokról (gyakran nem lesz, ha a HTTP kérés fejlécével vagy a POST testtel adják át), de valószínűbb, hogy elkapják, mint a Heartbleed esetében, amikor a teljes pcaps hiányában a heartbeat payloadok általában nem lettek volna sehol naplózva. De még mindig, a leggyakoribb válasz a “megtámadtak minket a Shellshockon keresztül” kérdésre ez lesz:
szerencsére ez nem “Nem, bizonyítékunk van arra, hogy nem volt kompromittálódás”; inkább “nincs bizonyítékunk, ami átfogja a sebezhetőség élettartamát”. Kételjük, hogy sokaknak van – és ez a rendszertulajdonosokat abban a kellemetlen helyzetben hagyja, hogy nem tudják, milyen kompromittálódások történhettek, ha történtek egyáltalán.
Kezdődjenek a találgatások arról, hogy az NSA benne volt-e a dologban…
Fogyasztó vagyok – mit tehetek?
Az attól függ. A Shellshock a Mac-eket érinti, így ha OS X-et futtatsz, ebben a szakaszban úgy tűnik, hogy veszélyben van, ami egyrészt rossz az OS X elterjedtsége miatt, de másrészt könnyen (és remélhetőleg gyorsan) orvosolható lesz egy elég jól bevált frissítési mechanizmus miatt (azaz az Apple távolról tud frissítéseket tolni a gépre).
Ha Mac-et használsz, a kockázat könnyen tesztelhető, ahogy ez a Stack Exchange válasz leírja:
Ez egy egyszerű teszt, bár kétlem, hogy az átlagos Mac-felhasználó kényelmesen végig fogja lépni a javasolt javítást, ami a Bash újrafordítását jelenti.
A nagyobb gondot a könnyű javítási útvonallal nem rendelkező eszközök jelentik, például a router. A gyártó weboldalán történő frissített firmware keresésen kívül ez egy nagyon nehéz dió lesz. Gyakran az internetszolgáltatók által biztosított routerek le vannak zárva, hogy a fogyasztók ne változtassák meg véletlenszerűen sem a konfigurációt, sem a firmware-t, és nem mindig van távoli frissítési útvonal, amelyet kiválthatnak. Ha ezt kombináljuk az eszközök és korosztályok hatalmas választékával, akkor ez különösen trükkös lehet. Persze ez sem az a fajta dolog, amit az átlagfogyasztó szívesen csinál magának.
Röviden, a fogyasztóknak a következő tanácsot adjuk: figyeljék a biztonsági frissítéseket, különösen az OS X esetében. Tartsa szemmel az internetszolgáltatójától vagy a beágyazott szoftvereket futtató eszközök egyéb szolgáltatóitól kapott tanácsokat is. Legyen óvatos az olyan e-mailekkel, amelyekben információkat kérnek vagy szoftver futtatására utasítják – az ilyen eseményeket gyakran követik adathalász-támadások, amelyek a fogyasztók félelmeit használják ki. Az átverések miatt az emberek jelenleg az iPhone-jukat a mikrohullámú sütőbe teszik, ezért egy pillanatig se higgye, hogy nem fognak futtatni egy véletlenszerű szoftvert, amelyet a Shellshock “javításaként” e-mailben küldenek nekik!
Összefoglaló
Minden valószínűség szerint még csak el sem kezdtük felfogni ennek a sebezhetőségnek a terjedelmét. Természetesen rengeteg összehasonlítást tesznek a Heartbleeddel, és számos dolgot tanultunk abból a gyakorlatból. Az egyik, hogy egy kis időbe telt, mire rájöttünk, milyen mértékben függünk az OpenSSL-től. A másik, hogy a probléma nagyon hosszú ideig tartott – hónapokkal a támadás után még mindig több százezer ismert hoszt volt sebezhető.
De egy szempontból a Heartbleed-összehasonlítás nem fair – ez potenciálisan sokkal rosszabb. A Heartbleed lehetővé tette a távoli hozzáférést az érintett gépek memóriájában lévő kis mennyiségű adathoz. A Shellshock lehetővé teszi a tetszőleges parancsok távoli kódbefecskendezését az engedélyezés előtt, ami potenciálisan sokkal szörnyűbb. Ebben a tekintetben egyet kell értenem Roberttel:
Ez még nagyon-nagyon korai – a cikk írásakor még csak fél nap telt el azóta, hogy először került az éterbe -, és gyanítom, hogy egyelőre csak a felszínét kapargatjuk annak, ami még hátravan.
Biztonság