Bezpieczeństwo aplikacji mobilnych w Polsce – małe i duże wpadki polskich aplikacji

mobiletrends.pl 1 rok temu

W polskich aplikacjach zdarzały się już niebezpieczne, a czasem choćby zabawne incydenty. Rodzi to jednak konieczność świadomości zagrożeń i warunków korzystania z aplikacji wśród użytkowników. Programiści za to muszą dbać o standardy i zabezpieczenia, ale najpierw biznes powinien im to umożliwić. Zacznijmy jednak od początku!

Rozwój cyberprzestępczości jest faktem. W samych aplikacjach jednak, jak już wiemy, powstaje dużo błędów. Sprawdź czy aplikacje mobilne są bezpieczne! W Polsce mogliśmy zaobserwować też wiele niebezpiecznych dla użytkowników i firm sytuacji związanych z mobilnym security. Z roku na rok, jest ich na szczęście coraz mniej.

Przyjrzymy się dzisiaj mBankowi, Żappce, Jaśminie, e-TOLL i StopCOVID.

Biedronka przypomniała przypadek mBanku

Jest środa. 7 września 2022 r. Jeronimo Martins niedawno wypuściło aplikację Biedronki. Kilka minut przed 16:00 użytkowników zasypują lakoniczne powiadomienia. Na ekranach pojawia się „p2”, „pusca” i „puszka”. Po kliknięciu w pushe otwierała się strona z komunikatem o błędzie. Aplikacja zaczęła mieć problemy z działaniem. Okazało się, iż powiadomienia nie miały opuścić środowiska testowego.

Biedronka gwałtownie pozbyła się usterki.

mBank zalicza pamiętną, ale niegroźną wpadkę

Sytuacja przypomniała jednak wpadkę mBanku sprzed dwóch lat. Ta również dotyczyła testowania powiadomień na produkcji. 5 sierpnia 2020 sieć zalano setkami screenshotów od klientów pokazujących dziwne powiadomienia. Na szczęście dla mBanku nie było tam wulgaryzmów, a jest to dosyć częstym żartem programistów.

Klienci, niektórzy przerażeni, inni rozbawieni, masowo wchodzili w te powiadomienia. Przeciążyli system.

Bank gwałtownie sobie poradził z tą wpadką i zbudował wokół niej kampanię, która obróciła ją w żart.

Wiele osób poważnie przestraszyły te pushe. Nic dziwnego. Niebezpiecznik przypominał o wcześniejszych atakach na routery, kiedy przestępcy podszywali się pod komunikaty banków i wyłudzali pieniądze. Podobne wpadki miały miejsce w innych bankach, np. w ING, który kilka miesięcy wcześniej rozesłał przez pomyłkę komunikat do większej liczby klientów, zamiast do jednego. Takie sytuacje potęgują niebezpieczeństwo wyłudzeń ze strony oszustów, którzy wykorzystują podobne metody, chociażby przy pomocy trojana Citadel.

Później niektórzy klienci mBanku mają wgląd do cudzego rachunku!

Jednak niecałe trzy tygodnie później dochodzi do o wiele poważniejszego incydentu. W 2020 r. 24 sierpnia jeden z czytelników Niebezpiecznika przesłał do jego redakcji wiadomość, w której opisał jak założył swoje pierwsze konto w mBanku. Podczas zakładania konta okazało się, iż w bazie widnieje już jego numer dowodu osobistego jako właściciela subkonta. Użytkownik nigdy nie miał tam konta i nie znał właściciela subkonta. Kiedy zostało mu założone konto, okazało się iż jego numer telefonu został przypisany do właściciela subkonta, który dostał powiadomienie, iż jego numer telefonu został zmieniony. Nowy użytkownik mBanku otrzymał też SMS z hasłami do realizacji transakcji. Hasła te również należały do właściciela subkonta.

Czytelnik uruchomił też aplikację mBanku, gdzie po zalogowaniu zobaczył konto właściciela subkonta. Mógł przeglądać historię transakcji i wypłacać cudze pieniądze, jednak dane w profilu nie należały do właściciela subkonta, a do niego. Po zakupach w Biedronce zauważył, iż do historii dołączył nowy zakup.

Osoby te skontaktowały się ze sobą i postanowiły powiadomić mBank o zaistniałym problemie. Bank tymczasowo zablokował oba konta. Co się stało?

System nadpisał stare konto nowym kontem innego użytkownika.

