Najciekawsze podatności znalezione przez nasz zespół w trakcie testowania bezpieczeństwa aplikacji mobilnych – przede wszystkim finansowych (bankowość, płatności).

1. (NIE)BEZPIECZEŃSTWO APLIKACJI
MOBILNYCH
Najciekawsze przypadki
Sławomir Jasek
SecuRing
KrakDroid, 7.12.2013

2. Abstrakt
● Whoami
● Kto i po co zaatakuje naszą aplikację
● Analiza ryzyka – podejście racjonalne
● Najciekawsze podatności w aplikacjach
mobilnych - przykłady
● Najważniejsze zasady bezpieczeństwa

3. # whoami
Konsultant bezpieczeństwa (~ 10 lat), setki projektów, głównie
różnego typu aplikacje
SecuRing (od 2003)
Testowanie i doradztwo dotyczące bezpieczeństwa aplikacji i systemów IT
Jeśli to możliwe w ramach„white-box” (przegląd konfiguracji, kodu,
konsultacje), a także już na etapie definiowania architektury
Wynikiem testu jest dokładny raport opisujący szczegółowo znalezione
podatności (oraz wykonane testy), wraz z rekomendacjami/sposobami
naprawy

4. Kto i po co zaatakuje naszą aplikację?
„grubszy cwaniak”
„script-kiddie”
Krzysztof Jarzyna
ze Szczecina
Ma motywację, zasoby
oraz możliwości
przeprowadzenia ataku
nakierowanego
Dorwał się do narzędzi,
wali na oślep, zwykle nie
bardzo rozumiejąc co się
dzieje.
Coś mu się przypadkiem
udało (lub nie), i afera
gotowa.

5. Analiza ryzyka – podejście racjonalne
Profil ryzyka zależy od aplikacji – jej funkcji
biznesowych, potencjalnych strat, zysków dla intruza.

6. Przykład 1
● Aplikacja mobilna dla kibiców
● M.in. typowanie wyników meczu, wśród prawidłowych
losowanie biletów
● Po wysłaniu typowania w aplikacji znika ta opcja,
można jedynie podglądnąć swój typ
Jak zaatakuje ten proces intruz?

7. Lokalne proxy – pozwala m.in. na edycję oraz
powtarzanie zleceń HTTP

8. Jak to zrobić poprawnie?
● Pamiętaj, że ruch pomiędzy aplikacją a
serwerem może być przechwycony i
zmodyfikowany
● SSL nie chroni przed lokalnym tamperingiem
● Walidacja musi być również po stronie
serwera!
● Nie ufaj mechanizmom bezpieczeństwa po
stronie klienta

9. Ryzyko?

10. Przykład 2
Aplikacja bankowości mobilnej, do uwierzytelnienia i autoryzacji
wymagany jest kod PIN.
Po 3-krotnym wprowadzeniu błędnego PIN-u konto blokuje się na
serwerze.
Pewne funkcje aplikacji (np. historia transakcji) działają również offline.
Aplikacja musi więc przechowywać lokalnie część danych pobranych z
serwera.
Dane te są trzymane w formie zaszyfrowanej, w prywatnym katalogu
dostępnym jedynie dla tej aplikacji. Do odszyfrowania konieczne jest
podanie PIN-u użytkownika.
Nie użyto stałego klucza zaszytego w aplikacji.

11. Spojrzenie intruza
● Aby ukraść pieniądze potrzebuje kod PIN
● Załóżmy, że udało mu się przejąć pełną
kontrolę nad urządzeniem mobilnym (np.
kradzież, malware...)
● Jednak nie może podsłuchać kodu PIN – nie
ma możliwości kontroli nad urządzeniem w
trakcie gdy użytkownik korzysta z bankowości
● Jak może uzyskać PIN?

12. Przykład 2 – proces offline.
Kod PIN jest używany również do odszyfrowania danych trzymanych
lokalnie.
Jest to funkcja, która działa bez połączenia do Internetu, więc kod PIN
nie może być zweryfikowany po stronie serwera.
Nawet jeśli aplikacja się zablokuje po 3 nieudanych próbach, jest to
proces offline. Konto nie zablokuje się na serwerze, a intruz może
odtworzyć stan aplikacji sprzed zablokowania i próbować ponownie.
Czyli - intruz może bez ograniczeń łamać kod PIN offline. Prawidłowy
kod pozna po tym, iż po rozszyfrowaniu uzyska sensowne dane.
Nawet jeśli kod jest złożony (a w praktyce najczęściej to kilka cyfr),
złamanie zajmie mu maksymalnie kilka godzin.

