Bezpłatne Dni Otwarte Sekurak Academy! Hackowanie na żywo, szkolenia, ebooki, …
Prawdopodobnie bez problemu można odblokować Twojego Androida – mając do niego fizyczny dostęp.
Taki przypadek wydarzył się niedawno w Serbii, gdzie do odblokowania telefonu studenta (Samsung Galaxy) użyto oprogramowania Cellebrite:
the Android phone of one student protester was exploited and unlocked by a sophisticated zero-day exploit chain targeting Android USB drivers, developed by Cellebrite.
Student zatrzymany przez policję wręczył im wyłączony telefon. Po jakimś czasie odebrał ten telefon również w stanie wyłączonym. Czyli wszystko OK? Niekoniecznie. Popatrz na tego loga z wydarzeń, opracowanego przez Amnesty International:
W celu uzyskania dostępu do danych z telefonu użyto narzędzi Cellebrite. Wymagało to fizycznego dostępu i podpięcia do telefonu za pomocą USB. Samo narzędzie Cellebrite symulowało podłączaną przez USB kamerę / kartę dźwiękową. W jakim celu? Aby wykorzystać podatność w sterownikach USB, które pracują z uprawnieniami jądra systemu Linux / Android (czyli w zasadzie maksymalnymi). Po skutecznym wykorzystaniu luki, narzędzie umożliwia na dostęp root (administrator) na telefonie.
Telefon (Android) mógł być wtedy nawet w pełni załatany… i nic by to nie dało, bo w akcji użyto podatności 0day (niezałatanej, nieznanej Googlowi).
Teraz kolejna niemiła informacja – podatność nie była związana z konkretnym modelem telefonu (czy wersją Androida); co więcej dotyka też systemu Linux. W skrócie – ogrom niezałatanych telefonów ale też laptopów z systemem Linux mogą być podatne:
As the exploit targets core Linux kernel USB drivers, the impact is not limited to a particular device or vendor and could affect a very wide range of devices
Podatność CVE-2024-53104 została załatana przez Google (w Androidzie) – w lutowym wydaniu łatek bezpieczeństwa (2025). Co ciekawe, w Linuksie łatka dostępna była już w listopadzie 2024. Co być może jeszcze ciekawsze, podatność została wprowadzona (zapewne przypadkiem) około 15 lat temu (!). To nie koniec, w Linuksie załatano dwie podobne podatności (CVE-2024-53197, CVE-2024-50302), ale na razie nie są one załatane w Androidzie.
No dobra, ale da się przed tym jakoś chronić?
- Warto oczywiście aplikować łatki bezpieczeństwa, ale w opisywanym przypadku niewiele by to pomogło… (podatność była klasy 0-day). Co więcej, różni producenci telefonów łatki zaaplikują z opóźnieniem… albo i nie zaaplikują.
- Można próbować działać tak jak zasugerował Krzysiek na naszym profilu TT:
- Na sekurakowym profilu TT wypowiedziała się też ekipa GrapheneOS. Ten ostatni, to utwardzona pod względem bezpieczeństwa wersja Androida:
Garść dodatkowych informacji w temacie opisywanego tematu – z perspektywy GrapheneOS można znaleźć tutaj.
~Michał Sajdak
Dziwne, że Samsung dodał opcje maksymalnego ograniczenia która całkowicie wyłączała USB (działało tylko ładowanie) nawet na odblokowanym tel nic po USB nie działało. Dodali tą funkcje jakoś pod koniec 2024 i bardzo szybko jakoś po 1-2 miesiącach skasowali.
Obecnie jest 1 opcja opisana w artykule czyli blokowanie po godzinie jak tel zablokowany (szkoda, że nie da się tego jakoś dostosować i blokować szybciej :( ) Ciekawe jak ta funkcja zachowuje się przy wyłączonym telefonie, czy też musi być min godzinę wyłączony ?
I w ustawieniach automatycznej blokady po jej aktywowaniu blokowane są polecenia wydawane przez USB oraz blokuje aktualizacje oprogramowania przez USB ciekawe czy coś by to zmieniło w opisanej sytuacji.
Dziwi mnie fakt, że nie da się jakoś bardziej blokować tego USB, zwłaszcza, że na krótko dodali taką funkcje więc da się, tylko czemu to skasowali !?