Business logic vulnerabilities — Low-level logic flaw

This is the third of the series of articles for business logic vulnerabilities. This one is more complicated than the previous two.

Before we get into the exploit. Lets understand what an integer overflow is.

Generally an integer is stored as a 32 bit value in the memory. That is the maximum number that can be stored is 2 to power 32 equal to 4,294,967,296 for unsigned integer or −2,147,483,648 and 2,147,483,647 for signed integer. So what happens if we do 4,294,967,296+1.

Lets do a small experiment with c. Here a c program to add two integers and print the results. This is for unsigned integer.

Lets do it for signed int which is the default in c.

Ok so what is the problem here. If we add 1 to the 4,294,967,295 which is the highest number allowed for a variable the result is zero and if we add 1 to 2,147,483,648 we got a negative number. This happened because our compiler was not able to handle what is beyond permitted value. The result may vary based on the compiler and language being used. And in most cases you will not get an error.

For more detailed explanation refer to the link. It explains the concept more deeply.,integer%20between%20%E2%88%922%2C147%2C483%2C648%20and%202%2C147%2C483%2C647.

So what, you may ask. I don’t see any security issue here. Let’s see how we can exploit this.

Consider a vulnerable e-commerce site where we buy a jacket. Lets try to add a large quantity of jackets

Here there is a limit of 99 that can be added at a time. So lets add in and try to increase the quantity to a value so that the total value overflows. For this we will intercept the request into burpsuite.

Get the request to burp intruder and set the payload to repeat indefinitely. At one point the total value will go to negative as it reaches the highest allowable value.

As can be seen when we add 17127 quantity of items into the cart, we see the total amount will go to negative as there is an integer overflow. If we repeat the process a few 100 times more, we will reach amount close to zero.

Since we cannot place the order for a negative amount. We need to add another item several times just so that we have total value greater than zero and less than $100. Now we were able complete the order successfully.

Lessons learnt

Now for the lessons learnt.

  1. Never trust the user. A developer should never create an application thinking it will be used only in the browser.
  2. Client side validations are not secure. Any kind of validation should happen at server side.
  3. Developer should understand the overall business logic. Typically, several developers work on a single module. So, every developer should understand various other components and how they function in a business.
  4. Maintain logic, business and data flows in the application.
  5. Maintain best coding practices with comments and explanation of code. When a new developer gets into shoes of a developed code, it will be very daunting to understand the code without proper comments.

This is a rather simplistic example. Usually applications become very complex as the project grows over time.

Anything about security I am interested.