A helpdesk megszemélyesítése ma már olyan hitelesítő adatokat eredményez, amelyek a jelszó-visszaállítást is túlélik

A hívás Teamsen érkezik. A megjelenő név alapján úgy tűnik, mintha az IT-részlegtől keresnék. A vonal másik végén egy türelmes, segítőkész ember jelentkezik, aki arra kéri a munkatársat, hogy indítsa el a Quick Assist alkalmazást, mert szeretné megoldani a számítógép lassú működését. A legtöbb alkalmazott számára ez egy teljesen hétköznapi helpdesk-beszélgetésnek tűnik. A Microsoft november 2-án ismertetett támadási kampányában azonban éppen ez volt az első lépés egy olyan tartományi hitelesítő adat megszerzéséhez, amely minden jelszócserét túlél.

A SC Media által is ismertetett, a The Hacker News beszámolójára támaszkodó biztonsági figyelmeztetés két, hasonló forgatókönyv szerint végrehajtott behatolást mutat be. Az egyik esetben a támadók informatikai ügyfélszolgálati munkatársnak adták ki magukat, és rávették az alkalmazottakat, hogy indítsanak Quick Assist munkamenetet. Ezután távoli hozzáféréssel kihasználták az Active Directory Certificate Services (AD CS) egyik sebezhető tanúsítványsablonját (ESC1), és privilegizált fiókok nevében igényeltek tanúsítványokat. A másik esetben a PetitPotam módszerrel kényszerítették hitelesítésre a tartományvezérlőt, majd egy ESC8 típusú továbbítási támadással megszerezték a tartományvezérlő tanúsítványát. A Microsoft ajánlásai rövidek és egyértelműek: a támogatási kéréseket belső kommunikációs csatornán keresztül kell ellenőrizni, meg kell szüntetni a szükségtelen tanúsítványigénylési jogosultságokat, és engedélyezni kell az Extended Protection for Authentication (EPA) funkciót a webes tanúsítványigénylési végpontokon.

Ez a történet röviden. De érdemes egy pillanatra megállni annál, hogy valójában mit is szereztek meg a támadók.

A hitelesítő adat, amely a jelszócserét is túléli

Amikor egy szervezet felismer egy ilyen jellegű kompromittálódást, az első reakció általában a jelszavak visszaállítása és a munkamenetek érvénytelenítése. Ez szükséges lépés, de a már kiadott tanúsítványt nem teszi érvénytelenné.

Az AD CS által kibocsátott tanúsítvány önálló hitelesítő eszköz. Segítségével a megnevezett felhasználó vagy számítógép jelszó nélkül is hitelesítheti magát, és a tanúsítvány mindaddig érvényes marad, amíg le nem jár, vagy kifejezetten vissza nem vonják. Az ESC1 esetében egy olyan tanúsítványsablon tette lehetővé a támadást, amelynél az igénylő maga adhatta meg a tanúsítvány alanyának nevét. Így a támadó egy privilegizált fiók nevében igényelhetett tanúsítványt.

A nyilvánosan elérhető szakmai útmutatók egyértelműek: ezek a támadási módszerek nem szoftverhibákon, hanem hibás konfigurációkon alapulnak, ezért nincs hozzájuk kiadható javítócsomag. A megoldás az üzemeltetési gyakorlatban keresendő: fel kell tárni a hibásan konfigurált sablonokat, vissza kell vonni a szükségtelen igénylési jogosultságokat, és ellenőrizni kell a korábban már kibocsátott tanúsítványokat.

A legtöbb olvasó számára az utolsó mondat a legfontosabb. Ha egy tanúsítványt privilegizált fiók nevében igényeltek, nem feltételezhető, hogy az incidens véget ért a jelszó megváltoztatásával. A tanúsítvány továbbra is használható hitelesítésre mindaddig, amíg valaki meg nem találja és vissza nem vonja. Ez a keresés nem történik meg automatikusan: ahhoz az is szükséges, hogy az identitáskezelésért felelős csapat tudja, mit kell keresnie.

A helpdesk-azonosítás a valódi védelmi kontroll

Fontos, hogy a munkatársakat megtanítsuk az ilyen távoli hozzáférési kérések visszautasítására, de a teljes kockázatot nem lehet kizárólag rájuk hárítani.

A középvállalatok többségénél az első vonalas informatikai támogatást egyetlen munkatárs vagy egy kisebb csapat látja el, a Quick Assist pedig teljesen legitim, mindennapi eszköz lehet. Ha az egyetlen védelmi intézkedés egy évente egyszer megtekintett kiberbiztonsági tudatossági videó, akkor olyan döntési felelősséget helyezünk a felhasználóra, amelyet valójában egy megfelelő eljárásnak kellene kezelnie.

A hatékonyabb védelem az azonosítási folyamatban rejlik: minden Teamsen, telefonon vagy chaten érkező távoli hozzáférési kérést ellenőrizni kell egy létező hibajegy vagy vezető által jóváhagyott visszahívás alapján, még mielőtt a munkatárs elindítaná a Quick Assist alkalmazást.

