(Nie)bezpieczeństwo aplikacji bankowości elektronicznej w Polsce

Korzystacie z aplikacji do bankowości elektronicznej? Myślicie, że tak ważne aplikacje jak te, które umożliwiają zarządzanie Waszymi pieniędzmi, są sensownie zaprojektowane, bezpiecznie napisane i dobrze przetestowane? My też tak myśleliśmy.

Wczoraj na konferencji Security PWNing Tomasz Zieliński z firmy PGS Software przedstawił wyniki swoich badań dziewiętnastu aplikacji do bankowości elektronicznej oferowanych przez polskie banki. Wyniki jego analizy zasługują na szersze nagłośnienie. Co prawda żadna badana aplikacja nie pozwalała w momencie analizy na prostą i łatwą kradzież środków z konta klienta, lecz niektóre błędy i zaniedbania, na które natrafił Tomasz, wołają o pomstę do nieba.

Kuriozum na dzień dobry

Cały raport Tomasza jest ciekawy, ale najbardziej zaskoczył nas fragment poświęcony zawartości paczki z aplikacją oraz samej aplikacji. W aplikacji Idea Banku Tomasz znalazł… listę loginów i haseł do kont testowych – jak twierdzi część z nich działała również na serwerze produkcyjnym banku.

Może zatem dowiedzieć się, że testerzy lubią hasła takie jak Kanapka6 czy Solaris86. Taki wsad do dowolnej opublikowanej aplikacji powinien spowodować przerażenie osób za nią odpowiedzialnych – a tu mamy do czynienia z aplikacją banku. Ale to tylko jeden z przykładów niedbałości autorów aplikacji. Aplikacja Banku Smart (dzisiaj Nest Bank) zawierała plik develop.properties.example z opisem opcji testowych, które można aktywować podczas kompilacji programu oraz listą kont testowych takich użytkowników jak Hans Kloss, James Blond czy Putin. W aplikacji banku BPH można było znaleźć pliki KML (ślady pozycji GPS dodawane domyślnie do użytej biblioteki),  w aplikacji Credit Agricole logi Jenkinsa, w aplikacji PKO BP nazwisko programisty pracującego nad projektem a w aplikacji  Citi wzór chińskiego potwierdzenia przelewu.

Poważne zaniedbania

W niektórych aplikacjach Tomasz natrafił na problemy które mogły spowodować wyciek danych osobowych klienta lub nawet nieautoryzowane wykonanie operacji na jego koncie. Na przykład w aplikacji BZ WBK do logów systemu Android trafiał adres strony, otwieranej przez aplikację, umożliwiającej złożenie wniosku o kartę. Problem polegał na tym, że adres zawierał token umożliwiający otworzenie tej strony na innym urządzeniu, a zatem odczytanie zawartych na niej danych takich jak imię, nazwisko, PESEL, adres i numer dowodu osobistego.

Jedna z dwóch testowanych aplikacji ING umożliwiała z kolei przejęcie sesji użytkownika. Do logów Androida lądował mianowicie link umożliwiający automatyczne zalogowanie w przeglądarce. Ze względu jednak na zupełnie niepowiązane z tym procesem zabezpieczenia (komunikat pokazujący się w konsoli JavaScript w wersji desktopowej strony, nie mający swojego odpowiednika w aplikacji mobilnej) link lądował w logach Androida i mógł być wykorzystany do załadowania sesji na komputerze i uzyskania dostępu do konta ofiary.

Aplikacja banku Pekao SA do logów Androida zapisywała z kolei całą komunikację sieciową. Całą, zatem także poszczególne znaki stosowanego w procesie uwierzytelnienia hasła maskowanego. Znaki były zapisywane otwartym tekstem. Dlaczego? To dobre pytanie.

Aplikacja Idea Banku (tego od haseł do kont testowych) otrzymywała z serwera dużo informacji. Zdecydowanie za dużo informacji. Oprócz wszystkich danych klienta obejmujących numer telefonu, nazwisko panieńskie matki i numer dowodu tożsamości, zupełnie aplikacji niepotrzebne, otrzymywała ona także informacje, np. o poziomie ryzyka klienta wg banku (w polu customerRiskLevel Tomasz dostał status podwyższony). Aplikacja nie powinna takich rzeczy widzieć, jeśli nie ma takiej potrzeby.

Co z tą bezpieczną komunikacją

Już od dawna standardem w komunikacji pomiędzy aplikacją a serwerem jest nie tylko stosowanie protokołu TLS, ale także tzw. przypinanie certyfikatów (certificate pinning), czyli zaszycie w kodzie aplikacji informacji o tym, jakie certyfikaty TLS może akceptować. Pomaga to uniknąć próby podsłuchu polegającej na dodaniu do zaufanych certyfikatu kontrolowanego przez atakującego. Myślicie, że z takiego mechanizmu korzystały wszystkie aplikacje? To jesteście w błędzie. Przypięcia certyfikatu zabrakło w aplikacjach mBanku, Idea Banku, T-Mobile Usługi Bankowe, Orange Finanse, Banku Smart, Pekao, BZ WBK, Raiffeisena i Citi. Wstyd. Po drugiej stronie rankingu należy postawić aplikacje Getin, Millennium, BGŻ, BPH, Alior Banku, Eurobanku i Credit Agricole, które odmawiały komunikacji z serwerem, który nie przedstawił się prawidłowym certyfikatem. Dodatkowo aplikacja Millennium przesyłała do banku błędny certyfikat, co bez wątpienia pomaga wykrywać ataki na klientów.

