Introduction During one of the audits, I noticed that some application accepted numbers in the exponential format (for example 5e10), however, all the fields were strongly typed – I couldn’t set any of the fields to a number higher than the Integer maximum value. Nevertheless, I kept that fact in my mind and continued to check other numerical fields with vast numbers that would exceed the integer limit. After some time, I finally found a field that did accept a number higher than integer, float or double, which meant that the variable type was BigInteger. Finding such variable type and a possibility to use exponential number format created a new vector for an attack – if application allows conducting any arithmetic equation, there is a chance to conduct a Denial of Service (DoS) attack. Logic behind the attack BigInteger is a variable type that allows usage of theoretically unlimited numbers (for example, Java implementation must support values at least in the range -2^Integer.MAX_VALUE to 2^Integer.MAX_VALUE). It also supports a variety of mathematic equations such as adding, subtracting, multiplying or dividing. When BigInteger variable is set to really high value and application conduct an equation with that, it will require ton of resource in order to just process the equation itself. The only problem that could occur is setting that number by HTTP request, since request body has its limits. In order to do that, we can user an exponential number format. If we send an HTTP request with the value set to the 1000000e9999999, we only use 15 characters, but the number itself would have nearly 60 million digits.

As an example, we can use a simple visit counter. If we can somehow change its value to high number and visit the website again, the application will try to add 1 to the visit counter value. Such a simple equation will take a lot of time and might hang the application. If the visit counting process is synchronous, it will instantly block access to the web page and cause a disruption in its functioning – the user will need for the equation to complete (and so all the next users). In case of an asynchronous process, it would be necessary to send a few requests – every of them would start a counting process and create a hanging thread consuming the resources, which results in resource exhaustion. Identifying an attack vector in the application The first step was finding the BigInteger variable, since the application accepted exponential number format in each request. In the tested application, the resource object was the one that was vulnerable. Each resource had its quantity attribute, which type was a BigInteger variable.

Second step was identifying if it is possible to conduct any arithmetic equation on the vulnerable object. Luckily, another functionality allowed to change the number of available resources in the action’s functionality. For example, if we trigger a given action, we can decrease or increase the number of available resources.

Plan of the attack will be pretty straightforward – create a resource, set its quantity to really high number, create an action that will be incrementing the resource quantity and trigger the action multiple times. Conducing an attack on the tested application The first planned step is creating the resource, which was done with the following HTTP request: The application created a new resource and returned its ID: The next planned step would be setting the newly created resource quantity to a high number, which was achieved by the following HTTP request: Server confirmed the change.

First requirement was fulfilled – BigInteger variable with a big number. Now the only thing left was creating a new action that will conduct an arithmetic operation, which could be achieved with the following HTTP request: The server created a new action and returned its ID: The last step would be triggering an action. Any action could be manually triggered by such HTTP request: After sending that request, the application still performed normally, so I decided to send a bit more request. After sending 14 requests more, I noticed that the application stopped responding – every request resulted in HTTP 504 Gateway Timeout error after a minute of waiting. Audit was conducted on the dev environment, and I had access to application metrics and telemetry. After checking some debug information, I noticed that some thread was hanging for over 2 minutes. In the details, there was an information regarding the currently executed method by a thread. The method that in the thread that was taking so long was java.math.BigInteger.Add(BigInteger.java) which confirmed that the application disruption was caused due to attempt of adding a simple 1 to the previously set number. Recommendations When creating an application, it is important to correctly choose the required type of the variable. BigInteger should not be used unless it is necessary. In Java, the largest positive Double has a value of 1.79^308 and Float has the largest positive value of 3.40^38F, so if we need to store numbers that exceed the max value of integer there are still other options than a BigInteger. If we need to use them, we should also remember about limiting the use of exponential number format – a few characters can result in tremendous numbers.

The application architecture is also significant. For example, if we start a new task, we should set a limit to the execution time. A proper application design can limit an impact or prevent unexpected resource consumption.