Itt válik igazán hasznossá a biztonságtudatossági képzés. Egy menedzselt kiberbiztonsági tudatossági program ugyanolyan életszerűen szimulálhatja az informatikai ügyfélszolgálat nevében érkező hívást, mint egy adathalász linket tartalmazó e-mailt. A képzés során azt a konkrét mondatot is begyakorolhatják a munkatársak, amellyel udvariasan visszautasíthatják a gyanús kérést:

„Felhívom az ügyfélszolgálatot a hivatalosan közzétett telefonszámon, és visszaellenőrzöm a kérést.”

Ez nem egy szabályzatból kiragadott mondat, hanem egy olyan konkrét reakció, amely éles helyzetben is segíthet a helyes döntés meghozatalában.

Fontos, hogy az eljárás mindkét oldalon működjön. Ha egy munkatárs kezdeményez hívást, az ügyfélszolgálatnak kell ellenőriznie az azonosságát. Ha viszont az ügyfélszolgálat keresi meg a munkatársat, akkor neki kell visszaellenőriznie a hívó fél személyazonosságát. A hívószám kijelzése és a Teamsben megjelenő név önmagában nem bizonyítja a hívó fél kilétét.

A tanúsítványinfrastruktúra valószínűleg régebbi, mint a jelenlegi csapat

A támadási kampány nehezebben kezelhető része egy olyan szolgáltatást érint, amelyet sok hasonló méretű szervezet évekkel ezelőtt állított üzembe, majd később már nem fordított rá kellő figyelmet.

Az AD CS-t gyakran azért telepítették, hogy tanúsítványokat biztosítson például a Wi-Fi- vagy RDP-kapcsolatokhoz használt számítógépek számára. Az a munkatárs pedig, aki annak idején ismerte a sablonok működését és konfigurációját, azóta talán már el is hagyta a vállalatot.

A tanúsítványsablonokhoz idővel egyre több igénylési jogosultság társulhat, miközben már senki sem emlékszik arra, hogy ezekre eredetileg miért volt szükség. Az ESC1 feltétel általában két kérdésen múlik: ki jogosult tanúsítványt igényelni, és az igénylő megadhatja-e a tanúsítvány alanyának nevét.

Ezek a problémák egy teljes PKI-modernizációs projekt nélkül is feltárhatók, de csak akkor, ha a szervezet az AD CS-t az identitáskezelési infrastruktúra részeként kezeli, nem pedig egy elfeledett háttérszolgáltatásként.

Ha az ügyfélszolgálat a bejárati ajtó, akkor az AD CS a tartalék kulcs. A támadási kampány két eleme itt kapcsolódik össze: a munkatárs engedélyezi a távoli hozzáférést, a támadó pedig eljut egy olyan tanúsítványsablonhoz, amelynek segítségével a számára eredetileg biztosítottnál jóval magasabb jogosultságot szerezhet.

A Microsoft által javasolt védelmi intézkedések nem igényelnek jelentős fejlesztési munkát. Elsősorban konfigurációs módosításokról és egy ellenőrző szkript futtatásáról van szó.

Három ellenőrzési feladat a következő negyedévre

Mielőtt befutna a következő Teams-hívás, egy kisebb infrastruktúra- vagy identitáskezelési csapat három konkrét intézkedést is elvégezhet:

• Az AD CS-tanúsítványsablonok áttekintése: Listázzák az összes olyan tanúsítványsablont, amelyhez igénylési (Enroll) jogosultság tartozik, és jelöljék meg azokat, amelyeknél az igénylő maga adhatja meg a Subject Alternative Name (SAN) mezőt. Egy privilegizált fiók tanúsítványa nem lehet megszerezhető egy olyan sablonon keresztül, amelyet egy átlagos munkaállomás is igénybe vehet.
• Az ügyfélszolgálati azonosítási eljárás kialakítása és tesztelése: Készítsenek írásos ellenőrzési protokollt a bejövő és kimenő támogatási hívásokhoz, teszteljék, majd tegyék minden munkatárs számára elérhetővé. Az eljárás legyen a telefon mellett, ne csak az éves oktatási anyagban.
• A webes tanúsítványigénylés védelmének megerősítése: Engedélyezzék az Extended Protection for Authentication funkciót a webes tanúsítványigénylési végpontokon, és szüntessék meg azokat az igénylési jogosultságokat, amelyek mögött már nincs aktuális rendszerigény.

A támadási módszer mindaddig működőképes marad, amíg a hívás első perce túl könnyű lehetőséget biztosít a támadóknak.

A kockázatért felelős vezető előtt álló kérdés ennél jóval egyszerűbb: tudjuk-e most azonnal, hogy egy átlagos munkaállomásról igényelhető-e tanúsítvány tartományi rendszergazdai jogosultságú fiók nevében?

Ha erre nem tudunk azonnal válaszolni, akkor a következő biztonsági felülvizsgálatnak éppen ezzel a kérdéssel kell kezdődnie.