12.12.2017 | 20:38

Michał Leszczyński

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.

Bezpieczeństwo aplikacji mobilnych - atak i obrona

Warsaw-center-free-license-CC0
Warszawa, 26 – 27 marca 2018

Czas trwania: 2 dni (15h), Prowadzący: Adam z z3s, Mateusz Kocielski
Liczba uczestników: maksymalnie 12 osób, cena: 2600 PLN netto

Szczegółowy opis szkolenia
Powrót

Komentarze

  • 2017.12.12 22:00 das

    Niestety zwykle bezpieczeństwo nie ma znaczenia liczy się wyłącznie łatwość obsługi.

    Odpowiedz
    • 2017.12.31 02:01 roobal

      Tu raczej nie chodzi o wygodę użytkownika/klienta, a raczej o wygodę programisty ;)

      Sam miałem ostatnio przypadek, gdzie devsi nie ograniają takich rzeczy jak uwierzytelnianie użytkownika i proszą o jawny dostęp do zasobu z danymi osbowymi.

      Odpowiedz
  • 2017.12.12 22:39 q

    Ja unikam wszelkiego rodzaju aplikacji bankowych i używam strony banku w zaufanej przeglądarce. Denerwują mnie nachalne próby wciśnięcia jakiegokolwiek pseudoproduktu który nic nie wnosi.

    A co do biblioteki Przelewy24 to chyba faktycznie było by lepiej gdyby wywoływała przeglądarkę albo osobny widok aplikacji. W androidzie można przecież przekazywać dowolne parametry podczas wywoływania aplikacji i odczytywać informację zwrotną.

    PS ta wiadomość została wysłana z WebView osadzonego w aplikacji Twittera

    Odpowiedz
  • 2017.12.13 00:02 Przemek

    To jeszcze sprawdzcie jaką oferują możliwość osadzenia na stronie płatności kartą.
    Mianowicie przez api otrzymuje się js który odpalasz na stronie – a on generuje diva z inputami na podanie danych karty – wszystko na stronie klienta.
    Czyli każdy zkrypt osadzony na stronie klienta (łącznie z jego skryptami) może sobie zaposać co tam użytkownik wpisze. I jeszcze do tego chwalą się wypełnianiem standardów dss

    Odpowiedz
    • 2017.12.13 10:59 Jacek

      PCI DSS zmusza dostawców do oferowania bezpiecznej metody płatności, i dostawca daje sprzedawcy taką możliwość.
      Ale dostawcy nie są w stanie wymusić na sklepach to żeby płatność była realizowana w sposób 100% bezpieczny, jak komuś shackują sklep to zrobi przekierowanie na stronę phisingową (albo podmieni JS w formularzu) i dostawca nie ma nic do tego.

      Odpowiedz
      • 2017.12.13 12:56 Przemek

        Ależ są – własnie poprzez przekierowanie na stronę dostawcy a nie wpisywanie danych na różnych „stronkach”.

        Odpowiedz
    • 2017.12.22 10:56 I Mnię

      Na tej samej zasadzie – PCI DSS wymaga, żeby SAD (CVV itp.) nie były przechowywane. I co z tego? Tona różnych usługodawców zapamiętuje twój CVV/CVV2, przy czym często nie jest to nawet opcjonalne, tylko żeby w ogóle skorzystać z usługi musisz kliknąć na „rozumiem, że będziecie przechowywać mój CVV i będziecie sobie ciągnąć z mojej karty kiedy będziecie chcieli” (np. Spotify z takich bardziej znanych). Teoretycznie jest to wbrew PCI DSS, ale co im zrobisz?

      Odpowiedz
  • 2017.12.13 01:07 pm7

    Cóż, kolejne powody, żeby płacić kartą, której możemy zdefiniować limity i znacznie łatwiej jest odzyskać pieniądze w razie kradzieży.

    Choć w tym tempie to będzie niedługo potrzebny drugi telefon na kody autoryzujące z banku…

    Odpowiedz
  • 2017.12.13 07:27 J23

    Nie rozumiem tych argumentów o aplikacjach z nie zaufanych zrodel. On jest raczej chybiony.
    Mogę napisać aplikacje korzystająca z biblioteki P24 i umieścić w google store a po roku podmienić bibliotekę ( opcja 2 wstrzyknąć kod js jak w artykule) na własną która będzie wykradać dane logowania i wysyłać na serwer aplikacji wraz z danymi aplikacji.
    Użytkownik nie jest w stanie zorientować się że coś takiego miało miejsce.
    Weryfikacja aplikacji w store tezpowinna przejść.

    Odpowiedz
    • 2017.12.13 11:31 Michał Leszczyński

      Dokładnie. Niekiedy nie wymaga to nawet aktualizowania aplikacji – pewne klasy mogą być ładowane dynamicznie, albo oddelegowane do silnika skryptowego JS. W efekcie ta sama wersja może nagle stać się „złośliwa”.

      Swoją drogą, podobny problem uniemożliwia audytowanie biblioteki Przelewy24. Cała konfiguracja jest pobierana z ich serwera ad hoc i mogą zmienić ją w każdym momencie bez wymuszania aktualizacji na twórcach zewnętrznych aplikacji.

      Odpowiedz
  • 2017.12.13 08:06 sebus

    A co to może być:
    https://hyvtza-s21d45i9i0f0s20i7f1_21314151617181.hitclick.net/1131926498409990/conversions-1625316339_3730087_1513148552.js ?
    Dostaje to w AdBlocku na liście elementów strony, podczas logowania do banku pekao24.pl ?

    Odpowiedz
    • 2017.12.13 11:23 Michał Leszczyński

      Prawdopodobnie jest to jakiś skrypt do śledzenia konwersji, czyli prowadzenia statystyk na temat tego, które transakcje doszły do skutku, a które nie.

      Odpowiedz
  • 2017.12.13 08:24 IvanBarazniew

    Dlatego do płatności we wszelkiej maści aplikacjach i na dziwnych stronach polecam blika. Wpisujemy tylko wygenerowany kod, czyli dane, które nie są wrażliwe ze względu na swój tymczasowy charakter, potwierdzenia płatności dokonujemy w aplikacji a nie za pomocą SMS, który może być odczytany.

    Oczywiście jak ktoś ma malware na telefonie to i tak będzie miał problem ale zagrożenie jest dużo mniejsze niż w przypadku podawania loginu i hasła do banku.

    Odpowiedz
  • 2017.12.13 08:24 Filon

    Całe to case study dotyczy webview na androidzie, jak wygląda ta kwestia w kontrolce webkita na iOS? Czy iOS również pozwala na wstrzykiwanie kodu do osadzonej przeglądarki i dwukierunkową komunikację między aplikacją a stroną?

    Sam korzystam z P24 chyba tylko w jednej aplikacji – mobilet, ale zawsze płacę blikiem, więc worst case scenario jest taki, że rąbną mi 10 zł i nie będę mógł kupić biletu. Inna sprawa, że kontrolka jest tak topornie osadzona, że po kupieniu biletu trzeba ubić apkę i otworzyć ponownie.

    Odpowiedz
    • 2017.12.13 17:00 Michał Leszczyński

      Funkcja zapisywania danych logowania do banku była dostępna na wszystkich trzech platformach (Android, iOS, Windows Phone). Rozwiązania techniczne na pozostałych platformach mogły się nieznacznie różnić.

      Odpowiedz
  • 2017.12.13 08:32 Jaro

    Koleś zaczyna maila od „Witam” -.-

    Odpowiedz
    • 2017.12.13 13:21 Anon

      Witam,
      Masz z tym problem?

      Odpowiedz
      • 2017.12.13 17:00 Sebastian

        Witam w mailach i korespondencji jest nieładne, tak na szybko. Było o tym ostatnio.

        Odpowiedz
    • 2017.12.13 16:05 witam

      Witam,

      i co?

      Pozdrawiam.

      Odpowiedz
  • 2017.12.13 09:40 adam

    zdaje się, że apka na andka z T-mobile, „mój T-mobile” działa na tej samej zasadzie. przy logowaniu podajesz nr tel. , dostajesz jednorazowy kod w sms, który jest automatycznie zasysany z wiadomości, zamaskowany.

    Odpowiedz
    • 2017.12.13 16:00 Lemon

      To akurat inny przypadek. T-Mobile wysyła do Ciebie SMSa serwisowego, który MA być niewidoczny dla użytkownika i przechwycany przez aplikację, poprzez ustawienie mu odpowiedniej klasy. Biblioteka Przelewy24 przechwytuje treść najzwyklejszych SMSów userskich wysyłanych przez bank.

      Odpowiedz
  • 2017.12.13 10:08 Kaczus

    Niestety ostatnio któryś pośrednik, w jednym ze sklepów też upierał się, że zapisze sobie dane karty, która płaciłem. Całe szczęście była to karta podarunkowa, której ważność się akurat kończyła. Ale takie rzeczy powinny być prawnie zabronione. A przynajmniej zmuszanie do tego, by zapamiętywało takie rzeczy. Pośrednik jedynie ma autoryzować i nic więcej…

    Odpowiedz
  • 2017.12.13 13:01 Marek

    Czy w tym przypadku nagłówki csp z wyłączeniem możliwości wykonywania skryptów inline wysyłane przez system transakcyjny banku mogły by uratować użytkownika przed taka doklejką kodu?

    Odpowiedz
    • 2017.12.13 16:40 Michał Leszczyński

      Jeżeli osadzona przeglądarka prawidłowo implementuje CSP to faktycznie powinno dojść do zablokowania skryptów. Nie jestem jednak pewien, czy nie dałoby się tego obejść np. stosując metodę WebView.evaluateJavascript – one może nie podlegać pod CSP, bo to ficzer analogiczny do konsoli developerskiej. Trzeba by przetestować w praktyce.

      Odpowiedz
  • 2017.12.13 17:38 Holden

    a ile hajsu autor otrzymał za pentest i czy nie bał się prawników?

    Odpowiedz
  • 2017.12.13 18:02 tom

    Może ktoś napisze jak skasować to zapamiętane hasło? Robiłem przelew do skycash i przez przypadek wybrałem „zapamiętaj hasło” (mbank) jak to sprawdzić i skasować? Android.

    Odpowiedz
    • 2017.12.13 18:25 Michał Leszczyński

      Usunięcie danych aplikacji powinno rozwiązać problem. Inna opcja to zainicjowanie kolejnej płatności i na etapie wyboru banku kliknięcie w przycisk [Options] w prawym górnym rogu (na belce „Przelewy24”). Tam powinna być lista zapamiętanych danych wraz z możliwością ich wykasowania.

      Odpowiedz
  • 2017.12.14 20:03 krc

    To samo robi SkyCash przy doładowaniu konta

    Odpowiedz
  • 2017.12.17 12:49 gosc

    ” Problem z modelem zaufania mógłby zostać naprawiony poprzez wydzielenie biblioteki do osobnej, samodzielnej aplikacji służącej do dokonywania płatności. ”
    1. Istnieje ryzyko dziury w kernelu.
    2. Wspomniany sandbox tez może mieć dziury, choć to kwestia też celowej ich polityki, żeby nie blokować wszystkiego.
    Przykład, nie może uruchomić aplikacji, ale może uruchomić kod, jeśli aplikacja już działa w tle, np. przeglądarki.
    3. Keylogery i Screenlogery to najlepszy przykład że aplikacji wcale nie trzeba hakować by mieć do niej dostęp. Chodzi mi oto że płacąc ze smartfona, a nie kartą , czy z komputera pozbawiamy się drugiego zabezpieczenia jakim był telefon. Zakładając że włamać na drugi telefon jest trudniej niż uzyskanie kodów z tego samego przejętego już sprzętu.
    4. Wirtualizacja osobnego sprzętu też nie da 100% pewności, bo nie ma takiego języka programowania, kod programu który każdy by mógł zweryfikować czy jest bezpieczny.

    Odpowiedz
    • 2017.12.17 17:55 Michał Leszczyński

      Na większość czynników wymienionych powyżej dostawca aplikacji nie ma wpływu. Bezpieczeństwo kernela, sandboxa itp. to odpowiedzialność producentów systemu.

      Odpowiedz
  • 2017.12.18 15:00 gość

    RADY:
    1. Nie ufać nikomu. Kontrola podstawą zaufania.
    2. Przezorny zawsze ubezpieczony.

    Odpowiedz

Zostaw odpowiedź

Jeśli chcesz zwrócić uwagę na literówkę lub inny błąd techniczny, zapraszamy do formularza kontaktowego. Reagujemy równie szybko.

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

Komentarze