The document provides tips for testing the security of banking applications and frameworks. It suggests focusing on business logic flaws, such as manipulating functions to perform unintended tasks or bypass intended flows. Other tips include exploiting flaws in validation routines, manipulating currency values, and "outwitting" developers by finding ways to upload malicious files that may be executed by administrators. The goal is to identify vulnerabilities in these applications, as many offshore development teams and banks still have limited security knowledge.

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.