Ryzyko związane z alternatywnymi klawiaturami w iOS

Chcąc być bezpiecznym, trzeba dmuchać na zimne, czyli nie włączać trybu pełnego dostępu.

Nowe możliwości, nowe rodzaje ryzyka

Począwszy od wprowadzenia do użytku iOS 8, użytkownicy otrzymali możliwość instalowania klawiatur innych niż fabrycznie dostarczone przez Apple. Dla fanów Androida ta „nowa wspaniała funkcja” była znana już od dawna, a jej późne pojawienie się w systemie Apple’a stało się powodem do drwin. Pomińmy to jednak na chwilkę i skoncentrujmy się na szczegółach technicznych alternatywnych klawiatur oraz niesionych przez nie nowych wyzwań w obszarze bezpieczeństwa.

Już we wrześniu 2014 roku pojawiły się głosy kwestionujące bezpieczeństwo przyjętych rozwiązań. Zewnętrzny, tylko powierzchownie zweryfikowany kod, uzyskuje dostęp zarówno do wprowadzanych informacji, jak i przesyłania ich swobodnie do chmury. Wszystko oczywiście pod pretekstem optymalizacji działania klawiatury.

Postanowiłem zatem rzucić trochę światła na ten budzący wątpliwości obszar bezpieczeństwa i prywatności.

App Extensions

iOS od wersji 8 pozwala na tworzenie różnorodnych rozszerzeń aplikacji. Rozszerzenia te podlegają narzuconym przez Apple restrykcjom i współdzielą zdefiniowaną odgórnie architekturę. Alternatywne dla systemowych klawiatury są specyficznym typem App Extension, zatem dla zrozumienia ryzyka związanego z klawiaturami musimy najpierw poznać strukturę rozszerzeń aplikacji jako takich.

App Extensions nie są bezpośrednio dostępne w App Store / iTunes. Każde rozszerzenie jest dostarczane poprzez stowarzyszoną z nim aplikację. Jeden taki kontener może zawierać nawet kilka rozszerzeń.

To bardzo ważna obserwacja, którą za chwilę zajmiemy się w szczegółach.

Ogólne ograniczenia

Dokumentacja deweloperska iOS 8/9/10 jest publicznie dostępna, zatem możemy swobodnie przedyskutować to, co mówi o interesujących nas rozszerzeniach aplikacji. Można oczywiście przekopać się przez całość samodzielnie, ale na potrzeby tego artykułu zrobiłem skondensowany wyciąg z linkami prowadzącymi do oryginalnych dokumentów.

Ograniczenia narzucone na wszystkie rodzaje rozszerzeń są wymienione w “Some APIs Are Unavailable to App Extensions”. Kluczowe punkty to:

• Dostęp do obiektu* sharedApplication* lub jakiegokolwiek API oznaczonego jako NSEXTENSIONUNAVAILABLE jest zablokowany. Innymi słowy, są obszary iOS, które w ogóle nie są dostępne dla rozszerzeń .
• HealthKit i EventKit są kompletnie zablokowane i niedostępne.
• To samo tyczy się kamer i mikrofonów.
• Nie można tworzyć długoterminowych procesów w tle.
• Rozszerzenia nie mogą otrzymywać danych przez AirDrop.

Ograniczenia klawiatur alternatywnych

Poza ograniczeniami ogólnymi klawiatury niestandardowe podlegają dodatkowym restrykcjom. Poniższe dotyczy tylko klawiatur niedostarczanych z system operacyjnym:

• Większość ustawień z obszaru Ustawienia > Ogólne > Klawiatura(Settings > General > Keyboard) nie jest dostępna dla klawiatur rozszerzonych. Tak właśnie określa to oficjalna dokumentacja – „większość”.
• Bezpieczne pola wprowadzania tekstu (np. prawidłowo zakodowane pole dla hasła) powodują automatyczne przełączenie do trybu klawiatury systemowej aż do momentu przejścia do pola zwykłego. *Dostęp do obiektów „klawiatury telefonicznej” jest zablokowany, włączając w to obsługę wprowadzania informacji do pól zdefiniowanych jako numeryczne.
• Aplikacje mogą aktywnie wymuszać blokadę dostępu dla klawiatur alternatywnych. Tak to powinno być zaimplementowane we wszystkich aplikacjach przetwarzających informacje poufne, na przykład tych obsługujących bankowość elektroniczną.
• Klawiatura niestandardowa nie może zaznaczać tekstu.
• Klawiatura nie może wyświetlać niczego poza obszarem swojego działania. Chodzi o wizualną restrykcję pola graficznego tylko do obszaru klawiatury (który de facto może być przez nią swobodnie definiowany). Te ograniczenia funkcjonują niezależnie od poziomu zaufania udzielonego przez użytkownika klawiaturze. Stanowi to bardzo solidną podstawę dla dalszych rozważań na temat bezpieczeństwa tych nowych rozwiązań.

