Zamiast wystawiania slajdów (są dostępne tutaj), postanowiłem zrobić mały przegląd swoich starszych wpisów i zebrać je w jednym poście. Dzięki temu jeśli ktoś jest zainteresowany tematem, będzie mógł poczytać trochę więcej, niż z suchych slajdów.
Zamiast slajdów z SecDay
Ataki celowane vs. ataki masowe
Moja prezentacja dotyczyła specyficznego typu ataków. Z tego powodu na początku wprowadziłem podział na ataki celowane oraz ataki masowe.
Ataki celowane to zupełnie inna klasa ataków, niż ataki masowe. W tym przypadku atakujący o swojej ofierze musi wiedzieć jak najwięcej. Choćby po to, by ją dobrze wybrać. Atak tego typu wymaga sporych przygotowań, jest również związany z większym ryzykiem. Z tego powodu atakujący musi wiedzieć, że atak, w przypadku powodzenia, będzie się opłacał. Zysk musi uzasadniać poniesione koszty oraz podjęte ryzyko.
W ostatnim czasie było kilka przykładów ciekawych ataków celowanych. Jeden z takich incydentów opisany jest we wpisie Wyłudził 300 tys. zł. …z banku. Nieco więcej w tym temacie można dowiedzieć się z Newsweeka, artykuł Vabank. Między innymi można się dowiedzieć, że wyprowadzenie pieniędzy (fizycznie) z banku, wcale nie jest proste. Co z tego, że udało się przelać kilkaset tysięcy na konto "słupa", skoro z tego konta można wypłacać jedynie kilka tysięcy dziennie?
Choć ataki celowane są spektakularne, to mimo wszystko sporadyczne. Spektakularne było przecież również wyniesienie kilku milionów złotych przez "ochroniarza": Dostał 5 milionów złotych na legitymację [Security Fail #8].
Jeśli na naszym koncie nie ma sporych pieniędzy, nic nie szkodzi. To, że mamy raczej małą szansę stać się ofiarą ataku celowanego, wcale nie znaczy, że jesteśmy bezpieczni. Są jeszcze przecież te ataki, które należą do drugiej grupy, czyli ataki masowe. Tu ofiary nie są wybierane, raczej obowiązuje podejście "kto się złapie". Choć wyprowadzane za pośrednictwem tego typu ataków kwoty z reguły nie są duże, to w połączeniu z ilością ofiar dają całkiem przyzwoite kwoty... A i ryzyko mniejsze. I takie wiadomości tego nie zmieniają: Scotland Yard rozbił duży gang hakerów. Ataki masowe mogą być prowadzone z dowolnego miejsca na świecie, a nie wszędzie policja działa tak sprawnie, lub jest specjalnie skłonna do współpracy.
Zamiast zajmować się bardzo wymyślnymi atakami, warto skupić się przede wszystkim na atakach masowych. Nie dlatego, by ataki celowane były nieciekawe czy nieistotne. Po prostu skala problemu związana z atakami masowymi jest dużo, dużo większa. Spotkać się z nimi ma okazję prawie każdy. Mało tego, przecież wiele osób już się z nimi spotkało. Choćby głośne ataki phishingowe, nawet jeśli niektóre dostarczają przede wszystkim wiele radości.
To właśnie obrona przed atakami masowymi była głównym tematem mojej prezentacji. A atakami masowymi, o których mówiłem, był wspomniany już phishing oraz ataki z wykorzystaniem malware.
Podstawowe mechanizmy ochrony
Ponieważ ataki masowe są kierowane przede wszystkim przeciwko użytkownikowi systemu, a nie samemu systemowi, można zastanawiać się, czy obrona przed nimi jest możliwa. Bez współpracy klienta - nie. Mimo wszystko można atakującemu utrudnić nieco życie dając jednocześnie klientowi dodatkowe szanse na zauważenie ataku. W tym zakresie najbardziej istotne są podstawowe mechanizmy obrony, czyli uwierzytelnienie użytkownika oraz autoryzacja transakcji.
Na temat tych mechanizmów pisałem już wielokrotnie. Dla przypomnienia:
- O bezpieczeństwie bankowości elektronicznej - uwierzytelnienie,
- O bezpieczeństwie bankowości elektronicznej - autoryzacja transakcji,
Uwierzytelnienie użytkownika
Cytowany tu tekst o uwierzytelnieniu użytkownika ma już prawie cztery lata, więc zdążył się nieco zdezaktualizować. Ale czy tak bardzo?
Uwierzytelnienie jednoskładnikowe nadal jest niebezpieczne, trudno się tu dziwić. Popularność podpisu cyfrowego spada. Część banków przestała go stosować z uwagi na aktywność malware kradnącego klucze. Inne dopuszczają użycie tej metody uwierzytelnienia wyłącznie w połączeniu z urządzeniem do bezpiecznego przechowywania kluczy. Coraz więcej banków stosuje uwierzytelnienie dwuskładnikowe. A UCR? Jakoś nie widać wielkiej, by to rozwiązanie było wykorzystywane. Zamiast tego pojawiły się tokeny GSM.
W tym wpisie stwierdziłem, że hasło maskowane jest trochę lepsze niż zwykłe hasło, lub podpis elektroniczny (klucz w pliku). Mimo wszystko za hasłami maskowanymi nie przepadam. Są niewygodne, a ich skuteczność mocno ograniczona. Ilość prób uwierzytelnienia, które trzeba podsłuchać by poznać całe hasło, wcale nie jest tak duża. Na ten temat też pisałem:
- O hasłach maskowanych,
- Maska II: atak kombinatoryka,
- Maska III: wartość oczekiwana,
- Hasła maskowane są ZŁE!,
Okazuje się, że teoria wyjątkowo zgadza się z praktyką. W typowych implementacjach wystarczy podsłuchać cztery/pięć prób uwierzytelnienia by poznać całe hasło użytkownika. A przecież atak wcale nie musi być pasywny.
Dodatkowe mechanizmy przy uwierzytelnieniu
W kontekście uwierzytelnienia użytkownika mówiłem również o dodatkowych mechanizmach, w które ten proces został obudowany. Konkretnie mówiłem o klawiaturze wirtualnej oraz obrazku antyphishingowym.
O klawiaturze wirtualnej pisałem: Klawiaturki wirtualne są ZŁE! O obrazku antyphishingowym do tej pory nie pisałem i na razie też sobie szczegóły odpuszczę. Wystarczy(?) chyba kilka informacji ogólnych.
Pierwotnie miał on być uzupełnieniem dwustronnego SSL, klient zamiast certyfikatu miał sprawdzać obrazek prezentowany przez serwer, a serwer miał rozpoznawać klienta na podstawie jego certyfikatu. Ponieważ zrezygnowano z dwustronnego SSL, serwer nie ma możliwości rozpoznania klienta przed podaniem przez niego swojego loginu. A w takim przypadku możliwy jest prosty atak man-in-the-middle, przez co obrazek nie wnosi praktycznie żadnej wartości dodanej. Niezależnie od tego, czy prezentowany jest przed czy po podaniu hasła.
Autoryzacja transakcji
Tekst o autoryzacji transakcji, mimo swoich lat, wciąż dość dobrze pokazuje do czego ten mechanizm jest potrzebny. Z czasem autoryzacja transakcji okazała się jeszcze istotniejsza. Nie tylko w zakresie dwóch podstawowych wymagań, czyli:
- potwierdzenia faktu złożenia zlecenia wykonania operacji,
- potwierdzenia parametrów zlecanej operacji,
Na pierwsze miejsce wysunęła się możliwość weryfikacji parametrów transakcji przed jej potwierdzeniem. Mówiłem o tym, jak dobrze parametry transakcji mogą zostać potwierdzone i (przede wszystkim) zweryfikowane przy pomocy kilku typowych metod autoryzacji wykorzystywanych we wdrożeniach bankowości internetowej.
Podpis cyfrowy chyba najlepiej spełnia postulat potwierdzenia faktu złożenia zlecenia wykonania operacji oraz potwierdzenia jej parametrów. Niestety, ograniczone możliwości weryfikacji powodują, że użytkownik nie do końca wie, co podpisuje.
W przypadku tokenów CR (w tym tokenów GSM) oraz kodów jednorazowych przesyłanych przez SMS okazuje się, że problemem jest pewna niejednoznaczność. Klient na podstawie otrzymanych danych nie ma całkowitej pewności, czy autoryzuje dokładnie taką operację, jaką chce wykonać. W przypadku spotykanych implementacji lepsze możliwości weryfikacji parametrów transakcji dają kody SMS, tokeny GSM są pod tym względem ograniczone. Jeśli ktoś jest zainteresowany tematem, kilka rozważań na ten temat znajdzie tutaj: Co identyfikuje rachunek czyli ile cyfr (nie)wystarczy.
Krótko wspomniałem o potencjalnej możliwości ataku typu replay attack na tokeny challnege-response. Więcej na ten temat można przeczytać tutaj: Token CR i replay attack. Temat tego typu ataków może dotyczyć również autoryzacji transakcji wykorzystującej podpis cyfrowy: Dlaczego podpisem warto objąć coś unikalnego.
Mówiłem też o tym, że w mojej ocenie wyższość tokenów GSM nad kodami SMS jest iluzoryczna, choć oczywiście kody SMS mają swoje wady. Jedna z wad to sposób dostarczania kodów. Taki kod podróżuje nie tylko przez sieć GSM, przechodzi również przez sieć operatora telefonii komórkowej, a wcześniej przez sieć brokera, który usługę bramki SMS do banku dostarcza. Atakujący może próbować przechwycić kody wysyłane przez bank do klientów. Przy czym im bliżej banku, tym lepiej - większy zysk z ataku. Przy atakach masowych raczej nie powinniśmy się obawiać klonowania kart SIM czy podsłuchiwania sieci GSM. Choć jest to technicznie możliwe, to ciężko to robić zdalnie. Z drugiej strony bardziej uwierzę w wynajęcie miłego, nadmuchanego pana, który zabierze mi telefon, niż w to, że ktoś będzie za mną biegał z przenośnym, podstawionym BTS.
Większy problem, niż bezpieczeństwo komunikacji, to bezpieczeństwo telefonów komórkowych. Te urządzenia to w coraz mniejszym stopniu telefony. To komputery, które możliwościami dorównują "dużym" komputerom sprzed kilku lat. I na tych telefonach z powodzeniem może funkcjonować malware. Jak tam się znajdzie?
Problemem wielu osób technicznych, w tym moim, jest szukanie technicznych rozwiązań jakiegoś problemu. Rzeczywiście, zainstalowanie malware na stacji roboczej to jedno, malware na telefonie - drugie. Do tego jeszcze trzeba jakoś skorelować ze sobą dane pochodzące z tych dwóch źródeł. Problem? Tak, chyba, że zrobi to za atakującego ładnie poproszony użytkownik.
Malware na telefonach komórkowych, ten atakujący banki, stanie się prawdopodobnie wkrótce sporym problemem. Dlaczego? Bo ZeuS dorobił się stosownej "wtyczki". Na ten temat można więcej przeczytać tutaj:
- Zasoby z konferencji Internet Banking Security 2010,
- ZeuS Variants Targeting Mobile Banking,
- ZeuS Mitmo: Man-in-the-mobile (I) ,
- ZeuS Mitmo: Man-in-the-mobile (II) ,
- ZeuS Mitmo: Man-in-the-mobile (III) ,
- Zeus In The Mobile (Zitmo): Online Banking’s Two Factor Authentication Defeated,
Obiektem ataku malware może być nie tylko SMS z kodami do autoryzacji transakcji, ale również token GSM, więc tutaj również ten wynalazek szczególnej wyższości nad kodami SMS nie ma.
Kilka dodatków
W pewnej chwili pojawił się wątek urządzeń USB zwiększających bezpieczeństwo bankowości internetowej. O ile się nie mylę, chodziło o to rozwiązanie: UBS Offers Security Device to Online Banking Customers. Zobaczymy jak będzie tego typu urządzenia będą się rozwijać. Być może skorzystanie ze specjalizowanych urządzeń tego typu będzie dobrym rozwiązaniem. Taką rolę miały pełnić telefony komórkowe, jednak chyba zbyt łatwo zainfekować je malware. "Klasyczne" tokeny mają zbyt małe możliwości w zakresie weryfikacji parametrów transakcji. Może i czas na coś nowego? Inna sprawa to kwestia adopcji tego typu urządzeń przez klientów, tu mam sporo wątpliwości.
Jedno z pytań z sali dotyczyło kiedy na komputerze, który jest "czysty" przeglądarka nie ostrzeże klienta przed nieprawidłowym certyfikatem. Odpowiedź może być nieco przewrotna - na przykład wtedy, gdy certyfikat będzie prawidłowy.
Przeglądarki "ufają" określonej grupie urzędów certyfikacji (CA), a z konstrukcji PKI wynika z kolei to, że ufają również certyfikatom wystawionym przez te urzędy. I tu pojawia się problem - tych domyślnie zaufanych urzędów jest zbyt dużo. Nie wszystkie mają równie wysokie standardy działania, a przeglądarka ufa im jednakowo (tu pomijam kwestię certyfikatów EV). By nie wgłębiać się za bardzo w temat: Ufne przeglądarki, ewentualnie bliżej źródła: Experts Warn of a Weak Link in the Security of Web Sites.
Sama poprawność certyfikatu jeszcze nie gwarantuje, że strona, na którą trafiliśmy, jest tą stroną, na którą trafić chcieliśmy. Certyfikat powinien być zweryfikowany przez użytkownika, w szczególności jego "odcisk palca". Banki, przynajmniej część z nich, informują klientów o tym, jak powinien wyglądać prawidłowy certyfikat, tu przykład z mBanku: Szyfrowanie i certyfikaty. A teraz zagadka - jak bardzo można ufać informacji na temat certyfikatu prezentowanej przez mBank? I dlaczego?
Przeglądarka może rozpoznać certyfikat jako prawidłowy również w innych przypadkach. Na przykład może zawierać błąd w procedurze weryfikacji jego poprawności. Niektóre z tych błędów mogą być bardziej używalne niż ten przykład: Multiple Browser Wildcard Cerficate Validation Weakness.
Okazuje się, że weryfikacja certyfikatu wcale nie jest taka prosta. Nie wystarczy sprawdzić, czy jest on poprawny, ale należy również sprawdzić, czy jest tym certyfikatem, który posiada autentyczny serwer. Rozwiązaniem tego problemu miał być obrazek antyphishingowy, ale z powodów, o których mówiłem na konferencji - nie jest.
Jeśli mocniej zastanowić się nad problemem, oczywiste staje się, że wcześniej czy później pierwsza linia obrony, uwierzytelnienie użytkownika, padnie. Dlatego tak istotna jest autoryzacja operacji. Operacji, bo w bankowości można zrobić więcej, niż tylko przelew. Powtórzę jeszcze raz - mechanizm autoryzacji powinien nie tylko potwierdzać fakt jej złożenia oraz jej parametry, ale również dawać klientowi możliwość weryfikacji tego, jaką operację w rzeczywistości autoryzuje. Sam mechanizm autoryzacji operacji powinien być nie tylko dobrze wymyślony, ale również poprawnie zaimplementowany. Z tym drugim też różnie bywa.
Dwie uwagi:
a) ze względów rynkowych to jest obecnie niestosowane (m.in. wygoda dla klienta, konieczność supportu dla niezliczonej ilości modeli telefonów)
b) pomijasz kwestie malware na telefony, a tego nie można pominąć (a.d.2010) - każdą aplikację prędzej czy później będzie się dało zreversować.
Myślę, że obecnie ciekawszym rozwiązaniem byłby powrót do prób z QR-kodami jako alternatywy dla przepisywania szczegółów transakcji ręcznie w modelu challenge-response. Paweł wspominał, że były próby, ale aparaty w komórkach były wtedy zbyt słabe. Może teraz jest już lepiej.
Pewnym dodatkowym argumentem dla banków za wprowadzeniem tokenów GSM jest redukcja kosztów - wysyłanie SMS kosztuje. W Twoim scenariuszu tej zalety by nie było - kody SMS nadal byłyby wysyłane, więc brak redukcji kosztów po stronie banku.
Teoretycznie podobne podejście można zastosować przy z kodami QR, to znaczy kod może zawierać szyfrowane lub jakoś "podpisywane" dane, ale tu problemem są aparaty. Im więcej danych ma być zakodowanych na takim kodzie, tym większe wymagania odnośnie aparatu.
Ogólnie - temat jest ciężki, z kilku powodów. Może do niego jeszcze wrócę, bo jest interesujący, ale na razie to więcej mam(y) wątpliwości, niż sensownych odpowiedzi.
Dużo ciekawych kwestii poruszył też Krzysiek w swoim komentarzu, na przykład kwestię "wspieralności" jakiegoś rozwiązania (dodatkowe koszty!).
p.s. Jasne ze malware i RE ignorowac nie mozna, ale to chyba dotyczy takze tokenow, dobrze mysle?