Showing posts with label Mobile. Show all posts
Showing posts with label Mobile. Show all posts

Tuesday, February 5, 2013

Develop a Browser App for Windows Phone 7

I personally have had a resistance toward developing applications for Windows Phone. However some days ago I started playing around with it and I can honestly say that it did not disappoint me at all. There is a high chance that you do not like the user experience which Windows Phone 7 provides, however I can tell you coding for Windows Phone 7 is really nice, easy and fun!

Prerequisites

It is assumed that you already have installed the following components:

  • Visual Studio 2010 for Windows Phone
  • .NET Framework 4
  • Windows Phone SDK 7.1


1. Create Your First Windows App Project

Open your visual studio, click on "New Project" and inside the Installed Templates section, choose your preferred language (This tutorial covers C# template).



A pop-up window then asks for the Target Windows Phone OS version which should be set to Windows Phone OS 7.1.

The template will create a MainPage.xaml file. Double-click on the file, and what you see resembles to the following picture:





2. Add UI Elements

Now browse to the MainPage.xaml file and  find the part of XAML file which defines StackPanel element:

      
      



You can see that it contains two TextBlocks where you can see the application name and page title. In the first TextBlock, change the Text property to "A Windows Phone App" and in the second one to "Mini Browser". As you can see, the changes affect the UI in the Preview panel.

Next, we need to add a TextBox (which user will put the website address), a Button and a Browser element.  For this, inside the MainPage.xaml, find the ContentPanel Grid :


Now, we need to open the Grid element and insert those elements inside the ContentPanel Grid element with the following lines of code:


3. Add Button Event Handler

In the preview panel, double click on the Go button. You will be directed inside the MainPage.xaml.cs file:

public partial class MainPage : PhoneApplicationPage
    {
        // Constructor
        public MainPage()
        {
            InitializeComponent();
        }

        private void Go_Click(object sender, RoutedEventArgs e)
        {
        }
    }

When the Go button is clicked, the browser navigates to the URL and the result will be shown inside the webbrowser element. For this, we add the following code inside the Go_Click button:
 
string HTTP = "http://";
string website = HTTP + URL.Text;
MiniBrowser.Navigate(new Uri(website, UriKind.Absolute));


Save all the modifications.


4. Run the application

Select the Windows Phone Emulator for the debugging in your toolbar:




Yes, the application is up and running. You should that it is working correctly both in Portrait  mode:



and also Landscape mode:


Monday, August 20, 2012

Android Attacks in a Nutshell (Part III)


3  Permission Re-delegation Attack

3.1  What is Permission Re-delegation?

Browsers and smartphone operating systems, however, have shifted from associating privilages to their user accounts to a fundamentally new model where applications are treated as potentially malicious and mutually distrusting. Principals receive few privileges by default and are isolated from one another except for communication through explicit IPC channels. Inter Process Communication (IPC) in a system with per-application permissions leads to the threat of permission re-delegation. Permission re-delegation occurs when an application with a usercontrolled permission makes an API call on behalf of a less privileged application without user involvement. The privileged application is referred to as a deputy, handling authority on behalf of the user. According to Porter et. al, More than a third of the 872 surveyed Android applications in their study had requested permissions for sensitive resources and also had exposed public interfaces; i.e. they are therefore at risk of facilitating permission re-delegation. Moreover, the paper claims that 15 permission redelegation vulnerabilities in 5 core system applications were found. The permission re-delegation process is as follows: the deputy defines a public interface that exposes some of its functionality. After that, a malicious requester application lacks the permission that the deputy has. The requester invokes the deputy’s interface, causing the deputy to issue a system API call. The system will approve and execute the deputy’s API call because the deputy has the required permission. The requester has succeeded in causing the execution of an API call that it could not have directly invoked (Figure 1).

 
Figure 2: Permission re-delegation attack: The requester does not have the text message permission, but the deputy does. The deputy also defines a public interface with a Notify method, which makes an API call requesting to send a text message. When the requester calls the deputy’s Notify method, the system API will send the text message because the deputy has the necessary permissions. Consequently, the attack succeeds. [1]

3.2  Implementated Applications for Attacks

Porter et. al, built attacks using 5 of the 16 system applications. All of the attacks succeed in the background with no visible indication to the user. The filtered 5 applications provided 15 paths to 13 interfaces with permissions, one of which was SignatureOrSystem and nine of which were Dangerous permissions. Two example application in order to create permission redelegation attacks were also presented:
•     Settings serves as the phone’s primary control panel. When a user presses certain buttons, Settings’ user interface sends a message to a Settings BroadcastReceiver that turns WiFi, Bluetooth, and GPS location tracking on or off. However, Settings’ BroadcastReceiver accepts Intents from any application. An unprivileged application can therefore ask the Settings application to toggle the state of devices by sending its BroadcastReceiver the same Intents that it expects from its user interface. Turning these devices on or off is supposed to require Dangerous permissions (CHANGE_WIFI_STATE, BLUETOOTH_ADMIN,and ACCESS _FINE _LOCATION, respectively).
•     Desk Clock provides time and alarm functionality. One of its public Services accepts directions for playing alarms. If an unprivileged application sends an Intent requesting an alarm with no end time, then Desk Clock will indefinitely vibrate the phone, play an alarm, and prevent the phone from sleeping. The alarm will continue until until the user kills the Desk Clock process. Playing sound with a wake lock requires the Dangerous WAKE_LOCK permission, and vibrating the phone requires the Normal VIBRATE permission.
Concrete vulnerabilities were found with implementing the two previously mentioned applications in 5 of the 16 applications, which is equal to half of the 11 system applications identified as at-risk. Unfortunately, the authors did not disclose the code and therefore we cannot go further. Finally, Porter et. al discussed that to prevent permission re-delegation attacks, an IPC Inspection mechanism were presented, in which each deputy will accept Intents from the applications that already share the common permissions which is needed for the execution of that Intent. IPC inspection mechanism resides on top of already stack-inspection-enabled JVM and CLR. Since this topic is not in the scope of this report, for more details see [1].

4  Conclusion

This report is an introduction to Android OS security. While there exists a range of taxonomies of android attacks [2], their impact and possibility of occurance differs. We presented an XSS vulnerability on default web engine of Android, i.e. WebKit, after that a description of one of Android’s permission re-delegation attacks was presented and its implemented applications were discussed.


References
[1] Adrienne Porter Felt et. al. Proceedings of the 11th usenix conference on security. In Permission Re-Delegation: Attacks and Defenses.
[2] Asaf Shabtai et. al. Google android: A comprehensive security assessment. 2010.
[3] Sebastian Gerling Michael Backes and Philipp von Styp-Rekowsky. A local cross-site scripting attack against android phones. Technical report, Information Security and Cryptography Group, Saarland University.
[4] Patrick McDaniel William Enck, Damien Octeau and Swarat Chaudhuri. A study on android security. In Proceeding of 20th USENIX Security Symposium.

Wednesday, August 15, 2012

Android Attacks in a Nutshell ( Part II)

2 Local XSS Attack

2.1 Attacker Model

 Backes, gerling and Stype-Rekowsky [3] developed an android version 2.3.4 application that without requiring any permission can steal cookies stored in the web browser for Web sites of the attacker’s choice and automatically installing arbitrary applications from the Android Market without user consent. The three prerequisites for this attack is the following:
• User should install the malicious application, either by integrating the malicious code into an unsuspicious application, e.g. a small game. Since no permission is needed at install-time, there is a high chance that the user shall install an application that looks trustworthy.
 • The user needs to store login cookies in the browser, which is similar to normal cross-site request forgery attacks. In case we want to install other Android applications, it is further required that the user is already logged in to his Google account (the one he paired his phone with). Note that it suffices that the user is logged in to an arbitrary Google service based on Google policy.
• The WebKit-based browser shipped with Android needs to be the default receiver for http:/https: and javascript: VIEW Intents.

 2.2 Implementation

The attack exploits a flaw in the Intent handling mechanism of the Android browser. Naturally, this browser is configured to receive VIEW Intents that operate on http: and https: URIs. The browser will also handle VIEW Intents for javascript:URIs as well. Whenever the browser receives an Intent to view an http:/https: URI, it will open a new browser window and load the given Web site. However, upon reception of a view Intent for a javascript: URI, the browser will not open a new window but reuse the currently active window. Consequently, the javascript code given in the Intent URI will be executed in the context of the Web site that is currently loaded in the active window. This leads to a generic local XSS vulnerability, which works with arbitrary websites. As it can be seen in the following lines of code, the application first creates a VIEW Intent for the target Web site, in our example https://market.android.com and dispatches it to the system. This will cause Android to launch the default browser and load the specified Web site. The application then sleeps for 10 seconds to wait for the Web site to finish loading. It then dispatches an Intent containing javascript code to be executed within the context of the previously loaded Web site. here, the Intent will cause the browser to display the cookie information stored for https://market.android.com.

The following is the code sample in Java:

Uri uri = Uri.parse("https://market.android.com/");
Intent intent = new Intent (Intent.ACTION_VIEW, uri );
startActivity(intent) ;
Thread.sleep(10000);
uri = Uri.parse("javascript:alert(document.cookie);");
intent.setData(uri);
startActivity(intent);

Tuesday, August 14, 2012

Android Attacks in a Nutshell (Part I)

1.1 Android and Dalvik


Android is an OS designed for smartphones. It includes a sandbox application execution environment, and a customized embedded Linux system that interacts with the phone hardware and an off-processor cellular radio. The Binder and application API runs on top of Linux. Each application is executed within a Dalvik Virtual Machine (DVM).

Applications interact with each other and the phone through different forms of IPC. Intents are typed interprocess messages that are directed to particular applications or systems services, or broadcast to applications subscribing to a particular intent type. Persistent content provider data stores are queried through SQL-like interfaces. Background services provide RPC and callback interfaces that applications use to trigger actions or access data. Finally, user interface activities receive named action signals from the system and other applications. DVM runs .dex files that are designed to be more compact and memory-efficient than Java class files. DVM fucntions close to Java Virtual Machine (JVM), with differences in application structure, register architecture, instruction set, constant pool structure, ambigous primitive types, null reference and comparison of object references. [4]


Figure 1: The Android System Architecture [4]

1.2 Android Security Mechanism
Shabtai et. al [2] categorizes Android’s security mechanisms into three main categories:
 • Linux Mechanism
 • POSIX users
 • File Access
 • Environment features
 • Memory management unit (MMU)
 • Type safety
 • Mobile carrier security features
 • Android-specific mechanisms
 • Application permissions
 • Component encapsulation
 • Signing applications
 • Dalvik virtual machine

One of the most crucial elements inside the previously mentioned list is the application permission mechanism. Generally, Android permissions are categorized into 3 security levels: Normal, Dangerous, and Signature. Normal permissions protect API calls that could annoy but not harm the user (e.g., SET_WALLPAPER); these do not require user approval. Dangerous permissions let an application perform harmful actions (e.g., RECORD_AUDIO). Signature permissions regulate access to extremely dangerous privileges, e.g., CLEAR_APP_USER_DATA.

 Depending on which OS functionalities an application wants to access, the developer has to define the permissions that his application requires. All permissions an applications needs are specified in the AndroidManifest.xml file, which is part of the every application package. Typical permissions comprise e.g. android.permission.INTERNET permission, which allows applications to open network connections. The permissions that were defined by the developer are shown to the user during the installation process of the application. Upon seeing them, the user can either decide to install the application and grant it all requested permissions, or he can abort the installation process. Permissions can neither be granted individually nor can they be granted or revoked at runtime. This process is also called install time permission grant system, which is the opposite of Time-of-Use permission systems as in Apple iOS. The user either accepts all requested permissions, or he cannot install the application. 

In this report two attacks are presented. First is a Cross-Site Scripting (XSS) attack against WebKit Web engine. The attack is classfied under minor-impact attacks with high rate of occurance. Seocond attack is a permission re-delegation which is an intersect of taxanomies 4 and 6, each of which have severe-impact with medium and high rate of occurance, reprectively. For more details on security factors in Android, see [2].