Ha most egy kattintásvadász híradást szeretnék megfogalmazni egy IT-val foglalkozó felületen, akkor annak címében biztosan beleírnám, hogy “Megtörték a Protont!”. De ezt az apropót használjuk most arra, hogy megvilágíthassam azt az állítást, hogy “amikor IT- és/vagy információbiztonsággal kezdesz foglalkozni, az első és legfontosabb dolgod, hogy magadévá tedd a biztonságkritikus gondolkodásmódot és megismerd az IT security világának működését”. – Ahogyan látni fogod, igen érdekes metszeteket kapunk. Ehhez pedig – a hír mellett, de attól imitt-amott nem kicsit elkujtorogva – néhány meglátást és méginkább tapasztalatot szeretnék hozni a hétköznapokból, és sok szempontból a DevOps Akadémia oldalain kapott visszajelzések alapján.

Megtörték a Protont! Is!

• A Sonar Research csapata kritikus sebezhetőséget fedezett fel több titkosított e-mail megoldásban, köztük a Proton Mailben, a Skiffben és a Tutanotában.
• Ezek a privacy-orientált email szolgáltatások végpontok közötti titkosítást biztosítanak, így a kommunikáció lehallgathatatlanná és biztonságossá válik az üzenetek továbbítása és tárolása közben.
• A hibák (findings) a webes (böngésző alapú) klienseket érintik, ahol az üzeneteket sikeresen fejtették vissza a támadás során. A mobil alkalmazásokat nem érinti.
• A támadás lehetőségének gyökere egy Cross-Site Scripting (XSS) sérülékenység jelenléte volt.
• A biztonsági rések lehetővé tették a támadók számára, hogy a felhasználó e-mailjeit ellopják és levelet küldjenek a nevében, azaz hitelesen kiadják magukat az áldozatoknak.
• Csak a Proton Mail esetében közel 70 millió felhasználó volt veszélyben.
• A problémát kijavították, és nincsenek jelei annak, hogy rosszindulatú támadók kihasználták volna a sebezhetőséget, amíg annak lehetősége fenn ált.

Eddig tart az átlag hírfogyasztó számára is releváns összefoglaló.

Az majd megvéd!

Emeljük ki, hogy a “Proton sztori” esetében egy XSS alapú támadásról beszélünk. Ha jól emlékszem, közel fél éven keresztül, 10+ képzésben és nagyságrendileg 25-30 órában (a már szerkesztett anyag ennyi) tárgyaltuk a webalkalmazások sérülékenységeit itt a DevOps Akadémia etikus hacker tanmenetében. Ezt azért fontos megemlíteni, mert ennek kapcsán tudok felvázolni egy gondolatmenetet.

Bár a képzéseinken jellemzően IT ismeretekkel már rendelkező kollégák vesznek részt, ahogyan haladtunk végig a webes sérülékenységeken és hoztam a példákat rájuk (XSS, CSRF, SQL injection, LFI, RFI, stb.) folyamatosan volt három visszatérő megjegyzés az élő képzések chat ablakaiban.

• “Ezek a támadások és a bemutatott demók elavultak, manapság nem működnek.”
• “Ez ellen a *** megvéd!” – Tetszőlegesen behelyettesíthető: WordPress, CloudFlare, egyéb CMS vagy add-on neve, Java, PHP, stb.
• Miért csak ezeket az “egyszerű”, böngésző alapú alkalmazásokban fellelhető sérülékenységeket tárgyaljuk?

Ezzel a három megjegyzéssel van egy apró gond. Egytől egyig hamis állításból indulnak ki. Még a harmadik is, amely egyébként kérdésként került sorolásra.

• Ezek a sérülékenységek és a kihasználásukra hozott példák archetípusok, amelyekkel minimálisan képben kell lenned. Etikus hackerként nem pusztán ezek jelenlétét fogod vizsgálni, hanem ezek (és további típusok) kombinációiban van lehetőséged a sérülékenységeket fellelni. Fejlesztőként vagy üzemeltetőként az a minimum, hogy ezek lehetőségeit ismered. Ráadásul ez “csak” az első 20-30 óra…
• Az csak egy mítosz, hogy bizonyos elterjedt, jónevű, megfelelően karbantartott eszközök (a programnyelvektől, a keretrendszereken át, az add-onokig és extensionökig) mindig minden ellen védelmet kínálhatnak. Ezt engedjük is el. Gyakran ők maguk hozzák be a sebezhetőséget az infrastruktúrádba. A WP kiegészítői legendásak ennek terén, de ugye ott volt nekünk a log4j esete is, ha csak egyet szabad említeni.
• Ha ezekbe a képzésekbe, példákba és a látott demókba csak egy egyszerű “weboldal” sérülékenységeit vagy képes felismerni, egészen biztosan alakítanod kell a biztonságkritikus látásmódodon (vagy a technikai ismereteiden). Tényleg csak a tömör példa kedvéért (hiszen messze még az irományom vége) egy LFI jellegű támadás nem pusztán a PHP include() lehetősége mentén nyílik ki, hanem bármely más programnyelv hasonló, például read() funkcióján keresztül lehetőséget adhat állományok tartalmának illetéktelen olvasására. Az XSS és az SQL injection az egyik leggyakrabban felbukkanó “találat” a vizsgálatok során. Böngésző, vastag-, vagy vékonykliens ilyen szempontból majdhogynem egyre megy.

