12.7k VIEWS
Pinterest LinkedIn LINE

This afternoon (June 18), GigaZine published a sensational article titled “Vulnerability Found That Allows iCloud, Email, and Browser-Saved Passwords to Be Stolen on iOS and OS X; Apple Ignored It for More Than Six Months” 1. I suppose that is to be expected from web media, but the article alone left me with no idea what this was actually about, so I read the original paper.

Here is the paper.

  • Xing, Bai, Li, Wang, Chen, Liao: “Unauthorized Cross-App Resource Access on MAC OS X and iOS” 2

First, let us applaud the authors.

With that said:

The zero-day attacks the authors claim to have discovered for the first time fall into the following 4 categories, or 5 when classified in detail.

  1. Password Stealing (a Keychain access-control vulnerability)[MacOS X]
  2. Container Cracking (an Apple App Store oversight in Bundle ID verification) [MacOS X]
  3. IPC Interception (3.a WebSocket non-authentication, and 3.b local OAuth redirect) [MacOS X]
  4. Scheme Hijacking [MacOS X, iOS]

Of these, we have actually known about at least 3.b and 4 since at least November 2013. They are precisely the problems OAuth PKCE, now in the final stages of standardization, is intended to solve 3. The article also says that “there is no remedy,” but to be precise, there is no remedy an end user can immediately apply. Developers can prevent their own applications from having these vulnerabilities. I describe those measures below.

1. Password Stealing (a Keychain access-control vulnerability)

Of the 4 vulnerabilities, this is the one I found most interesting—perhaps that is an inappropriate word. It arises from a combination of 2 bugs in the Keychain access-control model.

The MacOS X Keychain is structured as shown in Figure 1.

図１）MacOS Xのキーチェンの構造
Figure 1) Structure of the MacOS X Keychain (Source: Xing et al., “Unauthorized Cross-App Resource Access on MAC OS X and iOS”)

Each Keychain item has multiple attributes, credentials, and an access-control list (ACL). The ACL can list multiple applications allowed to access the item and the operations each application may perform, such as reading and writing. Only the applications specified there can access the item. Conversely, the listed applications can read or write the item’s information.

The ACL can be specified by the application that first created the item.

The attack scenario is as follows.

  1. Before the legitimate application creates the Keychain item, a malicious application creates it and also registers the legitimate application in the ACL.
  2. The user installs and begins using the legitimate application, which writes credentials to that item.
  3. The attacking application reads the value that was written.

On its own, this might seem unlikely to succeed because the attacking application must be planted before the legitimate application creates its legitimate Keychain item. With iCloud, for example, the item is created immediately after OS installation, so stealing iCloud credentials might seem impossible. There was, however, another bug that completely changed the situation:

“Any application can delete the item, provided it does nothing more than delete it.”

By using the following attack pattern, it therefore becomes possible to steal anything written to the Keychain.

  1. Use the attacking application to delete the legitimate application’s Keychain item.
  2. Use that same application to create the Keychain item and register the legitimate application in its ACL.
  3. The user uses the legitimate application, which writes the credentials.
  4. The attacking application reads the value that was written.

Countermeasure

To avoid this, before the legitimate application writes anything to the Keychain, it must read the ACL and check whether an unauthorized application has been inserted. Conversely, doing so prevents the attack.

Note that iOS does not have this vulnerability. It has no ACL in the first place, and an application can access only Keychain items it created itself.

2. Container Cracking (an Apple App Store oversight in Bundle ID verification) [MacOS X]

Applications in the MacOS X App Store have unique Bundle IDs and are confined within sandboxes whose namespaces correspond to those IDs. An area cannot be read by an application unless it has the same Bundle ID. Apple’s App Store checks whether a Bundle ID is duplicated and prevents registration in the Store when a duplicate exists—or at least that is what it was supposed to do.

In fact, the application Bundle ID was checked, but when an application contained a sub-application, that sub-application’s Bundle ID was not. A sub-application could therefore have any Bundle ID. Consequently, if an attacker could create a sub-application bearing the target application’s Bundle ID and persuade someone to install it, the attacker could read even the target application’s secret information.

Countermeasure

The first countermeasure would be for the App Store to perform the check properly. There are various other possible approaches, but they seem likely to take some time.

3. a WebSocket non-authentication

There are various means of interprocess communication, such as Unix sockets. The issue here, however, is local WebSocket communication. WebSocket is often used across networks, in which case a connection is made only after checks such as verifying the other party’s TLS certificate. When a local server port is specified, however, this TLS check does not work. As a result, if a spying application is listening on that port, it can steal passwords and other values entered by the user.

1password reportedly has this vulnerability. 1password listens on port 6263 for communications from its browser extension, and the 1password browser extension sends values such as passwords entered in the web browser to port 6263. Thus, if the attacking application starts before 1password and occupies port 6263, it can extract that secret information.

Countermeasure

According to 1password, a countermeasure is difficult, though I wonder why. I would have the 1password application generate a key pair during installation, give the public key to the browser extension, and encrypt all communications from the browser extension to port 6263 with that public key. Then, even if an attacking application obtained the information, it could not decrypt it and the attack would fail.

3. b Local OAuth Redirect

This redirects to a locally running web server instead of using WebSocket. The example given is an application called Pushbullet. It authenticates the user through Google Single Sign On and uses the access token arriving in a redirect to port 20807.

The attack begins when the attacking application occupies port 20807 before Pushbullet does. This lets it intercept the returned access token. After intercepting it, the attacker releases port 20807 so that the legitimate application can obtain the token.

Countermeasure

The solution to this attack is to stop using the Implicit Flow and use the Code Flow with OAuth PKCE.

4. Scheme Hijacking [MacOS X, iOS]

MacOS and iOS have an inter-application communication mechanism called custom schemes. This mechanism is used, for example, to invoke a particular application from the web or another application. Each application can specify a custom scheme. The problem would not arise if a 1 to 1 correspondence between custom schemes and applications were guaranteed, but in reality it is not: applications may register arbitrary custom schemes. A scheme-hijacking attack exploits this fact. The attacking application registers the target application’s custom scheme as its own. There is then a probability of roughly 5 tenths that the attacking application, rather than the legitimate one, will launch. If the invocation message using the custom scheme contains an access token, the token will be exposed.

Countermeasure

The solution to this attack is to stop using the Implicit Flow and use the Code Flow with OAuth PKCE [RFC7636].

Conclusion

I became sleepy and the latter half grew considerably rough. I will add more when I get the chance.

With that, see you again!

Footnotes

  1. http://gigazine.net/news/20150618-ios-os-x-password-killer/
  2. https://sites.google.com/site/xaraflaws/
  3. Sakimura, N., Bradley, J, and N. Agaawal:”Proof Key for Code Exchange by OAuth Public Clients”, RFC7636, IETF, (2015)

Related posts