Sprawdź podpis i poświadczenie notarialne dowolnej aplikacji Mac na terminalu

Gatekeeper uruchamia tę kontrolę automatycznie przy pierwszym otwarciu pobranej aplikacji i w większości przypadków nie widać szczegółów — pojawia się okno dialogowe, które należy kliknąć i gotowe. W tym laboratorium sprawdzimy, co widział Gatekeeper: który programista podpisał aplikację, czy podpis jest nienaruszony, czy sprawdził to notariusz Apple i co może zrobić po uruchomieniu. Każde polecenie tutaj jest dostarczane z narzędziami wiersza poleceń Xcode (xcode-select --install, jeśli jeszcze ich nie masz), a każde z nich jest tylko do odczytu — sprawdzasz aplikację, a nie zmieniasz.

Sam podpis: codesign -dvvv

codesign to narzędzie Apple do tworzenia i sprawdzania podpisów kodu. Flaga -d wyświetla w ścieżce informacje o podpisanym kodzie, a zgodnie ze stroną podręcznika „Zwiększenie poziomu szczegółowości daje więcej wyników” — więc -dvvv (wyświetlanie, trzy poziomy szczegółowości) daje pełny obraz w jednym poleceniu:

$ codesign -dvvv /Applications/Example.app
# example output, trimmed to the fields that matter
Executable=/Applications/Example.app/Contents/MacOS/Example
Identifier=com.example.app
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=... flags=0x10000(runtime) hashes=...
Signature size=4741
Authority=Developer ID Application: Example Software LLC (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Team Identifier=ABCDE12345
Runtime Version=14.0.0

Za każdym razem cztery pola do odczytania. Authority to łańcuch certyfikatów: normalna, zewnętrzna aplikacja powinna kończyć się na Apple Root CA poprzez Developer ID Certification Authority, z górną linią zawierającą nazwę programisty. Team Identifier to dziesięcioznakowy identyfikator Apple konta programisty — wartość do porównania między aplikacjami, które Twoim zdaniem pochodzą od tej samej firmy, ponieważ nie zmienia się pomiędzy ich wydaniami. flags=0x10000(runtime) oznacza, że ​​włączone jest wzmocnione środowisko wykonawcze, czyli zestaw dodatkowych ograniczeń (takich jak zapobieganie wstrzykiwaniu kodu do procesu), których Apple wymaga do poświadczenia notarialnego. A brak jakiejkolwiek linii Authority — tylko Signature=adhoc — oznacza, że ​​aplikacja jest niepodpisana lub z podpisem własnym, bez żadnego powiązania z Apple.

Czy podpis nadal pasuje do plików: --verify --deep --strict

Podpis jest obietnicą dotyczącą określonego zestawu bajtów w momencie podpisywania. --verify sprawdza, czy ta obietnica nadal jest aktualna — zgodnie ze stroną podręcznika potwierdza, „że kod w tych ścieżkach jest podpisany, że podpis jest ważny i że wszystkie zapieczętowane komponenty pozostają niezmienione”. Dwie dodatkowe flagi mają znaczenie w przypadku pakietu aplikacji, który jest katalogiem pełnym zagnieżdżonych zasobów, frameworków i plików wykonywalnych pomocniczych, a nie pojedynczego pliku:

$ codesign --verify --deep --strict --verbose=2 /Applications/Example.app
/Applications/Example.app: valid on disk
/Applications/Example.app: satisfies its Designated Requirement

--deep ma znaczenie, ponieważ zgodnie ze stroną podręcznika weryfikacja zagnieżdżonej zawartości jest domyślnie „ograniczona do płytkiego badania, które może nie wykryć zmian w zagnieżdżonym kodzie” — tryb głęboki rekurencyjnie weryfikuje każdą osadzoną strukturę i narzędzie pomocnicze, a nie tylko pakiet zewnętrzny. --strict dodaje dodatkowe kontrole, które Apple uważa za na tyle ważne, że domyślnie nie są włączone, w tym to, że każde dowiązanie symboliczne w pakiecie „wskazuje na zapieczętowane pliki w jego pakiecie”, odrzucając to, które wskazuje na zewnątrz aplikacji lub na coś niezapieczętowanego — znana sztuczka polegająca na przemycaniu niepodpisanego ładunku do legalnie podpisanego pakietu. Jeśli którekolwiek sprawdzenie się nie powiedzie, zobaczysz code failed to satisfy specified code requirement lub notatkę z dokładną nazwą tego, który zagnieżdżony element nie pasuje do tego, co zostało oryginalnie zapieczętowane — przeczytaj tę linię, nazywa ona plik.

Czytanie uprawnień

Uprawnienia to określone uprawnienia, jakie przyznaje jej podpis aplikacji — dostęp do kamery, możliwość łączenia się z siecią poza piaskownicą, wyłączanie sprawdzania poprawności bibliotek i tak dalej. codesign -d --entitlements - wyodrębnia je; na stronie podręcznika „Osadzone dane uprawnień zostaną wyodrębnione w podobny sposób i zapisane” w podanej ścieżce, a - oznacza standardowe wyjście:

$ codesign -d --entitlements - /Applications/Example.app
# example output, trimmed
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
<key>com.apple.security.network.client</key>
<true/>
<key>com.apple.security.device.camera</key>
<true/>

Większość uprawnień nie wyróżnia się niczym szczególnym i odpowiada potrzebom aplikacji — aplikacja do rozmów wideo żądająca dostępu do kamery nie jest żadnym znaleziskiem. Ten, na którym warto się zatrzymać, to disable-library-validation: oznacza to, że aplikacja załaduje kod spoza własnego podpisanego pakietu, co jest normalną potrzebą niektórych programów opartych na wtyczkach i szerszymi drzwiami niż wymaga tego większość aplikacji. Jest to szczegół, na który należy zwrócić uwagę, a nie automatyczna czerwona flaga i jest to dokładnie taki szczegół, którego nie można zobaczyć bez pytania.

Czy notariusz Apple rzeczywiście to sprawdził: spctl i zszywacz

Prawidłowy podpis potwierdza jedynie, że aplikacja nie została zmieniona od czasu podpisania jej przez programistę – nie mówi nic o tym, czy Apple ją przeglądał. To właśnie dodaje notarialność. W dokumentacji Apple opisano zautomatyzowaną usługę notarialną jako skanowanie „twojego oprogramowania w poszukiwaniu złośliwych komponentów, sprawdzanie problemów z podpisywaniem kodu i szybkie przesyłanie wyników”. Kiedy minie, „notariusz generuje bilet, który możesz przypiąć do oprogramowania; notariusz publikuje również ten bilet w Internecie, gdzie Gatekeeper może go znaleźć”.

spctl --assess to praktyczny sposób, aby zapytać własny silnik zasad Gatekeepera o werdykt, zamiast samodzielnie go wyciągać. Na stronie podręcznika --assess „dokonuje oceny podanych plików”, a -v / --verbose, powtórzone w celu uzyskania większej szczegółowości, jest opisane po prostu jako żądanie „bardziej szczegółowego wyniku”:

$ spctl --assess -vv /Applications/Example.app
/Applications/Example.app: accepted
source=Notarized Developer ID

source=Notarized Developer ID to wynik, który chcesz zobaczyć — oznacza to, że Gatekeeper znalazł ważny podpis identyfikatora programisty i poświadczenie notarialne, niezależnie od tego, czy bilet ten jest zszyty w aplikacji, czy też został znaleziony w Internecie. Wynik source=Unnotarized Developer ID oznacza, że ​​aplikacja jest podpisana, ale Apple nie poświadczył tego (lub jeszcze nie) notarialnie, a płaski rejected oznacza, że ​​Gatekeeper zablokuje jej uruchomienie w domyślnej konfiguracji.

Aby konkretnie sprawdzić zszywkę, xcrun stapler validate szuka biletu fizycznie dołączonego do aplikacji, zamiast prosić Gatekeepera o sprawdzenie go online — przydatne do potwierdzenia, że ​​aplikacja będzie nadal poprawnie oceniana bez połączenia z Internetem:

$ xcrun stapler validate /Applications/Example.app
Processing: /Applications/Example.app
The validate action worked!

Flaga kwarantanny: skąd pochodzi kontrola pierwszego uruchomienia

W przewodniku Apple dotyczącym bezpieczeństwa platformy wyjaśniono, że „Gatekeeper śledzi także pochodzenie plików zapisanych przez pobrane oprogramowanie” i „prosi użytkownika o zgodę przed pierwszym otwarciem pobranego oprogramowania”. Mechanizm, który za tym stoi, to rozszerzony atrybut com.apple.quarantine, który Safari, Mail i inne aplikacje dołączają do wszystkiego, co zapisują w sieci. xattr -l wyświetla tę listę i zgodnie ze stroną podręcznika ta opcja „powoduje wyświetlenie zarówno nazw atrybutów, jak i odpowiadających im wartości”:

$ xattr -l ~/Downloads/Example.dmg
com.apple.quarantine: 0081;65e1a2b3;Safari;

Brak danych wyjściowych oznacza, że ​​plik nie zawiera flagi kwarantanny — albo został utworzony lokalnie, dotarł ścieżką, która nie ustawia atrybutu (niektóre narzędzia do archiwizacji i menedżerowie pakietów pomijają to), albo flaga została ręcznie usunięta za pomocą xattr -d com.apple.quarantine. O tym ostatnim przypadku warto wiedzieć z innego powodu: jest to udokumentowany sposób, w jaki ludzie całkowicie omijają kontrolę pierwszego uruchomienia Gatekeepera w przypadku plików, którym ufają lub myślą, że ufają, i warto się nad tym zastanowić, zamiast wklejać nieznany zestaw instrukcji terminala.

Sprawdzone porównanie: dwie aplikacje należące do tego samego programisty

Konkretny sposób wykorzystania tego wszystkiego razem: załóżmy, że masz dwie kopie aplikacji i obie rzekomo pochodzą od tej samej firmy, jedną z witryny programisty, a drugą z linku, który ktoś Ci wysłał. Uruchom codesign -dvvv na obu i porównaj linię Team Identifier — jest to dziesięcioznakowy ciąg powiązany z konkretnym kontem programisty Apple i w przeciwieństwie do nazwy wyświetlanej lub identyfikatora pakietu nie jest to coś, co druga strona może przypadkowo odtworzyć bez dostępu do certyfikatu podpisującego tego konta. Jeśli dwie kopie przedstawiają różne identyfikatory zespołu, nie patrzysz na dwie wersje tej samej aplikacji; patrzysz na dwóch różnych sygnatariuszy, z których jeden nie jest tym, którego dotyczy pobranie. Następnie dodaj spctl --assess -vv na podejrzanej kopii — niedopasowane lub nieobecne źródło notarialne na kopii, które twierdzi, że jest identyczne z notarialnie poświadczonym oryginałem, jest potwierdzeniem, a nie tylko wskazówką.

Czytanie całego obrazu i rzeczywistych czerwonych flag

• Żadnego łańcucha Authority lub łańcucha, który nie kończy się w Apple Root CA — za aplikacją nie stoi żadna odpowiedzialna tożsamość programisty.
• codesign --verify kończy się niepowodzeniem, szczególnie w przypadku komunikatu zawierającego nazwę konkretnego zagnieżdżonego pliku — coś w pakiecie zmieniło się po jego podpisaniu.
• spctl --assess zwraca rejected lub identyfikator zespołu w codesign -dvvv nie odpowiada programiście, jakiego oczekujesz dla tego produktu.
• Flaga kwarantanny, która została wyraźnie usunięta z pliku, którego sam nie pobrałeś, lub który przybył nietypowym kanałem (skrypt, załącznik do wiadomości e-mail, którego nazwa została zmieniona tak, aby wyglądała jak coś innego).
• Szerokie uprawnienia — pełny dostęp do dysku, wyłączona walidacja bibliotek, nieograniczony dostęp do sieci — w aplikacji, której określony cel w oczywisty sposób ich nie potrzebuje.

Żadna z tych kontroli nie sprawdza, co faktycznie robi aplikacja po uruchomieniu i podłączeniu do sieci — to pytanie innego rodzaju, na które można odpowiedzieć, obserwując ruch w aplikacji, a nie jej sygnaturę. Czysty podpis i ważny bilet notarialny to prawdziwe, znaczące minimum: twierdzą, że Apple widział dokładnie ten zestaw bajtów i w momencie sprawdzania nie znalazł żadnych problemów z podpisaniem kodu. Stanowią początek zaufania do aplikacji, a nie jego koniec.

Jaką rolę odgrywają FireAI i HisnLabs

A clean signature and a stapled ticket say an app hasn’t been tampered with since Apple checked it — they say nothing about what it connects to afterward, which is the question FireAI’s per-app rules and on-device review are built to keep answering, signature by signature, connection by connection.

FireAI to własny produkt HisnLabs: zapora sieciowa z AI działająca bezpośrednio na Macu. Pokazuje prostym językiem każde połączenie nawiązywane przez twoje aplikacje i pozwala ci decydować, co opuszcza twojego Maca — jej AI działa lokalnie, więc twój ruch nigdy nie jest wysyłany do nas ani do nikogo innego. Zespół badań nad bezpieczeństwem HisnLabs dba o to, by te decyzje pozostały trafne: kataloguje, które domeny to zwykła telemetria, a które prawdziwa usługa, śledzi kraj i sieć stojące za połączeniem oraz trenuje lokalny model (funkcję Autopilot) na rzeczywistych wzorcach ruchu — a nic z tego nie opuszcza twojego Maca.

Możesz przeczytać o decyzjach technicznych, które za tym stoją, albo wypróbować FireAI przez 17 dni na FireAI od HisnLabs.