appsec eu 2015 - e-banking transaction authorization - possible vulnerabilities, security...

Wojtek Dworakowski, @wojdwo SecuRing

E-banking transaction authorizationCommon Vulnerabilities, Security Verification and Best Practices for Implementation

2

Wojtek Dworakowski

OWASP Poland Chapter Leader

Managing partner- Pentests- AppSec consultancy

3

Agenda

• Intro– Why additional authorization?– Authorization methods

• Vulnerabilities + best practices– by example

• Summary and future goals

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

5

Operation authorization

Sou

rce:

alio

rban

k.pl

dem

o

6

Image: Alior Bank

Domestic transfer: Recipient account 22XXXX222 amount 77.34 EUR authorization code: 36032651

7

Image: Barclays Bank

8

Operation authorization methods

Image: www.rsa.com

Image: www.newtechusacom

Image: iss.thalesgroup.com

Image: emue.comDomestic transfer to account 99XXXX890 amount 1.00 EUR authorization code: 36032651

Image: vasco.com

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• …

BUT SOMETIMES IMPLEMENTATION

FAILS

9

IDEAS ARE GREAT

Image: murator.pl Image: flickr mjaniec

VULNERABILITIES AND BEST PRACTICES – BY EXAMPLE

10

Example #1

Image: archemon.com

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

Recommendations• Transaction authorization method should

allow user to verify significant transaction data– (e.g. for money transfer - target account and

amount).

Example #2

Image: pinterest.com

15

SMS number change

16

SMS number change

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

Example #3

20

Step 1: User enters transaction data

POST /domesticTransfer HTTP/1.1task=APPROVE_TRNtrnData.acc_id=910458trnData.bnf_name=TELECOM+OPERATOR+LtdtrnData.bnf_acc_no=PL99111100000000001234567890trnData.amount=1.00trnData.currency=EURtrnData.title=invoice+123456

21

Step 2: User enters authorization data

POST /domesticTransfer HTTP/1.1task=SEND_RESPONSEtrnData.response=87567340

22

What could possibly go wrong?

Overwrite transaction data in step 2

POST /domesticTransfer HTTP/1.1task=SEND_RESPONSEtrnData.response=8756734

trnData.bnf_acc_no=PL66222200000000006666666666trnData.amount=1000.00trnData.currency=EUR

Recommendations

• Modification of transaction data Restart authorization process

EXAMPLE #4

Image: www.humorsharing.com

25

Transaction “signing” using SMS code transaction data:

bnf_acc_no = 22222amount = 1

data to sign:text=74726E4461…

SMS code

sha1(text, sms)

confirmation

user server

OK

phone

26

What could possibly go wrong?transaction data:bnf_acc_no = 22222amount = 1

data to sign:text=74726E4461…

SMS code

user server

OK

27

What could possibly go wrong?transaction data:bnf_acc_no = 22222amount = 1

data to sign:text=74726E4461…

SMS code

sha1(text, sms)

confirmation

user servertransaction data:bnf_acc_no = 66666amount = 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.

Example #5

29

Malware VS operation auth ex.1

Password:

Response:

ID: 7890 2341

Image: iss.thalesgroup.com

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

Example #6

Image: /justsomething.co33

34

Malware VS operation auth ex.2

• Authentication

Image: alibaba.com

PIN

35

Malware VS operation auth ex.2• Operation authorization

– same method as authentication

PIN

Sniff PIN, automate logon+transfer– In real life: sniffer + “remote desktop”

36

Recommendations

• Authorization process should require user’s physical intervention

Image: yubico.com

37

Future work

• Cheat sheet for developers / testers• OWASP ASVS extension• Testing Guide / Code Review Guide

extension• Help appreciated ;)

Contact@wojdwo

wojciech.dworakowski@securing.pl

http://www.securing.pl/en

38