Kilka dni później inni użytkownicy informowali, iż wciąż byli odcięci od swojego konta, przez cały czas widzieli dane osobowe innego klienta i mogą zapłacić swoją kartą na cudzym saldo. Użytkownicy, których konta zostały nadpisywane przez nowe, widzieli dane osób, które zakładały konto. Numer i data ważności dowodu osobistego, adres zameldowania i zamieszkania, te dane widziały wzajemnie osoby, których konta zostały ze sobą “złączone”. Starzy klienci nie mogli choćby tego zgłosić do mBanku. Pracownicy mLinii nie byli w stanie rozwiązać tego problemu, bo “ich dane nie zgadzały się z danymi właściciela rachunku”.

Zapytano mBank ile osób dotknęły te problemy, skąd one wynikają i czy można określić nowych klientów, których błąd dotknął. Niebezpiecznik spekulował, iż problem jest związany z wewnętrznymi aplikacjami banku, których używają przedstawiciele w oddziałach. Mógł w nich nastąpić błąd porównywania numerów dowodów, które bank traktuje jako unikatowe klucze w bazie. Możliwe było też niepoprawne wprowadzenie identyfikatora użytkownika.

mBank na pytanie o powód problemu odpowiedział, iż niewielka grupa klientów miała dostęp do informacji innych osób z powodu tego błędu. Bank natychmiast ograniczył im dostęp do serwisu ze względów bezpieczeństwa, a pieniądze klientów zostały zabezpieczone. Bank kontaktował się indywidualnie z każdą osobą, której dotyczył problem, i podjął wszystkie niezbędne kroki zgodne z prawem, interesem i bezpieczeństwem klientów. Bank serdecznie przeprosił wszystkich klientów, których dotknęły te problemy.

W e-TOLL była potężna dziura!

API jest wygodne, ale może być ryzykowne. W 2021 r. przekonało się o tym Ministerstwo Finansów. 26 października Niebezpiecznik informował, iż w dopiero co oddanym do użytku systemie poboru opłat, można było pobrać coś innego niż opłatę. e-TOLL, podobnie jak wcześniej Plus, nie uwierzytelniał API. System nie posiadał poprawnie zaimplementowanego uwierzytelniania. Spowodowało to, iż z zapytania można było usunąć parametr beneficiaryId. To dominanta odpowiadająca za identyfikację aktualnego użytkownika. Po usunięciu tego parametru można było zobaczyć obiekty z danymi ticketów innych użytkowników systemu.

Dziurawe API sprawiło, iż bez problemu można było pobrać dane innych użytkowników systemu. Najbardziej sowitym łupem były PESEL-e. Oprócz numeru PESEL bez problemu można było dobrać się do imienia i nazwiska, e-maila, numeru telefonu, NIP-u, szczegółów z przeglądarki i systemu operacyjnego, saldo konta czy historii wpłat i wypłat innego użytkownika.

Urząd gwałtownie naprawił lukę. Ministerstwo Finansów potwierdziło usunięcie błędów., ale niesmak pozostał.

Zwłaszcza, iż aplikacja mobilna sprawiała problemy użytkownikom.

System e-TOLL żądał ciągłego dostępu do lokalizacji, autostartu, informacji o aplikacjach i dostępu do schowka. Wymagała wszystkich danych personalnych – nr dowodu, PESEL, adresu zamieszkania, nr telefonu, e mail, VIN-u pojazdu. Aplikacja nieraz wymagała obecności drugiej osoby, bo kierowca nie był w stanie skupić się na jeździe. Jeden z użytkowników pobrał bilet przy wjeździe na A4. Jego żona w tym czasie włączała aplikacje, ktora nie otworzyła im bramki. Potem w czasie jazdy aplikacja nagle zaczęła działać. Kierowca czekał kilka minut przed bramką na autostradzie bez odpowiedzi aplikacji. Gdy chciał zawrócić, bramka nagle się otworzyła. Po jakimś czasie aplikacja ściągnęła poprawną kwotę z jego konta. Użytkownik nie był jednak zadowolony.

Frustracja, to słowo, które opisuje UX tej aplikacji. 2 lata później nie jest lepiej. Aplikacja w Google Play ma ocenę 1,6 gwiazdki, czyli jeszcze mniej niż na początku. – Nie działa, jak wszystko w tym kraju – pisze w komentarzach jeden z użytkowników.

Jaśmina – naruszenie licencji i dostęp do danych wyborców