A rossz hír, hogy valaki, valamit, valahol el fog rontani.

Bevehetetlen erődök

Nemrégiben, egy kezdő etikus hackereknek tartott élő tanfolyamon (ami felvételről elérhető) igyekeztem megvilágítani mi az a gondolkodásmód amit feltétlenül magaddal kell hoznod ha offensive security vagy auditor pályára készülsz. Ebből az első és legfontosabb: bevehetetlen erődök nem léteznek.

Ott és akkor egy pénzügyi intézmény példáját hoztam, ahol a kezdő pentester / etikus hacker / auditor egy szakmai és felügyeleti elvárásoknak történő megfelelőségekkel, a legmodernebb technológiákkal és magas színvonalú megvalósítással megerősített erődítménnyel találja szembe magát. Valljuk be, ez a kép egy kezdő számára rémisztő lehet, hiszen ezen kellene valahogyan fogást találnia. Azonban ez az erődítményről szóló állítás, ilyen formában hamis. Kizárólag olyan módon lenne igaz, ha minden egyes tagmondatában elhelyeznénk a “jó esetben” kifejezést, ami viszont majdhogynem megfordítja a mondat jelentését, és a nézőpont tekintetében máris könnyebb fogást találni rajta. Az elvárásoknak “jó esetben” megfelelő. “Jó esetben” a legmodernebb technológiákat felvonultató. “Jó esetben” magas színvonalú megvalósítás.

Nyilván ez a gondolatmenet leképezhető az olyan szolgáltatókra is, mint a jelen ügyben érintettek, akik egyébként brandet építettek biztonsági megvalósításaikra és hozzáértésükre. Sőt, valójában minden egyes szervezetre aki informatikai megoldásokat használ vagy szolgáltat. A gyakorlatban pedig mindenkire.

Talán már említettem: valaki hibázni fog. De ha nem, akkor valamilyen érdek (pl. pénzügyi) erősebb lehet. Ugyanott vagyunk.

Ezer szempár

A Proton által fejlesztett megoldás(ok)nak van egy nagyon fontos aspektusa. A forráskódjaik nyíltak, mindenki számára elérhetőek. Ilyen módon pedig a szemlélődő közönség / közösség bármikor betekintést nyerhet, kritizálhat, megköpködheti, észrevételezheti, vagy ha hibát, esetleg sérülékenységet talál, akkor akár ki is használhatja azokat. Ez az, amit “ezer szempár” effektusként ismerünk.

Ez most akkor hoz, vagy visz a konyháról? A kérdésen el lehet merengeni egy Unicum-sör kombó fölött, azonban manapság egyetértünk abban, hogy az “open source” szoftverek biztonságára messzemenőkig pozitívabb az a hatás amely a kódsorok publikussá tételével jár. Nem mellesleg így – a szabad licencelésnek köszönhetően – kerülnek a megoldásaik más szolgáltatások alá is.

Vegyük észre, hogy a Solar Research blogbejegyzése szerint is a kód publikálása kellett ahhoz, hogy a sérülékenységet a kutatói kiszúrják. A hiba javítva lett, a felfedezés pedig ezután került publikálásra.

• 2022-06-03 – Megküldték a riportot a Proton Mailnek
• 2022-06-15 – A Proton Mail közzétette a fixet a publikus repóban
• 2022-06-28 – A Proton megítélt $750 bug bounty-t
• 2022-07-06 – A javítás élesítésre került a production rendszereken
• 2023-05-10 – Az eredményeket technológiai oldalról prezentálták a Black Hat Asia rendezvényén
• 2023-08-05 – A Sonar Research publikálta az említett cikkét

