IMCAFS

Home

android penetration test learning manual (3) reverse and audit of android applications

Posted by tzul at 2020-03-04
all

Three point one

Android App disassemble

Android applications are archives of data and resource files created during application development. The extension of an Android application is. APK, which means an application package. In most cases, it includes the following files and folders:

Classes.dex (file)

Android manifest.xml (file)

Meta-inf (folder)

Resources.arsc (file)

Res (folder)

Assets (folder)

Lib (folder)

To verify this, we can simply unzip the application using any archive manager application, such as 7zip, WinRAR, or any preferred application. On Linux or Mac, we can simply use the unzip command to show the contents of the compressed package, as shown in the following screenshot: here, we use the - L (list) flag to simply show the contents of the compressed package, rather than extract it. We can also use the file command to see if it is a valid compression package. Android applications are made up of various components that together create working applications. These components are activities, services, broadcast receivers, content providers, and sharing preferences. Before continuing, let's take a quick look at these different components:

Here, we use the - L (list) flag to simply show the contents of the compressed package, rather than decompressing it. We can also use the file command to see if it is a valid compression package.

Android applications are made up of various components that together create working applications. These components are activities, services, broadcast receivers, content providers, and sharing preferences. Before continuing, let's take a quick look at these different components:

Activities: These are visual interfaces with which users can interact. These can include buttons, images, textview, or any other visual component.

Services: these Android components run in the background and perform specific tasks specified by the developer. These tasks can include anything from downloading files from HTTP to playing music in the background.

Broadcast receiver: These are receivers in Android applications, listening for incoming broadcast messages through other applications existing in Android system or devices. Once they receive broadcast messages, they can trigger specific actions based on predefined conditions. Conditions can be SMS, incoming call, power change, etc.

Shared preference: the application uses these preferences to save small datasets for the application. This data is stored in a folder called shared Φ prefs. These small data sets can include name value pairs, such as user scores and login credentials in the game. Storing sensitive information in shared preferences is not recommended because they can be vulnerable to data theft and disclosure.

Intent: these components are used to bind two or more different Android components together. Intents can be used to perform various tasks, such as starting actions, switching activities, and starting services.

Content provider: these components are used to access structured data sets used by applications. Applications can use content providers to access and query their own data or data stored in mobile phones.

Now that we know the internal structure of Android applications and how they are composed, we can continue to reverse Android applications. When we have only. APK files, this is the way to get readable source code and other data sources.

Three point two

Reverse Android App

As we discussed earlier, Android applications are just archives of data and resources. Even so, we can't simply unzip the archive (. APK) to get readable source code. For these cases, we have to rely on tools to convert byte code (as in classes. DEX) to readable source code. One way to turn bytecode into a readable file is to use a tool called dex2jar. The. DEX file is the Dalvik bytecode converted by Java bytecode, which makes it optimized and efficient for mobile platform. This free tool just converts the. DEX file that exists in the Android application to the corresponding. Jar file. Follow these steps:

One way to turn bytecode into a readable file is to use a tool called dex2jar. The. DEX file is the Dalvik bytecode converted by Java bytecode, which makes it optimized and efficient for mobile platform. This free tool just converts the. DEX file that exists in the Android application to the corresponding. Jar file. Follow these steps:

1. Download the dex2 jar tool from https://code.google.com/p/dex2 jar /.

2. Now we can use it to run our application's. DEX file and convert it to. Jar format.

3. Now, what we need to do is go to the command prompt and access the folder where the dex2 jar is located.

Next, we need to run the d2j-dex2jar.bat file (on Windows) or the d2j-dex2jar.sh file (on Linux / MAC) and provide the application name and path as parameters. In the parameters here, we can simply use the. APK file, or we can even extract the. APK file, and then pass the classes.dex file, as shown in the following screenshot:

As we can see in the screenshot above, dex2jar has successfully converted the application's. DEX file into a. Jar file named helloworld-dex2jar.jar. Now, we can open this. Jar file in any Java graphics viewer (such as jd-gui), which can be downloaded from its official website http://jd.benow.ca /. 4. Once we download and install the jd-gui, we can continue to open it now. It looks like the following screenshot:

4. Once we download and install the jd-gui, we can continue to open it now. It looks like the following screenshot:

5. Here, we can now open the. Jar file converted in the previous step and view all Java source code in the jd-gui. To open the. Jar file, we can simply access file | open.

In the right pane, we can see the Java source code of the Java application and all the methods. Note that the recompilation process gives you an approximate version of the original java source code. This doesn't matter in most cases; however, in some cases, you may see some code missing from the converted. Jar file. In addition, if application developers use some protection against decompilation, such as Proguard and dex2jar, we will not see the exact source code when we use dex2jar or apktool to decompile the application; instead, we will see a bunch of different source files, which is not the exact representation of the original source code.

