Nitesh Dhanjani

Cross Device Attacks Using Cloud Sync: An iCloud Example

The “protect the data, not the (mobile) device” mantra is permeating across organizations today, and that is a good thing. In this article, I wish to support the thought process by lending evidence for the following hypothesis: cloud synchronization services are likely to become a popular attack target by way of the desktop which is currently the weakest link.

In other words (and using Apple’s ecosystem as an example):

1. Individuals in the work place that use an iOS device (iPhone or iPad) also own a desktop (or laptop). 
2. The desktop operating system (OSX or Windows) is still the choice avenue of attack.
3. Individuals are increasingly relying upon applications on their mobile devices to store private information (credentials, financial, health).
4. Most users use iCloud to sync data between their applications on various devices. Note that iCloud files sync across devices regardless of if there is a corresponding app installed on the particular device.
5. A malware or root-kit that infects the desktop can steal and influence data that is synced using iCloud (as illustrated in the rest of this article).

Figure 1: Core iCloud services provide by Apple

The iCloud service offers two distinct services. As shown in Figure 1, the set of core services allows the user to backup and restore their device, as well as sync (i)Messages, contacts, calendars, reminders, Safari bookmarks & open tabs, notes, Passbook information, photos, and use the Find My iPhone feature.

These services can be turned on individually or managed via an MDM (Mobile Device Management) solution. Should these services be utilized, the “keys to the kingdom” in being able to access the user’s device data fully relies upon the strength and secrecy of the user’s iCloud password. In my blog post titled Apple’s iCloud: Thoughts on Security and the Storage APIs [PDF], I also discuss this risk in addition to a possibility of automated tools that scrape credentials of users compromised from other attacks (and published in forums and avenues such as @PasteinLeaks) to capture users’ iOS device data en masse.

Figure 2: iCloud Storage APIs (turned off in this case)

The second service offered as part of the iCloud services are Storage APIs that 3rd party developers can use to have the user’s sessions and application data seamlessly sync across devices and Operating Systems. This feature is the focus of this write-up.

Figure 3: iCloud directory in the GoodReader app on the iPhone

 

Figure 4: iCloud directory in the GoodReader app on the iPad

For example, the GoodReader app can be configured to use iCloud to manage documents across devices (iPhone in Figure 3 and the iPad in Figure 4).

For the purposes of the attack vector, assume that the user’s Macbook Air has been compromised. Traditionally, the attacker would be limited to the data stored on the OSX file-system. If the attacker wanted to gain access to data on other devices, the best bet would be to look for backup files. However, many users these days do not routinely backup their iOS devices with their laptops and choose to utilize iCloud instead. In this situation, the attacker can directly browse to the user’s ~/Library/Mobile Documents/ directory to access application data stored by apps that utilize the iCloud Storage APIs. What’s more - any changes the attacker makes to files in this directory are synced back to the iOS devices.

$ ls -al ~/Library/Mobile\ Documents/JFJWWP64QD~com~goodiware~GoodReader/Documents/Financials/

total 8

drwxr-xr-x  3 user  staff   102 Jan 29 21:04 .

drwxr-xr-x  4 user  staff   136 Jan 29 21:02 ..

-rw-r--r--  1 user  staff  2784 Jan 29 21:04 Fiscal_Q1.pdf

At this point, the user can steal the Fiscal_Q1.pdf, delete, or alter it. These changes will be reflected onto the user’s iOS device within seconds. Imagine the implications these might have to a victim user who’s profession is in the financial, medical, and military fields.

Based on this possibility, here are some points to take away:

The desktop OS is quite likely still the weakest link and can give rise to Cross Device Attacks such as these. Future malware and rootkits are likely to exploit this. In case of iOS devices with Document sync turned on, attackers and rootkit authors are likely to take advantage of situations where one of the devices can be easily compromised. They are likely to target popular iCloud apps to steal data as well as to modify and influence business transactions to their advantage.

Developers need to be cognizant of data-flow within their apps. Not all types of data, specifically credentials, need to be synced across devices. Note that app data may also sync by way of Apple’s core backup & restore service; developers can mark files that shouldn’t by synced by invoking addSkipBackupAttributeToItemAtURL or storing the files in Library/Caches within the iOS bundle.

