Mobile App Security Issues with Client-Side Protection
In this short series, we’ll review the available client-side solutions and explain where they fall short compared to API protection solutions.
Protecting mobile apps from automated threats such as brute force attacks, scraping, etc. under single or multiple identities is usually done with a device fingerprinting SDK at the app on the client side.
Device fingerprinting enables us to verify that what is accessing the server is indeed a “legit” application from a “legit” device. It requires a security code injection into the app, which imposes limitations and extra costs on the overall DevOps process, as well as a need to track the customer-installed versions and update all clients to the current one, just before turning on the filtration process at the server.
But that isn’t where the story ends. Rather, this is the end of the beginning. There are a bunch of fundamental flaws in this protection sequence that are major causes for concern – here we go:
Mobile security threats and prevention
Let’s examine the flow between the client and the server
- The API of the SDK code is compiled with the app. The SDK implementation code itself resides in an obfuscated library. A call to the SDK API is added in certain stages of the application flow, such as during session initiation.
- The SDK implementation then polls device configuration parameters (e.g., device_id, resolution, installed applications, language) and encodes them into a long client token several hundreds of bytes in length, that is signed and sent to the server.
- The client token is then verified by the server (e., checks that the signature structure is valid and that the encoded device data “makes sense”). The device data is used to build the fingerprint token, which is then sent to the client for further communication identification.
- The fingerprint token is appended to subsequent requests sent by the client to the server.
- The fingerprint token sent by the client is checked by the server for protected APIs, and requests that cannot be validated are denied.
- Aside from the requests’ source verification, the fingerprint token may be used (by the server) to limit the traffic coming from devices, based on device identity.
Normally this is enough to block non-sophisticated hackers
In order to run the automated script/bot the first time, the non-sophisticated attacker reverse-engineers the normal applicative flow and corresponding API calls. APIs are then called directly using script-based tools, such as curl and python.
As the flow generating the fingerprinting token is skipped, it will easily and obviously be rejected on the first attempt to access protected APIs.
Mobile App Security Vulnerabilities
Unfortunately, these mobile app security solutions or not good enough to block sophisticated attackers, such solutions are still exposed to many mobile app security vulnerabilities. Sophisticated hackers can easily work around the verification process, 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.
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.
Mobile App Security Solutions
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 mobile app security issues:
- 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.
- This raises the probability of false positives due to the simulation model being quite different from the optimal performance and interaction (Afterall, vendors build their applications according to general use models).
- This doesn’t work well with short sessions as there is not enough data to decide upon.
- These solutions can still be bypassed with bots that are aware of this technology. Some vendors call them 4th generation bots [ref 1]
References:
https://blog.radware.com/security/2019/09/meet-the-four-generations-of-bots/
https://www.nulled.to/topic/968127-akamai-cookie-gen-api-or-source/
https://twitter.com/jonesunk/status/979510019891908608
https://www.youtube.com/watch?v=4w6P3Me3VPQ
http://appium.io/
https://www.rightpoint.com/rplabs/automating-input-events-abd-keyevent
