Monday, 16 December 2013

Pentesting Android Applications Part 2 - M1 Insecure Data Storage(Shared Preferences)

0 comments Posted by srini0x00 on 09:03

Introduction

In this series of articles, we will look into some common approaches for Android App penetration testing. Our focus is to cover OWASP Mobile top 10 with various tools and techniques as it is the most common standard that many organizations and security professionals follow.

Below is the TOP 10 list from www.owasp.org
  • M1: Insecure Data Storage
  • M2: Weak Server Side Controls
  • M3: Insufficient Transport Layer Protection
  • M4: Client Side Injection
  • M5: Poor Authorization and Authentication
  • M6: Improper Session Handling
  • M7: Security Decisions Via Untrusted Inputs
  • M8: Side Channel Data Leakage
  • M9: Broken Cryptography
  • M10: Sensitive Information Disclosure 

Insecure Data Storage

Android provides a variety of ways to save persistent application data. Following are the most common ways of storing data by an Android Application. 
  • Shared Preferences
  • Internal Storage
  • External Storage
  • SQLite Databases
  • Network Connection
Device loss is a very common problem with mobile devices. An attacker who has physical access to the device may perform various types of attacks ranging from stealing personal data to theft of corporate sensitive information. Situation could be worse if the device is rooted. 

So, keeping the this fact in mind, if the above mentioned ways for storing data by an application not implemented properly, may lead to serious attacks. In this article, we will look into how one can look into SharedPreferences for sensitive information.

Shared Preferences:

"Shared Preferences" allows a developer to save and retrieve persistent key-value pairs of primitive data types such as booleans, floats, ints, longs, and strings. 

Let us see, how we can test an app to see if it is storing any sensitive information on this device with out proper security enforcement. 

I have developed a very simple app for demo purpose. the functionality of the app is described in later sections. 

You can download it from here.

Once after downloading it, install it onto the emulator as shown below.
I am using adb to do it.

C:\<adb path>adb devices
C:<adb path>adb install M1-SharedPrefs.apk 







As you can see, it has been installed. Now, you should see a new icon on your emulator.

Functionality of test app

Once if you launch the application, you can see three options as shown in Figure 1.3

Figure 1.3
Now, Click the first option and store some sample card details by filling in the details it asks. You can see the same details by clicking "View Card Details" and entering your name. You can clear the data by using "Clear Card Details" Option.
I have entered my details into the app as shown in Figure 1.4
.
Figure 1.4

So, this is the functionality of the app from an end user's point of view. Now, lets go ahead and check how it is storing the data we entered into it.

Get an adb shell on the emulator using the following command.
C:\<adb path>adb shell
Now, navigate to /data/data directory as shown below.
C:\<adb path>cd /data/data

This is where all the user installed applications will be. So, our app will be here in this directory. Let us check it's package name by using ls & grep as shown in Figure 1.5

Now, Navigate into this directory "com.example.m1_shared" and give an ls


We can clearly see, this app has "shared_prefs" directory. So lets get into this directory and open the bankdetails.xml file inside it as shown in Figure .
 As you can clearly see it has the bank details inside it as name value pairs. This is how many apps store their game scores and other interesting stuff. If it contains any sensitive data as shown in the above example, it is pretty easy for an attacker to steal it.

Note: Shared Preferences used to have features called "MODE_WORLD_READABLE" and "MODE_WORLD_WRITABLE" which enable other apps/users to read/modify the app's data. Those features are deprecated from API level 17.

 Please post your comments if you have any queries or suggestions.

Saturday, 14 December 2013

ARM Assembly part 2 - Setting up a LAB

0 comments Posted by srini0x00 on 05:56

In this series of articles, we have started with the introduction to ARM. In this article let us setup a lab to start writing programs in ARM assembly. We could either set up a virtual environment on your system based on ARM architecture such as qemu, or you could buy an ARM based device such as RasberryPi.

Our focus is to set up a virtual lab environment with Qemu, rather than writing programs on a real hardware device.

What is Qemu?

