5

iOS, like most other mobile OSs, has the potential to leak significant chunks of personal information to 3rd-party apps and to ad and tracking networks used by those apps, which in turn also has the potential to allow aggregating and tracking user identity and behavior across apps.

Location Services was finally locked down and the native Safari browser can be kept clean, but installed apps can still access Contacts, photos, and unique device identifiers without knowledge or consent of the user.

What strategies, tactics, and tools are available to help improve privacy with respect to 3rd-party apps, while maintaining a reasonable level of functionality?

AviD
  • 72,138
  • 22
  • 136
  • 218
pseudon
  • 1,420
  • 9
  • 20
  • iOS 7 and iOS 8 added substantial protections against apps accessing private data stores. Per-app permissions are now needed for: Location, Contacts, Calendar, Reminders, Photos, Bluetooth Sharing, Microphone, Camera, Health, HomeKit(?), and Motion & Fitness (though this grants access to Apple's Health app by default). – pseudon Mar 14 '15 at 15:04
  • There is also now a relatively easy way to reset the Advertising Identifier, and a (less easy) way to reset the Vendor ID. Force-quitting apps often can reduce one vector for fingerprinting. The more relevant question now may be: http://security.stackexchange.com/questions/70982/what-unique-device-fingerprinting-information-can-an-ios8-app-collect – pseudon Mar 14 '15 at 15:04

3 Answers3

3

In addition to the other answers, here are more tips :

  • if you must use social media, use either their mobile site or a third-party client. Social media is evil by definition as their way of making money is by reselling personal data, but third party developers couldn't care less about the social media site making money, they just want you to buy their app and will respect your privacy in most cases. Make sure you trust the developer, a concrete example of evil third-party apps would be the endless Snapchat screenshot apps coming from unknown developers often with Chinese names; if you want to see the damage done by these apps, search for snapchat leaked (NSFW); if you can't find a client you trust just don't use that social media service at all.

  • don't install all the apps you can see. For a developer, having their app on your device should be a privilege, not a right. There is really no need to install the latest clothes store's app or the new train/plane ticket comparison app. News app are evil as well, there is really no need for an app to read news, Safari can do so just fine, both for buying clothes, reading news and about 70% of what you're doing on your phone.

  • prefer paid apps over free ones. Free apps mean either there is advertising (your privacy is violated by the ad companies) or that you become the product (your privacy is violated by the app's developers themselves). Both are equally bad. Paid apps on the other hand have no advertising, so assuming you trust the developer you should be safe.

  • again, use Safari (in private browsing mode) whenever possible. Installing an app should be only as a last resort and that should mean you trust the developer entirely, which should rarely be the case.

  • finally, if you have the technical means and knowledge to do so, consider passing all your device's traffic through your network (via an HTTP proxy, VPN, or custom APN; the latter is very costly but means the carrier routes all the internet traffic from your mobile plan directly through your network, avoiding the need to configure a VPN on the device itself). You'll see, in addition to the obscure traffic caused by the device itself, quite a bit of analytic and crash reporter traffic. While they're less evil than plain advertising, they also should burn in hell. Block them at the proxy level (which can filter based on the hostname even with HTTPS) or at the firewall level in the worst case.

Community
  • 1
2

My flippant but accurate answer is "don't store your nudey photos on the iPhone". You could audit apps by sniffing the data sent to and from an iPhone in a representative configuration, but that won't be able to inspect data sent by apps that use TLS correctly. If you don't trust the third-party apps with sensitive data, don't give them any sensitive data to play with.

Where you are able to verify the function of a particular app (for example you get a third-party test report, or they offer you the source to audit and you trust that they used the same source to build the product, or it's your own app) then you can be confident that on a non-jailbroken iPhone, the content stored by that app in its container is unavailable to other apps due to the sandbox restrictions. But if the app starts using shared storage like the camera roll or address book, you're back to trusting all the apps.

2

Besides what the App Store provides, privacy policy inspection is typically done manually for iOS apps.

I utilize a DNS blackhole to create a transparent proxy while running Network Miner and using a pluggable logging proxy to replay SSL/TLS or other encrypted protocols. Mallory is often cited as a great pluggable logging proxy, but I prefer Burp Suite Professional because I often perform additional tasks with this tool. Note that this DNS blackhole method will not catch IPs that do not perform name translation, although a sniffer will still pick that traffic up.

A better method might be to inspect the source code during and after building it (when available). I use xcodebuild (along with clang-analyzer and Fortify 360 SCA sourceanalyzer) and Flash Professional to handle much of this work. The smartphonesdumbapps analyze_ios.pl tool is also quite excellent.

There are many tools for tracing execution when using the iOS Simulator, such as dtruss, iprofiler, Instruments, iosnoop, execsnoop, the DTraceToolkit, etc -- all of which really rely on the OS X version of DTrace. These are not as available on device, which supports gdb (XCode also automatically attaches lldb to the iOS Simulator or device when successfully building the code from the GUI).

If you want to see the Objective-C runtime on device, I highly suggest cycript.

Apple's policies regarding Contacts and UDID are changing rapidly. I do not believe that Apple's policies can be relied on, as many malicious apps have been made available through their App Store throughout its existence. Yes, less than Android -- but it still has happened.

A few Android apps that perform this type of inspection do exist, such as TrevE's Logging Checker, and the many apps from Lookout Mobile Security. I do not find these tools to be perfect, and perform a similar analysis as the iOS one using similar tools (strace instead of DTrace, Android Emulator instead of iOS Simulator, Android SDK instead of xcodebuid, Eclipse ADT instead of XCode GUI, FindBugs instead of clang-analyzer, etc).

I'm sure we'd all love to have Lookout Mobile Security app equivalents on iOS, as well as a cycript implementation for smali on Android.

atdre
  • 18,885
  • 6
  • 58
  • 107
  • https://krausefx.com/blog/announcing-inappbrowsercom-see-what-javascript-commands-get-executed-in-an-in-app-browser – atdre Aug 19 '22 at 13:23