ESET Threat Blog

Archive for the 'jailbreak' Category

iPhones, jailbreaking and blocked Apple IDs


Tuesday, February 16th, 2010

[Update: The Register's John Leyden has also commented on the issue at http://www.theregister.co.uk/2010/02/16/apple_bans_iphone_hackers/]

There's been a burst of interest in the last day or so in the blocking of certain Apple IDs from the iTunes App Store. Some bloggers have suggested that this might be a precursor to a massive blocking of jailbroken phones from accessing the App Store.

However, the reports I've seen all mention only two specific IDs, both of associated with individuals who are well known as having publicised vulnerabilities, so it sounds to me as if this measure is specific to individuals perceived as posing a security threat, not as a means of punishing jailbreakers by denying them the opportunity to pay for legitimate, approved apps supplied by software houses with whom Apple has a commercial relationship.

More comment on this at Mac Virus here  and here. Also, thoughts on the Wholesale Applications Community which brings together three of Apple's major competitors in the mobile phone industry and a large group of major telecoms providers.

David Harley CISSP FBCS CITP
Director of Malware Intelligence

ESET Threatblog (TinyURL with preview enabled): http://preview.tinyurl.com/esetblog
ESET Threatblog notifications on Twitter: http://twitter.com/esetresearch (or

http://twitter.com/ESETblog)
ESET White Papers Page: http://www.eset.com/download/whitepapers.php

Securing Our eCity community initiative: http://www.securingourecity.org/

Also blogging at:
http://smallbluegreenblog.wordpress.com/
http://avien.net/blog
http://blogs.securiteam.com
http://blog.isc2.org/
http://macvirus.com/

Whitelisting and the iPhone


Wednesday, November 25th, 2009

The much reported/blogged iPhone worm does not affect all iPhones. Specifically it affects SOME iPhones that have been jailbroken. A significant part of the iPhone and iPod Touch security model is a technique called “whitelisting”. This is not new and is known to be a very effective security technology that can be used to prevent malicious software from running on all kinds of computers or to only allow access to specific web sites. Fundamentally, network access control is a type of whitelisting.

When an iPhone or Touch is jailbroken, the whitelisting technology that has kept the rest of these devices pretty darn safe is removed. Estimates I have seen published put the number of jailbroken devices at close to 10%. I suspect this number has not yet topped out. So you have a security model that honestly is pretty darned effective and people are removing it. Why is this?

People love choice and functionality. There is a significant amount of overheard involved in most whitelisting implementations. An employer can deploy a whitelisting solution and mandate it’s use, but when you get out into user-land and personal property, people like choice and Apple does not provide the level of choice that a significant number of users desire.

Usability and security are often at odds. In the case of the iPhone malware, there was a really simple security step that protected some users of jailbroken devices. A default password that was changed by security savvy jailbreakers protected their devices from the latest round of jailbroken iPhone vulnerabilities while still allowing them a wider choice of software.

While whitelisting has some strong security advantages, there’s a reason why adoption has been limited.

Randy Abrams
Director of Technical Education

iPhone Hack Tool: a Postscript


Thursday, November 12th, 2009

Update: there's more information on the Windows 7 exploit mentioned below in a Register article at http://reg.cx/1FcX.

Update 2: I keep seeing references to this as a virus or worm. However, the code I've seen does not contain any self-replicative functionality. It's not even a Trojan, as such.

Following an extract from one of my blogs yesterday about the iPhone hack tool cited by Greg Keizer in Computerworld, I was taken to task in a comment by someone who rightly pointed out that "Apple has no obligation to secure jailbroken iPhones".

I hope the anonymous poster (and indeed Computerworld) won't mind if I quote a little more.

"Apple has no legal or moral obligation to secure jailbroken iPhones. Those, who jailbreak their iPhones, do so in violation of their promise to not modify the iPhone OS. That alone relieves Apple of any legal or moral obligation to repair security flaws in jailbroken iPhones."

That does sound to me a little like the familiar Mac Fanboi position of "No Mac user would ever be stupid enough to do something insecure and if they do it's their own fault." Still, no-one said that Apple is under an obligation to secure jailbroken phones: well, I certainly didn't. In fact, I don't condone or advocate jailbreaking, as you'll have gathered from my earlier blogs, if you read them. I do think, though, that Apple should, consider whether there are ways of mitigating proactively vulnerabilities introduced by jailbreaking. Or even of introducing safer ways of allowing the installation of unapproved applications, though allowing any app install is going to be less safe than maintaining an iron grip and blocking any unauthorised install. (And that applies on any platform.)

If Apple can introduce any proactive mitigation, though, the community will benefit from being a little bit better protected from itself (isn't that mostly what security people do?), and Apple will benefit from being perceived as going the extra mile.

On the subject of things I didn't say, I notice that some of our competitors are saying that this is a non-issue because there's nothing new about it. Absolutely right: it's just another vulnerability, though the fact that it's introduced by the end user is mildly interesting. Given that there's a simple way of shortcircuiting it, though, I can't see why you wouldn't pass on that information. It's called good netizenship, guys…

Incidentally, my colleague Aryeh Goretsky drew my attention to another interesting Proof-of-Concept case of strangling by Python script, in this case an allegedly remotely exploitable kernel crash in Windows 7.0/Server 2008R2. Since I'm not sure I'm in the full-disclosure business, I'll do some checking before I give more details here. 

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

ESET Threatblog (TinyURL with preview enabled): http://preview.tinyurl.com/esetblog
ESET Threatblog notifications on Twitter: http://twitter.com/esetresearch
ESET White Papers Page: http://www.eset.com/download/whitepapers.php

Securing Our eCity community initiative: http://www.securingourecity.org/