Urządzenia przenośne w tym w szczególności telefony komórkowe coraz częściej zastępują komputer w roli klienta aplikacji. Jednym z nowych trendów jest przenoszenie różnego rodzaju aplikacji internetowych (np. bankowości internetowej) na platformy mobilne. W swojej prezentacji chciałbym omówić problemy dotyczące bezpieczeństwa informacji jakie należy rozpatrzyć wdrażając usługi mobilne. Dla skoncentrowania uwagi analiza problemu będzie dotyczyć bankowości mobilnej dostępnej za pośrednictwem telefonu komórkowego. - Czym pod względem bezpieczeństwa różni się terminal przenośny (np. telefon komórkowy) od komputera? - Rodzaje aplikacji mobilnych – przeglądarka vs „gruby klient”. - Jak obecnie jest implementowana bankowość mobilna? - Wykorzystanie telefonów komórkowych do autoryzacji transakcji w bankowości internetowej (kody jednorazowe, tokeny challenge-response). - Ograniczenia środowiska mobilnego – wpływ na bezpieczeństwo. - Typowe podatności dla aplikacji internetowych – czy są one aktualne dla aplikacji mobilnych? Przegląd według listy OWASP Top 10. - Ryzyka, które zyskują na znaczeniu (np. zgubienie, kradzież, obserwacja, podsłuch)

1. Bezpieczeństwo aplikacji mobilnych
Wojciech Dworakowski

2. Bankowość mobilna
2

3. Agenda
Wykorzystanie aplikacji mobilnych w bankowości
Ograniczenia środowiska mobilnego – wpływ na
bezpieczeństwo
Podatności aplikacji mobilnych
 Typowe podatności aplikacji webowych (przegląd wg
OWASP Top10)
 Podatności specyficzne dla aplikacji mobilnych
Podsumowanie
3

4. Bankowość mobilna
SMS / text
 Powiadomienia
 Autoryzacja transakcji
 Tekstowe serwisy transakcyjne
 MMI / USSD
Przeglądarka
 Dostęp do serwisów banku (w tym
transakcyjnych)
– mobilnych (dostosowanych do
małego ekranu)
– tradycyjnych
Grafika: pocztowy.pl, aliorbank.pl 4

5. Bankowość mobilna
Aplikacje
 Autoryzacja transakcji (kody
jednorazowe, challenge –
response)
 Serwisy transakcyjne
Inne
 Technologie zbliżeniowe
(Near Field Communication)
 Lokalizacja
 ….?
Grafika: raiffeisen.pl, blog.bzwbk.pl 5

6. Ograniczenia platformy
laptop telefon
Ekran duży mały
Klawiatura wygodna niewygodna
Multitasking jest (widoczny) jest (niewidoczny)
Kradzież / zgubienie rzadkie częstsze
Blokowanie częste (w firmach) rzadkie (nawet w
urządzenia firmach)
Świadomość mała mniejsza
użytkowników
Grafika: bankofamerica.com 6

7. ZAGROŻENIA I PODATNOŚCI
APLIKACJI MOBILNYCH
Grafika: technabob.com
7

8. Czy podatności typowe dla aplikacji webowych
mogą dotyczyć aplikacji mobilnych?
Webowe Mobilne Mobilne
OWASP Top 10 (przeglądarka) („aplikacja”)
A1 – Injection TAK TAK
A2 – Corss Site Scripting (XSS) TAK (raczej) NIE
A3 – Broken Authentication and Session TAK (!) TAK
Management
A4 – Insecure Direct Object References TAK TAK
A5 – Cross Site Request Forgery TAK (raczej) NIE
A6 – Security Misconfiguration TAK TAK
A7 – Insecure Cryptographic Storage TAK TAK
A8 – Failure to Restrict URL Access TAK zależy
A9 – Insufficient Transport Layer TAK TAK
Protection
A10 – Unvaidated Redirects and TAK zależy
Forwards 8

9. Najgroźniejsza „podatność”
9

10. Man in the Mobile
Grafika: ingbank.pl, cert.pl 10

11. Man in the Mobile
Uwaga: Każda bankowość internetowa jest podatna na tego
typu atak
 (wykorzystująca telefon do autoryzacji operacji)
