Niebezpieczne obejście blokady blokady karty SIM – zaktualizuj Androida już teraz!

Łowca nagród za błędy, David Schütz, właśnie opublikował szczegółowy raport opisuje, jak przez kilka miesięcy skrzyżował miecze z Google nad czymś, co uważał za niebezpieczną lukę w zabezpieczeniach Androida.

Według Schütza, całkowicie przypadkowo natknął się na błąd związany z obejściem ekranu blokady Androida w czerwcu 2022 r., w rzeczywistych warunkach, które z łatwością mogły przydarzyć się każdemu.

Innymi słowy, rozsądnie było założyć, że inne osoby mogą dowiedzieć się o luce bez celowego szukania błędów, przez co jej odkrycie i publiczne ujawnienie (lub prywatne nadużycie) jako dziury zero-dniowej jest znacznie bardziej prawdopodobne niż zwykle.

Niestety, został załatany dopiero w listopadzie 2022 r., dlatego ujawnił go dopiero teraz.

Nieoczekiwana awaria baterii

Mówiąc najprościej, znalazł błąd, ponieważ zapomniał wyłączyć lub naładować telefon przed wyruszeniem w długą podróż, pozostawiając urządzenie niezauważone, gdy był w drodze.

Według Schütza spieszył się z wysłaniem wiadomości po powrocie do domu (domyślamy się, że był w samolocie) z niewielką ilością energii w akumulatorze…

…gdy padł telefon.

Wszyscy tam byliśmy, szukaliśmy ładowarki lub zapasowego zestawu baterii, aby ponownie uruchomić telefon, aby ludzie wiedzieli, że dotarliśmy bezpiecznie, czekamy na odbiór bagażu, dotarliśmy na stację kolejową, spodziewamy się, że wrócimy do domu za 45 minut, może zatrzymać się w sklepach, jeśli ktoś pilnie czegoś potrzebuje, lub cokolwiek mamy do powiedzenia.

I wszyscy zmagaliśmy się z hasłami i kodami PIN, gdy się spieszymy, zwłaszcza jeśli są to kody, których rzadko używamy i nigdy nie rozwinęliśmy „pamięci mięśniowej” do pisania.

W przypadku Schütza to skromny kod PIN na karcie SIM go zaskoczył, a ponieważ kody PIN karty SIM mogą być tak krótkie, jak cztery cyfry, są one chronione przez blokadę sprzętową, która ogranicza do maksymalnie trzech zgadnięć. (Byliśmy tam, zrobiliśmy to, zamknęliśmy się.)

Następnie należy wprowadzić 10-cyfrowy „główny PIN” znany jako PUK, skrót od osobisty klucz odblokowujący, który jest zwykle drukowany wewnątrz opakowania, w którym sprzedawana jest karta SIM, co czyni ją w dużej mierze zabezpieczoną przed manipulacją.

Aby chronić się przed atakami zgadywania PUK, karta SIM automatycznie smaży się po 10 błędnych próbach i musi zostać wymieniona, co zwykle oznacza wizytę w sklepie z telefonami komórkowymi z identyfikacją.

Co zrobiłem z tym opakowaniem?

Na szczęście, ponieważ bez niego nie znalazłby błędu, Schütz znalazł oryginalne opakowanie karty SIM schowane gdzieś w szafce, zdrapał pasek ochronny zasłaniający kod PUK i wpisał go.

W tym momencie, biorąc pod uwagę, że był w trakcie uruchamiania telefonu po tym, jak zabrakło mu zasilania, powinien zobaczyć ekran blokady telefonu, żądający wpisania kodu odblokowującego telefonu…

…ale zamiast tego zdał sobie sprawę, że był na niewłaściwym ekranie blokady, ponieważ oferował mu możliwość odblokowania urządzenia tylko za pomocą odcisku palca.

To powinno się zdarzyć tylko wtedy, gdy telefon zablokuje się podczas regularnego użytkowania i nie powinno się to zdarzyć po wyłączeniu i ponownym uruchomieniu, gdy pełne ponowne uwierzytelnienie kodu dostępu (lub jeden z tych „kodów wzorców” przeciągnij, aby odblokować) ) powinno być egzekwowane.

Czy na twoim ekranie blokady naprawdę jest „blokada”?

Jak zapewne wiesz z wiele razy mamy napisane o błędy na ekranie blokady przez lata w Naked Security problem ze słowem „blokada” na ekranie blokady polega na tym, że po prostu nie jest to dobra metafora do przedstawiania tego, jak złożony jest kod zarządzający procesem „blokowania” i „odblokowywania” nowoczesnych telefonów.

