12:51
13/1/2014

Ariel Sanchez z IO Active Labs, postanowił opublikować wyniki swoich badań dotyczących mobilnych aplikacji stworzonych przez światowe banki. A nie są one optymistyczne…

Badanie applikacji do bankowości mobilnej

Główne założenie badań prowadzonych przez Sancheza, polegało na przeprowadzeniu testów “Black Box” łącznej liczby 40 aplikacji należących do 60 najbardziej wpływowych (w konteście popularności/zasięgu) banków na świecie. Nie wiemy, czy wśród aplikacji znalazła się aplikacja któregoś z polskich banków — Sanchez nie ujawnia nazw, opublikował na swoim blogu jedynie pobieżną mapę lokalizacji niektórych banków.

Wszystkie testy przeprowadzono na aplikacji klienckiej, wykluczając jakiekolwiek operacje związane z serwerami zewnętrznymi. Ponadto badano tylko aplikacje w wersji na iOS. Narzędzia z jakich skorzystano to otool, Burp Proxy oraz IDA PRO, Clutch, objc-helper-plugin-ida, ssh, gdb i IPCU.

Testy, zakładały takie aspekty bezpieczeństwa jak:

  • 1. Bezpieczeństwo transmisji danych
  • 2. Ochrona przed dekompilacją
  • 3. Walidacja wprowadzanych i wyświetlanych danych
  • 4. Bezpieczeństwo przechowywanych przez aplikację danych
  • 5. Formę zapisu i przechowywania logów aplikacji
  • 6. Statyczna analiza aplikacji

Przejdźmy do statystyk..

…a nie są one optymistyczne.

Zestawienie wyników

Zestawienie wyników

Otóż, 40% aplikacji niestety nie sprawdza autentyczności używanych certyfikatów SSL, co zdecydowanie pozwala na stworzenie fałszywego certyfikatu przez atakującego w celu wykonania ataku Man in The Middle. Ponad 20% aplikacji w ogóle komunikowało się bez szyfrowania.

Spora ilość aplikacji (90%) zawierała odnośniki, które były nieszyfrowane (bez SSL) – a to pozwalało atakującemu, który przechwyci ruch z aplikacji, na wstrzyknięcie kodu JavaScript/HTML w celu stworzenia np. fałszywego ekranu logowania, by zmylić użytkownika i w ten sposób wyciągnąć jego dane dostępowe do konta bankowego — oto przykład:

Wstrzyknięty w aplikację kod JavaScript

Bład w UIWebView. Wstrzyknięty w aplikację kod JavaScript – wymaga przeprowadzenia ataku MITM

Wartym uwagi faktem jest to, że ponad 50% aplikacji zawiera podatności na wstrzyknięcie kodu JavaScript poprzez źle zabezpieczone implementacje interfejsu użytkownika (UIWebView), gdzie wprowadzane i wyświetlane informacje pozwalają np. na atak XSS. Pozwalało to atakującemu na wykonanie podstawowych czynności jak wysłanie wiadomości e-mail/SMS z urządzenia ofiary.

Kolejny przykład wstrzykniętego kodu - tym razem XSS

Kolejny przykład wstrzykniętego kodu – tym razem XSS

Dodatkowo, tylko 20% uruchomiło opcje PIE (Position Independent Executable) oraz Stack Smashing Protection, które zmniejszają ryzyko ewentualnych manipulacji związanych z możliwymi błędami pamięci.

Kolejną rzeczą (w przypadku 70% aplikacji) jest brak jakichkolwiek alternatywnych rozwiązań potwierdzających uwierzytelnienie użytkownika jako klienta banku… takim rozwiązaniem jest np. dwuskładnikowe uwierzytelnianie, które oprócz podania hasła dostępowego do konta, wymaga jeszcze podania specjalnie wysłanego kodu SMSem przez bank.

Sanchez w swoich badaniach, zwrócił także uwagę na generowanie i przechowywanie logów aplikacji, które zawierają m.in. raporty w przypadku ‘crashu’ aplikacji, a częstokroć są to wrażliwe informacje pod kątem bezpieczeństwa. Przede wszystkim, jak słusznie zauważył, takie logi raportowe są przydatnym źródłem informacji przy tworzeniu exploita, który bez problemu wykorzysta słabości aplikacji i pozwoli atakującemu na dostęp do konta bankowego.

Analiza statyczna…

…wykazała niestety kolejne “ciekawostki”. Autor, używając oprogramowania Clutch wyciągnął z kodu źródłowego takie rzeczy jak dane dot. uwierzytelniania:

__text:00056350 ADD R0, PC ; selRef_sMobileBankingURLDBTestEnv__
__text:00056352 MOVT.W R2, #0x46
__text:00056356 ADD R2, PC ; "https://mob_user:T3stepwd@db.internal/internal/db/start.do?login=mobileEvn"
__text:00056358 LDR R1, [R0] ; "setMobileBankingURLDBTestEnv_iPad_mobil"...
__text:0005635A MOV R0, R4
__text:0005635C BLX _objc_msgSend
__text:00056360 MOV R0, (selRef_setMobileBankingURLDBTestEnvWithValue_iPad_mobileT_ - 0x56370) ; selRef_setMobileBankingURLDBTestEnvWithValue_iPad_mobileT_
__text:00056368 MOVW R2, #0xFA8A
__text:0005636C ADD R0, PC ; selRef_setMobileBankingURLDBTestEnvWithValue_i_mobileT_
__text:0005636E MOVT.W R2, #0x46
__text:00056372 ADD R2, PC ; "https://mob_user:T3stepwd@db.internal/internal/db/start.do?login=mobileEvn&branch=%@&account=%@&subaccount=%@"
__text:00056374 LDR R1, [R0] ; "setMobileBankingURLDBTestEnvWith_i"...
__text:00056376 MOV R0, R4
__text:00056378 BLX _objc_msgSend

Sanchez zaznacza, że łatwość zdobycia takich informacji może otworzyć drogę potencjalnemu atakującemu do uzyskania dostępu do środowiska deweloperskiego danego banku i przeprowadzenia operacji na szerszą skalę – choćby wstrzyknięcia niepostrzeżenie do aplikacji złośliwego kodu, a następnie zarażenia nim wszystkich klientów danego banku, którzy z wykorzystaniem owej aplikacji, logują się na swoje konta bankowe…

Niezaszyfrowana baza Sqlite dostępna dla każdego

Informacje dotyczące szczegółów konta bankowego klienta albo historię jego transakcji można wyciągnąć z tworzonych przez aplikację nieszyfrowanych baz sqlite… Baza jest możliwa do pozyskania przez złodzieja zdalnie (exploitem) lub lokalnie, używając aplikacji, która zrobi jailbreak systemu iOS. Sanchez nawet zrobił zrzut ekranu, jednej z odczytanych baz:

Baza sqlite jednej z aplikacji

Baza sqlite jednej z aplikacji

Wnioski z przeprowadzonych testów

Ariel Sanchez poprzez przeprowadzenie powyższych testów oraz podzielenie się wynikami chciał zwrócić uwagę na fakt słabego poziomu bezpieczeństwa aplikacji bankowych, zwłaszcza patrząc przez pryzmat szczególnie wrażliwych danych przez nie przetwarzanych. Z punktu widzenia bezpieczeństwa, są to jedne z najczęściej atakowanych usług. Autor, zarekomendował więc poprawne nawyki/czynności, których praktykowanie przez programistów, znacznie zwiększy poziom bezpieczeństwa tworzonych aplikacji.

  • Upewnij się, że wszystkie połączenia korzystają z bezpiecznych protokołów transmisji danych (HTTPS)
  • Wymuś weryfikację certyfikatów SSL przez aplikację
  • Chroń wrażliwe dane przechowywane na urządzeniu klienckim, szyfrując je z użyciem API dla iOS.
  • Wymuś dodatkowe formy sprawdzenia urządzenia pod kątem ewentualnego jailbreak’a
  • Używaj sprawdzonych sposobów na uniemożliwienie zdebugowania aplikacji aby spowolnić ewentualny reverse engineering plików binarnych
  • Usuń wszystkie informacje, które mogą zostać wykorzystane przez atakujacego np. dotyczące infrastruktury developerskiej, albo komunikacji aplikacji z serwerami

Autor wynikami swoich badań podzielił się z bankami, których aplikacje testował. Można więc liczyć na to, że zespoły programistów niebawem usuną wszystkie zgłoszone przez Sancheza usterki.

PS. Jeśli interesuje was bezpieczeństwo aplikacji mobilnych, zapraszamy na nasze szkolenie z tej tematyki — odbędzie się ono już 6-7 lutego w Krakowie. Jeszcze przez tydzień można zapisać się na nie po niższej cenie.


Przeczytaj także:

31 komentarzy

