Generatywna analiza danych

Jak znaleźć nowe elementy podstawowe ataku na platformie Microsoft Azure

Data:

Przychody z usług chmurowych firmy Microsoft wzrosła 46% w pierwszym kwartale 2022 r., a jej udział w rynku chmury ma wzrosła o prawie 9% od 2017. Z Lazur w końcu używany na poważnie przez główny nurt, teraz jest idealny czas, aby zaangażować się w badania nad nadużyciami platformy Azure. Istnieje wiele nieodkrytych prymitywów związanych z nadużyciami, nagromadziło się wiele długów związanych z błędną konfiguracją i coraz większa liczba adwersarzy zaczyna poważniej atakować platformę Azure.

Po co tracić czas na szukanie prymitywów nadużyć zamiast błędów lub exploitów oprogramowania? Nadużycia mają znacznie dłuższy okres trwałości niż błędy i zero-days i są tańsze w utrzymaniu. Co ważniejsze dla atakujących, istnieją one w prawie wszystkich implementacjach danego oprogramowania i są znacznie trudniejsze do wykrycia i zablokowania przez obrońców. Dlatego tak ważne jest, aby badacze odkryli nowe możliwości nadużyć, aby można je było naprawić lub złagodzić.

Oto mój pięcioetapowy proces badania konkretnego systemu na platformie Azure i próby znalezienia nowych podstawowych ataków. Postępowanie zgodnie z tym podejściem pomoże Ci zaoszczędzić czas, pozostać na dobrej drodze i osiągnąć lepsze wyniki.

Krok pierwszy: zacznij od końca w umyśle

Najpierw musisz dowiedzieć się, jak działa wybrany system, jak współdziała z innymi systemami na platformie Azure i jak może być nadużywany. Poza tym zastanów się, jaki będzie Twój produkt końcowy — post na blogu? Sesja konferencyjna? Obronne wytyczne naprawcze lub aktualizacje narzędzia typu open source? Określ, co jest potrzebne do utworzenia tych zasobów. Rozważ również stworzenie kodu kontrolnego, aby obrońcy mogli sprawdzić te niebezpieczne konfiguracje, a także nadużyć kodu, aby inni mogli łatwo zweryfikować, w jaki sposób te konfiguracje mogą być nadużywane. Są to „kryteria sukcesu” dla Twoich badań, które pomogą Ci utrzymać koncentrację, uniknąć niepotrzebnych króliczych nor i zapewnić cenny wynik końcowy.

Krok drugi: Przestudiuj intencję i projekt systemu

Gdy już wiesz dokładnie, co musisz odkryć, rozpocznij badania tak, jak każdy inny — wyszukując w Google i czytając oficjalną dokumentację. Poszukaj wszystkiego, co wydaje się nadużywać (na przykład możliwość resetowania haseł i wymaganych uprawnień), zagłębiaj się w to i rób notatki w trakcie.

Skorzystaj z LinkedIn, aby zidentyfikować architektów produktów lub innych pracowników firmy Microsoft zaangażowanych w tworzenie przedmiotu badania. Przejrzyj ich kanały LinkedIn i Twitter i poszukaj zasobów, które są przez nich autorstwa lub opublikowane (posty na blogach, prezentacje z konferencji itp.). Zagłęb się w zasoby społecznościowe, takie jak fora lub repozytoria GitHub związane z tą usługą, ponieważ te grupy użytkowników są na ogół znacznie bardziej otwarte w dyskursie na temat problemów i słabości niż ludzie z Microsoftu. Rób notatki w systemie. Kiedy już będziesz w stanie mówić inteligentnie o architekturze i intencjach systemu oraz napisać bardzo dokładny, nietechniczny brief na ten temat, jesteś gotowy, aby przejść dalej.

Krok trzeci: poznaj system

Dokumentacja może zaprowadzić Cię tylko tak daleko — nie nadąża za zmianami na platformie Azure i prawie zawsze istnieją ukryte połączenia, które nie są udokumentowane. Kuszące jest przejście od razu do tego kroku, ale bez kontekstu systemu, który zbudowałeś poprzez badania, prawdopodobnie zmarnujesz dużo czasu.

Rozpocznij eksplorację systemu od najprostszego interfejsu — często jest to GUI portalu Azure. Jeśli wywołasz narzędzia dla programistów w przeglądarce Chrome, zobaczysz wszystkie żądania interfejsu API wysyłane przez przeglądarkę. Skopiuj je do PowerShell, a będziesz miał dobry początek budowania własnego klienta. Użyj oficjalnych narzędzi CLI na platformie Azure (plik binarny az, moduł AZ PowerShell i moduł Azure AD PowerShell).

Kiedy już wystarczająco zbadałeś, że możesz zbudować własnego podstawowego klienta do interakcji z systemem, nadszedł czas, aby kontynuować. Stanowi to podstawę dla bardziej dojrzałego klienta i automatyzacji procesu testowania możliwości nadużyć.

Krok czwarty: Katalog możliwości nadużyć

Teraz możesz użyć swojego klienta, aby wyliczyć wszystkie uprawnienia, które ten system może przydzielić, i przetestować znane już elementy podstawowe nadużyć z każdym z tych uprawnień (np. czy możesz awansować na administratora globalnego lub zmienić hasło administratora globalnego?). Miej oko na inne prymitywne nadużycia, które mogą pojawić się podczas twoich badań — i przetestuj je również, aby ujawnić wszelkie rozbieżności między tym, co mówi oficjalna dokumentacja, a tym, jak rzeczy działają w rzeczywistości.

Realistycznie musisz zautomatyzować ten proces. Kiedy przechodziłem przez tę metodologię badawczą, badając interfejs Azure Graph API, miałem listę około 175 uprawnień i tuzin prymitywów nadużyć do przetestowania na każdym z nich… Ty robisz matematykę.

Krok piąty: udostępnij wyniki

Ostatnim krokiem jest pomoc innym w nauce z Twojej pracy. Napisz post na blogu, porozmawiaj i/lub udostępnij swój kod. Chodzi o to, aby pomóc innym zaoszczędzić czas i rozszerzyć lub uzupełnić swoją pracę. Pomyśl o tym jako o pisaniu posta na blogu, którego potrzebowałeś na początku swoich badań.

Aby dowiedzieć się więcej, obejrzyj przemówienie, które wygłosiłem na ten temat (i dostęp do towarzyszącego pokładu). Chcesz rozpocząć badanie nadużyć platformy Azure? Oto kilka przydatnych witryn internetowych, w których można znaleźć zawartość techniczną dotyczącą zabezpieczeń platformy Azure: Leniwy Administrator, Dobre obejście!, AZReklamodawca, Thomasa Van Laere, Portale Microsoft.

spot_img

Najnowsza inteligencja

spot_img

Czat z nami

Cześć! Jak mogę ci pomóc?