To nie zależy od banku i rodzaju bankowości internetowej !
Istotą ataku jest nieświadomy użytkownik i jego „zarażony”
komputer
 Wrogi kod na komputerze skłania użytkownika do podania nr
tel.
 Instalacja wrogiego kodu na telefonie (za zgodą użytkownika)
11

12. NIEKTÓRE RYZYKA
CHARAKTERYSTYCZNE DLA
TECHNOLOGII MOBILNYCH
12

13. Kradzież / zgubienie
laptop telefon
Prawdopodobieństwo wystąpienia
Ilość (w Polsce) kilka mln 47,15 mln 1
smartfony 11,5% 2
Kradzież / zgubienie średnio bardzo często
Zabezpieczenia
Hasło (przy starcie) średnio PIN do SIM-karty
Dane aplikacji mogą być
dostępne bez PIN-u
Hasło (po rzadko Rzadziej
nieaktywności)
Szyfrowanie dysku rzadko Na razie niszowe
- BlackBerry: w systemie
- Nokia, Android: dodatek
1 Telepolis IV kwartał 2010
2 Gfk Polonia, styczeń 2011
13

14. Sposób dystrybucji aplikacji
Grafika: blogs.strategyanalytics.com
Zwolnienie użytkownika z odpowiedzialności
 Aplikacje są rozpowszechniane za
pośrednictwem „zaufanego” źródła
iTunes App Store, Android Market, MS Marketplace, BlackBerry
App World, Nokia OVI Store, …
Można zezwolić na instalacje z
„niezaufanych” źródeł
 m-banking: Dystrybucja za pomocą „sklepu”
albo poinstruowanie użytkowników, że mają
zezwolić na instalacje „niezaufanej” aplikacji
Czy faktycznie można mieć zaufanie do
aplikacji nawet ze „sprawdzonych” źródeł?
14

15. Sposób dystrybucji aplikacji
Malware DroidDream (Android Market – 1 marca 2011)
 Sklonowane ponad 50 popularnych aplikacji
 Opublikowano je ponownie z dodanym malware
„DroidDream”
 Te same lub podobne nazwy aplikacji
(developer: “Kingmall2010″, “we20090202″, “Myournet”)
 Ponad 200 tys. ściągniętych kopii w ciągu pierwszego dnia
 Malware zawiera dwa exploity umożliwiające uruchomienie
wrogiego kodu z przywilejami „administratora”
 Wykrada dane użytkownika. Umożliwia instalacje innych
programów.
Grafika: ubergizmo.com 15

16. Uwierzytelnienie
Uwierzytelnienie hasłem
 Niewygodna klawiatura
 Czy użytkownik ustawi „silne” hasło? Czy będzie chciał wpisywać
hasło za każdym razem?
Zapamiętanie użytkownika
 Zwiększona podatność na kradzież / zgubienie
PIN do aplikacji
 Co jest faktycznymi danymi uwierzytelniającymi do serwera?
 Bardzo często – błędy implementacji
– Np. przechowywanie danych uwierzytelniających otwartym tekstem
 Na ekranie dotykowym zostają ślady
Grafika: engadget.com
16

17. Uwierzytelnienie
Uwierzytelnienie hasłem
 Niewygodna klawiatura
 Czy użytkownik ustawi „silne” hasło? Czy będzie chciał wpisywać
hasło za każdym razem?
Zapamiętanie użytkownika
 Zwiększona podatność na kradzież / zgubienie
PIN do aplikacji
 Co jest faktycznymi danymi uwierzytelniającymi do serwera?
 Bardzo często – błędy implementacji
– Np. przechowywanie danych uwierzytelniających otwartym tekstem
 Na ekranie dotykowym zostają ślady
Grafika: engadget.com
17

18. Zakończenie sesji
Jak użytkownik zwykle kończy działanie?
Na niektórych platformach mobilnych nie ma pojęcia
„wyjścia” z aplikacji
 Aplikacja pozostaje w pamięci ale nie dostaje czasu
procesora
 Jeśli użytkownik ponownie uruchomi aplikację, to system
wróci do „zamrożonej” aplikacji (łącznie z jej stanem)
18

