Lock Screen Bypass in iOS 7 Beta 1
A new version of iOS, a new lockscreen/passcode bypass! Luckily this one was caught early in the first Beta of iOS 7 released to developers at WWDC 2013. Although this lockscreen bypass is simpler than some of the previous ones that required some tricky steps to pull off, it’s probably worth pointing out that it will only allow access to the phone’s photos, and the ability to delete, email, tweet or upload the stored image files. It does not allow access to any other apps.
I should point out that I played with iOS 7 for a day, and it was so buggy that I had to downgrade back to iOS 6. Luckily Apple has plenty of time to fix all these issues come the release date this fall.
To bypass the lockscreen simply follow these easy steps:
- Pull up the Control Center
- Tap the Calculator icon to open it
- Pull up the Control Center again
- Tap the Camera icon to open it
- Tap the photos icon in the bottom-left corner to get full access to the photos
Check out the video below to see it in action.
New Lockscreen Bypass in iOS 6.1
In a vulnerability that’s quite similar to one in iOS 4.1 a couple years ago, another lockscreen bypass has been discovered in iOS 6.1 which allows someone with physical access to your iPhone to make calls, view and modify your contacts, send an email to your contacts, listen to your voicemail, and access your photos (by attempting to add one of these to a contact).
The method for this bypass is fairly simple (see the video below for it in action):
- Swipe to unlock and then tap Emergency Call
- Make an emergency call (eg. 112/911) and immediately cancel it (please don’t unnecessarily call the emergency services ;)
- Press the power button twice
- Slide to unlock
- Hold down the power button for a couple seconds and then tap Emergency Call again.
- …
- Profit!
I should point out that this doesn’t seem to work on my iPhone 4 for some reason. Something does happen, but I just get a black screen until I press something whereupon I’m booted back to the lock screen.
There Is No Camera Lock Screen Bypass in iOS 5.1
There have been reports (and here) of iOS 5.1 containing a camera bypass tied to the new camera shortcut on the lock screen. The people who have reported this are sadly confused about the security timeout enforced by iOS’s Require Passcode setting (Settings > General > Passcode Lock > Require Passcode). If your Require Passcode setting is set to anything other than Immediately, then your device (and the camera roll from the camera shortcut) will be accessible for the entire duration of time specified (ie. 1 minute or 5 minutes).
As always, the best setting for Require Passcode is Immediately. That way you know that when you lock your device, it is actually locked, and will prevent someone from gaining access to it without the passcode within the minutes following the ‘lock’.
Sadly people seem all too eager to rush and report on iOS vulns before actually verifying them.
TDLR; There is no lock screen bypass in iOS 5.1 using the new camera shortcut. They were wrong.
Charlie Miller Discovers iOS Code-Signing Bypass Vulnerability
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.
The reason this vulnerability works is based around some changes Apple made in iOS 4.3 last year, which allowed Mobile Safari to run javascript at a more privileged level on the devices. This change required Apple to make an exception for Safari to execute unsigned code in a particular area of memory. Charlie Miller’s bug is allegedly a very unique case that allows any app to take advantage of this, and hence run their own unsigned code.
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.
iPad Lock Screen Bypass Vulnerability using Smart Cover [Patched]
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!
Securing Siri on a Locked iPhone 4S
Although I haven’t had the chance to play with her myself (does that sound wrong?), Siri seems like an awesome addition to the iPhone. It’s worth pointing out, however, that it is still possible to use Siri when the iPhone is locked – presumably for convenient ease-of-use. Unfortunately this means that anyone with physical access to your phone can access information including contacts, calendar items, SMS/iMessages, and also make calls and send emails or messages from you.
[Update] There have been a whole bunch of people crying about how this is a major security flaw. Just to dispel some of the myth… this is not a security flaw, it’s a design decision that Apple made based on usability. Yes, it’s a default setting that may introduce some vulnerabilities, but then again there are still lots of people who run around without passcodes. To be honest I’m usually the first to secure the hell out of everything, but in this case I feel they made the right decision for two reasons. First, Siri is obviously less useful as a hands-free assistant if you need to unlock your phone every time; and secondly making it easier to use will help drive the adoption of Siri.
Luckily Apple thought of this on at least two levels. First, if you ask Siri to unlock your iPhone she’ll respectfully tell you that she “can’t unlock your phone for you”. Secondly – and this is the important one – it is possible to disable the use of Siri when the iPhone is locked. The option now lives in Settings > General > Passcode Lock, where you can set Siri to Off.
Needless to say (contrary to the screenshot), I recommend setting ‘Require Passcode’ to Immediately, turn Simple Passcode off so you can set a 5-or-more-digit PIN, set ‘Siri’ to off to prevent access when your iPhone is locked, and turn on Erase Data after 10 failed passcode attempts.
Siri is great, but let’s not make it easy for someone to social-engineer her into betraying you. See my other post for more details on protecting your iPhone from loss and theft.
In other news… you can tell Siri to use a specific nickname when talking to you. It’s important to note, however, that the nickname will be put into your VCard. So be careful if you tell her to call you her pimp, and then send someone your contact details ;)
Extracting and Cracking Mac OS X Lion Password Hashes [Updated]
The Defence in Depth blog has a post about a flaw in Lion’s redesigned authentication mechanisms and Directory Services. In short, it is possible to change the password of the currently logged in user by simply running the following command in the terminal, and it won’t ask you for the user’s current password:
$ dscl localhost -passwd /Search/Users/<username>
In Lion it is also easy to dump a user’s SHA-512 password hash using the following command:
$ dscl localhost -read /Search/Users/<username>
Then look for the dsAttrTypeNative:ShadowHashData chunk in the output (sample below). The hex string in red is the salt, and the green is the hash.
62706c69 73743030 d101025d 53414c54 45442d53 48413531 324f1044 74911f72 3bd2f66a 3255e0af 4b85c639 776d510b 63f0b939 c432ab6e 082286c4 7586f19b 4e2f3aab 74229ae1 24ccb11e 916a7a1c 9b29c64b d6b0fd6c bd22e7b1 f0ba1673 080b1900 00000000 00010100 00000000 00000300 00000000 00000000 00000000 000060
Cracking password hashes can be done using his custom Python script, or John the Ripper (with the Jumbo patch). Note that even if someone manages to obtain your password hash, if you’re using a strong password it will be extremely difficult for them to recover it. Seems like both of these are important but fairly low-risk flaws introduced into Lion. Hopefully Apple will look into these for the next update.
[Update 1] While waiting for an Apple-supplied security update, it is possible to protect yourself from this vulnerability by adjusting the permissions on dscl:
sudo chmod go-x /usr/bin/dscl
This makes it so that only root can execute dscl. To revert this simply run:
sudo chmod go+x /usr/bin/dscl
[Update 2] This vulnerability was patched in Mac OS X 10.7.2.
Lion + LDAP = Authentication Bypass
Around a month ago, Mac OS X Lion (10.7) was found to have a fairly severe vulnerability when configured to use an LDAP server for authentication. In such a configuration, the system accepts any username or password upon login. This affects both the user interface, but also remote login such as SSH. This issue does not affect normal Lion users who haven’t set up an LDAP server.
Details of the issue aren’t well known, and as much as I’d like to reproduce the issue, I’m too lazy to set up an LDAP server to do it. My guess is that OSX queries the LDAP server, but a bug in the authentication and authorization code makes it so that the user is granted access regardless of whether a login failure is received from the server. I’ve heard reports that it’s possible to login using any non-existent username (with some errors about invalid home directories), but then it begs the question: who do you end up logged in as, and what privileges do you have? If you login with a known username, then you get access in the context of that user. I can’t say for certain, but this vulnerability should not allow a user using an invalid password to gain access to network resources that rely on that user’s authentication credentials, just the local system.
Apple hasn’t yet acknowledged the issue as far as I know, and it’s surprising that no patch was issued with 10.7.1. Perhaps a fix will come in the form of a security update, or the upcoming 10.7.2 update. In the meantime, consider disabling LDAP authentication on Lion systems to prevent unauthorised access.
Safekeeper Hotel Safe Bypass Video
I spent a week in Hawaii on the way back from Blackhat and Defcon in Las Vegas, and my hotel room had a Safekeeper key-lock safe that you had to pay $5 a day to use. Turns out the safe was perfectly usable without the key – which I guess nullifies the safe’s entire purpose. Although it had a Medeco lock, the lock wasn’t really necessary, I used a paperclip as my ‘key’. There must have been something really wrong with the way the plug was installed, I’d be horrified if this ‘attack’ worked on all of these safes. Unfortunately I only had the one in my room to play with.
Check out my demo video below for some facepalm-worthy safe bypass action!
[Updated] A guy called Brad found that his electronic hotel safe could be opened using an all-zero passcode.
Researchers Extract iPhone Data and Passwords in Minutes
A group of German security researchers from the Fraunhofer Institute for Secure Information Technology have discovered a way of extracting personal information and stored credentials from a locked iPhone, by way of a jailbreak. By gaining physical access to an iPhone (or iPad/iTouch), an attacker is able to reboot it into recovery mode, thus allowing them to upload their own jailbroken firmware onto the device. As part of this process SSH is enabled and a script can then be uploaded to the device which uses built-in system calls to extract encrypted data (including credentials in the keychain) from the device. See the video below for a demo of their attack, which can take as little as six minutes.
This attack would not be possible without existing jailbreak mechanisms, which effectively bypass the iPhone’s sandbox and allow unsigned code to be executed. The second issue is the way that iOS handles stored data and credentials, allowing any application to request the information. This is actually a prime example of the dangers of having a jailbroken iPhone or iPad, as it makes it much easier for an attacker to execute malicious code on your device.
These kinds of issues are not isolated to iOS devices, and the same would exist on other devices that could be made to run custom scripts. This will be a tricky issue for Apple to resolve, as much of its security relies on a strong sandbox. Their best chance is to try to identify and patch as many of the vulnerabilities that could be used for a jailbreak. They will also need to review the way iOS handles encrypted data, and ensure that data cannot be extracted by arbitrary applications.
Luckily there is not yet a publicly available automated tool to perform this attack, so it is unlikely that a random thief will be obtaining your data. If you’re really worried, you can use Apple’s free Find My iPhone service to remotely wipe your iOS device should it be lost or stolen. Check out my article on protecting and recovering your iPhone from loss and theft for more information.
The team’s original research paper is available here (PDF).
Loading ...
