Większość banków stosuje w swoich systemach bankowości internetowej i mobilnej metody autoryzacji transakcji (np. hasła SMS, "podpis elektroniczny", tokeny OTP, tokeny challenge-response). Stosowanie tego typu metod nie jest ograniczone tylko do systemów finansowych, są np. szeroko stosowane do autoryzowania operacji odzyskiwania hasła w różnego rodzaju aplikacjach. Autoryzacja transakcji ma ograniczać skutki wynikające z działania wrogiego oprogramowania na stacji użytkownika, przechwytywania sesji oraz zgadywania czy kradzieży haseł. W ostatnich latach widzimy jednak, że strategie działania grup przestępczych dostosowują się do tych zabezpieczeń i niejednokrotnie skutecznie je omijają. Prezentacja ma na celu skonfrontowanie obecnych metod autoryzacji operacji ze współczesnymi scenariuszami ataku przy użyciu malware oraz wskazanie typowych błędów w implementacji, które mogą przyczynić się do możliwości obejścia tych zabezpieczeń. Agenda (draft): - Krótka prezentacja metod autoryzacji transakcji. - Kilka "case study" - jak malware obchodzi autoryzacje transakcji (w tym własne doświadczenia zdobyte podczas analizy przypadków ataków w bankach). - Jak wybrać skuteczną metodę autoryzacji transakcji? - Na co uważać? Typowe błędy implementacji, które mogą przyczynić się do osłabienia mechanizmu autoryzacji transakcji.

1. Malware
i hackerzy
Wojciech Dworakowski
SECURE – 2015-10-14
Autoryzacja
transakcji
V S

2. wojdwo@securing:~$ whoami
Testowanie i doradztwo dotyczące
bezpieczeństwa aplikacji i systemów IT
od 2003 roku / ponad 300 systemów i aplikacji
Badania dotyczące nowych metod ataku i
obrony
OWASP Poland Chapter Leader
2

3. Agenda
Metody autoryzacji VS scenariusze działania malware
– podróż w czasie
Trendy i co czeka nas w (niedalekiej) przyszłości
Podatności w mechanizmach autoryzacji
Jak wybrać skuteczną metodę autoryzacji transakcji?

4. Metody autoryzacji transakcji
4
Image: www.rsa.com
Image: www.newtechusacom
Image: iss.thalesgroup.com
Image: emue.com
Domestic transfer to
account 99XXXX890
amount 1.00 EUR
authorization code:
36032651 Image: vasco.com
Image: wikipedia.org
Image: wikipedia.org

5. EWOLUCJA METOD
OBRONY I ATAKU

6. Uwierzytelnienie: hasło
Autoryzacja transakcji: brak
Scenariusz ataku: keylogger
Dawno, dawno temu…
Sinowall / Mebroot (2006)
(maskowane)

7. Kody TAN / iTAN - „Zdrapki”

8. Wskazanie tokena ma krótki czas życia
Time-based One-Time Password (TOTP)
Wyłudzenie wskazania i użycie go w czasie
(prawie) rzeczywistym
Podmiana transakcji w przeglądarce
nr_konta=661111000000006666
kwota=1000
KOD=3872

9. Challenge-response
***********Hasło:
Odpowiedź
tokena:
ID: 7890 2341
Image: iss.thalesgroup.com

10. Webinject + socjotechnika
Image: iss.thalesgroup.com
Hasło:
Odpowiedź
tokena:
ID: 4560 1407
Złe hasło. Wprowadź ponownie hasło i odpowiedź tokena
Rachunek:
Odpowiedź
tokena:
ID: 4560 1407
Kwota:
42 4433 6666
10 000 PLN
27492790

11. Słabości / Rekomendacje
Wszystkie te metody nie pozwalają na weryfikację
danych transakcji
Metoda autoryzacji transakcji powinna umożliwiać
użytkownikowi weryfikację znaczących danych
transakcji
(np. dla przelewu – konto odbiorcy i kwota)

13. SMS z kodem jednorazowym i opisem transakcji
Image: Alior Bank
Przelew krajowy: Nr konta
odbiorcy 22XXXX222 kwota
77.34 PLN kod autoryzujący:
36032651

14. Przechwycenie sesji i zmiana danych transakcji „w locie”
Zmiana nr konta w clipboardzie / pamięci
….
Metody ataku na autoryzację hasłem SMS
Problemy:
• Użytkownicy nie weryfikują
danych transakcji
• Użytkownicy weryfikują dane
transakcji z ekranem

15. Autoryzacja przy użyciu smartcard
Uwierzytelnianie
15
Image: alibaba.com

16. Malware VS smartcard
Autoryzacja transakcji
16
Podsłuchanie PIN,
Uwierzytelnie i wykonanie przelewów
– keylogger + “remote desktop”

17. CAP reader
17
Image: Barclays Bank

18. Socjotechnika
Weryfikacja poprawność
działania czytnika:
• Włóż kartę
• Naciśnij „SIGN”
• Wprowadź swój PIN
• Przepisz następujący ciąg
znaków: 6611 2266
• Wprowadź 11111
• Przepisz odpowiedź tutaj:

19. Socjotechnika („Dyre Wolf”)
Źródło: http://www.theinternetpatrol.com/dyre-wolf-wire-transfer-malware-gets-around-2-factor-authentication/

20. Brak uznanego, jednolitego standardu autoryzacji
transakcji
• Tylko przelewy „zaufane”
• SMS
• Token challenge-response
• Jako funkcja aplikacji
• Jako osobna aplikacja
• PIN (ten sam co do uwierzytelniania)
• Biometria (głos, odcisk palca)
• …
Bankowość mobilna

21. Overlay
Źródło:Arxan/IBM-http://www.slideshare.net/ibmsecurity/securing-mobile-banking-apps/18

23. webinject,
form grabbing,
cookie grabbing
browser hooking
on-the-fly webinject form
original server
Przejmowanie sesji
VNC
Wykrywanie POS +
Skanowanie pamięci
Wykrywanie smardcard
+ próba odczytu
Wykrywanie platform
bankowych + atak
Malware = Arsenał narzędzi = Różne scenariusze

24. Bankowość mobilna
Bankowość korporacyjna
Platformy bankowości korporacyjnej (np. Multicash)
Płatności elektroniczne
Private banking, Domy maklerskie, FOREX
Integracja z systemami FK, SDK
….
Cele: Atakowane aplikacje

25. Ataki celowane (targeting)
Firmy / korporacje
Klienci zamożni
Developerzy aplikacji bankowych
Łatwiejszy atak niż na bank
Na raz wiele aplikacji
Np. Corcow – sprawdza czy ofiara jest developerem
Androida
Cele: Zawężenie ataków

26. Malware wycelowane w konkretną aplikację a nie
masowe
Dostosowanie się do mechanizmów uwierzytelniania i
autoryzacji
Rozwój metod socjotechnicznych
Podmiana rachunku u źródła
Wykorzystanie podatności w mechanizmach autoryzacji
Metody działania

27. PODATNOŚCI
FUNKCJONALNE -
PRZYKŁAD
Podatności w mechanizmach
autoryzacji

28. Kluczowe operacje bez dodatkowej autoryzacji
Np.:
• Zmiana nr do kodów SMS
• „Parowanie” nowego urządzenia autoryzacyjnego
• Zmiana szablonu płatności

29. Zmiana nr do SMS
29

30. Zmiana nr do SMS
30

31. PODATNOŚCI
NIEFUNKCJONALNE -
PRZYKŁAD
Podatności w mechanizmach
autoryzacji

32. Krok1: Użytkownik wprowadza dane transakcji
POST /domesticTransfer HTTP/1.1
task=APPROVE_TRN
trnData.acc_id=910458
trnData.bnf_name=TELECOM+OPERATOR+Ltd
trnData.bnf_acc_no=9911110000000000123456789
trnData.amount=1.00
trnData.currency=EUR
trnData.title=invoice+123456
32

33. Krok2: Użytkownik wprowadza dane autoryzujące
POST /domesticTransfer HTTP/1.1
task=SEND_RESPONSE
trnData.response=87567340
33

34. POST /domesticTransfer HTTP/1.1
task=SEND_RESPONSE
trnData.response=87567340
Nadpisanie danych transakcji
34
trnData.bnf_acc_no=66222200000006666666666
trnData.amount=1000.00
trnData.currency=EUR

35. JAK WYBRAĆ
SKUTECZNĄ METODĘ
AUTORYZACJI?

36. Każdy bank i każda aplikacja są inne
Klienci: retail, MSP, corpo, private
Kanały: web, mobile, IVR, WebService, ...
Funkcjonalność
Profil klienta
środki, produkty, świadomość
Profil ryzyka, apetyt na ryzyko
Edukacja użytkowników

37. Scenariusz Czyja stacja komunikuje z
bankiem?
Czy strona jest zmieniana
w przeglądarce?
Przekierowanie na stronę
atakującego
atakującego webinject, przekierowanie
w DNS, strona serwowana
lokalnie, …
Zmiana transakcji w
przeglądarce
ofiary webinject
j.w. + back-connect ofiary webinject, przekierowanie
w DNS, strona serwowana
lokalnie, …
Remote desktop ofiary Nie
Zmiana nr rachunku w
clipboardzie, pamięci, na
stronie źródłowej
ofiary Nie
Detekcja malware - Nie ma paneceum na
wszystkie scenariusze ataków

38. Wyblokujemy adres IP / charakterystykę przegladarki /
konta słupów…!
Zaciemnijmy kod stony to malware nie będzie umiało zrobić
webinjecta!
Ograniczymy czas życia kodu autoryzującego!
Rozwiązania te są dobre ale na krótką metę.
Warto je stosować (w przypadku incydentu) ale zakładać
zmianę taktyki atakującego
…i jeszcze kilka (nieskutecznych?) pomysłów

39. Którzy klienci mają dostępne duże środki obrotowe?
Czy mają włączone dodatkowe zabezpieczenia:
autoryzacja na dwie ręce, limity, powiadomienia?
Przy wylogowaniu sprawdzanie czy klient wyciągnął
kartę z czytnika
Timeout + Techniki utrudniające scrapping
Rozwiązania tego typu również nie są uniwersalne
Ale skutecznie i trwale ograniczają powierzchnię ataku
…i kilka bardziej skutecznych przykładów

40. Potrzebna jest uniwersalna strategia
autoryzacji i uwierzytelniania
Wszystkie kanały
Nie tylko obecne trendy
ale też spojrzenie w
przyszłość
Bezpieczeństwo
/ Wygoda użytkowania
/ Koszty
Regulacje
Poprawność implementacji
Zabezpieczenia dodatkowe
np.: limity, podpis na dwie
ręce, powiadomienia, …
Detekcja
Malware, podejrzanych
operacji, anomalii
Edukacja użytkowników

41. WYGODA
UŻYTKOWANIA
KOSZT
BEZPIECZEŃSTWO
© Sławek Jasek

42. Materiały dodatkowe
http://www.securing.pl/materialy
OWASP Transaction Authorization Cheat Sheet
E-banking transaction authorization – possible vulnerabilities,
security verificationand best practices for implementation
Script-based malware detection in Online Banking Security
Overview
Raport Obserwatorium.biz:Nowe podejście do autoryzacji.
Systemowe zabezpieczenie instytucji finansowej

43. Dziękuję,
Zapraszam do kontaktu:
wojciech.dworakowski@securing.pl
@wojdwo