Naruszenie kodu źródłowego LastPass – opublikowano raport z odpowiedzi na incydent

Jeśli zapowiada się wielka historia tego miesiąca? Naruszenie danych Ubera, gdzie haker miał rzekomo wędrować po sieci firmy współdzielącej przejazdy…

..wielką historią z zeszłego miesiąca było Naruszenie LastPass, w którym atakujący najwyraźniej uzyskał dostęp tylko do jednej części sieci LastPass, ale był w stanie uciec z zastrzeżonym kodem źródłowym firmy.

Na szczęście dla Ubera, ich napastnik wydawał się zdeterminowany, aby zrobić duży, szybki chwyt PR, robiąc zrzuty ekranu, rozpowszechniając je swobodnie w Internecie i drwiąc z firmy krzykliwymi wiadomościami, takimi jak UBER ZOSTAŁ ZHAKOWANY, bezpośrednio na własnych forach Slack i bug bounty:

Wydaje się jednak, że atakujący lub osoby atakujące w LastPass działały bardziej ukradkiem, najwyraźniej nakłaniając programistę LastPass do zainstalowania złośliwego oprogramowania, które następnie wykorzystali cyberprzestępcy, aby złapać się w repozytorium kodu źródłowego firmy:

LastPass opublikował teraz oficjalny raport uzupełniający o incydencie, na podstawie tego, co udało się ustalić na temat ataku i napastników w następstwie włamania.

Uważamy, że artykuł LastPass jest wart przeczytania, nawet jeśli nie jesteś użytkownikiem LastPass, ponieważ uważamy, że jest to przypomnienie, że dobry raport odpowiedzi na incydent jest równie przydatny w przypadku tego, co przyznaje, że nie byłeś w stanie dowiedzieć się, kim byłeś.

Co teraz wiemy

Poniższe zdania pogrubione zapewniają zarys tego, co mówi LastPass:

• Atakujący „uzyskał dostęp do środowiska programistycznego przy użyciu zaatakowanego punktu końcowego programisty”. Zakładamy, że było to spowodowane przez atakującego, który wszczepił na komputer programisty złośliwe oprogramowanie szpiegujące system.
• Nie udało się ustalić sztuczki użytej do wszczepienia złośliwego oprogramowania. To rozczarowujące, ponieważ wiedza o tym, jak faktycznie przeprowadzono ostatni atak, ułatwia zapewnienie klientów, że zmienione procedury zapobiegania, wykrywania i reagowania prawdopodobnie zablokują go następnym razem. Przychodzi mi na myśl wiele potencjalnych wektorów ataków, w tym: niezałatane lokalne oprogramowanie, „shadow IT” prowadzące do niezabezpieczonej lokalnej konfiguracji, pomyłka polegająca na phishingu, niebezpieczne nawyki pobierania, zdrada w łańcuchu dostaw kodu źródłowego, na której opiera się dany koder, lub błędnie otwarty załącznik wiadomości e-mail z pułapką. Czapki z głów dla LastPass za przyznanie się do tego, co sprowadza się do „znanego nieznanego”.
• Atakujący „wykorzystał swój stały dostęp do podszywania się pod programistę, gdy programista pomyślnie uwierzytelnił się za pomocą uwierzytelniania wieloskładnikowego”. Zakładamy, że oznacza to, że haker nigdy nie musiał uzyskać hasła ofiary ani kodu 2FA, ale po prostu użył atak polegający na kradzieży plików cookielub wyodrębnił token uwierzytelniający dewelopera z prawdziwego ruchu sieciowego (lub z pamięci RAM komputera ofiary) w celu podpięcia się do zwykłego dostępu programisty:

• LastPass nie zauważył włamania od razu, ale wykrył i wyrzucił atakującego w ciągu czterech dni. Jak zauważyliśmy w niedawnym artykule na temat ryzyka niejednoznaczność sygnatury czasowej w logach systemowych możliwość określenia dokładnej kolejności, w jakiej zdarzenia miały miejsce podczas ataku, jest istotną częścią reakcji na incydent:

