Most of the modern internet or mobile banking applications use some sort of second factor, such as TAN lists, SMS codes, time-based OTP tokens, etc. to let user verify banking operations and to protect against MitM or malware attacks. During security tests in pre-production, it often turns out that tested banking systems have serious security flaws regarding implementation of transaction authorizations mechanisms, that (if not detected and corrected) could allow attacker to bypass or weaken those safeguards. During this presentation I would like to throw light on transaction authorization mechanisms security. The agenda will include: • Examples of possible vulnerabilities, which could allow to bypass those security mechanisms. • Resistance of selected transaction authorization mechanisms to common banking malware attacks. • Suggested best practices regarding implementation of transaction authorization.

1. Wojtek Dworakowski, @wojdwo
SecuRing
E-banking transaction
authorization
Common Vulnerabilities, Security
Verification and Best Practices for
Implementation

2. Wojtek Dworakowski
OWASP Poland Chapter Leader
Managing partner
- Pentests
- AppSec consultancy
2

3. Agenda
• Intro
– Why additional authorization?
– Authorization methods
• Vulnerabilities + best practices
– by example
• Summary and future goals
3

4. Why this topic?
• Threats: malware, password hijacking, …
• Risk: wire transfer frauds
• Banks are implementing 2nd factor
transaction authorization to lower the risk
• During pentests we have found that
implementation is often far from perfect
4

5. Operation authorization
5
Source:aliorbank.pldemo

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

7. 7
Image: Barclays Bank

8. Operation authorization
methods
8
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.co
m
Image: wikipedia.org
Image: wikipedia.org
• TAN / indexed
• Time based OTP
• C/R token
• SMS code
• phone-back
• „digital signature”
• smart cards
• mobile tokens
• unconnected card reader
• barcode scanning
• colorfull pattern scanning
• …

9. BUT SOMETIMES
IMPLEMENTATION
FAILS
IDEAS ARE
GREAT
Image: murator.pl Image: flickr mjaniec

10. VULNERABILITIES AND BEST
PRACTICES – BY EXAMPLE

11. Image: archemon.com

12. What’s wrong with these?
Domestic transfer to John Doe
amount 1000 EUR authorization
code: 36032651
Authorization code: 78537845
Domestic transfer from account
99XXXX890 amount 1.00 EUR
authorization code: 78537845
Images: wikipedia.org

13. Vulnerability
• User doesn’t know what he is authorizing
13
Recommendations
• Transaction authorization method should
allow user to verify significant transaction
data
– (e.g. for money transfer - target account and
amount).

14. Image: pinterest.com

15. SMS number change
15

16. SMS number change
16

17. Significant operations without
additional authorization
• SMS number change
• “Pairing” of new authorization device
• New signing key
• Predefined transfer template edit
• Deposit termination + possibility to choose
any target account

18. Recommendation
• Any significant operation should enforce
authorization
• Change of authorization credentials
(or method) should be authorized using
current authorization credentials
18

20. Step 1: User enters transaction data
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

21. Step 2: User enters authorization data
21
POST /domesticTransfer HTTP/1.1
task=SEND_RESPONSE
trnData.response=87567340

22. What could possibly go wrong?
Overwrite transaction data in step 2
22
POST /domesticTransfer HTTP/1.1
task=SEND_RESPONSE
trnData.response=8756734
trnData.bnf_acc_no=PL66222200000000006666666666
trnData.amount=1000.00
trnData.currency=EUR

23. Recommendations
• Modification of transaction data
 Restart authorization process

24. Image: www.humor

25. Transaction “signing” using
SMS code
25
transaction data:
bnf_acc_no = 22222
amount = 1
data to sign:
text=74726E4461…
SMS code
sha1(text, sms)
confirmation
user server
OK
phone

26. What could possibly go wrong?
26
transaction data:
bnf_acc_no = 22222
amount = 1
data to sign:
text=74726E4461…
SMS code
user server
OK

27. What could possibly go wrong?
27
transaction data:
bnf_acc_no = 22222
amount = 1
data to sign:
text=74726E4461…
SMS code
sha1(text, sms)
confirmation
user server
transaction data:
bnf_acc_no = 66666
amount = 1000
data to sign:
text=678993662…
OK
• Malware replies step
1 before user enters
code
• changes trn data
• sends signature with
new trn data

28. Recommendations
• Modification of transaction data
 Restart authorization process
• Application should control which
transaction state transitions are allowed.
28

30. Malware VS operation auth ex.1
Password:
Response:
ID: 7890 2341
Image: iss.thalesgroup.com

31. Malware VS operation auth ex.1
Password:
Response:
ID: 4321 5781
Image: iss.thalesgroup.com
Wrong password, please re-enter password and
token response
Victim was just
tricked to authorize
the transaction

32. Recommendations
• Transaction authorization method should
allow user to verify transaction data
• Different methods
– user authentication
– transaction authorization
• or user should be able to easily distinguish
between these two operations
32

33. Image: /justsomething.co

34. Malware VS operation auth ex.2
• Authentication
34
Image: alibaba.com

35. Malware VS operation auth ex.2
• Operation authorization
– same method as authentication
35
Sniff PIN, automate logon+transfer
– In real life: sniffer + “remote desktop”

36. Recommendations
• Authorization process should require
user’s physical intervention
36
Image: yubico.com

37. Future work
• Cheat sheet for developers / testers
• OWASP ASVS extension
• Testing Guide / Code Review Guide
extension
• Help appreciated ;)
37

38. Contact
@wojdwo
wojciech.dworakowski@securing.pl
http://www.securing.pl/en
38