Nowoczesny mobilny ekran blokady jest trochę jak drzwi wejściowe do domu, w których zamontowano przyzwoitą jakość zasuwkę…

…ale ma też skrzynkę na listy (skrzynka na listy), szklane panele wpuszczające światło, klapkę dla kota, zamykany zamek sprężynowy, na którym nauczyłeś się polegać, bo rygiel jest trochę kłopotliwy, oraz zewnętrzny bezprzewodowy dzwonek do drzwi/ kamera bezpieczeństwa, którą łatwo ukraść, mimo że zawiera hasło do sieci Wi-Fi w postaci zwykłego tekstu i ostatnie 60 minut nagranego materiału wideo.

Aha, a w niektórych przypadkach nawet bezpiecznie wyglądające drzwi wejściowe i tak będą miały klucze „ukryte” pod wycieraczką, co jest prawie sytuacją, w której znalazł się Schütz na swoim telefonie z Androidem.

Mapa krętych korytarzy

Nowoczesne ekrany blokady telefonu służą nie tyle do blokowania telefonu, co do ograniczania aplikacji do ograniczonych trybów działania.

Zwykle pozostawia to Tobie i Twoim aplikacjom dostęp na ekranie blokady do bogatej gamy funkcji „specjalnych przypadków”, takich jak aktywacja aparatu bez odblokowywania lub wyświetlanie wyselekcjonowanego zestawu powiadomień lub wierszy tematów wiadomości e-mail, w których każdy może je zobaczyć bez hasło.

To, na co natknął się Schütz, w zupełnie nietypowej sekwencji operacji, było błędem w czymś, co w żargonie nazywa się lockscreenem. maszyna stanowa.

Maszyna stanów jest rodzajem wykresu lub mapy warunków, w jakich może znajdować się program, wraz z legalnymi sposobami, w jakie program może przechodzić z jednego stanu do drugiego, takich jak przełączanie połączenia sieciowego z „nasłuchiwania” na „ podłączony”, a następnie z „połączony” na „zweryfikowany” lub ekran telefonu przełącza się z „zablokowanego” na „odblokowywalny odciskiem palca” lub „odblokowywalny, ale tylko za pomocą hasła”.

Jak możesz sobie wyobrazić, automaty stanowe do złożonych zadań szybko się komplikują, a mapa różnych ścieżek prawnych z jednego stanu do drugiego może być pełna zwrotów akcji…

…a czasami egzotyczne tajne przejścia, których nikt nie zauważył podczas testów.

Rzeczywiście, Schütz był w stanie przełożyć swoje nieumyślne odkrycie kodu PUK na ogólne obejście blokady ekranu, dzięki któremu każdy, kto podniósł (lub ukradł lub w inny sposób miał do niego krótki dostęp) zablokowane urządzenie z Androidem, mógł oszukać je w stanie odblokowanym, uzbrojony jedynie w nowa własna karta SIM i spinacz do papieru.

Jeśli się zastanawiasz, spinacz do papieru ma wysunąć kartę SIM znajdującą się już w telefonie, abyś mógł włożyć nową kartę SIM i wprowadzić telefon w stan „Muszę poprosić o kod PIN do tej nowej karty SIM ze względów bezpieczeństwa”. Schütz przyznaje, że kiedy udał się do biura Google, aby zademonstrować hack, nikt nie miał odpowiedniego wyrzutnika karty SIM, więc najpierw wypróbowali igłę, którą Schütz zdołał się dźgnąć, zanim udało mu się pożyczyć kolczyk. Podejrzewamy, że wbicie igły w czubek najpierw nie zadziałało (ciężko trafić małym czubkiem w kołek wypychacza), więc zdecydował się zaryzykować użycie igły skierowanej na zewnątrz, będąc „naprawdę ostrożnym”, zamieniając w ten sposób próbę hakowania w dosłowną włamać się. (Byliśmy tam, zrobiliśmy to, wbiliśmy się w czubek palca.)

Granie systemu z nową kartą SIM

Biorąc pod uwagę, że atakujący zna zarówno PIN, jak i PUK nowej karty SIM, może celowo trzykrotnie pomylić PIN, a następnie natychmiast uzyskać prawidłowy PUK, w ten sposób celowo zmuszając maszynę stanu blokady ekranu do stanu niepewnego, który Schütz odkrył przypadkowo.

W odpowiednim czasie Schütz odkrył, że może nie tylko wylądować na stronie odblokowania odcisku palca, gdy nie powinna się ona pojawić, ale także oszukać telefon, aby zaakceptował pomyślne odblokowanie kodu PUK jako sygnał do zamknięcia ekranu odcisku palca i „sprawdzić” cały proces odblokowania jakby wpisał pełny kod blokady telefonu.

