Security

What lessons can be learned from the iPhone worms?

Word spread quickly earlier this week when the first known worms targeting the Apple iPhone surfaced days apart in Australia and the Netherlands. Neither inflicts serious harm on devices — though perhaps the Australian "Ikee" worm is guilty of crimes against good taste, as it swaps out the iPhone's wallpaper for a vintage photo of Rick Astley. The events are notable, however, because they only affect jailbroken iPhones, raising questions over whether the iPhone jailbreaking community behaves responsibly when it frees the devices from Apple's factory restrictions.

Ikee was created on November 4 by Ashley Towns, a programmer from Wollongong, Australia. The worm propagates by scanning IP ranges in the blocks used by the iPhone's Australian carrier, checking for iPhone OS fingerprints, and looking for a running SSH daemon on any iPhones it finds. Because all iPhones ship from the factory with the same default root password, "alpine", the worm can connect, copy itself over to the new device, install its signature wallpaper, and repeat. Ikee also deactivates SSHd on the host phone as part of its payload, but it does not change the root password. Thus, restarting SSH makes the phone vulnerable to reinfection.

It attracted considerably less public attention than Ikee, but on November 2, a worm surfaced in the Netherlands using the exact same attack vector: IP range scanning of the approved 3G carrier, OS fingerprinting, and connecting via SSH using the default password. The Dutch worm lacked the campy sensibility of Ikee; rather than Rickrolling the iPhone's wallpaper, it popped-up a message telling the user that the iPhone was insecure and asking €4.95 for instructions on how to secure it. That same day, however, the author changed his mind and posted both an apology and free instructions for securing the phone on the web site to which the worm pointed its victims.

Jailbreaks are risky. Much like in real life.

"Jailbreaking" refers to hacks that enable full access to the iPhone's operating system, and is distinct from SIM unlocking, which removes carrier-restrictions that limit the device to registering on only approved 3G networks. The iPhone has multiple layers of security built into the OS, including everything from boot loader restrictions to application code signing. The term "jailbreak" originates from the fact that all iPhone applications run inside a chroot jail; when connecting the iPhone to a Mac or PC only the contents of the chroot jail are accessed by the iTunes application for installing and removing media content and applications.

Consequently, breaking out of the chroot jail is required to perform any real OS customization, and the popular jailbreaking utilities set up niceties that most hackers will expect on a Unix-like system like OS X. That includes SSH, which obviates the need to keep the phone attached to a PC by cable while working on it.

It is Apple's decision to ship all models of its iPhone with the same root password — a tactic common to embedded device makers, if not particularly secure. The point of debate is whether the security hole left open by the combination of a default root password and a running SSH daemon is Apple's fault, the jailbreaking tool authors', or simply the users'.

Searching for solutions

Changing the password is simple enough; should PwnageTool, PurpleRa1n, and the other jailbreak utilities do so upon installation, either by automatically generating a new password or by prompting the user? An Australian blogger who interviewed Towns about Ikee thinks so; he posted an opinion piece following up on the interview in which he asks the jailbreaking tool developers to to do just that.

From reading the various news sites' discussions, it is clear that plenty of others disagree, noting that the responsibility for securing the device stops with the end user. But is there any substantial risk to changing the root password on the device, when measured against the risks of a default password exploit? Default password exploits are well-known enough that most end-user applications have moved away from them; other than the fact that the iPhone is an embedded system, why should it be measured by different standards than a desktop or server, or for that matter, a PayPal account?

For comparison's sake, Android phones do not include a password-enabled root account, and although changing this is well-documented, it is a complicated process even for the comparatively unlocked Android Dev Phone 1. Similarly, installing a working SSH daemon is not a straightforward process even on a rooted phone. On the other hand, Maemo offers OpenSSH (both client and server) as a one-click install, but installing it automatically prompts the user to change the root password from its default.

