Chcąc budować oraz łączyć społeczność defensywnych bezpieczników (jest w Polsce jeszcze bardzo mała i stosunkowo zamknięta - poza kilkoma konferencjami i nielicznymi wyjątkami [kiedyś ich ujawnię] raczej każdy trzyma się swojego wew. podwórka), postanowiłem rozpocząć serię artykułów dla obecnych i przyszłych "obrońców".
A wszystko to zaczyna się na portalu Sekurak - miłego czytania i proszę, zostawiajcie w komentarzach (tu, tam) czy w mailach, tematy, które chcielibyście abym poruszył - nie ma tematów tabu.
2015-05-28
2015-05-27
CONFidence 2015: Podsumowanie
White Cat Security nastawione jest na realne, efektywne podnoszenie poziomu bezpieczeństwa przez skuteczniejszą obronę mimo tego, że firma, jej pracownicy lub klienci byli, są i będą atakowani - dlatego z takiej perspektywy podsumowujemy świeżo zakończoną, X edycję CONFidence.
5 prezentacji skupionych na defensywie, ponad 20 na ofensywie (w tym jedna, która definitywnie zasługuje na wyróżnienie: "APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium przypadków" za promocję defensywnych praktyk! wielka piątka Borys!) - lepiej niż w poprzednich latach.
Prezentacja "Analiza przypadku: Carbanak - jak uniknąć powtórki." wypełniła całą salę, mimo tego, że zamykała merytoryczny blok drugiego dnia konferencji - serdecznie dziękuję! Mimo tego, że na sali nadal zdecydowana większość to przedstawiciele "red teamów", wasze zainteresowanie obroną cieszy niezmiernie, dlatego będziemy kontynuować serie prezentacji o defensywie, nie powtarzając wcześniej przedstawionego materiału (chyba, że zostaniemy o to wprost poproszeni).
Gorąco namawiamy wszystkich zainteresowanych do zrobienia "zadania domowego", które zostało przedstawione podczas prezentacji - macie w rękach wędkę, jesteście krok bliżej by skuteczniej powstrzymywać skuteczne ataki i minimalizować straty.
Slajdy zostaną udostępnione na stronie konferencji, jeśli ktoś nie może się ich doczekać, standardowo zapraszamy na kontakt {@} whitecatsec.com.
PS
Na dniach ukaże się nasz artykuł na portalu sekurak.pl - oczywiście o defensywie. Zapraszamy do komentowania, ponieważ jest to pierwsza część serii, a kolejne zagadnienia będą wybierane na bazie komentarzy. Pokazujemy defensywę od kuchni, jaka jest naprawdę, z czym się wiąże, jak podejść by się nie z(a)razić.
5 prezentacji skupionych na defensywie, ponad 20 na ofensywie (w tym jedna, która definitywnie zasługuje na wyróżnienie: "APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium przypadków" za promocję defensywnych praktyk! wielka piątka Borys!) - lepiej niż w poprzednich latach.
Prezentacja "Analiza przypadku: Carbanak - jak uniknąć powtórki." wypełniła całą salę, mimo tego, że zamykała merytoryczny blok drugiego dnia konferencji - serdecznie dziękuję! Mimo tego, że na sali nadal zdecydowana większość to przedstawiciele "red teamów", wasze zainteresowanie obroną cieszy niezmiernie, dlatego będziemy kontynuować serie prezentacji o defensywie, nie powtarzając wcześniej przedstawionego materiału (chyba, że zostaniemy o to wprost poproszeni).
Gorąco namawiamy wszystkich zainteresowanych do zrobienia "zadania domowego", które zostało przedstawione podczas prezentacji - macie w rękach wędkę, jesteście krok bliżej by skuteczniej powstrzymywać skuteczne ataki i minimalizować straty.
Slajdy zostaną udostępnione na stronie konferencji, jeśli ktoś nie może się ich doczekać, standardowo zapraszamy na kontakt {@} whitecatsec.com.
PS
Na dniach ukaże się nasz artykuł na portalu sekurak.pl - oczywiście o defensywie. Zapraszamy do komentowania, ponieważ jest to pierwsza część serii, a kolejne zagadnienia będą wybierane na bazie komentarzy. Pokazujemy defensywę od kuchni, jaka jest naprawdę, z czym się wiąże, jak podejść by się nie z(a)razić.
2015-05-22
2015-05-13
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 - "{}"])
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 - "{}"])
2015-05-11
Aktywna obrona: wywiad na temat zagrożeń
W zachodniej części Europy czy USA o aktywnej obronie jako sposobie konsumpcji wywiadu na temat zagrożeń (ang. threat intelligence) mówi się dość otwarcie, widać doświadczenie. W Polsce z sukcesami w większości chowamy się po kątach lub przejście na ten etap dojrzałości nie ma miejsca. Sam niejednokrotnie przekonałem się jak wygląda obrona organizacji, która broni się aktywnie, a jak kiedy jest pasywna. Jeśli Twoja firma/organizacja jest gotowa na ten krok lub chce zrozumieć o co w tym naprawdę chodzi, polecam następującą lekturę (wynik współpracy MWR, CERT.UK i CPNI) lub kontakt ze mną (kontakt {@} whitecatsec.com) - inspirujących chwil!
2015-05-07
Ruch Eurobanku: spektrum zagrożeń
Eurobank jako pierwszy bank w Polsce zaproponował swoim klientom rozwiązanie Trusteer Rapport - ruch ten nie pozostał niezauważony (Rzeczpospolita, Maciej Samcik, AleBank, TokFM).
Spróbujmy popatrzeć na większy kawałek obrazka.
Do najpopularniejszych wektorów ataków na klientów instytucji finansowych można zaliczyć:
1) podmiana/modyfikacja kodu HTML/JS w systemie bankowości elektronicznej lub CMS (w tym także zamieszczanie dodatkowych skryptów z innych domen)
2) przekierowanie na fałszywą stronę systemu bankowości elektronicznej (przekierowanie może się odbyć np. przez modyfikację kodu HTML jak w 1) lub np. przez modyfikację wpisów dotyczących konfiguracji DNS i wskazanie innego adresu IP bankowości elektronicznej niż jest w rzeczywistości)
3) podmiana numeru rachunku w tzw. "schowku", jeśli kopiujemy numer rachunku i chcemy go wkleić do pola "nr. rachunku" w formularzu przelewu
4) podmiana numer rachunku w pamięci procesu
Problem przejmowania urządzeń mobilnych - smartfonów, aby wykradać kody SMS do autoryzacji wymagających tego operacji na potrzeby tej analizy zaniedbujemy, gdyż ten wektor nie należy do najpopularniejszych w Polsce. Sam phishing i fałszywe strony, na których przestępcy zbierają najczęściej login, hasło oraz czasem kody autoryzacyjne również nie są umieszczone na liście.
Pytania, które warto sobie zadać będąc na miejscu Eurobanku:
1) przed którymi wektorami Trusteer Rapport uratuje klientów, którzy go zainstalują?
2) czy sytuacja, w której zaatakowany jest punkt dostępowy do sieci Internet (podmiana serwerów DNS lub zdefiniowanie adresów IP dla konkretnych nazw) to rozwiązanie nadal będzie skuteczne?
3) co z urządzeniami mobilnym, na których korzystamy z systemów bankowości elektronicznej w wersji klasycznej, light (tzw. "lekkiej"/mobilnej) lub natywnej?
4) co z korzystaniem z bankowości elektronicznej poza komputerem, na którym klient zainstalował Trusteer Rapport?
Pytań należy zadać jeszcze wiele i wierzymy, że zostało to w Eurobanku zrobione lub temat jest w trakcie analizy. Ruch Eurobanku na pewno coś zmieni w sektorze finansowym w Polsce - czas pokaże co. Życzymy jak najlepiej!
AKTUALIZACJA (08.05.2015)
Skontaktował się z nami Eurobank (brawa za chęć dialogu!), poniżej oryginalna treść odpowiedzi na pytania, które pojawiły się na naszym blogu:
3) co z urządzeniami mobilnym, na których korzystamy z systemów bankowości elektronicznej w wersji klasycznej, light (tzw. "lekkiej"/mobilnej) lub natywnej?
4) co z korzystaniem z bankowości elektronicznej poza komputerem, na którym klient zainstalował Trusteer Rapport?
PS
Na zamówienie dokonujemy ewaluacji rozwiązań bezpieczeństwa, strategii/taktyk czy działań operacyjnych w zakresie wykrywania i obsługi incydentów bezpieczeństwa (także dotyczących ataków na klientów sektora finansowego) - na pewno pomożemy odpowiedzieć na wcześniej wymienione pytania i znacznie więcej. (kontakt {@} whitecatsec.com)
Spróbujmy popatrzeć na większy kawałek obrazka.
Do najpopularniejszych wektorów ataków na klientów instytucji finansowych można zaliczyć:
1) podmiana/modyfikacja kodu HTML/JS w systemie bankowości elektronicznej lub CMS (w tym także zamieszczanie dodatkowych skryptów z innych domen)
2) przekierowanie na fałszywą stronę systemu bankowości elektronicznej (przekierowanie może się odbyć np. przez modyfikację kodu HTML jak w 1) lub np. przez modyfikację wpisów dotyczących konfiguracji DNS i wskazanie innego adresu IP bankowości elektronicznej niż jest w rzeczywistości)
3) podmiana numeru rachunku w tzw. "schowku", jeśli kopiujemy numer rachunku i chcemy go wkleić do pola "nr. rachunku" w formularzu przelewu
4) podmiana numer rachunku w pamięci procesu
Problem przejmowania urządzeń mobilnych - smartfonów, aby wykradać kody SMS do autoryzacji wymagających tego operacji na potrzeby tej analizy zaniedbujemy, gdyż ten wektor nie należy do najpopularniejszych w Polsce. Sam phishing i fałszywe strony, na których przestępcy zbierają najczęściej login, hasło oraz czasem kody autoryzacyjne również nie są umieszczone na liście.
Pytania, które warto sobie zadać będąc na miejscu Eurobanku:
1) przed którymi wektorami Trusteer Rapport uratuje klientów, którzy go zainstalują?
2) czy sytuacja, w której zaatakowany jest punkt dostępowy do sieci Internet (podmiana serwerów DNS lub zdefiniowanie adresów IP dla konkretnych nazw) to rozwiązanie nadal będzie skuteczne?
3) co z urządzeniami mobilnym, na których korzystamy z systemów bankowości elektronicznej w wersji klasycznej, light (tzw. "lekkiej"/mobilnej) lub natywnej?
4) co z korzystaniem z bankowości elektronicznej poza komputerem, na którym klient zainstalował Trusteer Rapport?
Pytań należy zadać jeszcze wiele i wierzymy, że zostało to w Eurobanku zrobione lub temat jest w trakcie analizy. Ruch Eurobanku na pewno coś zmieni w sektorze finansowym w Polsce - czas pokaże co. Życzymy jak najlepiej!
AKTUALIZACJA (08.05.2015)
Skontaktował się z nami Eurobank (brawa za chęć dialogu!), poniżej oryginalna treść odpowiedzi na pytania, które pojawiły się na naszym blogu:
1) przed którymi wektorami Trusteer Rapport uratuje klientów, którzy go zainstalują?
Opatentowany system ochrony przeglądarki (tzw. lockdown technology) chroni przeglądarki przed nieuprawnionym dostępem do informacji, które są przekazywane między klientem, a bankiem niezależnie od tego jaki typ złośliwego oprogramowania powoduje zagrożenie.
Rapport efektywnie blokuje wszystkie te techniki ataku:
· Phishing
· Pharming lub DNS Spoofing
· Keylogging
· Man-in-the-Middle
· Man-in-the-Browser
· Screen Capturing
· Session Hijacking
· Drive-by Download
2) czy sytuacja, w której zaatakowany jest punkt dostępowy do sieci Internet (podmiana serwerów DNS lub zdefiniowanie adresów IP dla konkretnych nazw) to rozwiązanie nadal będzie skuteczne?
Trusteer Rapport również chroni przed takimi atakami, określanymi mianem DNS spoofing lub Pharming.
3) co z urządzeniami mobilnym, na których korzystamy z systemów bankowości elektronicznej w wersji klasycznej, light (tzw. "lekkiej"/mobilnej) lub natywnej?
Trusteer Rapport chroni obecnie tylko komputery stacjonarne.
4) co z korzystaniem z bankowości elektronicznej poza komputerem, na którym klient zainstalował Trusteer Rapport?
Bank zaleca klientom instalację programu Trusteer Rapport na każdym komputerze wykorzystywanym do połączeń z serwisem bankowości internetowej. Użytkownik może sobie bezpłatnie zainstalować Rapporta na dowolnej liczbie urządzeń.
PS
Na zamówienie dokonujemy ewaluacji rozwiązań bezpieczeństwa, strategii/taktyk czy działań operacyjnych w zakresie wykrywania i obsługi incydentów bezpieczeństwa (także dotyczących ataków na klientów sektora finansowego) - na pewno pomożemy odpowiedzieć na wcześniej wymienione pytania i znacznie więcej. (kontakt {@} whitecatsec.com)
2015-05-04
FBB 2015: Efektywna wymiana informacji
Już w najbliższą środę (06.05.2015 - Warszawa) podczas Forum Bezpieczeństwa Banków 2015 kontynuacja cyklu prezentacji dla sektora finansowego i pokrewnych. Tym razem tematem będzie "Efektywna wymiana informacji" - czyli, na naszą wiedzę jeszcze niewykorzystany potencjał, pozwalający na skuteczne obniżanie poziomu ryzyka (czyt. stresu) zarówno dla banków jak i ich klientów.
Jeśli chcesz posłuchać o:
1) źródłach motywacji do wymiany,
2) czym (z jakimi cechami) i jak się wymieniać,
3) z kim się wymieniać i w jakim celu,
4) skąd czerpać (rola "zbieracza" i "łowcy") informacje by mieć czym się wymienić,
5) jak to wygląda poza granicami Polski.
Zapraszamy!
W przypadku chęci wymiany doświadczeń lub potrzeby wsparcia w tym temacie, zapraszamy do rozmowy z Przemkiem Skowronem podczas FBB lub w innym terminie (kontakt {@} whitecatsec.com).
Jeśli chcesz posłuchać o:
1) źródłach motywacji do wymiany,
2) czym (z jakimi cechami) i jak się wymieniać,
3) z kim się wymieniać i w jakim celu,
4) skąd czerpać (rola "zbieracza" i "łowcy") informacje by mieć czym się wymienić,
5) jak to wygląda poza granicami Polski.
Zapraszamy!
W przypadku chęci wymiany doświadczeń lub potrzeby wsparcia w tym temacie, zapraszamy do rozmowy z Przemkiem Skowronem podczas FBB lub w innym terminie (kontakt {@} whitecatsec.com).
Subskrybuj:
Posty (Atom)