Odblokuj obejście!

Niestety, większość artykułu Schütza opisuje czas, jaki zajęło Google zareagowanie na tę lukę i naprawienie tej luki, nawet po tym, jak inżynierowie firmy zdecydowali, że błąd rzeczywiście można powtórzyć i wykorzystać.

Jak ujął to sam Schütz:

To była najbardziej znacząca luka, jaką do tej pory znalazłem, i przekroczyła dla mnie granicę, w której naprawdę zacząłem się martwić o oś czasu naprawy, a nawet o zachowanie jej jako „tajemnicy”. Może przesadzam, ale nie tak dawno FBI walczyło z Apple o prawie to samo.

Opóźnienia w ujawnieniu

Biorąc pod uwagę podejście Google do ujawniania błędów, z własnym zespołem Project Zero notorycznie zdecydowanym o potrzebie ustalenia ścisłych terminów ujawniania i trzymaj się ich, można było oczekiwać, że firma będzie przestrzegać zasad dotyczących 90 dni plus 14 dodatkowych przypadków w szczególnych przypadkach.

Ale według Schütza Google nie poradzi sobie w tym przypadku.

Najwyraźniej uzgodnił datę w październiku 2022 r., do której planował publicznie ujawnić błąd, tak jak teraz to zrobił, co wydaje się być wystarczającą ilością czasu na błąd, który odkrył w czerwcu 2022 r.

Ale Google nie dotrzymał tego październikowego terminu.

Łatka dla usterki, oznaczona numerem błędu CVE-2022-20465, w końcu pojawiła się w łatkach bezpieczeństwa Androida z listopada 2022 r., z dnia 2022, z Google opisując poprawkę jako: „Nie wyłączaj blokady klawiatury po odblokowaniu karty SIM PUK”.

Z technicznego punktu widzenia błąd był znany: warunki wyścigu, gdzie część systemu operacyjnego, która obserwowała proces wprowadzania PUK, aby śledzić „czy można teraz bezpiecznie odblokować kartę SIM?” stan zakończył się wygenerowaniem sygnału sukcesu, który przebił kod, który jednocześnie śledził „czy można bezpiecznie odblokować całe urządzenie?”

Mimo to Schütz jest teraz znacznie bogatszy dzięki wypłacie Google za bug bounty (jego raport sugeruje, że liczył na 100,000 70,000 USD, ale ostatecznie musiał zadowolić się XNUMX XNUMX USD).

I wstrzymał się z ujawnieniem błędu po terminie 15 października 2022, akceptując, że dyskrecja jest czasem lepszą częścią męstwa, mówiąc:

[Byłem] zbyt przestraszony, aby faktycznie zgasić live bug, a ponieważ naprawa była za niecały miesiąc, to i tak nie było tego warte. Postanowiłem poczekać na poprawkę.

Co robić?

Sprawdź, czy Twój Android jest aktualny: Ustawienia > Bezpieczeństwo > Aktualizacja bezpieczeństwa > Sprawdź aktualizacje.

Zauważ, że kiedy odwiedziliśmy Aktualizacja bezpieczeństwa ekranie, od jakiegoś czasu nie korzystając z naszego telefonu Pixel, odważnie ogłosił Android Twój system jest aktualny, pokazując, że sprawdził automatycznie minutę wcześniej, ale nadal mówi nam, że jesteśmy na October 5, 2022 aktualizacja zabezpieczeń.

Wymusiliśmy ręczne sprawdzenie nowej aktualizacji i natychmiast zostaliśmy poinformowani Przygotowuję aktualizację systemu…, po czym następuje krótkie pobranie, długi etap przygotowawczy, a następnie żądanie ponownego uruchomienia.

Po ponownym uruchomieniu dotarliśmy do November 5, 2022 poziom patcha.

Potem wróciliśmy i zrobiliśmy jeszcze jedno Sprawdź aktualizacje aby potwierdzić, że nie ma jeszcze żadnych poprawek.

---

Użyliśmy Ustawienia > Bezpieczeństwo > Aktualizacja bezpieczeństwa aby przejść do strony wymuszenia pobrania:

---

Zgłoszona data wydawała się nieprawidłowa, więc zmusiliśmy Androida do Sprawdź aktualizacje w każdym razie:

---

Rzeczywiście była aktualizacja do zainstalowania:

---

Zamiast czekać, użyliśmy Resume aby kontynuować od razu:

---

Nastąpił długi proces aktualizacji:

---

Zrobiliśmy jeszcze jeden Sprawdź aktualizacje aby potwierdzić, że tam byliśmy:

---