Feltörték a OneLogint, felhasználói adatok is veszélybe kerültek
Titkosított felhasználói információkhoz is hozzáférhettek a OneLogin rendszerét feltörő ismeretlen támadók. A vállalat már dolgozik a tűzoltáson, az érintettekkel és a hatóságokkal is felvette a kapcsolatot.
Adatszivárgás áldozata lett az egyszeri bejelentkeztetéssel (Single Sign-on, vagy SSO) foglalkozó OneLogin. A vállalat információbiztonsági igazgatója, Alvaro Hoyos blogposztban számolt be róla, hogy a illetéktelen hozzáférést észlelt rendszerében, amelyet a felfedezést követően a cég blokkolt, jelentett a hatóságoknak, kivizsgálásán pedig egy független biztonsági céggel közösen dolgozik. A OneLogin felvette a kapcsolatot az érintett ügyfelekkel, akiket tájékoztatott az incidensről, illetve az adataik biztonságba helyezéséhez is tett javaslatokat - nyilvánosan ugyanakkor nem túl bőbeszédű az esettel kapcsolatban.
Pedig kifejezetten súlyos behatolásról van szó: a támadóknak sikerült hozzáférést szerezniük a vállalat adatbázisaihoz, amelyek a felhasználókról és alkalmazásokról tárolt adatok mellett titkosítási kulcsokat is tartalmaznak - a cég szerint nem kizárt, hogy a behatolók érzékeny felhasználói adatok titkosítását is feloldhatják, és hozzáférhetnek azokhoz. Hogy ez pontosan milyen információkat takar, a cég nem közölte.
Nagy pénz, nagy szívás: útravaló csúcstámadó IT-soknak Az informatikai vezetősködés sokak álma, de az árnyoldalaival kevesen vannak tisztában.
A nyomozás eddig eredményei alapján az ismeretlen támadók hozzájutottak egy olyan AWS kulcskészlethez, amellyel az AWS API-n keresztül be tudtak jutni a OneLogin infrastruktúrájába, és hozzáférhettek a vállalatnál tárol adatokhoz. A behatolás március 31-én éjjel 2 óra környékén történt, a cég személyzete pedig reggel 9 felé lett figyelmes a szokatlan adatbázis-tevékenységre. Az illetéktelen hozzáférést percekkel az észlelés után sikerült elvágni, előtte azonban a támadók sok érzékeny információt megszerezhettek.
A OneLogin által a támadásban érintett ügyfeleknek kiadott elővigyázatossági lépések sora nem merül ki egy jelszó változtatásban, ahogy az Ars Technica is idézi, a határozott javaslat szerint a szolgáltatást használóknak többek között érdemes késlekedés nélkül új tanúsítványokat generálni az SAML SSO-t használó alkalmazásaikhoz, új kulcsokat generálni a korábbi API- és OAuth API-kulcsok helyett, új directory tokeneket generálni, új asztali SSO tokeneket és belépési azonosítókat létrehozni és felhasználóik számára kötelező jelszócserét indítani.
A vállalatnak egy éven belül ez a második jelentős biztonsági fiaskója, tavaly augusztusban egy bug miatt a Secure Notes szolgáltatásában normálisan titkosítva tárolt jegyzetek láthatóvá váltak a cég naplózórendszerében - amelyhez aztán egy behatoló sikeresen hozzá is jutott. Ekkor a felhasználói fiókok nem kerültek veszélybe.