How To Rob An Online Bank (and Get Away With It)

Mitja Kolsek 

Evolution of online banking attacks

For as long as online banking has been in effect, attackers have been trying to directly attack users. Phishing and client.side attacks are the past, present and future. More of these attacks are becoming focused on business customers.

Goal: Identity Theft

Attacks against personal users are interesting, but corporations are a much more lucrative target. It’s not unusual to see a corporation sending millions of dollars in transfers, and as such it’s easier to make money. However with corporate banking you need to be more targeted to find who in an organisation is responsible, and who should be targeted.

Digital certificates is a common method to locate the responsible party. These certificates are assigned to users for online corporate banking, and are often listed in online repositories. The data on these certificates often includes name, email and enough details to target a corporation.

Goal: Exploitation of Application Flaws

The attacker usually has no knowledge of the flaws in the remote system. This gives the bank a window of opportunity to detect the attacker as he probes systems. The bank is a perfect target, as it’s where all the money is, and there’s no messy social engineering required.

Direct Resource Access

Online banking is mostly web-based, even if there is a thick client or mobile application, in the backend communications you often see HTTP(S).

https://bank.com/banking?id=11223344

Yes, these things are seen in the wild… see Citi bank as an example.

Seen in the wild:

• ID’s and Account numbers in the URL
• Base64 encoded IDs and Account numbers
• Encrypted strings in the URL
• Brute-Force the key to find the ID or Account Number

Depending at what phase the server-side validation takes place, this can bypass protections. If the bank only checks the details server-side at the first phase, and you alter the data in the validation phase taking place afterwards, you can bypass systems.

Negative Numbers

Surprisingly often overlooked. Simple code validation can fail. If it’s checking the balance is more than the transfer, then a negative amount will also pass this check.

Creating money out of thin air

Instead of transferring a minus amount to another user, how about transferring it to another account we own. If we use a savings account that cannot go into negative, then what happens in the background. If there is a logic failure then the negative transfer will create money in the initial account.

Bypassing Limit Checks

Code is written by people, and people make errors. If an attacker can transfer between 2 accounts, creating a massive minus in 1 account and a huge profit in another, the attacker can cash out one account and never repay the debt on the other.

HTTP Parameter Pollution

Example:

POST /transfer

source=1&dest=2&amount=100

Checks are then performed on this to validate the source is owned by the user and the amount is within limits.

HPP Example:

POST /transfer

source=1&dest=2&amount=100&source=42

If the backend is susceptible to HTTP Parameter Pollution then the second phase of the transfer may take the second provided source (dependent on the backend code)

SQL Injection

Banks almost always say SQL Injection won’t be possible on their systems… however they’re often found.

Forging Bank’s Digital Signatures

Banks are very enthusiastic about digital signatures for various reasons, including the legal validation of digitally signed transactions and agreements.

In a transaction the user signs an agreement and returns it to the bank server for them to counter sign. However, what if the contents on the agreement is altered at the client side (either textually or the values).

Server-Side Code Execution

Not a specific banking vulnerability. However just as effective.

Examples include:

• JAVA Code Execution (JBoss bug in 2010)
• PHP Code Injection
• Shell Argument Injection

Getting rich without breaking the law

Rounding and currency exchange

Normally you end up loosing money when exchanging currency. However what happens if your transfer results in less than 0,01 cent. In these cases it will often be rounded up to 0,01 and you will make money… not much, but some.

Example:

Convert €100 into $136,40

Convert $0.01 into €0.01 until your $ are all exchanged

You then have €136,40

Banks will notice this… 1000’s of transactions will trigger flags and they won’t be happy with you.

Countermeasure –> Don’t let users exchange less than €1

Getting away with it

Why should we care, we’re not bank robbers… but when the customer says “You’d never get away with it” you need to have an answer.

Avoiding Detection

In detecting these vulnerabilities they will make noise and risk detection. In testing attacks they may trigger alarms

Solution –> User in the middle (hiding behind a user)

Breaking the money trail

Transferring money from bank to bank is still traceable. Attackers need to actually get the physical money out

Solution –> Money mules, BitCoins, WebMoney

Perfect Crime: Print new money, don’t let anybody know

Nobody lost anything, so nobody to complain

Possible through some of the attacks shown earlier. Create fake transaction history

New Functionalities

New technologies are a great thing for banks, but also for attackers.

Increase in automated loans and stock trading open up banks to new attacks.

Links :

• How To Rob An Online Bank And Get Away With It –> Overview