Sandbox

Domyślnie, gdy deweloper tworzy nową klawiaturę alternatywną, otrzymuje ona bardzo ograniczony dostęp i pracuje w niezwykle restrykcyjnym sandboksie. Klawiatura nie ma dostępu do sieci oraz nie może współdzielić kontenera ze stowarzyszoną z nią aplikacją.

Tak jest domyślnie, jednak klawiatura może zażądać udzielenia dodatkowych uprawnień, co oczywiście rodzi pytania o poziom zaufania dla twórcy oprogramowania. I to właśnie ten obszar wydaje się najbardziej problematyczny. Apple jasno zdefiniowało standardowe możliwości niekorzystającej z sieci klawiatury zewnętrznej oraz uprawnienia klawiatur o pełnym dostępie do sieci.

Ten podział rozjaśnia nieco znaczenie słowa „większość” użytego w dokumentacji. Można go odnaleźć w tabeli 8-1 („Designing for User Trust”).

Podsumowując, klawiatura bez dostępu do sieci może pracować tylko jako klawiatura, a jeśli użytkownik pozwoli jej na korzystanie z sieci, staje się pełnoprawną aplikacją.

Polityka App Store

Poza restrykcjami sandboksowymi każda klawiatura alternatywna musi spełniać wymogi narzucone przez polityki App Store, jeśli chce mieć szansę na publikację. Dokładnie cytując sekcję 25 App Store Review Guidelines:

• 25.1 Aplikacje przenoszące rozszerzenia muszą być zgodne z App Extension Programming Guide.
• 25.2 Aplikacje przenoszące rozszerzenia muszą zapewniać jakąś funkcjonalność (np. ekrany pomocy, dodatkowe ustawienia) albo będą odrzucone.
• 25.3 Aplikacje przenoszące rozszerzenia, które zawierają przekaz marketingowy, reklamy lub wymuszają zakupy „in-app” w widoku rozszerzenia (gdy klawiatura jest aktywna i widoczna dla użytkownika) będą odrzucone.
• 25.4 Rozszerzenia klawiaturowe muszą zapewniać metodę przełączania na następną klawiaturę.
• 25.5 Rozszerzenia klawiaturowe muszą działać nawet bez dostępu do sieci albo zostaną odrzucone.
• 25.6 Rozszerzenia klawiaturowe muszą udostępniać tryb klawiatury numerycznej opisany w App Extension Programming Guide albo zostaną odrzucone.
• 25.7 Aplikacje oferujące rozszerzenia klawiaturowe muszą mieć główną kategorię „Utilities” oraz dołączoną politykę prywatności albo zostaną odrzucone.
• 25.8 Aplikacje oferujące rozszerzenia klawiaturowe mogą zbierać informacje o aktywności użytkownika jedynie w celu poprawienia funkcjonalności klawiatury na urządzeniu iOS albo zostaną odrzucone. Pomimo że powyższe reguły mają bardzo szeroki kontekst, w punkcie 25.8 Apple kładzie szczególny nacisk na zrozumienie przez deweloperów, jaki rodzaj informacji o użytkowniku klawiatura może zbierać, a jakich nie.

Klawiatury bez dostępu do sieci

Wygląda na to, że klawiatury bez dostępu do sieci nie stanowią dla użytkownika większego zagrożenia. Nie mogą komunikować się z goszczącą je aplikacją poza wstawianiem i usuwanie tekstu. W takiej konfiguracji nie mogą nawet komunikować się z przenoszącą je aplikacją-kontenerem.

