Wojciech Dworakowski Autoryzacja transakcji V S Malware i hackerzy SECURE 2015-10-14
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
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?
Metody autoryzacji transakcji Image: www.rsa.com Image: www.newtechusacom Domestic transferto account 99XXXX890 amount 1.00 EUR authorization code: 36032651 Image: wikipedia.org Image: wikipedia.org Image: iss.thalesgroup.com Image: emue.com Image: vasco.com 4
EWOLUCJA METOD OBRONY I ATAKU
Dawno, dawno temu Uwierzytelnienie: hasło(maskowane) Autoryzacja transakcji: brak Scenariusz ataku: keylogger Sinowall/ Mebroot(2006)
Kody TAN / itan- Zdrapki
Time-based One-Time Password(TOTP) Wskazanie tokena ma krótki czas życia Wyłudzenie wskazania i użycie go w czasie (prawie) rzeczywistym Podmiana transakcji w przeglądarce nr_konta=661111000000006666 kwota=1000 KOD=3872
Challenge-response Hasło: *********** Image: iss.thalesgroup.com ID: 78902341 Odpowiedź tokena:
Webinject + socjotechnika Rachunek: Kwota: 42 4433 6666 10 000 PLN ID: 45601407 Odpowiedź tokena: Złe hasło. Wprowadź ponownie hasło i odpowiedź tokena Hasło: Image: iss.thalesgroup.com ID: 45601407 Odpowiedź tokena: 27492790
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)
Image: Alior Bank SMS z kodem jednorazowym i opisem transakcji Przelew krajowy: Nr konta odbiorcy22xxxx222kwota 77.34 PLN kod autoryzujący: 36032651 13
Metody ataku na autoryzację hasłem SMS Przechwycenie sesji i zmiana danych transakcji w locie Zmiana nr konta w clipboardzie/ pamięci. Problemy: Użytkownicy nie weryfikują danych transakcji Użytkownicy weryfikują dane transakcji z ekranem
Autoryzacja przy użyciu smartcard Uwierzytelnianie Image: alibaba.com 15
Malware VS smartcard Autoryzacja transakcji Podsłuchanie PIN, Uwierzytelnie i wykonanie przelewów keylogger + remote desktop 16
Image: Barclays Bank CAP reader 17
Socjotechnika Weryfikacja poprawność działania czytnika: Włóż kartę Naciśnij SIGN Wprowadź swój PIN Przepisz następujący ciąg znaków: 66112266 Wprowadź 11111 Przepisz odpowiedź tutaj:
Socjotechnika ( Dyre Wolf ) Źródło: http://www.theinternetpatrol.com/dyre-wolf-wire-transfer-malware-gets-around-2-factor-authentication/
Bankowość mobilna 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)
Overlay Źródło: Arxan/IBM - http://www.slideshare.net/ibmsecurity/securing-mobile-banking-apps/18
Malware = Arsenał narzędzi = Różne scenariusze webinject, form grabbing, cookie grabbing browser hooking on-the-fly webinjectform original server Przejmowanie sesji VNC WykrywaniePOS + Skanowanie pamięci Wykrywanie smardcard + próba odczytu Wykrywanieplatform bankowych + atak
Cele: Atakowane aplikacje 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: Zawężenie ataków 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
Metody działania 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
Podatności w mechanizmach autoryzacji PODATNOŚCI FUNKCJONALNE - PRZYKŁAD
Kluczowe operacje bez dodatkowej autoryzacji Np.: Zmiana nr do kodów SMS Parowanie nowego urządzenia autoryzacyjnego Zmiana szablonu płatności
Zmiana nr do SMS 29
Zmiana nr do SMS 30
Podatności w mechanizmach autoryzacji PODATNOŚCI NIEFUNKCJONALNE- PRZYKŁAD
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
Krok2: Użytkownik wprowadza dane autoryzujące POST /domestictransfer HTTP/1.1 task=send_response trndata.response=87567340 33
Nadpisanie danych transakcji POST /domestictransfer HTTP/1.1 task=send_response trndata.response=87567340 trndata.bnf_acc_no=66222200000006666666666 trndata.amount=1000.00 trndata.currency=eur 34
JAK WYBRAĆ SKUTECZNĄ METODĘ AUTORYZACJI?
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
Detekcja malware -Nie ma paneceumna wszystkie scenariusze ataków Scenariusz Przekierowaniena stronę atakującego Zmianatransakcji w przeglądarce Czyja stacjakomunikuje z bankiem? atakującego ofiary Czystrona jest zmieniana w przeglądarce? webinject, przekierowanie w DNS, strona serwowana lokalnie, 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
i jeszcze kilka (nieskutecznych?) pomysłów Wyblokujemyadres IP / charakterystykę przegladarki/ konta słupów! Zaciemnijmy kod stonyto 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 kilka bardziej skutecznych przykładów 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
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
WYGODA UŻYTKOWANIA KOSZT BEZPIECZEŃSTWO Sławek Jasek
Materiały dodatkowe www.securing.pl/materialy OWASP Transaction Authorization Cheat Sheet E-banking transaction authorization possible vulnerabilities, security verification and 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
Dziękuję, Zapraszam do kontaktu: wojciech.dworakowski@securing.pl @wojdwo