Android App Pentesting: Architecture & Security Features for Effective Testing, Apuntes de Informática

¡Descarga Android App Pentesting: Architecture & Security Features for Effective Testing y más Apuntes en PDF de Informática solo en Docsity!

by Atul Singh

Android Mobile App Pentesting

Mobile application pentesting is an upcoming security testing need that has recently obtained more attention with the introduction of the Android, iPhone, and iPad platforms, among others. Android is the biggest organized base of any mobile platform and developing fast—every day. Besides, Android is rising as the most extended operating system in this viewpoint because of different reasons. However, as far as security, no data related to the new vulnerabilities that could prompt weak programming at this stage is being revealed, realizing that this stage has an outstanding attack surface. After web applications, a bigger con- cern is mobile application penetration test. Let’s start with some basics.

Understanding the Android Operating System: Below is the basic architecture for an Android device,

might be you are familiar with some components. Let’s start from the bottom: ➡ Linux Kernel: Linux kernel is the base for a mobile computing environment. It provides Android with several key security features, like:

• A user-based permissions model
• Process Isolation
• Extensible^ Mechanism^ for secure IPC

• Content Provider -^ Content Provider component supplies data from one application to others on request. You can store the data in the file system, an SQLite database, on the web, or any other persis- tent storage location your app can access. Through the content provider, other apps can query or even modify the data (if the content provider allows it). Content Provider is useful in cases when an app wants to share data with another app.
• Resource Manager^ – Provides access to non-code embedded resources such as strings, colour set- tings and user interface layouts.
• Notifications Manager^ – Allows applications to display alerts and notifications to the user.
• View System^ – An extensible set of views used to create application user interfaces.
• Package Manager^ – The system by which applications are able to find out information about other applications currently installed on the device.
• Telephony Manager^ – Provides information to the application about the telephony services avail- able on the device such as status and subscriber information.
• Location Manager^ – Provides access to the location services allowing an application to receive up- dates about location changes. ➡ Applications:^ Located at the top of the Android software stack are the applications. These comprise both the native applications provided with the particular Android implementation (for example, web browser and email applications) and the third party applications installed by the user after purchasing the device. Typical applica- tions include Camera, Alarm, Clock, Calculator, Contacts, Calendar, Media Player, and so forth. ! In the above paragraphs, I have introduced Android architecture and information about various layers. Android apps are written in the Java programming language. The Android SDK tools compile your code along with any data and resource files into an APK: an Android package, which is an archive file with an .apk suffix. One APK file contains all the contents of an Android app and is the file that Android-powered devices use to install the app.

An APK file is an Archive that usually contains the following directories: ➡ AndroidManifest.xml: The AndroidManifest.xml file is the control file that tells the system what to do with all the top-level components (specifically activities, services, broadcast receivers, and content providers de- scribed below) in an application. This also specifies which permissions are required. This file may be in An- droid binary XML that can be converted into human-readable plaintext XML with tools such as android- apktool. ➡ META-INF directory:

• MANIFEST.MF: the Manifest File.
• 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:^ The directory containing 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 X
• mips:^ compiled code for MIPS processors only ➡ res:^ The directory containing resources not compiled into resources.arsc (see below). ➡ assets: A directory containing application’s assets, which can be retrieved by AssetManager.

• For example, a service might play music in the background while the user is in a different application, or it might fetch data over the network without blocking user interaction with an activity.

Broadcast Receiver

• A broadcast receiver is a component that responds to system-wide broadcast announcements.
• Many broadcasts originate from the system—for example, a broadcast announcing that the screen has turned off, the battery is low, or a picture was captured.
• Apps can also initiate broadcasts—for example, to let other apps know that some data has been downloaded to the device and is available for them to use.
• Although broadcast receivers don’t display a user interface, they may create a status bar notification to alert the user when a broadcast event occurs.
• More commonly, though, a broadcast receiver is just a “gateway” to other components and is intended to do a very minimal amount of work. For instance, it might initiate a service to perform some work based on the event.
• An application may register a receiver for the low battery message for example, and change its behavior based on that information.

Activating Components

• Three of the four component types—activities, services, and broadcast receivers—are activated by an asynchro- nous message called an intent.
• Intents bind individual components to each other at runtime (you can think of them as the messengers that re- quest an action from other components), whether the component belongs to your app or to another.
• In the upcoming post, we will be using Drozer which uses intents to showcase the vulnerabilities. Application Security Features by Android Operating System

