Security Threats to Financial Web Applications

First, a gentle reminder and disclaimer: Testing the security of an application or a system, without obtaining prior approval from its owner(s) is unethical, illegal, and can easily land you in jail. You may also be legally obliged to reimburse the financial and/or reputation losses that your activities have caused. Do not try any of the techniques in this blog post, unless you are a trained professional and are acting under the pre-approved terms and conditions of a formal penetration test engagement. All the information in this blog post is provided “as is”. We have sanitized the content to protect the security of systems. The author of this blog post (Reha Esen) or the company (Sistematik OÜ) are not responsible for any damages.

APT versus Logic Errors

In an APT against a bank, the cyber criminals would first have to identify a critical vulnerability, which would let them obtain a foothold into the internal network. This would be followed by lateral movement and privilege escalation, until they reach a payments system or locate a credit card database. This may require months of work, during which the execution must be flawless. Security products should be bypassed and alarms should be avoided. Doing all that without a vital mistake is difficult, expensive, and it requires patience. A zero day or two might help, surely, but they are difficult to discover or expensive to purchase. And if all of this goes well, hackers might hit the jackpot in one big shot. Even then, there comes the problem of taking out all the cash and laundering it.

As much as all this would sound attractive to a nerd, an APT attack is just way too expensive, too laborious, perilous, and unnecessary from a tactical perspective.

Cyber criminals are known for being rational and result-oriented. They are exceptionally effective at discovering the shortest path to money. Exploiting logic errors in public-facing financial systems provide them a tremendous potential. Some banks may not be aware of the problem, but a detailed examination of FX, time deposit account and mutual fund transactions can reveal long-running, well coordinated salami-attack campaigns.

So, let’s dive into the logic errors and fraud controls in internet banking applications.

Two Types of Financial Transactions – An Important Distinction

Let’s start with a simple categorization, which will lay some foundation for our thinking.

If a burglar would break into your house and steal your big screen tv, you would notice it right away, right? What if the burglar breaks into a giant warehouse where they never count the inventory properly? What if the burglar steals one TV every single day, without being noticed for years?

Some banking transactions take place between two customers. A money transfer transaction, for example, withdraws from one customer’s account and deposits into another’s. If a hacker could discover a critical bug that allows withdrawing from arbitrary accounts, the account owner would notice that and inform the bank right away.

There is a different transaction type, the one where the counterparty is not another client, but the bank itself. When you perform an FX sell, to exchange your EUR for USD, the bank buys your EUR and sells you its own USD. You perform a currency exchange with the bank.

Why is transaction counterparty important?

Most bank staff perceive Internet banking as a “secure” channel, because it lacks human involvement. They assume that there’s no room for human error or ill intent. These systems are also thoroughly tested, therefore the data that comes out should be accurate.

This thinking leads the staff members of accounting, internal control and other business departments to not performing reconciliation on internet banking transactions. However, the lack of human scrutiny makes this channel a suitable target for cyber crime.

It makes sense for cybercriminals to target the bank itself, instead of its customers. Most customers properly examine their account balances and transactions, but unfortunately most of the time banks trust technology too much, and don’t check their own accounts.

Attack Categories

I break down the logic errors into 5 categories. This approach gives the tester a structure and helps to organize the scenarios better.

Ownership Checks are designed for verifying the parameters that a client submits, to make sure they point to the client’s own products. A money transfer transaction uses the following parameters:

• Sender account number – money will be withdrawn from this account
• Recipient account number – money will be sent to this account
• Amount
• Value date – used for creating a standing order for a future date

The hacker logs into the internet banking with his own account and clicks the money transfer transaction. He inputs the parameters listed above, but right after hitting the submit button, he intercepts his own traffic. Intercepting the traffic allows changing the value of any submitted parameter, before the packet leaves his PC. He overwrites the sender account with another customer’s account number. This way, the hacker will make the transfer from someone else’s account, if the backend does not perform ownership checks.

Attackers can also access other clients’ data through internet banking systems. Lack of robust ownership checks can permit disclosure of account and credit card statements, or similar financial data. Such critical information can aid the attackers to identify high-value clients and boost the payoff of a targeted attack.

Circumventing Time-based Checks: Internet Banking may enforce a certain time limitation for completing a certain transaction. FX markets move too quickly, therefore the exchange rates change multiple times each second. This would prevent users from completing a transaction successfully because the values they see on the screen will be invalid before they can complete the transaction. EUR 100 will no more be equal to USD 118.53 in a few seconds. To resolve this problem, the bank fixes an exchange rate for you, for a limited time, like a minute or two.

