Posts tagged ‘vulnerability’

Subscribe

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.

Share this:

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):

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.

Share this:

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.

Share this:

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!

Share this:

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.

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:

Share this:

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.

For sysadmins, the following Terminal command achieves the same thing:

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.

Share this:

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.

Share this:

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.

Share this:

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

Share this:

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.