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.
Semelhante a AppSec EU 2015 - E-banking transaction authorization - possible vulnerabilities, security verification and best practices for implementation
Semelhante a AppSec EU 2015 - E-banking transaction authorization - possible vulnerabilities, security verification and best practices for implementation (20)
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
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).
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
19.
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
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
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