Továbbra is LastPass.
Újabb részleteket közölt a LastPass a tavaly augusztusban őket ért támadásról. Azóta eltelt fél év, lássuk, mi újat tudnak nekünk mutatni - én teljes mértékben le voltam döbbenve, de természetesen az Olvasó úgy érez, ahogy akar.
Tavaly szeptember 8 és 22 között nagy mennyiségű adatot töltöttek le a LastPass által használt AWS tárhelyről. Mivel az már korábban kiderült, hogy a támadó aktivitása augusztusban kezdődött a LastPass rendszerei ellen, nyilvánvalóan ekkor történt valami, ami megelőzte a cég rendszereibe történt behatolást. A LastPass állítása szerint négy DevOps fejlesztőjüknek volt hozzáférése a kérdéses AWS-hez, így gyorsan kiderült, melyiküket támadták meg először. A cég szerint a fejlesztő privát számítógépét fertőzték meg a támadók keyloggerrel. Egy névtelen Ars Technica információ szerint a fejlesztő privát számítógépén a Plex media server futott, amelynek két ismert sebezhetősége van. Mivel az egyik autentikált felhasználót igényel, az nem jöhet szóba, a másik CVE 2018-as sebezhetőség, XXE-vel támadható - könnyű kivitelezni, nem igényel autentikációt és távolról is végrehajtható, 7.7-es CVSS értékeléssel. Tehát a fejlesztő a saját, sebezhető - és már feltört - gépéről érte el a nevezett AWS instance-ot, miközben a sebezhetőségre már volt patch is 2022-ben... Nyilvánvalóan felmerül, van-e BYOD policy a LastPassnél, valamint egyéb, biztonsági policy, amely kimondja: privát géppel nem szabad elérni a céges erőforrásokat? Ha nincsenek ilyenek, akkor egyáltalán: miért foglalkozik a LastPass azzal, amivel? Ha vannak ilyen házirendek, megtörtént-e a felülvizsgálatuk, ha találtak lyukakat közöttük, lefedték-e azokat? Nos, erről nem szól semmilyen közlemény...
Sajnos, van rosszabb is. Tavaly decemberben a cég közölte az üzleti felhasználókkal: ha Federated Login Services-t használnak, nincs teendőjük. A probléma az, hogy a Super Admin fiókokat nem lehet így autentikálni. A decemberi közleménnyel ellentétben a cég most azt mondja: a mesterjelszavak K2-es komponensét is letöltötte a támadó, mivel az része a titkosított biztonsági mentéseknek - amikhez a támadónak viszont kulcsa van. Mondhatnánk, hogy a jelenlegi ismereteink szerint a K1 komponens biztonságban van, csakhogy a K1 az egész tenantra nézve ugyanaz és minden olyan felhasználónak megvan a tenanton belül, aki használja a jelszókezelő szolgáltatást. Tegyük fel, hogy a következő célpontul választott cégnél találnak olyan alkalmazottat, aki "kapható" social engineeringre... vagy netán van egy sebezhető Plex media servere...
Persze, a probléma nem megoldhatatlan, mondhatnánk, csak rotálni kell a K1-et. Igen, a K1 rotálásával minden egyes - a tenantban létező - felhasználót ki kell venni a federationből, majd újra belerakni őket. Öröm az ürömben, hogy a re-federáció rotálja a K2-t is. Ezzel azonban vége is a jó híreknek, amíg ez a re-federáció nem történik meg, a tenant és a felhasználók K1 és K2 komponense ugyanaz marad.
Mindamellett, hogy érdekes megfigyelni, milyen mozaik hogyan illeszkedik a nagy, teljes képbe, számomra az is érdekes, milyen folyamatok, tényezők váltották ki a LastPass jelszókezelő rendszere körüli anomáliákat.
Nyilván a támadásra nem mondható el különösebb szofisztikáltság: OWASP Top 10-ben évek óta ismert támadást szenvedett el a fejlesztő egy olyan, javított sebezhetőségen keresztül, amire már régóta volt javítás, ezután a támadó semmi mást nem csinált, mint amit minden támadó tett volna: vitte a szajrét.
Azt azonban érdemes lenne feszegetni, milyen a LastPassnál a környezet, amiben a fejlesztőknek és egyéb munkatársaknak létezniük kell? Milyen a cégkultúra? Vannak-e minden alkalmazottra nézve kötelező policy-k? Milyen kivételeket alkalmaznak? Mi volt az oka, hogy a fejlesztő a privát számítógépét használta - hanyagság a részéről, vagy a cég részéről (pl. tönkrement a céges gépe és hetek, hónapok óta nem kapott másikat)?
Az én véleményem az, hogy noha technikailag tanulságos a történet, a governance oldaláról nem fogunk megtudni semmit - pedig az legalább olyan fontos része az ilyen eseteknek, mint a technikai.
Coresec
2023.03.02