Szymon Hołownia przed kongresem Polska2050 ogłaszał, iż będzie miał wyjątkowego gościa. Nie obyło się bez uszczypliwości od TVP, gdy okazało się, iż gościem tym nie jest Barack Obama tylko aplikacja, Jaśmina.

Niestety, aplikacja już po tygodniu zaliczyła pierwsze wpadki. Okazało się, iż korzysta z cudzego kodu, co nie jest niczym złym. Naruszyła jednak licencję Apache, co wskazuje na brak przygotowania prawnego aplikacji. Co więcej, w Jaśminie można było podejrzeć adresy e-mail użytkowników. Jeden z użytkowników napisał na Twitterze, iż był w stanie masowo pobierać z niej adresy e-mail.

Tutaj również winne jest API. Aplikacja zwracała e-maile w odpowiedzi na zapytania do API.

Konto Jasmina_2050 zamiast podziękować, stwierdziło, iż dziura była szczęśliwym trafem użytkownika, i iż w krótkim czasie “odebrali mu zabawkę”, więc nie ma o czym mówić. Równocześnie nadali mu imię, nazywając go Łukaszem, co jest kuriozalne w kontekście naruszania danych osobowych.

Fundacja Panoptykon obwieściła wielkie rozczarowanie postawą Jaśminy do ochrony prywatności swoich sympatyków.

Błędy zdarzają się choćby najlepszym, zatem dziwi postawa Polski2050. Zwłaszcza w obrębie nowych wartości i uczciwości, jakie głosi Szymon Hołownia. Przypadek ten pokazuje, iż przed daniem aplikacji na produkcję, warto sprawdzić jej zgodność z licencjami, standardami bezpieczeństwa oraz wytycznymi UODO.

Aplikacja rządowa – wielki projekt i wielka wpadka

Nie sposób opowiedzieć całą historię “Stop COVID”. Powiedzieć, iż to kontrowersyjna aplikacja, to jak nic nie powiedzieć. Nieodpowiedzialna w kwestii prywatności. Nie byłoby to wielkim problemem, gdyby nie fakt, iż to aplikacja rządowa! Miała walczyć z koronawirusem. Za to skutecznie walczyła z programistami i testerami. Na początku zastosowano w niej technologię umożliwiającą inwigilację. Następnie rząd stwierdził, iż aplikacja jest zdecentralizowana i iż kod źródłowy projektu jest dostępny dla wszystkich, co okazało się nieprawdą. Według wielu doniesień medialnych, od lipca do października aplikację uruchomiło “aż kilkadziesiąt” osób. Brak zainteresowania aplikacją spowodował, iż rząd chciał zmusić społeczeństwo, nakładając ograniczenia w sklepach bez ProteGO Safe (wcześniejsza nazwa). Głośne sprzeciwy Polaków spowodowały upadek tego pomysłu, a Ministerstwo Cyfryzacji pośpiesznie usunęło ze stron internetowych ślady nieodpowiedzialnych wytycznych dla sprzedawców. Twierdząc, iż nie były one wydane, zarzuciło mediom rozpowszechnianie fake newsów. Scena jak z filmów Barei. Podobnie zresztą było z “rekomendacjami” dotyczącymi obostrzeń. (XD) Jednak ludziom w trakcie kwarantanny narzucono już obowiązek jej instalacji.

Rząd zdecydował się na zaimplementowanie protokołu contact tracingu.

Programiści uznali, iż oparcie aplikacji na scentralizowanej PWA jest w porządku.

Niebezpiecznik mówił o problemie z WebView. W uproszczeniu kod takiej aplikacji jest ładowany z serwera, co powoduje brak prywatności użytkowników. Takie podejście jest nieodpowiedzialne, biorąc pod uwagę możliwe gromadzenie danych przez serwery Ministerstwa Cyfryzacji i “ciche aktualizacje” kodu. Taka implementacja nie ma nic wspólnego z prywatnością. Autor wpisu sugerował, iż to brak zrozumienia prywatności przez programistów albo szantaż lub nacisk ze strony innych osób. Jeden z programistów, który pracował przy aplikacji Stop COVID odradzał choćby jej instalację! gwałtownie zrezygnował z pracy. Podczas podpisywania profilem zaufanym oświadczenia o licencji kodu, dostał podziękowania. Pojawiła się w nich pełna lista e-maili osób, które podpisały podobne oświadczenie. Wyciek danych w zwykłym mailu od Ministerstwa. Błąd ludzki, zdarza się, ale to wciąż Ministerstwo.

Naciski programistów i mediów związanych z bezpieczeństwem doprowadziły do konferencji, która ociepliła wizerunek rządu. Minister Marek Zagórski potwierdził, iż model WebView nie przejdzie dalej. Zaufanie do aplikacji mogło rosnąć, jednak wtedy ktoś wykorzystał prorządowe boty, aby promować aplikację Stop COVID. Było to jednak tak nieudolnie, iż zaufanie do aplikacji spadło, a w sieci spowodowało salwy śmiechu. Wielu podejrzewa, iż to wewnętrzne tarcia polityczne mające ośmieszyć Ministerstwo Cyfryzacji.

twitter.com/WojtekKardys

Były programista “Stop COVID” podniósł też, iż aplikacja zawierała funkcje poboczne. Kod zaczął się znacznie rozrastać i różnić od wcześniejszej specyfikacji, co utrudniało jego weryfikację przez niezależnych specjalistów.

Nie jest jasne, dlaczego zamiast rozwijać najważniejsze funkcjonalności, do aplikacji dodawane były poboczne moduły, takie jak ankiety dot. zdrowia, które korzystają z API od Infermedica.

Informacje z ankiety miały być anonimowe, jednak pojawiają się wątpliwości co do tego, jak anonimowe są adresy IP osób, które udzielały odpowiedzi. – Na wstępie dodam, iż nie jesteśmy powiązani w żaden sposób z aplikacją Stop COVID (dawniej ProteGo Safe). Projekt po prostu korzysta z naszego darmowego API. Sama aplikacja PorteGo rzeczywiście zbiera sporo informacji, ale prawda jest taka, iż do nas nie dociera nic, co mogłoby zidentyfikować użytkownika. Nie dostajemy ani imienia ani adresu IP użytkownika, bo requesty idą przez serwery twórców aplikacji (więc my widzimy tylko adres ich serwera). Jedyne co jest prawdą to, iż trafia do nas User-Agent i to by było na tyle – napisał Niebezpiecznikowi Piotr Orzechowski z Infermedica.

Trochę lepiej!

W końcu zdecydowano się jednak na API od Google/Apple. Sekurak tłumaczy, iż to API korzysta z Bluetootha i jest domyślnie wyłączone na poziomie telefonu, czyli żeby uczestniczyć w projekcie trzeba zainstalować apkę oraz dodatkowo włączyć wspomniane API. Nie wysyła też danych do chmury. Chyba, iż użytkownik wyrazi na to zgodę. To rozwiązanie miało zapewniać maksymalną prywatność.

Na szczególne uznanie zasługuje tutaj Sekurak, które podjęło się szerokiej analizy aplikacji oraz audytu jej bezpieczeństwa. W raporcie od Securitum znalazło się blisko 40 błędów. Nie było tam wysokich czy krytycznych luk, bo wiele z nich zostało poprawione lub częściowo poprawione po medialnych poprawkach. Zgodnie z deklaracją otrzymaną od zespołu Klienta, aplikacja webowa została w całości wdrożona w aplikacjach mobilnych w wersji lokalnej, nie odwołującej się do aplikacji wskazanej w domenie safesafe.app i pod tym adresem została umieszczona strona HTML wraz z informacja o projekcie i linkami do sklepów Google Play i Apple App Store. Celem testów nie była jednak analiza aspektów prywatności, a wykrycie potencjalnych podatności na niebezpieczeństwa. Analiza aplikacji nie obejmowała też przeglądu Bluetooth i mechanizmu Exposure Notification.

Darmowe zakupy w Żabce?

Na koniec, jedna z najświeższych sytuacji. 23 stycznia 2023 roku, Niebezpiecznik poinformował, iż dziura w API żappki pozwalała dowolnie podbić saldo punktów w aplikacji. W ten sposób można było pozwolić sobie na darmowe zakupy. Nieautoryzowane doładowanie żappsów, czyli punktów w programie lojalnościowym Żabki pozwalało wymienić je na fizyczne produkty. A co trzeba było zrobić, aby podbić sobie punkty? Wystarczyło wysłać żądanie do API, które miało treść, jak na poniżej załączonym obrazku.

Specjaliści Niebezpiecznika informują, iż metoda points.upcharge zdradziła, iż wykorzystywane jest tu API Synerise. Do przetwarzania żądań w tym API trzeba znać token z odpowiednimi uprawnieniami, ale nie zawsze, co pokazuje wspomniana już wpadka Plusa czy e-TOLL.

Nie wiadomo, kto pierwszy wykorzystał żądanie do nabijania punktów w aplikacji Żabki.

Według ustaleń Niebezpiecznika możliwe, iż osoba ta miała dostęp do środowiska testowego lub konta o odpowiednich uprawnieniach. W grudniu 2022 r. miał miejsce incydent dotyczący pracowników Żabki, w wyniku którego nieuprawnione osoby miały dostęp do ich haseł pracowników. Mogło mieć to związek z nabijaniem punktów. Jednak jeden z pracowników stwierdził, iż metoda points.upcharge nie była weryfikowana i można było użyć dowolnego tokenu, co było poważnym błędem implementacji. To także brak odpowiednich testów API.

Żabka potwierdziła, iż incydent zaistniał, ponieważ ktoś niepoprawnie skonfigurował system, umożliwiając zbyt szerokie działanie metody points.upcharge. Potwierdziła to także osoba doskonale znająca API Synerise. Okazało się, iż umożliwia ono odpowiednie obsłużenie tej metody, aby uniemożliwić nieautoryzowane akcje, jednak wymaga to szczegółowej implementacji. W przypadku błędu, pojawiają się takie problemy.

Sytuacja spowodowała, iż wielu użytkowników wykorzystało lukę i “okradło Żabkę”, wynosząc z niej darmowe zakupy. Niektórzy chwalili się pełnymi bagażnikami towaru za “lewe” żappsy, jak to ładnie określa redakcja Niebezpiecznika. Jednak po zdekodowaniu żądań, API zostawia wiele identyfikatorów, które pozwalają dotrzeć do “hackerów”. Kamery w sklepach i działania informatyków doprowadzają do zatrzymania przez Policję kilku klientów. Jednym z nich był zatrzymany Filip.

Jesteśmy względnie bezpieczni

Główne zagrożenia związane z kodowaniem aplikacji obejmują nieodpowiednie zabezpieczenia danych, luki w kodzie czy wycieki danych. Deweloperzy powinni stosować odpowiednie praktyki oraz aktualizować i sprawdzać implementację API, aby zapewnić im stabilność. Przykłady włamań i ataków pokazują, iż choćby najmniejsza luka może doprowadzić do poważnych konsekwencji. Porównując jednak raport CERT z 2021 do raportu Spicy Mobile z 2019 czy PGSSoft z 2016, widzimy wzrost zagrożeń, ale znaczną zmianę po stronie deweloperów. Błędów jest ogrom, ale nie ma już wielu krytycznych luk w aplikacjach.

Biznesie: wybieraj mądrze!

Pamiętaj, iż wina często leży po stronie pospiesznych klientów, a nie samych programistów, którzy mogą nie mieć odpowiedniej ilości czasu w zaprogramowanie zabezpieczeń. Deweloperzy również potrzebują czasu oraz szkoleń. Mogą nie wiedzieć wszystkiego. Luki najczęściej wynikają z pośpiechu, braku komunikacji lub braku odpowiednich narzędzi. Ważna jest też sama decyzja co do partnera strategicznego, który zajmie się developmentem produktu.

Bezpieczeństwo aplikacji zaczyna się w momencie wyboru software house’u. o ile wybierzemy malutkie studio, gdzie jest 2-3 deweloperów i tester, to tak naprawdę dużo furtek pozostaje otwartych, o ile chodzi o bezpieczeństwo – mówi Ilona Leoniewska. Przy wyborze partnera projektu, warto więc zwrócić uwagę na to, jakie tam jest podejście do bezpieczeństwa, jakie jest pokrycie tworzonego przez firmę kodu testami, czy ma na pokładzie osobę, która zajmuje się serwerami, całą infrastrukturą i architekturą – kwituje CRO z Escola SA.

Mimo wszystko, na więcej niebezpieczeństw narażeni są użytkownicy. SMS-y obiecujące kupony od Żabki, Oficjalne serwery pocztowe Ergo Hestii atakujące Polaków, ataki malware na klientów Santandera, trojany dla IN G w mailach, phishing podszywający się pod mBank, punktowy wyciek danych kupujących na Allegro, SMS-y podszywające się pod InPost, phishing automatyczny z Allegro. Takich sytuacje są tysiące, a większość z nich koncentruje się na użytkownikach. Cyberprzestępcy częściej ich atakują niż same aplikacje, bo jest to po prostu łatwiejsze. Nic dziwnego, skoro w 2021 roku najpopularniejszym hasłem było 123456. Dlatego edukacja użytkowa jest bardzo ważna.