Presentation from OWASP AppSec EU 2016 Rome All internet banking applications are different but all of them share many common security features which are very specific to this domain of web applications, such as: • transaction limits, • notifications via SMS or e-mail, • authorization schemes, • trusted recipients, • two-factor authentication and transaction authorization, • pay-by-links, • communication channel activation (e.g. mobile banking or IVR), It is not very rare that these safeguards are incorrectly implemented leaving the internet banking application vulnerable. Last year at AppSec EU I was talking about common vulnerabilities in e-banking transaction authorization. As a follow-up to this presentation, OWASP Transaction Authorization Cheat Sheet was published and gained some attention from banks, developers and testers. This year, I want to continue and expand this work to other security mechanisms which are specific and common to internet banking applications. During my presentation I want to show some common mistakes made during implementation of the abovementioned internet banking safeguards. As a follow-up, I am planning to expand OWASP Transaction Authorization Cheat Sheet to Internet Banking Cheat Sheet which will include guidelines for secure implementation of all security mechanisms common to contemporary internet banking applications. At the end of my presentation, I also want to discuss the idea of expanding key OWASP materials such as ASVS, Testing Guide, Development guide by adding appendixes specific to group of applications (such as internet/mobile banking, e-commerce, etc.).

1. Wojtek Dworakowski, @wojdwo
SecuRing
Internet banking safeguards
vulnerabilities

2. #login
Wojtek Dworakowski
SecuRing (since 2003)
OWASP Poland Chapter Leader
2

3. Agenda
• Intro
– Banks vs attackers – current state, common security features
• Vulnerabilities and best practices
– transaction authorization vulns, trusted recipients feature
abuses, transaction limit bypass, user auth mistakes…
• PSD2 – future changes to internet banking security
• Should OWASP publish guidelines for specific
application domains (e.g. internet banking)?
3

4. Extreme sports and
IT security
4
When I hit the ground I want my
gear not to fail
Same applies to internet banking
security features in case of
attack

5. BANKS VS ORGANIZED (?) CRIME
5

6. Common attack patterns
• Malware
– Web inject
– Keylogger + remote desktop
– Clipboard manipulation
• Vulnerability exploitation
– Infrastructure
– Application
– Libraries / frameworks !

7. WebInject
7
source: http://blog.trendmicro.com/trendlabs-security-intelligence/winning-the-online-banking-war/

8. Clipboard (or memory) manipulation
8Source: CERT Poland
http://www.cert.pl/news/8999/langswitch_lang/en

9. Clipboard (or memory) manipulation
9Source: CERT Poland
http://www.cert.pl/news/8999/langswitch_lang/en
More info: https://www.cert.pl/en/news/single/vbklip-2-0-no-
clipboard-but-matrix-like-effects/

10. Server vulnerability exploitation
• In late 2015 one
of Polish banks
was pwned
(outdated
components)
• Intruder was
able to modify
transactions
source: www.zaufanatrzeciastrona.pl
~ 40 000 eur

11. Server vulnerability exploitation
Source: www.zaufanatrzeciastrona.pl
• In late 2015 one
of Polish banks
was pwned
(outdated
components)
• Intruder was
able to modify
transactions
~ 92 000 eur

12. Server vulnerability exploitation
Source: www.zaufanatrzeciastrona.pl
English writeup:
https://www.linkedin.com/pulse/online-banking-owned-single-
attacker-wojciech-dworakowski

13. How banks mitigate these risks?
• Multi-factor authentication
• Transaction authorization
– Trusted recipients
• Authorization schemes
• Transaction limits
• Notifications (SMS, e-mail, …)
• Channel activation
– Mobile device authorization
img src: http://nuvali.ph/see-and-do/sports/mountain-bike-trails/

14. What if these protections will fail?
14
Img src: www.mtb-downhill.net

15. SECURITY FEATURES
VULNERABILITIES
BEST PRACTICES
Details matter
15

16. Transaction authorization
16

17. 17
Source:aliorbank.pldemo

18. 18
Image: Alior Bank
Domestic transfer: Recipient
account 22XXXX222 amount
77.34 EUR authorization
code: 36032651

19. Vuln examples (functional)
19
Domestic transfer from account
99XXXX890 amount 1.00 EUR
authorization code: 78537845

20. Vuln examples (non functional)
POST /domesticTransfer HTTP/1.1
task=APPROVE_TRN
trnData.acc_id=910458
trnData.bnf_name=TELECOM+OPERATOR+Ltd
trnData.bnf_acc_no=PL99111100000000001234567890
trnData.amount=1.00
trnData.currency=EUR
trnData.title=invoice+123456
20
Step 1: User enters transaction data

21. Vuln examples (non functional)
Step 2: User enters authorization code
21
POST /domesticTransfer HTTP/1.1
task=SEND_RESPONSE
trnData.response=87567340

22. Vuln examples (non functional)
22
POST /domesticTransfer HTTP/1.1
task=SEND_RESPONSE
trnData.response=8756734
trnData.bnf_acc_no=PL66222200000000006666666666
trnData.amount=1000.00
trnData.currency=EUR
Overwrite transaction data in step 2

23. Transaction authorization
– best practices
Thx !
• Steven Wierckx
• Adam Zachara
• Adam Lange
• Sławomir Jasek
• Andrzej Kleśnicki
• Sven Thomassin
• James Holland
• Francois-Eric Guyomarch
• Milan Khan
23

24. Trusted recipients
24

25. Trusted recipients
• The process is very error prone
• Developers are using same forms and are slightly
modifying logic to do normal and “trusted” transfers