A híradás azt is tartalmazza, hogy “nem találtak olyan jelet, ami arra utalna, hogy rosszindulatúan kihasználták volna a sérülékenységet”. Ez azt jelenti, hogy biztosan nem használták ki? Soha, senki? Nem. Ez azt jelenti, hogy minden, a pozitív és etikus ügymenetben érdekelt fél a megfelelő módon járt el, és nem megállapítható, hogy volt-e olyan szereplő aki ebben nem működött együtt. Tudunk ennél többet tenni?

Biztos, hogy a nagyvilág összes repójában hibátlan kódok vannak? Dehogy! Oké, de ezeket a réseket akkor bárki megtalálhatja? Ezért kell zártan kezelni a forráskódokat? Nem, az elsősorban üzleti érdek. Másodsorban nyilván szolgálhatja pármillió sor spagettikód elfedését is. Na és az jobb?

Tökéletes kód létezhet, ezt onnan tudjuk, hogy a lottó ötöst is el szokták vinni. Azok a bizonyos nagy számok! Ugye?

Gyarlóság

Mondjuk, hogy van egy szervezet, amely ténylegesen igyekszik előtérbe helyezni és kiemelten kezeli a biztonságot. Semmi kifogás, semmi kibúvó a jó gyakorlatok és elvárások alól. Megvan a beletett munka és erőforrás. Minden szakmai és felügyeleti elvárás megáll. A legjobb szakembereket és technológiai megoldásokat vonultatják fel. Nem fogunk rést találni a pajzson?

Az IT biztonság területén (igazából minden más technológiai téren is, csak nem akarok hitkérdést csinálni belőle) el kell fogadnunk a tényt, hogy “ember tervez, ember végez”. Az első rézdarabtól, az infrastruktúrákat működtető protokollokon és a programnyelvek fejlesztésén át, az operációs rendszereken, illetve mindennemű technológiai és szabályozó keretrendszereken keresztül, a felhasználói alkalmazásokig.

Vannak emberi tulajdonságok és állapotok – a lustaságtól a hozzánemértésen át a másnaposságig – amelyekre nagyszerű összefoglaló kifejezés lehet a “gyarlóság” (csak hogy ne kelljen végtelenségig sorolnom).

Igen, még velem is megesik. Mondanám, hogy biztosan van olyan akivel nem, de nem akarok hülyeségeket beszélni. Az állásinterjún mindenki “terézapa”.

Itt lenne néhány kérdésem.

Fejlesztőként soha nem hagytál bent egyetlen karakternyi oda nem illő kódot sem? Üzemeltetőként soha nem siklottál el semmi fölött? Hálózatosként biztos, hogy minden check box és minden CLI argumentum a megfelelő módon került a helyére? Felelős információbiztonsági vezetőként tuti, hogy mindenre elő tudod rántani a papírt, és biztos lehetsz benne, hogy az úgy is működik a szervezetednél ahogyan le lett körmölve?

Második kérdésem: igazam van, vagy igazam van amikor azt mondom, hogy a fentiekre jó lelkiismerettel kimondva csak egyetlen igaz válasz létezik. Ha más nem, mindenki volt nullakilóméteres munkavállaló, magyarul kezdő, corporate szlengben junior. Vagy másnapos. Vagy egyéb oka volt? Sietség? Házassági évforduló? Projektzárás? Lustaság? Kimerültség? Családi problémák? Túlterheltség? 15 éves a konyhaszekrény? Bla, bla-bla-bla, blablabla, bla-bla… Mindegy, l3x@rom…?

Biztos vagy benne, hogy a szervezetednél minden IT-s, minden egyes nap nyugodtan hajtja párnára a fejét?

Ha IT-val foglalkozol emlékszel mikor motoszkált utoljára a fejedben, hogy “hááát oda még kellett volna az a beállítás”, “azt a néhány kódsort elegánsabban is meg lehetett volna írni”, “mégiscsak meg kellett volna győzni a pénzügyet arról a tűzfalról”, vagy bárminek a kapcsán: “hát azt jobban is meg lehetett volna csinálni.”

De se’ gond! Nyugi, csak aznap ennyire eleven a gondolat. Mikor a munkából hazafelé menet kinyomod a céges telefont akkor már sokkal könnyebb. Lefekvés után az éjszaka csendjében még eszedbe jut, de holnapra majd elmúlik, mert jön az új feladat, lesz más amin pörögni kell, és lesz valaki vagy valami ami nyomasszon. Lassan a ködbe vész. Meg amúgy is, az a hülye cég megérdemli, mert csak ennyit emeltek…

A mulasztás pedig – száz másik kolléga évek alatt hasonlóan elhelyezett apró kicsi bombájával egyeütt – ott ketyeg a szervezeted infrastruktúrájának testén.

Szép álmokat!

Hoppá!

