Friday, 30 May 2014

Launching - Android Application Pentesting Video Course

0 comments Posted by srini0x00 on 03:53
I am delighted to announce our Video Course on Android Application Penetration Testing.

 After starting my blog, I got several requests from readers asking me to make a simple video series beginning from basics. I always wished I had time to do a complete video series. But when John of 101hacker.com approached me with an idea to start JSInfosec and release the video series on Android Security, I got some moral boost to start the things. As a result of that conversation we are launching a complete course which can surely help you in becoming an Android Application Penetration Tester. I am sure you would love the series since it is designed in such a way that even a beginner in the field of mobile security can learn the techniques.

Release Date: 31st May 2014
Course Price: $99

For more details, 
Visit www.jsinfosec.com
write us contactus@jsinfosec.com

Friday, 25 April 2014

Exploiting Content Provider Leakage

0 comments Posted by srini0x00 on 06:13

Introduction

In the previous article, we discussed how an attacker exploits vulnerable Activity Components and ways to secure them. In this Article, we will discuss "Content Provider Leakage". 

What are content Providers?

As per Google’s inbuilt security model, Application data is private to an application and hence it is not possible for an application to access other application’s data by default. When applications want to share their data with other applications, Content Provider is a way which acts as an interface for sharing data between applications. Content providers use standard insert(), query(), update(), delete() methods to access application data. A special form of URI which starts with “content://” is assigned to each content provider. Any app which knows this URI can insert, update, delete and query data from database of the provider app. 
There may be some cases where content providers might not be implemented for sharing data with other apps, or developer may want to give access only to those apps which have proper permissions. In such cases, if proper security controls are not enforced in the app, that leads to leakage of information.
   
Inbuilt SMS application in Android devices is a classic example of content providers. Any app can query the inbox from the device using it’s URI content://sms/inbox.   But, READ_SMS permission must be declared in the app’s AndroidManifest.xml file in order to access SMS app’s data.


Prerequisites to follow the steps:

Computer with Android SDK Installed
A Non Rooted mobile device to install the app.

Test Application’s functionality:

Once after downloading the test application, install it in the non rooted android device in order to test and exploit it. 
It can be installed with adb using the following command
adb install <name of the apk>.apk
It has a feature to store data inside the application. When we launch it, it appears as shown in the figure. 
The Goal is to find out if there are any content providers implemented in this app and if YES, We need to check and exploit if they are vulnerable to data leakage.

Topics Involved:

Information gathering
Attacking Vulnerable Content Providers
Securing the applications

Information gathering

Like any other pentest, let’s start with information gathering. We assume that we have the APK file with us. So, decompile the downloaded apk file as shown in the previous article and check AndroidManifest.xml file for any registered content providers. We should also check the smali files for all the URIs used in the app.
Content Providers are generally registered in AndroidManifest.xml file in the following format.
So let’s go ahead and examine the manifest file.
We got one content provider registered in the AndroidManifest.xml file and good news is, it is exported to be accessed by all other apps. 

Attacking Vulnerable Content Providers

This is the most interesting part. Let’s now try to query the content provider we found. If it returns any data, then it is vulnerable. This can be done in multiple ways.
1. Using adb shell
2. Using a Malicious app to query
3. Using Mercury Framework
Using adb:
To query the content provider from adb, the app should be installed on the device. 
Get an adb shell on the device and type the following command to query the content provider. In my case, I am going to query the URI I found in MyProvider.smali file which is extracted by APK tool.

Content –query –uri content://com.isi.contentprovider.MyProvider/udetails
We should now see all the details stored into the app’s db as show in the figure below.




Using a Malicious app to query:
We can even write a malicious app to query the data from its content provider. Following is the code snippet to query the inbox from a mobile device. 

Using Mercury Framework:
The entire process can be carried out using Mercury framework in even more efficient and simple way.
Securing the Applications:
1. Setting android:exported attribute’s value to false:
In the AndroidManifest.xml file of our application, we should add the following attribute to the content provider to be secured. In our case com.isi.contentprovider.MyProvider is the content provider.
If we try to query the content provider whose android:exported value is set to false, it will throw an exception as shown below.
Note: The Default value of android:exported is true for all the applications using API Level lower than 17.
2. Limiting access with custom permissions

