Wdrożenie zabezpieczeń

Zespół ds. bezpieczeństwa Androida regularnie otrzymuje prośby o informacje na temat zapobiegania potencjalnym problemom z bezpieczeństwem na urządzeniach z Androidem. Czasami też sprawdzamy urządzenia i informujemy producentów oraz partnerów o potencjalnych problemach.

Na tej stronie znajdziesz sprawdzone metody dotyczące bezpieczeństwa oparte na naszym doświadczeniu. Są one uzupełnieniem dokumentacji Projektowanie z myślą o bezpieczeństwie, którą udostępniliśmy deweloperom. Zawierają one szczegóły dotyczące tworzenia lub instalowania oprogramowania na poziomie systemu na urządzeniach.

Aby ułatwić stosowanie tych sprawdzonych metod, zespół ds. bezpieczeństwa Androida w miarę możliwości włącza testy do pakietu testów zgodności Androida (CTS) i Android Lint. Zachęcamy implementatorów urządzeń do udostępniania testów, które mogą pomóc innym użytkownikom Androida (testy związane z bezpieczeństwem można wyświetlić na stronie root/cts/tests/tests/security/src/android/security/cts).

Proces tworzenia

Stosuj te sprawdzone metody w procesach i środowisku programowania.

Sprawdzanie kodu źródłowego

Weryfikacja kodu źródłowego może wykryć wiele problemów z bezpieczeństwem, w tym te wymienione w tym dokumencie. Zdecydowanie zalecamy zarówno ręczną, jak i automatyczną weryfikację kodu źródłowego. Sprawdzone metody:

• Uruchom Android Lint na całym kodzie aplikacji, używając pakietu SDK Androida, i napraw wszystkie wykryte problemy.
• Kod natywny należy analizować za pomocą automatycznego narzędzia, które może wykrywać problemy z zarządzaniem pamięci, takie jak przepełnienie bufora i błędy typu off-by-one.
• System kompilacji Androida obsługuje wiele narzędzi do sprawdzania LLVM, takich jak AddressSanitizer i UndefinedBehaviorSanitizer, które można wykorzystać do tego celu.

Korzystanie z testowania automatycznego

Testy automatyczne mogą wykryć wiele problemów z bezpieczeństwem, w tym te opisane poniżej. Sprawdzone metody:

• Testy zabezpieczeń są regularnie aktualizowane. Aby sprawdzić zgodność, uruchom najnowszą wersję testu CTS.
• Regularnie uruchamiaj CTS w trakcie procesu tworzenia, aby wcześnie wykrywać problemy i skracać czas potrzebny na ich rozwiązanie. Android używa CTS w ramach ciągłej integracji w naszym zautomatyzowanym procesie kompilacji, który jest wykonywany kilka razy dziennie.
• Producenci urządzeń powinni zautomatyzować testowanie zabezpieczeń interfejsów, w tym testowanie z nieprawidłowymi danymi wejściowymi (testowanie fuzzingowe).

Obrazy systemu znakowania

Sygnatura obrazu systemu ma kluczowe znaczenie dla integralności urządzenia. Sprawdzone metody:

• Urządzenia nie mogą być podpisane kluczem, który jest znany publicznie.
• Klucze używane do podpisywania urządzeń powinny być zarządzane zgodnie ze standardowymi metodami branżowymi dotyczącymi obsługi kluczy poufnych, w tym sprzętowego modułu zabezpieczeń (HSM), który zapewnia ograniczony, możliwy do zweryfikowania dostęp.

podpisywanie aplikacji (plików APK);

Podpisy aplikacji odgrywają ważną rolę w zabezpieczeniach urządzenia i służą do sprawdzania uprawnień oraz aktualizacji oprogramowania. Wybierając klucz do podpisywania aplikacji, weź pod uwagę, czy aplikacja będzie dostępna tylko na jednym urządzeniu, czy na wielu urządzeniach. Sprawdzone metody:

