Được tạo bởi Blogger.

Bài Mới ...

Setting Up Penetration Testing Lab Using Mobexler

Written By AKADEMY on Thứ Tư, 13 tháng 5, 2020 | 02:36

Requirements

  • Hard Disk: ~50 GB
  • Ram: 4 GB

Steps

  • Download the ova file from links given above.
  • Install VirtualBox latest version available: Download Link
  • Once installed, start virtual box, go to File → Import Appliance → Select the Downloaded OVA file →Click Import → Click Import.
  • Once the virtual box image has been imported successfully, go to Mobexler v1.0 → Settings → Network and confirm that one of the network cards has NAT and other has Host Only Adapter connection. Note: The name of Host Only Adapter can change depending upon the operating system you are using and the name you have given to it.
  • Start the Mobexler virtual machine, and login with the password: 12345
  • Once logged in, verify if you can connect to the internet. Go to Applications → Internet → Launch Firefox and open any website.
    Note: Mobexler comes preinstalled with Android Studio. But because of the limitation of running an ARM based emulator inside the virtualbox, the emulator becomes extremely slow (10 times slower). Due to this reason, we strongly suggest setting up the lab using Genymotion as the emulator, or using any real android device as the test device.

Setting Up Genymotion As a Test Device/Emulator

  • Go to the Genymotion Website and download a “Genymotion For Fun” application → Genymotion For Fun.
  • Installed the downloaded application, register/sign in to free account and launch “Genymotion” from application/program list. Note: For testing, you are free to download and setup any available genymotion image. In this tutorial, we will use “Google Nexus 5X - 7.0 API 24”.
  • Now from the genymotion application, select the device “Google Nexus 5X - 7.0 API 24” → Install
  • Once the Genymotion device image has been downloaded, run the image to make sure it’s working fine.
  • Now, go to the website ​https://apkpure.com/​ and download the APK for “Wifi ADB” application.
    Link: Link: ​https://apkpure.com/search?q=wifi+adb
  • Once the apk is downloaded, simply drag and drop the apk over the running Genymotion Device. This will install and launch the application, Wifi ADB. 8.Now, go to setting of Android Emulator → WiFi settings → Forget Wifi.
  • Once the wifi has been disconnected, go to Wifi ADB application and select the button to start Wifi over ADB. If asked for Root Permissions → Select Allow or Allow Always.
  • Ensure that the ADB is running over a wifi address which is on “Host-only Adapter”, generally it will start with 192.168.X.X
  • Go to Mobexler → Launch Terminal from Dock at bottom → Enter the command “adb connect IP:PORT”. Here, IP:PORT is the IP address and port which is showing on Wifi ADB application.
  • Launch Android Studio, from Applications → Android Zone → Android Studio.

Android Application Penetration Testing: Setting up, Certificate Installation and GoatDroid Installation

Written By AKADEMY on Thứ Tư, 20 tháng 9, 2017 | 00:01

To begin with mobile application penetration testing on the Android platform, we have multiple tools available that can be easily downloaded and installed to prepare the environment testing.These tools will help us to set up a virtual device serving as a smart phone using Android and the mobile application that is installed will undergo security testing.
In this article we will discuss:
  1. Setting up the emulator
  2. Setting up the proxy (Burp Suite)
  3. Installing the certificate
  4. Installing the test application (Goatdroid).
Setting Up the Emulator
The Android SDK can be downloaded from the following link: http://developer.android.com/sdk/index.html. Depending on what operating system you are working on, you can download it for Linux or Windows. I will be using Windows 7 for the demonstration.
After downloading it, you can extract the bundle and, as you can see, inside the bundle there are SDK manager.exe and other folders. Right now, we want to set up an emulator, so we will launch Android SDK manager to create our AVD (Android virtual device); this will be our virtual Android phone, on which we will be installing apps.

After launching the Android manager, go to Manage AVDs and add new. You can create a new AVD by giving it a name like Myandroid. You can select any device; I have selected it as Nexus 4. Select the target as the Android version that you are interested in. Other options are very clear and you can select accordingly. You can assign RAM and make sure to give some space for an SD card, as it will be useful later on in this post. Also, don’t forget to select the snapshot option so it will save the state of the AVD.