Three point three

Using apktool to reverse Android Application

Another way to reverse Android applications is to convert. DEX files to SmalI files. SmalI is a file format with a syntax similar to that of a language called jasmine. We won't go into the SmalI file format now. For more information, see the online wiki https://code.google.com/p/smali/wiki/ to learn more about SmalI. Once we download apktool and configure it, we are all ready to follow the instructions in the previous section. Compared with the JD GUI, the main advantage of apktool is that it is bidirectional. This means that if you decompile an application and modify it, and then recompile it using apktool, it can perfectly recompile and generate a new. APK file. However, dex2jar and JD GUI cannot do similar functions because they provide approximate code rather than accurate code. Therefore, in order to decompile an application using apktool, all we need to do is pass the. APK file along with the apktool binary to the command line. Once the decompilation is complete, apktool creates a new folder with the application name, which stores all the files. To decompile, we just call apktool d [app name]. APK. Here, the - D flag indicates decompilation. In the following screenshot, we can see the application decompiled with apktool:

Once we download apktool and configure it, we are all ready to follow the instructions in the previous section. Compared with the JD GUI, the main advantage of apktool is that it is bidirectional. This means that if you decompile an application and modify it, and then recompile it using apktool, it can perfectly recompile and generate a new. APK file. However, dex2jar and JD GUI cannot do similar functions because they provide approximate code rather than accurate code.

Therefore, in order to decompile an application using apktool, all we need to do is pass the. APK file along with the apktool binary to the command line. Once the decompilation is complete, apktool creates a new folder with the application name, which stores all the files. To decompile, we just call apktool d [app name]. APK. Here, the - D flag indicates decompilation.

In the following screenshot, we can see the application decompiled with apktool:

Now, if we go into the SmalI folder, we'll see a bunch of different SmalI files that contain the code for the Java classes that we wrote when we developed the application. Here, we can also open a file, change some values, and use apktool to build it again. In order to build a modified application from SmalI, we will use the B (build) flag in apktool.

apktool b [decompiled folder name] [target-app-name].apk

However, in order to decompile, modify and recompile the application, I personally recommend using another tool called virtual tenstudio (VTS). This tool provides similar functions with apktool, the only difference is that VTS provides a beautiful graphical interface, making it relatively easy to use. The only limitation of this tool is that it only runs in a Windows environment. We can download VTS from the official download link http://www.virtual-ten-studio.com/. Here is a screenshot of the decompilation of the application for the same project:

Three point four

Audit Android apps

Android applications often contain many security vulnerabilities, most of the time due to developers' errors and ignorance of security coding practices. In this section, we will discuss vulnerabilities in Android based applications and how to identify and exploit them. Content providers expose that many applications use content providers to store and query data in applications or data from phones. Unless you have defined that the content provider can use permissions to access, any other application can use the content provider defined by the application to access the data of the application. All content providers have unique uniform resource identifiers (URIs) for identification and query. The standard naming convention for content provider URIs starts with content: / /.

If the Android API version is less than 17, the default property of the content provider is always export. This means that unless the developer specifies permissions, any application can use the application's content provider to access and query data. All content providers need to be registered in Android manifest. XML. So we can use apktool for our application and check the content provider by looking at the Android manifest. XML file. The general way to define a content provider is as follows:

The general way to define a content provider is as follows:

So now, we will give an example of a vulnerable application and try to exploit the content provider to leak the vulnerability: 1. In order to decompile the application, we will use apktool to decompile the application using apktool d [appName]. APK. 2. To find the content providers, we can simply view the Android manifest.xml file that defines them, or we can use a simple grep command to get the content providers from the application code, as follows:

1. In order to decompile the application, we will use apktool to decompile the application using apktool d [appName]. APK.

2. To find the content providers, we can simply view the Android manifest.xml file that defines them, or we can use a simple grep command to get the content providers from the application code, as follows:

3. We can use the grep command to find the content provider, and use grep – R 'content: / /'. This command finds the content provider in each subfolder and file and returns it to us.

4. Now, we install the application in the simulator. In order to query the content provider and verify that the vulnerability is exploitable, we need to install the application in an Android device or emulator. Using the following code, we will install the vulnerable app.apk file on the device:

5. We can query the content provider by creating another application without any permission, and then query the content provider of the vulnerable application. To get information quickly, we can also use ADB to query the content provider, which we can see in the following command:

The following commands are run on the vulnerable application, and the output shows the comments stored in the application:

Here, we can also use another tool called drozer from MWR lab to find the leaked content provider vulnerability in Android applications. We can download and install drozer from the official website https://labs.mwrinfosecurity.com/tools/drozer/. 6. Once we install it, we need to install agent.apk to our simulator, which is located in the downloaded. Zip file. The agent is required for the interaction between the system and the device. We also need to forward a specific port (31415) each time we start the simulator to establish a connection. To install devices on Macs and other similar platforms, we can follow the online guide available at https://www.mwrinfosecurity.com/system/assets/559/original/mwri_drozer-users-guide_2013-09-11.pd.

6. Once we install it, we need to install agent.apk to our simulator, which is located in the downloaded. Zip file. The agent is required for the interaction between the system and the device. We also need to forward a specific port (31415) each time we start the simulator to establish a connection. To install settings on MAC and other similar platforms

7. Once finished, we can start the application and click the embedded server text. From there, we need to go back to the device, launch the drozer application, and enable the server by clicking the upper left toggle button called disabled.

8. After that, we need to access the terminal and start drozer and connect it to the simulator / device. To do this, we need to enter drozer console connect, as shown in the following screenshot:

9. Here, we can run the app.provider.finduri module to find all content providers, as follows:

10. Once we have the URI, we can now query it using the drozer application. To query it, we need to run the app.provider.query module and specify the URI of the content provider, as shown in the following screenshot:

If drozer is able to query and display data from the content provider, this means that the content provider leaks data and has vulnerabilities because drozer is not explicitly granted any permission to use the dataset. 11. In order to fix this vulnerability, developers need to specify the Android: exported = false parameter when creating a content provider, or create some new permissions, which another application must request before accessing the provider.

11. In order to fix this vulnerability, developers need to specify the Android: exported = false parameter when creating a content provider, or create some new permissions, which another application must request before accessing the provider.

Three point five

Unsafe file storage

In general, when developers store data for an application, they do not specify the correct file permissions for the file. These files are sometimes marked as globally readable and can be accessed by any other application without requiring permission. In order to check the vulnerability, all we need to do is access the ADB shell, and then use CD to enter / data / data / [package name of the app]. If we execute a simple ls-l here, we can see the file permissions of files and folders:

In order to check the vulnerability, all we need to do is access the ADB shell, and then use CD to enter / data / data / [package name of the app].

If we execute a simple ls-l here, we can see the file permissions of files and folders:

Here we can use find to search for permissions.

If we execute cat userinfo.xml, it stores the user name and password of the user of the application.

This means that any other application can also view and steal the user's confidential login credentials. This vulnerability can be avoided by specifying the correct file permissions when developing an application, and calculating the hash of passwords and salts together. Directory traversal or local file inclusion vulnerability as the name implies, a path traversal vulnerability in an application allows an attacker to read other system files using the provider of the vulnerable application. This vulnerability can also be checked using the tool we discussed earlier, drozer. Here, we use an example to illustrate the adobe reader Android application vulnerability found by seafastian Guerrero (http://blog.seguesc.com/2012/09/path-traversal-vulnerability-on-adobe-reader-android-application). This vulnerability exists in adobe reader 10.3.1 and has been fixed in later versions. You can download older versions of various Android applications from http://android.com. We will launch drozer and run the app. Provider. Finduri module to find the content provider URI.

