Nie będę wnikał tu w szczegóły, ale krótkie wprowadzenie się przyda. Mamy więc Activity, z których składa się aplikacja (a przynajmniej jej GUI). Aplikacja może składać się z wielu takich elementów, może też korzystać z funkcji zdefiniowanych w innych aplikacjach. Do tego przydaje się Intent. Każda aplikacja w pliku AndroidManifest.xml umieszcza listę swoich Activity (i nie tylko, ja w tym kontekście warto jeszcze wspomnieć o Service). Domyślnie Activity i Service są “lokalne” dla danej aplikacji, ale jeśli zdefiniowany zostanie IntentFilter, to stają się one dostępne dla innych aplikacji w systemie. Jeśli chcemy ograniczyć jakie aplikacje powinny móc korzystać z komponentów naszej aplikacji, musimy ustalić odpowiednie permission.

Do czego służy Service? Ten cytat z dokumentacji jest chyba wystarczającym wyjaśnieniem:

A Service is an application component representing either an application's desire to perform a longer-running operation while not interacting with the user or to supply functionality for other applications to use.

Teraz załóżmy, że nasz użytkownik będąc na jakimś Activity chce wywołać operację, która może zająć wiele czasu i w szczególności może zakończyć się niepowodzeniem. By nie spowodować zamrożenia GUI (albo wkurzającej “kręcioły”), programista może tą funkcję zaimplementować w usłudze i z poziomu Activity wywołać tę usługę poprzez wywołanie funkcji startService. W szczególności może być tak, że wyśle on w tym miejscu Intent o określonej nazwie, a system wywoła usługę, która ma zarejestrowany odpowiedni IntentFilter. I teraz ważna sprawa Intent może być wysłany “rozgłoszeniowo”.

W jaki sposób rezultat pracy usługi może być zwrócony do Activity? Na przykład wysyłając broadcast, który w pewnych przypadkach może trafić do wszystkich aplikacji na urządzeniu, które zarejestrowały odpowiednie filtry (patrz BroadcastReceiver: Security).

Widzicie już potencjalny problem? Zresztą ta kwestia jest dość dokładnie pokazana w dokumentacji Androida, ale na wszelki wypadek:

• zewnętrzna aplikacja może wywołać usługę w “naszej” aplikacji,
• zewnętrzna aplikacja może otrzymywać komunikaty z rezultatem wywołania usługi,

Oczywiście może , ale wcale nie musi , muszą ku temu zaistnieć sprzyjające okoliczności (błędy).

Do czego to może prowadzić? Wyobraźmy sobie aplikację, niech będzie to aplikacja bankowości internetowej, która skonstruowana jest w następujący sposób:

• W Activity nie ma żadnego kodu do komunikacji z serwerem,
• Komunikacja z serwerem jest realizowana w Service,
• Po logowaniu tworzony jest obiekt odpowiadający za komunikację poszczególnych Service z serwerem,
• Activity wywołuje Service wysyłając odpowiedni Intent,
• Service zwraca rezultat wywołania wysyłając odpowiedni Intent (broadcast),

Do czasu, gdy Intenty wymienione między Activity i Service są lokalne (patrz np. LocalBroadcastManager) a usługi nie są eksportowane (patrz: android:exported), problemu w zasadzie nie ma. Co jednak, jeśli zaistnieją “sprzyjające okoliczności”?

Potencjalny scenariusz ataku jest prosty. Zewnętrzna aplikacja może:

• zarejestrować BroadcastReceiver dla interesujących ją Intent,
• wołać pewne funkcje API poprzez wywoływanie Service z odpowiednim Intent,

Skutkiem takiej podatności będzie co najmniej wyciek danych. Piszę co najmniej, bo teoretycznie mogę wyobrazić sobie sytuację, w której korzystając z socjotechniki wroga aplikacja skłoni użytkownika do podania kodu autoryzującego transakcję.

Cała ta sytuacja kojarzy mi się z następującym (hipotetycznym?) przykładem. W pokoju pracuje dwie osoby, “wywołują” wzajemnie swoje “usługi” rozmawiając ze sobą, a rozmawiają na tematy “wrażliwe” i mają możliwość wywołania “wrażliwych” operacji (np. “odblokuj mi konto X i ustaw hasło na Y”). I tak żyją sobie spokojnie przez długi czas, aż pewnego dnia w pokoju pojawia się trzecia osoba. Sposób pracy dwóch “starych” osób nie ulega zmianie, ale zmieniło się środowisko. Nowa osoba może po pierwsze uzyskać interesującą wiedzę tylko słuchając rozmowy (taki BroadcastReceiver). Może też spróbować “ataku aktywnego”, czyli po prostu spróbować poprosić kogoś o zrobienie czegoś, do czego ten nowy pracownik nie ma uprawnień. Zadziała? Może, ale nie musi. Nie musi, bo my ludzie mamy często domyślnie włączony mechanizm uwierzytelnienia oparty na biometrii – rozpoznajemy osobę po głosie. To dlatego w przypadku przekrętu “na wnuczka” pojawia się chore gardło.

