0. Wstęp

Banki, aby jak najbardziej uszczęśliwić swoich klientów (albo w zasadzie, by nie oddać ich w ręce konkurencji), inwestują w nowe trendy i technologie. Najpierw mieliśmy proste (statyczne) strony internetowe, następnie bankowość elektroniczną, teraz czasem nawet mamy dostęp do sklepów bankowych. Oczywiście wszystko w wersji klasycznej oraz mobilnej. Strony są piękniejsze, ciekawsze, zaskakują nas nowymi możliwościami. Wczoraj – HTML4 z Javą, dzisiaj HTML4+CSS+JS+JQuery, jutro HTML5. Wspaniale, że banki idą z duchem czasu.

Niestety, w niektórych aspektach można odnieść wrażenie, że chodzi tutaj tylko o cukiereczki, przedstawiane klientom na ekranach ich monitorów. Nowe technologie - to nowe niebezpieczeństwa, a z tym banki walczyć nie chcą.

Wpis ten przedstawia wyniki analizy, którą przeprowadziłem na przełomie marca i kwietnia 2012, przygotowując się na szkolenie grupy FP Security Experts w związku w wydarzeniem Caseweek 2012. Badania dotyczyły analizy zabezpieczeń największych banków w Polsce przeciwko zagrożeniom związanym z atakami z rodziny UI Redressing (a dokładnie – Clickjacking).

1. Czym są ataki z rodziny UI Redressing – Clickjacking

Ataki UI Redressing są atakami, które polegają na zaawansowanym manipulowanu wyglądem strony w taki sposób, aby zachęcić użytkownika do wykonania pewnych konkretnych akcji na atakowanych stronach (tutaj: banków). Ataki przeprowadzane są albo przy wykorzystaniu specjalnie spreparowanych stron, albo przy wykorzystaniu luk, takich jak XSS, HTML Injection (do ich wykorzystania nie jest wymagany błąd na stronie banku, może być do tego użyta dowolna strona z błędem lub nowa strona ze złośliwym kodem).

Najpopularniejszym atakiem z rodziny UI Redressing jest atak typu Clickjacking.
Oprócz Clickjackingu, do ataków UI Redressing można zaliczyć również między innymi:

• Cursorjacking
• Tabnabbing

Clickjacking polega na porwaniu kliknięcia użytkownika. Ofiara odwiedza spreparowaną (lub zaatakowaną) stronę. Strona ta zachęca w klikania w pewne elementy, na przykład poprzez pewne linki, gry lub inne akcje. Elementy te przykryte są niewidzialnymi ramkami, wysuniętymi względem innych (z-index). Użytkownik myśli, że wykonuje akcje (klikanie) na pewnej przyjaźnie wyglądającej stronie, a w rzeczywistości klika w kontekst znajdujący się w niewidzialnej ramce. Ramka ta (iframe) posiada treść atakowanej strony (bankowej), która jest tak wypozycjonowana, aby ofiara klikała w rzeczy zdefiniowane przez atakującego.

Demonstracja klasycznego (najprostszego) przypadku ataku Clickjacking pokazuje poniższy film. Atakowany jest tutaj serwis Politechniki Śląskiej (Moodle CMS):

W ten prosty sposób istnieje możliwość usunięcia konta na atakowanej stronie (banku), dodania komentarza, uploadowania plików i tak dalej. Spore niebezpieczeństwo.

Jak chronić webaplikację przed atakami Clickjacking?

Aplikację można obronić na dwa sposoby.

Po pierwsze powinniśmy wykrywać, przy użyciu Javascriptu, czy nasza strona jest ramkowana. Jeśli tak, powinniśmy w jakiś sposób uniemożliwić „klikanie”, poprzez na przykład wyłączenie elementów strony przy wykorzystaniu CSS lub poprzez „wyskoczenie” naszej strony poza ramkę.

Zapobieganie ramkowaniu naszej strony przez inne nazywamy Framebustingiem.

Kod framebustingowy nie jest strasznie skomplikowany i zazwyczaj zawiera kilka linii kodu Javascript (2-5). Niestety, jego poprawne napisanie wymaga bardzo dokładnej analizy, ponieważ istnieje wiele możliwości, aby go oszukać… co oczywiście umożliwi nam dalsze przeprowadzanie ataku (tzw. Busting framebusting).

Lepszą ochroną jest zastosowanie nagłówków X-Frame-Options w naszej webaplikacji. Gdy przeglądarka pobierze do ramki kod strony, który wyśle nagłówek X-Frame-Options, wtedy zawartość nie zostanie wyświetlona. Zamiast tego użytkownik otrzyma informację, że ramkowanie strony jest niedozwolone. Dodanie nagłówka X-Frame-Options kosztuje w większości przypadków programistę dodanie jednej linijki kodu. Może to zrobić też administrator serwera HTTP, również w większości przypadków dodając jedną linijkę do pliku konfiguracyjnego (przynajmniej w wypadku Apache2). Stosowanie X-Frame-Options jest banalnie proste i może całkowicie rozwiązać problem Clickjackingu na naszej stronie. Jedyny warunek: przeglądarka użytkownika musi wspierać ten nagłówek. Z tym na szczęście dzisiaj nie ma już problemu:

Więcej o atakach UI Redressing oraz ochronie przeciwko nim można można usłyszeć na warsztacie HTML 5 – Nowe zagrożenia.

Ataki Clickjacking przypominają zarówno ataki CSRF, jak i klasyczne ataki phishingowe.

2. Banki poddane analizie

Lista banków została zaczerpnięta z artykułu portalu „Newsweek Biznes”:
Ranking „Przyjazny Bank Newsweeka 2011″: Najlepszy bank internetowy.

W powyższym rankingu przeprowadzono badania bankowości elektronicznej pod względem możliwości oferowanej przez nowe technologie oraz użyteczności tych technologi. Jak pisze Newsweek:

Czy dla 10 milionów klientów korzystających z usług bankowych bez wychodzenia z domu, tylko za pomocą internetu i telefonu, jakość obsługi ma mniejsze znaczenie? Absolutnie nie, choć dla nich z natury rzeczy istotniejsze są inne aspekty tej jakości. Takie jak łatwość nawigacji i dokonywania operacji na stronie internetowej banku, funkcjonalność poczty elektronicznej czy poszerzanie oferty banku o nowe, a zyskujące popularność produkty i usługi…

fot. Vizzdoom - Tabela 1. Lista badanych banków

Jak można przeczytać w Tabeli 1, zbadane zostały nie tylko strony główne banków, ale również strony bankowości elektronicznej. Jak się okazało, całkowicie inne podejście pod względem bezpieczeństwa funkcjonuje w tych dwóch obszarach.

Warto też zaznaczyć, że w przypadku bankowości elektronicznej badania dotyczą tylko kont indywidualnych (lub najpopularniejszej opcji bankowości elektronicznej danego banku). Pobieżna analiza pokazała, że poziom zabezpieczeń różnych usług e-bankowości w tych samych placówkach stoi na tym samym poziomie – ze względu na czas nie przeprowadzałem dogłębnej analizy każdego wariantu.

3. Metoda analizy

Pierwszym sprawdzanym zabezpieczeniem było określenie, czy strona banku zwraca odpowiednio ustawione nagłówki X-Frame-Options.

Następnie analizie poddano kod Javascript Framebusting. Zabezpieczenie to, pomimo wielu wad, powinno w krytycznych sytuacjach być stosowane obok X-Frame-Options, aby umożliwić ochronę dla użytkowników korzystających z bardzo starych wersji przeglądarek.

Samo wdrożenie Framebustingu to nie wszystko – trzeba go stosować poprawnie. W kolejnym kroku próbowałem przełamać kod framebustingowy przez zastosowanie mechanizmów implementowanych we współczesnych przeglądarkach (lub takich, które lada chwila się pojawią, ponieważ znajdują się w nowych wersjach specyfikacji HTML 5).

Ostatnim krokiem jest opisanie kontaktu na linii Pentester – Bank. Błędy zdarzają się każdemu. Po pierwszej analizie skontaktowałem się pisemnie z przedstawicielami każdego z banków, przy użyciu formularzy kontaktowych dostępnych na ich stronach (lub poprzez e-maile). Opisywałem tam problem oraz pytałem, czy zostanie on poprawiony (oraz kiedy).

Wiadomości były wysyłane dnia 29 marca 2012 r. Na odpowiedź czekałem 22 dni, do 20 kwietnia (około 15 dni roboczych, ze względu na święta).

Po niespełna 3 tygodniach sytuacja została zbadana ponownie, aby zobaczyć, czy w takim okresie banki potrafią zareagować na niebezpieczeństwo.

4. Ocena

Na ocenę składa się pięć czynników:

1. X-Frame-Options (strona główna) – 0 pkt: brak nagłówka, 5 pkt: stosowanie nagłówka na stronie głównej banku
2. X-Frame-Options (e-bankowość) – 0 pkt: brak nagłówka, 5 pkt: stosowanie nagłówka na stronie bankowości elektronicznej
3. Framebusting (strona główna) – 0 pkt: brak Framebustingu, 2 pkt: stosowanie Framebustingu, 5 pkt: stosowanie poprawnego Framebustingu na stronie głównej banku
4. Framebusting (e-bankowość) – 0 pkt: brak Framebustingu, 2 pkt: stosowanie Framebustingu, 5 pkt: stosowanie poprawnego Framebustingu na stronie bankowości elektronicznej
5. Kontakt – 0 pkt: brak odpowiedzi banku (lub odpowiedź automatyczna), 1 pkt: generyczna odpowiedź (wszystko w porządku, mamy dobre zabezpieczenia, proszę się nie martwić), 2 pkt: zrozumienie problemu, przekazanie go do odpowiedniego departamentu w celu analizy, 3 pkt: zrozumienie problemu, opisanie metody zabezpieczenia, obietnica wdrożenia, 5 pkt: zrozumienie problemu i wdrożenie poprawek na swoje strony

fot. Vizzdoom - Tabela 2. Wyniki badań

Zasada działania kodu framebustingowego jest prosta – kod powinien wykryć, czy strona jest w ramce. Jeżeli jest – stronę powinno się zaciemnić lub przeładować np. top.location. Skutkuje to „wyskoczeniem” strony z ramki rodzica i udaremnienie ataku.

Niestety, jest wiele sposobów omijania kodu framebustingowego. Jeżeli kod jest napisany niepoprawnie – wtedy atakujący może przechytrzyć mechanizm, zaramkować stronę i podsunąć taką wersję ofierze. Niepoprawny kod framebustingowy jest sytuacją bardzo często widzianą w internecie. OWASP, przeprowadzając badania w 2010 roku, był w stanie złamać takie zabezpieczenia na każdej stronie z rankingu Alexa TOP World 500.

fot. Vizzdoom - Tabela 3. Stosowany kod framebustingowy

Wnioski

Niestety, wyniki analizy są bardzo niepokojące.

Jeśli chodzi o tematykę X-Frame-Options, to można śmiało powiedzieć, że polskie banki nie mają pojęcia o tym nagłówku. Jego wdrożenie jest banalnie proste (można to zrobić przez jedną linijkę kodu lub jeden wpis w konfiguracji serwera, aby zabezpieczyć całą aplikację), jednak w praktyce nagłówek wysyła tylko bank Inteligo i to wyłącznie na stronie e-bankowości.

Widać, że zagadnienie ataków UI Redressing – Clickjacking nie jest obce wśród programistów banków, ponieważ widać próby zabezpieczania przed tym niebezpieczeństwem. Pomimo tego, że strony główne banków nie są zabezpieczane w żaden sposób, można zauważyć kod framebustingowy na stronach e-bankowości. Powoduje to, że możemy nakłonić ofiarę do dowolnego klikania po stronach głównych banków (zazwyczaj nic to nam nie da), przygotowanie ataku na stronę e-bankowości przysporzy już więcej problemów. Ale czy aby na pewno?

Tylko dwa banki stosują poprawny kod framebustingowy na stronie e-bankowości. Reszta witryn posiada dziecinne zabezpieczenia, które można obejść na wiele sposobów. Czasem może to być proces skomplikowany, ale można go uprościć, używając ramki z sandboxingiem. Sandboxing ramek jest nowym elementem specyfikacji HTML5, który pozwala na wyłączanie skryptów lub zmiany wartości top.location. W tym momencie sandbox interpretowany jest wyłącznie przez przeglądarki Chrome, Safari oraz Internet Explorer 10. Wsparcie w przeglądarkach nie jest duże – ale należy podkreślić, że sandboxing ramek jest zaakceptowanym elementem HTML5. Lada chwila wszystkie wiodące przeglądarki będą go obsługiwać (chociażby rzesza użytkowników nowego Windowsa 8 wraz z IE 10).

Ze wszystkich dwudziestu jeden banków w miarę bezpiecznie mogą czuć się wyłącznie klienci banków Inteligo, Deutche Bank oraz Citi Handlowy. W tych trzech bankach w miarę poprawnie wdrożony jest przynajmniej jeden czynnik zabezpieczający najważniejszy element serwisu, czyli e-bankowość.

Trzy banki: mBank, Meritum Bank oraz ING Bank Śląski w praktyce nie gwarantują żadnego zabezpieczenia przeciwko atakom Clickjacking, jednak widać u nich próby wdrożenia pewnych zabezpieczeń. Pomimo tych niedociągnięć, kontakt z tymi bankami był przyjemny i skutkował przekazaniem moich sugestii do odpowiednich ludzi/departamentów. Można mieć nadzieję, że po pewnym czasie (lub po nagłośnieniu tego artykułu) zabezpieczenia w tych bankach zostaną wprowadzone.

Cała reszta piętnastu banków albo posiada błędne mechanizmy, albo nie implementuje ich wcale! Jest to tragiczna wiadomość, w szczególności że w wielu przypadkach kontakt w tej sprawie był albo niemożliwy, albo skutkował tylko wysyłaniem wiadomości w rodzaju „Nasze zabezpieczenia są na najwyższym poziomie. Używamy SSL” i nic w tej tematyce nie mogłem zrobić.

Każdy może popełniać błędy. Ważny jest zatem aspekt kontaktu z bankiem – ponieważ zagrożenie może wpływać na tysiące klientów i może być zauważone przez klienta. Wiele akcji marketingowych ma nas uświadomić, w jak przyjemny i sprawny sposób możemy nawiązać kontakt z pracownikami banków. Formularze kontaktowe, telefony i wiele innych informacji kłuje nas w oczy na stronach banków. W dużej części przypadków obietnice te możemy wyrzucić do kosza, ponieważ jedyne, na co możemy liczyć, to informacja, że uwaga trafiła gdzieś do skrzynki pocztowej jakiegoś pracownika. Czasem zdarza się, że dostaniemy nic nieznaczące podziękowanie za wysłanie wiadomości (automat) lub ogólne zapewnienie – że będzie lepiej (zapewne pisane wzorcem Copiego-Paste’a). Na całe szczęście istnieje grupa banków, z którymi można wymienić przynajmniej jednego maila na odpowiednim poziomie.

Z gamy wyżej opisanych piętnastu banków warto wspomnieć osobno o BZW BK. Pomimo tego, że nie zostały tam zaimplementowane żadne zabezpieczenia przeciwko atakom Clickjacking – kontakt z tym bankiem był nad wyraz przyjemny. Sprawę przekazano odpowiedniemu programiście, który wymieniając ze mną maile, udowodnił, że bardzo dobrze rozumie problem i przedstawił jego poprawne rozwiązanie. Miało ono być wdrożone, jednak jego pojawienie się zaplanowane zostało dopiero na kolejną wersję serwisu. Niestety – do tej pory to nie nastąpiło, ale z wysokim prawdopodobieństwem zabezpieczenia pojawią się w najbliższych miesiącach.

Ciekawa sytuacja wystąpiła w kontakcie z Inteligo. Nie korzystałem nigdy zarówno z ich usług, jak i usług PKO BP oraz iPKO. Jako osoba, która nie interesowała się tymi bankami, muszę śmiało powiedzieć, że czułem się mocno zagubiony. Nie widziałem, która część serwisu (lub która strona) należy do jakiej jednostki. Początkowo przeoczyłem Inteligo, myśląc, że jest to iPKO. Na szczęście 100% akcji Inteligo należy do PKO BP, więc kontaktując się nie rozdrabniałem się na różne usługi. Pisałem ogólnie o stronie i e-bankowości tych jednostek. Przyznaję, była to niezbyt czysta zagrywka, ponieważ pisałem o błędach zabezpieczeń Clickjackingowych, a Inteligo częściowo wysyła nagłówki X-Frame-Options. Pracownik jednak zapewnił mnie, że aplikacje są zabezpieczone i banki od dawna mają świadomość tych ataków. To bardzo dobra odpowiedź – wiadomo, że pracownik wie, o czym mówi (a nie tylko zamydla oczy). W związku z powyższym wystawiona została wysoka ocena w kategorii Kontakt. Przemilczę, że zabezpieczenia nie są wprowadzone wszędzie, ale ten fakt jest odnotowany w tabeli wyników.

Końcowe wnioski z analizy przedstawia poniższy rysunek:

Słowo końcowe

Powiedzenie „bezpieczne jak w banku” nie do końca odnosi się do poziomu zabezpieczeń polskich banków, przynajmniej jeśli chodzi o ataki z rodziny UI Redressing – Clickjacking. Ogólnie rzecz ujmując, bezpieczeństwo elektroniczne banków w Polsce (w opisywanym temacie) nie stoi na wysokim poziomie. Banki chętnie wprowadzają nowe technologie i rozwiązania – jednak nie szkolą pracowników w tematyce przeciwdziałania nowym niebezpieczeństwom.

W tym momencie żaden bank nie dostarcza kompletnych zabezpieczeń na swoich stronach. Wyłącznie 3 banki (na 21 zbadanych) dostarczają pewne poprawne mechanizmy, które zabezpieczają kluczowe usługi.

Czy sytuacja ta zmieni się w najbliższym czasie? Jeżeli ten artykuł nie uderzy do publicznej świadomości na dużą skalę – bardzo wątpię. Duża część banków nie zwraca uwagi na opinie pentestera.

Ataki Clickjackingowe są bardzo proste w przeprowadzeniu i mogą wyrządzić wysokie szkody. Zabezpieczenie się przeciwko nimi to kilka minut pracy. Jak widać, jest to dla wielu instytucji zbyt dużo.

Generalna rada – nie wierzcie nikomu na słowo. A przede wszystkim… Nigdy nie ufajcie maszynom!

Vizzdoom
IT Security Engineer

Artykuł za zgodą autora został przedrukowany z serwisu vizzdoom.net

Czytaj także: Skrypty do likejackingu sprzedawane na Allegro