Ebben a blog bejegyzésben egy penetrációs teszt folyamatát, eredményeit és a teszt utáni munkálatokat mutatom be egy konkrét példán keresztül. Fontos kiemelni a teszt jelentőségét, hiszen nagyvállalati környezetben, elegendő anyagi és humán forrással, előzetes tesztelés mellett is több kritikus és súlyos biztonsági sérülékenységet találtam.
A penetrációs teszt elvégzésére egy nagy európai egészségügyi vállalat kért fel. Az alkalmazás kiemelten szenzitív betegadatokat tartalmaz. A webalkalmazás segítségével az orvosok és egyéb egészségügyi dolgozók nyomon tudják követni a beteg medikációját és kórtörténetét. (Itt megjegyezném, hogy az appnak mobil verziója is van, ami nem volt a teszt része. Az egészségügyi személyzet tabletek segítségével fér hozzá a betegek adataihoz.)
Az előkészületek
Az első meeting alkalmával az alkalmazás egyik vezető fejlesztője bemutatta az appot, ami már első ránézésre is óriási méretű volt. Valamikor az 1990-es évek végén fejlesztették az első verziót és azóta gondozzák. Itt meg kell jegyeznem, hogy az ún. Legacy szoftverek eleve több sérülékenységet tartalmazhatnak, hiszen a fejlesztés idejében a legtöbb biztonsági hibát még nem is ismerte a szakma. Egy ilyen hatalmas alkalmazás esetén a javítás legtöbbször csak részleges, mert folyamatosan cserélődnek a fejlesztők, akik gondozzák a kódot, valamint a biztonsági tudatosság is kérdéses.
A bemutatás után megkaptuk az előző sérülékenység vizsgálat jelentését, ami három évvel a jelen teszt előtt zajlott. Átolvasva az a benyomásom keletkezett, hogy az alkalmazás jól van megírva, csak apróbb konfigurációs hibákra kell számítani, hiszen az előző tesztben is csak 4 sérülékenységet talált a tesztelő, melyek közül egy se volt súlyos.
Megegyeztünk egy két hetes időintervallumban, ami során átnézem a legfontosabb biztonsági funkciókat, a logint, a jelszó visszaállítást, jogosulatlan hozzáférést, input validációt, az adatok átvitelének és tárolásának biztonságát, valamint az infrastruktúrát.
A penetrációs teszt
Két héttel a Kick-off meeting után kezdődhetett a penetrációs teszt. Már az első nap nyilvánvalóvá vált, hogy a feltételezésem nem volt helyes. Hiába tesztelte valaki a webalkalmazást, az tele volt biztonsági hibával. Összesen 23 hibát találtam, amiből 3 kritikus és 5 súlyos volt. Mondanom sem kell, hogy ez egy betegadatokat tároló alkalmazásnál, ami 20-30 éve produktív, ez az eredmény sokkoló.
A teszt után a projektvezető felhívott és hosszan elbeszélgettünk az eredményekről, természetesen ő sem akarta elhinni, hogy ennyi hibával működnek és a korábbi teszter sem találta meg. Nagyon fontos tehát, hogy egy kompetens biztonsági szolgáltót válasszon a vállalkozás, aki kellő szakmai és gyakorlati ismeretekkel rendelkezik a penetrációs teszt elvégzéséhez.
A penetrációs teszt főbb eredményei
Stored Cross-Site Scripting
A Stored Cross-Site Scripting vagy Stored XSS egy input validációs sérülékenység. A fejlesztő nem használt egy listát a felhasználó által bevihető biztonságos karakterekről, így egy támadó akár JavaScript kódot is illeszthet a beviteli mezőbe. Ilyen esetben az alkalmazás azt feltételezi, hogy végre kell hajtani a kódot. A stored jelző azt jelenti, hogy az alkalmazás a felhasználói inputot eltárolja az adatbázisban és minden felhasználó, aki meglátogatja az oldalt, láthatja, tehát áldozattá válhat.
Az XSS remek lehetőséget nyújt egy támadónak a felhasználók munkamenetének ellopásához, ezért ennek a hibának a súlyossága kritikus.
Az alkalmazáson belül korlátozások nélkül lehetett szerkeszteni a betegek adatait, például nevét.
Privilege Escalation
Privilege Escalation során egy felhasználó több jogosultságra teszt szert, mint szabadna, ez lehet horizontális (másik felhasználó) vagy vertikális (adminisztrátori jogok).
Az orvosi alkalmazás felhasználói beállításaiban egy apró fül jelezte, hogy az adott felhasználó milyen jogosultságokkal rendelkezik. Arra nem gondolt a fejlesztő, hogy ne mellékelje egy lenyíló listában az összes jogosultságot, amit így a felhasználó szabadon választhatott magának, így percek alatt bárkiből admin lehetett.
Elavult TLS konfiguráció
A TLS, vagy Transport Layer Security a mozgásban lévő (kliens és szerver közötti) adatok titkosításáról gondoskodik. A legújabb verzió a TLS 1.3.
Az alkalmazás SSL 3.0-t használt, ami 2015 óta az Internet Szabvány (RFC 7568) szerint nem biztonságos. Számos ismert exploit ellen védtelenné tette az alkalmazást.
Fájl feltöltés
Az alkalmazás lehetővé tette, hogy a betegadatok közé dokumentumokat töltsön fel a felhasználó, ám azt nem ellenőrizte, hogy milyen fájlt tölt fel valójában. Az script fájloktól egészen az EICAR teszt vírusig minden fájlt elfogadott.
Cross-Site Request Forgery
A Cross-Site Request Forgery, vagy CSRF egy olyan támadás, melynek során a felhasználó aktív munkamenetét használja ki egy támadó. Például egy phishing mail segítségével ráveszi a felhasználót, hogy látogasson meg egy weboldalt és kattintson egy gombra. Mivel a támadó ismeri a webalkalmazást és tudja milyen kérést kell küldeni a szerver felé, ezért a gomb amire az áldozat kattint, ezt a kérést küldi (például jelszóváltoztatás) el. Mivel az áldozat be van jelentkezve az applikációba, ezért a szerver úgy értelmezi, hogy az áldozat küldte a valid kérést.
A penetrációs teszt során CSRF támadás segítségével sikerült megváltoztatni egy adminisztrátor felhasználó e-mail címét és jelszavát, ezzel kizárva őt és átvenni az uralmat az alkalmazás felett.
Végkifejlet
A jelentés kézhezvétele után 2 hónappal sikerült az összes sérülékenységet javítani, valamint ezeket a javításokat validáltam is egy ismételt tesztelés során. A közös együttműködés azóta is tart, rendszeresen végzek penetrációs teszteket a vállalat alkalmazásain és hálózatán.
A fent leírt példán látszik, hogy fontos a penetrációs teszt rendszeres időközönkénti elvégzése, hiszen az idő haladtával új hibák tűnnek fel, amik 10-15 évvel korábban nem kerültek volna be egy jelentésbe.
A penetrációs teszt részletei teljes anonimizálás, valamint előzetes egyeztetés után kerülhettek a blog bejegyzésbe.