QEMU (short for "Quick EMUlator") is a free and open-source hosted hypervisor that performs hardware virtualization. QEMU is a hosted virtual machine monitor: It emulates central processing units through dynamic binary translation and provides a set of device models, enabling it to run a variety of unmodified guest operating systems.

Simply put, it is an emulator which acts as a CPU.  Qemu supports ARM, PowerPC, MIPS and even x86 emulation.

Steps to be followed

Lets begin with setting up a lab.

Step 1: Download Qemu .

We can download Qemu from its official website - http://wiki.qemu.org/Download

Step 2: Install all the dependencies before installing Qemu.

We can use the following command to install dependencies.

$apt-get build-dep qemu

Step 3: Run the configuration script, to build Qemu for ARM processor.

Extract the downloaded Qemu archive and navigate to the qemu directory.  in my case, it is as shown below.

$cd qemu-1.7.0

Run the commands shown below

$./configure --target-list=arm-softmmu
$make
$sudo make install

Step 4: Create an ubuntu disk image of 10GB

$qemu-img create ubuntu.img 10G

The next step is to install Ubuntu (ISO image in my current working directory)

$qemu -hda ubuntu.img -cdrom ubuntu-12.04.3-desktop-i386.iso -m 512 -boot d

From here, follow the same installation steps you would use on a real machine.
Once installed, you could boot the created virtual environment with the following command.

$qemu -m 512 -hda ubuntu.img

Drop an email at srini0x00@gmail.com if you face problems in setting up the lab, so that I can write other ways of doing it or probably make a video of the whole process.

Saturday, 7 December 2013

Attacking an Android Device using a Reverse Connection Shell

1 comments Posted by srini0x00 on 07:18

Background

Trend of Mobile Devices is growing up. Hackers are now shifting their focus onto mobile devices. Android is not an exception. Because of it's open source nature and the market share it has, it is more prone to attacks when compared to other mobile platforms. 

I have developed an android Trojan to demonstrate one of such attacks to show how dangerous it is if a user doesn't care about the security of his personal data 

Though, it is possible to steal SMS, CallLogs, Contacts, GPS Location and other Sensitive data from the device remotely using this malware, the focus of this video is to show that it is possible to execute remote commands to steal sensitive information from an android device. 

Note: This application is written by the author for demonstration purposes and not uploaded on Internet

Video

          

Trojan Description

It contains two parts similar to any other trojan.
                1. Client(Android App)
2. Server(Written in JAVA)

1. Server listens for incoming connections on port 8888(Reverse Connection Trojan).

2. When a user starts the client app, it automatically connects to the server and gives a reverse shell.

3. Now the attacker can execute remote shell commands on the Android Device.

Recommendations for Users


  • Always check the permissions before you install any new app.
  • Always install apps from trusted sources.
  • Install an anti virus solution on the device(though they can be easily bypassed).
Please post your comments for any queries and suggestions.


Pentesting Android Applications Part 1 - Analyzing Android Permissions

0 comments Posted by srini0x00 on 05:06

Introduction:

Android Permission Model is one of the Core Security Features implemented by Google for Android Platform to protect end users.

When A developer develops an Android App, he must declare the permissions if the app uses any protected features of the device.

As an example, if an app wants to monitor incoming SMS or read Phone State or access internet, would specify permissions as shown in the following code snippet.

  <manifest xmlns:android="http://schemas.android.com/apk/res/android"
            package="com.permissionexample.helloworld" >
            <uses-permission android:name="android.permission.RECEIVE_SMS" />
    <uses-permission android:name="android.permission.INTERNET" />
           <uses-permission android:name="android.permission.READ_PHONE_STATE" />
            ...
   </manifest>

It is done using a file called AndroidManifest.xml which makes use of the tag <uses-permission> as shown in Figure 1.1
Figure 1.1 AndroidManifest.xml file

Note:Components such as Intents, Services and Broadcast receivers also should be included when used to access sensitive resources.

Permissions for an End User

When a user is installing an Application, it pops a window showing the permissions being used by the app. If the user agrees and accepts it, the app will comfortably use those permissions from then and no further checks will be done while running the app. However, if an app tries to access the permissions that are not specified in the Manifest file, it will silently end up in a failure to access that specific resource or sometimes it throws a security exception.

