Az Okta platformon felfedezett hitelesítési kockázatok

Egy keddi jelentés szerint a kutatók négy „nagy hatású” biztonsági kockázatot fedeztek fel az Okta identitás- és hozzáférés-kezelési (IAM) platformon.

A kockázatok közé tartozik az egyértelmű szöveges jelszókiszivárgás a SCIM-en – a Cross-domain Identity Management rendszeren – keresztül – a jelszavak és egyéb adatok titkosítatlan HTTP-csatornákon keresztüli megosztása, az alapértelmezett konfigurációk, amelyek lehetővé teszik a rendszergazdák számára, hogy behatoljanak más szervezetek IT-környezeteibe, valamint a változtatható azonosítónapló-hamisítás.

Az ezeket a kockázatokat kihasználó támadók hitelesítési adatokat lophatnak, bizalmas személyes és pénzügyi információkhoz férhetnek hozzá, és megzavarhatják az Okta által kezelt informatikai környezeteket.

Az IAM kockázatai

Az IAM-szoftver megszervezi, hogy egy informatikai környezetben mely személyek milyen erőforrásokhoz férhetnek hozzá. Az Okta-hoz hasonló platformok olyan funkciókat is kínálnak, mint a jelszókezelés és az egyszeri bejelentkezés, ami lehetővé teszi a felhasználók számára, hogy zökkenőmentesen jelentkezzenek be és váltsanak át egyik szoftverkörnyezetből a másikba. Összességében az IAM-ek meglehetősen kényelmesek a felhasználók és a rendszergazdák számára egyaránt.

A nem biztonságos IAM azonban számos hasonló ok miatt kényelmes a támadók számára. Az Oktában újonnan felfedezett kockázatok lehetővé tehetik, hogy hackerek vagy rosszindulatú bennfentesek jelszavakat szerezzenek, átvegyék a rendszergazdai fiókokat, vagy akár egy egész szervezet adatait megsemmisítsék.

Vegyük például a jelentésben felvázolt harmadik kockázatot.

A globális és elosztott szervezetek számára az Okta a csomópont és küllő építészet, ahol az anyavállalat („hub”) felügyeli és szolgáltatásokat nyújt az általa ellenőrzött kisebb független vállalkozásoknak („küllő”). A kutatók azt fedezték fel, hogy egy Okta-beszéd adminisztrátora „megszemélyesítheti a hub bármely fiókját és/vagy a hubhoz csatlakoztatott downstream alkalmazást”. A jelentés felvázolja, hogy ez hipotetikusan hogyan fordulhat elő:

Egy kis céget felvásárolt egy nagy Fortune 500. A vállalat a kis cég Oktáját csatlakoztatta a fő Oktához, amely az alapértelmezett konfigurációval a központjukként működik. A felvásárolt cég feltört adminisztrátora kiemelt rendszergazdai jogosultságokat szerez az Okta központjukban, ha szuperadminisztrátornak adja ki magát, és így teljes, korlátlan hozzáférést kap a vállalat teljes alkalmazás- és szolgáltatásgyűjteményéhez.

A kis cég adminisztrátora hozzáférhet más vállalkozások informatikai környezetéhez – beleértve magát a nagy Fortune 500-hoz tartozót is –, hogy bizalmas adatokat lopjon el vagy semmisítsen meg, vagy az adatokat bármi másra is felhasználja.

Ezek a sebezhetőségek?

A kutatók ügyeltek arra, hogy megállapításaikat „kockázatként” jellemezzék, nem pedig nyílt sebezhetőségként. Amikor megkeresték az Oktát, az Okta kifejtette, hogy „a funkciók a terveknek megfelelően működnek, és nem szabad sebezhetőségként besorolni”. Hogy lehet ez?

Tekintsük korábbi példánkat. A kisvállalati adminisztrátor jogosulatlan hozzáférést kaphat a hubhoz és más küllőkhöz, ha létrehoz egy felhasználót a hub rendszergazdájával azonos azonosítóval. Az, hogy egy óriási hub- és küllőkörnyezetben két felhasználó ugyanazzal a felhasználónévvel rendelkezhet, „szándékos, és célja, hogy megkönnyítse a hozzáférés-szabályozás skálázását a szervezeten belül, miközben a vezérlés hatókörét egy adott küllőre korlátozza”. A gyakorlatban azonban minden szélhámos adminnak kiteszik a hubot.

Az Okta lehetőséget kínál a felhasználónév-kettőzés kikapcsolására, de „ezek a vezérlők alapértelmezés szerint nincsenek beállítva, így a felhasználó a kezdeti beállításoktól elbizonytalanodhat. Az Okta szintén keveset tesz az útmutatóban, hogy elmagyarázza felhasználóinak, hogy jelentős kockázatot jelenthetnek ezek a nem biztonságos alapértelmezett beállítások.”

„Az Okta nagyon jó biztonsági gyakorlattal rendelkezik számos területen” – jegyezték meg a kutatók, hozzátéve, hogy „biztosak vagyunk abban, hogy más IAM-szolgáltatóknál is vannak hasonló problémák”. Tanulmányuk végén tehát azt javasoljuk, hogy a szervezetek proaktív megközelítést alkalmazzanak független biztonsági megoldások bevezetésére IAM-eszközeikhez.