19. Zakończenie sesji
Scenariusz
 Użytkownik loguje się do aplikacji bankowości mobilnej
 Nie wylogowuje się ale kończy korzystanie (exit, przycisk
„home”, odebranie połączenia telefonicznego, etc.)
 Intruz przejmuje telefon
 Aplikacja bankowości nadal jest aktywna – z sesją
użytkownika
Kluczowym zabezpieczeniem staje się niszczenie sesji
(na serwerze!) po dłuższej nieaktywności użytkownika
19

20. Rozwój platform mobilnych
Żadne oprogramowanie nie jest pozbawione błędów
Uaktualnienia
 Znacznie rzadsze niż w przypadku systemów
operacyjnych na komputerach
 Skomplikowany proces przygotowania nowej wersji
systemu
– Platforma  Producent telefonu  Operator
– Kilka miesięcy
20

21. Rozwój platform mobilnych
Wiele platform
 iOS, Android, Symbian, Windows Phone,
BlackBerry, Bada, …
 Aplikacja musi być przygotowana na każdą
wspieraną platformę
 Komplikacja procesu  Zwiększone ryzyko
wprowadzenia podatności
Dynamiczny rozwój technologii
 Zawsze w historii powodowało to problemy ;)
 Nowe technologie = nowe techniki ataku
– Np. Near Filed Communication
21

22. Błędy implementacji - przykład
Listopad 2010
 Firma viaForensics ujawnieniła podatności w bankowości
mobilnej dużych amerykańskich banków
 Sprawdzali tylko czy aplikacje przechowują w telefonie dane
wrażliwe bez szyfrowania
 Artykuł w Wall Street Journal
Przykłady:
 Wells Fargo (Android) – nazwa użytkownika + hasło, salda rachunków
 USAA (Android) – kopie „odwiedzanych stron”
 Bank of America (Android) – odpowiedź na pytanie do odzyskiwania hasła
 JP Morgan Chase (iPhone) – nazwa użytkownika i hasło (opcjonalnie)
 TD Ameritrade (iPhone i Android) – nazwa użytkownika
Źródło: http://online.wsj.com/article/SB10001424052748703805704575594581203248658.html
22
http://viaforensics.com/appwatchdog/

23. Podsumowanie
m-Banking ≠ e-Banking
 Jak każda nowa technologia również technologie mobilne
niosą ze sobą nowe zagrożenia
 Środowiska mobilne nie dostarczają mechanizmów
bezpieczeństwa zbliżonych do współczesnych
komputerów
23

24. Podsumowanie
m-Banking ≠ e-Banking
Trzeba uaktualnić model zagrożeń
 Czy potwierdzenie tożsamości na podstawie faktu
posiadania komórki (numeru telefonicznego) jest
wystarczające?
 Czy telefon to urządzenie zaufane?
 Czy telefon jest bezpieczniejszy od komputera?
 Jaki jest wpływ zagrożeń typowych dla urządzeń
przenośnych na naszą aplikację? Np. strata urządzenia
24

25. Bezpieczniejsza bankowość mobilna?
Planowanie i projektowanie
 Szczegółowa analiza wpływu na bezpieczeństwo
– Identyfikacja zagrożeń, analiza ryzyka
– Modelowanie zagrożeń
– Niestandardowe zachowania użytkownika
 Dodatkowe zabezpieczenia (np. limity, powiadomienia,
fraud detection)
 Zabezpieczenia na przyszłość – nie tylko na dzisiaj !
25

26. Bezpieczniejsza bankowość mobilna?
Implementacja
 Szczegółowe testy bezpieczeństwa
– Przy uwzględnieniu zagrożeń
– ..i technik charakterystycznych dla technologii
mobilinych
– Scenariusze ataku łączące mobilny i webowy dostęp do
usług
– Większość istotnych podatności istnieje po stronie
serwera
– Ale trzeba uwzględnić zagrożenia wynikające
z „mobilności”
26

27. Bezpieczniejsza bankowość mobilna?
Wdrażanie i utrzymanie
 Edukowanie użytkowników
 … i kadry technicznej
 Monitorowanie i reagowanie na nowe zagrożenia i metody
ataków
27

28. Pytania?
info@securing.pl
Tel.: 12 425 25 75
Wojciech Dworakowski
wojciech.dworakowski@securing.pl
Tel.: 506 184 550
28