LastPass: ilyen egy biztonsági krízis belülről

Átmulatott éjszaka után senki nem szeret hajnali telefonhívásra ébredni - különösen nem arra, hogy az informatikai biztonság egyik igazi celebritása jelentett be biztonsági hibát a hősünk által (is) fejlesztett online szolgáltatás kapcsán. Amely történetesen felhasználók millióinak jelszavait tárolja felhős rendszerében.

Pontosan ez történt március végén, amikor a Google Project Zero híres infobiztonsági szakértője, Tavis Ormandy jelentette a LastPassnak, hogy súlyos biztonsági hibákat talált a szolgáltatásban. A rendszert ma már jelentős részben a LastPasst felvásárló LogMeIn hazai fejlesztői építik, nem csoda, hogy az említett telefonhívás is egy hazai szoftvermérnöknél, Barta Ákosnál csöngött ki.

Előzmények: ahogy arról a HWSW részletesen beszámolt, március végén több komoly biztonsági hibát is találtak a LastPass online jelszókezelőben. A hibát a csapat meglepő hatékonysággal javította, mindössze néhány nap alatt készült el a problémás böngészős beépülők frissítése - messze gyorsabban, mint amit a Project Zero 90 napos nyilvánosságra hozási ideje megkövetelt volna. Mivel ilyen sztorik a budapesti fejlesztői közösségben viszonylag ritkán fordulnak elő, leültünk a budapesti csapat képviselőivel, Barta Ákossal és Komjáthy Szabolccsal - meséljék el ők, milyen volt ezt belülről végigcsinálni.

Maximális prioritáson

A LastPass üzemeltet saját bug bounty programot, amelyen keresztül be lehet jelenteni a szolgáltatásban tapasztalt hibákat, biztonsági problémákat. Amennyiben a csapat úgy dönt, hogy az valóban hiba és tényleges biztonsági kockázata van, akkor jár a jutalom, az igazán súlyosakért 2500 dollárt is kifizet a cég a rendszeren keresztül.

Ormandy bejelentése is az ilyenkor szokásos útvonalat járta végig, először néhány fejlesztő validálta a problémát, megállapították annak súlyosságát és beizzították a már említett telefonos forródrótot. A hibajelentést a csapat maximális prioritással kezelte - a gyakorlatban arra a pár napra minden más fejlesztés leállt, minden érintett fejlesztő kizárólag ezzel a problémakörrel foglalkozott, egészen annak elhárításáig, a korábban betervezett munkákat így ideiglenesen a LastPass-csoport felfüggesztette.

A hiba elhárítására gyorsan összeállt egy, különböző érintett csapatok tagjaiból álló team, amelyben a fejlesztők és üzemeltetők mellett a támogatás, a minőségbiztosítás is képviseltette magát. Erre azért volt szükség, hogy az egyes csoportok között élő maradjon a kommunikáció - így például a support csapat is rálátást kapott a problémára, így az érdeklődő ügyfeleknek pontos információval szolgálhatott a kérdésben és tudott tájékoztatást adni a javítás időpontjára vonatkozóan is.

Machine recruiting: nem biztos, hogy szeretni fogod Az AI visszafordíthatatlanul beépült a toborzás folyamatába.

Első lépésben a csapat a sebezhetőség hatásának minimalizálására koncentrált. Néhány nem-kritikus funkció azonnali lekapcsolásával (egy problémás domén letiltásával) nagyon le lehetett szűkíteni a támadási felületet, így azonnali megoldásként ezt meg is lépte a LastPass-brigád. Ehhez szerencsére vannak a szoftverben beépített kapcsolók, amivel az egyes funkciók egyenként aktiválhatóak-inaktiválhatóak, így ezt könnyen meg lehetett valósítani, a bejelentéstől számítva kevesebb, mint 24 óra alatt sikerült is a közvetlen kockázatot elhárítani.

^{(fotók: LogMeIn)}

A következő lépés pedig a sebezhetőségek kód szintű javítása volt. Ez egy sokkal komplexebb feladatnak bizonyult, sok ponton kellett a kódbázishoz hozzányúlni, a változtatásokat pedig élesítés előtt alapos tesztelésnek is alá kell vetni. Szerencsére a Project Zero csapatával a bejelentés után is aktív maradt a kapcsolat, így egy áthidaló megoldás pont onnan érkezett, amivel nagyon gyorsan, minimális változtatással sikerült javítást eszközölni (ennek műszaki részleteiről korábban már értekeztünk, gyakorló JavaScript-fejlesztőknek viszont ezt is érdemes fellapozni).

Project Zero - celebek az IT-biztonságban

Korábbi cikkünkben mi is hangsúlyoztuk, hogy a LastPass-hibákat nem néhány script kiddie, hanem az internetes biztonság egyik legprofibb csapata, a Google szárnyai alatt működő Project Zero találta. Ez a csapat azzal a (meglehetősen általános) küldetéssel jött létre, hogy emeljen az online szolgáltatások biztonsági szintjén, különös tekintettel a kritikus elemekre, mint az operációs rendszerek, a böngészők - vagy épp az online jelszókezelők.

