(nie)bezpieczenstwo aplikacji mobilnych
Post on 17-Jan-2017
100 Views
Preview:
TRANSCRIPT
(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?
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
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
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.
Metoda RegisterUser
Odpowiedź serwera:
<soapenv:Body>
<registerUserResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<registerUserReturn xsi:type="xsd:string">
<error code="266" >Incorrect login</error>
</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
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
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
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".
top related