ComputerWorld's Robert McMillan speculates that Apple cares little about the issue — jailbroken phones are not covered by warranty, so there is no incentive for the company to close its part of the security hole by changing its root password policy. In fact, it may tacitly approve of the negative press generated around jailbreaking.

On the other hand, as the author of the Dutch worm put it, "the way I got access to your iPhone can be used by thousands of others. And they can send text messages from your number (like I did..), use it to call (or record your calls), and actually whatever they want [...]" The next exploit taking advantage of the iPhone's default root password may not require a jailbroken device. Apple will surely sit up and take notice then. In the meantime, though, the question remains: should the people who care about freeing a device from the factory's proprietary lock-downs also care about putting it into a secure state once it is free?

While some FOSS-based phones may not require jailbreaking — or not enable SSHd as part of the process — there are warnings here for Google, Nokia, Palm, and others. By forcing users to perform dodgy operations on their phones, in order to enable the functionality they want, phone makers may very well be putting those users at risk. Whether the underlying code is open source or proprietary doesn't alter that risk.

Comments (15 posted)

Brief items

Vixie: What DNS Is Not

Comments (none posted)

New vulnerabilities

alienarena: buffer overflow

Comments (none posted)

apache: man-in-the-middle/SSL injection

Comments (none posted)

cups: cross-site scripting

Comments (none posted)

drupal6: multiple vulnerabilities

Comments (none posted)

horde: cross-site scripting

Comments (none posted)

java: multiple vulnerabilities

530053 - CVE-2009-3873 OpenJDK JPEG Image Writer quantization problem (6862968)
530057 - CVE-2009-3875 OpenJDK MessageDigest.isEqual introduces timing attack vulnerabilities
(6863503)
530061 - CVE-2009-3876 OpenJDK ASN.1/DER input stream parser denial of service (6864911)
CVE-2009-3877
530062 - CVE-2009-3869 OpenJDK JRE AWT setDifflCM stack overflow (6872357)
530063 - CVE-2009-3871 OpenJDK JRE AWT setBytePixels heap overflow (6872358)
530067 - CVE-2009-3874 OpenJDK ImageI/O JPEG heap overflow  (6874643)
530098 - CVE-2009-3728 OpenJDK ICC_Profile file existence detection information leak (6631533)
530173 - CVE-2009-3881 OpenJDK resurrected classloaders can still have children (6636650)
530175 - CVE-2009-3882 CVE-2009-3883 OpenJDK information leaks in mutable variables
(6657026,6657138)
530296 - CVE-2009-3880 OpenJDK UI logging information leakage(6664512)
530297 - CVE-2009-3879 OpenJDK GraphicsConfiguration information leak(6822057)
530300 - CVE-2009-3884 OpenJDK zoneinfo file existence information leak (6824265)
532904 - CVE-2009-3729 JRE TrueType font parsing crash (6815780)
532906 - CVE-2009-3872 JRE JPEG JFIF Decoder issue (6862969)
532914 - CVE-2009-3886 JRE REGRESSION:have problem to run JNLP app and applets with signed Jar
files (6870531)
533211 - CVE-2009-3865 java-1.6.0-sun: ACE in JRE Deployment Toolkit (6869752)
533212 - CVE-2009-3866 java-1.6.0-sun: Privilege escalation in the Java Web Start Installer
(6872824)
533214 - CVE-2009-3867 java-1.5.0-sun, java-1.6.0-sun: Stack-based buffer overflow via a long file:
URL argument (6854303)
533215 - CVE-2009-3868 java-1.5.0-sun, java-1.6.0-sun: Privilege escalation via crafted image file
due improper color profiles parsing (6862970)

Comments (none posted)

kernel: integer overflow

Comments (none posted)

libvorbis: arbitrary code execution

Comments (none posted)

qtwebkit: arbitrary local file access

Comments (none posted)

typo3: multiple vulnerabilities

Comments (none posted)

wordpress-mu: denial of service

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>