As you can see, MyAndroid appears in the list of AVDs and it is ready for use. Let us start the device.

The virtual device is launched, as we can see the Nexus 4 virtually.

To test the mobile that will be installed in this emulator, we will need an intercept proxy like Burp Suite to capture the requests/response. I am using the free version of Burp Suite for this demo. First, we will configure Burp Suite to listen on external interfaces. In Proxy → Options → Proxy Listeners → Edit → Binding select “Specific address” or you can also select it to listen on “All interfaces.” This will allow the virtual device to connect to Burp Suite.

To connect to Burp Suite inside the virtual device, go to Settings → Wireless and networks → more →VPN → Mobile networks →Access Point Names → Select the default APN of the device and Edit Access point. Set the proxy and port as the IP of the main system and the port on which Burp is running. Refer to the screenshot below:

This will allow Burp Suite to intercept all the requests generated by this virtual device. As you can see in the screenshot below, when we launched the browser, the request generated to Google was intercepted by the Burp Suite proxy in the middle, which confirms that our settings are correct and are working fine.

Also, you may notice that, when we browse a site hosted over HTTP, it generates a pop-up notifying us that the connection is untrusted.

To avoid this pop-up every time we browse a site hosted over HTTPS, we will install the Burp certificate in the device so that browser of the VD will trust the Burp Suite and will smoothly allow the communication. This will save our time while we perform security testing. To install the Burp Suite certificate, first we will import it.
Let us browse any web application hosted over HTTPS from the browser of our main system (Firefox, in my case), which has a proxy configured as Burp Suite. Please note that I have configured my Firefox browser to use Burp as proxy by changing the settings at Tools → Options → Network → Settings → Manual Proxy configuration. Refer to this screenshot:

As you browse the website, the browser will generate the alert saying the connection is untrusted. Click on “Add Exception” and then you can go to the “View.” To import the certificate, see the “Details.”

You can select “PortSwigger CA,” export it, and save it on your system. The saved certificate will be in the .crt format.

Our next task is to install this certificate in the virtual device. Let us first push this certificate inside the virtual device. Here we will be pushing the certificate into the SDcard. One way to push it is by using the “adb push ” command to transfer the certificate to the sdcard of the VD.

As we see in the sdcard folder, the PortSwiggerCA.crt is successfully saved.

So our certificate is inside our virtual device. Now it is time to install the certificate. Go to Settings → Security → Install from SD card.
After clicking OK, the PortSwiggerCA certificate will be successfully installed.

Also to verify the installation, Go to Settings → Security → Trusted Credentials. You can see in USER that the installed certificate is successfully displayed.

