W ubiegłym miesiącu miało miejsce naruszenie części środowiska deweloperskiego i kodu źródłowego menedżera haseł LastPass. Można uznać, że to wydarzenie nie było szczególnym zagrożeniem dla użytkowników końcowych. Hasła główne i żadne dane przechowywane w LastPass nie zostały przechwycone. Dlatego pod względem wpływu na ogólne bezpieczeństwo przedstawiana sytuacja nie ma większego znaczenia. Natomiast zawsze interesujące są opisy podobnych ataków i reakcje na incydent, który spowodowały. 15 września LastPass zaktualizował swoje oświadczenie z sierpnia dotyczące incydentu.
Przede wszystkim atakujący uzyskał dostęp do stacji roboczej z użyciem poświadczeń programisty. Konto używało uwierzytelniania wieloskładnikowego.
Our investigation determined that the threat actor gained access to the Development environment using a developer’s compromised endpoint. While the method used for the initial endpoint compromise is inconclusive, the threat actor utilized their persistent access to impersonate the developer once the developer had successfully authenticated using multi-factor authentication.
O ile nieautoryzowany dostęp do sieci firmowej jest poważnym problemem, to zadziałały odpowiednie zabezpieczenia i wykluczono możliwość dostępu do jakichkolwiek danych użytkowników. Były to:
- Fizyczna separacja środowisk deweloperskich i produkcyjnych.
- Brak danych produkcyjnych w środowiskach deweloperskich.
- Ogólny brak możliwości odszyfrowania danych.
I takie podejście, że oba środowiska są całkowicie oddzielone, jest bardzo dobrą praktyką. Dodatkowo firma przeprowadziła analizę kodu źródłowego w celu poszukiwania ewentualnych złośliwych zmian. Nie wykryto takowych, podano jednak kolejny wart implementacji pomysł, czyli dedykowany dział, który może wdrażać zmiany na produkcji.
Ostatnie punkty reakcji na incydent w LastPass to rozpoczęcie współpracy z firmą zajmującą się bezpieczeństwem IT oraz przygotowanie nowych zabezpieczeń.
Opisywany przebieg ataku jasno wskazuje, że zasada minimalnych uprawnień sprawdza się świetnie. Pracownicy nie muszą mieć dostępu do „wszystkiego”, a już na pewno nie powinni ich mieć do środowisk produkcyjnych. Oczywiście to zależy od specyfiki pracy, ale ogólnie programiści nie muszą posiadać przez cały czas dostępu do produkcji. Można stosować podejście „okienek wdrożeniowych” i udzielać im dostępu w określonych przedziałach godzinowych.
