macOS Gatekeeper / Quarantine / XProtect
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Gatekeeper to funkcja zabezpieczeń opracowana dla systemów operacyjnych Mac, zaprojektowana w celu zapewnienia, że użytkownicy uruchamiają tylko zaufane oprogramowanie na swoich systemach. Działa poprzez weryfikację oprogramowania, które użytkownik pobiera i próbuje otworzyć z źródeł zewnętrznych do App Store, takich jak aplikacja, wtyczka lub pakiet instalacyjny.
Kluczowym mechanizmem Gatekeepera jest jego proces weryfikacji. Sprawdza, czy pobrane oprogramowanie jest podpisane przez uznanego dewelopera, co zapewnia autentyczność oprogramowania. Ponadto ustala, czy oprogramowanie jest notaryzowane przez Apple, co potwierdza, że nie zawiera znanej złośliwej zawartości i nie zostało zmienione po notaryzacji.
Dodatkowo, Gatekeeper wzmacnia kontrolę i bezpieczeństwo użytkownika, prosząc użytkowników o zatwierdzenie otwarcia pobranego oprogramowania po raz pierwszy. To zabezpieczenie pomaga zapobiegać przypadkowemu uruchomieniu przez użytkowników potencjalnie szkodliwego kodu wykonywalnego, który mogli pomylić z nieszkodliwym plikiem danych.
Podpisy aplikacji, znane również jako podpisy kodu, są kluczowym elementem infrastruktury zabezpieczeń Apple. Służą do weryfikacji tożsamości autora oprogramowania (dewelopera) oraz do zapewnienia, że kod nie został zmieniony od momentu ostatniego podpisania.
Oto jak to działa:
Podpisywanie aplikacji: Gdy deweloper jest gotowy do dystrybucji swojej aplikacji, podpisuje aplikację za pomocą klucza prywatnego. Ten klucz prywatny jest powiązany z certyfikatem, który Apple wydaje deweloperowi po zapisaniu się do programu Apple Developer. Proces podpisywania polega na stworzeniu kryptograficznego skrótu wszystkich części aplikacji i zaszyfrowaniu tego skrótu kluczem prywatnym dewelopera.
Dystrybucja aplikacji: Podpisana aplikacja jest następnie dystrybuowana do użytkowników wraz z certyfikatem dewelopera, który zawiera odpowiadający klucz publiczny.
Weryfikacja aplikacji: Gdy użytkownik pobiera i próbuje uruchomić aplikację, system operacyjny Mac używa klucza publicznego z certyfikatu dewelopera do odszyfrowania skrótu. Następnie ponownie oblicza skrót na podstawie aktualnego stanu aplikacji i porównuje go z odszyfrowanym skrótem. Jeśli się zgadzają, oznacza to, że aplikacja nie została zmodyfikowana od momentu jej podpisania przez dewelopera, a system zezwala na jej uruchomienie.
Podpisy aplikacji są istotną częścią technologii Gatekeeper Apple. Gdy użytkownik próbuje otworzyć aplikację pobraną z internetu, Gatekeeper weryfikuje podpis aplikacji. Jeśli jest podpisana certyfikatem wydanym przez Apple dla znanego dewelopera i kod nie został zmieniony, Gatekeeper zezwala na uruchomienie aplikacji. W przeciwnym razie blokuje aplikację i informuje użytkownika.
Począwszy od macOS Catalina, Gatekeeper sprawdza również, czy aplikacja została notaryzowana przez Apple, co dodaje dodatkową warstwę zabezpieczeń. Proces notaryzacji sprawdza aplikację pod kątem znanych problemów z bezpieczeństwem i złośliwego kodu, a jeśli te kontrole przejdą, Apple dodaje do aplikacji bilet, który Gatekeeper może zweryfikować.
Podczas sprawdzania niektórych przykładów złośliwego oprogramowania zawsze powinieneś sprawdzić podpis binarnego pliku, ponieważ deweloper, który go podpisał, może być już powiązany ze złośliwym oprogramowaniem.
Proces notaryzacji Apple'a służy jako dodatkowe zabezpieczenie chroniące użytkowników przed potencjalnie szkodliwym oprogramowaniem. Polega on na przesłaniu aplikacji przez dewelopera do zbadania przez Usługę Notarialną Apple'a, której nie należy mylić z Przeglądem Aplikacji. Ta usługa to automatyczny system, który dokładnie sprawdza przesłane oprogramowanie pod kątem obecności złośliwej zawartości oraz wszelkich potencjalnych problemów z podpisywaniem kodu.
Jeśli oprogramowanie przejdzie tę inspekcję bez wzbudzania jakichkolwiek obaw, Usługa Notarialna generuje bilet notarialny. Deweloper jest następnie zobowiązany do dołączenia tego biletu do swojego oprogramowania, co nazywa się 'przyklejaniem'. Ponadto, bilet notarialny jest również publikowany online, gdzie Gatekeeper, technologia zabezpieczeń Apple'a, może go uzyskać.
Przy pierwszej instalacji lub uruchomieniu oprogramowania przez użytkownika, istnienie biletu notarialnego - czy to przyklejonego do pliku wykonywalnego, czy znalezionego online - informuje Gatekeeper, że oprogramowanie zostało notarialnie zatwierdzone przez Apple'a. W rezultacie, Gatekeeper wyświetla opisową wiadomość w początkowym oknie dialogowym uruchamiania, wskazując, że oprogramowanie przeszło kontrole pod kątem złośliwej zawartości przez Apple'a. Proces ten zwiększa zaufanie użytkowników do bezpieczeństwa oprogramowania, które instalują lub uruchamiają na swoich systemach.
Zauważ, że od wersji Sequoia, spctl nie pozwala już na modyfikację konfiguracji Gatekeepera.
spctl to narzędzie CLI do enumeracji i interakcji z Gatekeeperem (z demonem syspolicyd za pośrednictwem wiadomości XPC). Na przykład, możliwe jest sprawdzenie statusu Gatekeepera za pomocą:
Zauważ, że kontrole podpisów GateKeeper są wykonywane tylko dla plików z atrybutem Quarantine, a nie dla każdego pliku.
GateKeeper sprawdzi, czy zgodnie z preferencjami i podpisem binarka może być wykonana:
syspolicyd jest głównym daemonem odpowiedzialnym za egzekwowanie Gatekeepera. Utrzymuje bazę danych znajdującą się w /var/db/SystemPolicy i można znaleźć kod wspierający bazę danych tutaj oraz szablon SQL tutaj. Zauważ, że baza danych nie jest ograniczona przez SIP i jest zapisywalna przez roota, a baza danych /var/db/.SystemPolicy-default jest używana jako oryginalna kopia zapasowa w przypadku uszkodzenia innej.
Ponadto, pakiety /var/db/gke.bundle i /var/db/gkopaque.bundle zawierają pliki z regułami, które są wstawiane do bazy danych. Możesz sprawdzić tę bazę danych jako root za pomocą:
syspolicyd również udostępnia serwer XPC z różnymi operacjami, takimi jak assess, update, record i cancel, które są również dostępne za pomocą Security.framework's SecAssessment* API, a xpctl faktycznie komunikuje się z syspolicyd za pośrednictwem XPC.
Zauważ, jak pierwsza zasada kończy się na "App Store", a druga na "Developer ID" oraz że w poprzednim obrazie było włączone wykonywanie aplikacji z App Store i zidentyfikowanych deweloperów. Jeśli zmodyfikujesz to ustawienie na App Store, zasady "Notarized Developer ID" znikną.
Istnieją również tysiące zasad typu GKE:
To są hashe, które pochodzą z:
/var/db/SystemPolicyConfiguration/gke.bundle/Contents/Resources/gke.auth
/var/db/gke.bundle/Contents/Resources/gk.db
/var/db/gkopaque.bundle/Contents/Resources/gkopaque.db
Lub możesz wymienić poprzednie informacje za pomocą:
Opcje --master-disable i --global-disable narzędzia spctl całkowicie wyłączą te kontrole podpisów:
Kiedy jest całkowicie włączona, pojawi się nowa opcja:
Można sprawdzić, czy aplikacja będzie dozwolona przez GateKeeper za pomocą:
Możliwe jest dodanie nowych reguł w GateKeeper, aby zezwolić na uruchamianie określonych aplikacji za pomocą:
Regarding kernel extensions, the folder /var/db/SystemPolicyConfiguration contains files with lists of kexts allowed to be loaded. Moreover, spctl has the entitlement com.apple.private.iokit.nvram-csr because it's capable of adding new pre-approved kernel extensions which need to be saved also in NVRAM in a kext-allowed-teams key.
Upon downloading an application or file, specific macOS applications such as web browsers or email clients attach an extended file attribute, commonly known as the "quarantine flag," to the downloaded file. This attribute acts as a security measure to mark the file as coming from an untrusted source (the internet), and potentially carrying risks. However, not all applications attach this attribute, for instance, common BitTorrent client software usually bypasses this process.
Obecność flagi kwarantanny sygnalizuje funkcję zabezpieczeń Gatekeeper w macOS, gdy użytkownik próbuje wykonać plik.
In the case where the quarantine flag is not present (as with files downloaded via some BitTorrent clients), Gatekeeper's checks may not be performed. Thus, users should exercise caution when opening files downloaded from less secure or unknown sources.
Sprawdzanie ważności podpisów kodu to proces wymagający dużych zasobów, który obejmuje generowanie kryptograficznych hashy kodu i wszystkich jego powiązanych zasobów. Ponadto, sprawdzanie ważności certyfikatu wiąże się z przeprowadzeniem sprawdzenia online na serwerach Apple, aby zobaczyć, czy został on unieważniony po jego wydaniu. Z tych powodów, pełne sprawdzenie podpisu kodu i notaryzacji jest niepraktyczne do przeprowadzenia za każdym razem, gdy aplikacja jest uruchamiana.
Therefore, these checks are only run when executing apps with the quarantined attribute.
Ten atrybut musi być ustawiony przez aplikację tworzącą/pobierającą plik.
Jednak pliki, które są w piaskownicy, będą miały ten atrybut ustawiony dla każdego pliku, który tworzą. A aplikacje, które nie są w piaskownicy, mogą ustawić go same lub określić klucz LSFileQuarantineEnabled w Info.plist, co spowoduje, że system ustawi rozszerzony atrybut com.apple.quarantine na utworzonych plikach,
Moreover, all files created by a process calling qtn_proc_apply_to_self are quarantined. Or the API qtn_file_apply_to_path adds the quarantine attribute to a specified file path.
It's possible to check it's status and enable/disable (root required) with:
Możesz również sprawdzić, czy plik ma rozszerzony atrybut kwarantanny za pomocą:
Sprawdź wartość rozszerzonych atrybutów i znajdź aplikację, która zapisała atrybut kwarantanny za pomocą:
Właściwie proces "może ustawić flagi kwarantanny dla plików, które tworzy" (już próbowałem zastosować flagę USER_APPROVED w utworzonym pliku, ale nie została zastosowana):
```c #include #include
enum qtn_flags { QTN_FLAG_DOWNLOAD = 0x0001, QTN_FLAG_SANDBOX = 0x0002, QTN_FLAG_HARD = 0x0004, QTN_FLAG_USER_APPROVED = 0x0040, };
#define qtn_proc_alloc _qtn_proc_alloc #define qtn_proc_apply_to_self _qtn_proc_apply_to_self #define qtn_proc_free _qtn_proc_free #define qtn_proc_init _qtn_proc_init #define qtn_proc_init_with_self _qtn_proc_init_with_self #define qtn_proc_set_flags _qtn_proc_set_flags #define qtn_file_alloc _qtn_file_alloc #define qtn_file_init_with_path _qtn_file_init_with_path #define qtn_file_free _qtn_file_free #define qtn_file_apply_to_path _qtn_file_apply_to_path #define qtn_file_set_flags _qtn_file_set_flags #define qtn_file_get_flags _qtn_file_get_flags #define qtn_proc_set_identifier _qtn_proc_set_identifier
typedef struct _qtn_proc *qtn_proc_t; typedef struct _qtn_file *qtn_file_t;
int qtn_proc_apply_to_self(qtn_proc_t); void qtn_proc_init(qtn_proc_t); int qtn_proc_init_with_self(qtn_proc_t); int qtn_proc_set_flags(qtn_proc_t, uint32_t flags); qtn_proc_t qtn_proc_alloc(); void qtn_proc_free(qtn_proc_t); qtn_file_t qtn_file_alloc(void); void qtn_file_free(qtn_file_t qf); int qtn_file_set_flags(qtn_file_t qf, uint32_t flags); uint32_t qtn_file_get_flags(qtn_file_t qf); int qtn_file_apply_to_path(qtn_file_t qf, const char *path); int qtn_file_init_with_path(qtn_file_t qf, const char path); int qtn_proc_set_identifier(qtn_proc_t qp, const char bundleid);
int main() {
qtn_proc_t qp = qtn_proc_alloc(); qtn_proc_set_identifier(qp, "xyz.hacktricks.qa"); qtn_proc_set_flags(qp, QTN_FLAG_DOWNLOAD | QTN_FLAG_USER_APPROVED); qtn_proc_apply_to_self(qp); qtn_proc_free(qp);
FILE *fp; fp = fopen("thisisquarantined.txt", "w+"); fprintf(fp, "Hello Quarantine\n"); fclose(fp);
return 0;
}
I znajdź wszystkie zainfekowane pliki za pomocą:
Informacje o kwarantannie są również przechowywane w centralnej bazie danych zarządzanej przez LaunchServices w ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2, co pozwala GUI uzyskać dane o pochodzeniu plików. Co więcej, może to być nadpisane przez aplikacje, które mogą być zainteresowane ukrywaniem swoich źródeł. Ponadto, można to zrobić z poziomu API LaunchServices.
libquarantine.dylb
Ta biblioteka eksportuje kilka funkcji, które pozwalają manipulować polami atrybutów rozszerzonych.
API qtn_file_* zajmują się politykami kwarantanny plików, a API qtn_proc_* są stosowane do procesów (plików tworzonych przez proces). Nieeksportowane funkcje __qtn_syscall_quarantine* to te, które stosują polityki, które wywołują mac_syscall z "Quarantine" jako pierwszym argumentem, co wysyła żądania do Quarantine.kext.
Quarantine.kext
Rozszerzenie jądra jest dostępne tylko przez cache jądra w systemie; jednak możesz pobrać Kernel Debug Kit z https://developer.apple.com/, który będzie zawierał wersję z symbolami tego rozszerzenia.
To Kext będzie przechwytywać za pomocą MACF kilka wywołań, aby zarejestrować wszystkie zdarzenia cyklu życia pliku: tworzenie, otwieranie, zmiana nazwy, tworzenie twardych linków... nawet setxattr, aby zapobiec ustawieniu rozszerzonego atrybutu com.apple.quarantine.
Używa również kilku MIB:
security.mac.qtn.sandbox_enforce: Wymuszanie kwarantanny w ramach Sandbox
security.mac.qtn.user_approved_exec: Procesy w kwarantannie mogą wykonywać tylko zatwierdzone pliki
XProtect to wbudowana funkcja antywirusowa w macOS. XProtect sprawdza każdą aplikację, gdy jest uruchamiana po raz pierwszy lub modyfikowana, w porównaniu do swojej bazy danych znanych złośliwych oprogramowań i niebezpiecznych typów plików. Gdy pobierasz plik przez niektóre aplikacje, takie jak Safari, Mail lub Wiadomości, XProtect automatycznie skanuje plik. Jeśli pasuje do jakiegokolwiek znanego złośliwego oprogramowania w swojej bazie danych, XProtect zapobiegnie uruchomieniu pliku i powiadomi cię o zagrożeniu.
Baza danych XProtect jest regularnie aktualizowana przez Apple o nowe definicje złośliwego oprogramowania, a te aktualizacje są automatycznie pobierane i instalowane na twoim Macu. Zapewnia to, że XProtect jest zawsze aktualny z najnowszymi znanymi zagrożeniami.
Warto jednak zauważyć, że XProtect nie jest pełnoprawnym rozwiązaniem antywirusowym. Sprawdza tylko określoną listę znanych zagrożeń i nie wykonuje skanowania w czasie rzeczywistym, jak większość oprogramowania antywirusowego.
Możesz uzyskać informacje o najnowszej aktualizacji XProtect, uruchamiając:
XProtect znajduje się w chronionej lokalizacji SIP pod /Library/Apple/System/Library/CoreServices/XProtect.bundle, a wewnątrz pakietu można znaleźć informacje, które XProtect wykorzystuje:
XProtect.bundle/Contents/Resources/LegacyEntitlementAllowlist.plist: Pozwala na użycie starych uprawnień dla kodu z tymi cdhashami.
XProtect.bundle/Contents/Resources/XProtect.meta.plist: Lista wtyczek i rozszerzeń, które są zabronione do załadowania za pomocą BundleID i TeamID lub wskazują minimalną wersję.
XProtect.bundle/Contents/Resources/XProtect.yara: Reguły Yara do wykrywania złośliwego oprogramowania.
XProtect.bundle/Contents/Resources/gk.db: Baza danych SQLite3 z hashami zablokowanych aplikacji i TeamIDs.
Zauważ, że istnieje inna aplikacja w /Library/Apple/System/Library/CoreServices/XProtect.app, związana z XProtect, która nie jest zaangażowana w proces Gatekeepera.
Zauważ, że Gatekeeper nie jest uruchamiany za każdym razem, gdy uruchamiasz aplikację, tylko AppleMobileFileIntegrity (AMFI) weryfikuje podpisy kodu wykonywalnego tylko wtedy, gdy uruchamiasz aplikację, która została już uruchomiona i zweryfikowana przez Gatekeepera.
Dlatego wcześniej możliwe było uruchomienie aplikacji, aby ją zbuforować z Gatekeeperem, a następnie zmodyfikowanie niewykonywalnych plików aplikacji (jak pliki Electron asar lub NIB) i jeśli nie było innych zabezpieczeń, aplikacja była uruchamiana z złośliwymi dodatkami.
Jednak teraz to nie jest możliwe, ponieważ macOS zapobiega modyfikacji plików wewnątrz pakietów aplikacji. Więc, jeśli spróbujesz ataku Dirty NIB, odkryjesz, że nie jest już możliwe jego nadużycie, ponieważ po uruchomieniu aplikacji, aby ją zbuforować z Gatekeeperem, nie będziesz mógł zmodyfikować pakietu. A jeśli zmienisz na przykład nazwę katalogu Contents na NotCon (jak wskazano w exploicie), a następnie uruchomisz główny plik binarny aplikacji, aby ją zbuforować z Gatekeeperem, spowoduje to błąd i nie zostanie uruchomione.
Każdy sposób na obejście Gatekeepera (udać się zmusić użytkownika do pobrania czegoś i uruchomienia tego, gdy Gatekeeper powinien to zablokować) jest uważany za lukę w macOS. Oto niektóre CVE przypisane do technik, które pozwalały na obejście Gatekeepera w przeszłości:
Zaobserwowano, że jeśli Narzędzie archiwizacji jest używane do ekstrakcji, pliki z ścieżkami przekraczającymi 886 znaków nie otrzymują rozszerzonego atrybutu com.apple.quarantine. Ta sytuacja niezamierzenie pozwala tym plikom ominąć kontrole bezpieczeństwa Gatekeepera.
Sprawdź oryginalny raport po więcej informacji.
Gdy aplikacja jest tworzona za pomocą Automatora, informacje o tym, co jest potrzebne do jej uruchomienia, znajdują się w application.app/Contents/document.wflow, a nie w pliku wykonywalnym. Plik wykonywalny to tylko ogólny binarny plik Automatora zwany Automator Application Stub.
Dlatego możesz sprawić, że application.app/Contents/MacOS/Automator\ Application\ Stub wskazuje za pomocą linku symbolicznego na inny Automator Application Stub w systemie i uruchomi to, co znajduje się w document.wflow (twój skrypt) bez wywoływania Gatekeepera, ponieważ rzeczywisty plik wykonywalny nie ma atrybutu kwarantanny.
Przykładowa oczekiwana lokalizacja: /System/Library/CoreServices/Automator\ Application\ Stub.app/Contents/MacOS/Automator\ Application\ Stub
Sprawdź oryginalny raport po więcej informacji.
W tym obejściu stworzono plik zip z aplikacją, która zaczynała kompresję z application.app/Contents zamiast application.app. Dlatego atrybut kwarantanny został zastosowany do wszystkich plików z application.app/Contents, ale nie do application.app, co było sprawdzane przez Gatekeepera, więc Gatekeeper został ominięty, ponieważ gdy application.app został uruchomiony, nie miał atrybutu kwarantanny.
Sprawdź oryginalny raport po więcej informacji.
Nawet jeśli komponenty są różne, wykorzystanie tej podatności jest bardzo podobne do poprzedniej. W tym przypadku wygenerujemy Archiwum Apple z application.app/Contents, aby application.app nie otrzymał atrybutu kwarantanny podczas dekompresji przez Archive Utility.
Sprawdź oryginalny raport po więcej informacji.
ACL writeextattr może być użyty do zapobiegania komukolwiek w pisaniu atrybutu w pliku:
Ponadto, format pliku AppleDouble kopiuje plik wraz z jego ACE.
W kodzie źródłowym można zobaczyć, że tekstowa reprezentacja ACL przechowywana wewnątrz xattr o nazwie com.apple.acl.text zostanie ustawiona jako ACL w dekompresowanym pliku. Więc, jeśli skompresujesz aplikację do pliku zip w formacie AppleDouble z ACL, który uniemożliwia zapisanie innych xattr... xattr kwarantanny nie został ustawiony w aplikacji:
Sprawdź oryginalny raport po więcej informacji.
Zauważ, że to może być również wykorzystane z AppleArchives:
Odkryto, że Google Chrome nie ustawia atrybutu kwarantanny dla pobranych plików z powodu pewnych wewnętrznych problemów macOS.
Formaty plików AppleDouble przechowują atrybuty pliku w osobnym pliku zaczynającym się od ._, co pomaga w kopiowaniu atrybutów plików między maszynami macOS. Jednak zauważono, że po dekompresji pliku AppleDouble, plik zaczynający się od ._ nie otrzymał atrybutu kwarantanny.
Mając możliwość stworzenia pliku, który nie będzie miał ustawionego atrybutu kwarantanny, można było obejść Gatekeeper. Sztuczka polegała na stworzeniu aplikacji pliku DMG przy użyciu konwencji nazewnictwa AppleDouble (zaczynając od ._) i stworzeniu widocznego pliku jako dowiązania symbolicznego do tego ukrytego pliku bez atrybutu kwarantanny.
Gdy plik dmg jest wykonywany, ponieważ nie ma atrybutu kwarantanny, obejdzie Gatekeeper.
Utwórz katalog zawierający aplikację.
Dodaj uchg do aplikacji.
Skonpresuj aplikację do pliku tar.gz.
Wyślij plik tar.gz do ofiary.
Ofiara otwiera plik tar.gz i uruchamia aplikację.
Gatekeeper nie sprawdza aplikacji.
W pakiecie ".app", jeśli atrybut quarantine xattr nie jest do niego dodany, podczas wykonywania Gatekeeper nie zostanie uruchomiony.
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
