breaking the bank : how to really test/annoy financial institutions
DESCRIPTION
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.TRANSCRIPT
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. �