W korporacjach pracownicy, by pobrać na swój prywatny telefon pocztę z serwera Exchange, muszą zaakceptować jego politykę. Może mieć to poważne konsekwencje – do nieautoryzowanego skasowania zawartości telefonu włącznie.
Architekci Microsoftu słusznie założyli, że trend Bring Your Own Device będzie miał coraz większe znaczenie dla jego klientów. Wyposażyli zatem serwer Exchange w funkcjonalności umożliwiające kontrolowanie środowiska, w którym część urządzeń stanowi własność użytkowników. Kiedy pracownik chce ściągnąć służbową pocztę na swój prywatny telefon, musi najpierw zaakceptować politykę serwera. Określa ona takie parametry jak długość hasła, poziom jego złożoności, opóźnienie aktywacji blokady ekranu czy też dezaktywację usługi WiFi (która w przypadku niektórych modeli iPadów może być ostatnim poleceniem odebranym przez urządzenie). Najdalej idącą interwencją serwera jest jednak możliwość zdalnego wymazania zawartości telefonu. Co ciekawe, opisane powyżej funkcjonalności działają prawie na każdym smartfonie – czy to Android, iOS czy Blackberry.
Czy można podszyć się pod Exchange’a?
Pewien pentester, Peter Hannay, postanowił sprawdzić, jak wygląda przesyłanie aktualizacji polityki serwera do telefonu i czy da się wysłać polecenie skasowania zawartości telefonu nie posiadając Exchange’a pod ręką. Jego pierwsza, intuicyjna odpowiedź brzmiała „To nie może być wykonalne, na pewno istnieją mechanizmy, które temu zapobiegają. Przynajmniej SSL.” Będąc jednak nie tylko pentesterem, ale także naukowcem, postanowił zbadać sprawę dogłębnie. Zaczął od analizy wymienianych pakietów.
Gdy administrator Exchange’a wyśle polecenie skasowania zawartości telefonu, Exchange zaczyna odmawiać realizacji jakichkolwiek zapytań ActiveSync telefonu, informując, że musi najpierw otrzymać prośbę o nową politykę. Kiedy już otrzyma od telefonu odpowiednie żądanie, wysyła politykę w formacie pliku wbxml (xml zapisany w formie binarnej dla zmniejszenia rozmiaru), zawierającego polecenie skasowania zawartości aparatu.
Aby przeprowadzić testy, Peter postanowił skorzystać z urządzenia WiFi Pineapple, które jest miniaturowym ruterem WiFi z rozbudowanymi możliwościami przeprowadzania ataków typu MiTM (jak na przykład udawanie dowolnej sieci WiFi, poszukiwanej przez telefon). Dodatkowo zainstalował w systemie certyfikat SSL, który nie spełniał żadnego rozsądnego kryterium oprócz tego, że wygasał w przyszłości. Nie pasował adres serwera ani data ważności, a certyfikat był podpisany swoim własnym kluczem. Mogło by się wydawać, że takie połączenie zostanie odrzucone.
Wyniki testów
Peter sprawdził dwa przypadki testowe. W pierwszym serwer Exchange’a 2010, do którego wcześniej były podłączone testowane urządzenia, korzystał z domyślnego certyfikatu podpisanego własnym kluczem, w drugim korzystał z certyfikatu podpisanego przez zaufany urząd certyfikacji.
W pierwszym przypadku telefon działający pod kontrolą systemu Android (zarówno 2.3 jak i 4.0) przyjął polecenie usunięcia danych bez żadnych uwag. iPhone (iOS 5) wyświetlił użytkownikowi komunikat „Nie mogę zweryfikować tożsamości serwera” oraz dał do wyboru trzy opcje: „Kontynuuj”, „Anuluj” i „Wyświetl szczegóły”. Gdy użytkownik wybrał „Kontynuuj”, telefon grzecznie usunął swoją zawartość. Z kolei Windows Phone 7.5 odmówił w ogóle wykonania operacji.
W drugim scenariuszu wykonania polecenia odmówiły zarówno Android jak i Windows Phone, a iPhone powtórzył identyczne pytanie i pozwolił użytkownikowi zatwierdzić wyczyszczenie urządzenia. Jak więc widać, najlepiej w tej sytuacji zachował się Windows Phone, nie pozwalając atakującemu na nawet najmniejszą szansę skasowania zawartości telefonu.
Co jeszcze da się zrobić?
Jakie jeszcze możliwości oferuje protokół ActiveSync? Standardową funkcjonalnością jest dwukierunkowa synchronizacja poczty. Można zatem tak skonfigurować skrypt udający serwer Exchange’a, by wymusił na urządzeniu przesłanie całości skrzynki pocztowej (ze szkicami niewysłanych wiadomości włącznie). Dodatkowo protokół przewiduje wysłanie nowej konfiguracji serwera poczty wychodzącej – więc zamiast usuwać zawartość urządzenia, można ustawić swój własny serwer jako domyślny dla całej poczty wysyłanej z urządzenia i zachować możliwość zapoznawania się z korespondencją danej osoby nawet, gdy opuści ona kontrolowaną przez nas strefę zasięgu WiFi.
Jak bronić się przed tym atakiem?
Należy pamiętać, że opisywany powyżej atak nie jest błędem usługi, a jedynie marną implementacją protokołu. Jedyne, co możemy zrobić, to zapewnić, by serwer Exchange’a w naszej firmie korzystał z prawidłowego certyfikatu, podpisanego przez zaufany urząd certyfikacji. a użytkownicy iPhone’ów byli świadomi zagrożeń, jakie na nich czyhają, jeśli wybiorą opcję „kontynuuj”.
Osobom zainteresowanym szczegółami polecamy prezentację Petera z konferencji Defcon, gdzie omawia swoje badania i demonstruje na żywo przykłady usuwania danych z telefonów.
Komentarze
Jest błąd „Echxange”. Niemniej jednak, artykuł zacny.
Dzięki, poprawione (i ze 4 inne przy okazji…)