Securing your jailbroken iPhone
December 2, 2009 at 9:02 am
Unless you have been cut from the net this last week, you probably know
by now iPhones are facing their first set of malware (first ? well, actually, not quite as we have already detected spyware for iPhones):
it’s just all over the web. Those malware target jailbroken iPhones whose the default root password (’alpine’) hasn’t been changed.
Consequently, most people remind/advise iPhone owners to customize root’s password or not to jailbreak their iPhone. This is correct, but it is nonetheless worth adding that:
- all passwords should be customized: for instance, change the password of the mobile account too (i.e. the default user account).
- never use a default password whether it is ‘alpine’ or anything else. iPhones with old firmwares (older than 1.1) use default password ‘dottie’. True, they are not vulnerable to the worms we encountered, but the modification would be so basic…
- do not use simple passwords. This is true for PCs, it is true for iPhones too. It would be easy to modify the worms to brute force passwords. Incidentally, that’s how Sophos found iPhoneOS/Eeki.B changes the password to ‘ohshit’. By the way, thanks to Scott McIntyre (xs4all) for sharing his sample with us.
With this in mind, I reached over for our lab’s iPhone and placed myself in the situation of a typical iPhone owner trying to secure his device. I turned the iPhone on, disabled wifi, connected the iPhone to a lab’s PC via USB and set up a SSH tunnel (I like iUSB Tunnel, because it’s simple).
At this stage, either the iPhone hasn’t been compromised and login succeeds with default password (alpine): please jump to “Changing passwords” below, or it has been compromised and root’s password consequently changed: then, logging in with the default password will fail.
In that case, I would probably recommend you completely re-install the iPhone, because one never knows what the intruder did to the phone. Remember he/she had root access to the device, he/she could do anything.
For now, let’s suppose you decide just to change the passwords, inspect the iPhone and re-install later.
To customize a password, the current one is required. If you know the password (’alpine’ by default, ‘ohshit’ if compromised), then no problem, change the password (jump to ‘changing passwords’). If you don’t know what the old password is, the easiest solution consists in editing /etc/master.passwd with a text editor that runs as root. For instance, install iFile (eu.heinelt.ifile), browse to the /etc directory and open master.passwd for edition.
Temporarily reset root’s password to ‘alpine’ (default):
root:/smx7MYTQIi2M:0:0::0:0:System Administrator:/var/root:/bin/sh
Sidenote. I find it quite dangerous such text editors run with root privileges!
Then, login as root using password alpine and change it. See below.
Changing passwords
As a side note, I realized that picking up a nice (and secure) password was quite difficult on mobile phones, because even if the iPhone’s virtual keyboard is handy, you usually don’t feel like entering a long and complicated password (e.g. special characters are not immediately accessible on the virtual keyboard). iPhone developers, we’d certainly love to have a thumbprint authentication application, or an application where the password is a few secret gestures on the touchscreen, perhaps like a handwritten signature (but a secret one). Those gestures could translate into a long and complicated key we would not generally need to enter.
Once I changed passwords, it occurred to me that, anyway, any login attempts should be logged. I searched /var/log and /var/logs but couldn’t find any log concerning SSH. So, I opened the SSH daemon configuration file (/etc/ssh/sshd_config) and uncommented those lines:
#SyslogFacility AUTH
#LogLevel INFO
Restarted the SSH daemon, and re-logged in: still no logs ! Yes, actually, the iPhone ships with no syslog daemon ! So, I downloaded and installed a syslog daemon (com.) and configured /etc/syslog.conf:
*.*;auth.info /var/log/syslog
After restarting syslog and ssh, this time I finally get my logs in /var/log/syslog:
Nov 24 14:29:15 iPhone-de-axelle sshd[6270]: Failed password for mobile from 127.0.0.1 port 56304 ssh2
Nov 24 14:29:18 iPhone-de-axelle sshd[6270]: Accepted password for mobile from 127.0.0.1 port 56304 ssh2
Actually, logs are rather useful before one gets compromised, to see the failed login attempts, because once an intruder has successfully logged in as root, he/she can stop the syslog daemon or erase /var/log/syslog…
Finally, I ought to point out allowing root login via SSH is usually considered as insecure. Disable it in /etc/ssh/sshd_config (check out other security options) :
PermitRootLogin no
– The Crypto Girl (with her iPhone)


Twitter
FaceBook
LinkedIn
YouTube
[...] In terms of reported attack cases, Adobe.Products.SWF.Remote.Code.Execution moved into third place this month while MS08-067, notoriously exploited by Conficker, remained in first. Flash and actionscript are constantly targeted to exploit systems, with innovations being leveraged such as Flash run-time packers. New developments on the threat landscape this period include an out-of-band patch for Adobe Shockwave (APSB09-16), a zero-day vulnerability with Internet Explorer (CVE-2009-3762), a Windows 7 DoS, and a new worm targeting jailbroken iPhones. November has been very active for iPhones with 4 new attacks exploiting a misconfiguration of OpenSSH on jailbroken devices: malware targeting Dutch iPhones for ransom ($7 USD), a tool stealing SMS and contacts (HackerTool/iPhoneStealer), a worm changing the background image and another one trying to steal banking credentials (iPhoneOS/Eeki). These are all areas in which threats will likely continue to develop, so be safe out there – keep all software up to date, employ a valid intrusion prevention system to guard against vulnerabilities and zero-days, and if you own a jailbroken iPhone, change the root password now. [...]