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.

1. Breaking the Bank
How to really test/annoy financial institutions

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. 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.

5. 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.

7. 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.

8. 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.

9. 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.

10. The goods
! Business logic flaws.
! Compliancy and financial regulation flaws.
! Bypassing validation routines.
! Outwitting the developer.

11. 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.

12. 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.

14. 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.

15. 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.

16. 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?

17. 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.

18. 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

19. 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!

21. 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.

22. 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.

23. 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.

24. Conclusion
! Get as much information about the app/platform as possible.
! Be methodical.
! Think ‘how can this be subverted?’
! Dare for more.