Oczywiście pozostaje im opcja lokalnego składowania wszystkich ruchów użytkownika, wszystkich naciśnięć klawiszy, ale w obliczu braku komunikacji sieciowej na wiele się to nie zda. W oddzielnej pracy spróbuję prześledzić przykładowy kod w celu przetestowania skuteczności tych ograniczeń sandboksu.

Każda próba przechowywania i przetwarzania sekwencji klawiszy powinna wzbudzić poważne wątpliwości co do polityki prywatności, ale alternatywna klawiatura bez dostępu do sieci wydaje się nie stwarzać tego rodzaju ryzyka.

Sieć oznacza pełne zaufanie

Podczas gdy dokumentacja deweloperska Apple jest szczególnie precyzyjna w odniesieniu do prywatności i zaufania użytkownika, terminologia używana w samym iOS jest bardzo myląca. W rzeczywistości to, co w dokumentacji nazywane jest „klawiaturą z dostępem do sieci”, jest tak naprawdę klawiaturą z włączonym „Pełnym Dostępem” („Full Access”).

To ustawienie byłoby jeszcze lepiej zrozumiałe, gdyby nazywało się „Pełne Zaufanie” (“Full Trust”), ponieważ nadawany za jego pomocą wzrost uprawnień nie ogranicza się tylko do dostępu sieciowego.

Klawiatury obdarzone pełnym zaufaniem

Dobra wiadomość jest taka, że to od użytkownika zależy nadanie pełnych uprawnień klawiaturze.

Zła wiadomość jest odpowiedzią na pytanie: co taka klawiatura może robić, gdy użytkownik już podejmie decyzję o nadaniu jej pełnych uprawnień?

Nagle klawiatura może wymieniać informacje z przenoszącą ją aplikacją-kontenerem (poprzednio nie było to możliwe). Informacje, które klawiatura przekaże aplikacji-matce, mogą następnie być wysłane gdziekolwiek i to bez wiedzy użytkownika.

Poza współdzieleniem sandboxu z aplikacją-matką, klawiatura uzyskuje dostęp do usług lokalizacyjnych oraz książki adresowej (wymagane zezwolenie użytkownika). Dostęp do sieci jest możliwy także bezpośrednio, a każde użycie klawiatury może być przesłane, gdzie tylko deweloper sobie zażyczy.

Z niewyjaśnionych powodów klawiatura ma też dostęp do Game Center (przez aplikację-kontener). Aplikacja ta ma też możliwość oferowania „in-app purchase” w celu rozszerzania funkcjonalności lub jakimkolwiek innym celu biznesowym wymyślonym przez twórcę oprogramowania.

Włączając „Pełny Dostęp” klawiaturze alternatywnej, użytkownik wystawia się na znacznie większe ryzyko niż początkowo oceniał i co sugerował Apple. Ta konfiguracja jest tak podatna na nadużycia, że w momencie jej włączenia wyświetlane jest nawet ostrzeżenie. Jest ono tak szerokie, że użytkownik powinien się zastanowić, po co w ogóle stworzono takie rozszerzenia. Tylko kto by się nad tym zastanawiał w obliczu nowej ekscytującej funkcjonalności…

Co znajdziemy w App Store

Żeby zaoszczędzić czytelnikom wysiłku, przetestowałem kilka klawiatur dostępnych w App Store. W razie zapytań odnośnie niewymienionych w zestawieniu klawiatur, tabela może być na bieżąco aktualizowana.

Większość poniżej wymienionych klawiatur oferuje jakąś funkcjonalność bez włączania „Pełnego Dostępu”. Dla ułatwienia odbioru wyróżniłem te, które namawiają użytkownika do nadania im pełnych uprawnień. W kolumnie „Domyślne” pokazałem klawiatury bez pełnego dostępu, w kolumnie „Pełny Dostęp” można zobaczyć, jak wyglądają po nadaniu pełnych uprawnień.

Flesky

(nie żąda pełnego dostępu)

KauiBoard

(żąda pełengo dostępu)

Minuum

(nie żąda pełnego dostepu)

MyScript

(żąda pełnego dostępu)

Riffsy

(żąda pełnego dostępu)

SwiftKey

(żąda pełnego dostępu)

Swype

(nie żąda pełnego dostępu)

Powyższe zestawienie to oczywiście bardzo mała próbka, ale – zważywszy na „ciasnotę” domyślnego sandboxa – przypuszczam, że coraz więcej klawiatur będzie żądało pełnego dostępu.

