Thinking about Requests

The reason I want to wrap up this topic is just to keep all of my logics and comprehension of request in pen testing, hacking. Why it’s important? Rather than knowing the best practices, security cheat sheets that need to follow in order to protect your applications from the attacks, which also could be done by automatic software, tools or so. But for requests, in this case, could be API, I'd say it's quite tedious for those automatic "machines" to help you detect things. Indeed, with common vulnerabilities like SQL injection, XSS, CSRF or so could be done easily by fuzzing.

The things I want to talk here is the interaction between the application and servers which they are talking to. Before diving into it, I just want you to understand one important thing (it could be not sufficient) from my knowledge that is the way how the app works. Most of the applications nowadays, it depends on what types of applications they have their own structure. Thus, I'd like to repeat my words in the previous post "Common vuls in Mobile Apps".

Case 01: The application interacts with the server constantly

This common case happens in none-game apps on the grounds that the user's relevant data is minor, thus the requests are always made every single time the functions are called. I hope that you've already known what is "data validation" in security point of view. Yes, what I want to talk to is tampering data requests, indeed it happens in both Request & Response, GET or POST. If you are confused about what this is, just wandering around google that could be helpful.

The tampering data requests happens when the server side does not re-verifies the input when propagated to end-users (Response). And, the server-side does not re-verifies the data between user input and server when propagated to end server (Request).

Case 02: The application data is loaded for the first time when created.

This often happens in gaming apps more than other apps due to the huge data have to be propagated to the users as such gold, points, time to build, and other numerical values that makes the game run. Therefore, talking with the server constantly in the real-time is painful and really tedious. Developers always choose to load all of these values once at the first time the application created.

Similarly to the case 01, attackers just need to tamper the data (RESPONSE) that are propagated by the servers to the end users and change them to whatever they want. For example:

The players will get 500 Gold for first-time play, the server will response with value {Gold: 500} to the clients. The attackers are able to replace this value to an arbitrary amount.

{Gold: 500} replace to {Gold: 700}, at here the players will get 700 gold instead of 500 for the first time the character created.

I hope the 2 cases afore have given you the illustration of how the mobile/desktop applications work with its data derived from the servers, of course, there are more but these are generic ones I'd say. As you can see it does not include other common vuls like SQL injection or XSS in this case. It's a real hack, it challenges your logics, skills and experiences to understand the whole structure of the app at first, then later use your skills and logic to analyze and exploit them. How to get more gold for yourself?, Will replace the values in response make you as a top player? How to bypass the minimum value set to make a transaction for lower KYC? And many more cases to gain the benefits for your own if you know how to sneak into it 😊 . Let's dive right into it

I'll be talking about black box pentest. But, what is tampering request attack?

As the OWASP defines - "The Web Parameter Tampering attack is based on the manipulation of parameters exchanged between client and server in order to modify application data, such as user credentials and permissions, price and quantity of products, etc. Usually, this information is stored in cookies, hidden form fields, or URL Query Strings, and is used to increase application functionality and control. This attack can be performed by a malicious user who wants to exploit the application for their own benefits or an attacker who wishes to attack a third-person using a Man-in-the-middle attack. In both cases, tools like Webscarab and Paros proxy are mostly used. The attack success depends on integrity and logic validation mechanism errors, and its exploitation can result in other consequences including XSS, SQL Injection, file inclusion, and path disclosure attacks."

The scenarios are similar with Mobile Parameter Tampering attack, it's web based attack obviously. Rather than that, it just adds one more case of changing the values and behaviors of the apps. It makes the app works in abnormally and helps players gain benefits from it.

Determine functions (buttons):

1.Single function

A button is represented for a function, which means once users press them they will execute a command. In the picture shown below, a single function "buy" make a post request that containing some other key pair values. These values are changeable and replaced by other malicious values which will give the attackers benefits.

2. Family functions

The preceding picture has shown that the relation between buttons (functions). An "ETH" function has 2 child functions Withdraw and Deposit, in the other way, pressing the ETH button will show you another page containing Withdraw and Deposit buttons. Usually, the parent's functions are not just landing pages, it also has its own requests in the back to operate their child functions. More precisely, the response data of the ETH function is also the request data of the Withdraw and Deposit.

The above figure illustrates that a pentester has tampered the response values amount from 0 to 100, now the app understands that the servers responded with value 100 for winning_amount, then stored them in the local database where later it's used for Withdraw request data. He's now bypassed the condition of Withdraw and making a request to withdraw. Remember in this case, the server does not double-check for user's winning_amount, there is a fund keeper who keeps and gives all the money to the players. Thus, the fund keeper thought that this user has won 100 ETH and started giving him the prize. Back to the previous section, where the value 100 came from?. It was tampered and replaced at the first "press" ETH button, where the server is supposed to response the actual winning_amount but it was deceived by the pentester.

Yes, you no need to replace winning_amount by using tamper method. You can just go to the local database and modify them as rooted users.