26. Vuln example #1: make it trusted
1. Send unauthorized transfer
2. Add some magic
26
transferData.trusted=Y

27. Vuln example #2: overwrite data
1. Create the transfer from trusted recipient template
2. Add (or overwrite) transfer parameters during sending
27
transferData.beneficiary_acc_no=66222200000000006666666666
transferData.beneficiary_adr=Changed+Address+8%2F5

28. Vuln example #3: business logic error
trusted recipient
Allice Eva
Any account
trusted recipient
no additional authorization needed
Yes – it’s totally twisted… but it’s real
Read more: https://www.linkedin.com/pulse/online-banking-
owned-single-attacker-wojciech-dworakowski
Intruder Money mule

29. Trusted recipients
Recommendations
• Decision should be taken server-side
• Carefully control transfer state
• Do not allow additional params
• Control gate (go | not go) at the end of the process
29

30. TRANSACTION LIMITS

31. Limit examples
• transfers / card operations
• cash / online
• one-time amount
• daily / weekly sum
• daily transactions number
• business parameters
(e.g. max/min deposit amount)
• …
• If the limit is exceeded:
– forbid operation
– ask for additional credentials
– call customer to verify the
transaction
– …

32. Vuln example #1
• Simply – change limits
• Sometimes it doesn’t require additonal authorization ;)
32

33. Vuln example #2: overwrite at confirmation
Enter transaction data below limits
Send form  Limits are validated  Confirmation form
33
POST /retail/transfer
task=APPROVE_TRANSFER
trn_amount=1000000

34. Transaction limits - requirements
• Transaction limits change should require additional
authorization (SMS code, one time token, challenge-
response, …)
• Do not allow additional params
• Control gate (check limits) also at the end of the process
34

35. NOTIFICATIONS

36. Vuln examples
• Simply change phone number (or email)
• …or disable / reconfigure notifications
• Sometimes it doesn’t require additonal authorization
36

37. Notifications - requirements
• Notification change should require additional authorization
(SMS code, one time token, challenge-response, …)
• User should be notified about:
– wrong authentication attempt
– (even better) about positive authentication
– transaction (SUM) above defined limit
– activation of new access channel (mobile, IVR) or new device
pairing
– password or phone number change
37

38. USER AUTHENTICATION

39. We are teaching
users to have
strong passwords
Source: http://xkcd.com/936/
28
characters

40. Passphrases and password managers obstacles
• Limited length
• Limited chars
– Extreme case:
8 digits
• Masked
passwords
Source: Data collected by SecuRing during research on security
features used by online banking in Poland (17 banks)
28
characters

41. Authentication - requirements
• Functional
– Require strong password
– Don’t limit use of passphrases !
– User should be notified about wrong/positive authentication
– Visible info about last good/bad authentication
• Take care about password recovery path!
41

42. FUTURE – CRASH COURSE IN PSD2
42

43. PSD2
Payment Services Directive (revised)
Major topics:
• SCA – Strong Customer Authentication
• PIS – Payment Initiation Service
• AIS – Account Information Service
Scope:
• Mandatory for all „Payment Service Providers”

44. Strong Customer Authentication (SCA)
‘strong customer authentication’ means an authentication based
on the use of
• two or more elements categorised as
– knowledge (something only the user knows),
– possession (something only the user possesses)
– inherence (something the user is)
• that are independent, in that the breach of one does not
compromise the reliability of the others,
• and is designed in such a way as to protect the confidentiality
of the authentication data;
44

45. Payment Initiation Service
Icons made by Madebyoliver and Freepik from www.flaticon.com 45
Merchant
Payment
Initiation
Service
Provider
User’s
Bank
Merchant’s
Bank
Bank’s API
Scraping
old way
new way

46. PIS – scraping example
46

47. Account Information Service
• online service to provide consolidated information on one
or more payment accounts held by the payment service
user with either another payment service provider or with
more than one payment service provider;
• Examples:
– Personal finance management
– Automated creditworthiness and financial situation analysis
47

48. Account Information Service
Icons made by Madebyoliver and Freepik from www.flaticon.com 48
Account
Information
Service
Provider
Bank’s API
Scraping

49. SCA / PIS / AIS
• Possible implementation errors
cosequences
– Payment data change
– Unauthorized access to user’s data
(mass scale?)
– Authentication bypass
– …
49

50. PSD2 - current state
• EBA will issue Regulatory Technical Standard (Jan 2017)
– Until then, current status quo should be maintained
• EBA released Discussion Paper, call for comments was
closed 8 Feb 2016
– My AppSec related comments:
https://www.linkedin.com/pulse/strong-customer-authentication-
secure-communication-psd2-dworakowski
50

51. SUMMARY & WHAT NEXT?
51

52. Implementation errors = vulnerabilities
52
• If security controls are implemented with vulnerabilities
then they are useless
• Vulnerable safeguards cause false sense of security

53. Precise requirements
53

54. OWASP to the rescue !
• Common problems:
– SQLi
– XSS
• ..or features
– Authentication, 2FA
– Transaction authorization
• Cheat Sheet Series
• ASVS
• Dev Guide
• SKF
• …
54

55. OWASP to the rescue ?
Common application business
domains (and features)
• online banking / mobile banking
• PIS / AIS (PSD2)
• e-commerce
• SCADA
• social networking
• company webpage
• …
?
Shouldn’t we have
common requirements
for common app
domains?
55

56. Internet banking - proposal
• Online Banking Cheat Sheet
• ASVS „module”
• Dev Guide chapter
56
Let me know if you want to help !

57. Q & A
57
@wojdwo
wojtekd@securing.pl
http://www.securing.pl/en