13. Jak to zrobić poprawnie?
● Wszystkie próby użycia hasła (np. w celu
uwierzytelnienia lub autoryzacji) powinny być
weryfikowane na serwerze, nie lokalnie na urządzeniu.
● Poprawne użycie kryptografii – uwaga na błędy
pozwalające na łamanie siłowe offline.
● Najlepiej nie przechowywać żadnych danych wrażliwych
na urządzeniu, nawet w formie zaszyfrowanej
● Uwaga na logi systemowe itp.
Warto poczytać:
http://wampir.mroczna-zaloga.org/archives/1147-jak-zepsuc-uwierzytelnienie-w-aplikacji-mobilnej.html

14. Ryzyko?

15. Przykład 3
Aplikacja mobilna do wyświetlania w czasie
rzeczywistym oraz natychmiastowego zlecania
różnych operacji.
W tym celu opracowano specjalny protokół,
komunikujący się przez SSL z serwerem.

16. Protokół - architektura

17. Protokół - pakiety

18. Protokół

19. Protokół – wywołanie WS

20. Protokół – inne metody WS

21. Metoda RegisterUser
Odpowiedź serwera:
<soapenv:Body>
<registerUserResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<registerUserReturn xsi:type="xsd:string">
&lt;error code=&quot;266&quot; &gt;Incorrect login&lt;/error&gt;
</registerUserReturn>
</registerUserResponse>
</soapenv:Body>

22. RegisterUser – drążymy dalej
Po dodaniu kolejnych brakujących parametrów:
● Incorrect first name
● Group with name null doesn't exist
● Group with name admin doesn't exist
● Group with name Administrator doesn't exist
● A grupa „Root” ?

23. Protokół – Game Over
<soapenv:Body>
<registerUserResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<registerUserReturn xsi:type="xsd:string">
User was registered sucessfully with id=5392745
</registerUserReturn>
</registerUserResponse>
</soapenv:Body>
Tak zarejestrowany użytkownik po zalogowaniu mógł
zarządzać zasobami WSZYSTKICH INNYCH
UŻYTKOWNIKÓW SYSTEMU

24. Walidacja, separacja przywilejów,
wiele poziomów zabezpieczeń...

25. Inicjalizacja mobilnego kanału
bankowości
Bankowość internetowa, logowanie za pomocą hasła,
autoryzacja operacji za pomocą kodów SMS.
Aplikacja bankowości mobilnej, zabezpieczona za
pomocą PIN-u (uwierzytelnienie, autoryzacja
transakcji).
Solidna kryptografia w procesie dodawania nowego
urządzenia do konta, oraz w trakcie korzystania z
bankowości.
Proces przemyślany, aby użytkownik nie zrobił
sobie krzywdy.

26. Inicjalizacja mobilnego kanału -
proces
● Po zalogowaniu w serwisie www, użytkownik wybiera opcję dodania
nowego urządzenia mobilnego. Wprowadza w formularzu nowy kod
PIN. Wyświetla się kod QR („seed” kryptograficzny) do
zeskanowania w urządzeniu.
● Użytkownik skanuje kod QR w telefonie. Podaje na urządzeniu ten
sam kod PIN.
● Aplikacja mobilna przesyła do serwera zaszyfrowany PIN-em „seed”
● Serwer porównuje, czy dane się zgadzają
● W aplikacji www należy następnie potwierdzić dodanie nowego
urządzenia, klikając przycisk „Akceptuj”.

27. Jak patrzy na to intruz?
● Wyobraźmy sobie, że intruz przejął kontrolę nad
komputerem użytkownika (np. malware)
● Poznał login i hasło do bankowości internetowej. Nie
może jednak ukraść pieniędzy, ponieważ nie ma
dostępu do kodów sms
● Ale – przecież autoryzacja transakcji możliwa jest
również za pomocą aplikacji mobilnej
● Jak przejąć aplikację mobilną?

28. Inicjalizacja mobilnego kanału - problem
Brak autoryzacji procesu dodawania nowego
urządzenia mobilnego!
Malware działający na stacji użytkownika
może dopisać sobie - bez jego wiedzy - nowe
urządzenie mobilne, uzyskując w ten sposób
możliwość autoryzacji transakcji.
ragecomic.fr

29. BankDroid
● Aplikacja służy do informowania online o saldach oraz
zmianach na kontach różnych skandynawskich banków
● Działa w tle, odpytując o status co chwilę
● Łączy się automatycznie z bankami również gdy telefon
jest podłączony do niezaufanych sieci
● 100 000 – 500 000 instalacji
https://play.google.com/store/apps/details?id=com.liato.bankdroid

30. BankDroid – kod źródłowy (GPL)
CELOWO wyłączono weryfikację certyfikatów SSL banków:
public Urllib(boolean acceptInvalidCertificates) {
this(acceptInvalidCertificates, false);
}
public void checkServerTrusted(java.security.cert.X509Certificate[] chain, String authType)
throws java.security.cert.CertificateException {
// TODO Auto-generated method stub
}
https://github.com/liato/android-bankdroid

