MobileApps Security Issue

Question

I've a very compelling question to begin first. But this is not about code level, it's just for me to gauge my understanding. Correct me if i'm wrong, now days MobileApps as per design utilizes the session token method for a request.

Currently, for first time user will pass in their deviceID, pin, and timestamp for an encrypted value from the back-end. Subsequently , the front-end system will send this parameter for request and get a response success. The token has expiration date of 30 minutes.

With a recent event, hackers are able to manipulate the request from a script by spoofing. So the hackers are imitating the same behavior as from mobileapps. How do we cater for this kind of scenario? Is there a way to block these kind of request ?

Answer 1

Token Method

Correct me if i'm wrong, now days MobileApps as per design utilizes the session token method for a request.

I think you are referring to OAUTH2 or OpenID tokens.

OAUTH2

OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.

OpenID

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID Providers, and session management, when it makes sense for them.

Mobile App Identification to the API

Currently, for first time user will pass in their deviceID, pin, and timestamp for an encrypted value from the back-end. Subsequently , the front-end system will send this parameter for request and get a response success. The token has expiration date of 30 minutes.

Normally developers identify the mobile to the API server with a secret that is normally called api-key or some kind of named token *-token. No matter what the convention name used this is identifier is always a secret that sometimes is a simple unique string to identify the mobile app and sometimes is more sophisticated, like in your case.

With a recent event, hackers are able to manipulate the request from a script by spoofing.

The problem is that anything running in the client side can be reverse engineered easily by an attacker on a device he controls. He will use introspection frameworks like Frida or xPosed to intercept at runtime the running code of the mobile app or will use a proxy tool like MiTM for watching the communications between the mobile app and the API server. Normally their first step in reverse engineer a mobile app will be to use the Mobile Security Framework to reverse engineer the binary of you mobile app to extract all static secrets and to identify attack vectors.

Frida

Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.

xPosed

Xposed is a framework for modules that can change the behavior of the system and apps without touching any APKs. That's great because it means that modules can work for different versions and even ROMs without any changes (as long as the original code was not changed too much). It's also easy to undo.

Mobile Security Framework

Mobile Security Framework is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing framework capable of performing static analysis, dynamic analysis, malware analysis and web API testing.

MiTM Proxy

An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.

So after using all this tools is possible for an attacker to replay all steps your mobile app does to get the token from the API server and use it afterwards to automate the attacks against the API server.

Possible Solution

So the hackers are imitating the same behavior as from mobileapps. How do we cater for this kind of scenario? Is there a way to block these kind of request?

So anything that runs on the client side and needs some secret to access an API can be abused in different ways and you can learn more on this series of articles about mobile api security techniques. This articles will teach you how API Keys, User Access Tokens, HMAC, TLS Pinning can be used to protect the API and how they can be bypassed.

A better solution can be employed by using a Mobile App Attestation solution to enable the API server to know is receiving only requests from a genuine mobile app.

A Mobile App Attestation service will guarantee at run-time that your mobile app was not tampered or is not running in a rooted/jail broken device by running a SDK in the background(without impacting user experience), that will communicate with a service running in the cloud to attest the integrity of the mobile app and the device is running on.

On successful attestation of the mobile app integrity a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud are aware. In the case of failure on the mobile app attestation the JWT token is signed with a secret that the API server does not know.

Now the App must send with every API call the JWT token in the headers of the request. This will allow the API server to only serve requests when it can verify the signature and expiration time in the JWT token and refuse them when it fails the verification.

Once the secret used by the Mobile App Attestation service is not known by the mobile app, is not possible to reverse engineer it at run-time even when the App is tampered, running in a rooted device or communicating over a connection that is being the target of a Man in the Middle Attack.

The Mobile App Attestation service already exists as a SAAS solution at Approov(I work here) that provides SDKs for several platforms, including iOS, Android, React Native and others. The integration will also need a small check in the API server code to verify the JWT token issued by the cloud service. This check is necessary for the API server to be able to decide what requests to serve and what ones to deny. Your current token could be used as a payload claim in the Approov Token to allow the API server to continue using it with the guarantee that was not tampered with.