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.
Flashback Malware Exploiting Unpatched Java on Macs [Updated]
There’s a piece of Mac malware, known as ‘Flashback’, that’s going around and takes advantage of a Java vulnerability in order to compromise and infect Macs online. Although the vulnerability isn’t Mac-specific, and was patched back in February, Apple has yet to distribute that update to everyone via Software Update, leaving everyone vulnerable.
Apparently the team behind this malware is quite efficient at updating it, and so they have been successful in spreading it around. Lion doesn’t come with Java by default, so unless you’ve manually installed it, you’re safe. If you have installed Java on Lion however, I don’t know yet whether Lion’s built-in anti-malware is being updated quickly enough to keep up with the new malware variants (although I highly doubt it).
If you are running Snow Leopard (or earlier), or Lion with a manually-installed Java, then the best thing to do is disable it. The majority of web users do not need Java on a regular basis. I recommend disabling Java system-wide by going to Applications > Utilities > Java Preferences and then unchecking all the checkboxes in the General tab. If you use Safari to browse, you can disable Java by going to Safari > Preferences > Security and unchecking ‘Enable Java‘.
Keep an eye out for an upcoming Java update from Apple.
[Updated] Seems all the talk about this has nudged Apple to act! They’ve released Java for OS X Lion 2012-001 and Java for Mac OS X 10.6 Update 7. F-Secure have released a free Flashback remover tool, and Apple have announced they are also working on software to detect and remove Flashback malware.
Source: F-Secure
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!
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.
Advisory: NAB Credit Card Envelope Information Disclosure Vulnerability
I recently ordered some new credit cards, two sets of two (makin’ it rain baby), and they arrived in the post today in two separate envelopes. National Australia Bank (NAB) send out their cards in unmarked white envelopes, which is good, what’s not so good is that the embossed number on the card gets permanently imprinted into the plastic window of the envelope – presumably due to the pressure of having other envelopes on top of it. As a result, with the right lighting, I was able to read the full card number before I even opened the envelope (blurry snapshot below). It’s probably worth noting that the number will still be legible after the recipient has disposed of the envelope in the trash.
One can argue that having just the card number on its own is not as useful. But remember you’re holding an addressed envelope, so you have the cardholder’s name and address, including post code. You also know the start date on the card, which will almost always be the current month (sometimes the following month), and due to the fact that most credit cards have a lifespan of three years, you can also deduce the year of expiry. The month of expiry may or may not be the same as the start month. The only thing missing is the CVV, but then again there are still plenty of places that don’t require those. With just the card number, an attacker could clone it onto a fake credit card, and start using it in shops with any random signature.
Although this post is intended to be tongue-in-cheek, it probably wouldn’t hurt for NAB (or their card printing company) to fix this ‘vulnerability’. What would PCI say? :D
Grabbing OSX Passwords Through FireWire
There was a lot of attention given to yesterday’s news of Passware Kit Forensic v11 being able to extract your Lion login password if your computer was locked or sleeping, even with FileVault turned on. It’s worth pointing out that not only is this old news (from 2006), it isn’t even a vulnerability specific to Mac OS X, but rather a vulnerability introduced on computers with FireWire (or iLink) ports. The FireWire specification provides external devices with the interesting ability to interact directly with system memory (without going through the OS). While in theory this could open up interesting uses, in reality it just enables vulnerabilies due to the fact that a computer’s live memory can be used to extract data or manipulate parameters. Windows systems are vulnerable to this attack too, and there are tools (eg. winlockpwn) that exist that allow an attacker to unlock a locked Windows machine, or dump its memory, just by plugging into it via FireWire/iLink.
This flaw definitely has security and privacy implications, but only if the attacker is able to get physical access to your computer. As I’ve pointed out on a number of occasions, if someone gets phsysical access to your computer, it’s game over. Even without a FireWire port, techniques such as the Cold Boot Attack may allow an attacker to recover passwords or decryption keys from live memory. Until Apple completely phases out FireWire in favour of Thunderbolt, this will continue to be an issue to be aware of. Thunderbolt itself, although not fully tested, may yet be found to have some similar issues; although I’m hoping Apple/Intel will have learnt from past mistakes.
There’s not a huge amount you can do to protect yourself apart from:
- Disable automatic login, and shut down your computer when you don’t plan on using it (especially if you’re going to be away from it for a while). Note that for this to really be effective, you’ll need to enable FileVault as well – otherwise the attacker will be able to access your unencrypted HD.
- Block your FireWire port with epoxy – or destroy it altogether.
Mac OS X “Lion” and the Dangers of Restoring from a Partition
With the release of Mac OS X 10.7 “Lion”, Apple is changing the way we’ll be doing system upgrades. Lion will only be available to Snow Leopard users electronically through the Mac App Store, and thus it will no longer be possible to purchase a physical install DVD. Before I go into the intended topic of this post, allow me to <rant> about how I’m not too keen on this decision. As a result, it’s no longer possible to install OSX on Macs that don’t have an internet connection (yes, these do exist!). Even for those who do, many don’t have very fast internet connections, or may have extremely low usage caps. I know that UK internet providers still offer entry-level packages 5Mbit lines and stupidly low 1-5 GB monthly limits. Lion is likely to be about 4GBs in size. Oh, you want to install OSX on more than one Mac? Suuure, just download the 4GB install package on each Mac.</rant> You get the point…
The real thing I wanted to talk about is Apple’s solution to system re-installation or recovery, and specifically the security implications thereof. Installing Lion will cause it to create a small ‘recovery’ partition on your primary drive, which is essentially a partition equivalent of an install DVD. If you have a problem with your main OSX partition, and need to run repair utilities or reinstall, you just boot from the recovery partition. Sounds really useful actually, as you don’t need to worry about having a DVD handy. But where this solution brings ease-of-use and convenience, it also brings some security risks.
Although Mac OS X is still largely unaffected by malware, the winds of change are indeed upon us, and it’s unrealistic to assume the Mac will remain virus-free forever. As viruses get more complex they find ever-improving ways of making themselves persistent on a system. There are countless examples of Master Boot Record viruses on Windows where the only sure-fire solution is to completely wipe the hard drive and reinstall from CD/DVD. Because once your system is infected, good security practice forces you to assume that any file or executable is compromised. So, how does this affect a bootable recovery partition? If I were a virus writer, I’d make pretty darn sure that I infect a core installer file on the recovery partition so that any installation will have my virus. The nice thing about DVDs is that even if you insert them into an infected computer, they can’t be changed, and so you have complete confidence (barring a very advanced/rare firmware virus) that wiping and reinstalling from DVD yields a fresh and clean install of your system. As a security professional, I don’t think I’ll be able to trust a recovery partition like that.
But wait, there’s more. Viruses are a concern, but if you’re a smart user they’re not really a problem. We can run anti-virus, disable Flash, Java and Javascript, etc, and as long as you browse safely and don’t open random executables you’ll be perfectly fine. What about an attacker with remote or physical access to your computer? If I remotely hack into someone’s Mac, either due to a vulnerability or a weak password, all I have to do is modify a few files in the existing system and the recovery partition, and boom, persistent back door! The user can reinstall OSX all they want… my back door will simply be reinstalled with it.
But wait, there’s more. Even if your computer is completely secure from remote attacks, the same goes for someone with physical access to your Mac. Now, as a disclaimer, I have to point out that anytime an attacker gets physical access to any computer it’s game over. Even if you use FileVault, I may not be able to log in to your computer (unless some kind of cold boot attack is still possible), but I can easily boot your computer from a USB stick (or remove your hard drive if you have a Firmware password), trojan your recovery partition and corrupt your primary boot partition (similar to an Evil Maid attack). What are you going to do? Reinstall Mac OS X from my trojaned recovery partition of course! It’s not like you have a choice.
Any system compromise can lead to the installation of a persistent backdoor for the lifetime of the recovery partition on that hard drive. I don’t want to sound overly critical; I am probably one of the most fervent Apple supporters you’ll ever meet (with good reasons too), but not to the extent it stops me from thinking about potential impacts. I appreciate that Apple is trying to make things easier for Joe User. Being able to download updates electronically is awesome, and I honestly believe many would take advantage of that (myself included), but users should be given the choice. Particularly in situations like this where not having a physical install medium can have an impact on both usability and security.
My guess (or maybe hope) is that if Apple is not going to sell install DVDs itself, we may be allowed to burn our own install DVDs after downloading Lion from the Mac App Store. Either way, it is fairly trivial to burn the Lion installer onto a DVD – but users shouldn’t have to (or sometimes can’t) resort to a hack like that. Take heed, Apple.
[Update 21/07/11] Ok, so Apple isn’t going to allow users to burn their own DVDs, but they have confirmed that Lion will be available on a mini USB drive in August (for $69).
Loading ...
