A Shellshock egy 30 éve létező hiba a Bash parancssori felületű shellben, amelyet 2014-ben fedeztek fel jelentős fenyegetésként. A Shellshock ma is fenyegetést jelent a vállalkozások számára.
A fenyegetés minden bizonnyal kevésbé kockázatos, mint a felfedezés évében. Azonban egy olyan évben, amikor a biztonsági prioritások újrakalibrálódtak, hogy lépést tartsanak a kaotikus tájjal, itt az ideje, hogy visszatekintsünk erre a fenyegetésre és azokra a mögöttes tényezőkre, amelyek ma is életben tartják ezeket a támadásokat.
Miért releváns a Shellshock 2020-ban?
A Shellshock kritikus sebezhetőség a támadók számára biztosított eszkalált jogosultságok miatt, amelyek lehetővé teszik számukra, hogy tetszés szerint veszélyeztessék a rendszereket. Bár a ShellShock sebezhetőséget, a CVE-2014-6271-et 2014-ben fedezték fel, ismert, hogy még mindig számos szerveren létezik a világon. A sebezhetőséget nem sokkal később frissítették (CVE-2014-7169), és egészen 2018-ig módosították.
A fő ok, amiért a Shellshock még mindig használatban van, nem meglepő. Ez a sebezhetőség egy egyszerű és olcsó támadás, amelyet a rossz szereplők bevethetnek egy tudatlan célpont ellen. A CVE-bejegyzés óta elérhetőek a javítások, de minden olyan szervezet, amely nem rendelkezik megfelelő javításkezelő rendszerrel, még mindig sebezhető lehet.
A Shellshock még 2017-ben is kiemelkedő volt. Ha a támadóknak csak néhány alapvető programozási készségre, egy szerverre és a rosszindulatú szoftverekhez való hozzáférésre van szükségük, akkor ez nem meglepő. Ráadásul a támadás kivitelezésének költsége nem sokkal több, mint néhány dollár havonta. A matematika a támadóknak kedvez. Minimális tudás, kis erőfeszítés és alacsony költségek egyenlőek egy könnyű hacker stratégiával.
A kiberbiztonsági médiamegjelenések és még a Belbiztonsági Minisztérium riasztása ellenére egyes rendszerek továbbra is javítatlanok. Az egyik példa szerint a Center for Election Systems tisztviselői nem alkalmaztak olyan javítást, amely veszélyeztette a georgiai választási rendszereket.
Hogyan működik a Shellshock?
Laikusan szólva a Shellshock egy olyan sebezhetőség, amely lehetővé teszi, hogy a Bash sebezhető verzióját tartalmazó rendszereket kihasználva magasabb jogosultságokkal rendelkező parancsokat lehessen végrehajtani. Ez lehetővé teszi a támadók számára, hogy potenciálisan átvegyék az adott rendszer irányítását.
Mélyebbre merülve a technikai részletekbe, a Shellshock egy biztonsági hiba a Bash héjban (GNU Bash a 4.3-as verzióig), amely a Bash-t a környezeti változókból származó nem szándékos bash parancsok végrehajtására készteti. A sebezhetőséget kihasználó fenyegető szereplők távolról is kiadhatnak parancsokat a célállomáson. Bár a Bash alapvetően nem az internetre irányul, számos belső és külső szolgáltatás, például webkiszolgáló használja a környezeti változókat a szerver operációs rendszerével való kommunikációhoz.
Ha ezeket az adatbemeneteket a végrehajtás előtt nem szanálják – ez az a kódolási szabványos folyamat, amely biztosítja, hogy a kód ne legyen része a bemenetnek -, a támadók a Bash héjon keresztül végrehajtott HTTP-kérő parancsokat indíthatnak.
A sebezhetőség részletesen
A webszerverek nem az egyetlen sebezhető hálózati erőforrás. Az e-mail kiszolgálók és a DNS-kiszolgálók, amelyek a BASH-ot használják az operációs rendszerrel való kommunikációra, szintén érintettek lehetnek. Bár a BASH rendszerint Unix-alapú rendszereken található, a Windows-alapú rendszereket használó szervezetek sem védettek. Ezek valószínűleg olyan eszközöket vagy hardvereket használnak, amelyek sebezhetőek. Ne feledjük, hogy a BASH része lehet az otthoni routereknek, számos IoT-eszköznek és beágyazott rendszernek.
AShellshock akár Denial of Service (DOS) támadások indítására is használható.
Itt a kódsor (egy Bash-funkció deklarációja, amelyet pontosvessző követ, és a ‘sleep’ parancs három lehetséges útvonalról futtatva biztosítja a végrehajtást):
new_function() { :;} ; /bin/sleep 20 /sbin/sleep 20 | /usr/bin/sleep 20
Ez a “sleep” parancs arra kényszeríti a szervert, hogy húsz másodpercet várjon a válaszadás előtt. Ezáltal a gép erőforrásai lényegében túszként vannak tartva, mert a gép húsz másodpercig semmi mást nem tud csinálni.
Egy sleep parancs lehet, hogy ártalmatlan, de egy támadó képes lehet ezt rosszindulatú kóddal helyettesíteni. Ezután ez a kód megbilincselheti a kiszolgálót vagy az erőforrást, így az képtelen lesz bármilyen kérést kezelni.
Nagy a kockázata annak, hogy a kártékony internetfelhasználók számára lehetővé válik, hogy távolról tetszőleges parancsokat hajtsanak végre. A nyitás használatával a rossz szereplők programokat indíthatnak a rendszeren, kimenő kapcsolatokat hozhatnak létre saját rendszereikhez, és rosszindulatú szoftvereket futtathatnak.
A legkritikusabb talán az, hogy a sebezhetőség kihasználható a rendszerben tárolt bizalmas adatok és információk, például hitelkártyaadatok, jelszavak és személyazonosításra alkalmas információk (PII) ellopására.
Még mindig elterjedt a Shellshock?
A Shellshock már nem olyan elterjedt, mint 2014-es felfedezésekor. Képzelje el azt a kihívást, hogy a vállalat összes sebezhető szerverét foltoznia kell (és akkoriban sokan voltak).
Ezzel együtt a Shellshock továbbra is probléma.
Folyamatban van például egy “Sea Turtle” nevű kiberfenyegetés és sebezhetőségi kampány, amely a DNS-bejegyzéseket használja ki arra, hogy hozzáférjen érzékeny rendszerekhez. A támadások sikeréhez számos gyakori hardver- és szoftveres sebezhetőségre van szükség – a Shellshock az egyik ilyen.
Noha közel sem olyan elterjedt, mint korábban, minden vállalatnak meg kell győződnie arról, hogy minden hardver és szoftver foltozva van és naprakész.
Hogyan lehet tudni, hogy érintett-e
Mivel a Shellshock hat éves, rengeteg sebezhetőség-ellenőrző program áll rendelkezésre. Néhány közülük ingyenes. Az egyik, a bashcheck letölthető a Github segítségével.
A technikai érdeklődésűek számára egy egyszerű parancs beírása a Bash promptba is megteszi a hatását:
env X=”() { :;} ; echo Bash is Infected” /bin/sh -c “echo completed”
env X=”() { :;} ; echo Bash is Infected” `which bash` -c “echo completed”
env VAR='() { :;}; echo Bash is Infected’ bash -c “echo completed”
Ha a prompt a “Bash is Infected” üzenetet adja vissza, ideje frissíteni és javítani. Ha a kimenete nem adja vissza, hogy “Bash is Infected”, akkor valami ilyesmivel fog válaszolni:
bash: warning: VAR: ignoring function definition attempt
bash: error importing function definition for `VAR’
Bash Test
Ha weboldal vagy konkrét CGI szkriptek sebezhetőségét szeretné tesztelni, a következő eszköz segíthet: ‘ShellShock’ Bash sebezhetőség CVE-2014-6271 Teszteszköz. A két beviteli mező valamelyikébe írja be a tesztelni kívánt weboldal vagy CGI-szkript URL-címét, majd kattintson a kék gombokra.
Mit tanulhatunk a kiberbiztonsági fenyegetésekről
A legnagyobb tanulság a vállalkozások számára – és ezt meg kell ismételni – az, hogy foltozzák be a rendszereket.
A foltozási időt csökkenteni tudó csapatok jobban át tudják irányítani ezeket az erőforrásokat az égetőbb biztonsági problémákra. Bár egyes vállalatok a javításkezelést inkább informatikai, mint biztonsági feladatnak tekintik, a biztonsági részlegeknek mindig a javításkezelésre kell összpontosítaniuk, mivel az kritikus fontosságú a vállalat biztonsági helyzetének szempontjából.
Ha az Ön rendszerei ma még mindig sebezhetőek, akkor valószínűleg vannak olyan alapvető működési problémák, amelyekkel foglalkozni kell. A Shellshock egy nagyon régi sebezhetőség, amelynek javítófoltjai szinte minden rendszerhez elérhetők. A legjobb módja az ilyen típusú sebezhetőség elleni védelemnek, ha naprakészen tartja rendszereit, és alkalmazza az összes, erre az exploitra kiadott javítást.
Az eszközök foltozása során, ami általában egy egyszerű folyamat, stratégiai megközelítést kell alkalmaznia.
Az alaposan tesztelt javítások nagyszerű módja az üzleti hatások minimalizálásának – például egy régi operációs rendszert futtató, kritikus fontosságú szerver esetében. Ha egy rendszer nem javítható azonnal, a sebezhetőség potenciális kockázatát az üzleti hatással szemben kell mérlegelni.
A Shellshock csak egy a sebezhetőségek hosszú listáján, amelyekkel a vállalatnak foglalkoznia kell. A sebezhetőségek végtelennek tűnő áradatának kezelése a kiberbiztonságot alátámasztó kritikus stratégia, és ez mindig is így lesz.
Checklista a biztonságos szervezethez
A sikeres sebezhetőségkezeléshez a vállalatoknak képesnek kell lenniük arra, hogy az alábbi három területen sikerrel járjanak:
- A potenciálisan veszélyes sebezhetőségek gyors azonosítása: Itt a gyorsaság a legfontosabb. Ha mindenki egy oldalon áll egy szilárd tervvel, az elősegíti a gyorsabb reakcióidőt.
- A sebezhetőség súlyossági szintjének meghatározása: A szervezet kockázattűrő képességének ismerete nagyban hozzájárul annak meghatározásához, hogy egy sebezhetőség milyen súlyos lehet. A hálózati infrastruktúrától függően egyes sebezhetőségek veszélyesebbek, mint mások.
- Olyan cselekvési terv készítése, amely egyensúlyt teremt a biztonság sürgősségének és a termelési környezetre gyakorolt potenciális hatásnak a között: A biztonság, a termelés és a termelékenység egyensúlyának megteremtése állandó akadály, de a sebezhetőségek kezelésére vonatkozó legjobban meghatározott tervekkel rendelkező szervezetek általában megtalálják a legjobb egyensúlyt.
Rod Soto független biztonsági kutató számára a Shellshock legnagyobb tanulsága az volt, hogy az internet sok sebezhető alkalmazáson alapul, és mindig magában hordozza a szegmensek nagy részének veszélyeztetésének lehetőségét.
“Az ilyen potenciális sebezhetőségek kezelésének módja a jövőben az, hogy a kommunikáció nyitott és átlátható legyen a fejlesztők, karbantartók és biztonsági szakemberek között” – mondja Soto. “Így ha egy ilyen kiterjedt és jelentős sebezhetőséget találnak, az összes érintett fél közötti koordinációval javítani vagy mérsékelni lehet az érintett rendszereket.”
Még abban az esetben is, ha a vállalat sikeresen mérsékli a Shellshock vagy bármely más sebezhetőség kockázatát, nem feltételezheti, hogy a reagálási terve tökéletes. A reagálási tervnek egy élő, lélegző dokumentumnak kell lennie, és gyakran felül kell vizsgálni, hogy a szervezet gyorsan tudjon reagálni a fenyegetésekre.
Végezetül, mint minden támadás utáni forgatókönyv esetében, a terv minden egyes fázisának felülvizsgálata során fel kell tennie bizonyos kérdéseket.
- A terv mely részei voltak sikeresek?
- A terv mely részei nem voltak sikeresek?
- Mit nem tettünk meg, amiről most már tudjuk, hogy meg kellett volna tennünk?
- Mit tanultunk, ami lehetővé teszi számunkra, hogy jobban felkészüljünk a következő sebezhetőségre, ami az utunkba kerül?
A Shellshock lehet, hogy egy régi támadás, de egy támadó számára minden lehetőséget megragad, hogy kihasználja a megfelelő biztonsági higiéniát nélkülöző áldozatokat.
Mi az, amit megtanultunk?