This vulnerability can also be checked using the tool we discussed earlier, drozer. Here, we use an example to illustrate the adobe reader Android application vulnerability found by seafastian Guerrero (http://blog.seguesc.com/2012/09/path-traversal-vulnerability-on-adobe-reader-android-application). This vulnerability exists in adobe reader 10.3.1 and has been fixed in later versions. You can download older versions of various Android applications from http://android.com.

We will launch drozer and run the app. Provider. Finduri module to find the content provider URI.

Once we find the URI, we can now use app.provider.read to search for and exploit local file inclusion vulnerabilities.

Here, I try to read some files from the system, such as / etc / hosts and / proc / cpuinfo, which exist in all Android instances by default because it is a Linux based file system.

S

127.0.0.1 localhost

As we can see in the screenshot below, we have successfully used the adobe reader vulnerability content provider to read files from the Android file system.

Client injection attack client attack usually occurs when the application does not check user input. For example, during a query on a SQLite database, the application is parsing user input because it is in a query statement. Let's take an example of an application that checks the local SQLite database to authenticate users against login credentials. Therefore, when the user provides the user name and password, the running query will be as follows:

Let's take an example of an application that checks the local SQLite database to authenticate users against login credentials. Therefore, when the user provides the user name and password, the running query will be as follows:

Now, under normal circumstances, this will work, the user enters their real login credentials, and the query depending on the condition will return true or false.

But what if the attacker enters the SQL statement instead of the normal user name? Refer to the following code:

Therefore, in this case, even if the user does not know the user name and password, they can easily bypass it by using the 1'or'1 '=, which returns true in all cases. As a result, application developers must perform appropriate checks in the application to check user input. We can also use drozer's app.provider.query to exploit SQL injection vulnerabilities. Its syntax looks like:

We can also use drozer's app.provider.query to exploit SQL injection vulnerabilities. Its syntax looks like:

Now, this will return a list of the entire tables in the SQLite database, whose information is stored in sqlite'u master. You can also continue and execute more SQL queries to extract more information from the application. In order to use drozer's actual vulnerability exploitation, you can download their vulnerability application from https://www.mwrinfosecurity.com/products/drozer/community-edition/.

Three point six

OWASP mobile TOP10

The web application open security project (OWASP) is one of the standards concerning security and vulnerability search. It also publishes a list of the top 10 vulnerabilities, including the most common and important in a variety of platforms. The top 10 Guides for OWASP mobile can be found at https://www.owasp.org/index.php/projects/owasp'mobile'security'project'top'ten'mobile'risks. If we look at the OWASP mobile project, here are 10 security issues for the mobile applications it covers:

Weak server control

Insecure data storage

Insufficient transmission layer protection

Unexpected data disclosure

Lack of authorization and certification

Invalid encryption

Client injection

Security decision through untrusted input

Incorrect session handling

Lack of binary protection

Let's introduce them one by one, and quickly understand their relationship in mobile applications, and how we detect them: the first OWASP vulnerability in weak control of the server is weak control of the server. As the name suggests, the server does not send data from the mobile application to the server in a secure way, or exposes some sensitive APIs when sending data. For example, consider an Android application that sends login credentials to the server for authentication without validating the input. An attacker can modify credentials in such a way that they can access sensitive or unauthorized areas of the server. This vulnerability can be considered as a vulnerability in mobile and web applications. Insecure data storage simply means that application related information is stored on the device in a way that users can access. Many Android applications store user related private information or application information in shared preferences, SQLite (plain text format) or external memory. Developers should always remember that even if the application stores sensitive information in the data folder (/ data / data / package name), as long as the phone is root, malicious applications / attackers can access it. Transport layer protection is inadequate many Android developers rely on sending data over an insecure network, such as HTTP or a form that does not properly implement SSL. This makes the application vulnerable to all different types of attacks on the network, such as traffic interception, manipulation of parameters when sending data from the application to the server, and modification of responses to access the application's locked area. Unexpected data disclosure this vulnerability can occur when an application stores data in its own vulnerable location. These may include clipboard, URL cache, browser cookie, HTML5 datastorage, statistics, etc. An example is when users log in to their banking application and their passwords have been copied to the clipboard. Now, even malicious applications can access the data in the user's clipboard. Lack of authorization and authentication if Android applications or general mobile applications attempt to authenticate or authorize users based on client checks without proper security measures, these applications are most vulnerable. It should be noted that once the phone is rooted, most client protection can be bypassed by attackers. Therefore, it is recommended that application developers use server-side authentication and authorization for appropriate checks. Once the verification is successful, use randomly generated tokens to authenticate users on mobile devices. Invalid encryption this simply means using an insecure cryptographic function to encrypt the data part. This may include algorithms known to have vulnerabilities, such as MD5, SHA1, RC2, or even customized algorithms without appropriate security measures. Client injection is feasible in Android applications. The main reason is to use SQLite for data storage. We will perform injection attacks throughout the chapters of this book. In mobile applications, developers should always filter and verify user provided input or other relevant input through security decisions of untrusted input, and should not use them as they do in applications. Untrusted input often leads to other security risks in the application, such as client injection. Incorrect session processing when performing session processing for mobile applications, developers need to deal with many factors, such as the normal expiration of authentication cookies, security token creation, cookie generation and rotation, and the inability to invalidate back-end sessions. You must maintain the correct security synchronization between the web application and the Android application. The lack of binary protection means that applications cannot be properly prevented from being reversed or decompiled. Tools such as apktool and dex2jar can be used for reverse Android applications, which can expose various security risks of applications if they do not follow the correct development practices. To prevent application analysis through reverse attack, developers can use tools such as Proguard and dashboard.

Sum up

In this chapter, we learned to use various methods to reverse Android applications and analyze the source code. We also learned how to modify the source code and then recompile the application to bypass some protections. In addition, we saw how to use tools like drozer to find vulnerabilities in Android applications. You can also try out the various vulnerabilities in the exploit me lab by yourself through http://labs.securitycompass.com/exploit-me/ which is developed by security compass. In the next chapter, we'll take a closer look at traffic interception for Android applications and use it in our penetration tests.

In the next chapter, we'll take a closer look at traffic interception for Android applications and use it in our penetration tests.

Compiled by dragon messenger

Original: learning testing for Android devices

By Aditya Gupta