We can also impose permission-based restrictions by defining custom permissions for an activity. This is helpful if the developer wants to limit the access to his app’s components to those apps which have permissions.

Other issues with Content Providers:

SQL Injection: If security controls are not properly implemented, content providers can lead to Client Side attacks like SQL Injection. This works similar to traditional SQL Injection attacks.
Path Traversal: This is one more attack which can be carried out, if a content provider is not properly implemented. This is similar to the path traversal attacks on Web Applications. It allows an attacker to traverse and view the local file system. Sensitive files can be transferred from the device to the local machine using an app vulnerable to Path Traversal attack.

Note: You can download the sample application used in this article and follow the steps along with us.
 Download Link: Click Here

Feel free to post your suggestions and Questions.

Exploiting and Securing Application Components

0 comments Posted by srini0x00 on 05:14

Introduction

Mobile Application Security is one of the hottest segments in the security world as security is really a big concern with growing mobile applications. In this Article, we will go through the attacks associated with Android Application Components.

What are Android Application Components?

App components are essential building blocks of an Android App. Every app is built as a combination of some or all of those components which can be invoked individually. There are 4 main components in Android which are explained below.

 Activity: An Activity provides a screen with which users can interact in order to do something. Users can perform operations such as making a call, Sending an SMS etc.
Example: Login screen of your facebook app.

Service: A Service can perform long-running operations in the background and does not provide a user interface.
Example: Playing Music

Content Providers: A content provider presents data to external applications as one or more tables. In other words, content providers can be treated as interfaces that connect data in one process with code running in another process.
Example: Using content providers, any app can read SMS from inbuilt SMS App’s repository in our device.
*READ_SMS permission must be declared in the app’s AndroidManifest.xml file in order to access SMS app’s data.

Broadcast Receivers: A broadcast receiver is a component that responds to system-wide broadcast announcements such as Battery Low, boot completed, headset plug etc. Though most of the broadcast receivers are originated by the system, applications can also announce broadcasts.
This article focuses on demonstrating the methodology to attack and secure vulnerable Activity components of Applications.  

Background:

As shown in the figure below, it has two activities. The first activity takes a password as input. If the user enters the correct password he will be landed in a page which says “Private Area”, else he will get a message “Wrong password”. For test purposes, the password to login is set as “password”. Ideally, the first screen should use an intent and invoke the second screen if a valid password is entered. We need to perform black box testing on this app to see if we can bypass the authentication by directly invoking the welcome screen.

Prerequisites to follow the steps

Computer with Android SDK Installed
A Non Rooted mobile device to install the app.

Topics Involved:

Information gathering
Attacking Vulnerable Activity Components
Securing the applications

Information gathering

1.       Decompile the app with APK tool
2.       Analyze AndroidManifest.xml file for exported Activity components.

Every Android App has a package name and every Activity has its own Class name inside the package. The initial steps are to find out the name of the package and names of the available sensitive activities. Though, there are other methods to get this information, looking at the AndroidManifest.xml is a good approach. We can get the AndroidManifest.xml file by decompiling the application using APKTOOL.
1.       Download APKTOOL from here
2.       Place the test application in the same folder as in APKTOOL
3.       Now, decompile the apk file using the following command as shown in figure.
apktool d testapp.apk
As shown in the figure below, we should now be able to see a new folder named “testapp” with AndroidManifest.xml file inside it.
Now, we need to search for the package name and its activities.
All the activities will be registered in AndroidManifest.xml file using <activity></activity> tags. So, anything inside these tags will be an activity. Looking at the AndroidManifest.xml file, we are able to see two Activity Components and the package name as shown in the figure below.

By examining the above figure, it is clear that we got the following information about the app.
com.isi.testapp is the name of the package.
com.isi.testapp.Welcome could be the activity we are getting after providing the correct password.

Attacking Vulnerable Activity Components

Our job now is to launch Welcome activity without providing any password in the first screen.
We can perform attacks on vulnerable activity components in several ways as mentioned below.
1.       Launching sensitive Activities with Activity Manager Tool.
2.       Using a Malicious App to invoke Activities of other apps.
3.       We can also use Mercury framework for performing these attacks which will be covered in later articles.

Launching sensitive activities with Activity manager tool:

