Firma Microsoft wyciągnęła ważną lekcję po usunięciu poważnego wycieku danych wynikającego z „zbyt liberalnej” sygnatury dostępu współdzielonego (SAS) znak przypadkowo ujawnione przez jednego z pracowników.
Do zdarzenia doszło w czerwcu 2023 rgdy badacz firmy Microsoft udostępnił adres URL magazynu obiektów Blob platformy Azure w publicznym repozytorium GitHub, jednocześnie przyczyniając się do modelu uczenia się sztucznej inteligencji (AI) typu open source.
Jednak adres URL zawierał token SAS dla konta pamięci wewnętrznej, który odkryli analitycy pod adresem specjaliści ds. bezpieczeństwa w chmurze Wiz.io.
Za pomocą tokena udało im się uzyskać dostęp do konta magazynu, gdzie dzięki nadmiernym przywilejom zhakowanego tokena mogli znaleźć znacznie więcej niż tylko dane open source.
Okazało się, że token został skonfigurowany tak, aby udzielać uprawnień na całym koncie magazynu, które zawierało również 38 TB danych, w tym kopie zapasowe stacji roboczych pracowników firmy Microsoft zawierające wrażliwe dane osobowe, dane uwierzytelniające, tajne klucze i 30 000 wewnętrznych wiadomości Teams.
Zespół Wiz i Microsoft współpracowały, aby zapobiec dalszej eskalacji problemu i obecnie to robią wspólnie opublikowane informacje o incydencie w skoordynowanym raporcie ujawniającym luki w zabezpieczeniach (CVD).
Zespół Microsoft Security Response Center (MSRC) stwierdził, że zakres naruszenia był na szczęście ograniczony. „Żadne dane klientów nie zostały ujawnione ani żadne inne usługi wewnętrzne nie były zagrożone z powodu tego problemu” – stwierdzili. „W odpowiedzi na ten problem nie są wymagane żadne działania ze strony klienta. Dzielimy się… wnioskami i najlepszymi praktykami… aby informować naszych klientów i pomagać im uniknąć podobnych incydentów w przyszłości”.
Problem z tokenami SAS
Jak wyjaśnili Hillai Ben-Sasson i Ronny Greenberg z Wiz.io, tokeny SAS są nieco problematyczne. Zostały zaprojektowane w celu ograniczenia dostępu i umożliwienia określonym klientom łączenia się z określonym zasobem usługi Azure Storage, ale zawierają nieodłączne elementy niepewności, co oznacza, że należy nimi ostrożnie zarządzać, co nie miało miejsca w tym przypadku.
Użytkownik może między innymi łatwo i szybko dostosowywać poziomy dostępu, podobnie jak czas wygaśnięcia, co teoretycznie mogłoby pozwolić na utworzenie tokena, który nigdy nie wygasłby (ten, który został skompromitowany, był w rzeczywistości ważny do 2051 r., czyli 28 lat). od teraz).
Dodatkowo, ze względu na to, że użytkownicy mają dużo mocy w stosunku do tokenów SAS, administratorom może być bardzo trudno dowiedzieć się, że w obiegu znajduje się token o wysoce liberalnym charakterze, który nigdy nie wygaśnie, a także nie jest łatwo unieważnić token – aby to zrobić, administrator musi obrócić klucz konta, który podpisał token, co czyni wszelkie inne tokeny podpisane tym samym kluczem bezużytecznymi.
Wszystko to, a także ryzyko przypadkowego ujawnienia, jak miało to miejsce w tym przypadku, sprawia, że tokeny SAS są „skutecznym narzędziem dla atakujących, którzy chcą zachować trwałość na zaatakowanych kontach pamięci masowej” – stwierdzili Ben-Sasson i Greenberg.
„Ze względu na brak zabezpieczeń i zarządzania tokenami SAS konta, należy je uważać za tak samo wrażliwe, jak sam klucz konta. Dlatego zdecydowanie zaleca się unikanie używania konta SAS do udostępniania zewnętrznego. Błędy podczas tworzenia tokena mogą łatwo pozostać niezauważone i ujawnić wrażliwe dane.
„Niedawno Raport Microsoftu wskazuje, że napastnicy wykorzystują brak możliwości monitorowania usługi w celu wystawiania uprzywilejowanych tokenów SAS jako backdoora” – stwierdzili. „Ponieważ wydanie tokena nie jest nigdzie udokumentowane, nie ma sposobu, aby dowiedzieć się, że został wydany i podjąć wobec niego działania.”
Andrew Whaley, starszy dyrektor techniczny w Promonincydent pokazał, że nawet projekty mające najlepsze intencje mogą nieumyślnie zakończyć się sukcesem.
„Podpisy dostępu współdzielonego stanowią poważne ryzyko dla bezpieczeństwa cybernetycznego, jeśli nie są zarządzane z najwyższą starannością” – stwierdził. „Chociaż są niezaprzeczalnie cennym narzędziem do współpracy i udostępniania danych, mogą również stać się mieczem obosiecznym, jeśli zostaną źle skonfigurowane lub niewłaściwie obsługiwane. Kiedy wydawane są zbyt liberalne tokeny SAS lub gdy są one ujawniane w sposób niezamierzony, przypomina to dobrowolne przekazanie kluczy do drzwi wejściowych włamywaczowi.
„Microsoft być może byłby w stanie zapobiec temu naruszeniu, gdyby wdrożył bardziej rygorystyczną kontrolę dostępu, regularnie kontrolował i unieważniał nieużywane tokeny oraz dokładnie edukować swoich pracowników na temat znaczenia ochrony tych danych uwierzytelniających” – powiedział Whaley. „Dodatkowo ciągłe monitorowanie i zautomatyzowane narzędzia do wykrywania zbyt liberalnych tokenów SAS również mogłyby zapobiec temu błędowi”.
Microsoft stwierdził, że nie ma problemu z bezpieczeństwem ani luki w zabezpieczeniach w usłudze Azure Storage ani w samej funkcji tokenu SAS, ale zauważył, że tokeny należy zawsze tworzyć i prawidłowo zarządzać. Od czasu zdarzenia firma Microsoft udoskonala funkcję tokena SAS i kontynuuje ocenę usługi w celu jej dalszego udoskonalenia.
„Jak każdy sekret, tokeny SAS muszą być tworzone i odpowiednio obsługiwane” – stwierdził zespół MSRC. „Jak zawsze gorąco zachęcamy klientów do stosowania naszych najlepszych praktyk podczas korzystania z tokenów SAS, aby zminimalizować ryzyko niezamierzonego dostępu lub nadużyć.
„Microsoft stale udoskonala także swój zestaw narzędzi do wykrywania i skanowania, aby proaktywnie identyfikować takie przypadki nadmiernie udostępnionych adresów URL SAS i wzmacniać naszą standardową bezpieczną postawę.
„Doceniamy możliwość zbadania wniosków zgłoszonych przez Wiz.io. Zachęcamy wszystkich badaczy do współpracy z dostawcami w ramach skoordynowanego ujawniania luk w zabezpieczeniach i przestrzegania zasad przeprowadzania testów penetracyjnych, aby uniknąć wpływu na dane klientów podczas prowadzenia badań bezpieczeństwa.
Wyróżnione zagadnienia
Zespół Wiz.io stwierdził, że incydent uwydatnił dwa główne zagrożenia.
Po pierwsze, nadmierne udostępnianie danych – ponieważ badacze zbierają i udostępniają ich dużo, zwłaszcza jeśli w tym przypadku pracują nad modelem sztucznej inteligencji, istnieje zwiększone ryzyko przypadkowego spowodowania naruszenia. W związku z tym dla zespołów ds. bezpieczeństwa niezwykle ważne staje się określenie jasnych wytycznych dotyczących udostępniania zbiorów danych AI na zewnątrz, przy czym zarówno zespoły ds. bezpieczeństwa, jak i zespoły badawczo-rozwojowe powinny nad tym współpracować.
Po drugie, istnieje ryzyko ataku na łańcuch dostaw. W tym przypadku token przyznał dostęp do zapisu na koncie magazynu zawierającym modele sztucznej inteligencji, nad którymi pracował badacz, więc gdyby złośliwy aktor szybko to wylosował, mógłby z łatwością wstrzyknąć złośliwy kod do plików modeli, co doprowadziło do ataków na inni badacze uzyskujący dostęp do modelu za pośrednictwem GitHuba, a w dalszej kolejności niewypowiedziane szkody, jeśli i kiedy kod wejdzie do powszechnego użytku publicznego. W związku z tym, zdaniem zespołu, zespoły ds. bezpieczeństwa powinny podjąć kroki w celu przeglądu i oczyszczenia modeli sztucznej inteligencji pochodzących ze źródeł zewnętrznych, aby nie zostały one wykorzystane do zdalnego wykonania kodu.