Security researcher Charlie Miller (@0xcharlie) has discovered a significant flaw in iOS which may allow a malicious app on the App Store to download and execute arbitrary unsigned code. What this means for iPhone, iPad and iPod Touch users is that installing a malicious app may allow an attacker to obtain shell access to your device, and download contacts or images.
Apple reviews every app submitted to the App Store, which has meant that iOS users have not had to worry about outright malware. Since this vulnerability allows the apps to fetch code remotely, they can perform actions not reviewed by the App Store staff. Charlie had submitted a proof-of-concept app that was approved (see video below), but has since been removed by Apple.
Charlie will be presenting the vulnerability in detail at the SysCan conference in Taiwan next week. Apple has already released a developer beta of iOS 5.0.1 which patches the recent iPad Smart Cover lock screen bypass, but I would not be at all surprised if they release another beta which includes a fix for this bug. Until then, be careful to only install apps from developers you trust.
[Update] Apple has kicked Charlie out of the Developer program. At first I felt that this was an extremely bad reaction on Apple’s part. That said, Apple is probably most upset that Charlie’s proof-of-concept app could have been installed by legitimate users. Regardless of Charlie’s intentions, this could constitute malware, and he should have removed the app as soon as he saw the flaw existed. The posting of his video above probably didn’t help matters either.
Marc Gurman at 9to5Mac has discovered a vulnerability on the iPad that allows for a limited bypass of the device’s lockscreen. Anyone with an iPad Smart Cover (or fridge magnet) can gain access to the previously-open app (or the home screen if no app was open).
By holding the power button to bring up the ‘Power Off’ screen, closing the smart cover, re-opening it (or just sliding a fridge magnet along the right-hand side of the device), and clicking cancel, the attacker will be dropped into the screen that was open before the iPad was locked. If the attacker gets dropped into the home screen, then they’ll be able to see the installed apps, but won’t be able to open anything. If Safari or Mail (or any other app) was the open when the device was locked, then the attacker would have access to that app.
Unlike Siri being available from the lock screen, which is not a security flaw (an unintended behaviour), this one actually is; and although an attacker does not get full control of the iPad, the severity depends on whether a sensitive app was being used before the device was locked.
Luckily it is possible to protect yourself against this bug in the interim by disabling Smart Covers in Settings > General > iPad Cover Lock/Unlock > Off. Expect Apple to patch this in iOS 5.0.1. Check out 9to5’s video below for a demonstration:
[Update] Apple did indeed patch this bug in iOS 5.0.1. Those of you who disabled your Smart Covers for security purposes can now re-enable them!
JailbreakMe.com has been updated to allow easy untethered jailbreak of your iOS devices, just follow the instructions on the site. Thanks to a new PDF exploit from comex (with the help of chpwn), it is now possible to jailbreak iPhones, iPads (including iPad 2) and iPod Touches running iOS 4.3.3 (note this doesn’t yet include any versions below that). During the jailbreak, saurik’s Cydia app store is automatically installed.
Interestingly, users with jailbroken devices can protect themselves by patching the PDF vulnerability by using ‘PDF Patcher 2’ in Cydia. Normal users will have to wait for iOS 4.3.4 from Apple. Note, however, that having a jailbroken iPhone or iPad still makes you slightly more vulnerable to other attacks, as the iOS sandbox is essentially bypassed.
The Mac App Store was released in the recent 10.6.6 update, allowing Mac users to buy and install apps in the same, easy, one-click fashion as iPhone and iPod Touch users. Over 1 million apps were downloaded in the first 24 hours. Although the Mac App Store doesn’t make use of a sandbox like the iOS App Store does, there are still several mechanisms developers can use to prevent their software from being copied and shared between different users.
Hackers have discovered that one of the simpler methods used to authenticate an app is actually stored as a separate plist file within the application bundle. This means that an app can be copied, and the authentication files within its bundle can be replaced with those from an app that was legally purchased (even if it’s a free app).
In order to resolve this, developers should not rely solely on the data found within the plist file external to the binary, and perform some checks against hard-coded values within the binary itself. Some simple tips are available here. Ultimately all software is crackable, Mac App Store or not, so my suggestion to application developers is: spend more time developing great new features, and less time worrying about anti-piracy. This is what itself Apple does. In the long run most people will follow the simplicity route and buy the app.
In related news: How not to store passwords in iOS (developers take heed)
With the recent high-profile Gawker compromise, their entire source code and user database are available as a torrent. Some people have taken to cracking the (weak) password hashes, whilst others are looking for bugs in the source.
GBOTD#1 is a XSS found in the first 3 lines of the first file:
According to Mike, he’s already found over 30 bugs after just a few hours of hunting.
Gawker Media, who run many other sites including Lifehacker, Gizmodo and io9, have had their servers and databases hacked by a group called Gnosis. This results in over 1.3 million user accounts being compromised, across their various websites. Part of the issue is the fact that Gawker were using the outdated DES algorithm to secure passwords in the database, making it trivial for the hackers to crack the hashes. To make matters worse, many Gawker admins have also been using extremely weak passwords for their accounts. A full account from the hackers’ perspective can be found here, and there is clearly some beef between them and Nick Denton (owner of Gawker) who appears to have been baiting 4chan (baad idea).
The 1.3 million user accounts, together with Gawker Media’s source code, have been made available in a torrent posted on The Pirate Bay. You can quickly check whether your account is one of those by checking out this spreadsheet (Google). It’s safe to say that if you have any accounts on websites run by Gawker Media, you’re going to want to change your password. If you happen to reuse passwords a lot, then you’ll want to change your password everywhere… isn’t password reuse a joy?
Note: This is a 2008 post I managed to recover from my archive of Securethoughts.net
A team of researchers at Princeton University have devised a way to compromise disk encryption mechanisms, and even other disk image encryption mechanisms, by recovering latent data such as encryption keys, that remain in RAM after a computer has been rebooted/turned off. They’ve tested their attacks against encryption mechanisms such as Microsoft’s BitLocker, TrueCrypt, Linux’s dm-crypt and Apple’s FileVault.
This technique is ingeniously simple, and they’ve written a tool from which they can boot a computer, and do a memory-dump of the latent memory data, which they then run through another utility which searches the memory dump for encryption keys, which can then be used to decrypt the encrypted drive/images.
With regards to Mac OS X 10.4 and 10.5, the group discovered that the system stores multiple copies of users’ login passwords in active memory, making them vulnerable to such imaging attacks. Those passwords are often used to protect the keychain, which stores many of users’ other passwords, including the FileVault password, and potentially other encrypted disk images. This is potentially something Apple should address, and they don’t really want to be storing passwords and keys in memory, if they don’t have to. Keeping as little sensitive data in active memory as possible would greatly reduce the chances of it being compromised in imaging attacks such as these.
Check out their great video below, and read more about it after the jump! Read more