Dodaj komentarz
  1. ciekawe jak się mają aplikacje naszych banków na Androida czy Windows Phone :)

  2. ciekawe ile osób próbowało zalogować się z pomocą niezamazanych danych z obrazka …

  3. Dobrze że Niebezpiecznik jest to przynajmniej człek się zastanowi dwa razy zanim coś głupiego zrobi. Dzięki.

  4. Tak jak kazde ktore widzielismy do tej pory? :-)

  5. Ostatni raz zalogowałem się na bank z aplikacji ING
    Mam prośbę wstawcie artykuł o bankowych aplikacjach na Androida.

    • Dlaczego ostatni raz? Znasz jakieś błędy, które w niej występują? Sanchez niestety nie zdradza, jakie konkretnie aplikacje testował, ale na pewno nie weryfikował tych na Androida (co nie znaczy, że one nie zawierają błędów takich jak opisane przez niego iOS-owe odpowiedniki).

    • NFC akurat można zaimplementować na stronie – są odpowiednie API, a przeglądarki mobilne mają odpowiednie uprawnienia w systemie.

    • Jeśli chodzi o Polskie banki to ja spotkałem się jeszcze z jednym błędem – minimalizacja aplikacji nie powoduje automatycznego wylogowania

    • A minimalizacja przegladarki powoduje? Gdyby tak bylo, przeklejanie rachunku przy przelewie byloby niemozliwe :)

  6. Nie rozumiem dlaczego nie robią testów penetracyjnych na tego typu aplikacjach?
    Przecież to powinno być standardem i takie testy powinny robić minimum dwie niezależne firmy, żeby zredukować ryzyko błędu.

    • Bo to nie są tanie rzeczy :)

    • Myślę że dział marketingu chciał, jak najszybciej wypuścić aplikację mobilną. Bo inni też mają.

      Ogólnie nie rozumiem idei bankowości mobilnej.

    • To jest coś co fajnie wygląda na papierze, i brzmi dobrze na spotkaniach w korpo – a jaka jest tego użyteczność to już nikogo nie obchodzi…

    • Złota zasada marketingu –
      1) bezpieczeństwa nie można zważyć
      2) a jak ktoś się włamie, to oskarży się dział IT

  7. Piotrze pierwszy raz jak logowałem się na bank przez aplikację ING to zszokowała mnie jedna rzecz po wprowadzeniu loginu i hasła musiałem nadać kod PIN ale uwaga ! co jest najlepsze następne logowanie wymagało samego kodu PIN!! jak dla mnie to jest dość niebezpieczne, bo przy takich aplikacjach powinno być logowanie dwuskładnikowe,swoje hasło do konta+kod PIN który nadajesz osobiście bez ograniczeń. Dobrze że po zalogowaniu od razu zresetowałem PIN do aplikacji przez internet.

    • Hasło + PIN to nie jest uwierzytelnienie dwuskładnikowe.

  8. Nie rozumiem jednej rzeczy: po co w ogóle są tworzone te aplikacje mobilne banków? Nie przypominam sobie, abym kiedykolwiek korzystał z aplikacji banku na PC. Skoro na komputerze możliwe jest zarządzanie kontem z poziomu przeglądarki, do dlaczego inaczej miałoby być z telefonami? Chyba, że czegoś nie rozumiem, w takim razie proszę kogoś o wytłumaczenie mi tego fenomenu.

    • Wygoda (powiadmienia) i szybkość (natywna aplikacja vs web). Plus możliwość korzystania np. z interfejsu NFC telefonu.

    • NFC akurat można zaimplementować na stronie internetowej – są odpowiednie API, a przeglądarki mobilne mają odpowiednie uprawnienia w systemie.

  9. @tkk, to ma za zadanie uwygodnić CI korzystanie z [s]apli[/s] TFU, programu :). Logując się raz za pomocą loginu+ hasła nadajesz pin, później już tylko pin. I nie bawisz się w ‘wpisz pięc znaków’, tylko z marszu pin, i ‘bankujesz mobilnie’ kłamiąc żonie w żywe oczy ze zapłaciłeś za prąd na czas :P. Ma być wygodnie, Ty masz z tego korzystać i zadawać sobie pytanie ‘jak ja do tej pory żyłem bez TFUfona’.
    [quote=ing]Czy jeśli wpiszę błędny PIN do aplikacji, to dostęp do ING BankOnLine zostanie zablokowany?

    Trzykrotne wpisanie błędnego PINu spowoduje jego zablokowanie, natomiast nie zablokuje dostępu do ING BankOnLine. W takiej sytuacji PIN można zdefiniować przy użyciu hasła maskowanego. Uwaga: 5-krotne błędne wpisanie hasła maskowanego spowoduje zablokowanie dostępu do ING BankOnLine.[/quote]
    Mnie najbardziej bolała w tym pinie jego czterocyfrowość, hasło do banku mam ponaddwudziestoznakowe, nawet pin do simkarty w [u]tele[/u]fonie ma osiem znaków.
    Także śpij spokojnie, nikt nie zawinie Twoich dutków tak szybko.
    W sumie to dzięki Tobie przypomniałem sobie, że miałem zapytać w banku czy mogą mi wydłużyć maksymalną długość pinu do karty :P

  10. Nigdy nie mogłem zrozumieć, dlaczego na telefonach i inych urządzeniach mobilnych nie można zwyczajnie użyć przeglądarki do wyświetlenia i obsłużenia strony banku czy facebooka, tylko “potrzeba” do tego “specjalnych” (jak widać nafaszerowanych syfem) programików defacto robiących praktycznie to samo, co przeglądarka (tylko gorzej).

    • Też nie wiem. Ja zawsze używałem przeglądarki do korzystania z konta, niezależnie czy na PC czy na dotykowcu.

  11. Wysyłanie kodu SMSem potrzebnego do zalogowania się do aplikacji mobilnej – najprawdopodobniej zainstalowanej na tym samym telefonie. Mam dziwne wrażenie, że w tym przypadku jest to mało dwuskładnikowe uwierzytelnianie.

    Jeżeli chcemy się zabezpieczyć przed atakującym, który zna login i hasło i zainstaluje sobie aplikację na swoim telefonie – wystarczy, że każdy telefon (instalacja aplikacji) musi być zaakceptowany w przeglądarce przy użyciu kodu SMS. Coś podobnego robi Steam, ilekroć logujesz się z “nowego” komputera, wysyłają kod emailem, który trzeba przepisać na nowym komputerze.

  12. Akurat uniemożliwienie analizy aplikacji zmniejsza jej bezpieczeństwo, bo utrudnia pracę White Hatom takim jak Ariel Sanchez. Za to prawdziwi przestępcy mają dość kasy żeby wykonać analizę programu nawet po zaciemnieniu.
    To samo dotyczy komunikacji z serwerami.

    Sprawdzanie jailbreaka (czy roota) jest mało efektywne i tylko denerwuje zaawansowanych użytkowników (jak było z jedną aplikacją, która nie działała na zrootowanych telefonach z Androidem, miała przez to b. niską ocenę).

    • Z drugiej strony, jeżeli skutecznie zabezpieczysz aplikację przed reverse engineeringiem, a stosowane rozwiązania będą kryptograficznie bezpieczne, może się okazać, że nawet “prawdziwi przestępcy”(Cokolwiek to miało oznaczać) nie podołają. Oczywiście wiem, że to nie jest proste – ale to jest po prostu wyścig zbrojeń.

    • jest jeszcze grupa “nieprawdziwych” przestępców, którzy przez to “zaciemnienie” zostaną powstrzymani; chyba jednak warto

  13. UIWebView – ciekawa definicja kontrolki (implementacje interfejsu użytkownika)

  14. @Sky – nie wyobrażam sobie, żeby ktoś udostępnił tego typu serwis bez testów penetracyjnych. Nie wszystko da się wykryć, niektórzy mogli wziąć starych sprawdzonych pentesterów, co to jednak specyfiki mobilnego syfu tak dobrze nie znają, itd. Takie życie :)

  15. Przecież to piszą jakieś pociotki na zlecenie, po
    znajomości. Czemu się wiec dziwić, skoro na kursie programistycznym
    tego nie uczą

  16. Problemem wydaje się być głównie wynagrodzenie z tytułu wytworzenia aplikacji. Zresztą jak w większości przypadków chodzi tylko i wyłącznie o jedno – pieniądze. Jestem programistą PHP i wiem z doświadczenia że najtrudniejszym tematem nie jest rozwiązanie problemu programistycznego, a jedynie fakt iż zleceniodawca chce mieć produkt szybko, tanio a co najważniejsze nie chce słyszeć o dodatkowych kosztach czy problemach. “… to ma działać…” mówi do mnie zleceniodawca i ucina dalsze dywagacje nad problemem bezpieczeństwa. Obliczam ile roboczogodzin potrzeba do wytworzenia wersji beta, ile potrzeba czasu na testy by osiągnąć założone przez klienta cele i zabieram się do pracy… Tak to wygląda w Polsce. Aplikacje natywne to jeden aspekt problemu, responsywność serwisów bankowych to kolejny temat, hasła jednorazowe czy stałe hasła do serwisów z hasłami alfanumerycznymi wraz ze znakami specjalnymi, również logowanie wieloetapowy to z kolei zupełnie klasa sama w sobie. Uwierzytelnianie ma być dla klienta proste i wygodne, ale za cenę silnej kryptografii i dokąd nie wprowadzi się w Polsce obowiązku budowania silnie kryptograficznych aplikacji webowych jak i natywnych to możemy tylko pomarzyć o bezpieczeństwie w sieci.

  17. […] — coraz więcej słyszymy o dziurach w aplikacjach mobilnych. Na łamach Niebezpiecznika informowalismy juz o realnych błędach w aplikacjach mobilnych, które mogły posłużyć do ataków np. na bankowość […]

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: