fbpx
18máj, 2021
0Comments
featured-image

Kódolt probléma

Manapság nincs olyan hét, hogy ne lenne a friss hírek közt egy kibertámadásról szóló, és emiatt már az átlagember is megtanult olyan kifejezéseket, mint sérülékenységek, biztonsági rések – vagyis a szoftverek azon hibái, amit a támadók kihasználva elérhetik a céljaikat: adatok, információk megszerzését, rendszerek módosítását. Aztán persze ezeket – jó esetben gyorsan, de nem kapkodva – kijavítják. De miért nem csinálnak rögtön biztonságos rendszereket?

1987-ben az NSA – az amerikai elektronikus hírszerzésért (és támadásért) felelős ügynökség – kölcsönkérte az USA kevésbé híres, kettes számú nukleáris kutatóintézetének egyik szakértőjét. Bár a szépen csengő, de annál bajlósabb, nukleáris téllel fenyegető évtizedeket hozó Manhattan projekt szülőhelyéhez, az új-mexikói Los alamos-hoz képest ismeretlen Sandia National Lab neve semmitmondó, az atombomba fétissel megáldottak tudják, hogy legalább olyan fontos helyszín. Az itt dolgozó mérnökök feladatai közé tartozott többek közt a nukleáris arzenál működésének biztonságát garantálni, ebbe beleértve az egyre bonyolultabb rendszerek szabotázs elleni védelmét, illetve a lehetséges szabotázsok felderítését, ami tekintve az egyre inkább chipekkel átszőtt vezérlést egyre inkább jelentette a szoftverek vizsgálatát. A fent említett szakértő úr úgy vélte, hogy mivel az USA folyamatosan kutatja a szovjet rendszerek abuzálási lehetőségeit, joggal feltételezhető, hogy az elvtársak sem tesznek másként odaát – ezt egyébként nagyon jól tippelte. Arra is rájött, hogy a chipekbe komplex funkciókat költöztető szoftverek támadásával gyakorlatilag láthatatlanul lehet egrecíroztatni ezeket a rendszereket. Az ezen a téren elért eredményei juttatták el aztán az NSA-hez, ahol rögtön a belépője részeként megkérdezte a téma ottani szakértőit, hogy mekkora az a komplexitás, ami mellett még garantálható szerintük egy szoftver működésének teljes körű ismerete – vagyis hogy azt, és csak azt tudja és hajtja végre, amire a tervezők eredeti szándékai szerint hivatott. A helyi guruk válaszukban tízezerben határozták meg azon kódsorok számát ami mellett még biztosan vállalható a kitétel, és százezerben ahol már biztosan nem. Ekkor James Gosler – a Sandia hacker-e – megmutatta nekik azt a háromezer sorból álló kódot, amit neki sikerült úgy módosítani, hogy azt az erre felkent kiértékelő csapat sem fedezte fel.

Ma már nem könnyű találni szumma háromezer sorból álló, önállóan működő programkódot – leszámítva persze a beágyazott rendszereket. A program kódsor egy szapora fajta, a Linux kernel első komplett verziója 176 000 sorból állt, 5 év múlva már 2 000 000 és ma már több, mint 27.8 milliónál tart. A Windows forráskód még ennél is szebben szaporodott, 50 millió sor fölött jár, és akkor zárjuk a számfürdőzést egy kevésbé hétköznapi felhasználású eszközzel: a Pentagon Joint Strike Fighter repcsijének xbox-a is több, mint 8 millió sornyi szellemi terméktől függ. Persze a legtöbb fejlesztő nem operációs rendszereken vagy békefenntartásra fejlesztett támadó eszközökön dolgozik, de egy website vagy egy randi app is kellően komplex és méretes lehet. Ekkora mennyiségű kódban pár biztonsági rést okozó hiba még csak nem is tűnik soknak, miközben egy is elég lehet a katasztrófához.

És akkor meg is érkeztünk a válaszhoz a kérdésre, hogy miért nem készítenek rögtön biztonságos szoftvereket a fejlesztők (ami picit hasonlít a miért nem keressük elveszettnek hitt tárgyainkat rögtön az utolsó helyen kérdésre): egyrészt alapvetően azt készítenek, általában a legjobb tudásuk szerint. Viszont “a legjobb tudásuk” nem erre van csibészeltetve, és főleg az elvárások nem erről szólnak. Általánosan két tényezőből állnak a fejlesztési flipper karjai amik közt a programozó a flippergolyó szerepében pattogni kényszerül: határidő és funkcionalitás. Ez a kettő – a nyilvánvaló gazdasági szempontok miatt – folyamatosan “kiterheli” a fejlesztő csapatokat, így ha minden flottul megy és időben megy flottul, akkor megérkezés van és átadás.

Másrészt a  fejlesztőknek általában nem kell biztonsági szakembereknek is lenni (bár ez talán egyre inkább indokolt lenne) – és az általuk a rendszerekben hagyott – nem szándékosan, de azokba kódolt – hibák, sérülékenységek teljesen radar alatt vannak nekik és nem szakmai hiányosságból fakad. Mint a vakvezető kutya aki nem szúrja ki a kokót – nem ez a dolga.