Enterprises must prepare to enable sync services. At the moment, the easy solution may be to configure employee devices via MDM to disable iCloud backup and documents. However, customers and employees will demand the enablement of sync services such as these will provide seamless transition across devices and increase in productivity. Perhaps the convergence of desktop and mobile Operating Systems and devices may pave the way to the right direction - it can be argued that the Sandbox mechanism in OSX that draws inspiration from the iOS sandbox architecture is one example of this.

In summary, cloud sync technologies have blurred lines surrounding data compartmentalization. Organizations that are seriously looking into creating solid mobile security strategies must accept this reality - the entire ecosystem of devices, including attack vectors across devices, should be taken into account and incorporated into the strategy.

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.

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.

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.

Blame the Credit Card Franchise: Criminals on Amazon's EC2 (Elastic Compute Cloud)

As a technology enthusiast first, and an information security professional second, I admire the internal complexity, external simplicity, and sheer power offered by Amazon's cloud computing services. Academics have forever fantasized about instant-on-pay-per-use-grid-computing. Amazon has been able to turn this into reality. The advent of utility computing indicates progress: it is 2009 - most of us shouldn't have to dwell on organizing computing infrastructure - rather, most of us should be able to take computing for granted so we can create great things with it.

I'd like to discuss how the EC2 service, as it stands currently, can and is being abused by criminals. I'm not the first person to bring up this problem, yet it is an important issue that is worthy of further discussion because it exposes an extraordinarily powerful infrastructure into the hands of cyber-criminals.

For the purpose of this conversation, I want to take upon how the criminals in the phishing underground are likely to benefit from Amazon's EC2 because it ties back to what I feel is the root issue (the credit card system). I'd also like to invite you to read an interview with Billy Rios and me, titled Spies in the Phishing Underground, to gain some further background on  the characteristics of the average phisher, common tools used, and how the criminals are able to communicate and trade knowledge.