Oryginał tego wpisu dostępny jest pod adresem Ściany mają uszy (i potrafią mówić)

Autor: Paweł Goleń

Pierwszy przykład to ta wypowiedź:

#fail #security rapidshare.com nie szyfruje haseł dostałem maila z moim hasłem. A nie link do zmiany jego ...

Pytanie – czy na podstawie otrzymania zapomnianego hasła można wyciągnąć wniosek, że hasło nie jest szyfrowane? A może jest tak:

Przypominam, że jeśli hasło jest ZASZYFROWANE, to można je ODSZYFROWAĆ i wysłać użytkownikowi. Może więc jednak szyfruje :)

Z dużym prawdopodobieństwem można przypuszczać, że rzeczywiście hasło po stronie serwera jest przechowywane w formie jawnej. Jest to jednak tylko przypuszczenie, przesłanka, którą w tym przypadku dysponujemy nie jest wystarczająca, by stwierdzić, że hasło nie jest szyfrowane. Wystarcza natomiast do tego, by stwierdzić, że hasło nie jest przechowywane w postaci hasha. W mojej ocenie pojęcie szyfrowania oznacza takie przekształcenie wiadomości, które umożliwia jej odzyskanie (odszyfrowanie). Nie jest więc wykluczone, że jakiś serwis przechowuje hasła w formie szyfrowanej, a gdy jakiś użytkownik hasła zapomni, jest ono odszyfrowane i wysyłane mu mailem. Temat przechowywania haseł poruszałem już wielokrotnie, zainteresowanych odsyłam na przykład tu: O przechowywaniu haseł.

Ktoś może uznać, że się czepiam. Pewnie coś w tym jest, ale moim zdaniem precyzja wypowiedzi jest istotna. Szyfrowanie hasła to nie to samo, co przechowywanie hasha hasła. Przechowywanie hasła w formie szyfrowanej jest prawie tak złe, jak przechowywanie go w formie jawnej, ale... Tu niespodzianka – istnieją protokoły uwierzytelniania, które wymagają hasła użytkownika w formie jawnej, jeśli więc są one stosowane, przechowywanie hasła w formie zaszyfrowanej może być uzasadnione. Taka funkcja istnieje nawet w Windows: Store passwords using reversible encryption.

Na zakończenie tego przykładu pytanie – czy fakt otrzymania linku do zmiany hasła pozwala na stwierdzenie, że po stronie serwera hasło nie jest przechowywane w formie jawnej lub szyfrowanej?

Teraz drugi przykład. Natknąłem się na niego, gdy szukałem komentarzy ludzi na temat wygody i bezpieczeństwa haseł maskowanych. Znalazłem między innymi ten wpis: Bezpieczne metody uwierzytelniania użytkowników, a pod nim następujący komentarz:

Krew się we mnie zagotowała jak przeczytałem ten wpis. Czy wie Pan o czym świadczy pytanie o losowe litery z hasła? O tym, że hasło trzymane jest w \*postaci niezaszyfrowanej\* co urąga wszelkim zasadom bezpieczeństwa, szczególnie w banku! (...)

Czy autor tego komentarza ma rację? Chodzi mi tu o cytowaną część komentarza, która dotyczy haseł maskowanych przy uwierzytelnieniu w systemach bankowości internetowej.

Odpowiedź na to pytanie brzmi: to zależy. Nie jest tak, jak sugeruje autor, że użycie hasła maskowanego zawsze oznacza przechowywanie hasła w postaci jawnej (lub zaszyfrowanej). To zależy od konkretnej implementacji. Są takie, które w chwili zmiany hasła generują pewną liczbę masek i wyliczają stosowne hashe. W tym przypadku hasło nie musi i nie jest przechowywane w postaci jawnej. Są również i takie rozwiązania, w których hasło w takiej postaci najprawdopodobniej jest przechowywane. Świadczą o tym przekształcenia wykonywane po stronie klienta (w przeglądarce) po wpisaniu hasła. Takim sygnałem może być przekształcenie typu:

sha1(token, pwd)

gdzie token jest losowy i unikalny dla każdej próby uwierzytelnienia, natomiast pwd to fragment hasła wpisany przez użytkownika. Ale jeśli przekształcenie przyjmuje formę:

sha1(token, sha1(pwd))

nie ma już konieczności przechowywania w bazie hasła w formie jawnej. Tu pozwolę sobie przypomnieć o jednym z udostępnionych przeze mnie wyzwań, w którym przekształcenia wykonywane na wpisanym przez użytkownika haśle przed wysłaniem go do serwera są dość istotne.

Dlaczego podaję te przykłady? Wyciąganie na podstawie istniejących przesłanek błędnych lub nieuprawnionych wniosków, może być szkodliwe. Jeśli dochodzimy do etapu wnioskowania, warto zastanowić się, które z naszych wniosków mają twarde dowody, a które opierają się w znacznej części na naszej intuicji. Być może warto przeprowadzić jakieś dodatkowe testy, które nasz wniosek potwierdzą, lub obalą.

Oryginał tego wpisu dostępny jest pod adresem Wyciąganie błędnych wniosków II

Autor: Paweł Goleń