So we are all set for mobile app penetration testing.
The next step is to install the application in the virtual device that will undergo security testing. The test application we will be using is Goatdroid (https://www.owasp.org/index.php/Projects/OWASP_GoatDroid_Project) by owasp.
The application can be downloaded from the following link:
https://github.com/downloads/jackMannino/OWASP-GoatDroid-Project/OWASP-GoatDroid-0.9.zip
This Android application is purposefully made vulnerable for educational purposes. We will be pushing this application in the AVD. Let us download this zip file and extract the contents.

Let us have a look what it contains.
goatdroid_apps contains two vulnerable apps:
  1. FourGoats
  2. HerdFinancial
We will be installing these two apps in the AVD. Also, goatdroid-0.9.jar will launch the server for these two apps to communicate with.
Let us launch goatdroid-0.9.jar:

You can specify the location of the virtual device and the SDK path in order to identify the virtual device that this application is going to access. As you can see, it can also push the apk files (FourGoats and HerdFinancial) into the virtual device and install these vulnerable apps. Just make sure that the path specified for the virtual device and SDK path is correct.
Let us push the app into the device.

And, as you can see, the app is successfully installed in the device and will be displayed in the VD.

Start the web service, as we are going to log in to the FourGoats. Let us first provide some destination info to the FourGoats application, to access Burp Suite (IP 192.168.4.9 port 8082) and the port on which the web service will be accessed(9888).

Now you are set to log in. Use the username goatdroid and password goatdroid and you are ready to test this application, with a successful login and Burp Suite in the middle to capture and modify the request. In the same way, you can push the other app, HerdFinancial, and test it.

Android Application Security Testing Guide: Part 2

Written By AKADEMY on Thứ Ba, 19 tháng 9, 2017 | 23:50

In our last part of this series (Android Application Security Testing Guide: Part 1), we discussed static analysis of Android APK files on the security background, and we tried to find any sensitive information which we can collect. In this part, we will head to our second phase, i.e. Dynamic Testing. But before going further, don’t you want to test your skills you learned in the first part? I have created a small challenge for this. The below link will take you to an APK file I have uploaded to Dropbox. You have to download the APK file and perform a thorough static analysis on it. The challenge is to find out the email ID which is hardcoded in the APK file.
HINT: Email ID contains “sam” as string.
For those who were unable to find the link of m0biliz3r, here is the link.
For starting off with dynamic testing, we first need to install the application into the emulator. Either we can install the application from Play Store directly (if available), or we can use the APK file if the client has provided us with this.
The first step in installing the application in the emulator is of course to open the emulator. Then we will use ADB (Android Debug Bridge), as this provides an excellent interface between the emulator and our computer machine. For both cases, we will need our emulator up and running.
To start the emulator, you can follow any of the two approaches. You can click on AppUse Dashboard, go to the Android tab and then click on “Launch Emulator”. This will start the emulator in the default settings saved in AppUse. If you want to customize the settings, then go for manual approach. For this go to “/AppUse/Android/android-sdk-linux_86/tools/”.
Image 1: Contents of “tools” directory
To launch the emulator, type in the following command:
./android avd
And the AVD (Android Virtual Device) Manager window will come up. This window will list down all the virtual devices you have created (if any) along with their respective configurations. By default, AppUse comes along with a default device, so your AVD manager must list it as shown in image below.
Image 2: Basic Android Virtual Device Manager
By using the new option, you can either create a new device of your own choice with configurations you want, or can customize the existing one. The edit dialogue box will look something like the below image.
Image 3: Edit Android Virtual Device Dialog Box
Please also note down that the emulator keeps on running through with various updates. Also with the launch of the new version of Android OS, there are certain packages you might wish to install. Al these things can also be done from AVD Manager. In case you wish to install a new one, or want to see the installed packages, go to “Tools” in the menu bar and select “manage SDK”. Android SDK Manager will come up, and it will list the available packages as well as the installed packages. The packages which are already installed will have a check mark in the check box before them, as shown in the image below.
Image 4: SDK manager
To install any new package, mark the check box in front of the package and install on “Install X Package(s)” where X is the number of packages selected. With the similar approach, you can delete the packages. Keep in mind that this step will require an Internet connection obviously, as you are going to download some packages.
Fine, so once we are done with editing the SDK and AVD, go back to the main window of AVD Manager and start the machine. It will ask you to enter any runtime customization (if required), like clear old data, or define a new custom screen size.
Image 5: Dialogue box popping up just before the launch of the emulator
Once done, launch it. The emulator will start and this might take some time, so get loaded with patience. Once it is loaded, enter your emulator and enjoy the look and feel. Yeah, I mean it. Enjoying the look and feel can comprise of exploring your virtual device and different settings, and if you own an Android phone, you can compare the features as well. If you don’t see certain features, you must be missing out on some packages.
A PIC OF A RUNNING EMULATOR
Ahh! So finally, let’s go ahead with installing the application into the emulator. Get the APK ready in your AppUse machine and go to the following path:
/AppUse/Android/android-sdk-linux_86/platform-tools
Image 6: ADB in “platform-tools” directory
As we already discussed, ADB stands for Android Debug Bridge and helps you do a lot of tasks on the emulator from your machine. Installing the application is one of them.
adb install <name of APK>
If you want to install it to sdcard, i.e. external memory, then you can use -s. Once done, go back to your emulator and check if you have that application installed or not. As the application installs, it goes to the APPS menu as well as in the list of the installed applications in the application manager. You can use any of these places for ensuring the installment of your application. As soon as the app gets installed, check if you can use the application properly, all the functions are working, etc. Once the prequalification is done, we will start off with dynamic testing.
As already mentioned, in dynamic testing we will focus purely on the way the application is processing the requests on the server side. To be able to get more control on the requests and response, we will need an intermediate proxy which will enable us to see the raw requests and responses going to and from the server. For this, we will use Burp Suite. So let’s start configuring our proxy.
To configure the proxy go to Settings. A screen something like the below one will come up. Select “More”.
Image 7: Settings options in the emulator
In the next menu, select “Mobile Networks”.
Image 8: Options in “Wireless & networks” section
Select Access Point Names option as shown in the image.
Image 9: Mobile network settings
No, there must be a mobile network already configured, and the name of the network will be “Telkila”, as shown in the image below. Choose this network.
Image 10: Access Point Names List
The next window will give you an option to configure a proxy on this network. In case you have more than one network coming in the APNs list, make sure you select the one which you would be using to test the application.
Put the IP address of your interface where you will be listening the traffic, i.e. where you will run Burp. Down to that, put the port number on which you want to listen. By default it’s 8080 in Burp, but feel free to change it, just make sure you have same port number configured at both end points, i.e. in Burp and in this menu. Use the image below to get more ideas on how to configure your proxy.
Image 11: Proxy configuration in the emulator
By saving these settings, you will have successfully configured the emulator to route the traffic through this IP on 8080 port, i.e. our Android VM is configured to send all the web traffic to our web proxy. So the next step must be to set up the web proxy. We have lot of web interception proxies available in market, but for this demonstration purpose, I would suggest you use Burp, as it is one of the most popular proxies. Use the professional version or the free one. Appuse already has the free version of BurpSuite in its arsenal. To open it up, go to directory:
/Appuse/Pentest/Burp
and type:
java -jar burpsuite_v1.5.jar (the name of the jar file may change so please check it using “ls”).
Here I have configured the other version of Burp, so will use the command as shown in the figure. This will open the Burp Interface to you.
Image 12: Screenshot of BurpSuite
Now go to the “Proxy” tab, select the “Options” tab. Select the default configured interface, and click on “Edit”.
Image 13: BurpSuite Proxy Configuration
If you are already familiar with Burp, use it your way, but if you are using it for the first time, make the settings exactly same as above. In the specific address option, select the IP address you want to listen to traffic on. If you have an emulator on one machine (say A) and BurpSuite on other one (say B), then in the emulator’s proxy settings you have to put the IP address of B machine. Similarly, at B, you will have to mention in Burp that you want to specifically listen on this IP.
Another catch here is that you can choose the “All interfaces” option, but this might create a lot of traffic for you if you have other interfaces also working in your machine, and due to lot of requests response going through, you might miss the important one.
So once you are done with all this hustle and bustle, let’s go back to our emulator and check if we can intercept the traffic or not. First of all, set the interception to be on as shown in the figure.
Image 14: Proxy > Intercept > “intercept is on”
Now start the browser in the emulator and open any site using HTTP protocol. (Yes, I said HTTP and not HTTPS. We will solve the HTTPS issue later on in the next part of this series.) So for example, let’s open http://3ncrypt0r.blogspot.com. This must not open the browser until and unless you will forward it. Now go to Burp, and you will see a GET request to 3ncrypt0r.blogspot.com waiting for your action.
Image 15: Raw HTTP Request intercepted in BurpSuite
As soon as you will click “Forward”, it will go to the server and as the server will respond back, and you will see the response in Burp. Now there are chances that you might not see any response in Burp. If that’s the case, go to the options tab in the proxy section and mark the check box against “Intercept response based on the following rules”, as shown in the figure.
Image 16: BurpSuite Configuration for getting HTTP responses
This being done, you will start receiving responses in Burp.
Image 17: HTTP Response captured in BurpSuite
Now again when you will click on “Forward”, the response will go the browser and you must be able to see the web page in the browser. So this was a basic manual proxy configuration for testing your application dynamically, i.e. on server side logics and communications. You can use any other intermediate proxies like Charles Proxy, ZAP, etc. I used Burp as I am more handy and comfortable with Burp.
So we discussed the basic setup for doing dynamic testing of our applications. No doubt there are certain catches which you will encounter while doing this, for example:
  1. Issues with SSL traffic which goes on HTTPS protocol.
  2. Applications which use a specific mobile network and hence you will not be able to test them on the emulator.
  3. Frequent issues you might face with the emulator.
Don’t worry about that; we have a lot of things to be covered later and we will definitely solve all these problems. While I write the next article, you practice the things you learned in this article. There are a lot of vulnerable applications which come by default in Appuse and Android Tamer.

Android Application Security Testing Guide: Part 1

Android is a Linux kernel mobile platform that has been popular throughout its existence on a huge variety of devices, especially mobile smartphones. Most organizations, ranging from banking to telecom companies, have also come up with their apps for Android. Just like generic web applications, these mobile applications need a pen-test exercise as a part of their SDLC life cycle. This market is projected to reach a huge size by the end of 2014 with the growing demand for high end smartphone applications. Also, people generally rely too much on their Android devices, so compromising them might lead to the loss of a good amount of critical data, including passwords, mails, etc. Therefore, security testing of the applications carrying sensitive user data is very important.
This series is a solution for those who want to take a deep dive into mobile application security testing, as these articles focuses on the approach for pen-testing Android-based mobile applications. It also provides an introduction to the tool set available for the Android platform. During the whole series, we will try to understand the complete process of mobile application testing in a very comprehensive manner.

Speaking in general, the Android platform basically needs to be secure at two levels, i.e., the application level and the device level. For application level security, we need to uncover the bugs in applications that are going to be installed on the device. For this, we look out for server-side as well as client-side security issues in the application. For a clearer understanding of what we are going to cover, let’s make an outline of this series:
  • Get the APK file.
  • Decompile the APK file.
  • Install the APK.
  • Intercept the requests.
  • Check for local storage.
There are a lot of tools that we require for testing. To reduce the time for installing everything manually, we will opt for App-Use, which is a freely available distribution for Android application security testing. There is another VM, i.e., Android Tamer by @anantshri ,which also contains a lot of tools for this exercise including tools for mobile testing, pen-testing, ROM modding, etc., and can be found at his blog.
Two basic and essential things are:
  • A phone emulator (Android SDK)
  • A regular web application proxy (e.g., Burp Suite, Mallory, etc.)
There are already a lot of tools in this App-Use, namely apktool, smali, baksmali, manifest explorer, jdgui, dex2jar, Android SDK, adb, burp suite, etc. We will explore each of them one by one either for static or dynamic testing. Before we start off with the testing methodology, let’s have a quick understanding of some important tools:
Android SDK—This is by far the most important tool for the whole pen-test exercise. Android SDK is a mobile device simulator where you install your applications and use the application the way you use it on your mobile device. SDK gives you almost all functionalities that a mobile device will give you, except for the availability of a SIM card, which can be tweaked as well. We will discuss this tweak stuff in the later part of our series.
Image 1. Typical view of Android Emulator
Burp Suite—Burp Suite is an intermediate proxy that is generally used to intercept the traffic in between your application and the end-point server. Apart from interception, it has some useful tabs, such as:
  • Repeater, used for capturing a request and analyzing it in case you don’t want the involvement of the browser every time.
  • Intruder, used for automating customized request for attacks on apps.
  • Scanner, which is more useful for some automated testing while you are manually testing the application logic.
  • Sequencer, used for analyzing the randomness in random tokens being generated by the application from server side.
  • Decoder, used for a quick encode/decode task when you encounter a encoded string in your assessment.
Burp Suite is mainly required in the dynamic testing phase of our penetration testing exercise.
Image 2. Typical view of Burp Suite Proxy
ADB (Android debug bridge) *2—ADB is a very useful command line tool that comes along with the Android SDK. This allows you to communicate from your system to the Android device in terms of file transfers, application installations, working on device shell, etc. This has mainly three components:
  1. A client that runs on the main machine. As soon as you pass any adb command, a client is invoked.
  2. A server that runs as a background process on the main machine and manages the communication between the client and ADB daemon.
  3. A daemon that runs as background process on the device.
ADB gives you huge flexibility while interacting with the device. Some of the most commonly used commands that might help you are:
  • adb shell—Starts a remote shell in the target emulator and you can work on device as if you are physically using it.
  • adb install<apk_file>—Installs the given APK file into the device. –s will make it install on the /sdcard.
  • adb push—Copies a file from machine to your device.
  • adbpull—Copies a file from device to your machine.
  • adblogcat—Prints log data on the screen.
Okay, enough tool talk. Time to start testing. The first step before starting the test is to download the VM image of App-Use from their website and extract the files in a folder. Open this file in VMware-player. Assign at least 1 GB of ram to the machine for to avoid system lagging while doing work and open the virtual machine.
Image 3. App-Use Desktop
In order to go further, we now need the APK file. This can be either downloaded from some source, or you can directly install in the device from the Google Play store. Once installed, this will make the application come up in your application menu. And now you can browse/use the application.
To get the APK file:
  1. If your client / target provides you this file directly, there are no worries.
  2. But many organizations do not give you the APK file; they expect you to get their application from the Google Play Store. In this case, Install the file in your phone from Google Play. And the Android SDK does not contain Google Play services installed by default. To install it either you can install the Play store in App-Use itself or you can use the free version of the Genymotion emulator as well. You can easily install a Google Play store in your mobile device as well. I found the later one very comfortable for me. And if you have an Android phone, you are a lucky chap. Once you have installed the application in your device, you need another application called “App Backup and Restore” for extracting the APK file. Open the app and it will look something like:
Image 4. Backup & Restore Application
To extract the APK file for any application, mark the checkbox in front of the application and click on “Backup.” You can also backup more than one application at a time. Close “backup and restore,” and find the APK file in the /data folder. Copy the file and get it ready for your emulator.
So we now have the APK file with us. We will divide our testing approach into two parts:
  1. Static analysis—In this phase, we will try to uncover the vulnerabilities on the client side, i.e., insecure storage, etc. The objective will be to find out some critical data that can be gained from the APK file itself.
    So let’s understand a bit about the APK file. APK files are actually zip format packages based on the JAR file format. the MIME type for Android these files is application/vnd.android.package-archive. To make an APK file, a program is first compiled and then all the contents of the program are packed into one file. Therefore, this APK file will anyway contain all the program’s code (in DEX files), all resources, certificates, manifest file, etc. which we can reverse-engineer by either following a set of steps or using some tools that are available for this, as well.
    If you want to try this out on a vulnerable application, App-Use contains some vulnerable apps at “/Appuse/targets/” path.
    Manual approach—Copy the APK file to a new location. For instance, we are using ExploitMe.apk.
Image 5. Target APK file
Rename the file extension from “.apk” to “.zip.”
Image 6. Filename after changing the extension from apk to zip.
Extract the contents of this zip file as shown in the figure below.
Image 7. Result of extracting the ZIP file
This will give you the contents of the APK package, which you further need to explore. But before going that, let’s understand what exactly are the functions of these files and folders*1
  • META-INF directory:
    • MANIFEST.MF—This file simply enumerates the files that are included in the distribution, either for processing by various packaging tools, or for human use.
    • CERT.RSA—The certificate of the application.
    • CERT.SF—The list of resources and SHA-1 digest of the corresponding lines in the Manifest.MF file.
  • lib: This directory contains the compiled code that is specific to a software layer of a processor. The directory is split into more directories within it:
    • armeabi—compiled code for all ARM based processors only.
    • armeabi-v7a—compiled code for all ARMv7 and above based processors only.
    • x86—compiled code for x86 processors only.
    • mips—compiled code for MIPS processors only.
  • res: This directory containing resources not compiled into resources.arsc.
  • assets: This directory contains applications assets.
  • AndroidManifest.xml: This is an additional Android manifest file, describing the name, version, access rights, referenced library files for the application.
  • classes.dex: The classes compiled into the DEX file format understandable by the Dalvik virtual machine.
  • resources.arsc : This is a file containing precompiled resources, such as binary XML, for example.
As classes.dex contains the whole bunch of code, it’s quite obvious that if must be handled with care. “Dex” stands for Dalvik executable format. As another option, these files can also be collected from the “/data/Dalvik-cache” folder.
Image 8. Existence of DEX file in dalvik-cache folder.
Once you have collected all these files, the next step is to analyze this information with the Java source code. Start with android_manifest.xml; as mentioned above, this file contains the file permission for the application while accessing the Android operating system on the device. Open the file in any text editor.
Image 9. Contents of a typical Android Manifest.xml file
We can see all the permissions assigned to each application. While exploring the application on the device, check if the website is assigned any unrequired permission. For this, we can either use dextojar for converting the Dalvik executable code to the corresponding Java code in the form of a JAR file. To use it, go to “/AppUse/Pentest/dex2jar/dex2jar-0.0.9.15/” and execute the following command:
dex2jar.sh <path_to_dex_file>
By default it will put the output in the same directory.
Image 10. Converting DEX file to JAR file with the help of de2jar
Now we have the JAR file, which can be analyzed for any malicious strings within the package to help us in further operations. There is a utility called jdgui that can be used for this. To open this, go to “Terminal” and type “jdgui.” Once the application gets loaded, go to “open” and locate the JAR file. This will give you the whole package in a hierarchal view. Navigate manually through all these class files and check if any sensitive data is present. When I do my pen-testing exercise for clients, most commonly I found their API secret keys, sometimes internal IPs, and quite a few times the username, password, or database strings. Here is the snippet of the class files in jdgui.
Image 11. Opening up the JDGUI to view the contents of JAR file
Image 12. Contents of Jar file in form of class files
Another option is to decompile the DEX file to a SMALI file, which is an assembly language specifically designed for this purpose only. This can be done by using the utility apktool, which accepts the APK file as an input and give the folder SMALI files as output. The approach of using apktool has another advantage over dex2jar, i.e., it makes it quite easy to save the changes and recompile the APK file with modified classes. Below is the basic syntax for apktool:
apktool<d><path_to_apk_file><path_for_output_directory>
Image 13. Decompiling the apk file using apktool utility
Image 14. Decompiles class files in output folder.
By now you have got all the SMALI files, which contain the Java code in clear text. So go through each of the files and check if it contains any sensitive data. But isn’t there an overhead? Definitely there is. There is a small utility by teams2n called mobilizer.py to automate this stuff. The tool aims at doing all the things I mentioned above in an automated manner so, as a tester, you have to only pass the APK file and the tool will tell you any sensitive information leaking in the package. You can download it from their github page.
Run mobilizer.py and pass the filename as parameter. As of now, it only accepts the relative paths and stores the result in the file “logfile.log” in the same directory.
Image 15. Using m0bliz3r for automated sensitive data investigation
Image 16. Results from m0bliz3r in logfile
As you can see, this tool will give you a list of sensitive strings found in the APK file. One point to note is that this tool only searches for strings in a simple way and might give you results where the username was written as string and original username was not present (quite obviously).
Now we have finished our first part, i.e.. “Reverse Engineering of APK file.” So far, we have discussed the techniques for decompiling and reversing the Android package manager file. This is all we need to test before installing the application into the emulator. We will discuss the techniques and challenges that come our way while doing the dynamic testing for Android applications in Part 2 of our “Android Application Security Testing Guide Series.”
Stay Tuned…
Comments and feedbacks are highly appreciated for giving me more idea about what you guys want this series to cover.
References
*1. http://en.wikipedia.org/wiki/Manifest_file
*2. http://developer.android.com/tools/help/adb.html

Tài Liệu CEH v10 (Book & Lab)

Xem thêm »

New 1

Xem thêm ... »

Tài Liệu Metasploit F/W

Xem thêm ... »

New 2

Xem thêm ... »

Tài Liệu [OSCP] / Video & Doc

Xem thêm ... »

New 3

Xem thêm ... »
 
Trung Tâm Đào Tạo An Toàn Thông Tin Thao Trường Mạng Online Là Gì | Học An Ninh Mạng Trực Tuyến | CEH VIỆT NAM
Copyright © 2013. MOBISEC EDU VN - All Rights Reserved
Web Master @ AM4W@NH
Contact @ Đông Dương Giáo Chủ