A javítások kiadásánál azonban komoly problémába ütközött a csapat: míg a Chrome-hoz készült bővítmény frissítése egy óra alatt átfut a Google rendszerén és megkezdődik a sebezhető plugin leváltása, a Firefox és az Opera ennél sokkal-sokkal lassabb és kiszámíthatatlanabb. Ez pedig nagyon veszélyes: a javított verziót a sebezhetővel összevetve potenciális támadók könnyen visszafejthetik az eredeti hibát és megkezdhetik azt kihasználni a még javítatlan platformokon. A csapat ezért felvette a kapcsolatot a böngészőgyártókkal, akik a problémát meglepően nyíltan és segítőkészen kezelték - így sikerült szinkronizálni a három böngésző között a javítás kiadását és minimális eltéréssel frissíteni a beépülőket.

Kiértékelés?

Miután a hibákat sikerült visszaigazoltan elhárítani, és immár állíthatta magáról a szolgáltatás, hogy a világ egyik legjobb biztonsági csapata sem talál már fogást rajta, a csapat nekiállt kiértékelni a szituációt, a rá adott válaszokkal együtt. "Ilyenkor megpróbáljuk felderíteni a hiba gyökerét, anélkül, hogy hibáztatásba vagy ujjal mutogatásba torkollna a dolog" - mondja Barta. "A problémás kódrészletek (ahogy az összes kód) sok kézen, több ellenőrzésen esik át, ezért nem is lenne fair felelősöket keresni, ennél sokkal fontosabb kitalálni azt, hogy hogyan lehet ezt a jövőben elkerülni."

De meg lehetett volna fogni a hibákat? Minden szoftvercégnél komoly kérdés, hogy a megírt kód milyen ellenőrzések (code review) után mehet élesbe, kinek kell azt ellenőriznie, milyen mélységben, mekkora alapossággal. Ezek mindig kompromisszumos döntések, az alapos ellenőrzés általában kevesebb hibát, de visszaeső produktivitást jelent - ezek között kell minden szervezetnek megtalálnia az egyensúlyt. Összességében a kiértékelés arra a következtetésre jutott, hogy a meglévő code review folyamat jól működik, a kérdéses hibákat a mainál sokkal alaposabb átnézéssel sem lehetett volna biztosan kiszűrni.

Ettől függetlenül persze a konkrét hiba tanulságait levonta a szervezet, és például a szoftverarchitektúra oldalán komoly változások jönnek. Itt az egyes modulok közé izolációs réteg kerül, nem lesznek közös változók és közös memória, így egy-egy programhiba hatása jóval korlátozottabb lesz, sokkal nehezebben válik egy tévedés veszélyes sebezhetőséggé.

"A krízis esetén használt belső céges folyamatok élesben jól vizsgáztak" - mondja Komjáthy, a retrospektív elemzés ugyanis ezt a területet is kiértékelte. Ettől függetlenül van néhány pont, ahol lehet javítani azok hatékonyságát. Például az egyik ilyen a belső hibakezeléshez használt Atlassian JIRA módosítása: bekerült külön flag a biztonságkritikus módosításokhoz, amely jelzi a dedikált biztonsági csapatnak, hogy azzal a hibajeggyel kiemelten kell foglalkoznia.

Már félig magyar termék

A LastPass jelszókezelőt még 2015 októberében vásárolta fel a LogMeIn, a kis fairfaxi (Washington DC melletti) startup akkor 110 millió dollárt ért a hazai gyökerű szoftverháznak. A LastPass fejlesztésén azóta már jóval nagyobb szervezet dolgozik, összesen mintegy 90-100 fővel, amit kiegészítenek az értékesítők és a támogatás-ügyfélszolgálat. A fejlesztést több, párhuzamosan dolgozó csapat végzi, ők egyszerre egy-egy komolyabb képesség (feature) elkészítésén dolgoznak - egy ilyen csoport van Fairfaxben, 3 a LogMeIn bostoni főhadiszállásán és 5 a budapesti irodában. Minden csapat "önjáró", vagyis képes a rábízott feladatot saját hatáskörben megvalósítani, ehhez rendelkezik szakértővel minden LastPass-modulhoz (frontend, kliensek, backend, stb.)

Ennyi csapatra szükség is van, ma már a LastPass óriási projektté nőtte ki magát. Van több platformra, több böngészőhöz elérhető bővítmény, ehhez jönnek a mobilalkalmazások (Android és iOS mellett még a Windows Phone is támogatott), plusz ehhez jön az alkalmazásokat kiszolgáló backend. Ez így együtt már jelentős kódbázist jelent, amihez szükség is van a sok fejlesztőre.

A fentiekkel párhuzamosan pedig van egy dedikált infobiztonsági csapat, amelynek kimondott feladata a rendszer biztonságát vizsgálni, az élesbe küldött kódot ellenőrizni, az online szolgáltatás ellen penetrációs teszteket végezni. Ez a csapat rendszeres belső auditot végez, amelynek tanulságai folyamatosan visszakerülnek a végtermékbe. A csapat munkáját külön "bug bounty" program egészíti ki, ez honoráriumot biztosít olyan külső biztonsági szakembereknek, akik a hibákat a LastPassnál jelentik be.