Prywatność i cyberbezpieczeństwo to nie są hobbystyczne fanaberie dla ludzi w foliowych czapeczkach. Skompromitowane urządzenie mobilne to bezpośrednie zagrożenie dla Twojego życia osobistego, finansów i spokoju psychicznego.

Właśnie ruszyłem ze swoim blogiem, a to mój pierwszy wpis:
🔗 https://meridian.bearblog.dev/droga_do_grapheneos/

Opisuję w nim historię z ukrytym korporacyjnym MDM na moim telefonie i to, jak techniki Incident Response oraz przejście na GrapheneOS pozwoliły mi odzyskać kontrolę.

To mój debiut, dlatego bardzo zależy mi na Waszym feedbacku. Co myślicie o tym tekście? Dajcie znać w komentarzach, czy taka tematyka Was interesuje i czy chcecie kolejne wpisy o konfiguracji i hardeningu GrapheneOS! 🛡️📱

#GrapheneOS #Cybersecurity #Privacy #Prywatnosc #Bezpieczenstwo #FOSS #MobileSecurity #PlFediverse #Blog

Jak okiełznałem system z MDM. Moja droga do GrapheneOS

W świecie cyberbezpieczeństwa często rozmawiamy o "modelach zagrożeń" (Threat Models) w sposób czysto teoretyczny. Analizujemy tabelki, czytamy dokumentację ...

Meridian
@meridian Tak. Mnie interesuje. Dodałam do rrs-ów. Przeczytam uwaznie w weekend.

@meridian co ty mówisz o urządzeniach mobilnych i ich kompromitacji jeśli regularnie widzę jak ludzie informują że znaleźli kartę płatniczą i właściciel może się zgłosić po odbiór. Wielokrotnie publicznie mówiłem że to jest bez sensu kartę należy przeciąć i wyrzucić bo skompromitowana karta nie nadaje się do niczego innego poza przecięciem i wyrzuceniem. I co? I jajco, nic się nie zmienia ludzie nie mają najmniejszego pojęcia o technologii używanej od lat.
Więcej ludzie nie mają najmniejszego pojęcia o bezpieczeństwie czegoś takiego jak seks który jest w użyciu trochę dłużej niż od dłuższego czasu 😂 niż jakakolwiek inna technologia wymagająca zabezpieczeń.

#GrapheneOS #Cybersecurity #Privacy #Prywatnosc #Bezpieczenstwo #FOSS #MobileSecurity #PlFediverse #Blog

@Aegewsh Rozumiem Twój sceptycyzm i masz rację świadomość leży. Ale właśnie dlatego warto pisać o takich rzeczach. Ktoś musi zacząć edukować, nawet jeśli na początku trafi to tylko do garstki osób, które wiedzą, co zrobić ze znalezioną kartą ;)
@meridian Czy nie wystarczyło spróbować przywrócić nowy telefon do ustawień fabrycznych, żeby pojawiła się informacja o MDM?
@rozie Przy przywracaniu ustawień fabrycznych nie było tej informacji, dopiero w trybie naprawy taki komunikat się pojawił.
@meridian Ciekawe. Jaki to MDM był? 3rd party MDM nie powinien przeżyć przywracania do fabrycznych (tzn. nie bardzo jest opcja, by przeżył).

@rozie To tak nie działa we współczesnych systemach. Korporacyjne systemy MDM (jak Apple DEP/Business Manager czy Android Zero-Touch / Samsung Knox) są zintegrowane na poziomie sprzętowym (IMEI/numer seryjny) oraz weryfikowane bezpośrednio na serwerach producenta systemu podczas aktywacji urządzenia.

Zwykłe przywrócenie do ustawień fabrycznych (Factory Reset) czyści jedynie partycję danych użytkownika (/data). Partycja systemowa oraz zaszyte w urządzeniu identyfikatory pozostają nienaruszone. Telefon po resecie i połączeniu z sieciami Apple/Google natychmiast odpytuje serwer i ponownie wymusza blokadę MDM. Właśnie dlatego komunikat o blokadzie potrafi "ukryć się" przy standardowym uruchomieniu i wyskoczyć dopiero w trybie naprawczym (Repair Mode) lub podczas próby ponownej aktywacji, bo system sprawdza wtedy integralność i status urządzenia.

