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!
This research was performed by J. Alex Halderman , Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, and Edward W. Felten. A combined team from Princeton, the Electronic Frontier Foundation (EFF), and Wind River Systems (specialists in decide software optimisation).
Although their paper focuses on recovering encryption keys, naturally this technique can be applied to any other sensitive information that may be stored in RAM at the time. They’ve also used data reconstructions algorithms to recover data that has already decayed from RAM. According to their paper, keys with 10% of bits decayed can be reconstructed to nearly any 128-bit AES key within a few seconds. On average, they found that memory was legible for up to 20 seconds on some hardware, but this number could extend into several minutes. By drastically reducing the temperature of the memory modules, they were able to reliably recover data up to 10 minutes after removing the RAM chip. Particularly interesting is their research with ECC memory, where they found that machines that support ECC memory tended to wipe RAM upon boot, which is done to avoid errors in the case of uninitialised reads of the memory. Unfortunately this is a characteristic of ECC-enabled machines, and not the memory modules themselves, meaning that ECC memory inserted into non-ECC hardware was still recoverable.
The software developed by the team, presumably with the particular help of Wind River Systems, allowed them to recover the memory dumps in several ways including: over a PXE network boot, which would send the data in UDP packets over the network; using a USB drive to run a small memory-dumping program; or using an EFI bootloader, such as those used on Intel Macs, which also allowed data transfer over netboot.
I highly recommend their paper, particularly the first and last thirds of it, as they are quite legibly written (the middle is mainly about recovering different encryption algorithm keys). It will be interesting to see what kind of innovation will come about in attempts to defend against such attacks. No doubt we will be seeing some papers on that subject soon.