• Aplikacje nie mogą być podpisywane kluczem, który jest znany publicznie.
• Klucze używane do podpisywania aplikacji powinny być zarządzane zgodnie ze standardowymi w branży procedurami dotyczącymi obsługi kluczy poufnych, w tym HSM, który zapewnia ograniczony, możliwy do zweryfikowania dostęp.
• Aplikacje nie powinny być podpisywane kluczem platformy.
• Aplikacje o tej samej nazwie pakietu nie powinny być podpisane różnymi kluczami. Często zdarza się to podczas tworzenia aplikacji na różne urządzenia, zwłaszcza gdy używasz klucza platformy. Jeśli aplikacja jest niezależna od urządzenia, użyj tego samego klucza na wszystkich urządzeniach. Jeśli aplikacja jest przeznaczona dla konkretnego urządzenia, utwórz unikalne nazwy pakietów dla każdego urządzenia i klucza.

Publikowanie aplikacji

Google Play umożliwia producentom urządzeń aktualizowanie aplikacji bez konieczności przeprowadzania pełnej aktualizacji systemu. Może to przyspieszyć reagowanie na problemy z bezpieczeństwem i wdrażanie nowych funkcji, a także zapewnić, że aplikacja będzie mieć unikalną nazwę pakietu. Sprawdzone metody:

• Prześlij aplikacje do Google Play, aby umożliwić automatyczne aktualizacje bez konieczności przeprowadzania pełnej aktualizacji bezprzewodowej. Aplikacje, które zostały przesłane, ale nie zostały opublikowane, nie mogą być pobierane bezpośrednio przez użytkowników, ale są nadal aktualizowane. Użytkownicy, którzy zainstalowali aplikację wcześniej, mogą ją ponownie zainstalować lub zainstalować na innych urządzeniach.
• Utwórz nazwę pakietu aplikacji, która jest wyraźnie powiązana z Twoją firmą, np. za pomocą znaku towarowego firmy.
• Aplikacje opublikowane przez producentów urządzeń powinny być przesyłane do Sklepu Google Play, aby uniknąć podszywania się pod nazwę pakietu przez użytkowników spoza firmy. Jeśli producent urządzenia zainstaluje aplikację na urządzeniu bez opublikowania jej w Google Play, inny deweloper może przesłać tę samą aplikację, użyć tej samej nazwy pakietu i zmienić jej metadane. Gdy aplikacja zostanie zaprezentowana użytkownikowi, te niezwiązane metadane mogą wywołać zamieszanie.

reagować na incydenty,

Osoby z zewnątrz muszą mieć możliwość kontaktu z producentami urządzeń w sprawie problemów z bezpieczeństwem związanym z konkretnym urządzeniem. Zalecamy utworzenie publicznie dostępnego adresu e-mail do zarządzania incydentami związanymi z bezpieczeństwem. Sprawdzone metody:

• Utwórz adres security@twoja-firma.com lub podobny i podaj go do wiadomości publicznej.
• Jeśli dowiesz się o problemie z bezpieczeństwem związanym z systemem Android lub urządzeniami z Androidem od różnych producentów, skontaktuj się z zespołem ds. bezpieczeństwa Androida, przesyłając raport o błędach związanych z bezpieczeństwem.

Wdrożenie usług

Podczas wdrażania usługi stosuj te sprawdzone metody.

Izolowanie procesów root

Procesy root są najczęściej atakowane w celu podniesienia uprawnień, dlatego zmniejszenie liczby procesów root zmniejsza ryzyko podniesienia uprawnień. CTS zawiera test informacyjny, który zawiera listę procesów głównych. Sprawdzone metody:

• Urządzenia powinny uruchamiać minimalny niezbędny kod jako root. W miarę możliwości używaj zwykłego procesu Androida, a nie procesu root. ICS Galaxy Nexus ma tylko 6 procesów root: vold, inetd, zygote, tf_daemon, ueventd i init. Jeśli proces musi być wykonywany na urządzeniu jako root, udokumentuj go w prośbie o funkcję w AOSP, aby można było go publicznie sprawdzić.
• W miarę możliwości kod root powinien być odizolowany od niezaufanych danych i dostępny przez IPC. Na przykład możesz ograniczyć funkcję root do niewielkiej usługi dostępnej za pomocą Bindera i ujawnić usługę z uprawnieniami podpisu aplikacji z niewielkimi lub zerowymi uprawnieniami do obsługi ruchu sieciowego.
• Procesy root nie mogą nasłuchiwać na gniazdach sieciowych.
• Procesy root nie mogą udostępniać środowiska uruchomieniowego ogólnego przeznaczenia dla aplikacji (np. maszyny wirtualnej Java).

