Microsoft znalazł zrzut awaryjny Storm-0558 wykorzystany do kradzieży klucza podpisu

Firma Microsoft opublikowała szczegółowe informacje na temat tego, jak wspierany przez państwo chiński podmiot zajmujący się zaawansowanymi trwałymi zagrożeniami (APT), wyśledzony jako Storm-0558, mógł zdobyć klucz klienta konta Microsoft (MSA) w celu sfałszowania tokenów umożliwiających dostęp do witryn OWA i Outlook.com konta u wielu znanych klientów.

Incydent, który został po raz pierwszy ujawniony we wtorek 11 lipca, rozpoczęło się w kwietniu i od połowy maja umożliwiło Storm-0558 dostęp do danych kont e-mail w wielu organizacjach, w tym agencjach i departamentach rządu USA. Wykrycie i zajęcie się włamaniami zajęło kolejny miesiąc.

Od tego czasu Microsoft musiał się zmierzyć krytykę swojej reakcji na incydentw tym oskarżenia urzędników państwowych o zaniedbania.

Dochodzenie Redmond w sprawie incydentu zostało już zakończone, dzięki któremu Microsoft odkrył, że Storm-0558 był w stanie wykorzystać rzadki zbieg okoliczności do rozpoczęcia kampanii cyberataków. Podjęła działania, aby zapobiec ponownemu wystąpieniu tej sytuacji.

„Microsoft stale ulepsza systemy w ramach naszej strategii dogłębnej obrony. Inwestycje dokonane w związku z kluczową kadrą kierowniczą MSA ujęte są w art https://aka.ms/storm-0558 blogu. Elementy szczegółowo opisane na tym blogu stanowią podzbiór tych ogólnych inwestycji” – powiedział zespół ds. bezpieczeństwa MSRC firmy.

Ze względu na bardzo wrażliwy charakter danych swoich klientów firma Microsoft utrzymuje ściśle kontrolowane, odizolowane i objęte ograniczeniami środowiska produkcyjne, których zadaniem jest zapobieganie opuszczaniu kluczowych materiałów.

Jednak w kwietniu awaria systemu podpisywania przez klienta doprowadziła do utworzenia migawki uszkodzonego procesu – jest to tzw. zrzut awaryjny, rodzaj zrzut pamięci. Takie zrzuty awaryjne usuwają poufne informacje, a ten nie powinien był zawierać klucza podpisującego, jednak w tym przypadku klucz podpisujący został uwzględniony ze względu na warunki wyścigu – problem występujący, gdy dwa procesy lub wątki programu próbują uzyskać dostęp do tego samego zasobu w tym samym czasie, powodując problemy w systemie. Systemy Microsoftu nie wykryły wówczas tego problemu – od tego czasu zajęto się tym problemem.

Ponieważ Microsoft nie wierzył, że zrzut awaryjny zawiera poufne materiały, został przeniesiony z izolowanej sieci produkcyjnej do środowiska debugowania, które znajduje się w głównej sieci korporacyjnej połączonej z Internetem, zgodnie ze standardowymi procesami debugowania firmy Microsoft. W tym momencie obecność klucza była nadal niewykryta.

W pewnym momencie Microsoft odkrył, że Storm-0558 pomyślnie włamał się na konto firmowe należące do inżyniera Microsoft mającego dostęp do środowiska debugowania. Niestety, zasady przechowywania dzienników firmy Microsoft oznaczają, że nie ma bezpośredniego dowodu na to, że Storm-0558 wydobył w tym momencie klucz podpisywania ze środowiska debugowania, ale w pewnym stopniu jest to najbardziej prawdopodobny zastosowany mechanizm.

I tak już zła sytuacja uległa pogorszeniu dla firmy Microsoft i jej klientów rządowych, ponieważ aby sprostać rosnącemu zapotrzebowaniu na obsługę aplikacji współpracujących zarówno z aplikacjami konsumenckimi, jak i korporacyjnymi, firma Microsoft od pięciu lat korzysta ze wspólnego punktu końcowego publikowania kluczowych metadanych.

Konfigurując tę ​​ofertę konwergentną, Microsoft oświadczył, że zaktualizował dokumentację, aby wyjaśnić wymagania dotyczące walidacji zakresu klucza – to znaczy, jakiego klucza użyć w przypadku kont konsumenckich, a którego w przypadku przedsiębiorstw. Udostępnił także interfejs programowania aplikacji (API) za pośrednictwem swojej biblioteki dokumentacji i pomocniczych interfejsów API, które pomagają w kryptograficznej walidacji podpisów, ale co najważniejsze, nie zaktualizował tych bibliotek, aby automatycznie przeprowadzały sprawdzanie poprawności zakresu, co jest teraz czymś innym, co zostało teraz poprawione.

Kiedy w 2022 r. zaktualizowano systemy pocztowe firmy, aby korzystały ze wspólnego punktu końcowego metadanych, programiści błędnie założyli, że biblioteki te przeprowadziły pełną weryfikację klucza podpisu i w związku z tym nie dodały wymaganej weryfikacji wydawcy/zakresu, co doprowadziło do szeregu okoliczności, w których poczta system mógłby z radością zaakceptować żądanie poczty korporacyjnej przy użyciu tokena zabezpieczającego podpisanego kluczem klienta.

„Zrzuty awaryjne zwykle nie zawierają kluczy do podpisu, ale nie był to jedyny przypadek, który spowodował błąd” – powiedział Jake Moore, globalny doradca ds. bezpieczeństwa cybernetycznego w firmie ESETU.

„Podobnie jak w przypadku zdecydowanej większości ataków, cyberprzestępcom udało się złamać korporacyjne konto inżyniera umożliwiające dostęp do wszystkich obszarów, które pomyślnie rozpoczęło atak, dlatego niezwykle ważne jest, aby takie konta pozostawały w stanie wysokiej czujności i czujności na ataki phishingowe” – dodał. .

„Klucz ten zasadniczo skutecznie naśladował dowolne konto użytkownika lub aplikację, jakiej oczekiwał. Uzyskanie klucza z poprzedniego zrzutu awaryjnego, który umożliwił włamanie do usług chmurowych Microsoft, było możliwe, ponieważ wcześniej nie uwzględniono skanowania poświadczeń.