Ráadásul a biztonsági rések kihasználása sok esetben nem hogy nem triviális, de kifejezetten think-outside-of-box gondolkodást igényel, ami a funkcionalitásra fókuszálás miatt amúgy is meglévő csőlátás mellett nem várható el a fejlesztőktől, ellenben egy ilyenre szakosodott, rubik kockán és ördöglakatokon nevelt kiber ninjának sokszor könnyű terep, de még ha nem is az, ideje van rá bőven. A fejlesztőknek minden rést meg kéne látni – a már emlegetett, tavaszt idéző hatalmasra duzzadó kódbázisban – , a támadóknak viszont elég egyet, szóval eléggé asszimetrikus csatatér.

Viszont valamit kezdeni kellett a problémával, és látszik is, hogy egyre inkább így gondolják a fejlesztő cégek – a biztonságos termék előállítás kapudrogjaként az etikus hackerek szolgáltatásait kezdték el igénybe venni: a késztermék pentesztelését. Ez egy jó gyakorlat, a feltárt sérülékenységekről készített riport tartalmazza a javításra, illetve kockázatcsökkentésre tett javaslatokat, de ez egyrészt többkörös vizsgálatot is indukálhat – jó esetben legalább egy visszamérőt a javítások után – másrészt sosem lehetünk biztosak abban, hogy minden hibát feltárt a teszt. Persze ha egy cég megengedheti magának, hogy bug bounty programot hirdet és az adott cuccot hetekig erőszakolgathatják önjelölt számítósok és valódi szakemberek tucatjai, akkor egyre kisebb vakfolt marad. De ez nem olcsó és sokan nem is feltétlenül komfortosak a terméküket kitenni ilyen jellegű figyelemnek – a biztonság még mindig annyira szenzitív kérdés, hogy nem minden cég csinál szívesen céltáblát a legújabb szoftververziókból.

A pentest utáni nagy lépés a biztonságosabb termék felé vezető úton a biztonságos fejlesztési folyamat – attól függően, hogy kit kérdezünk SDLC: Secure Development Lifecycle VAGY Secure SDLC, ahol az S=software  – bevezetése. Itt már – a nevéből adja – tudatos, fejlesztés közbeni tevékenységekről van szó. Sőt, valójában a technológia, a folyamatok és a szaktudás szokásos threesome-járól. A technológia ezesetben egy biztonságos fejlesztést támogató eszköz, amely menet közben a forráskód statikus vizsgálatával szagolja ki a problémás részeket, mint a sziget K hídján a szekusok a baracklébe öntött pálinkát. Az ilyen eszköz folyamatokba illesztése mellett pedig szükséges a fejlesztő csapat képzése, vagy legalább egy dedikált ember felszekusítása, aki a fejlesztői múltja és képességei mellett a biztonsági problémákat is érti, illetve az azokra adott megoldási javaslatok implementálásban is jártas. Persze úgy a tuti, ha ezek mellett még megtörténik az éles rendszerbe állítás előtt egy penetrációs teszt is.

Az USA nukleáris arzenáljának védelmén edződött fentebbi úr már akkoriban megállapította  a tényt, amitől sajnos azóta sem szabadulhattunk: sosem tudhatjuk biztosan, hogy minden hibát kiszúrtunk egy rendszerben. Ebből következően sosem lehetünk 100%-ig biztosak egy rendszer biztonságában – ennek ellenére erre kell törekedni, ezt minél inkább megközelíteni. És mivel a fejlesztési fázisban a legjobb szándék, akarat, eszköz és a tesztelések ellenére is becsúszhatnak programozott hibák, valamint a szoftvert futtató környezetből adódhatnak még pluszban (konfigurációs, implementációs okokból fakadóan), ezért a Defense in depth attitűdöt érdemes követni: vagyis újabb rétegekkel erősíteni a védelmet. Ha már minden oldalról betörésbiztosnak ítéltük meg a webshop-unkat, akkor biztosak lehetünk benne, hogy valamire nem gondoltunk, és akkor jöhet fölé a következő réteg. Csak egy a példák közül a web application firewall – aka WAF, ami egy dedikált eszköz a webes alkalmazásokat kívülről érő wannabe és valódi hacker támadások elleni védelemre, ami a Servergarden tárhely szolgáltatásának egyik kulcseleme. Egy ilyen megoldás kiékelheti a fejlesztés közben alkalmazás szinten “beépített” biztonsági réseket, jelentősen növelve ezzel az egész rendszer biztonságát.

Szintén a Servergarden kínálatában megtalálható Bitninja alapja egy SIEM rendszer, ami telepítés után rendszerbiztonsággal kapcsolatos információkat gyűjt a szerverekről, hálózati eszközökről és ezek alapján létrehoz egy normál működési profil alapján összelegózott digitális lakmuszpapírt, amitől bármilyen eltérést anomáliaként észlel és így a friss fenyegetések ellen is hatékonyan fel tud lépni.

A 100% hackerproof alkalmazásra, website-ra gondolva mindig  jusson eszükbe a jó kereskedő, aki szerint két fajta törhetetlen poharunk van: az olcsóbb könnyebben, a drágább nehezebben törik.