Izolowanie aplikacji systemowych

Zazwyczaj w przypadku preinstalowanych aplikacji nie powinno się używać wspólnego identyfikatora UID systemu. Jeśli jednak aplikacja musi używać wspólnego identyfikatora UID systemu lub innej uprzywilejowanej usługi, nie może eksportować żadnych usług, odbiorników transmisji ani dostawców treści, do których dostęp mają aplikacje innych firm zainstalowane przez użytkowników. Sprawdzone metody:

• Urządzenia powinny uruchamiać kod niezbędny do działania systemu. W miarę możliwości używaj procesu Androida z własnym identyfikatorem UID zamiast ponownie używać identyfikatora UID systemu.
• W miarę możliwości kod systemu powinien być odizolowany od niesprawdzonych danych i przekazywać interfejs IPC tylko zaufanym procesom.
• Procesy systemowe nie mogą nasłuchiwać na gniazdach sieciowych.

Izolowanie procesów

Piaskownica aplikacji na Androida zapewnia aplikacjom izolację od innych procesów w systemie, w tym procesów roota i debugerów. O ile debugowanie nie zostało specjalnie włączone przez aplikację i użytkownika, żadna aplikacja nie powinna naruszać tego założenia. Sprawdzone metody:

• Procesy root nie mogą uzyskiwać dostępu do danych w poszczególnych folderach danych aplikacji, chyba że korzystają z udokumentowanej metody debugowania Androida.
• Procesy root nie mogą uzyskiwać dostępu do pamięci aplikacji, chyba że używają udokumentowanej metody debugowania Androida.
• Urządzenia nie mogą zawierać aplikacji, które uzyskują dostęp do danych lub pamięci innych aplikacji lub procesów.

Bezpieczne pliki SUID

Nowe programy setuid nie powinny być dostępne dla niezaufanych programów. Programy setuid często zawierają luki, które można wykorzystać do uzyskania dostępu roota, dlatego staraj się ograniczyć dostęp do programu setuid w przypadku niezaufanych aplikacji. Sprawdzone metody:

• Procesy SUID nie mogą udostępniać powłoki ani backdoora, które można wykorzystać do obejścia modelu zabezpieczeń Androida.
• Programy SUID nie mogą być zapisywane przez żadnego użytkownika.
• Programy SUID nie powinny być czytelne ani wykonywalne dla wszystkich. Utwórz grupę, ogranicz dostęp do binarnego pliku SUID do członków tej grupy i umieścić w niej wszystkie aplikacje, które mają mieć możliwość uruchamiania programu SUID.
• Programy SUID są częstym źródłem informacji o rootowaniu urządzeń przez użytkowników. Aby zmniejszyć to ryzyko, programy SUID nie powinny być uruchamiane przez użytkownika powłoki.

Sprawdzanie CTS obejmuje test informacyjny, który wylicza pliki SUID. Niektóre pliki setuid są niedozwolone w testach CTS.

Bezpieczne gniazda nasłuchujące

Testy CTS kończą się niepowodzeniem, gdy urządzenie nasłuchuje na dowolnym porcie w dowolnym interfejsie. W przypadku awarii Android sprawdza, czy są używane te sprawdzone metody:

