Breaking the bank : how to really test/annoy financial institutions


Published on

Presentation by Daniel Cuthbert at ZaCon 2 in 2010.

This presentation is about how to test banking applications/frameworks. The presentation begins with a brief overview of the security level of banking frameworks. Business logic and financial regulation flaws are discussed, how to use these flaws to test a framework are also discussed.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Breaking the bank : how to really test/annoy financial institutions

  1. 1. Breaking the BankHow to really test/annoy financial institutions
  2. 2. Who the hell am I?!   One of the original OWASP members from back in the day.!   Started the OWASP Testing Guide.!   Security old fart.
  3. 3. What the hell am I on about?!   Banking applications and frameworks are a pleasure to test.!   They often have many vulnerabilities lurking beneath the surface.!   Not many testers know how to wrangle the frameworks to get what they want.!   It makes you look great compared to other testers.
  4. 4. Quick background lesson!   Banking frameworks aren’t as confusing as you’d think.!   Often only a handful of frameworks in use globally.!   JAVA and .NET only (no-one really uses PHP, admit it!)!   SAP/IBM/FLEXCUBE (Oracle Financial Services) are the popular choice.!   Developed off-shore and customised in-house by dev teams onsite.
  5. 5. Overall security!   Most modern banking frameworks are relatively secure.!   Don’t expect Grossmann style attacks (a.k.a the net is falling, aaaaaaaah).!   They have large development teams and sexier budgets to fix issues.!   They’ve been tested heavily by many of the best for years.
  6. 6. So shall I give up now?!   Have faith. Most big development teams still have little, or none, knowledge about secure coding.!   Off-shore development is 5 years behind the west.!   There are loads of vulnerabilities still to be found.
  7. 7. Information gathering!   You need to have all the information before any testing starts.!   Understand regulatory requirements for market/application.!   Understand what Banking Standards are required for app.!   Obtain functional spec for all applications/frameworks to be tested.
  8. 8. The goods!   Business logic flaws.!   Compliancy and financial regulation flaws.!   Bypassing validation routines.!   Outwitting the developer.
  9. 9. Business logic flaws!   Most frameworks have logic flaws introduced during the development phase.!   Logic flaws require you to fully understand the application and function.!   They could be anywhere in the application, from authentication to validation.
  10. 10. Business logic flaws are:!   Legitimate requests with legitimate values.!   The ability to abuse a function to perform a task it was not meant to perform.!   The ability to bypass, or circumvent, the intended flow of an application.
  11. 11. Authentication business logic flaw!   Banking app has 2-stage authentication: !  first page prompts for userID/pass and passcode (4-6 digit) !  second page asks for 3 random chars of memorable word.!   This is ripe for a logic flaw attack.
  12. 12. Authentication business logic flaw!   Enter a valid username and password combo and press enter, the 2nd phase always asks for the same 3 random chars. (good practice).!   Enter a valid username and incorrect password and press enter (don’t add any memorable info from drop-down). The app asks for different chars from the memorable password.!   We can now determine when a valid password combo has been entered by the behavior of the 2nd-phase page.
  13. 13. Business logic flaws!   Use and Abuse cases are your friend: !   how can an attacker subvert this function? !   what are the maximum amounts allowed? !   can the amount be a negative amount? !   can you manipulate source and destination accounts?
  14. 14. Compliancy and financial regulation flaws!   Banking apps are strictly controlled by various financial laws.!   These laws protect the consumer from being ripped off.!   Testing for these flaws requires knowledge of how .net/JAVA handles monetary values.!   NaN/Infinity and Exponential Notation are your friend.
  15. 15. Rounding errors!   Float and double data types are based on IEEE754.!   This standard acknowledges shortcomings relating to rounding errors.!   System.out.println(3.00 - 1.10); !  result is actually 1.89999999999999999
  16. 16. Bypassing validation routines!   The use of Nan/Infinity and exponential notation is key to bypassing validation routines.!   App has regulatory requirement to only allow a transaction under 10,000 per day. Validation checks input amount for <6 characters. Anything more is denied.!   What about 9E1 or 0.99E+6 (all valid)!   Test all listed reserved words in numeric fields!
  17. 17. Currency manipulation!   Currency functions are easy to manipulate: !  often they obtain the value at the start of the function. !  change the value to see if it’s accepted. also change currency value. !  bypass currency restrictions using exponential notation.
  18. 18. Outwitting the developer!   Most developers dabble with security but often don’t fully understand implications.!   Retail banking applications have functions to allow customers to contact bank staff. Often these allow uploads (strictly controlled).!   I’ve yet to see any upload function checking content. This is ripe for abuse.
  19. 19. Malicious uploads!   Create malicious PDF. (use Metasploit, any Adobe vuln is useful).!   Log into banking app and contact administrators, attach PDF and send.!   Sit and wait for admin to launch PDF (which has been cleared by the framework)!   Control admin workstation.
  20. 20. Conclusion!   Get as much information about the app/platform as possible.!   Be methodical.!   Think ‘how can this be subverted?’!   Dare for more.