31. BankDroid – i tak 21 razy ;)
src/com/liato/bankdroid/banking/banks $ grep "Urllib(true)" *
AbsIkanoPartner.java
Bioklubben.java
DanskeBank.java
DinersClub.java
EasyCard.java
Eurocard.java
Everydaycard.java
FirstCard.java
ICA.java
IkanoBank.java
IkanoPartnerBase.java
Jojo.java
OKQ8.java
PayPal.java
Payson.java
PlusGirot.java
SEB.java
SEBKortBase.java
Steam.java
Vasttrafik.java
Volvofinans.java

32. MITM na SSL? Ale kto by to potrafił?!!
To przecież takie trudne!
Czyżby?

33. dSploit – dzieciak sąsiadów już ma
Bardzo prosty interfejs, do obsługi przez laika.
WiFi Scanning & Common Router Key Cracking
Deep Inspection
Vulnerability Search
Multi Protocol Login Cracker
Packet Forging with Wake On Lan Support
HTTPS/SSL Support (SSL Stripping + HTTPS -> Redirection)
MITM Realtime Network Stats
MITM Multi Protocol Password Sniffing
MITM HTTP/HTTPS Session Hijacking
MITM HTTP/HTTPS Hijacked Session File Persistance
MITM HTTP/HTTPS Realtime Manipulation
GPL, do pobrania z http://dsploit.net

34. Przejęcie konta PayPal

35. Mały eksperyment
Kraków, 7.12.2013, ~13.30. MITM – podmiana obrazków (dSploit).

36. MITM na SSL – prawidłowa (?) reakcja

37. Nie wymagaj od użytkowników zbyt wiele!
Test na użytkownikach aplikacji Android – okienko
udające instalację nowego CA w telefonie.
Po zainstalowaniu kontrolowanego przez intruza CA, może on
przeprowadzić atak MITM na dowolne połączenie SSL w sposób
niezauważalny dla ofiary!

38. Mam nowy certyfikat – hurra!
● 73% osób zaakceptowało nowe CA – przez co stali się podatni na atak MITM
- 77% z nich było przekonanych, iż w ten sposób zwiększyli swoje
bezpieczeństwo
- tylko 2% podejrzewało, iż instalacja nowego CA mogła mieć negatywny
wpływ na ich prywatność
źródło: https://www.owasp.org/images/7/77/Hunting_Down_Broken_SSL_in_Android_Apps_-_Sascha_Fahl%2BMarian_Harbach%2BMathew_Smith.pdf
Wnioski
● Nie zadawaj trudnych pytań!
● Rozwiązanie: certificate pinning.
picardfacepalm.com

39. Podejście racjonalne
● Kto i po co chciałby zaatakować
naszą aplikację? Jakich zasobów do
tego potrzebuje?
● Koszt zabezpieczenia nie może być
większy niż wartość chronionych
zasobów
● Negatywny wpływ na używalność czy
dostępność
● Przyzwyczajenia użytkowników
● Uwaga na fałszywe poczucie
bezpieczeństwa i odpowiedzialność
Andrzej Tobis - Kierownica
www.otwartazacheta.pl

40. Mniejsze ryzyko
● Przechowywanie danych wrażliwych w pamięci operacyjnej
urządzenia w trakcie pracy aplikacji.
● Użycie klawiatury systemowej - niektóre implementacje
zostawiały w systemie informacje o wciskanych klawiszach.
● Brak możliwości przeniesienia na kartę SD
● ...
Nawet jeśli ryzyko nie jest wysokie (trudność w wykorzystaniu),
zabezpieczenie może być wdrożone z powodów wizerunkowych.

41. Mniejsze ryzyko
Pomimo istotnych skutków, warunki wykorzystania
podatności są bardzo trudne do spełnienia

42. Pamiętaj!
Myśl o bezpieczeństwie – już na etapie projektowania!
Bezpieczeństwo transmisji.
Lokalnie przechowywane dane.
Środowisko po stronie serwera.
Wiele warstw zabezpieczeń, zasada najmniejszych przywilejów.
Nie wymagaj od użytkownika zbyt wiele.
Andrzej Tobis - Dodawanie
www.otwartazacheta.pl

43. Merry Hacking X-Mas!
www.securing.pl/konkurs/
● I miejsce - Płatny, miesięczny staż w naszej
firmie.
● II miejsce - Bilet wstępu na konferencję
Confidence 2014.
● III miejsce - Książka "The Web Application
Hacker's Handbook".

44. Dziękuję!
slawomir.jasek@securing.pl