@meridian Tak, systemowe przeżyją przywracanie. Stąd pytałem jaki to był MDM. Sorry, jeśli pytanie o 3rd party było niejasne.

@rozie Właśnie o to chodzi. Gdyby to był profil 3rd party, factory reset załatwiłby sprawę.

Tutaj w bezpiecznym Trybie naprawy (Repair Mode) system wypluł jasny komunikat o administratorze IT. Modyfikacje dotyczyły wyłącznie stockowych aplikacji systemowych – każda próba ręcznej zmiany ich uprawnień była w tle momentalnie cofana. Co więcej, przy tak głębokim wdrożeniu próba flashowania ucegliłaby telefon w bootloopie. To było zaawansowane, sprzętowo-systemowe zabezpieczenie, a nie zwykła aplikacja użytkownika. Urządzenie ostatecznie poszło do wymiany.

@meridian dlaczego uważasz fdroid za przestarzały?

@kayo77 F-Droid jest świetny ideologicznie, ale technicznie utknął w przeszłości i wymusza spore kompromisy w kwestii bezpieczeństwa. Uważam go za przestarzały z trzech głównych powodów:

Stare Target SDK: Wiele aplikacji w repozytorium nie jest aktualizowanych pod kątem nowoczesnych API Androida. Przez niskie Target SDK aplikacje te mogą obchodzić współczesne mechanizmy obronne systemu (np. nowoczesną izolację w piaskownicy czy restrykcyjne zarządzanie uprawnieniami).

Model podpisywania aplikacji: F-Droid sam buduje kod i podpisuje pakiety własnym kluczem kryptograficznym, zamiast kluczem dewelopera. Centralizuje to zaufanie (w razie kompromitacji serwerów F-Droida zagrożone są aktualizacje) i uniemożliwia łatwą migrację na oficjalne wydania (np. z GitHuba) z powodu konfliktu podpisów.

Zacofany instalator: Oficjalny klient przez lata ignorował nowoczesne, bezpieczne API systemowe Androida służące do zarządzania pakietami. Wprowadzanie tak podstawowych funkcji jak automatyczne i bezobsługowe aktualizacje w tle (Unattended Updates) zajęło im lata, co mocno odstaje od dzisiejszych standardów UX i security.

Właśnie dlatego w świecie GrapheneOS standardem staje się pobieranie aplikacji FOSS bezpośrednio od deweloperów (np. przez Obtainium)

@meridian a jaką masz pewność że deweloper czegoś nie dokleił? Przypomnę tylko agenta Tactical RMM do którego dev dodał koparkę. Poza tym nie wiem dlaczego winisz fdroida za stare SDK aplikacji w nim będących. To nie powinno być rola deva?

@kayo77 Przypadek Tactical RMM to świetny przykład, ale dotyczył systemu desktopowego, gdzie aplikacja uruchomiona z uprawnieniami administratora ma pełny dostęp do wszystkiego. Na GrapheneOS architektura opiera się na zasadzie zerowego zaufania do kodu (Zero Trust) i rygorystycznej izolacji (sandboxingu). F-Droid w żaden sposób nie audytuje kodu pod kątem ukrytych złośliwych funkcji (jak wspomniana koparka) – sprawdza jedynie, czy jest on otwartoźródłowy. Przed złośliwym deweloperem nie chroni sklep, a wyłącznie piaskownica systemu operacyjnego.

Co do Target SDK: naturalnie, to deweloper pisze kod, ale to polityka F-Droida pozwala na dystrybucję porzuconych i potencjalnie niebezpiecznych aplikacji. Dla porównania – Google Play czy repozytoria zgodne z Verified Apps od Privacy Guides usuwają pakiety niespełniające współczesnych standardów bezpieczeństwa. F-Droid świadomie akceptuje i dystrybuuje aplikacje ze starym SDK, które mogą omijać nowoczesne mechanizmy obronne Androida.

Właśnie dlatego mój obecny setup eliminuje te ryzyka i przewyższa model F-Droida:

Używam Obtainium, więc pobieram oryginalne paczki bezpośrednio z wydań dewelopera, bez pośrednictwa serwerów F-Droida (w przypadku F-Droida kompromitacja ich serwera oznacza zagrożenie dla wszystkich aplikacji podpisanych ich centralnym kluczem).

Używam App Verifiera, który pilnuje integralności i automatycznie weryfikuje podpisy kryptograficzne.

Dodatkowo bazuję na weryfikacji skrótów kryptograficznych (SHA-256) dostarczanych i sprawdzanych przez zaufaną społeczność na forum GrapheneOS.

Taki model (Decentralizacja + Kryptografia + Silny Sandboxing) daje mi realne, techniczne bezpieczeństwo. F-Droid daje często złudne poczucie ochrony, oparte na ślepym zaufaniu do jednej, centralnej instytucji.

@meridian @kayo77
>F-Droid daje często złudne poczucie ochrony, oparte na ślepym zaufaniu do jednej, centralnej instytucji.

Zarzut, który rykoszetuje przeciw GNU/Linuksowi. Oficjalne repozytoria z dystrybucji typu Debian/Ubuntu/Fedora/(...) sprowadzają się do traktowania wszystkich programów - od jądra i usług systemowych, przez pakiety biurowe i przeglądarki, do gier jako integralnych części systemu operacyjnego...

@74 Argument o elektrośmieciach wynika z mylenia dwóch parametrów. O tym, na jak starym telefonie ruszy aplikacja, decyduje minSdkVersion. Podnoszenie bezpieczeństwa kodu nie odcina starych urządzeń. Z kolei targetSdkVersion to informacja dla nowych systemów (jak Android 14/15 czy GrapheneOS), jak aplikacja ma chronić dane. Jeśli deweloper utrzymuje tam stary numerek, to po to, by program na nowym smartfonie mógł legalnie omijać restrykcje prywatności (np. dostęp do schowka czy lokalizację). Akceptując takie pakiety, F-Droid pozwala na dziurawienie mechanizmów obronnych systemu.

Porównanie do repozytoriów Debiana czy Fedory to błąd logiczny. Na desktopie soft z repo ma domyślnie dostęp do całego katalogu domowego (/home) może czytać klucze SSH czy sesje przeglądarek. Tam zaufanie do repozytorium musi być absolutne. Na GrapheneOS rządzi bezkompromisowy sandboxing na poziomie jądra. System nie ufa nikomu i dzięki Storage Scopes izoluje programy tak głęboko, że nie widzą one plików innych aplikacji. To nie sklep ma mnie chronić przed złośliwym kodem, od tego jest pancerna piaskownica OS.

Skoro system i tak izoluje kod, kluczowa staje się zdecentralizowana kryptografia. F-Droid w głównym repozytorium domyślnie sam kompiluje kod i podpisuje paczki swoim centralnym kluczem kompromitacja ich infrastruktury tworzy gigantyczne ryzyko dla całego softu naraz. W moim setupie z Obtainium omijam ten problem i pobieram paczki podpisane unikalnymi kluczami deweloperów bezpośrednio z ich GitHubów. Za kontrolę integralności odpowiada App Verifier, wspierany przez weryfikację skrótów SHA-256 przez społeczność GrapheneOS. F-Droid sprawdza jedynie licencję, a nie złośliwe funkcje. Ślepe zaufanie do niego to podejście z 2010 roku. Model silny sandbox + Obtainium to po prostu kolejny etap ewolucji.

@meridian @kayo77 większość urządzeń z Androidem ma wersję z 2023 (ukazała się wtedy 14) roku lub nawet starszą https://gs.statcounter.com/os-version-market-share/android/mobile-tablet/worldwide

Porzucanie starych SDK to zamienianie starego sprzętu w elektrośmieci

Inna sprawa, jak stare SDK jest akceptowane przez F-Droida...

Mobile & Tablet Android Version Market Share Worldwide | Statcounter Global Stats

This graph shows the market share of mobile & tablet android versions worldwide based on over 3 billion monthly page views.

StatCounter Global Stats