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.
Komentarze
Dzięki!
Skoda tylko, że artykul,do którego odnosicie, posiada mniej szczegółowe informacje niż Wasz :)
Szkoda, chętnie bym poczytał :)
Jak się przyjrzysz to w artykule do którego linkujemy jest link do pliku PDF.
Faktycznie, wielkie dzięki!
https://www.pgs-soft.com/wp-content/uploads/2016/11/Raport_bankowy_2016.pdf
Szkoda, że whitepaper nie zawiera tyle szczegółów, co prezentacja z Security PWNing 2016. Brakuje odniesienia do jakości pracy developerów pewnej firmy, której aplikacje zawierają błędy niegodne studenta.
Bardzo fajnie jednak opisane ;)
Aplikacja Alior Kantor to jest dopiero czad. Bez przerwy „błąd SSL”, „błąd serwera”, „nieznany błąd”. A ty kliencie ugryź się w d… i restartuj do skutku.
Byc moze ktos robi ci Mitm-a :)
Kłamstfo ! same kłamstfa ! Banki som bezpieczne !
Pisałem już kiedyś do Banku Millennium oraz prosiłem o komentarz niebezpiecznik.pl, ale nikt jakoś nie zauważa, że zabezpieczenia w w/w banku są kryptograficznie słabe – konto zabezpiecza identyfikator (jawny), hasło składające się z 8 cyfr (10^8 kombinacji) i jawny PESEL. No ale kogo to obchodzi…
A ten jawny identyfikator w to też 8 cyfr… Bank Millenium ma chyba najbardziej nieprzyjemny system logowania (wymaga wpisania 19 cyfr) a do tego nie za bezpieczny.
To nie jest kwestia programistów ani testerów tylko biznesu. To oni zatrudniają ludzi, zamawiają funkcjonalności, ustalają budżety, czytają raporty i akceptują wersje. Co z tego jak tester zgłosi błąd albo programista potrzebę szkolenia lub więcej czasu na implementację jak mu biznes powie „nie”.
Proszę zatem szanowną redakcję o unikanie komentarzy w stylu „najwyraźniej zapewnienie odpowiedniego poziomu aplikacji przerasta możliwości ich autorów oraz testerów” bo nie oddają one całego obrazu sprawy i są po prostu krzywdzące.
Zgadzam się
Owszem oddają. To co napisałeś odnośnie finansowania i zarządzania takimi projektami jest prawdą i nie stoi w sprzeczności z tezą Adama o ch……. programistach. Przecież to proste: bank określa budżet (zazwyczaj poniżej realnych kosztów lub na granicy) a następnie dostaje za to firmę z kiepskimi ludźmi bez kompetencji. Za dobrego fachowca trzeba dobrze zapłacić. Można też, tak jak ZUS, wywalić spore pieniądze i dostać to co „biznes” dostaje za mniejsze ale to specyfika własności publicznej.
Klauzula sumienia
Również jestem zdziwiony tego typu sformułowaniami. Wydawałoby się, że autorzy znają się trochę na branży i przyczynach tego typu sytuacji.
I tak, i nie. Zwykle jest tak, niestety, jak piszesz – biznes mówi „nie” i już. Jednak jest to kwestia uświadamiania klienta – dobre firmy tłumaczą biznesowi, że to czego potrzebują to spełnienie potrzeb. Finalnie klient mówi „co”, a programiści wiedzą „jak”. No i z drugiej strony trzeba zrozumieć, że może jeśli sie nie da dobrze, to może nie warto w ogóle…
I tak, i nie. W większości przypadków jest, niestety, tak jak piszesz, czyli biznes mówi „nie” i już.
Jednak jest to w dużej mierze kwestia uświadamiania klienta. Dobre firmy tłumaczą biznesowi, że to, po co do nich [informatyków] przyszli, to spełnienie potrzeb. „Potrzeba” to kluczowe słowo. Trzeba wytłumaczyć klientowi, że on mówi „CO” a programiści wiedzą „JAK”. Da się, da się zrobić dobry soft, ale trzeba zwrócić uwagę klienta na rzeczy ważne od strony nie-biznesowej (stykamy przecież biznes z IT).
Jeżeli jednak… to może jeśli nie da się czegoś zrobić dobrze, to może lepiej w ogóle…?
bo chyba chodzi o ten biznes, zeby banki robily kasy a nie zeby byly super bezpieczne itp. ;)
A gdzie Plus bank? ;)
Dlatego ja do banku się loguję tylko z komputera, po kablu i ze specjalnie przygotowanego liveCD. Nie ufam wszystkiemu co loguje do banku ale „lata w powietrzu” (wifi, itd.)
I nigdy nie stoisz przed koniecznością zrobienia przelewu z miejsca gdzie nie masz dostępu do kabla i liveCD?
I masz czas żeby za każdym razem przy drobnym przelewie uruchamiać opisana przez ciebie procedurę?
Zazdroszczę…
Upierdliwe to jest, fakt. Ale liveCD mam zawsze przy sobie, w torbie od laptopa, a jak nie ma możliwości podpięcia się, to mówię odbiorcy przelewu że sorry, ale musi zaczekać aż do domu/hotelu (tam zwykle jest możliwość podpięcia się) wrócę.
Co do hopów, itd. to nawet jeśli leci to na którymś hopie 50km ode mnie w powietrzu, to już tutaj https działa. Tu chodzi raczej żeby zabezpieczyć się przed zeusami itd. (liveCD, czyli tylko do odczytu, czyli odpala się tylko co ja kazałem odpalać no i raczej zeusa na pingwinka nie ma) i debilami z ruterem-wabikiem udającym pobliskie otwarte wifi (podpięcie kabelkiem).
A skąd masz pewność, że na którymś hopie sygnał nie leci przez powietrze? ;)
A jaki problem bezpieczeństwa związany jest z robieniem screenshotów? I jeśli jakikolwiek — to co z desktopami, gdzie nikt nie zabroni w aplikacji webowej zrobienia zrzutu?
No wlasnie, tez sie zastanawiam, jest to szalenie upierdliwe, ostatnio musialem robic zdjecie ekranu, bo aplikacja nie pozwalala na zrobienie screenshota.
Screenshoty ujawnić mogą wpisywane hasło w aplikacji.
Bo gwiazdki/kropki ci dużo powiedzą…
Na Androidach widać ostatnio wpisaną literę hasła. Jeśli ktoś robiłby zrzuty ekranu po każdej wpisanej literze, odczytałby całe hasło. Genialny wynalazek tak BTW.
Nieźle zaufana trzecia strona umie ominąć adblocka a youtub nie umie :)
Bo pewnie są wbudowane w stronę.
Ja osobiście gdybym chciał obrabować konto firmy ( danej) nie musiałbym włamywać się na Ich konto do banku. Wystarczyło by żeby gwizdnąć im starego twardziela od serwera… Wszytko tam jest. Księgowość , numery kont kwoty, hasła, i loginy. Wystarczy trochę pohakować i taki np. Mostostal ,lub Zakłady Chemiczne w… nawet by sie nie spostrzegły że KTOŚ im wytransferował w nocy kilka milionów na przysłowiowe małe Antyle lub na Banco Aruba. Najsłabszym ogniwem w firmie jest nie przechowywanie danych ale… staroci ! Włamywać się do Banku aby mnie spec służby namierzyły…(!?) Głupota. Niech sobie co poniektórzy przypomną jak w D. ktoś podmienił numery kont podczas pewnej płatności. Trzysta tysięcy wyfrunęło nie tam gdzie trzeba. Do dzisiaj nikt tych pieniędzy nie znalazł. Faktury poszły do kogoś kto potem kasy nie dostał. Ja tego nie zrobiłem ale mechanizm jest prosty, miejscami aż za prosty. Ale jak to sie mówi wszystko do czasu…