Activity Manager is a tool that comes preinstalled with Android SDK and can be used along with “adb shell”. This tool can be used to launch activities and Services of an application. We can even pass intents using it.
So, let’s begin.
1.       Connect the device to the computer and get a shell on the device using the following command

adb shell

2.       Type in the following command to launch Welcome activity.

am start –n com.isi.testapp/.Welcome

We should now see the welcome screen fired up by am tool without providing the password.

Using a Malicious App to invoke Activities of other apps:

Another way of invoking other application’s activities is to write a malicious app and feed it with the name of the package and activity to be launched. The figure below is a code snippet to launch an activity where in com.isi.testapp.Welcome is the activity to be launched. In our case, malicious app doesn’t require any permission to launch “Welcome” activity of vulnerable app.


Using Mercury framework:

The same attack can be reproduced with mercury framework. We will discuss mercury framework later in this series.

Securing the application components

1.       Setting up android:exported attribute’s value to false

In the AndroidManifest.xml file of our application, we should add the following attribute to the application component to be secured. In our case com.isi.testapp.Welcome is the activity to be secured.
The above code restricts other applications or any system component other than the current app from accessing this Activity.  Only applications that have the same user id as the current app will be able to access this Activity.

1.       Limiting access with custom permissions

android:exported attribute is not the only way to limit an activity's exposure to other applications. We can also impose permission based restrictions by defining custom permissions for an activity. This is helpful if the developer wants to limit the access to his app’s components to those apps which have permissions.
Note: The above security controls are applicable to any other Application component which we discussed in the beginning of the article.

References:

Note: You can download the sample application used in this article and follow the steps along with us.
 Download Link: Click Here

Feel free to post your suggestions and Questions.

Friday, 24 January 2014

ARM Assembly Part 3 - "Hello world" in ARM assembly

0 comments Posted by srini0x00 on 02:00

Background

This article gives you the taste of writing your first program in ARM assembly. The series eventually takes you towards advanced ARM assembly concepts, writing shell code and ARM Exploitation. To follow this series, you need to have the lab setup which is explained here.

We are going to write a very simple program which prints the string "Hello World @androidpentesting.com\n". In order to simplify our task, we will take advantage of system calls to print the string on the output screen and exit the program.

What is System Call?

Operating Systems contain routines to perform various low level operations. If we want to invoke these operating system routines from our program, we need to make system calls.

From Wikipedia, "A system call is how a program requests a service from an operating system's kernel. This may include hardware related services (e.g. accessing the hard disk), creating and executing new processes, and communicating with integral kernel services (like scheduling). System calls provide an essential interface between a process and the operating system."

How do I check the list of systemcalls?

Type in the following command in terminal.

cat /usr/include/asm/unistd.h

In this program, we will use write and exit syscalls as shown in figure 1.1 and figure 1.2. As we can clearly see in the figures, write has the system call number 4 and exit has the system call number 1.
Figure 1.1
Figure 1.2

We can check the man files to know the usage of these syscalls which looks as shown in figure 1.3 and figure 1.4.

Figure 1.3
Figure 1.4

Your First Program

Now open any editor of your choice and type in the following program, then save it as "filename.s". In my case, I am using Vim editor. Every line in the program is self explanatory as i have given explanation in the comments.
Figure 1.5

The registers r0, r1, r2 are being used for data operations. When we work with syscalls, register r7 should be used to store syscall number.

Note: In the next article, we will have a detailed explanation of ARM registers and how we use them.

SVC in the above program is an instruction that generates a supervisor call. Supervisor calls are normally used to request privileged operations or access to system resources from an operating system. In simple words, SVC is used to generate an interrupt(in our case, write and exit).

Once, we are done with writing the program, we have to assemble and link it to the final executable.

Assembling and Linking

Now, we need to assemble and link the program. "as" is the assembler and "ld" is the linker we use.
To assemble the program type in the following commands as shown in figure 1.6

Assembling: as -o filename.o filename.s 
(filename.s is the input to the assembler, filename.o is the output)

Linking:       ld -o filename filename.o 
(filename.o is the input to the linker, filename is the final executable)

./filename                             
(Executing the binary to see the output)

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

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

0 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.


 

Recent posts

Recent Comments

Bookmark & Share