appsec eu 2015 - e-banking transaction authorization - possible vulnerabilities, security...
TRANSCRIPT
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
http://www.securing.pl/en
38