Legyen az a felvetésünk, hogy egy közel tökéletes szervezet, közel tökéletes munkavállalói építették a biztonságot. Na, ezzel a mondattal el is szpojlereztem… Oké, de most mondjuk azt! A vállalati kultúrából hiányzik a lustaság és a másnaposság is. Ismét, hogy ne kelljen sorolni: egyszerűen hiányzik a gyarlóság a szervezetből. Tökéletesen képzett, 20+ év tapasztalattal dolgozó szakemberek viszik az IT területeket, legyen az business vagy support.

Most képzeljünk el egy check boxot. Igen egy egyszerű négyzetet amit egy random kezelőfelületen be lehet ikszelni. Ha kipipálod kiiktatja egy sérülékeny protokoll működését, de az arra épülő megoldásokat innentől nem tudod használni. Nyilván van lehetőséged mérlegelni, hogy a folyamataidhoz szükséged van-e arra a protokollra, és ha igen akkor a vállalt kockázat milyen arányban áll a biztosított lehetőségek előnyeivel.

Most pedig képzeljük el a lentebb soroltakat egymástól függetlenül, vagy akár egyszerre…

• A gyártó ezt elfelejtette leírni az upgrade dokumentációjában ahol ez a lehetőség megjelent.
• A gyártó kiküldte a disztribútornak, hogy legyen szíves ezt lekommunikálni, de valahol elsikkadt a dolog.
• A szervezet illetékes szakembere (20+ évvel a háta mögött) épp szabadságon volt és visszatérve “elveszett” a mail a másik 1000 között.
• Épp váltás volt a pozícióban és bár a tökéletes munkavállalót egy másik tökéletes váltja, még pár hétig a rendszerrel és a szervezettel ismerkedik, de (mivel tökéletes) pár hét múlva majd odaér, hogy ezt az információt átvegye és megfontolja, a boxot pedig majd benyomja ha úgy lesz megítélve.

Csakhogy a sérülékenységet kihasználó kampány már dül az interneten.

Nyilván tudnám még sorolni. Mit gondolsz, hasonló anomália hányszor eshetett meg eddig a szervezetednél? Nem konkrétan ez, hanem hasonlóan banális együttállás. Ez egy sok milliós felvetés. A zero-day problémakörét pedig most még nem is tárgyalom túl. Az egyik feloldása épp a fenti példában van “elrejtve”. Hoppá!

A leggyengébb láncszem

Akik kicsit többet láttak már a biztonsági, de akárcsak az IT szakmából (vagy legalábbis beültek egy információbiztonsági tudatosságot fejleszteni hivatott képzésre), itt és most várhatják, hogy ezzel a címszóval – “a leggyengébb láncszem” – a korábban sorolt emberi tényezőkre visszavezethető veszélyforrások mellett még elő fogok jönni “Józsival” és “Marikanénivel”, akik az IT tökéletlen működésének hullámain evickélve nyitnak ki biztonsági réseket, illetve válnak a humán alapú, social engineering támadások céltábláivá. Jogos! Oké, akkor ezt le is tudtam.

Most fogalmazzunk inkább úgy, hogy bár már-már közhelyes, hogy ha egy szervezet (de akár alkalmazás, szerver, infrastruktúra – igazából bármilyen IT megoldás) védelmének részegységeit egy lánc szemeiként értelmezzük, akkor annak biztonsága pusztán olyan erős, mint a leggyengébb láncszeme. De ettől még igaz. Ráadásul ezt együtt kell értelmeznünk egy másik vonatkozó mondással (legalábbis én gyakran említem összefüggésében): “A víz is arra folyik amerre a legkönnyebben utat talál”.

A kis Igor, Abdul, Chan, meg manapság már Ronaldo is, no meg a többiek, nem fognak fejjel rontani az AI alapú rendszereinknek, és nem a tűzfalnak mennek neki légkalapáccsal. Egyetlen pontot fognak keresni, és ha létezik meg is fogják találni. Ott pedig beszökik a víz.

Kérem szépen, nekem kifogásom van

Igen, a Proton sztoritól indultam. Semmi különös, a Proton is és a sztori is jól van így. Külső szemlélőként a legoptimálisabb forgatókönyv valósult meg. Nincs miért szégyenkezniük. Sem a szervezetet, sem a felhasználókat, sem a brandet nem érte csapás. Én voltam aki kicsit elkujtorgott. Nem hozok rá kifogást, a fentebb soroltak közül szabadon választható. De néhány kérdést még engedj meg nekem.

Te is ilyen egyszerűen meg fogod úszni? “Szerencséd” lesz? A te szemedben “Isten végez”?

Lesz egy jó kifogásod?

Nota bene, árvíz van!