• LastPass fizycznie oddziela swoje sieci rozwoju i produkcji. Jest to dobra praktyka w zakresie bezpieczeństwa cybernetycznego, ponieważ zapobiega przekształceniu się ataku na sieć programistyczną (gdzie rzeczy są nieuchronnie w stanie ciągłych zmian i eksperymentów) przekształcenia się w natychmiastowe naruszenie oficjalnego oprogramowania, które jest bezpośrednio dostępne dla klientów i reszty firmy .
• LastPass nie przechowuje żadnych danych klientów w swoim środowisku programistycznym. Ponownie, jest to dobra praktyka, biorąc pod uwagę, że programiści, jak sugeruje nazwa stanowiska, na ogół pracują nad oprogramowaniem, które nie przeszło jeszcze pełnego przeglądu bezpieczeństwa i procesu zapewnienia jakości. Ta separacja czyni również wiarygodnym, że LastPass twierdzi, że żadne dane ze skarbca haseł (które i tak byłyby zaszyfrowane za pomocą kluczy prywatnych użytkowników) nie mogły zostać ujawnione, co jest silniejszym twierdzeniem niż po prostu powiedzenie: „nie mogliśmy znaleźć żadnych dowodów na to został odsłonięty”. Utrzymywanie danych ze świata rzeczywistego poza siecią programistyczną uniemożliwia także programistom o dobrych intencjach nieumyślne przechwycenie danych, które mają podlegać ochronie regulacyjnej, i wykorzystanie ich do nieoficjalnych celów testowych.
• Chociaż kod źródłowy został skradziony, atakujący nie pozostawił żadnych nieautoryzowanych zmian w kodzie. Oczywiście mamy do czynienia tylko z roszczeniem LastPass, ale biorąc pod uwagę styl i ton pozostałej części raportu z incydentu, nie widzimy powodu, aby nie wierzyć firmie na słowo.
• Przenoszenie kodu źródłowego z sieci deweloperskiej do produkcji „może nastąpić dopiero po zakończeniu rygorystycznych procesów przeglądu, testowania i walidacji kodu”. To sprawia, że ​​LastPass może twierdzić, że żaden zmodyfikowany lub zatruty kod źródłowy nie dotarłby do klientów lub reszty firmy, nawet jeśli atakującemu udało się wszczepić fałszywy kod w systemie kontroli wersji..
• LastPass nigdy nie przechowuje ani nawet nie zna prywatnych kluczy odszyfrowywania swoich użytkowników. Innymi słowy, nawet jeśli atakujący uciekł z danymi hasła, skończyłoby się tak samo posiekaną cyfrową kapustą. (LastPass zapewnia również publiczne wyjaśnienie w jaki sposób zabezpiecza dane przechowalni haseł przed łamaniem offline, w tym za pomocą PBKDF2-HMAC-SHA256 po stronie klienta do solenia, haszowania i rozciągania hasła offline za pomocą 100,100 XNUMX iteracji, dzięki czemu próby złamania hasła znacznie trudniej, nawet jeśli atakujący uciekną z lokalnie przechowywanymi kopiami magazynu haseł).

Co robić?

Uważamy, że rozsądne jest stwierdzenie, że nasze wczesne założenia były poprawnei że chociaż jest to wstydliwy incydent dla LastPass i może ujawnić tajemnice handlowe, które firma uważała za część swojej wartości dla akcjonariuszy…

…ten hack można uznać za własny problem LastPass, z którym należy sobie poradzić, ponieważ w tym ataku nie osiągnięto żadnych haseł klientów, nie mówiąc już o złamaniu:

Ten atak i własny raport z incydentu LastPass są również dobrym przypomnieniem, że „dziel i rządź”, znany również pod żargonem Zero zaufania, jest ważnym elementem współczesnej cyberobrony.

Jak wyjaśnia ekspert Sophos Chester Wiśniewski w swojej analizie niedawny hack Uber, stawką jest o wiele więcej, jeśli oszuści, którzy uzyskają dostęp do kilka Twojej sieci może wędrować w dowolnym miejscu w nadziei uzyskania dostępu do cała kolekcja tego: