Biblioteka, która zapisuje login i hasło do banku i przechwytuje Wasze SMSy

Chcielibyście w aplikacji do zamawiania pizzy zapisać swój login i hasło do banku oraz umożliwić jej przechwytywanie wiadomości SMS z kodami autoryzacyjnymi wysyłanymi Wam przez bank? Brzmi niezbyt ciekawie, prawda? A dla Przelewy24 to dobry pomysł.

Serwis Przelewy24 zazwyczaj kojarzony jest jako pośrednik gwarantujący wysokie bezpieczeństwo transakcji internetowych, przy jednoczesnym zapewnieniu szybkości realizacji płatności. Rzeczywiście, proces zatwierdzania płatności w klasycznej wersji “przeglądarkowej” jest bezpieczny i nasze dane logowania nigdy nie opuszczają strony internetowej banku (zakładając oczywiście, że na komputerze nie znajduje się złośliwe oprogramowanie). Sytuacja może się jednak zmienić diametralnie, kiedy korzystamy z aplikacji napisanej przy użyciu tzw. bibliotek mobilnych Przelewy24.

Proces płatności w aplikacji mobilnej wyglądem bardzo przypomina ten “desktopowy”.

Przeglądarka osadzona

Biblioteki Przelewy24 realizują proces zatwierdzania płatności poprzez tzw. przeglądarkę osadzoną w aplikacji. Dalej klasycznie: w przeglądarce ładowany jest najpierw serwis Przelewy24, a później zależnie od wyboru użytkownika, strona internetowa konkretnego banku.

Zacznijmy od podstaw: co to w ogóle jest “przeglądarka osadzona”? Tego typu rozwiązania można spotkać od wielu lat na różnych platformach, a ich głównym zastosowaniem jest tworzenie aplikacji, które z jakiegoś powodu implementują interfejs użytkownika w postaci strony internetowej. Dwie nietypowe właściwości tego rozwiązania uwzględniają:

• dostęp do dodatkowych interfejsów skryptowych, które są przeglądarce wystawiane przez aplikację – uprawnienia udzielane skryptom JavaScript zależą od decyzji programisty, niekiedy skrypty pracują z uprawnieniami (i możliwościami) normalnych programów;
• wysoki wpływ aplikacji na to, co dzieje się wewnątrz wykorzystywanej przez nią osadzonej przeglądarki – chociażby możliwość wykonywania skryptów JavaScript w kontekście załadowanej strony.

Czy zalogowalibyście się do swojego banku w przeglądarce osadzonej w aplikacji do zamawiania pizzy? Co by nie mówić, okno aplikacji z przedstawionego wyżej zrzutu ekranu wygląda dość wiarygodnie i być może faktycznie byłbym skłonny wpisać tam swoje dane. Dla pewności zerknąłem jednak do dokumentacji, a także samej biblioteki. W wyniku tego “dochodzenia” dowiedziałem się, że w takiej sytuacji, wspomniana “aplikacja do zamawiania pizzy” może wstrzykiwać dowolny kod JavaScript do strony banku. I co najciekawsze: rzeczywiście to robiła.

Tak właśnie działała biblioteka promowana przez Przelewy24, która pozwala programistom na zbudowanie własnej “aplikacji do zamawiania pizzy” zintegrowanej z płatnościami u tego pośrednika. Co więcej, oferowała ona wiele interesujących funkcji, np. zapamiętywanie naszego hasła do banku w celu późniejszego autouzupełniania (nawet w przypadku haseł maskowanych), a także automatyczne przepisywanie kodów SMS. Mając zrozumiałe podejrzenie, że jest to jakiś rodzaj malware albo oszustwa, przystąpiłem do analizy.

Wstrzykiwanie kodu JavaScript do strony banku

Podczas inicjowania procesu płatności biblioteka łączy się z serwerem Przelewy24 i pobiera z niego archiwum zawierające konfigurację oraz skrypty przeznaczone dla poszczególnych banków. Skrypty te zajmują się przechwytywaniem danych logowania, a także automatycznym ich uzupełnianiem.

Biblioteka mobilna obserwowała adres strony załadowanej w osadzonej przeglądarce, a jeżeli odpowiadał on adresowi strony logowania określonego banku, wybierała odpowiedni skrypt i wstrzykiwała go do załadowanej strony w ten sposób:

package pl.dialcom24.p24lib.bank;

public class e {
   /* ... */
   private void b(final String var1) {
      if(var1 != null) {
         this.c.post(new Runnable() {
            public void run() {
               e.this.c.loadUrl("javascript:(function() {\n   var script = document.createElement(\'script\'); \n var newContent = document.createTextNode(\'" + var1 + "\'); \n script.appendChild(newContent); \n  document.getElementsByTagName(\'head\')[0].appendChild(script); \n })()");
            }
         });
      }
   }
   /* ... */
}

Przytoczona funkcja wywoływana jest w odpowiedzi na zdarzenie załadowania strony w przeglądarce (WebViewClient.onPageFinished). Natomiast tak wyglądał wstrzykiwany kod JavaScript w przypadku jednego z banków:

var id = "userID";
var pwd = "pass";
var sms = "SmsCode";

function Bank() {
   BankBase.call(this, id, pwd, sms);
}

Bank.prototype = Object.create(BankBase.prototype);

Bank.prototype.registerJsEventListners = function() {
   this.addEventListenerForId("submitButton", "click", this.getGredentialsIfIdNotNull);
};

BankBase.prototype.setCredentials = function(idVal, pwdVal) {
   if (idVal || pwdVal) {
       $("#submitButton").removeClass("disabled").removeAttr("disabled");
   }
   return this.setCredentialsById(idVal, pwdVal);
};


Bank.prototype.scrollToFriendlyEl = function() {
   setTimeout(function() {
      if (B.scrollToElById(B.sms)) return;
      if (B.scrollToElById("submit")) return;
   }, 10);
};

var P24_B = new Bank();
var B = P24_B;

Nie był to jedyny wstrzykiwany plik, oprócz kodu specyficznego dla danego banku dodawany był również plik „biblioteczny” (clean code!) z kodem wspólnym, m. in. implementacją klasy P24_B.

Konfiguracje dla poszczególnych banków zawierały również wyrażenia regularne opisujące format SMSów z kodami autoryzacyjnymi oraz informację o numerze nadawcy. Posiadając te informacje, biblioteka Przelewy24 była w stanie automatycznie wyłuskać kod do autoryzacji transakcji z przysłanej na nasz smartfon wiadomości SMS. Przykładowy plik konfiguracyjny prezentował się tak:

bankFriendlyName=Example Bank
bankUrl=https://bank.example.com/
bankUrlTransfer=https://transfer.bank.example.com/
bankSmsSender=5555
bankSmsRegex=^.*kod sms: (\d{8}).*$

Po przeczytaniu tych wartości biblioteka wiedziała, że jeżeli użytkownik zostanie przekierowany na stronę bank.example.com, to należy wstrzyknąć powyżej przytoczony kod JavaScript. W przypadku niektórych banków biblioteka ingerowała również w wygląd stron, poprzez wstrzykiwanie własnych arkuszy CSS, które ukrywały niektóre komunikaty, albo zmieniały sposób wyświetlania kontrolek w formularzu.

Brzmi absurdalnie, prawda? Być może dla niektórych wygląda to wręcz jak działanie złośliwego oprogramowania? Nic bardziej mylnego.

Zapamiętamy Twoje hasło, dla Twojej wygody

Była to jedna z oficjalnych funkcji bibliotek mobilnych Przelewy24, która miała na celu poprawienie tzw. user experience podczas dokonywania płatności. Dlaczego “była”, a nie “jest”? Do tego dojdziemy wkrótce.

Komunikat wyświetlany przez starszą wersję biblioteki Przelewy24 po załadowaniu się strony logowania do banku.

No dobrze… Gdzie wobec tego trafiały przechwycone dane? Były one szyfrowane algorytmem AES ze statycznym kluczem (czyli poniekąd raczej “kodowane”) i zapisywane w pamięci urządzenia.

Problem z tym rozwiązaniem polega na tym, że biblioteka Przelewy24 dołączona do androidowej aplikacji jest jej integralną częścią, a więc działa w tym samym kontekście bezpieczeństwa. Oznacza to że biblioteka jest w stanie odczytać dane zapisane przez aplikację i vice versa.

Wcześniej zadane pytanie można sformułować ponownie: czy pozwolilibyście aplikacji do zamawiania pizzy na wykonywanie dowolnego kodu JavaScript w kontekście strony internetowej waszego banku, zapamiętywanie Waszych danych logowania i omijanie dwuskładnikowego uwierzytelniania poprzez automatyczne przechwytywanie SMSów?

Oczywiście, logowanie się do banku przez jakąkolwiek zewnętrzną aplikację jest niebezpieczne. Tutaj mamy jednak do czynienia z oficjalnym rozwiązaniem wypromowanym przez Przelewy24, które stwarza iluzję, jakoby użytkownik zatwierdzał transakcję w “osobnym, bezpiecznym podsystemie”. W rzeczywistości wygląda to jak ukłon w stronę twórców złośliwego oprogramowania – zaledwie niewielka modyfikacja biblioteki pozwala zmienić ją w narzędzie do czyszczenia kont bankowych.

Poziom bezpieczeństwa tego rozwiązania mógłby wzrosnąć do akceptowalnego poziomu, gdyby zostało ono zaprojektowane w formie oddzielnej aplikacji do przeprowadzania płatności. Te zalecenia, wraz z załącznikiem w postaci proof-of-concept aplikacji złośliwie wykorzystującej bibliotekę do kradzieży haseł przesłałem do producenta rozwiązania. Otrzymałem następującą odpowiedź:

Dziękujemy za wnikliwą analizę i przesłanie tak obszernej dokumentacji wykrytej podatności. Potwierdzamy, że opisany przez Pana scenariusz jest prawidłowy.

Dotyczy on wyłącznie bibliotek mobilnych w wersji 2.x Obecnie przygotowujemy paczkę z bibliotekami w wersji 3.x W wersji 3.x – domyślnie opcja „zapamiętaj login i hasło do banku” będzie wyłączona, bez możliwości włączenia tej opcji przez twórcę Aplikacji bez wiedzy użytkownika. Zarówno w wersji 2.x, jak i 3.x decyzja o tym, czy dane te będą zapamiętane na urządzeniu, zawsze finalnie należy do Użytkownika. Nie jest to obowiązkowe. Wraz z udostępnieniem nowej wersji bibliotek, będziemy kontaktować się z poszczególnymi Merchantami z prośbą o ich aktualizację w udostępnionych aplikacjach.

Natomiast chcielibyśmy podkreślić, że Klient instalując aplikację z nieznanego źródła, bądź od niezaufanego, z jego punktu widzenia, wydawcy, powinien być świadomy zagrożeń bezpieczeństwa jego danych. Dotychczasowa analiza rynku pokazała jednoznacznie, że zewnętrzna aplikacja P24 nie jest rozwiązaniem satysfakcjonującym zarówno Merchanta, jak i Klienta.

– Krzysztof Szanecki – CTO Przelewy24

Z odpowiedzi wynika, że twórcy biblioteki byli świadomi, że ich rozwiązanie już na poziomie “papierowego projektu” łamie koncepcję aplikacyjnego sandboxa i przez to zapewnia mizerny poziom zabezpieczeń. Z przyczyn marketingowych nie została jednak podjęta decyzja o zmianie biblioteki w aplikację. W zamian obiecano jednak wprowadzenie większych ograniczeń w stosunku do funkcji zapamiętywania hasła.

Banki reagują

Przed publikacją artykułu nieformalnie zasięgnęliśmy opinii działów bezpieczeństwa kilku dużych banków. Banki jednoznacznie negatywnie wypowiedziały się o pomyśle Przelewy24. Ku naszemu całkowitemu zaskoczeniu kilka dni później omawiana biblioteki została radykalnie odchudzona – całkowicie zniknęła możliwość zapamiętywania hasła oraz automatycznego przepisywania kodów z SMSów. Pomimo, że w kodzie nowej biblioteki pozostały ślady po starych funkcjach, faktycznie przestała ona wstrzykiwać kod JS/CSS specyficzny dla poszczególnych banków, a z konfiguracji zniknęły wyrażenia regularne służące do wyłuskiwania kodów z SMSów.

O ile względny poziom bezpieczeństwa po tej operacji znacznie wzrósł, ogólna zasada działania biblioteki nadal nie uległa zmianie. Proces logowania do banku i zatwierdzania płatności ciągle odbywa się w przeglądarce osadzonej, która działa w kontekście obcej, zewnętrznej aplikacji. Nie daje to użytkownikowi żadnej możliwości odróżnienia właściwego procesu zapłaty od phishingu.

Możliwe zagrożenia

• Złośliwa aplikacja może używać podrobionego widoku Przelewy24, który będzie identyczny pod względem graficznym i funkcjonalnym. Użytkownik nie ma możliwości sprawdzenia, czy ma do czynienia z oryginalną biblioteką mobilną, czy podróbką.
• Złośliwy programista może zmodyfikować kod oryginalnej biblioteki i dołączyć go do swojej aplikacji.
• Istnieje również ryzyko użycia oryginalnej biblioteki i ingerowanie w jej stan przez zewnętrzną aplikację (np. za pomocą Reflection API).

Niezależnie od tego, który z powyższych wariantów zostałby wybrany, możliwe jest dowolne manipulowanie kontrolką WebView, w tym:

• Przechwycenie wpisanego loginu i hasła do banku przez zewnętrzną aplikację,
• Podmiana informacji w serwisie transakcyjnym, np. wyświetlenie innego numeru konta albo tytułu przelewu, niż w rzeczywistości,
• Aktywny phishing użytkowników poprzez przekierowanie ich do fałszywego serwisu transakcyjnego.

Ponownie pragniemy też podkreślić, że problem wynika z architektury rozwiązania proponowanego przez Przelewy24 (czyli bibliotek mobilnych) i nie jest związany z podatnością występującą bezpośrednio w serwisie jakiegokolwiek banku.

