In the first blogpost in this short series, we had a quick look at client-side solutions’ ability to block non-sophisticated hacker attempts.
In this second part of the series we will answer the next obvious question – Is this enough to block professional hackers as well?
A spoiler – uh, sadly no. Sophisticated hackers can easily work around the verification process described in part 1, and perform the automated attack multiple times. It is done by running the original app in a controlled environment (such as testing automation tools – see [ref 5-6]) in which the communication between the app and the server – including a “desired payload” (the abusing parameter values) – is being controlled and can be manipulated. As the original app in a real environment communicates with the server, it also passes the fingerprint token that will be used to verify the request as “normal” by the server.
Now, since the source device is identifiable it can be rate limited, so another workaround is needed to overcome this. Hackers accommodate for this by making the device untraceable.
Making the device untraceable
The device fingerprint consists of a well-known set of device parameters. These parameters can be automatically tampered with at the beginning of each session by an attacker using a script uploaded to the automated framework used. Thus, the SDK will generate different valid fingerprints for the same device, at each session, making the device tracking impractical.
Now, since this process demands a real device, hackers frequently choose an alternative solution which allows running the automated attack from standard workstations or botnets. A bulk of valid fingerprints is pre-prepared in order to be attached to the script’s API requests parameters.
How are fingerprints pre-prepared?
It is done using the same process of token generation by the mobile SDK and running it in a proper sandbox (emulator or physical device whose settings can be controlled via script), eliminating the need for a user interface, generating valid tokens automatically.
This is easy since the token generation process isn’t tightly coupled with the application code and can be cloned. See [ref 2-4] for several links where hackers demonstrate and describe this approach.
Some forward looking thoughts
Major vendors recently mentioned a capability to distinguish bots from humans by tracking their interaction with applications or browsers. These solutions, however, present quite few challenges:
1. They are very intrusive as this requires capturing mouse movements, clicks and other events, running a risk of ‘breaking’ the application or impacting its performance.
2. This raises the probability of false positives due to the simulation model being quite different from the optimal performance and interaction (After all, vendors build their applications according to general use models).
3. This doesn’t work well with short sessions as there is not enough data to decide upon.
4. These solutions can still be bypassed with bots that are aware of this technology. Some vendors call them 4th generation bots [ref 1]