Due to a logic flaw in Oracle's FlexCube Direct Banking application, it was possible to enumerate usernames, and then reset said user password, and transaction pin, granting full access to the victim user's account.
This would have (and probably has) allowed for a malicious attacker to drain any account that is behind the application. To make things worse, this is a shockingly simple vulnerability, which should have been picked up by simple bounds testing before application release.
This vulnerability has been patched in the April 2016 CPU, users of the banking application should update their sites as soon as possible. The developer was notified in January 2016. Non-authenticated, remote users can exploit this.
The banking application allows for users to reset their account user password, and account transaction password, through answering secret questions, such as the user’s favourite colour, mother’s maiden name, or place of birth. The first step in this process is providing the username. Depending on the configuration of the FlexCube application, this action also allows for user enumeration. Should the user exist on the system, the “secret” questions are displayed to the end user, else, a page stating that a password has been sent to the mobile number registered with the account. It is assumed that this is dependant on the configuration of the application, and if mobile two-factor authentication is enabled for accounts.
Assuming that you are able to guess an account name, the attacker can then answer the questions to gain access to the account. The quality of the default questions is quite low, which is one way of gaining access. Below is the request sent to the application attempting a password reset:
The application displays the password reset dialogue. At which point, the attacker can change the victim users account password, as well as the victims transaction password. Which is all you need to go around emptying all the accounts, from all the banks, which use Oracle Flexcube Direct Banking.
The initial attempt at patching this was only a partial fix, the application now requested that two answers had to be provided. However, an attacker could specify the same answer twice, say, for example, a user's favourite colour (red anyone?), and this was accepted as the two required answers.
This sort of flaw is simple enough to test for, and should have been picked up with normal bounds testing before product release. It makes you wonder how many more of these simple logic flaws exist within an application that controls a few million of any given currency!
As a footnote, if you don't get the title, shame on you. Watch SwordFish; it is an accurate depiction of how hacking and encryption works. (Or not).