Then let’s ask this: what if it is possible to circumvent the implemented time-based controls? If a hacker could fix an exchange rate indefinitely, they would wait for the market prices, and if the fixed exchange rate is more favorable compared to the current market price (buying more USD with his EUR), they would complete the transaction. Otherwise, they would just cancel the transaction at no cost.

Implementing the time-based controls on the client-side, as well as requests to extend the timeout being prone to replay attacks are the major causes for circumvention of time-based controls.

Parameter Tampering is when a malicious user changes the parameter values of a transaction, so they perform the transaction with an undue gain for them. An easy example is an attacker submitting a negative amount in a money transfer transaction. This would allow transferring money from the recipient’s account to their own account.

A more sinister example is in credit card transactions. Installments on credit card purchases is getting ever more popular since it is a practical “easy finance” option. Purchasing a USD 2,000 laptop is easier, if you will pay USD 200 each month, for the next 10 months. However, if the number of installments is a client-side parameter (and I usually see multiple installment options in online stores), submitting 1,000,000 as the number of installments would create a million-month payment plan, with 0.2 cents each, which the system would obviously round down to zero. While the card limit will reduce by USD 2,000, the actual payment will never take place.

TOCTOU (Time of Check, Time of Use) vulnerabilities are most frequently observed in complex transactions that conclude in multiple steps. Complex transactions need a high number of parameters; therefore, they usually have multiple screens, with which they collect some more information from the end user at each step.

A time deposit account opening is a good example. The system will ask for the following parameter values from the end-user:

• Current account to withdraw money from
• Type of the time-deposit account (some banks have different account type options)
• Currency of the time-deposit account
• Term options
• Tenor
• Deposit amount
• Deposit return type (what to do with the interest amount at the end of the period)

Apparently, it would not be user friendly to have a single, long page and ask a ton of questions to the end user. Instead, the transaction has 3 steps: the first step collects the first few parameters, then the second step collects the rest, and then the third step asks for verification.

The application would also limit your choices in step 2, based on what is chosen in step 1. This means, if you open a time deposit account with EUR currency in step 1, then in step 2 the system will provide the interest rate options for EUR currency only.

Now suppose that there are two currency options for time deposit account opening, with diverse interest rates. There’s the USD option, which yields a low interest rate, like 1% per annum. The other is the Argentinian peso option, which yields 40% per annum. This difference makes sense, because there’s almost no inflation on USD and very high inflation on Peso. The high interest rate in Peso just helps compensate for the devaluation of your money in a Peso account. However, we are attackers now (hypothetically), so we will take advantage of this disparity and try to open a USD account with a 40% annual interest return.

Here is the process:

1. Choose Peso as the currency and proceed to step 2
2. Pick any interest rate and proceed to step 3.
3. Do not submit step 3. Instead, re-submit step 1, but this time change the currency to USD, instead of Peso.
4. Now, if the back-end controls are not robust, then you have submitted the parameters to open a USD time deposit account, with 40% interest rate. The system may allow this, because the interest rate was already set in step 2; therefore, all data required for account opening is collected.

The trick here is to do an additional re-submission, so that the steps go like this: 1-2-1-3

Apart from internet banking sites, you can observe TOCTOU vulnerabilities in e-commerce applications. Checkout often has multiple steps, which may be open to TOCTOU vulnerabilities. The trick is the same; Proceed to the last step but don’t just submit it yet, re-submit a previous step (like adding a new item to the cart), and then submit the last step to complete the transaction. The attacker adds the last item to the cart, but does not pay for it.

Similarly, some websites use payment processors for securing credit card transactions. However, security flaws can still stir up financial fraud. The attacker can pay for a cheap product at the processor’s system, ut alter the confirmation data that the processor returns, and submit it to the website as if he paid for an expensive product.

Conclusion

Through time, exploiting logic flaws will become more and more important for cyber criminals. This is because they are easier to find and less risky to execute. Furthermore, banks can seldom notice such attacks.

Tests that focus on technical checks end up searching for ordinary bugs in well-written financial applications. This can only offer limited help for preventing fraud. Besides, testers often lack the financial knowhow, and this prevents developing realistic fraud scenarios. A team that embodies technical and financial abilities and has a sound method can give the adequate coverage.

Besides penetration tests, banks can add the below-listed checks to their control inventory for detecting fraudulent transactions.

• Reconcile transactions from self-service channels and report clients with outlying transactions.
• Use automated reports to list repetitious transactions and customers that trigger too many errors.
• Internal control teams should examine the suspicious activities in more detail.

Additional Reading

Don’t forget to check out this excellent write-up by the NCC Group: https://www.nccgroup.com/globalassets/our-research/uk/whitepapers/2015/06/common-security-issues-in-financially-orientated-web-applications-_v1.1.pdf