• Na urządzeniu nie powinno być żadnych portów podsłuchowych.
• Porty nasłuchujące muszą mieć możliwość wyłączenia bez OTA. Może to być zmiana konfiguracji serwera lub urządzenia użytkownika.
• Procesy root nie mogą nasłuchiwać na żadnym porcie.
• Procesy należące do identyfikatora UID systemu nie mogą nasłuchiwać na żadnym porcie.
• W przypadku lokalnego IPC z użyciem gniazd aplikacje muszą używać gniazd domeny UNIX z dostępem ograniczonym do grupy. Utwórz deskryptor pliku dla IPC i nadaj mu uprawnienia +RW dla określonej grupy UNIX. Wszystkie aplikacje klienckie muszą znajdować się w tej grupie UNIX.
• Niektóre urządzenia z kilkoma procesorami (np. radio/modem oddzielone od procesora aplikacji) używają gniazd sieciowych do komunikacji między procesorami. W takich przypadkach gniazdo sieciowe używane do komunikacji między procesorami musi korzystać z odseparowanego interfejsu sieciowego, aby uniemożliwić dostęp nieautoryzowanym aplikacjom na urządzeniu (czyli użyć iptables, aby uniemożliwić dostęp innym aplikacjom na urządzeniu).
• Demony, które obsługują porty nasłuchujące, muszą być odporne na źle sformatowane dane. Google może przeprowadzić testy fuzz na porcie przy użyciu nieautoryzowanego klienta, a gdy to możliwe, autoryzowanego klienta. Wszystkie awarie są zgłaszane jako błędy z odpowiednim poziomem ważności.

Dane logów

Rejestrowanie danych zwiększa ryzyko ich ujawnienia i obniża wydajność systemu. Wystąpiło wiele publicznych incydentów związanych z bezpieczeństwem, które były wynikiem rejestrowania poufnych danych użytkowników przez aplikacje domyślnie zainstalowane na urządzeniach z Androidem. Sprawdzone metody:

• Aplikacje i usługi systemowe nie powinny rejestrować danych pochodzących z aplikacji innych firm, które mogą zawierać informacje poufne.
• Aplikacje nie mogą rejestrować żadnych informacji umożliwiających identyfikację osoby w ramach normalnego działania.

CTS zawiera testy, które sprawdzają, czy w logach systemowych nie ma potencjalnie poufnych informacji.

Ograniczanie dostępu do katalogu

Katalogi, w których można zapisywać, mogą zawierać luki w zabezpieczeniach i umożliwiać aplikacji zmianę nazw zaufanych plików, zastępowanie plików lub przeprowadzanie ataków za pomocą linków symbolicznych (osoby przeprowadzające atak mogą użyć linku symbolicznego do pliku, aby oszukać zaufany program i zmusić go do wykonania niechcianych działań). Katalogi do zapisu mogą też uniemożliwić prawidłowe wyczyszczenie wszystkich plików po odinstalowaniu aplikacji.

Zalecamy, aby katalogi utworzone przez system lub użytkowników z poziomu root nie były dostępne do zapisu dla wszystkich. Testy CTS pomagają egzekwować tę sprawdzoną metodę, testując znane katalogi.

Bezpieczne pliki konfiguracji

Wiele sterowników i usług korzysta z plików konfiguracyjnych i danych przechowywanych w katalogach takich jak /system/etc i /data. Jeśli te pliki są przetwarzane przez proces z przywilejami i można je zapisywać, aplikacja może wykorzystać lukę w zabezpieczeniach w tym procesie, tworząc złośliwe treści w pliku z możliwością zapisu przez wszystkich. Sprawdzone metody:

• Pliki konfiguracji używane przez procesy uprzywilejowane nie powinny być dostępne do odczytu przez wszystkich użytkowników.
• Pliki konfiguracji używane przez procesy uprzywilejowane nie mogą być dostępne do zapisu dla wszystkich użytkowników.

Przechowywanie bibliotek kodu natywnego

Kod używany przez uprzywilejowane procesy producenta urządzenia musi znajdować się w katalogu /vendor lub /system; te systemy plików są montowane tylko do odczytu podczas uruchamiania. Zalecamy, aby biblioteki używane przez system lub inne zainstalowane na urządzeniu aplikacje o wysokich uprawnieniach również znajdowały się w tych systemach plików. Pomoże to zapobiec wystąpieniu luki w zabezpieczeniach, która mogłaby umożliwić atakującemu kontrolowanie kodu wykonywanego przez proces uprzywilejowany.

Ograniczanie dostępu do sterownika urządzenia

