Home > Uncategorized > Mobile Applications Security: Part 3

Mobile Applications Security: Part 3

In my previous two postings about mobile device applications security I’ve described some of the major vulnerabilities in these applications as well as security features in them (if such features exist, which is typically not the case). But there are also other security considerations concerning mobile device applications that must be taken into account. One particularly important one applies to iPhones. A newly installed iPhone is in a “factory state”—the only changes to the system itself should be Apple updates. Certain iPhone applications require significant changes in the phone to be made if they are to be installed successfully, however. These changes, called “jailbreaking,” involve overwriting the iPhone’s firmware. For example, one of the best and most popular iPhone forensics tools, iLiberty, requires that an iPhone be jailbroken. Once an iPhone is jailbroken, not only certain applications but entire application bundles can now be installed on it. It is also possible for a jailbroken iPhone to connect to a 3G network service provider other than AT&T, the thought of which I am sure AT&T does not relish.

Jailbreaking may not sound like a big deal, but it really is in several significant ways:

• It is, according to Apple, a violation of the law.
• It voids the iPhone service warranty.
• Once an iPhone is jailbroken, most of Apple’s content and security controls (including Apple’s sandbox) on it do not work any longer. Jailbreaking thus exposes an iPhone to a much wider range of attacks than in the case of an iPhone in a factory state. Because the Cydia app installer on every iPhone runs as root, applications installed after an iPhone is jailbroken will run as root and will thus not be subject to normal security constraints such as sandbox-imposed constraints. Among other things, this now opens up the way for installing all kinds of malicious code on the iPhone as well as for attacks such as the one described in one of my earlier blog entries in which an attacker can remotely ssh to an iPhone and enter the root password, which, unfortunately, is a now widely known default password unless it is changed by the iPhone owner. If successful, the attacker will own the victim iPhone.
• It also produces numerous changes in the iPhone that may cause the best of iPhone forensics efforts in capturing data from a jailbroken iPhone to be thrown out in a court of law on the basis of questionable forensics data integrity of data. In short, data on a phone on which a possibly illegal act has been performed are questionable.

A considerable amount of naiveté concerning iPhone jailbreaking exists. Those who jailbreak their iPhones too often wrongly assume that they can bring their phones back to a factory state by simply selecting the Restore function that accompanies the Backup function. Although this in some cases appears to be true, it often is not. For one thing, the iPhone may not allow a restoration attempt on a jailbroken iPhone and may instead display an error message every time someone tries to do a restore. Additionally, errors, some of which may impair the iPhone’s functionality from that point on, may occur during the restoration process, causing the restoration of the iPhone to be incomplete. Furthermore, doing a restore results in loss of photos and other information stored on an iPhone. Why not do a backup before restoring to save photos and other information? The answer is that doing a backup first to save this information may not be advisable for reasons described at www.tipb.com/2008/10/…/how-to-problems-with-your-iphone-restore/. Moreover, rumor (but not confirmed fact) has it that an Apple store employee can quickly determine that a jailbroken phone for which the Restore function has been run has been jailbroken by simply entering a code on the iPhone in question.

By the way, Jailbreaking attempts themselves may not even work in the first place. Various Apple updates contain code that keeps known jailbreaking methods from working. In time a few users will create and use a new jailbreaking method, and sometime later an Apple update that prevents this new method from working will become available, and so on.

The bottom line is that issues such as jailbreaking iPhones also need to be considered when an information security practice is modifying security policies and standards because jailbreaking involves more security risks than one might superficially realize. Forbidding jailbreaking unless there is a strong business justification for doing so would at a minimum be a wise thing to do.

Categories: Uncategorized Tags:
  1. No comments yet.
  1. No trackbacks yet.
You must be logged in to post a comment.