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.
Security Update 2011-005 Fixes DigiNotar SSL Vulnerability
Apple has finally issued Security Update 2011-005 to address the recent issues around compromised Dutch certificate authority DigiNotar. It was discovered that at least 531 fraudulent SSL certificates were issued by DigiNotar, leading to their root certificate being revoked in all major operating systems and browsers over the past two weeks. A man-in-the-middle attacker in possession of one of these certs (eg. Google, Skype), would be able to intercept SSL-encrypted traffic to those sites. It is believed that the use of these fraudulent certs may have been limited to the Iranian government.
This patch removes the DigiNotar CA from the trusted root certificates in the Mac OS X keychain (which is also used by Safari) for Lion and Snow Leopard. Unfortunately no patch has been issued for Leopard (10.5) users, leaving them at a heightened risk from these bad certificates. It is recommended that Leopard users delete the DigiNotar CA certificate from the Keychain using the following steps:
- Open Keychain Access (/Applications/Utilities/Keychain Access)
- Click on the System Roots keychain in the top-left hand panel
- Click on Certificates in the bottom-left hand panel
- Type DigiNotar into the search field in the top right.
- Right-click on the DigiNotar Root CA, and select Delete.
# sudo /usr/bin/security delete-certificate -Z C060ED44CBD881BD0EF86C0BA287DDCF8167478C /System/Library/Keychains/SystemRootCertificates.keychain
Firefox users should update to the latest version of Firefox. Here is the full Apple description for this update:
Security Update 2011-005
- Certificate Trust Policy Available for: Mac OS X v10.6.8, Mac OS X Server v10.6.8, OS X Lion v10.7.1, Lion Server v10.7.1Impact: An attacker with a privileged network position may intercept user credentials or other sensitive information
Description: Fraudulent certificates were issued by multiple certificate authorities operated by DigiNotar. This issue is addressed by removing DigiNotar from the list of trusted root certificates, from the list of Extended Validation (EV) certificate authorities, and by configuring default system trust settings so that DigiNotar’s certificates, including those issued by other authorities, are not trusted.
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.
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
Key iOS Security Updates Patch PDF and Certificate Validation Vulnerabilities (4.3.4 and 4.3.5)
The two latest iOS updates are fairly significant in that they patch two critical vulnerabilities. iOS update 4.3.4 patched a number of bugs including comex’s PDF/FreeType vulnerability used to create the latest JailbreakMe exploit. If you’re a jailbreaker, it’s essential that you run comex’s ‘PDF Patcher 2′ within Cydia, in order to patch the underlying vulnerability. iOS update 4.3.5 released a couple days ago, patches a fairly significant bug in the way iOS validates SSL/TLS certificates. This vulnerability can allow an attacker to intercept and/or modify data protected within an SSL session without the user knowing it. This was possible to due the fact that iOS didn’t validate the basicContstrains parameter of SSL certificates in the chain.
If you’re only an occasional patcher – now is the time.
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).
Jailbreak iOS 4.3.3 with JailbreakMe 3.0
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.
Loading ...
