LastPass opublikował aktualizację w sprawie incydentów bezpieczeństwa, które miały miejsce w zeszłym roku.

Jak podaje LastPass, atakujący zinfiltrowali komputer domowy jedno z inżynierów DevOps, wykorzystując podatny pakiet oprogramowania multimedialnego innej firmy. Wstrzyknęli keyloggera do oprogramowania, którego następnie użyli do przechwycenia głównego hasła do konta z dostępem do korporacyjnego Vault’a LastPass’a. Po wejściu wyeksportowali wpisy i foldery udostępnione, które zawierały klucze odszyfrowywania potrzebne do odblokowania opartych na chmurze zasobów Amazon S3 z kopiami zapasowymi Vault’a klientów.

Ta najnowsza aktualizacja dochodzenia LastPass daje nam wyraźniejszy obraz tego, w jaki sposób dwa incydenty naruszenia bezpieczeństwa, które miały miejsce w zeszłym roku, były ze sobą powiązane. Przypomnijmy, ze LastPass ujawnił w sierpniu 2022 r., że „nieautoryzowana strona” uzyskała dostęp do ich systemu. Podczas gdy pierwszy incydent zakończył się 12 sierpnia, firma stwierdziła w swoim nowym oświadczeniu, że cyberprzestępcy byli „aktywnie zaangażowani w nową serię działań rozpoznawczych, wyliczeniowych i eksfiltracyjnych dostosowanych do środowiska pamięci masowej w chmurze, trwających od 12 sierpnia 2022 r. do października 2022 r. 26.02.2022.”

Kiedy firma ogłosiła, że doszło do drugiego naruszenie bezpieczeństwa w grudniu, powiedziała, że atakujący wykorzystali informacje uzyskane z pierwszego incydentu, aby dostać się do jej usługi w chmurze. Przyznali również, że atakującym udało się uzyskać wiele poufnych informacji, w tym z zasoby Amazon S3. Aby móc uzyskać dostęp do danych zapisanych w S3, hakerzy potrzebowali kluczy deszyfrujących zapisanych w „wysoce ograniczonym zestawie folderów współdzielonych w sejfie menedżera haseł LastPass”. Dlatego atakujący obrali za cel jednego z czterech inżynierów DevOps, którzy mieli dostęp do kluczy potrzebnych do odblokowania firmowej pamięci masowej w chmurze.

W dokumencie pomocniczym (PDF), który firma udostępniła (za pośrednictwem BleepingComputer), wyszczególniła dane, do których uzyskali dostęp cyberprzestępcy podczas tych dwóch incydentów. Najwyraźniej kopie zapasowe w chmurze, do których uzyskano dostęp podczas drugiego naruszenia, obejmowały „tajne API, tajemnice integracji stron trzecich, metadane klienta i kopie zapasowe wszystkich danych w sejfie klienta”. Firma nalegała, aby wszystkie poufne dane w sejfie klienta, z wyjątkiem pewnych wyjątków, „mogły zostać odszyfrowane tylko za pomocą unikalnego klucza szyfrowania pochodzącego z hasła głównego każdego użytkownika”. Firma dodała, że nie przechowuje haseł głównych użytkowników.

LastPass wyszczególnił również kroki, które podjął, aby wzmocnić swoją obronę w przyszłości:

• Z pomocą firmy Mandiant wykonaliśmy obrazy kryminalistyczne urządzeń w celu zbadania zasobów korporacyjnych i osobistych oraz zebrania dowodów szczegółowo opisujących działania potencjalnych cyberprzestępców.
• Pomogliśmy inżynierowi DevOps w wzmocnieniu bezpieczeństwa jego sieci domowej i zasobów osobistych.
• Włączyliśmy wieloskładnikowe uwierzytelnianie dostępu warunkowego firmy Microsoft za pomocą dopasowania kodu PIN za pomocą aktualizacji aplikacji Microsoft Authenticator, która stała się ogólnie dostępna podczas incydentu.
• Wymieniliśmy poświadczenia o krytycznym i wysokim poziomie uprawnień, o których wiadomo było, że są dostępne dla ugrupowania cyberprzestępczego; kontynuujemy rotację pozostałych elementów o niższym priorytecie, które nie stanowią zagrożenia dla LastPass ani naszych klientów.
• Rozpoczęliśmy unieważnianie i ponowne wydawanie certyfikatów uzyskanych przez cyberprzestępcę.
• Przeanalizowaliśmy zasoby pamięci masowej w chmurze LastPass AWS S3 i zastosowaliśmy lub zaczęliśmy stosować dodatkowe środki wzmacniające S3:
• Wprowadziliśmy dodatkowe logowanie i alerty w całym środowisku Cloud Storage z bardziej rygorystycznymi zasadami IAM.
• Dezaktywowaliśmy wcześniejszych deweloperskich użytkowników IAM.
• Włączyliśmy zasady, które uniemożliwiają tworzenie i używanie długotrwałych deweloperskich użytkowników IAM w nowym środowisku programistycznym.
• Zmieniliśmy klucze użytkownika IAM istniejącej usługi produkcyjnej, zastosowaliśmy ostrzejsze ograniczenia dotyczące adresów IP i ponownie skonfigurowaliśmy zasady, aby były zgodne z najmniejszymi uprawnieniami.
• Usunęliśmy przestarzałych użytkowników usług IAM ze środowisk programistycznych i produkcyjnych.
• Włączamy wymuszanie tagowania zasobów IAM na kontach zarówno dla użytkowników, jak i ról, z okresowymi raportami o niezgodnych zasobach.
• Przeprowadziliśmy rotację krytycznych certyfikatów SAML używanych w usługach wewnętrznych i zewnętrznych.
• Usunęliśmy przestarzałe/nieużywane certyfikaty SAML używane do programowania, usług lub stron trzecich.
• Zrewidowaliśmy nasz całodobowy system wykrywania zagrożeń i reagowania na nie, dodając dodatkowe zarządzane i zautomatyzowane usługi ułatwiające odpowiednią eskalację.
• Opracowaliśmy i udostępniliśmy niestandardowe narzędzia analityczne, które mogą wykrywać ciągłe nadużycia zasobów AWS.

Jak widać firma podjęła na prawdę szereg dodatkowych akcji- brawo. Natomiast jeden punkt na pewno zwraca moją uwagę. Mianowicie dopiero po incydencie wdrożyli drugi etap uwierzytelnienia w postaci aplikacji MS Authenticator – myślałem, ze tego typu firma ma w standardzie wykorzystywanie kluczy U2F – myliłem się. Co jeszcze zwraca moją uwagę?Mianowicie fakt, żeby nie korzystać z prywatnych urządzeń w celach służbowych i nie mieszać prywaty z zadaniami służbowymi. Czy coś jeszcze? Tak! Aktualizujmy na bieżąco oprogramowanie, z którego korzystamy.

źródło: https://thehackernews.com/2023/02/lastpass-reveals-second-attack.html ;
https://support.lastpass.com/help/incident-2-additional-details-of-the-attack