In order to setup a phishing site, the first task a criminal has to complete is to compromise and gain access (or obtain by way of bartering) to a server on the Internet. The next thing the phisher is likely to do is to un-archive a ready-made phishing-kit (HTML, JavaScript, and images representing the target organization's logo, in addition to a server side script that is responsible for collecting the POST variables and emailing them to a static email address owned by the phisher) in the web-root of the web server running on the compromised host. And there you have it, a fully working phishing site.

A typical phishing site is found out by the targeted organization via customer complaints or by the aid of community driving anti-phishing efforts (example: Phishtank). Once this happens, the ISP who owns the IP address of the compromised host is identified and contacted. All of this happens within a matter of hours. In other words, the time-to-live of phishing sites is less than a day, if even a few hours. This promotes a whack-a-mole approach to the problem: criminals setup phishing sites as fast as they can, while organizations that are targeted must locate them and attempt to shut them down by contacting the ISPs.

The goal of the targeted institutions is to play the whack-a-mole game faster: find the phishing sites as fast as possible and shut them down before their customer data is stolen.

On the other hand, the goal of the phisher is to play the whack-a-mole game harder: quickly spawn new instances of phishing websites and lure potential victims to submitting their information. Because the time-to-live of phishing sites is only a matter of hours, it is in the best interest of the criminals to continue to seek out faster methods of spawning new instances of phishing sites. This is why Amazon EC2 is a ripe platform for the phishers. If you are a phisher, this is the process you can follow to abuse the EC2 platform:

1. Sign up for an Amazon account and EC2 service using a single stolen credit card.
2. Configure an EC2 virtual instance (AMI) to host a phishing site.
3. Spawn n instances of the AMI. Phishing sites are now active (if the default number of instances a new customer is allowed to create is low, the phisher will have to create m Amazon accounts in step 1. to get n X m instances if that is the goal).
4. Collect thousands of additional credit card numbers in a matter of hours.
5. Amazon is likely to be notified of the phishing sites and will terminate the account and all associated AMIs. No problem. Just select one credit card out of the hundreds or thousands you have likely to have captured in step 4 and go back to to Step 1.

Do you see the problem at hand? EC2 is an extraordinarily powerful infrastructure available to anyone with a stolen credit card. Even if someone is able to use the EC2 platform for a few hours with a stolen credit card, he or she will be able to initiate a vicious cycle that may become impossible to halt.

I feel that the root cause of this situation is that credit institutions, based on weighing lost revenue to the amount of fraud committed, have decided to accept the fraud because the cost of instituting a more secure mechanism (biometric or 2-factor, for example) is higher than the cost of the fraud. Profitable institutions have the right to make a business decision such as this, but the problem in this scenario is that the cost of the fraud due to credit card transactions, which are insecure by design (the credit-card system is based on a static number that never changes), is also borne by merchants such as Amazon and also the organizations that run business using the Amazon cloud, yet this cost is not figured into the original business decision.

I think this is a disappointing situation. From a business perspective, I sympathize with Amazon - here is a company that wants to offer bleeding-edge innovation to the masses, yet they are unable to find an alternative to the credit-card system without having to compromise and make it difficult for the legitimate people to also use the service. Even so, I am glad that Amazon continues to offer their platform to the masses. Innovation should be allowed to drive forward. Always.

It isn't within the scope of this write-up to consider technical tactics Amazon could use to lower the impact and probability of the problem (but feel free to comment if you want to discuss). However, I do wish that Amazon did a better job of setting up a clear channel of communication so information security researchers and administrators are easily able to reach them. I have been asked for advice by some organizations who have noted denial of service attacks launched their way, originating from the Amazon cloud space, and I'm told it often seems next to impossible to reach anyone at Amazon who knows or cares enough to look into the matter.

In closing, you may be interested in my earlier write-up on this topic which is a little dated but may still be of some value: Amazon's Elastic Compute Cloud [EC2]: Initial Thoughts on Security Implications.

Why Jerry Seinfeld Probably Cost Microsoft a Lot More than $10 Million

In a previous article, Hacking the Psyche, I presented the security and privacy implications of capturing feelings of individuals using on-line mechanisms for good use as well as abuse and manipulation. Whenever controls around individual privacy are called into question, there is always, on the other side of the coin, a clear business opportunity.

Corporations often use indirect data such as demographic information and sales statistics to measure the health of their brand because the direct data, i.e how the public and their customers actually feel about their brand, is not available for capture. In this article, I want put forth a case study to demonstrate how capturing feelings on the social web can allow companies to measure the reputation of their brand.

In September 2008, Microsoft reportedly paid Jerry Seinfeld $10 Million dollars to star in it's recent TV commercial campaign. In this article I want to provide evidence to facilitate the hypothesis that Microsoft, in addition to paying Seinfeld, suffered the additional cost of damage to its brand from the commercials. On a positive note, the I'm a PC commercial that followed seems to have up for the damage.

Here are the TV advertisements:

September 4, 2008: Shoe Circus [starring Jerry Seinfeld and Bill Gates]

September 11, 2008: New Family [starring Jerry Seinfeld and Bill Gates]

September 18, 2008: I'm a PC [not starring Jerry Seinfeld]

Now, lets turn to Twitter to measure the feelings expressed towards these commercials during the month of September 2008. Using the Emotion Dashboard tool I presented in Hacking the Psyche, I was able to visualize how people on Twitter felt about these commercials. Here's a video of the tool in action:

Here is a screen-shot of the result including some annotations:

   
1. Most people disliked the first commercial (Red bar indicating overall negative feelings). The most common word used to express feelings towards the first commercial was "WTF" as indicated by the word cloud and the video demonstration.
   
2. Feelings on the Microsoft brand started to pick up to a positive state only to be re-plummet downwards once the second commercial was aired (Red bar).
   
3. The third commercial, I'm a PC, devoid of Seinfeld, was generally liked and appreciated, helping feelings towards the Microsoft brand return to a positive state (Yellow bar indicating 'happy' feelings).

There you have it: a powerful method to use feelings expressed in social media to measure a corporation's brand and marketing efforts.

Brand reconnaissance is not the only effort that can be leveraged from feelings on the social web. If you are interested in this topic, I invite you to consider my upcoming talk the O'Reilly Money Tech Conference titled Emotion Dashboard: Harvesting Feelings on the Social Web for Powerful Decisioning.

Hacking the Psyche

In this article, I want to persuade you of the real possibility and high probability that, in the very near future, remote entities will be able target people’s on-line presence to capture and leverage their emotional states and feelings. There are some very extreme implications of this from a security and privacy perspective, and this is the scope I will adhere to in this article. On the flip side, the ideas presented in this article can be leveraged to construct powerful business decisioning and measurement capabilities, a topic that deserves it’s own space - I will cover this subject in a separate article in the next few days.

Before I go any further, I want to stress that the purpose of this article is not to spread undue alarm, nor is the purpose to portray social online media as an evil. I personally utilize the many avenues of online communication and collaboration facilitated by the Generation Y culture. The purpose of this article, instead, is to share some of my initial thoughts on the possibilities of abuse, specific to the mapping of individual feelings online and possible implications.

We Feel Fine.
To begin with, I insist that you watch Jonathan Harris’ TED talk titled The Art of Collecting Stories:

In this talk, Jonathan describes his passion for making sense of the emotional world and his deep compassion for the human condition. Regardless of this particular article, Jonathan’s talk stands on it’s own. I think Jonathan’s ideas, projects, and aspirations are true works of art. His ideas are powerful enough to inspire a security professional such as me to look outside the oft-incestual world of information security, and to reach out and connect with other venues of Science and understanding. In a small way, the material presented in this article are my attempts to try and do just that.

I invite you to visit one of Jonathan’s projects that he co-founded with Sep Kamvar - We Feel Fine :

Since August 2005, We Feel Fine has been harvesting human feelings from a large number of weblogs. Every few minutes, the system searches the world's newly posted blog entries for occurrences of the phrases "I feel" and "I am feeling". When it finds such a phrase, it records the full sentence, up to the period, and identifies the "feeling" expressed in that sentence (e.g. sad, happy, depressed, etc.). Because blogs are structured in largely standard ways, the age, gender, and geographical location of the author can often be extracted and saved along with the sentence, as can the local weather conditions at the time the sentence was written. All of this information is saved.

The result is a database of several million human feelings, increasing by 15,000 - 20,000 new feelings per day. Using a series of playful interfaces, the feelings can be searched and sorted across a number of demographic slices, offering responses to specific questions like: do Europeans feel sad more often than Americans? Do women feel fat more often than men? Does rainy weather affect how we feel? What are the most representative feelings of female New Yorkers in their 20s? What do people feel right now in Baghdad? What were people feeling on Valentine's Day? Which are the happiest cities in the world? The saddest? And so on.

...

At its core, We Feel Fine is an artwork authored by everyone. It will grow and change as we grow and change, reflecting what's on our blogs, what's in our hearts, what's in our minds. We hope it makes the world seem a little smaller, and we hope it helps people see beauty in the everyday ups and downs of life.

Here is a video I uploaded to Youtube, demonstrating We Feel Fine’s interface, including the ability filter for specific targets (for example: feelings expressed by individuals in their 20s in Iraq):

Emotion Dashboard: Targeting Individuals.
The We Feel Fine project does not target specific individuals. The creators of the project imply that doing so would violate an individual's privacy:

Privacy: We Feel Fine only collects and displays data that was already posted publicly on the World Wide Web? We Feel Fine never associates individual human names with the feelings it displays, though it always provides a link to the blog from which any displayed sentence or picture was collected....

We Feel Fine is a work of art designed by well meaning intellectuals. It doesn’t have the capability nor the intention of intruding on any one particular person’s privacy, yet the project raised my personal consciousness towards the security and privacy implications of capturing the feelings (past and present) of individuals.

To pursue discussion around the possibility and implications of capturing feelings projected by individuals online, I decided to develop a proof of concept visualization tool that I will call Emotion Dashboard. This is not a production-ready tool of any sort because I do not currently have the resources to develop such a thing. The goal of this tool (if you should even call it a tool) is to demonstrate my ideas and my vision on this particular topic to facilitate and encourage further discussion in the community. Here are the components of Emotion Dashboard:

• RSS. It consumes an RSS feed as its source of input. This RSS feed can include more than one resource stitched together using a service such as Yahoo Pipes:       
  

  In other words, the targeted individual’s online presence may include his or her Facebook profile updates, Blogs, and Twitter messages. In this way, updates on all of the sources of a particular individual’s online presence can be coupled together in one RSS feed and then supplied to Emotion Dashboard which will scan the feed from the past to the present (older entries first).

• Pulse. In order to visualize the emotional state of an individual from the past (older RSS entry) to the current, the tool includes a line graph at the top of the interface that tends upwards when a word that expresses a happy (positive) emotion is found, and downwards when a word that expresses a sad or angry (negative) emotion is located. To accomplish this feature, I was able to leverage the CSV file provided by the We Feel Fine project located here: http://www.wefeelfine.org/data/files/feelings.txt. This file includes a list of words that are commonly used to express feelings. I marked each word in this file against my judgment of it being a positive or negative sounding word. Occurrences of these words are plotted on the line graph, and can also be clicked on to spawn a new browser session targeting the relevant location of the word.

   
  Immediately below the line graph is a solid bar that expresses the culmination of the individual’s overall mood. The color of this bar is either Yellow (happy), Blue (sad), or Red (angry).  The hex code for these colors are also derived from the We Feel Fine CSV file listed above.

  

  I concede that this technique of merely grepping for words lacks context and that is prone to an extremely high error rate. However, given the limited amount of resources I have at this point, my goal is not to provide something that readily usable for all cases, but to present a starting point of a possible approach and the probable implications should this be extended to apply intelligent grammar based contextual analysis. Do note that, even though I concede this is an approach vulnerable to a high error rate, the technique does, statistically speaking, get slightly more accurate the more words it consumes.

• Word Cloud. Below the line graph is a simple word cloud containing words from the CSV list discussed above. As the RSS feed is analyzed from past to present, words in the word cloud grow in size as they re-occur.

  

  The word cloud allows the user to analyze the words being used to express feelings as the Emotion Dashboard reads the RSS feed from past to present. The words in the cloud are colored based on the associated hex color codes present in the CSV file.

The following is a screen-shot demonstrates a sample output of an individual’s (who we will call “Jack Smith” for the purposes of this discussion) online presence:

Here are some observations and implications:

• Jack’s initial online presence portrays his emotional state as positive (word-cloud: happy).
• Jack’s blogs about his friend being laid-off from his job (word-cloud: layoff). This is a negative event.
• Feelings expressed by Jack on venues (other than this blog) where he has online presence (example: Twitter), on the same day as his blog entry about his friend’s layoff, are extremely negative (word-cloud: handicapped, upset) even though Jack is discussing other topics. This can lead to the hypothesis that Jack’s overall mood is negative because he is influenced by his friend’s situation. This hypothesis, if true, may allow a malicious third party into manipulating Jack’s negative state to influence his actions. However, in order for such a tactic to succeed,  the third party will need to understand Jack’s personality to understand how Jack behaves in moments of stress. It is possible for a third party to construct a personality profile on Jack by studying his authored content based on his on-line presence (blog, Twitter, Facebook, etc) and correlating it with known personality analysis methodologies, for example, the Big Five personality traits based tests:



Once enough information about Jack is collected to reasonably satisfy the personality test requirements, Jack’s personality patterns can be determined that may aid a malicious third party in exploiting Jack’s current emotional state. It is also plausible that this an be extended to automated and trigger based abilities. This is an extremely powerful idea - Jack may not be consciously aware of his negative mood, yet a third party may be able to analyze this remotely with some degree of probability. The following is a screen-shot of the results of a Big 5-like personality test (courtesy of Signal Patterns) :

• Jack’s mood recovers to a positive state as time progresses, only to be briefly pulled down momentarily by his discussion of his friend’s layoff situation. This illustrates that the after-shocks of his friends situation are still negatively affecting him.
• Eventually, Jack recovers to his average positive state (word-cloud: nice).

Case Study: Criminal Investigation and Analysis.
There are numerous security and privacy implications of the discussion at hand. I am unlikely to succeed in attempting to iterate them all. Instead, I want to present one particular case study that can further illustrate the impact of this topic.

In this case study, I want to take upon the following real incident: http://blog.mlive.com/chronicle/2008/07/excon_vents_pain_online_then_k.html

Ex-con vents pain online, then kills
OCEANA COUNTY -- Danlee Mead was apparently using his MySpace site to tell the world how unhappy and desperate he felt in the hours before he abducted and killed his wife, then turned a shotgun on himself.... Hours later, the depth of the ex-convict's anguish turned to violence.....

A cached copy of Danlee’s MySpace page suggests that he changed his profile (moments before he committed the violent act) to use more positive-sounding words, even though his overall thoughts remained negative. His prior profile, also consisted of negative feelings, yet the words used in the original profile were more negative-sounding. Here is a demonstration of what his profile looks like when run through an analysis over time:

A few observations:

• Initially, Danlee’s Myspace profile frequents negative-feeling words (blue bar).
• His profile remains consistently negative over time (blue bar).
• The words used in his updated profile tip the mood bar to positive (yellow). This is when Danlee changed his profile right before committing the crime.

Following from the above observations, it is clear to see how this type of analysis can be used by investigators, admittedly after-the-fact, to get a glimpse into a suspect's state of mind over time.

It may not be possible to use data from online social media to proactively detect the future behavior of all individuals, yet in this situation, the criminal did indeed have prior history of crimes. Perhaps a proactive approach targeted towards known suspects’ online social presence can be used to detect certain deviance form tuned thresholds - possibly in an automatic fashion based on a set of defined triggers. Such an approach seems more tolerable for a set of individuals with known backgrounds because the elements in their history can aid in influencing the signal-to-noise ratio in favor of the signal.

Some Additional Thoughts.
The prior case study was just one illustration of the many impacts of using social media to capture the psyche of individuals. Here are some additional thoughts:

• There are positive and negative implications of targeting individuals (or groups). In the first situation, it is easy to see how Jack’s online activity was used to get a better understanding of his psychological state, in addition to the hypothesis on how something like this can be further extended to aid in malicious manipulation and influence by a malicious entity. In the second situation, it is clear to see how the visualization of expressed feelings online may aid investigators into obtaining further insight into a given case.
• The victim is the volunteer. Individuals with social presence online willingly contribute and volunteer data that can facilitate the mapping of their psyche. This is in contrast to the Orwellian sense, where information is extracted from the victims in an intrusive way.
• The data set is genuine. Most people do not over-edit their blog entries or Twitter messages to conceal emotions.
• The study of an individual’s online presence and it’s correlation to emotion and personality analysis is most likely to remain probabilistic. This introduces the risk of unfair analysis. For example: What does it mean for an individual to be identified, and in turn judged, as someone with a 15% chance of being a psychopath?
• (online) Social privacy is an oxymoron. Social applications are, by definition, mutually beneficial to users within the system. If you sign up on a social networking application as Mickey Mouse to protect your identity, your friends will not be able to find you, thereby decreasing the value of the system to you. The popular social networking sites often promise privacy by implementing controls on certain tuples, yet as a user, it is important to understand that there is implied and indirect information within the system (such as connections between networks and the cases presented in this article) that cannot be concealed without destroying the core use-cases of the social application.

To conclude, I sincerely hope this article facilitates further discussion around the topics presented. You may feel that the probability of fruition of some of my thoughts and ideas is low. Perhaps you may find them extremely fantastical, or perhaps you agree that the scenarios presented indeed have a high probability of being relevant in the near future. I am obviously intrigued by the topic and I’d be delighted to hear your thoughts.

New O'Reilly Network Article

My new article, titled "Google Your Site for Security Vulerabilities" is available here. It includes google_vulns.php, a sample PHP script, which uses the Google API to search for sensitive data.

Nessus Article

My new article, Installing and Configuring Nessus, is now available. Part 2 of this article will discuss NASL and how to write Nessus plug-ins. It should be up in a few weeks or so.