Dziś będzie krótko. Na początek odsyłam do tekstu, do którego chcę się odnieść: A czy Twój bank jest odporny na ataki UI Redressing – Clickjacking? A teraz konkretniej - ja z UI Redressing mam pewien problem. To jest doskonała podatność do pokazywania na konferencjach, szkoleniach, prezentacjach. Jest bardzo efektowna, ale już z jej efektywnością bywa różnie. Tekst, do którego odsyłam, dotyczy bankowości internetowych. Obawiam się, że w tym konkretnym przypadku z efektywnością (czyli skutecznością) tego typu ataku byłoby bardzo słabo.
Nie wszystko złoto
Istotą UI Redressing jest przekonanie użytkownika, że robi coś innego, niż w rzeczywistości robi. Możliwość nałożenia jednej strony na drugą pozwala w rezultacie "wykorzystać" użytkownika do tego, by wykonał on oczekiwane przez atakującego operacje. Kilka ciekawych przykładów można znaleźć choćby u Krzyśka, na przykład Exploiting the unexploitable XSS with clickjacking albo Cross domain content extraction with fake captcha. Warunkiem powodzenia takiego ataku jest użytkownik, który robi to, czego oczekuje od niego atakujący. I tu zaczynają się schody.
W przypadku bankowości internetowych każda istotna operacja powinna wymagać autoryzacji. Wynika to choćby z zasady defence-in-depth. Zakładamy, że atakujący może uzyskać dostęp do konta użytkownika (zdobycie danych uwierzytelniających, przejęcie sesji) i staramy się zastosować takie zabezpieczenia, by skutki takiego zdarzenia były ograniczone do ujawnienia informacji. Do tego należy dodać również pewne rozwiązania wprowadzane dla wygody użytkownika, jak choćby przelewy/szablony zaufane, albo brak wymagania autoryzacji operacji wewnętrznych (przelew między rachunkami, założenie lokaty). Każda inna operacja powinna wymagać autoryzacji, a autoryzacja nie powinna być możliwa "przypadkiem". Użytkownik powinien wiedzieć, że autoryzuje operację oraz powinien wiedzieć dokładnie jaką operację autoryzuje. Mechanizmy techniczne muszą być uzupełnione edukacją użytkowników, a użytkownik nie powinien być zaskakiwany działaniem mechanizmu bezpieczeństwa (tak: Principle of least astonishment).
Ile operacji trzeba wykonać, by dokonać przelewu? Dla uproszczenia niech będzie to przelew krajowy. W większości banków, które widziałem, trzeba:
- określić rachunek źródłowy,
- wpisać rachunek docelowy,
- określić kwotę przelewu,
- podać dane odbiorcy przelewu,
- podać tytuł przelewu,
- potwierdzić przelew,
Przypominam, że jesteśmy jeszcze przed autoryzacją, a aby znaleźć się w tym miejscu, musieliśmy trafić na wyjątkowo skłonnego do współpracy użytkownika. Pozostaje go tylko przekonać do tego, by przepisał kod otrzymany w SMS, albo na przykład podał wskazanie tokenu. Nie jest to całkowicie niemożliwe, ale zbliżamy się niebezpiecznie do poziomu albańskiego wirusa. Jeśli trafiliśmy na użytkownika tak skłonnego do współpracy, to najprawdopodobniej Clickjacking nie jest wcale potrzebny.
Można rozważać kolejne funkcje w różnych bankowościach i zastanawiać się, którą z nich być może użytkownik wykonałby nieświadomie. Będę się jednak upierał, że by atak tego typu zadziałał musi być jednocześnie spełnionych bardzo wiele warunków. Prawdopodobieństwo zaistnienia ich wszystkich jednocześnie jest niewielkie. Jeśli natomiast użytkownik jest wyjątkowo podatny na social engineering, to może po prostu trzeba go wystarczająco ładnie poprosić, by zrobił to, czego od niego oczekujemy? Na przykład tak: Police Themed Ransomware Continues. Niezłe skutki odnoszą również ogłoszenia o "aktualizacji" numerów kont bankowych do opłat za czynsz, wodę, (...). Słyszałem nawet o fraudach, w których przesyłane były aktualizacje numeru kont komornika, na które miały być kierowane zajęte środki. Gra warta świeczki, jeśli uwzględnić, że zdarzają się zajęcia opiewające na wiele milionów złotych...
Podatności należy postrzegać w odpowiednim kontekście, choćby po to, by określić z jakim ryzykiem się wiążą. Jeśli podatność istnieje (i o niej wiemy) to powinniśmy zwracać uwagę na dwie rzeczy:
- potencjalny skutek wykorzystania podatności,
- prawdopodobieństwo wykorzystania podatności,
Prawdopodobieństwo wykorzystania podatności zależy między innymi od tego, jak łatwo ją wykorzystać. Jeśli do skutecznego wykorzystania podatności wymagane jest spełnienie wielu warunków, to prawdopodobieństwo jej wykorzystania jest niewielkie. W rezultacie niewielkie jest również ryzyko z nią związane, nawet jeśli potencjalnie skutki wykorzystania podatności mogą być duże.
Warto zauważyć, że określony typ podatności w różnych systemach/aplikacjach może charakteryzować się różnym stopniem trudności wykorzystania. Kradnięcie lajków to jedno, wykorzystanie UI Redressing do wyprowadzenia pieniędzy z konta w bankowości internetowej, to drugie.
P.S. Oczywiście uważam, że w ramach wspominanej już zasady defence-in-depth nagłówek X-FRAME-OPTIONS powinien być wykorzystany. Chcę natomiast pokazać, że nie zawsze brak tego zabezpieczenia to od razu tragedia i koniec świata.
Ataki Clickjacking ogółem nie są ogromnym niebezpieczeństwem - ale dobrze wiesz, że jednak mogą wywołać duże nieprzyjemności, chociażby na co dwudziestym atakowanym użytkowniku. No jest to klasyczny problem phishingu - niby nic, a jednak ludzie pieniądze tracą.
W artykule pisałem bardziej w kontekście tego, że banki nie kwapią się, aby wprowadzać zabezpieczenia szybko i sprawnie, nawet gdy ktoś wprost wspomina o błędach.
Jeśli chodzi o wykradzenie pieniędzy jest to już przykład skrajnie ciężki i trudny. Praktycznie nie możliwy do wykonania tą metodą. Jednak e-bankowość to nie tylko przelewy. Mam konto tylko w jednym banku, ale mogę tam zrobić dużo operacji nie związanych z przelewem, a których nie chciałbym "wyklikać". I nie wszedzie są wymagane tokeny smsem.
Artykuł, który opisałem był mi potrzebny do szkolenia, które prowadziłem - jako pewna demonstracja stopnia olewania tej tematyki na polskich stronach. Podzieliłem się nim po prostu dalej. Każdy zaznajomiony z tematem wie czym jest Clickjacking i jak trudno coś przy jego pomocy zyskać. Badanie to jednak badanie, ma nakreślić jakąś część rzeczywistości szerszej publice (po co trzymać coś dla siebie, jak innych może zaciekawić).
Ja dalej uważam, że banki trochę olewają sprawę - dla mnie bankowość elektroniczna powinna być wzorem w tematyce bezpieczeństwa IT.
Jeśli chodzi o zmiany, nawet tak niewielkie jak dodanie nagłówka, to administratorzy też nie mogą sobie od tak wprowadzić zmiany. Jeśli zmiana ma być w kodzie, to z kolei zaczyna się proces zmiany, który trwa (i kosztuje). Skoro kosztuje, to może nie jest to najbardziej istotny temat do wydawania pieniędzy.
Nie zgadzam się z Twoim ostatnim zdaniem w komentarzu. System powinien być wystarczająco bezpieczny. To, co to w praktyce oznacza (jakie ryzyko bank jest skłonny zaakceptować), zależy od banku. Spora część działalności banku to właśnie szacowanie ryzyka i podejmowanie decyzji, co z nim zrobić. A wpływ na ryzyko ma nie tylko bankowość, ale też całe "wsparcie" za nią, którego nie widać. Choćby wykrywanie fraudów i reakcja na nie.