Already showed you how the Android’s app basically structured and also developed. But now, we will take a step further, and help you to understand setting up the security environment for android apps! Besides that, you will also see how some basic testing processes function and you will learn them easily. Ready to start? I think you are!
Did you know that you can basically set up the test environment which is fully functioning on almost any device which runs on Windows, Mac OS or Linux? That’s great, but from where to start?
First of all, you will need some local Android SDK installations. Those need to run and to be managed by the Android Studio. They are very easy to install, you just need to follow the instruction, which is, trust me, totally basic. Once you’ve gone through that process those installed SDKs can be found on the following path:
-if you are using Windows, check the C section, then username. You will see where the app data has the local section, and there you will find the Android.
-for Mac OS just go to the users’ section and in the library, you will find the Android section.
Let’s talk about the testing on the real device now! If you want some dynamic analysis to be done, you will then definitely need an Android device on which will the app run on. What is recommended while testing on the real advice? What are the benefits? You will definitely have the more natural area when testing like that rather than on some emulator.
Rooting. This is the first thing which is recommended when you’re testing on the real device. It actually means modifying the OS. In that case, you will easily run the commands as the root user. It is very important for you because you will have the privilege to fully control the operating system. Besides that, it will allow you to bypass the restrictions, for example, the app sandbox.
There is another thing about rooting that you definitely need to know. It’s risky! So, if you are going to take a part in it, you need to understand that there may be some consequences. Those can be voiding the warranty, making your device inoperable and unusable and it can create some additional security risk.
So, the best advice would be-don’t root the personal device. You have your private information on it and sensitive data right? You don’t want to risk that. Instead of rooting your personal device, you should decide to do it for some cheap and dedicated test device. For the example, you can easily run some devices from the Google’s Nexus series for your testing, because no matter how old they may seem, they can run the newest Android versions. So, this would be your perfect choice for testing!
What are the mobile devices that can be rooted?
Those are Virtually and Android, commercial versions of Android OS such as Linux OS evaluations at the kernel level etc. What do you need to do when you start rooting the device? First of all, you will need to unlock its bootloader. Besides that, evaluating the available network setup options also takes the first place. The device must be connected to the same Wi-Fi network while testing. The best advice for you would be to use the existing access point. The other option you have is to create the ad-hoc wireless network. Once you’ve done this, you will need to configure the proxy to the point of the interception proxy and then its CA certificate must be added. You must add it to the trusted certificates in the Android device’s certificate storage. Then, the request will show up in the interception proxy, and you are done.
Exploring the Testing Methods
First of all, will talk about the Manual static Analysis. Here we have the black-box testing, which provides you the access to the compiled library. It is important to know that it doesn’t provide you the access to the original source code. What about the white-box testing? When talking about the Android app security testing, it is almost the equivalent as the black-box testing. You will decompile most of the apps really easily.
What do you need here? The Android’s SDK and IDE. Those will act as the setup which is similar to the developer’s setup. Let’s say you are in the process of the black-box testing. You need to know that you won’t have there the access to the original form of the source code, but you will have the app package in Android’s .apk format most of the times. It can be installed easily and it will help you a lot to retrieve the parts of the source code.
will now show what exactly pulls the APK from the device!
$ adb shell pm list packages
(…)
package:com.awesomeproject
(…)
$ adb shell pm path com.awesomeproject
package:/data/app/com.awesomeproject-1/base.apk
$ adb pull /data/app/com.awesomeproject-1/base.apk.
Here the apk is providing the very easy method which retrieves the APK’s source code by the command line. Besides that, it has the packages dex2jar and the CFR which automate the extraction, decompilation steps and also the conversion. You can install it this way:
$ git clone https://github.com/b-mueller/apkx
$ cd apkx
$ sudo ./install.sh
What will this do is that it will copy the apkx to the /usr/local/bin. If you want to run it after this on the APK, you should do it this way:
$ apkx UnCrackable-Level1.apk
Extracting UnCrackable-Level1.apk into the UnCrackable-Level1
Converting: classes.dex -> classes.jar (dex2jar)
dex2jar UnCrackable-Level1/classes.dex -> UnCrackable-Level1/classes.jar
Decompiling to UnCrackable-Level1/src (cfr).
will talk about the Automated Static Analysis now. Here, you definitely need to use the tools which are efficient for the static analysis. Those will help you to have the access to the more complicated business logic. Here you have the plethora of the static code. Those are the analyzers which are available and they basically range from the open source scanners to even full-blown enterprise-ready scanners. You also need to keep in mind that it may happen that the analyzers don’t find all of the problems just by themselves. So, you will need to keep your eyes wide open and to carefully review each finding. You will then understand what the app is actually doing to improve your chances of finding vulnerabilities if they exist.
There are some open source tools which work on the automated security analysis of the APK you need to know about. Those are QARK, JAADAS, and Androbugs.
Okay, we saw what are the static tools and how they function. But, what about the dynamic analysis? They are different because they are performed while executing the mobile app. Tests can range and vary a lot. So, you will find easily some testing of the investment of the file system and also be monitoring the communication. They have the wide range of possibilities.
There are some several tools which support the dynamic analysis on the app and they mostly rely on the HTTPS protocol. Ones which are the most important for you and those you definitely need to know about are those so-called interception proxies. The most famous ones in this category are the OWASP ZAP and the Burp Suite Professional.
What does the interception proxy actually give you? You will find yourself in the man-in-the-middle position while testing! It is very useful for reading and modifying all of the app’s requests and also the endpoint resources. Those are used for testing the Authorization, Session Management, and more.
Drozer. This is the Android’s security assessment framework which will allow you to research the security vulnerabilities which may exist in the app. It assumes the role of the third-party app by interacting with some other applications on IPC’s endpoints and also on the underlying OS.
And finally, you need to learn about the potential obstacles you can come across while testing. The first and the most important advice would definitely be to advise with your team about getting the debug built for the security controls. It will allow you the more comprehensive analysis. The second thing you need to know about is that it is preferable to disable the root detection.
All in all, hope that you have enjoyed this lesson! I tried to make it interesting and easy to understand! Enjoy the testing process and take care for your safety!