SANS Penetration Testing

Mobile Application Assessments Part 2: A Look at Windows Mobile

[Editor's note: This is the second article in a series of tips, tools, and techniques for analyzing mobile applications and their associated infrastructures. It builds on the previous article which focused on an overall approach, but now focusing on tools and common findings for vulnerable Windows mobile client applications. -Ed.]

By Erik Van Buggenhout, Koen Van Beirendonck, and Pieter Danhieux
In our previous article in this series, we sketched out a generic approach penetration testers and vulnerability assessment personnel can apply to assessing mobile applications. In this post, we will look at the client-side part of the assessment for Windows Mobile applications.

In this article, we'll consider an example assessment, directly based on real-world tests we've performed for our clients, in which we look at a Windows Mobile application that is used on employee PDAs and communicates with a central server in order to fetch and update client data. In particular, a custom Windows CE application is running on the PDA, with a connection to the server carried across a 3G network.

The main focus of our assessment will be to see if an attacker can steal the PDA and obtain sensitive client data or even manipulate it (from a black-box perspective). According to the design and architecture of the application, this data should not be present on the PDA itself, but should only be stored server-side.

As a first step, we start by analyzing access to the PDA itself. The penetration tester can begin by booting the PDA and checking if any obvious security measures are present. During our example assessment, we noted that the PDA was not password-protected and only asked for a PIN code in order to establish a 3G connection. This PIN code prompt can be avoided in order to access the PDA without 3G connectivity (and obviously also no back-end connection to the server).

Once we have access to the device, we analyze whether the PDA is hardened in any way. An older (published in 2008), but still very interesting read on this is NIST's Guidelines on Cell Phone and PDA Security. During our example assessment, we noted that the PDA was being used in a "default" mode, without any specific security configurations or hardening measures (no authentication to access the device, no encryption, unnecessary services enabled, etc.). We thus had full control over the PDA, the client-side device itself. When we tried to launch the application under analysis, however, we still receive an application-level login prompt. The goal of the assessment is to attempt to obtain / manipulate client data, so we'll need to go further and also obtain access to the application itself.

Given the vulnerabilities noted above, the next step will be to simply hook the PDA to our computer and copy all data & files that are stored on the device, as shown in the figure below:

By analyzing the structure of the application and researching these file names and suffixes, we can identify the following interesting information:

-It clearly is a .NET application (note the OpenNETCF files in the figure)

-It is using a .sdf Compact SQL Server database (note the .sdf file in the figure)

In order to assess the application logic, we will attempt to decompile the .NET application using the commercial (but relatively inexpensive) Reflector .NET tool. The results of Reflector show us that the application code is not obfuscated. Consequently, we were able to deduce the following interesting line of code:

So, we've found the application's .sdf file which contains the database, and we've found a hard-coded clear-text password in connection string in the application code! Using a low-cost tool such as sdfviewer or Primework's Data Port Console, we can open the entire database structure and contents (provided we have the right credentials):

Interestingly enough, the application is storing loads of personal information, much to the surprise of the company that asked us to perform the assessment. This is what we in the business like to refer to as a "significant finding," and it puts a smile on our faces.

Furthermore, exploring the database's contents in more detail, we also identified that the logon information of the last logged on user is recorded in the database. The credentials are stored in a weak, reversible hashing algorithm and can thus be abused to obtain valid access to the application, even across the 3G network.

Now that we have also obtained access to the application, the final piece of the puzzle is getting the connection towards the server going and really be able to interact with the back-end. Again, this did not prove to be a tough nut to crack, as a default PIN code (0000) proved to be enough to allow access to the 3G connection and dedicated APN.

In summary, using the identified vulnerabilities, an attacker that steals a device with this application can easily manipulate any client data stored on the server (using the credentials of the last logged on user). Furthermore, without access to the application itself, an attacker could still extract loads of sensitive client data stored on the PDA filesystem itself.

Our report for this assessment will include the following vulnerabilities:

- The PDA is not using any form of authentication (e.g., password / fingerprint)

- The PDA is not hardened (unnecessary services such as Bluetooth and WiFi are enabled)

- Client application code is not obfuscated

- The local database is accessed using a weak password, and a cleartext, unobscured password is readily accessible and easily discoverable in the code

- Personal information is stored client-side on the PDA

- Last logon password is stored using a weak hashing algorithm

- The 3G connection is only protected using a default PIN code

Stay tuned for our next posts in this series, which will further analyze mobile client-side assessments on iOS, Blackberry, and Android.

-Erik, Koen, & Pieter

Post a Comment






Captcha


* Indicates a required field.