We can see the permissions of each app installed in the Device as shown in Figure 1.3.

Goto Settings > Applications. Pick an app and scroll down to see the permissions that the app uses.

Figure 1.3

Note: If any app is using more permissions than what it needs, we may suspect it as a malicious app and further analysis is needed.

Pentesting Android Apps - Analyzing Permissions

Though it is pretty much easy for an end user to look at the permissions and decide whether he wants to accept them or not, A pentester's life wont be that easy in analyzing an app's behavior
since an app may contain Dangerous hidden services or malicious intended broadcast receivers. So it is always a good idea to have a look at the manifest file during a pentest or Malware analysis.

Here are various scenarios a pentester may come across and different techniques he needs during his pentest.

  • When Source code is available
  • When An APK is available(No source code)
  •         When APK is not available
When Source code is available:

If the source code is available, we can directly jump into the AndroidManifest.xml file and analyze the app permissions and other components being used by the app.

1. Check <uses-permission> to see if any suspicious permissions are being used in the file other than what it requires.
For example, If you are analyzing a calendar application, it really doesn't require READ_SMS permission which requires further analsis with the Code.

2. Check if there are any Broadcast receivers such as boot_completed 

<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED"></action>
</intent-filter>

the above  code snippet broadcasts it's message when the device completes it's booting. So, it could be used to start a malicious app every time the user restarts his device.

When an APK is available:

Many techniques are there to read the permissions when an apk file is available.

Background: Android Apps contain the extension ".apk". An apk is nothing but a compressed ZIP file which consists of AndroidManifest.xml file as a part of it. We can extract it using decompression tools such as winrar, winzip or 7zip. So, when an Android APK is available, we can extract it to see the Manifest file but the text inside is not readable. So, we need to look at other ways of doing it.

Option 1: aapt

aapt(Android Asset Packaging Tool) comes by default when we install android SDK.  Android eclipse utilizes this tool to package the apk file that constitutes an Android application
This tool can be used to see the permissions of defined in an APK as shown in Figure 1.4.

Copy aapt from SDK installation location to any directory you like.
Place your apk file into the same directory as shown in Figure 1.5.
Figure 1.5

Open your command promt and navigate to the directory where you placed aapt.
Write the following command
aapt dump permissions <your app.apk>

Figure 1.6


Option 2: APK-TOOL
APK-tool is one of the most commonly used tool for android application reversing which we will discuss later in this series. In this article,we focus only
on Android permissions.

You can download apk tool from https://code.google.com/p/android-apktool/

Place apk-tool and your target app in the same directory as shown in Figure 1.7.
Figure 1.7

Open command prompt and navigate to the direcory where you placed apk-tool
Now, execute the following command
apktool d <your app.apk> output-path

Upon executing the above command, a new folder will be created with the name "output path", in my case it is "output" in the current directory. Get into that to see the newly created AndroidManifest.xml file to read.

When APK is not Available:

When an apk file is not available, though there are ways to see the permissions directly from the device, it is always a good idea to extract it to an APK and then follow the same steps as we did in scenario 2.
We can extract the app from the installed device using apps such as Apk Extractor. 

Summary: 

Analyzing AndroidManifest.xml file is very important during a pentest to figure out the declared permissions, intents and services in an app. We have seen various techniques to read manifest file in an app. An end user must have a keen look at the permissions before installing an app and be cautious in downloading apps from third party app stores.

Please post your comments for any queries or suggestions.

Tuesday, 3 December 2013

Andorid Inbuilt Security Features

0 comments Posted by srini0x00 on 10:31

Introduction

Though there are debates going on Android vs iOS, It is widely accepted that Android is one of the coolest mobile platforms from an end user's perspective. But, when it comes to the security, keeping it's open source nature in mind, it is really challenging for Google to implement a robust security architecture. Lets dive into the android inbuilt security model implemented by Google.
Following are the key security features

  • Security at the OS level through the Linux kernel.
  • Application sand boxing.
  • Secure inter-process communication.
  • Application signing.
  • Application-defined and user-granted permissions

1. Robust security at the OS level through the Linux kernel

Android is built upon Linux Kernel. because of it's open source nature, thousands of developers have been working on Linux kernel security and thus it became a stable and  secure kernel by many corporations and security professionals.

2. Application Sandboxing

I would take a step ahead to make you clear with this concept of Application Sandboxing. 

Regular Linux Machines:

Lets first take an example of how a normal Linux machine works. Multiple applications running will have the same user ID.

Here, I have logged into my Ubuntu Machine as user "srini" and running two processes.

1. Firefox
2. Gedit

Now, if we look at the User IDs of the above two processes, they run with the same UID "srini". To cross check , i am filtering the processes running with UID "srini" by writing the following command.

ps -U srini | grep 'firefox\|gedit'

ps -U srini : Shows all the process running with UID "srini"
grep 'firefox\|gedit' : filters the output and finds the specified strings.

Figure 1.1

Android Device:

Now, its not true in case of android applications. Every Single application installed in your device, will have a separate User ID(UID). This ensures that each application and it's resources are being sand-boxed and will not be accessible to any other application.

Note: Applications signed with the same key(it is possible if two apps are developed by the same developer), can access each others data.

Figure 1.2 shows how each application is given a separate UID.
1. Connect your device/phone using adb.
2. give "ps" command

Figure 1.2

The above figure shows how each installed app holds a different UID. The highlighted app is the inbuilt contacts app holding the UID u0_a4. Similarly, we can observe the UIDs of other apps. 

Figure 1.3 shows how each apps data is isolated in a separate sand-boxed environment under data/data directory. 
1. Connect your device/emulator to your machine using adb.
2. Navigate to the directory /data/data using the following command.
cd  data/data
3. enter "ls" command

Figure 1.3

Is there a way to break out of this Sandbox?

Google says, "Like all security features, the Application Sandbox is not unbreakable. However, to break out of the Application Sandbox in a properly configured device, one must compromise the security of the the Linux kernel".

This is where we can comfortably discuss about android rooting which enables all the apps to have root privileges to do most of the things they want to do on the android system.

In Linux (and UNIX) based machines, ‘root’ is the supreme user level with highest privileges to perform any task.  By default, only the Linux kernel and a small number of core utilities run as 'root' on android. But if you root your device  the root user level is available to all apps running on the device. Now any user or app with root permission can modify any other part of the Android OS including the kernel, and other apps as well as the application data by breaking out of the sandboxed environment.

Later in this series, I will write an article to describe how rooting works. 

3. Secure inter-process communication

In android, processes can communicate with each other in several ways such as Intents, Network Sockets etc.

Though Google claims that all of them need permissions, Android permissions can be easily bypassed. Later, in this series we will see how we can bypass android permission model to steal sensitive data and to upload it onto a remote server.

The fact with web applications that any data sent over the network without proper cryptographic implementations, is susceptible to attacks holds true with mobile applications as well. 

Example: Passing sensitive data in clear text format using an intent.

Note: There were malwares such as iCalender on Google play store which used to send premium rated SMS from user device on which it is installed. Android 4.2 added further control on the use of SMS. Android will provide a notification if an application attempts to send SMS to a short code that uses premium services which might cause additional charges. The user can choose whether to allow the application to send the message or block it.

4. Application signing

Application Signing ensures that every application that is run on the Android platform must be signed by the developer. Applications that attempt to install without being signed will rejected by either Google Play or the package installer on the Android device. Self signed certificates are allowed to use, as Google currently does not perform CA verification for application certificates.

5. Android Permission Model:

Permission model is said to be one of the important aspects of Android Security. However, as discussed in the previous section, we can easily bypass the permissions to do majority of sensitive tasks.
In the next article, we will discuss the aspects of how android permissions are enforced and how a pentester can analyze permissions of applications from security point of view.

Hope this information helps you. Please post your comments for any queries or suggestions.

 

Recent posts

Recent Comments

Bookmark & Share