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.