Successfully reported this slideshow.

AppSec EU 2015 - E-banking transaction authorization - possible vulnerabilities, security verification and best practices for implementation

5

Share

1 of 38
1 of 38

AppSec EU 2015 - E-banking transaction authorization - possible vulnerabilities, security verification and best practices for implementation

5

Share

Download to read offline

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.

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.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

AppSec EU 2015 - E-banking transaction authorization - possible vulnerabilities, security verification and best practices for implementation

  1. 1. Wojtek Dworakowski, @wojdwo SecuRing E-banking transaction authorization Common Vulnerabilities, Security Verification and Best Practices for Implementation
  2. 2. Wojtek Dworakowski OWASP Poland Chapter Leader Managing partner - Pentests - AppSec consultancy 2
  3. 3. Agenda • Intro – Why additional authorization? – Authorization methods • Vulnerabilities + best practices – by example • Summary and future goals 3
  4. 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. 5. Operation authorization 5 Source:aliorbank.pldemo
  6. 6. 6 Image: Alior Bank Domestic transfer: Recipient account 22XXXX222 amount 77.34 EUR authorization code: 36032651
  7. 7. 7 Image: Barclays Bank
  8. 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. 9. BUT SOMETIMES IMPLEMENTATION FAILS IDEAS ARE GREAT Image: murator.pl Image: flickr mjaniec
  10. 10. VULNERABILITIES AND BEST PRACTICES – BY EXAMPLE
  11. 11. Image: archemon.com
  12. 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. 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. 14. Image: pinterest.com
  15. 15. SMS number change 15
  16. 16. SMS number change 16
  17. 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. 18. Recommendation • Any significant operation should enforce authorization • Change of authorization credentials (or method) should be authorized using current authorization credentials 18
  19. 19. 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
  20. 20. Step 2: User enters authorization data 21 POST /domesticTransfer HTTP/1.1 task=SEND_RESPONSE trnData.response=87567340
  21. 21. 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
  22. 22. Recommendations • Modification of transaction data  Restart authorization process
  23. 23. Image: www.humor
  24. 24. 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
  25. 25. What could possibly go wrong? 26 transaction data: bnf_acc_no = 22222 amount = 1 data to sign: text=74726E4461… SMS code user server OK
  26. 26. 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
  27. 27. Recommendations • Modification of transaction data  Restart authorization process • Application should control which transaction state transitions are allowed. 28
  28. 28. Malware VS operation auth ex.1 Password: Response: ID: 7890 2341 Image: iss.thalesgroup.com
  29. 29. 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
  30. 30. 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
  31. 31. Image: /justsomething.co
  32. 32. Malware VS operation auth ex.2 • Authentication 34 Image: alibaba.com
  33. 33. Malware VS operation auth ex.2 • Operation authorization – same method as authentication 35 Sniff PIN, automate logon+transfer – In real life: sniffer + “remote desktop”
  34. 34. Recommendations • Authorization process should require user’s physical intervention 36 Image: yubico.com
  35. 35. Future work • Cheat sheet for developers / testers • OWASP ASVS extension • Testing Guide / Code Review Guide extension • Help appreciated ;) 37
  36. 36. Contact @wojdwo wojciech.dworakowski@securing.pl http://www.securing.pl/en 38

×