What is a rogue/fake app?
A Rogue App is a 100% working copy of the original app. It is modified to steal the device, app, registration, footprint, and user data, and then pass them all to the thief, using built-in http client. Usually, there is no change in the look & feel or functionalities.
The rogue app can also be used for data theft, brand abuse, Botnet activity, denial of service, and surveillance.
The typically stolen data is IMIE#, Telephone #, SIM details, package details, signature details, registration code/footprint data, user's password, transaction password, fingerprint, OTP, etc.
How to build a rogue app?
Download the original APK from the app store, decompile it using online tools, make the required changes for stealing the data, rename the package, build the package, sign with own signature, and then publish it on an app store or on a website.
How rogue app can be propagated?
The download link of the rogue app can be propagated to a large number of people using social media, with some encouraging text attached that lures people to download it.
From where a rogue app can be downloaded?
A rogue app can be downloaded from an app store or from a website.
How to make a user download the rogue app from the app store?
On searching for an app on the app store by name, the app store shows the matching list in the descending order of rating. There is a tendency of installing the first one.
By installing the original app and uninstalling it with a poor rating, many times, the original app can be pushed to the bottom. Whereas by giving the highest rating to the rogue app, it can be pushed to the top of the list.
Can a person detect rogue app?
It is practically impossible for a common person to detect a rogue app as the look & feel and functionalities are exactly the same as the original app.
What happens on download and first use?
Since the rogue app is a 100% functional app, the user can go through the registration process and carry out a transaction on the app, as usual. Broadly, this rogue app can do one the following.
- In the process, the app can collect all the required data to carry-out a transaction as the user and the user's registered device. This data can be sent to the thief using http-client.
- Or the app itself can change the data and submit. For example, by changing the entered "account to" and the "amount" , the transfer can be made to some other account.
How thief can use the stolen data?
The thief can substitute this stolen data at the point of stealing in another copy of the original app, without bothering app logic. Thus, the app will always consider it data generated by the app itself.
This way the thief can carry out transactions impersonating the user’s app, the user’s device, and the user.
For a mass theft, the thief can execute transactions by substituting data of users in a loop and running it under a simulator.
The thief can use the existing functionalities of the app to make it more lethal. e.g. by regularly checking the account balance and transferring out the balance as soon as a credit appears in the user's account.
What kind of DDoS/Botnet activity can be carried?
Typically, when a user uses the app from a new device/telephone number, he/she has to go through a registration process. His/her earlier registration is invalidated on reaching the number of allowed device limit. By simply running the app by substituting different device/telephone data, the user's account can get disabled. This activity can be carried out for a large number of users by running it in a loop. Thus, denying service to a large number of users.
How branding can be misused?
The thief can take a copy of an organization app and launch a rogue app by changing the package name, organization name, logo, etc. Here, the thief is using some other brand but is actually using the APIs of the organization. This will make it impossible for a rogue app monitoring service to detect this rogue app. The thief can also upload this app on a website, which is beyond the reach of a rogue app monitoring service.
Thus, the thief can steal data using some other brand and use the stolen data to target the organization.
How the app generated data can be trapped and misused?
The data from the app can be forwarded to the thief’s server using http. The encryption key is either hardcoded in the app or exchanged with the server. It can always be extracted from the original app at the java level. This key can be used to decrypt the received data, modify the data, encrypt the modified data and then submit it to the organization server for carrying out a fraudulent transaction.
Are java errors in the decompiled code a show stopper?
The decompiled java code may show errors, but it is very unlikely that classes required for data stealing will give errors. By selectively modifying the required class and replacing its byte code, the result can be achieved.
Alternatively, changes can be made in dex files, as they never give any compilation errors.
Can obfuscation protect from tampering?
Can app signature protect installation of the rogue app?
Since package name is renamed, there won’t be any conflict of signatures, even if the APK is signed by a third person.
Can a person download an app from a website and not app store?
Anybody can download and install an app from any website if "Unknown sources" is enabled on his/her mobile. On clicking the propagated link in his/her social media message, the user can install a rogue app from an external website. As most of the users are non-technical, they can't notice the threat.
Can encryption offer any protection?
In the rogue app, the thief steals data before encryption takes place. Hence, encryption won’t make any difference.
Can SSL offer protection?
SSL comes into picture only while data transfer between the app and the organization server. In the case of a rogue app, both the data stealing and the data substitution are carried out at the app level, much before the data transfer starts. Hence SSL does not offer any protection in this case.
Can certificate pinning reject request coming from a rogue app by the server?
Since the rogue app presents the same certificate as the original app, the server will treat the request coming from the rogue app as coming from the original app.
Can any java based anti-tampering code offer protection against a rogue app?
Typically, app signature or classes.dex are used as reference objects for detecting tampering.
Checkpoint/Signature, based on any external property like timestamp, size, CRC, memory allocation, can always be extracted from the object of the original app and can be substituted at a proper place in the java code of a rogue app to fool the system.
The simplest way is to copy the original objects like classes.dex, RSA signature in asset folder and change the reference in java code to point to asset folder. This technique will always get the correct value of the original app, thus ridiculousing the whole anti-tampering mechanism.
Can C++ based anti-tampering code offer protection against a rogue app?
- If C++ library in-turn is making calls to underlying application or android classes to get the reference of the app signature or classes.dex object then the underlying android/java classes can be modified and be included as a part of the APK. Values of the original object can be substituted in these modified classes using techniques discussed earlier.
- If C++ library in-turn is not making calls to underlying application or android classes to get the reference of the app signature or classes.dex object then C++ module can be patched to read signature/classes.dex file from asset folder. It is very easy to crack/patch disassembled C++ code using utilities like “IDA Pro”.
- If C++ library is not making calls to java library to get checkpoint and the output of C++ module is checked against the webserver, the output can be changed at java level before it is submitted to the webserver. Or, the response from webserver call can be changed at java level to indicate no tampering.
- “proc/self/map” gives memory allocation in 4K block. Memory allocation mainly changes on the introduction or on the removal of a new class, method, or public object. There is a high chance that introduction of a stealing code won’t change memory allocation. Even if there is a change, it can be adjusted by adding/removing a few lines of code.
- Any hardcoded encryption key always gives the same output. Similarly, if the encryption key is passed to the C++ module, it always gives the same output corresponding to the key.
The thief can always obtain the output of C++ module from the original app, by running the original app in debug mode under an emulator. If required, the thief can root his/her device. This output can be substituted in the rogue app as the output of C++ module, thus fooling the whole system.
- If the output of C++ module is encrypted and data contains some dynamic data like time to make output dynamic, then the encryption key can be easily extracted from C++ module. Please see the next point to find out how to extract the encryption key.
The checkpoint/signature based on any external property like timestamp, size, CRC, hash, can always be extracted from the object of the original app and it can be substituted at an appropriate place in the decrypted output of C++ method at java level of the rogue app to fool the system. Before substituting, the output can be re-encrypted using the extracted key.
- The call to C++ module can be bypassed in java code, in case anti-tampering check is performed within the C++ module. Thus, breaking the complete anti-tampering check chain.
Similarly, any other tampering check can be bypassed externally without understanding or changing the C++ code.
How to know which java class C++ code is calling?
By forcing a statement raising an exception, printing its printTrace(), and running under an emulator, java class calls from C++ can be easily detected.
Can C++ based encryption offer any protection against data tampering?
Any hardcoded encryption key always gives the same output. Similarly, if the encryption key is passed to the C++ module, it always gives the same output corresponding to the key.
- Instead of tampering encrypted output data, tampering of input data to C++ module can be carried out.
- It is very easy to extract either passed or hard-coded encryption keys by cracking disassembled C++ code using utilities like “IDA Pro”. It is because parameter name, function name, class name, local variable name, return value, switch statements, etc. are never changed in assembly code. By searching de-assembled code using parameter name or function name, the exact line where encryption is taking place can be reached. Once the key is extracted, the output data of C++ can be decrypted, modified, and re-encrypted for futher processing.
Can rogue app monitoring service provide formidable protection?
- Rogue app monitoring service can scan only app stores. Whereas, the thief can upload rogue app on a website. Thus, defeating rogue app monitoring service.
- It is difficult to identify and remove copycat (similar looking) rogue apps as they do not violate Google policy.
- Rogue app monitoring service can't identify a rogue app if resource images and texts are encrypted.
- There can be a substantial time difference between when a rogue app is uploaded and when it is removed by an app monitoring service from the app store. In this period, a large number of users can download the rogue app, as social media messages spread at a very high speed.
- On bringing down a rogue app, the thief can upload another copy of the rogue app with a different package name.
- Using URL forwarding, the pointer of the link in a social media message can be changed to the download link of the new package.
- App store has to put back the app on App store if the app owner protests. Then, it can be removed only after a long legal process. Thus, giving a very long window for users to download the rogue app.
Can risk engines detect activities coming from a rogue app?
Since all authentication data is exactly the same as the original app, it is almost impossible for a risk engine to detect activities coming from a rogue app.
Can OTP/2FA offer any reliable protection against the rogue app?
- A small piece of code can be introduced in the rogue app that reads the OTP received by SMS on the user’s mobile and then sends it to the thief. This OTP can be used by the thief to complete the transaction.
- In case email based OTP is used, a small piece of code can be introduced in the rogue app that can read OTP using published email INTENDS.
- Or the app itself can change the data and submit. For example, by changing the entered "account to" and the "amount", the transfer can be made to some other account. Since, the user himself/herself is entering the received OTP/2FA to confirm the transaction, the transaction will go through successfully.
- Or if 2FA is used at the time of login, the rogue app can send login session data to the theif using http client on successful authentication. The thief can further carry-out transaction using stolen session data simulating a logged-in session.
- Typically, a loggin session expires after many minutes of in-activity. Most organizations do not use OTP/2FA for small value transactions. Thus, this stolen login session data can be used for carrying out multiple transactions.
Can fingerprint offer any protection?
External fingerprint (like Aadhar) is just another piece of data. It can be stolen and substituted exactly in the same way as any other data.
Built-in fingerprint reader check can be bypassed by changing the return value of the fingerprint check method in java to “true”.
Can pre-registration of payee offer any protection?
Since any code of the rogue can be modified, the app code can be modfied to call the existing payee registration API to register the thief as a payee.
Can password change help?
On using the new password in the rogue app, the thief will automatically get the new one.
Can typical device authentication solution offer protection?
All device protection solutions use one or more device/application properties for identifying a device. All properties can be stolen and used exactly in the same way.
Can channel security solution offer any protection?
Again, all channel protection solutions use one or more device/application properties for channel security. Since all properties can be stolen and substituted in rogue and/or thieves app, these solutions become ineffective.