Aplikacje mobilne
Pod pojęciem aplikacji mobilnej rozumiem w tym przypadku aplikacje stworzone specjalnie dla urządzenia mobilnego, nie chodzi mi o specjalną wersję "zwykłej" aplikacji internetowej dostosowaną do wyświetlania i obsługi na urządzeniu przenośnym.
Podstawową rzeczą, na którą trzeba zwrócić uwagę w przypadku takiej aplikacji mobilnej jest to, że działa ona w środowisku kontrolowanym przez użytkownika, czyli potencjalnego atakującego. W rezultacie może on przeanalizować działanie aplikacji i w dowolny sposób je zmodyfikować. Nie można więc polegać na żadnych mechanizmach, w tym mechanizmach bezpieczeństwa, które są zaimplementowane w tej aplikacji.
Bezpieczeństwo API
Aplikacja komunikuje się z bankiem z wykorzystaniem udostępnionego przez bank API, często technicznie jest to realizowane poprzez udostępnione dla aplikacji usługi Web Service. Trzeba pamiętać, że funkcje udostępnionego API mogą być wywoływane przez atakującego w dowolny sposób, z dowolnymi parametrami i w dowolnej kolejności. Sposób działania aplikacji mógł zostać zmodyfikowany przez atakującego, lub może on korzystać z API bezpośrednio, z pominięciem udostępnionej aplikacji.
Często popełnianym błędem w przypadku aplikacji mobilnych jest traktowanie aplikacji jako dodatkowego w stosunku do strony WWW kanału prezentacji danych, gdzie zarówno aplikacja WWW, jak i aplikacja mobilna korzysta z tego samego API. Problem z tego typu podejściem polega na tym, że aplikacja WWW (część serwerowa) działa w środowisku kontrolowanym przez bank, dzięki czemu użytkownik (atakujący) nie może modyfikować aplikacji i może wejść z nią w interakcję w oczekiwany/założony sposób. Można również oczekiwać, że wbudowane w aplikację mechanizmy bezpieczeństwa oraz reguły logiki biznesowej będą działały zgodnie z oczekiwaniami. Pośrednio wymusi to korzystanie z API w sposób zgodny z oczekiwaniami, czyli na przykład wywoływanie funkcji API w określonej sekwencji z zachowaniem integralności stanu procesu między poszczególnymi wywołaniami.
Sytuacja zmienia się, jeśli atakujący może wywoływać w dowolny sposób funkcje API. W przypadku procesów składających się z wielu kroków otwiera to drogę do ataków polegających na pominięciu, powtórzeniu lub zmianie kolejności wykonania korków, co czasami pozwala na przykład wykonać przelew bez autoryzacji transakcji, uzyskać pożyczkę bez weryfikacji zdolności kredytowej lub zmienić parametry we wniosku (np. kwota pożyczki) już po uzyskaniu decyzji kredytowej dla wniosku o innych parametrach.
Trzeba pamiętać też, że w API mogą być dostępne parametry, którymi użytkownik nie powinien manipulować, na przykład data otwarcia lokaty czy jej oprocentowanie. W normalnym przypadku parametry te są ustawiane przez aplikację WWW i użytkownik, potencjalny atakujący, nie ma możliwości ich modyfikacji. Jeśli jednak te istotne parametry są ustawiane na poziomie aplikacji mobilnej, mogą zostać zmodyfikowane przez atakującego.
To nie są teoretyczne rozważania, z tego typu błędami wynikającymi z użycia udostępnionego dla aplikacji API w sposób niezgodny z oczekiwaniami/specyfikacją spotkałem się wielokrotnie w testowanych aplikacjach, nie tylko w aplikacjach bankowych.
Lokalnie przechowywane dane
Kolejną interesującą i potencjalnie niebezpieczną cechą aplikacji mobilnych jest przechowywanie danych na urządzeniu. Wszystko po to, by zmniejszyć ilość wymienianych z serwerem danych i zwiększyć komfort użytkownika w trakcie korzystania z aplikacji. Problem polega na tym, że wśród danych przechowywanych na urządzeniu mogą znaleźć się dane objęte tajemnicą bankową, a samo urządzenie może zostać utracone przez użytkownika (zgubione lub skradzione). Czy nowy "właściciel" urządzenia może uzyskać dostęp do danych aplikacji?
Przy odpowiedzi na to pytanie można uwzględnić dwa obszary. Po pierwsze bezpieczeństwo samego urządzenia i jego systemu operacyjnego, a po drugie bezpieczeństwo samej aplikacji. Teoretycznie urządzenie mobilne może być skonfigurowane w taki sposób, ze dostęp do danych użytkownika na nim przechowywanych nie będzie możliwy. Niestety, zwykli użytkownicy nie posiadają swoich działów IT i działów bezpieczeństwa, w związku z tym takie zabezpieczenia, nawet jeśli są dostępne, nie są wykorzystane. W praktyce możliwe jest więc odzyskanie danych aplikacji przechowywanych na urządzeniu, jeśli trafi ono w ręce wystarczająco zmotywowanego atakującego. Czy w takim przypadku dane aplikacji bankowej pozostaną bezpieczne?
Podstawowym sposobem ochrony danych jest ich szyfrowanie. Początkowo w przypadku aplikacji mobilnych dane były przechowywane w postaci jawnej, z czasem szyfrowanie danych stało się powszechne, ale zaszyfrowane dane są tylko tak bezpieczne, jak klucz użyty do ich zaszyfrowania. Przy badaniu aplikacji często okazuje się, że klucz szyfrowania jest zapisany wprost na urządzeniu lub jest generowany na podstawie cech urządzenia (np. numer IMEI, numer seryjny, adres MAC, itp), które to informacje są dostępne dla atakującego - ma przecież bezpośredni fizyczny dostęp do urządzenia. Również generowanie klucza szyfrowania w oparciu o hasło/PIN wprowadzany przez użytkownika nie jest rozwiązaniem wystarczającym. W przypadku urządzenia mobilnego sposób wprowadzania danych jest na tyle niewygodny, że przestrzeń potencjalnych haseł do przeszukania jest niewielka, w związku z czym odzyskanie klucza szyfrowania z użyciem metody brute force jest zadaniem trwającym zwykle co najwyżej kilka minut.
W praktyce bardzo trudno jest skutecznie zabezpieczyć dane przechowywane na urządzeniu mobilnym, w związku z czym najlepiej z przechowywania takich danych jest po prostu zrezygnować. Ewentualnie decyzja o tym, czy określone dane mogą być przechowywane na urządzeniu czy też powinny być pobierane każdorazowo z serwera może być podejmowana na podstawie typu informacji. Można również zastosować rozwiązanie, w którym dane są przechowywane na urządzeniu tylko wówczas, gdy użytkownik aktywnie korzysta z aplikacji. Po zamknięciu aplikacji lub upłynięciu określonego czasu od ostatniej akcji użytkownika przechowywane dane są usuwane.
Dane uwierzytelniające
Po co atakujący ma odzyskiwać dane zapisane na urządzeniu, jeśli po prostu może uruchomić aplikację i uwierzytelnić się w systemie. Będzie w stanie to zrobić, jeśli uzyska dostęp do danych uwierzytelniających. Teoretycznie nawet prosty środek zabezpieczający w postaci kodu PIN może być wystarczającym zabezpieczeniem, pod warunkiem, że atakujący dysponuje jedynie ograniczoną ilością prób jego odgadnięcia. Niestety, w aplikacjach mobilnych często wykorzystane są schematy uwierzytelnienia, które umożliwiają łamanie danych uwierzytelniających bez kontaktu z serwerem, co w praktyce daje atakującemu nieograniczoną ilość prób.
Skrajnym przypadkiem była aplikacja, w której sekret używany do uwierzytelnienia był zaszyfrowany kluczem generowanym na podstawie czterocyfrowego kodu PIN użytkownika, a oprócz tego na urządzeniu był przechowywany hash tego kodu w celu uwierzytelnienia użytkownika do funkcji aplikacji dostępnych bez połączenia z serwerem banku. Zadanie odzyskania danych uwierzytelniających sprowadzało się do sprawdzenia 10 000 możliwych kodów PIN, wyliczenia dla nich hasha i porównaniu z wartością przechowywaną w urządzeniu. Później wystarczyło podać ustalony w ten sposób kod PIN przy starcie aplikacji by uzyskać dostęp do konta bankowego w kontekście właściciela urządzenia...
Nawet najlepiej zaprojektowany mechanizm uwierzytelnienia może okazać się nieskuteczny, jeśli programiści aplikacji mobilnej postanowią logować za dużo, tak na wszelki wypadek. Okazuje się, że sytuacja, w której do logów trafiają istotne dane lub nawet cała komunikacja aplikacji z serwerem, wcale nie należy do rzadkości. Na podstawie danych zapisywanych w logach urządzenia w trakcie testów aplikacji udawało się nawet pokonać mechanizmy oparte na kodach jednorazowych generowanych przez aplikację tokenu. W praktyce możliwe było sklonowanie tokenu, dzięki czemu atakujący był w stanie nie tylko uzyskać kod potrzebny do uwierzytelnienia w aplikacji, ale również do autoryzowania dowolnej operacji.
Autoryzacja transakcji
Autoryzacja transakcji jest jednym z podstawowych mechanizmów bezpieczeństwa w aplikacjach bankowości internetowej. Dzięki temu osoba wykonująca operację ma szansę potwierdzenia nie tylko samej chęci wykonania operacji, ale również jej istotnych parametrów. Oczywiście jest to możliwe, o ile pozwala na to wykorzystywana metoda autoryzacji.
Często autoryzacja transakcji jest realizowana z wykorzystaniem oddzielnego, potencjalnie niekontrolowanego przez atakującego kanału komunikacji. Przykładem takiego podejścia wykorzystanie wiadomości SMS, w której poza kodem autoryzacyjnym przekazane są parametry transakcji albo tokenu, do którego należy przepisać pewne informacje o transakcji.
W przypadku aplikacji mobilnej często okazuje się, że przejęcie kontroli nad urządzeniem, na którym aplikacja jest zainstalowana, daje atakującemu również możliwość autoryzacji operacji. Jeśli na przykład wykorzystywana jest metoda autoryzacji transakcji z wykorzystaniem kodów SMS, atakujący otrzyma kod na urządzenie, które kontroluje. Przeniesienie metody autoryzacji transakcji wprost z rozwiązań tradycyjnych może skutkować tym, że w praktyce takie rozwiązanie nie daje żadnej wartości dodanej, nie podnosi poziomu bezpieczeństwa systemu.
Malware
Możemy zaakceptować fakt, że atakujący mający bezpośredni fizyczny dostęp do urządzenia mobilnego (np. telefonu) może zrobić wszystko. Jesteśmy skłonni podjąć to ryzyko dlatego, że wydaje nam się iż prawdopodobieństwo takiego zdarzenia jest niskie. Trudno przypuszczać, by ktoś kradł telefony tylko po to, by uzyskiwać dostęp do kont bankowych ich właścicieli. Oczywiście takie sytuacje mogą się zdarzyć, jeśli potencjalna ofiara rokuje szanse na duży zysk, trudno jednak w takim scenariuszu dopatrywać się potencjału na ataki masowe.
Sytuacja zmienia się, jeśli uwzględnimy malware (wrogie oprogramowanie). Telefon to nie jest bezpieczne urządzenie, to zwykły komputer, choć pracujący pod kontrolą nieco innego systemu operacyjnego i w nieco innym modelu bezpieczeństwa. Technicznie jest możliwe stworzenie programu, który eskaluje swoje uprawnienia w ramach urządzenia (przez wykorzystanie podatności w systemie), uzyska dostęp do danych innych aplikacji, będzie w stanie monitorować działania użytkownika, modyfikować sposób działania wykorzystywanych przez niego aplikacji. Dokładnie tak samo, jak ma to miejsce w przypadku malware na "zwykłe" komputery.
Czy aplikacje mobilne, z których korzystamy, zapewniają akceptowalny poziom bezpieczeństwa przy takim modelu zagrożeń? Jeśli nie, może warto zastanowić się nad wprowadzeniem odpowiednich mechanizmów bezpieczeństwa już teraz, zanim atakujący stwierdzą, że już opłaca się stworzyć kod atakujący aplikacje mobilne.
Może okazać się, że dalsze podnoszenie bezpieczeństwa aplikacji mobilnych nie będzie możliwe z uwagi na rozdźwięk między wymaganiami bezpieczeństwa i oczekiwaniami użytkowników odnośnie sposobu działania i wygody użytkowania aplikacji. Dlatego coraz bardziej istotne stają się dodatkowe mechanizmy bezpieczeństwa, na przykład systemy analizujące anomalie, które są w stanie zablokować lub chwilowo wstrzymać podejrzaną transakcję.
NFC, elektroniczny portfel
Technologie zbliżeniowe zyskują na popularności, popularne również staje się wykorzystanie telefonów z NFC do płatności zbliżeniowych. Warto jednak pamiętać, że ta sama technologia może być wykorzystana do instalacji malware na telefonach wytypowanych ofiar.
NFC, malware, atak targetowany
Na konferencji BlackHat w tym roku zademonstrowane zostały ataki, w których z wykorzystaniem NFC atakujący mógł uzyskać nieograniczony dostęp do telefonu ofiary. Wystarczyło, by atakujący zbliżył się wystarczająco do wybranej ofiary.
Jak działał atak? NFC może być wykorzystany nie tylko do dokonania płatności, ale również wywołania określonej aplikacji na drugim telefonie. W ten sposób można na przykład wymieniać się wizytówkami czy przekazywać sobie adresy interesujących stron w sieci. W wielu przypadkach telefon otrzymując transmisję NFC podejmie akcję bez interakcji z użytkownikiem. Problem pojawia się wtedy, gdy atakujący jest w ten sposób w stanie wywołać podatną aplikację i wykorzystać tę podatność. Oczywiście podatna jest aplikacja a nie samo NFC, jednak jest to nowy wektor ataku, który można wykorzystać do zainfekowania telefonu konkretnej, wybranej ofiary. Jest to bardzo przydatna możliwość, jeśli chcemy okraść konkretnego klienta banku, o którym wiemy, że ma wystarczająco dużo pieniędzy, by cała akcja się opłacała.
Elektroniczny portfel
Jednym z rozwiązań umożliwiających płatności zbliżeniowe przy pomocy telefonu komórkowego jest Google Wallet. Aplikacja chroniona jest kodem PIN, który musi zostać podany przy uruchomieniu aplikacji. Teoretycznie taki sposób płatności powinien być bezpieczniejszy niż zwykłe karty zbliżeniowe gdzie kod PIN nie jest wymagany. Niestety, w pierwszych wersjach aplikacji PIN składowany był na urządzeniu w sposób, który pozwalał na łatwe jego odzyskanie. W rezultacie szczęśliwy znalazca telefonu mógł ustalić PIN do portfela i wykonać płatność. W nowszych wersjach aplikacji wykorzystywane jest rozwiązanie sprzętowe, które ogranicza ilość dostępnych prób w podobny sposób, jak robi to chip na karcie.
Jeśli nawet tak duża firma jak Google, autor systemu Android tworzy aplikację dla tego systemu i popełnia tak oczywiste błędy, jaką mamy gwarancję, że rozwiązania oferowane przez innych dostawców takich błędów nie zawierają?
Warto tu również wspomnieć o przykładowej aplikacji, która umożliwiała płatności zbliżeniowe z telefonu ofiary bez fizycznego dostępu do urządzenia. Atakujący instalował na telefonie ofiary aplikację, która działała jako proxy między interfejsem NFC na telefonie ofiary, a interfejsem NFC w urządzeniu atakującego. W rezultacie atakujący mógł zapłacić za zakupy kartą ofiary, która znajdowała się w praktycznie dowolnym miejscu na świecie (patrz: NFCProxy i demonstracja: NFCProxy Demo).
Wirtualny Bank, Wirtualny Oddział
Klienci oczekują, że zostaną obsłużeni szybko i sprawnie, najchętniej bez konieczności udawania się do oddziału banku. Banki starają się spełnić oczekiwania klientów, między innymi dlatego, że wirtualna obsługa klientów może być w przeliczeniu tańsza, niż utrzymywanie tradycyjnych oddziałów.
Zmiana sposobu obsługi klienta wymusza również zmianę części procedur. Dotyczy to na przykład zmiany sposobu weryfikacji tożsamości klienta. Klient nie musi przychodzić do oddziału by podpisać umowę, nie musi również oczekiwać na kuriera, który dostarczy do niego umowę do podpisania i zweryfikuje jego tożsamość. Klient, który chce założyć konto w banku może potwierdzić swoją tożsamość i swoje dane osobowe poprzez przelew pochodzący z innego banku, w którym już ma konto. Gdzie tu problem?
Okazuje się, że bardzo szybko pojawiły się ataki, w których atakujący skłaniał ofiarę do przelania drobnej sumy pieniędzy na wskazany przez atakującego numer konto. Przelew ten był potwierdzeniem operacji zakładania konta wykonanej w imieniu ofiary przez atakującego. Co dalej atakujący robili z założonym w ten sposób kontem zależało tylko od ich inwencji. Ważne, że wszystkie ich działania szły na konto ofiary, która o całej sprawie mogła się dowiedzieć dopiero wtedy, gdy u drzwi pojawił się komornik w związku z niespłacanymi ratami pożyczek.
Wspomniane ataki nie były oczywiście atakami technicznymi. Do ich realizacji konieczne było przekonanie ofiary do podania oczekiwanych przez atakującego danych i wykonania pożądanych akcji. Socjotechnika jednak jest potężnym narzędziem i znalazły się osoby, które jej uległy. Przykłady:
Do ograniczenia tego problemu wystarczy drobna modyfikacja wymagań odnośnie danych opisowych przelewu, który potwierdza tożsamość klienta w taki sposób, by nie miał on wątpliwości czego ten przelew dotyczy. Ciągle jednak pozostaje problem w przypadku, gdy atakujący uzyska dostęp do konta ofiary w systemie, który w sposób heurystyczny podejmuje decyzję, czy dana transakcja ma być autoryzowana. Do potwierdzenia tożsamości w procesie zakładania konta wystarczy drobna kwota, a taki przelew może nie wymagać autoryzacji. Oczywiście można w procesie decyzyjnym uwzględnić opis przelewu i wymagać autoryzacji w przypadku, gdy opis wskazuje na taki typ przelewu. Problem w tym, że jak na razie dane opisowe przelewu potwierdzającego tożsamość nie są ujednolicone.
Innym istotnym procesem jest weryfikacja zdolności kredytowej przed udzieleniem kredytu lub pożyczki. Jeśli klient aktywnie korzysta z rachunku w banku, w którym chce uzyskać pożyczkę, można wykonać analizę tego rachunku i określić zdolność kredytową wnioskodawcy. Co w przypadki, gdy główne konto klienta znajduje się w innym banku?
W części systemów pojawiają się rozwiązania, w których klient podaje swoje dane uwierzytelniające do banku, w którym ma rachunek, a bank, w którym klient składa wniosek, automatycznie analizuje historię rachunku. Problem w tym, że takie procedury stoją w sprzeczności z zasadą, która mówi, by nie podawać danych uwierzytelniających stronom trzecim. W efekcie zmianie mogą ulegnąć przyzwyczajenia użytkowników, a w rezultacie ataki socjotechniczne polegające na wyłudzeniu haseł mogą stać się łatwiejsze. Dodatkowo trzeba pamiętać, że bank decydujący się na takie rozwiązanie musi przetwarzać przekazane przez użytkowników hasła w taki sposób, by zminimalizować prawdopodobieństwo ich wycieku.
Zarządzanie budżetem - PFM
Kolejnym nowym rozwiązaniem, które pojawia się w systemach bankowych są narzędzia służące do wspomagania zarządzania budżetem. Część z nich pozwala integrować informacje finansowe z innych banków, w związku z czym pojawia się pytanie w jaki sposób te dane są importowane. Czy proces importu odbywa się lokalnie przez jakiś komponent po stronie klienta, czy jest realizowany po stronie serwera? Co dzieje się z hasłem wpisanym przez użytkownika? Czy aby na pewno dane pobierane z innych banków wykorzystywane są tylko po to, by prezentować użytkownikowi jego budżet, czy może dodatkowo są wykorzystywane do tego, by zaproponować klientowi lepszą ofertę?
Innym ciekawym obszarem mogą być wszelkiego rodzaju funkcje pozwalające na porównanie swojego profilu z innymi klientami banku. W założeniu porównanie odbywa się w odniesieniu do pewnej grupy o określonych parametrach. Problem może pojawić się jednak wówczas, gdy użytkownik uzyska większą swobodę określenia grupy klientów, z którymi ma się porównać. W skrajnych przypadkach może pozwolić to na stworzenie dość dokładnego profilu konkretnego klienta banku.
Serwisy społecznościowe
W wielu aplikacjach bankowych wykorzystywane są funkcje społecznościowe lub inne funkcje oferowane przez zewnętrznych dostawców, choćby związane z danymi geograficznymi lub analizą odwiedzin użytkowników w serwisie. Trzeba pamiętać, że korzystanie z takich funkcji oznacza w praktyce dołączenie do swojej aplikacji zewnętrznego kodu, który może zmienić się w dowolnym momencie funkcjonowania aplikacji. W efekcie atakujący przejmując kontrolę nad systemem, z usług którego korzystamy, mogą również skutecznie atakować naszą aplikację.
Trzeba zwrócić również uwagę na wyciek informacji następujący w wyniku samego dołączenia zewnętrznych gadżetów do naszej aplikacji. Operatorzy usług zewnętrznych mogą uzyskać dodatkowe informacje odnośnie tego z jakich banków, jakich usług, jak często i w jakich placówkach klient korzysta. Można postrzegać to jako zagrożenie dla prywatności, choć z drugiej strony sami klienci z prywatności rezygnują umieszczając na swoich profilach w serwisach społecznościowych wszelkiego rodzaju informacje.
Część banków już dostrzegła potencjał serwisów społecznościowych, nie tylko jako miejsca do prowadzenia działań marketingowych, ale również do wykonywania drobnych operacji finansowych w gronie znajomych, bez konieczności logowania się w tym celu do banku. Problem polega na tym, że użytkownicy do serwisów społecznościowych zalogowani są prawie przez cały czas, a przejęcie sesji czy konta w takim serwisie jest zdecydowanie łatwiejsze, niż przejęcie konta w banku. Atakujący po przejęciu konta ofiary będzie mógł wykonywać te same operacje finansowe co ofiara, a więc w praktyce będzie mógł on wyprowadzić pieniądze z konta ofiary. Nie musi to być jednak istotnym problemem, jeśli na operacje wykonywane w ten sposób zostaną nałożone sensowne limity dotyczące dopuszczalnych kwot i ilości transakcji.
Na koniec
Postępu nie da się zatrzymać, trzeba założyć, że z nowych technologii i nowych rozwiązań będziemy korzystać. Z drugiej strony trzeba pamiętać, że nowe rozwiązania mogą wiązać się z nowymi ryzykami, lub mogą zmienić ekspozycję na ryzyka już znane. Przede wszystkim trzeba uświadomić sobie, że zawsze będzie istniała grupa ludzi, która nie będzie chciała postępować zgodnie z przyjętymi zasadami, która udostępnione funkcje będzie chciała wykorzystać dla swojej korzyści. Przy projektowaniu nowych rozwiązań i usług trzeba uwzględnić nie tylko zwykłego klienta postępującego zgodnie z zasadami, ale również zastanowić się jak projektowany proces czy usługa może zostać nadużyte.
Bezpieczeństwo trzeba uwzględnić w procesie wdrażania nowych technologii i nowych produktów. Im wcześniej w procesie projektowania, tworzenia i wdrażania nowych rozwiązań zostaną one poddane ocenie pod kątem bezpieczeństwa, tym wcześniej będzie można zidentyfikować potencjalnie niebezpieczne miejsca i wprowadzić niezbędne modyfikacje stosunkowo niewielkim kosztem. Jeśli te same słabości zostaną zidentyfikowane po wdrożeniu i uruchomieniu produkcyjnym rozwiązania, koszt i stopień skomplikowania działań naprawczych będzie zdecydowanie wyższy.
Czy dobrym rozwiązaniem zadbania o bezpieczeństwo danych jest program McAfee? Ponoć McAfee jest liderem na rynku http://starlit.pl/ochrona-danych-mcafee-liderem-rynku/