Local information leakage found in multiple iOS apps.

This post has been in the making for some time. There are multiple reasons why it hasn't been finalized until now .

One of the reasons was because I don't know what to make of  these findings, but some of the things I found got me thinking about how much information we are carrying around with us on our everyday devices, that insight isn't unique. But I would like to add my $2 cent to the insight and show how simple it is to do application "snooping".

No (special) skills required ;)

I decided to look at which information I was able to view/access from apps installed on a non jailbreaked iDevice.

Using Ubuntu and the bundled Fuse driver, that enables you to easily access your iDevice and it's content like stored pictures and applications which is what the drivers was made for in the first place I guess.

The best way I found to analyze installed applications from a running system, was to use the ideviceinstaller application.

ideviceinstaller enables you to install (as the name implies), remove and backup application.

            $ ideviceinstaller -a com.goodiware.GoodReaderIPad -o copy=/tmp/

This will create a local copy of the installed GoodReader app. The app will be copied to the tmp directory as a zip archive. Which you can easily unzip to gain access to the application files as if it was on the device it was archived from.

Many of us handle these devices with "great" care, to protect the information that are stored on them(locking the device, not enabling SSO in apps etc).

Sadly not everyone are doing this. It can be painfully obvious if you look at your friends and families devices the next time you meet up. I think this is especially true with "younger" users.

This raises the questions. should a unlocked device be fully open for information snooping? As you will see further down, some apps store information locally that is not available unless you are logged in to the application it self, why should that information be available without a valid login and password?

A short note on something that got me of the track for a while, the first time you connect a locked device, you will have to unlock it to be able to have your Linux based system access the device. However the next time you are able to connect and access the locked device even though it's locked. It's seems that there is some "key exchange" during the first "sync" which is then locally stored on the connected device (the Linux box)

.config/libimobiledevice should after a successful connection contain files like

HostCertificate.pem

HostPrivateKey.pem

libimobiledevicerc

RootCertificate.pem

RootPrivateKey.pem
and a file with a long random name.pem, that is unique for the connected device

If you happen to see a error message that says that you are unable to mount your iDevice
"Unhandled  Lockdown error (-15)" (This is usually because you have connected a locked device for the first time to the Linux host)

Then try wiping the content of the libimobiledevice directory to be able to access your iDevice(unlocked this time).

On a locked device the attack vector ends up being quite limited, as you will have to connect the device once, unlocked to be able to retrieve information from the locked device in the future. It's possible but still very limited.

Update: Even if you take some measures to lock your device to prevent a lost device from being data mined, there might be some occasion when you would let others have access to your locked device, two examples that come to mind, if you have to get it look over by a support tech or if you are told be customs or any other LE department to hand over your device for inspection. This is the information that would possible be disclosed by doing so. You would most likly hand over it unlocked.

Findings:

<Unnamed bank app>: I was able to list all my previous bank transactions (including amount, date and information) from a well known "Nordic bank" app .
 
Vendor was informed during fall but has not yet solved the issue .. This is information that requires a valid login to be displayed and one can question if this information should be stored in plain or rather if it should be stored locally at all ..

Skype: The Skype app stores "all" previous chat conversations in clear text

(Container/Library/Application Support/Skype/<username>)

Apple mobilme: The mobilme app has a feature that enables you to track your iDevices and other Apple hardware(Macbook's etc)

The application does not only store information about the device it's installed on, but it also has information about the other devices that are been "tracking" enabled using the same Apple-ID.

The information includes, besides the devices, the name you have given the device and

which generation and/or model they are. It also contains a long random sequence which is the same for all devices, most likely the unique ID that connects all devices for that account.

Facebook: Contains a list of all connected friends ..

( Container/Library/Caches/4100.0).. nothing really secret I guess ..

Linkedin: Contains amongst all connections private email addresses, the one you only have access to if you are connected to that person or has configured your account to show(?). Also it contains a value called "accesTokenXmemberId", "SkeyVsecret" and "WOATokenXNSObject", these values could maybe be used for the apps authentication(API?)? They could possible be used outside the apps for access as well .. I have to look into it ..

More to look at

I tried to copy the Google authentication app from one device to another to see if I was able to leverage the information stored in the application. This did not go so well and will require more research as this would be "bad" if one was able to copy a software token.

This might require one to pick a part the application and rebuild it as the application is most likely bound to the installed device. This was true with the google app, but there are more softtoken apps on the marked to be looked at...

But to summarize this confusing post, I can say that I learned a few new tricks and I found some interesting information and remembers that even if you take care to not allow single sign on for your favorite apps, the apps them self might store the very information that you would like to keep private locally.

/Mikael

Update: The unnamed bank just released a new version fixing the above described problem.