Niestety autorzy niektórych aplikacji ciągle uznają, że odrobina HTTP nie zaszkodzi. O ile możemy jeszcze zrozumieć linki do dokumentów na serwerach WWW banku (chociaż naprawdę HTTPS powinien już być standardem) to wczytywanie obrazów pojawiających się na głównym ekranie po aplikacji, jak w BZ WBK, jest grubą przesadą. Aplikacja BPH pobierała w ten sposób listę bankomatów a aplikacje Alior Bank, BZ WBK i  PKO BP wczytywały po HTTP instrukcje bezpiecznego korzystania z aplikacji.

Inne problemy

Chociaż zrobienie nieautoryzowanego zrzutu ekranu w większości telefonów z Androidem nie jest możliwe, to niektóre modele miały problemy to umożliwiające – jednak tylko aplikacje BZ WBK, Getin Banku, Millennium, BGŻ i Credit Agricole blokowały możliwość zrzutów ekranu. W wielu aplikacjach Tomasz odkrył proste problemy związane z jakością kodu – w tym komunikaty o błędach w obcych językach czy wyjątek opisany jako „You do something wrong mapper must contains item type for item %sat this place, Maybe You modify your adapter in illegal way !?”

W apliakcjach Pekao, BZ WBK, mBank i Raiffeisen Tomasz znalazł adresy środowisk testowych. Aplikacja Credit Agricole była taka uprzejma, że umożliwiała podanie adresu swojego serwera w pliku XML – to prawie jak zaproszenie dla przestępców. W aplikacji Eurobanku znalazła się biblioteka diagnostyczna Leak Canary a aplikacja BZ WBK zawierała m.in. funkcje diagnostyczne płatności bezstykowych. W wielu aplikacjach Tomasz znalazł także kod przesyłający dane do polskich i zagranicznych serwisów świadczących różne usługi diagnostyczne i analityczne.

Reakcja banków

Tomasz starał się przekazać swoje spostrzeżenia bankom. Telefony do Biur Obsługi Klienta nie pomogły – nie udało mu się trafić do nikogo komu mógłby swoje obserwacje przekazać. Informacji kontaktowych zabrakło także na stronach banków (za wyjątkiem globalnej witryny ING). Emaile lub formularze kontaktowe pomogły w kilku przypadkach.  Alior Bank i Milennium zareagowały w ciągu kilku godzin, nieco później także ING, mBank, Orange Finanse, BZ WBK i BPH. Pozostałe banki nie ułatwiały komunikacji i wymagały dodatkowych zabiegów by uzyskać odpowiedź na prośbę o przesłanie klucza PGP. Czasem pomogły dopiero wiadomości wysłane bezpośrednio do członków zarządów i działów PR. Na koniec całego procesu zgłaszania błędów jedynie Millennium wystosował list z podziękowaniami i drobnym upominkiem.

Podsumowanie

W artykule nie opisaliśmy wszystkich problemów odkrytych przez Tomasza – osoby zainteresowane szczegółami odsyłamy do pełnej treści jego publikacji. Większość banków zgłoszone błędy już poprawiła. Problemy odkryte przez Tomasza nie oznaczają, że ktoś może ukraść Wasze pieniądze. Większość z nich nie powoduje bezpośrednich negatywnych skutków dla klienta banku, ponieważ wymaga np. posiadania zrootowanego telefonu zainfekowanego przez złośliwe oprogramowanie czy podsłuchiwanego połączenia z siecią, lecz nie umniejsza to wagi znalezisk. Mówimy w końcu o aplikacjach bankowych, które powinny spełniać najwyższe kryteria bezpieczeństwa i jakości.

Warto pamiętać, że mamy rok 2016 i aplikacje polskich banków były już nie raz testowane pod kątem różnych błędów (sami wiemy o co najmniej jednym wcześniejszym projekcie). Mimo tego ciągle można było w nich odkryć błędy których powinien wstydzić się nawet początkujący programista aplikacji mobilnych. Obawiamy się też, że gdy za rok ktoś spojrzy na nowsze wersje tych samych aplikacji, to raport będzie podobny – bo najwyraźniej zapewnienie odpowiedniego poziomu aplikacji przerasta możliwości ich autorów oraz testerów. Mamy tylko nadzieję, ze przynajmniej kilka instytucji po lekturze raportu zmieniło swoje procedury kontroli jakości.

Przy okazji – jeśli interesuje Was tworzenie bezpiecznych aplikacji mobilnych, to zapraszamy na nasze szkolenia poświęcone wykrywaniu i unikaniu błędów w aplikacjach dla Androida i iOS  – już za niecałe 3 tygodnie w Warszawie.