Tylko zaufany kod powinien mieć bezpośredni dostęp do sterowników. W miarę możliwości zaleca się stosowanie architektury z jednym demonem, który pośredniczy w wywołaniu do sterownika i ogranicza dostęp do tego demona. Zalecamy, aby węzły urządzeń sterownika nie były odczytywalne ani zapisywalne przez wszystkich. Testy CTS pomagają egzekwować tę sprawdzoną metodę, sprawdzając znane przypadki odsłonięcia sterowników.

Wyłączanie ADB

Most debugowania Androida (adb) to przydatne narzędzie do tworzenia i debugowania, ale jest przeznaczone do użytku w kontrolowanych, bezpiecznych środowiskach i nie powinno być włączone do ogólnego użytku. Sprawdzone metody:

• Domyślnie ADB musi być wyłączone.
• ADB musi wymagać od użytkownika włączenia przed akceptacją połączeń.

odblokować programy rozruchowe,

Wiele urządzeń z Androidem obsługuje odblokowywanie, co umożliwia właścicielowi urządzenia modyfikowanie partycji systemowej lub instalowanie niestandardowego systemu operacyjnego. Typowe przypadki użycia obejmują instalowanie ROM-ów innych firm i rozwijanie urządzenia na poziomie systemu. Na przykład właściciel urządzenia Google Nexus może uruchomićfastboot oem unlock, aby rozpocząć proces odblokowywania, który wyświetla użytkownikowi tę wiadomość:

Sprawdzona metoda polega na tym, aby przed odblokowaniem urządzenia z Androidem usunąć wszystkie dane użytkownika. Nieusunięcie wszystkich danych po odblokowaniu może umożliwić osobie atakującej znajdującej się w pobliżu nieautoryzowany dostęp do poufnych danych użytkownika Androida. Aby zapobiec ujawnieniu danych użytkownika, urządzenie obsługujące odblokowywanie musi prawidłowo wdrażać tę funkcję (mieliśmy już wiele przypadków, gdy producenci urządzeń niewłaściwie wdrożyli funkcję odblokowywania). Właściwie zaimplementowany proces odblokowywania ma te właściwości:

• Gdy użytkownik potwierdzi polecenie odblokowania, urządzenie musi natychmiast rozpocząć proces wymazywania danych. Flaga unlocked nie może być ustawiona, dopóki nie zostanie zakończone bezpieczne usunięcie.
• Jeśli nie można bezpiecznie usunąć danych, urządzenie musi pozostać w zamkniętym stanie.
• Jeśli jest to obsługiwane przez urządzenie blokujące, należy użyć ioctl(BLKSECDISCARD) lub jego odpowiednika. W przypadku urządzeń eMMC oznacza to użycie polecenia Secure Erase lub Secure Trim. W przypadku eMMC 4.5 i nowszych oznacza to użycie zwykłego kasowania lub przycinania, a następnie operacji Sanitize.
• Jeśli BLKSECDISCARD nie jest obsługiwany przez urządzenie blokujące, należy użyć ioctl(BLKDISCARD). Na urządzeniach z eMMC jest to zwykła operacja Trim.
• Jeśli BLKDISCARD nie jest obsługiwany, można zastąpić blokowanie urządzeń przez wpisanie wszystkich zer.
• Użytkownik musi mieć możliwość wyczyszczenia danych przed flashowaniem partycji. Na przykład na urządzeniach Nexus można to zrobić za pomocą polecenia fastboot oem lock.
• Urządzenie może rejestrować, za pomocą efuse lub podobnego mechanizmu, czy zostało odblokowane lub ponownie zablokowane.

Te wymagania gwarantują, że wszystkie dane zostaną zniszczone po zakończeniu operacji odblokowania. Niewdrożenie tych zabezpieczeń jest uznawane za średnio poważną lukę w zabezpieczeniach.

Urządzenie, które jest odblokowane, można ponownie zablokować za pomocą polecenia fastboot oem lock. Zablokowanie programu rozruchowego zapewnia taką samą ochronę danych użytkownika w nowym niestandardowym systemie operacyjnym jak w systemie operacyjnym oryginalnego producenta urządzenia (np. dane użytkownika zostaną usunięte, jeśli urządzenie zostanie ponownie odblokowane).