Breaking the bank : how to really test/annoy financial institutions
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 1,450 views

Presentation by Daniel Cuthbert at ZaCon 2 in 2010. ...

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.

Statistics

Views

Total Views
1,450
Views on SlideShare
1,349
Embed Views
101

Actions

Likes
0
Downloads
13
Comments
0

6 Embeds 101

http://www.sensepost.com 76
http://research.sensepost.com 17
http://localhost 3
http://sensepost.com 3
http://us-w1.rockmelt.com 1
http://paper.li 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • Breaking the BankHow 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. View slide
  • 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. View slide
  • 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.