Zagrożenie

Można się oczywiście nonszalancko stwierdzić „i co z tego?”. Najczęściej pada także argument, że użytkownika nie obchodzi to, co się dzieje z informacjami o naciskanych przez niego klawiszach.

Weźmy jako przykład klawiaturę Riffsy (tę od animowanych GIF-ów). Zwykły użytkownik postrzega ją jako proste narzędzie pozwalające na upiększenie pisanych wiadomości. Oczywiście podkreślanie emocji przez animowane GIF-y jest zapewne bardzo ekscytujące, ale niesie ze sobą kilka problemów.

Riffsy zapewnia oprócz GIF-ów także „standardową” klawiaturę (która wygląda jak systemowa), aby użytkownik nie musiał przełączać się ciągle między klawiaturą systemową i rozszerzoną. Oczywiście wszystko, co wpisze się poprzez „standardową” klawiaturę Riffsy, jest wysyłane do ich serwerów w celu „analizy”.

I nie chodzi tu o jakąś dyskryminację tego konkretnego producenta klawiatury, ale o wskazanie konieczności przeczytania i zatwierdzenia – najczęściej niezwykle długich i złożonych – warunków użytkowania i polityki prywatności. Któż je czyta? Przecież najczęściej naciskane jest „OK”, aby jak najszybciej zacząć korzystać z nowej zabawki. A kto ma prawo do jednostronnego zmieniania tych warunków i to bez powiadamiania użytkownika? Odpowiedź pozostawiam w gestii czytelników.

Spotykam się z kontrargumentem, że jeśli ktoś postrzega tu problem prywatności, to zawsze może włączać klawiaturę rozszerzoną tylko w momencie chęci wysłania GIF-a… Ale jest to przecież bardzo niewygodne i większość użytkowników pozostanie przy ulubionych ustawieniach. Zatem nie jest to rozwiązanie kwestii bezpieczeństwa.

Każda informacja, która pojawi się w zdefiniowanym przez klawiaturę alternatywną polu wprowadzania, jest dla niej dostępna. Oznacza to, że wszystko to, co użytkownik wprowadza w wykorzystywanych codziennie aplikacjach, jest dostępne dla dewelopera klawiatury, o ile otrzymał pozwolenie na „Pełny Dostęp”.

Rekomendacje

Po wykonaniu analizy zagrożeń bardzo rzadko można wysnuć jeden, ogólny wniosek. Ale w tym przypadku jest inaczej – moja rekomendacja jest bardzo prosta:

Nie używaj klawiatury, która wymaga od Ciebie nadania uprawnień „Pełnego Dostępu”!

Jeśli klawiatura może działać bez takich wyższych uprawnień, według mojej oceny można mieć wysoki poziom pewności, że Twoje dane są bezpieczne.

Zapraszam po więcej informacji na blog.trendmicro.pl Tekst oryginalny autorstwa Marka Nunnikhovena (@marknca).

Uwagi uzupełniające

1. W ustawieniach ogólnych klawiatury nie ma niczego, co wpływałoby na kwestie bezpieczeństwa i prywatności. Ustawienia dotyczą korzystania ze skrótów, autopoprawek, sprawdzania pisowni etc.
2. Aplikacja przenosząca klawiaturę Swype objaśnia znaczenie „Pełnego dostępu” i prosi użytkownika o włączenie tych uprawnień w celu uruchomienia funkcji „Guided Access”. Guided Access jest funkcją systemowa pozwalającą na skupienie się na jednym zadaniu. W momencie uruchomienia pewne obszary ekranu są blokowane, aby przypadkowe naciśnięcie nie spowodowało zakłócenia głównego zadania. Interesująca obserwacja jest taka, że klawiatury alternatywne nie przestrzegają ograniczeń Guided Access i to bez względu na ustawienia „Pełnego dostępu”. W czasie szybkiego testowania okazało się, że tylko klawiatura systemowa zachowuje się według wytycznych Apple. Implementacja tej funkcji leży po stronie dewelopera co w przypadku klawiatur alternatywnych nie ma miejsca. Może to być ciekawy obszar badań nad skutecznością ograniczeń systemowych w odniesieniu do rozszerzeń aplikacji.