Breaking the Bank �How to really test/annoy financial institutions�

Who the hell am I?�

!   One of the original OWASP members from back in the day.�

!   Started the OWASP Testing Guide.�

!   Security old fart.�

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

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

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

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

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

The goods�

!   Business logic flaws.�

!   Compliancy and financial regulation flaws.�

!   Bypassing validation routines.�

!   Outwitting the developer.�

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

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

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

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

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?�

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

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 �

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!�

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

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

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

Conclusion�

!   Get as much information about the app/platform as possible.�

!   Be methodical. �

!   Think ‘how can this be subverted?’�

!   Dare for more. �