Your Problem
We have a live mobile application supporting registering with the user's mobile number. We send OTP upon each register request and now we have hundreds of spam requests costing a lot of money due to the SMS service fee.
Registering with the mobile phone number to deter spam isn't enough because a lot of services exist in the internet to provide anyone with free mobile phone numbers, that are often used to workaround registrations or any other services that require you to provide a number.
Rate limiting on Ip is applied.
Malicious users can rotate their IP address when they use a script (bot) or run your app in an emulator. Also IP addresses in mobile are very dynamic, its not like in residential broadband where they stay stable for long periods.
Rate limiting on device id is also applied.
The malicious user will rotate the device id when using a bot, an emulator or a rooted device.
Reverse Engineering
The register request is secured by adding a signature to the header using the HMAC SHA-256 algorithm, the key used to generate the signature stored in mobile code.
The malicious user will reverse engineer you mobile app statically to see how the HMAC signature is done and then replicate it on its script. In a series of articles around Mobile API Security I wrote an article about statically reverse engineering an app, while in the context of extracting an API Key the principles remain to extract the logic for the HMAC signature. You can learn how to it by yourself on your own app by applying the same basic technics I used on the article How to Extract an API key from a Mobile App with Static Binary Analysis:
The range of open source tools available for reverse engineering is huge, and we really can't scratch the surface of this topic in this article, but instead we will focus in using the Mobile Security Framework(MobSF) to demonstrate how to reverse engineer the APK of our mobile app. MobSF is a collection of open source tools that present their results in an attractive dashboard, but the same tools used under the hood within MobSF and elsewhere can be used individually to achieve the same results.
During this article we will use the Android Hide Secrets research repository that is a dummy mobile app with API keys hidden using several different techniques.
The malicious user may also reverse engineer dynamically your app to understand how it communicates with your API server in order to do exactly the same on its bot.
This is usually done with a MitM attack on a device that the malicious user controls and a lot of open-source tools exist to help with the task, being the most known ones mitmproxy and Frida. Turns out that I also wrote an article on how to use this tools, not to extract the HMAC signature, but to bypass certificate pinning, but the basic mechanics to perform the dynamic analysis are the same, therefore I invite you to try this techniques against your own app. Learn the basics of MitM attack with Frida and mitmproxy on the article Bypassing Certificate Pinning:
In this article you will learn how to repackage a mobile app in order to disable certificate pinning and in the process you will also learn how to create an Android emulator with a writable system to allow for adding the custom certificate authority for the proxy server into the Android operating system trust store. This will allow us to bypass certificate pinning and intercept the requests between the mobile and its backend with a MitM attack.
The Difference Between WHO and WHAT is Accessing the API Server
But it turns out that this is not enough to secure the process.
No, its not enough because its not that hard to bypass with the several techniques I shown above.
In order for you to improve your security posture when developing an application you first need to understand the difference between who and what is doing the request to the API server.
In the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
So think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
When you grasp this idea and it's ingrained in your mindset, then you will look into mobile API security with another perspective and be able to see attack surfaces that you never though they existed before.
Possible Solutions
Security must be always seen as a layered approach, where you add as many layers as needed to deter the opponent from even trying to break them, or if in the case they try they will need a lot of resources, knowledge and time. This not new to software development, its being done for centuries, like in the medieval castles and prisons.
Is there any other practice we should do to solve the spam issue?
I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
From this answer the Mobile App Attestation would be the most suitable for you to employ in order to give a very high degree of confidence to your API backend that the request is indeed from what it expects, a genuine and unmodified version of your mobile app, not from a bot, an emulator, a jail broken device or whatever other technique being used by the malicious user.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
