True Stories of the TRC

Breaking the Bank

Banking institutions are a high-profile target for malicious hackers and, as such, their web applications should be properly secure to give peace of mind to both the institutions and their customers. While a vulnerability scanner can find some low-hanging fruit of vulnerabilities, a manual assessment of the application is necessary to test that the business logic of the website is sound. If a bank is doing business with branches or transactional activity with the State of New York, Cybersecurity Regulation declares the applications need to be evaluated, assessed, or tested.

WhiteHat’s Business Logic Assessments do just that. In a recent assessment of a banking application, I was able to identify and exploit an insufficient process validation vulnerability which allowed a user to set up a wire transfer of negative value.

 

What is insufficient process validation?

Insufficient process validation is a vulnerability where the web application fails to prevent an attacker from bypassing the intended flow control or business logic of the application. Web applications can contain many different processes or functions which can fall victim to this vulnerability, i.e. registering a new user account, adding a product to a shopping cart, or transferring funds between two bank accounts. Being able to exploit this vulnerability can lead to catastrophic results depending on the sensitivity of the exploited functionality. It’s all about fraud prevention.

 

Securing the Infiltration Route

The banking application – we’ll call it some.bank.site – contained the typical functionalities of any bank’s website; the user can generate reports of banking activity; initiate, confirm, or cancel wire transfers; perform user account management; and many more options. Automated vulnerability testing can only do so much because of how sensitive and complex many of those functionalities are, so manual vulnerability testing is performed to find flaws in the business logic of a site.

The wire transfer functionality was one of the primary targets during my testing. When it comes to functionality that deals with the movement of money, it would be detrimental to the institution if a malicious hacker could control where the money goes to or how much money is being transferred. The transfer consists of two steps:

 

  1. The user inputs the information for the wire transfer i.e. the account to transfer the money from, the account to transfer to, and the amount of money to transfer, along with any notes the user may want to add;
  2. The user reviews the transfer details before confirming the transaction.

 

Using Burp Suite to monitor the request and response between the client and the server, I filled out the form with some dummy data and sent the request. Looking in Burp, the request was formatted in such a manner:

 

POST /WireTransferAction

Host: some.bank.site

[…other headers…]

 

currentMonth=01&currentDay=05&currentYear=2018&accountFromID=0123456789&account
ToID=9876543210&accountCurr=USD&amountString=0.01&notes=&submitButton=Submit

 

The amountString parameter looked promising. If I could successfully submit a wire transfer with a value that is outside the expected, either greater than the amount in the account or a negative amount, then it would show that the logic for the functionality is flawed.

 

Stealing the Treasure

The moment of truth arrived. I opted to take the path of using a negative value, which would lead to a reverse transfer. Returning to the initial page of the wire transfer functionality, I filled in all the necessary values and initiated the transfer with Burp in intercept mode. I had noticed during testing that the form prevented the user from inputting a negative value, so intercepting the request in transit would allow me to modify the request.

With the captured request, I modified the value of the amountString parameter to -0.01 and then forwarded it. On the review transfer details page, it displayed the negative value that would be transferred. I clicked the confirm button and was met with a page stating that the transfer setup was successful. This confirms that the wire transfer functionality was indeed vulnerable to insufficient process validation. If a hacker exploited this vulnerability, they could initiate reverse transfers from other people’s accounts to their own, committing fraud.

 

Changing the Heart of the Process

In order to remediate this vulnerability, sanity checks need to be implemented to ensure that all transfer processes function in the intended manner. Although there was client-side code preventing the user from inputting a negative value, this was easily bypassed by the use of an intercepting proxy tool such as Burp. A safety measure for the application developer would be to implement server-side code that checks that the transfer value requested is within the valid range of values given the amount of money in a user’s account.

In other words, a user should be unable to initiate a transfer of either more money than they have or a negative amount of money. If the server receives an amount that is invalid, it should redirect the user back to the initial page with an error message stating that a valid value should be used.

As shown, insufficient process validation is one of numerous vulnerabilities that can negatively affect complex web applications such as the ones for banking institutions. This kind of vulnerability has had real world consequences when exploited. In 2008, E-Trade and Schwab lost $50,000 when they failed to validate a limit of one bank account per user in their sign-up process, which allowed an attacker to link one bank account to numerous users and accumulate money via micro-deposits. Another case involved the QVC home-shopping network in 2005 where one could order an item, cancel the order, but still receive the items. This exploitation led QVC to lose more than $412,000. These kinds of losses should stress the importance of properly testing the business logic of the processes during the development of web applications, and in production with new feature adds.

Tags: application security, Compliance, DAST, finance, PCI, Penetration testing, Secure Coding