Hacking a Bank : 101

Advanced Banking Logic Vulnerabilities

Banks form the core of the economy. Today, Cyber Attacks are taking place daily and banks worldwide are affected.

In the past year, we have observed the security of various banks in terms of mobile application security. The security flaws described are those due to poor programming practices.

åThe Flaws can be elucidated as follows —

1. Replay Attack
2. Bypassing payment to a malicious beneficiary
3. Bypass Challenge Response in 2FA

In order to describe the attacks, consider a fictional bank, “SPDL Bank”. The customers of the bank are Alice and Bob, and the hacker is Eve. We want to reflect flaws in logic, and we use Charles Proxy to sniff SSL traffic between the mobile bank and the bank server.

A mobile banking application should allow the users to perform a subset of operations they can perform at the bank. Thus we lay down our assumptions of how the mobile banking application should actually function. While making a payment, a payment request should be valid only once. Similarly, transfers should be possible only to approved and trusted beneficiaries. Moving on to the challenge response, banks, as an added layer of security may ask for certain digits of a password (like 2nd,3rd and 7th digit), or a similar form of secondary authentication. Only upon responding with what was asked for, is the transaction processed.

1). Replay Attack

Suppose Alice is transferring money to Bob through the mobile banking application. The payment request should be valid only once. Any attempts to provide the same to the bank should be treated as invalid. In a practical scenario, suppose Alice is transferring 10$ to Bob legitimately. Bob can pair up with the hacker Eve, and can have replay the request 10 times. Thus 90$ is siphoned off from Alice’s account without her authorisation.

The defence against replay attacks is a nonce, or a secret between the client and the server as a function of time.

2. Bypass Payment Attack

As part of everyday business, Alice transfers 100 $ to Bob. This is a valid transaction since Bob exists in the list of approved beneficiaries.

The steps in completing a transaction are as follows-

Alice->Server : Transfer 100$ to Bob

Server-> Alice: OK ; Give me authentication numbers : 1 , 5 ,8

Alice->Server : Transfer 100$ to Bob ; Authentication 1:22 5:45 8:12

Transfer Successful

The Authentication characters can be considered to be Key Value pairs, where there are 16 Keys 1…16. There exist authentication digits for each of these

The Bypass payment hack happens in step 3. Eve, the adversary can tamper the request as

3. Alice -> Server : Transfer 10000$ to Eve ; Authentication 1:22 5:45 8:12

The server accepts it, and the transfer is successful. The problem is

1. Lack of check in step 3, if recipient is a beneficiary
2. State not maintained between step 1 and 3.

Thus money can be diverted to malicious entities.

3. Two Factor Authentication Bypass

As described in the transaction steps, authentication values need to be provided. The server asks for 3 values randomly out of 16, as a two factor auth.

An attack is changing the challenge response questions.

In Step 2, When the Bank asks for the 2FA

2. Server-> Alice: OK ; Give me authentication numbers : 1 , 5 ,8

Eve can tamper with the request response, and provide the 3 valid key value pairs she knows. Thus irrespective of what the server asks for, Eve can provide the key value pairs she knows, and the transaction still goes through. Thus she effectively bypasses the security mechanism since she can spoof each transaction.

Alice->Server : Transfer 100$ to Bob ; Authentication 1:22 2:99 3:10

This attack is an advanced one, and requires Eve to possess the session key. However once she has it by sniffing a live transaction, By combining vulnerability 2 & 3, She can create malicious transactions.

These flaws are related to the logic and may not fall under the banks threat model, as they assume the application to be in the trusted computing base. However, this assumption, may not hold true, given how easy it is to poison the phone certificate store through an application with misleading permissions.

Public Key Pinning would solve the problem in the sniffing, However there may be an adversary sniffing traffic on the first install and run of the banking application. In addition, these logic vulnerabilities would exist even in the web banking application.

At Spherical Defence (neural.ai), we are developing technology for banks to detect intrusion attempts real time using Deep Learning by learning grammar and the semantics of trusted communication.