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.

Friday, 29 November 2013

ARM Assembly Part 1 - An Introduction

0 comments Posted by srini0x00 on 12:52
We have seen a very basic C Program in the previous article to get a brief understanding of how a processor processes and executes the code written in a High Level language like C. If you have missed it, you can refer it from here.  Now let’s see a brief introduction to Assembly Language and ARM Processors.

Assembly Language

Assembly is a low level programming language with which we can directly communicate with the Processor.
Our Processor can understand only 0s and 1s (binary) where, it is very difficult for a human being to understand binary.

Assembly Language acts as a bridge between the human and Processor. Though, there are many advantages with Assembly,  it is machine dependent. As it is very specific to Hardware Processor family, Programs written for one computer might not run in another computer with different hardware configuration.
It means, A Program written for a machine working on Intel processor might not work with a machine running on ARM processor. Hence, Different processors need different assembly language.

Example Processor families:
Intel
ARM
MIPS

This series focuses only on ARM Assembly language.

What is ARM?

ARM is one of the leading companies which provide processors for embedded devices such as mobile Phones. These ARM processors are based on RISC Architecture.

Most of the devices around us today including mobile Phones, tablets, Multimedia players, and routers are running with ARM Processors. i-devices  such as iPhone, iPad and most of the smart phones running on android platform use ARM processors because of their enhanced power saving design.

Checking for Processor information on an Android Device

We can see the details of the processor being used in our android mobile Phone by following the steps below.

In this example, I am using an emulator instance to show how we can see the CPU information on a device. Just in case if you are using a real device, steps remain the same.

Step 1: Connect your Phone to the machine using adb or over SSH to open a shell on the device.
Please refer to this article if you want to know more about adb

Step 2: type the following command
cat /proc/cpuinfo

It looks as shown in the figure 1.1

figure 1.1
The above figure says that the processor being used is ARMv7.
Note: When launching a new emulator, we can explicitly specify which processor we want to use with the emulator instance as shown in figure 1.2
figure 1.2

Summary:

We have seen what assembly language is and how it is specific to each processor family. We have also seen the details about ARM family of processors. In the next article, we will see the lab setup to start programming ARM Assembly.

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

A deeper insight into “Hello World!” in C

0 comments Posted by srini0x00 on 10:52

Motivation:

In the world of Computer Science, probably the very first output that every programmer would see on his computer screen is “Hello World!”.

So, Lets recall the Hello World! program one more time before actually getting into the nitty gritty details of ARM Assembly Language.

Let the game begin

When we compile and run a very simple C Program, all we see is a binary giving us an output.

 Source Code  -> Compiler -> Binary


But, in the process of generating the binary, there will be some intermediate files generated during different phases which we often don't care. 

Sourcecode -> pre processing -> Compiling -> assembling -> linking -> Binary


Lets look at all these Phases with a sample program. I am using an Ubuntu machine with Intel Processor. 
Let’s first write a simple C Program as shown below.
/* Hello World Program in C */
#include<stdio.h>
main()
{
printf("Hello World!\n");
return 0;
}

Compile the above code in a way that it saves all the temporary files in the current directory where we have written our code.

gcc –save-temps helloworld.c –o hello

The above command generates the following files as shown in Figure 1.1
helloworld.i      -preprocessed file
helloworld.s     -assembly file
helloworld.o    -object file
hello                -binary

Figure 1.1

Pre Processing: 

Pre-processing is setting up everything ready for a compiler to do its job (Compiling). 

WikiPedia: A pre-processor is a program that processes its input data to produce output that is used as input to another program. The output is said to be a pre-processed form of the input data, which is often used by some subsequent programs like compilers. 

In our case, the output after preprocessing is helloworld.i. We can see this file by opening it with any text editor or by using the following command.
cat helloworld.i

Compiling: 

Compiling is basically a process where it takes the high level language’s source code as an input and generates an output usually to a lower level language like assembly.

In our case, the output after compiling is helloworld.s. We can again see the code as explained in preprocessing phase.

Assembling: 

The previous step has generated an assembly language code. Here in this step the code generated by the compiler will be assembled and a new output will be generated for a linker to link it to a final executable. 

In our case, the output after compiling is helloworld.o. 

Linking: 

As explained in the previous phase, this is where the linker will link the object files to a final executable.

In our case, the output after compiling is hello which is the final executable. Even if we try to see the code of this file using any text editors, we end up understanding nothing since it is an executable file.

Now, to see the output, we can execute it as shown in figure 1.2

 figure 1.2

Summary

The Programmer’s ultimate goal is, processor should process and execute what the programmer is asking it to do(Printing "Hello World!" onto the screen in our example). Since, our processor cannot understand the programs we are writing in a high-level language like C, we are converting them into a form which our processor can understand.

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

Tuesday, 26 November 2013

Android Debug Bridge - An introduction

0 comments Posted by srini0x00 on 09:32

What is ADB?

Android Debug Bridge (adb) is a command line tool which acts as a bridge between you and your Android device. It allows the users to control the mobile device right from your computer/laptop.Using ADB, We can do many operations on the Connected Device or Emulator such as, 

  • Checking what are the devices/emulators connected to the computer.
  • Installing an application.
  • Copying files from to/from a phone onto your computer.
  • Executing shell commands.
  • Exploring the directories on a device/emulator.
  • Analyzing the installed app directories for vulnerabilities.

What do we need to work with adb?


  • A Laptop/Computer with adb installed
  • An Android mobile phone/ Emulator(USB Debugging should be enabled on mobile)
  • A USB Cable(If you are using a mobile phone)

How does adb work?

ADB has three important components.
  1. A Client
  2. A Server 
  3. A Daemon
Client: 
Client resides on the computer we are working on. We can explicitly execute it by navigating to android installation path and then moving to platform tools. The adb client looks as shown in figure 1.1
Syntax: <Your installation path>\platform-tools

In my case, I have it in the following path.
C:\Users\DELL\AppData\Local\Android\android-sdk\platform-tools

figure 1.1

Server:
It is a background process running on the computer we are working on, it is used to manage the communication between the client running on the computer and daemon running on the device.

Daemon: 
It is a background process by default running on each android device or emulator.

When we start adb client on the computer, it checks whether the server is running or not, if it is not running, it will start it on port 5037 as shown in figure 1.2

Figure 1.2 adb command looking for attached devices.

Since, my emulator is still switching on, the above figure shows the emulator's status as offline. Once, if it is started it shows the status device as shown in the figure 1.2.1.

figure 1.2.1

Checking the adb connections with netstat

Lets recheck whether this 5037 port is listening for any connections or not using netstat command line utility.

netstat  -a | findstr 5037

-a is to display all connections and ports
| is to pipe the results
findstr is to find the specific string rather than displaying all the output on the screen.
The output is as shown in figure 1.3
figure 1.3

As we can clearly see, a process is listening for a connection on port number 5037. Once if we connect to a device/emulator the status becomes “ESTABLISHED”
Lets run the command “adb shell” as shown in figure 1.4, it gives us a shell on the emulator/device where we can execute the commands.
figure 1.4

If we now check the same nestat command, status says “ESTABLISHED”.

Running Commands

We can now start using adb for different purposes. For instance, let us do a quick “ls” to see all the files and folders in the current directory as shown in the figure 1.5
figure 1.5

We keep using adb throughout this series wherever it is needed. So, its always a good idea to get your hands dirty with adb. 

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


 

Recent posts

Recent Comments

Bookmark & Share