Nie wszystko złoto

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.

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:

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:

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.

Oryginał tego wpisu dostępny jest pod adresem Nie wszystko złoto

Autor: Paweł Goleń