Android Permission Model

By default, there are some protected API’s in the Android operating system which can only be accessed by the operat- ing system. The Protected APIs include:

• Camera functions
• Location data (GPS)

• Bluetooth functions
• Telephony functions
• SMS/MMS functions
• Network/data connections Below is the Permission Dialog while installing the famous social networking app Facebook. Before Going Into the Battle, You Should Know About Your Arsenals: ➡ Android Testing Distributions:
• Appie:^ A portable software package for Android Pentesting and an awesome alternative to existing^ vir- tual machines.
• AndroidTamer:^ It is a virtual/live^ platform for Android Security Professionals.
• AppUse:^ AppUse is a VM developed by AppSec Labs.
• Santoku:^ Santoku is an OS and can be run outside a VM as a standalone operating system. ➡ Reverse Engineering and Static Analysis:
• APKInspector:^ It^ is a powerful GUI tool for analysts to^ analyze^ Android applications.

➡In the next step, check whether the device is connected or not. Type -

• adb devices , it will give us the list of attached devices ➡Install the Drozer apk file in emulator, you can simply drag and drop the file into the emulator or you can install it via Santoku. Set the path of the file and type:
• adb install^ drozer file name.apk ➡After installing Drozer, set the password in Drozer console and enable ssl.

➡After this, turn on the Drozer switch and type the following command for connection

• adb forward tcp:31415 tcp: ➡After this, run Drozer, type command in terminal
• drozer console connect ➡Here I’m going to demonstrate with a few vulnerable applications like OWASP GoatDroid, InsecureBankv2, etc. ➡First install the catch vulnerable application.
• adb install InsecureBankv2.apk

➡For example, run^ app.package.info^ --help^ will output:

➡Retrieve package information, type:

• run^ app.package.info^ -a^ com.android.insecurebankv2^ (Package^ Name) ➡Now, we will try to identify the attack surface of the application, type:
• run^ app.package.attacksurface^ com.android.insecurebankv ➡Let’s try to reverse the .apk file with APKTool, as I already mentioned that APKTool for reverse engineering, 3rd party, closed, binary apps. After running that, it will create a folder in the same directory with decompiled files in it. - apktool^ d^ InsecureBankv2.apk^ (APK^ name)

➡Choose any active activities:

• r u n^ a p p. a c t i v i t y. s t a r t^ - - c o m p o n e n t^ c o m. a n d r o i d. i n s e c u r e b a n k v 2 com.android.insecurebankv2.DoTransfer (Activity Name) ➡Open the decrypted^ AndroidManifest.xml^ file. The following screenshot shows the Activity which is to be ex- ploited is set to be exported. ➡Back on the Emulator, notice that the login page has been bypassed. ➡ADB Shell: Adb provides a UNIX shell that you can use to run a variety of commands on an emulator or connected device. In terminal you can use all adb commands. - adb^ shell

➡Type^ dumpsys^ meminfo^ –^ All process details ➡In case you want to check the process for a particular application, then type^ dumpsys^ meminfo^ application name.apk ➡Let’s go with Android Backup Functionality, you can check the same in manifest.xml file. Allow backup and debug mode should be false in application.

➡Now we are going to attack on content providers of the Android application, in this I’m going to use another vulner- able application named Sieve. Let’s start:

- run^ app.package.attacksurface^ com.mwr.example.sieve ➡As we can see, we have two content providers, let’s check: - run^ app.provider.finduri^ com.mwr.example.sieve ➡So by using app.provider.finduri module we have found some of the exported content provider URIs which can be accessed by other apps installed on the same device. As we can see, we have two similar URIs; let’s try to see what juicy information is hidden in these content providers.

- run^ app.provider.query^ content://com.mwr.example.sieve.DBContentProvider/keys ➡Let’s try to exploit these content providers: - run^ app.provider.query^ content://com.mwr.example.sieve.DBContentProvider/keys/ --selection “pin=1234” --string password “impassword55555” ➡Exploiting Android Pasteboard: login in the application with valid credentials. Click on the Transfer option. ➡S e l e c t t h e a c c o u n t n u m b e r f i e l d a n d s e l e c t t h e c o p y o p t i o n. ➡Now, back on the terminal, enter the below command to find out process details of the running InsecureBankv2 ap- plication. Note the user and the package name of the InsecureBankv2.application. - adb^ shell^ ps^ |^ grep^ insecurebankv ➡Enter the below command: