Cracking Authorization Logic in Android

With increase in the demand of mobile applications we can see a variety of applications in the market. Also businesses now-a-days prefer to make complex functionality available to the user through the medium of mobile applications. As the nature of applications get complex their implementation and design too gets complicated. And in applications that require authorization or in other words role based access controls the chances for design flaws to exist are prominent. I came across one such insecure implementation that I have demonstrated below. 

 Here, the logic to determine access to different features of the application is dependent on a configuration file that comes shipped with the application bundle i.e. apk file. 

 We will see how to crack it and gain access to features that are hidden or forbidden to the user. 

The initial screen that appears to the user when we start the application is shown below.

Now the user logs in to the application. This being a hybrid application it makes a call to the web server and authenticates the user.

Once the login is successful the user is given access to the application. Note that the user – “Bob” is able to access to ONLY 2 features of the application viz. Funds transfer and View History.

However, Bob is aware that other uses of the same application get access to more than 2 features after login. Well, they could be some privileged users of the application. But, Bob is not happy with it. He somehow wants access to all the features of the application and he decides to crack it.

He uses a tool called – “apktool”, which is a reverse engineering tool for android and tries to unpack the “.apk” file. The steps are really simple, go to the directory where you have “apktool” and type “apktook d <name of the apk file to be unpacked> <name of directory to place the contents>”

Once the command is executed it unpacks the application in the specified directory – “Decompiled” in this case.

The unpacked directory is shown below, observe that it gives access to the entire “res” (i.e. resource) directory of the application.

Bob is happy to see that and he continues to browses the contents within the “res” directory. To his surprise he observes that there is a file named – “accessdata.xml” that has something like names of different menus and their status as “ON” or “OFF”. He has found a treasure here :) This could probably be the access control configuration.

He observes that the menus to which he has access are marked as “ON” and the other menu is kept as “OFF”. He changes the 3^rd menu to ON and saves the file.

He recompiles the file using the same apktool, as below. This time he uses the mode “b” of the apktool.

Bob now has a recompiled application with a new access control configuration. But can he install this “apk” file in this device? 

No, with the process of recompilation he has lost of developer signature. He wonders how to resolve this issue until he figures out a tool called “SignApk”.

He signs the application with “SignApk” using the following command. It is pretty straightforward; all you need to do it use the command below and specify a new name for the apk file, “MyBankSigned.apk” as in this case.

The signed apk is shown below.

Bob firsts uninstalls the application that he already has.

And excitedly installs his new apk into the device using “adb”.

Now, Bob logins into the application.

Bingo!!! He gets access to the 3^rd Menu, which is not authorized to access.

Bob can now proceed to create new account in the system.

Why did Bob succeed? 

This is because the application had insecure access control logic. It relied on some configuration files and took access control decision based on it.

Observe that the “MenuDisplay” activity that loads after successful login loads the configuration from the raw file.  

The configurations i.e. “item and value” pairs are picked from the xml file (accessdata.xml) and stored it in a “menuconfig” object.

Depending on the value obtained from the configuration file the menus are either made visible or disabled for the user.

This leaves a big hole in the application that the users can easily change the values of the configuration file which is in clear text and alter the functionality of the application.

Thus, applications that make use of clear text values from configurations files, database, and preference files are all subject to such attacks.

So what is the solution for this problem?

Create different “apk” files for different user types/roles and distribute it to the users. Every user who belongs to a particular user type will then get a specific apk file that has no logic to make any access control decision. And then there will be no scope for the user can to manipulate any value stored in any file to influence the functionality of the application.

If the above solution is NOT feasible following technique can be used.

For Online Access -

(This applicable for application that can make a call to the web server.)

A) Instead of fetching the access rights information locally, fetch it from the remote server and load the menu controls based on the server response.

B) To maintain data integrity, create a checksum of the access right information at server and send it along with response.

C) Validate the checksum at the client end before loading the menu controls

For Offline Access –

(This applicable for application that does not make call to the web server.)  

A) Store the access rights information in an encrypted format in the database/files.

B) To maintain data integrity, create a checksum of the access right information and save it separately in the file.

C) Validate the checksum before loading the menu controls based on the flags.