(Nie)bezpieczenstwo aplikacji mobilnych

(NIE)BEZPIECZEŃSTWO APLIKACJI MOBILNYCH

Najciekawsze przypadki

Sławomir JasekSecuRing

KrakDroid, 7.12.2013

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

# 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

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.

Analiza ryzyka – podejście racjonalne

Profil ryzyka zależy od aplikacji – jej funkcji biznesowych, potencjalnych strat, zysków dla intruza.

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?

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

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

Ryzyko?

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.

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?

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.

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

Ryzyko?

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.

Protokół - architektura

Protokół - pakiety

Protokół

Protokół – wywołanie WS

Protokół – inne metody WS

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>

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” ?

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

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

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.

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”.

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ą?

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

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

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

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

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

Czyżby?

dSploit – dzieciak sąsiadów już maBardzo prosty interfejs, do obsługi przez laika.

WiFi Scanning & Common Router Key CrackingDeep InspectionVulnerability SearchMulti Protocol Login CrackerPacket Forging with Wake On Lan Support HTTPS/SSL Support (SSL Stripping + HTTPS -> Redirection)MITM Realtime Network StatsMITM Multi Protocol Password SniffingMITM HTTP/HTTPS Session HijackingMITM HTTP/HTTPS Hijacked Session File PersistanceMITM HTTP/HTTPS Realtime Manipulation

GPL, do pobrania z http://dsploit.net

Przejęcie konta PayPal

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

MITM na SSL – prawidłowa (?) reakcja

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!

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

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 - Kierownicawww.otwartazacheta.pl

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.

Mniejsze ryzyko

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

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 - Dodawaniewww.otwartazacheta.pl

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".

Dziękuję!

[email protected]