Korzystam z Przelewy24, co robić?

W celu zachowania bezpieczeństwa nigdy nie powinno się wprowadzać swoich danych logowania w przeglądarce osadzonej wewnątrz zewnętrznej aplikacji, nawet jeżeli wykorzystuje ona oficjalną bibliotekę Przelewy24. Zatwierdzanie płatności przez smartfona jest bezpieczne wyłącznie w przypadku, kiedy korzystamy z oficjalnej aplikacji banku, albo przeprowadzamy cały proces płatności poprzez klasyczną przeglądarkę.

Każdorazowo warto sprawdzać również nazwę aplikacji, do której należy aktywne okno, poprzez wciśnięcie przycisku otwierającego widok “ostatnie aplikacje”: kwadrat na Androidzie 5.0+, podwójny prostokąt na niższych wersjach. Jeżeli logujemy się w przeglądarce, należy również sprawdzić, czy adres na pasku adresu pokrywa się z faktycznym adresem naszego serwisu transakcyjnego.

Komentarz Przelewy24

W obliczu ujawnionych problemów postanowiliśmy zadać operatorowi serwisu Przelewy24 kilka pytań:

1. W ciągu minionego tygodnia ukazała się nowa wersja bibliotek mobilnych Przelewy24, jakie są różnice względem starej wersji i co było powodem aktualizacji?
2. Czy stanowisko Przelewy24 zmieniło sie od czasu odpowiedzi z dn. 30.11.2017 na zgłoszenie podatności zarejestrowane pod numerem Ticket#2017112877266118 [chodzi o zacytowaną wyżej odpowiedź Krzysztofa Szaneckiego – przyp. red.]?
3. W jaki sposob uzytkownik moze sprawdzic, czy podaje swoje dane logowania w oficjalnej bibliotece, czy w jej wiarygodnej podróbce?

Odpowiedzi udzielił Michał Bzowy, Wiceprezes zarządu firmy PayPro S.A.

Witam,

W zeszłym tygodniu pojawiała się zapowiadana nowa wersja biblioteki mobilnej. Prace nad biblioteką trwały od paru miesięcy, najważniejsze zmiany to:

– dodanie nowych funkcjonalności związanych z obsługą transakcji

– dostosowanie obsługi do najnowszej wersji formatki płatniczej

– podniesiony poziom bezpieczeństwa aplikacji od strony użytkowej i przechowywania danych

– refactor kodu biblioteki

– zgodność z najnowszymi wersjami systemów mobilnych operacyjnych

Pojęliśmy również decyzję, iż w chwili obecnej nie będą w aplikacji przechowywane kompletne dane autoryzacyjne. Mimo, iż użytkownik świadomie sam musiał wyrazić zgodę na zapisanie danych, postanowiliśmy ograniczyć zakres danych.

Biblioteka stanowi integralną część aplikacji, nie ma możliwości zweryfikowania autentyczności pojedynczej biblioteki. Proszę zwrócić uwagę, że oszust próbujący wyłudzić dane może sam napisać taką aplikację, nie potrzebuje do tego gotowej biblioteki. Użytkownik instalujący aplikację na swoim urządzeniu powinien zachowywać odpowiednio ograniczone zaufanie do nieznanych aplikacji, z niesprawdzonych źródeł. Nieodpowiedzialnie udzielenie uprawnień aplikacji od niesprawdzonego dostawcy otwiera furtkę na dowolne nadużycie.

Ciężko przyjąć tę odpowiedź – przecież w klasycznej wersji Przelewy24 dla aplikacji internetowych model bezpieczeństwa oparty jest na zaufaniu w stosunku do operatora. Sprzedawca, nawet złośliwy, nie ma technicznej możliwości wpłynięcia na dokonywany przez nas proces zapłaty za towar lub usługę. Można powiedzieć, że w tym modelu sprzedawca jest oddzielony „grubą kreską” od użytkownika i jego banku.

Umożliwienie osadzania bibliotek Przelewy24 w dowolnej aplikacji psuje przedstawiony w poprzednim akapicie model, ponieważ zaledwie jedna płatność dokonana w złośliwej zewnętrznej aplikacji może niepostrzeżenie wyczyścić konto użytkownika (patrz: Możliwe zagrożenia). Problem z modelem zaufania mógłby zostać naprawiony poprzez wydzielenie biblioteki do osobnej, samodzielnej aplikacji służącej do dokonywania płatności. Okazuje się, że w tym przypadku usability zwyciężyło nad bezpieczeństwem. Szkoda.

Lokowanie produktu

Jeśli chcecie, by autorzy aplikacji mobilnych w Waszej firmie lepiej rozumieli takie i podobne zagrożenia, to wyślijcie ich na nasze szkolenie z bezpieczeństwa aplikacji mobilnych – w marcu 2018 w Warszawie.